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.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “There Is No Patch Tuesday on the Blockchain: Why Solidity Developers Need Fusion-Grade AppSec Before They Deploy”.
By the numbers:
- The median time from vulnerability disclosure to weaponization has collapsed from 840 days to 1.6 days.
- 80% of exploitations now occur on or before the day of disclosure.
- AI-assisted developers introduce security findings at 10× the rate of their peers, according to the Cloud Security Alliance report cited by Checkmarx.
Key questions
Q: What breaks when Solidity scanning is not reproducible before deployment?
A: What breaks is the release decision itself.
Q: Why do smart contract vulnerabilities become so much more serious after deploy?
A: Once a smart contract is deployed, flaws are effectively permanent and can be exploited before the team can intervene.
Q: What do teams get wrong about LLM-only scanning for Solidity?
A: They treat probabilistic output like reliable evidence.
Practitioner guidance
- Enforce pre-deploy scan reproducibility Require identical Solidity code to produce identical findings across repeated scans before code can pass a release gate.
- Validate contract-language coverage explicitly Inventory which scanners truly understand Solidity and mixed smart-contract code paths, then block deployment when coverage is partial or inferred.
- Separate detection from developer review Insert an independent findings-validation stage so unstable model output does not reach engineers as actionable evidence.
Bottom line: Solidity changes the AppSec model because deployment can make flaws permanent and immediately monetisable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:09 pm
Reproducibility is the control that changes Solidity security from hope to evidence. In conventional AppSec, teams can often compensate for a noisy scan with later triage or patching. Smart contracts remove that cushion, so the finding has to be stable before deployment or it is not suitable for governance. For practitioners, the key shift is that validation quality becomes part of release control, not a downstream tuning concern.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should Web3 teams prioritise deterministic scanning over AI-assisted coverage?
A: They need both, but in the right order. Deterministic scanning should provide the stable baseline for known Solidity risks, while AI-assisted analysis extends language coverage and emerging pattern detection. The decisive requirement is that every result is validated before it influences release approval.
👉 Read our full editorial: Solidity appsec needs reproducible scanning before deployment