Notifications
Clear all
Topic starter
19/08/2026 3:25 pm
TL;DR: Solidity teams face a different security problem from conventional AppSec: once a smart contract is deployed, vulnerabilities become immutable and can be exploited in a single block, while AI-assisted code generation and inconsistent LLM-only scanning increase the odds that flaws reach production, according to Checkmarx. The practical shift is toward deterministic pre-deploy validation with reproducible findings, not post-deploy remediation.
NHIMG editorial — based on content published by Checkmarx: Solidity appsec needs reproducible scanning before deployment
By the numbers:
- The median time from vulnerability disclosure to weaponization has collapsed from 840 days to 1.6 days, compressing the response window for software teams.
- 80% of exploitations now occur on or before the day of disclosure, which leaves almost no room for delayed remediation.
- AI-assisted developers introduce security findings at 10× the rate of their peers, increasing the burden on review pipelines.
Questions worth separating out
Q: How should security teams govern smart contract code before deployment?
A: Security teams should treat smart contract deployment as a hard release gate.
Q: Why do Solidity applications need stricter AppSec controls than typical web apps?
A: Solidity applications need stricter controls because deployed contracts are immutable and often hold or move value directly.
Q: What do teams get wrong about AI scanning for smart contract security?
A: Teams often assume an LLM-based scanner is enough if it finds interesting issues.
Practitioner guidance
- Gate Solidity releases on reproducible findings Require the same contract to produce the same findings across repeated scans before it can pass release approval.
- Separate Solidity coverage from generic source-code coverage Verify that the scanner understands contract-specific logic, state transitions, and on-chain value flows instead of assuming enterprise-language rules will carry over cleanly.
- Validate AI-assisted findings before developer triage Put an independent validation step between AI-generated results and engineering work so noise does not consume release-time capacity or create false confidence.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- Side-by-side benchmark results comparing deterministic scanning with LLM-only analysis for Solidity code.
- The findings validation flow that Checkmarx says removes unstable results before developers see them.
- Deployment-stage workflow details for scanning code locally without leaving the development environment.
- Performance and false-positive numbers for the multi-model approach across mixed codebases.
👉 Read Checkmarx's analysis of reproducible Solidity scanning for Web3 security →
Solidity scanning and Web3 security: what changes before deploy?
Explore further
19/08/2026 4:09 pm
Immutable code creates a governance problem, not just a tooling problem. Once a Solidity contract is deployed, the control model shifts from patching to prevention. That means release governance must account for security evidence, reproducibility, and sign-off quality before code reaches chain. For practitioners, the takeaway is that blockchain programmes need stricter pre-deploy gates than conventional application teams.
A question worth separating out:
Q: What should organisations do when smart contract findings are inconsistent across scans?
A: Inconsistent results should be treated as a governance failure, not a harmless tooling quirk. If identical code produces different findings, the team cannot reliably gate releases, brief auditors, or measure risk. The response is to require stable validation before using the scan output in production decisions.
👉 Read our full editorial: Solidity appsec needs reproducible scanning before deployment
