Notifications
Clear all
Topic starter
02/08/2026 11:39 am
TL;DR: Application risk assessments are failing to keep pace with AI-generated code, stagnant third-party dependencies, and compressed attack timelines, according to Veracode. The case for continuous, evidence-based software governance is no longer theoretical when nearly half of AI-assisted code still misses basic security tests.
NHIMG editorial — based on content published by Veracode: 6 Best Practices for Application Risk Assessments
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams make application risk assessments continuous?
A: Security teams should place assessment controls inside the development pipeline rather than around it.
Q: Why do AI-generated code changes increase application security risk?
A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up.
Q: What breaks when application risk assessments stay periodic?
A: Periodic assessments break when the software changes faster than the assessment cycle.
Practitioner guidance
- Embed continuous assessment into CI/CD Trigger static analysis, dynamic analysis, and software composition scanning on every commit, dependency update, and container build so findings arrive before release rather than after the next review cycle.
- Governing AI-generated code as a controlled input Apply the same security gates to AI-assisted code as to human-written code, including validation for unsafe patterns, explicit approval for sensitive paths, and traceability for generated changes.
- Expand scope to pipeline identities and dependencies Map the identities, tokens, and service accounts that move code through build and deploy stages, then include them in assessment scope alongside third-party libraries and images.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on embedding static, dynamic, and composition scanning into CI/CD workflows.
- Specific examples of how to report application risk data to boards in measurable business terms.
- Practical treatment of AI-generated code governance and validation controls.
- The source article's full framing of software trust as an evidence problem rather than a scanning problem.
👉 Read Veracode's analysis of 6 best practices for application risk assessments →
Application risk assessments: are your controls keeping up?
Explore further
02/08/2026 12:52 pm
Continuous assessment is now a governance requirement, not an operational preference. Point-in-time reviews assume the system remains stable long enough for the findings to matter. In modern software delivery, that assumption is false because code, dependencies, and pipeline access evolve continuously. For identity programmes, this creates a direct link between application risk and the governance of CI/CD credentials, service accounts, and workload identities. The practitioner conclusion is simple: assessment must move with the software.
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: Application risk assessments must become continuous software governance
