Notifications
Clear all
Topic starter
01/08/2026 10:42 pm
TL;DR: AI-assisted development is driving a trust gap in AppSec: Veracode says 45% of AI-generated code contains known security vulnerabilities without guidance, while 82% of organisations carry security debt and 60% of that debt is critical. Scanning still matters, but software trust now depends on provenance, continuous verification, remediation, and auditable governance.
NHIMG editorial — based on content published by Veracode: The Best Application Security Testing Tool Isn’t a Scanning Tool Anymore
By the numbers:
- Veracode says 45% of AI-generated code contains known security vulnerabilities when no security guidance is provided.
- Veracode’s 2026 State of Software Security Report found that 82% of organisations now carry security debt.
- Verizon DBIR reported that software vulnerability exploitation accounted for 31% of confirmed incidents, overtaking credential abuse.
Questions worth separating out
Q: How should security teams govern AI-generated code in production pipelines?
A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact.
Q: Why does remediation speed matter more when AI writing code is common?
A: Because AI increases the volume of code and defects at the same time.
Q: What breaks when security teams rely only on scanning and pre-runtime checks?
A: Scanning and pre-runtime checks can identify weaknesses, but they do not stop a live AI-driven attack once execution begins.
Practitioner guidance
- Define provenance requirements for AI-generated code Tag machine-produced code at creation and preserve metadata on source, approval, and policy gates so teams can trace what entered the pipeline.
- Measure remediation latency as a security control Track time-to-fix for high-risk defects and report exposure duration alongside defect counts so leaders can see how long vulnerable code remains live.
- Add continuous verification to release gates Compare approved build artefacts against deployed artefacts so drift, unauthorised changes, and unreviewed AI-generated modifications are detected before production trust is lost.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- How the vendor frames provenance, continuous verification, and autonomous remediation as part of an AppSec operating model.
- The underlying data behind the 45% AI-generated code vulnerability figure and the 82% security debt finding.
- The vendor's argument for how security trust can be attested to boards, customers, and regulators.
- The recognition context from SD Times 100 and how the vendor positions its category scope.
👉 Read Veracode's analysis of why AppSec tools must now prove software trust →
AI-generated code and security debt: are AppSec tools keeping up?
Explore further
01/08/2026 10:52 pm
Software trust has become the real control objective in AppSec. The article correctly identifies that finding vulnerabilities is no longer enough when code is being generated, merged, and deployed at machine speed. The governance challenge now is proving provenance, controlling introduction paths, and maintaining auditable assurance across the development lifecycle. For practitioners, that means security programmes must move from scan-centred reporting to trust-centred control design.
A question worth separating out:
Q: How do security teams prove software is trustworthy to auditors and boards?
A: They need evidence beyond scanner output: approved provenance, continuous verification, remediation timelines, and enforceable policy gates. Trust is demonstrated by showing how code was introduced, how it was reviewed, how quickly defects were closed, and whether the production state still matches the approved one.
👉 Read our full editorial: AI-generated code is redefining what application security tools must do
