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.
At a glance
What this is: This is an application security analysis arguing that point-in-time assessments no longer match the speed and complexity of modern software delivery.
Why it matters: It matters to IAM practitioners because software risk increasingly intersects with identity, secrets, supply chain trust, and governance evidence across both human and machine-driven development.
By the numbers:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
👉 Read Veracode's analysis of 6 best practices for application risk assessments
Context
Application risk assessments are supposed to tell teams what is safe to ship, but periodic testing now lags behind a software environment that changes continuously. In practice, the gap is not just speed. It is governance, because modern application risk assessment must account for AI-generated code, software supply chain exposure, and the identity and secrets that let code interact with production systems.
Veracode’s argument is that risk assessment can no longer be a point-in-time compliance ritual. That matters for IAM and NHI programmes because application security evidence increasingly depends on how service credentials, API keys, workload identities, and CI/CD permissions are controlled across the development lifecycle.
Key questions
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. That means scanning at commit, build, and test stages, then routing findings directly to the teams that can fix them before release. Continuous assessment only works when the workflow produces immediate, contextual action rather than delayed reporting.
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. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.
Q: What breaks when application risk assessments stay periodic?
A: Periodic assessments break when the software changes faster than the assessment cycle. Findings become stale, remediation starts too late, and critical exposure windows remain open while teams wait for the next review. In modern environments, that creates a false sense of security because the report reflects yesterday’s state, not today’s risk.
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.
Technical breakdown
Why point-in-time application risk assessments fail
Traditional application risk assessments capture a snapshot of code, dependencies, and runtime state at a single moment. That model breaks when code changes continuously, third-party libraries age without update, and AI-assisted development increases release velocity. A scan result is only as useful as the time between the scan and the next change. In modern delivery pipelines, that interval can be minutes, not weeks. The real technical problem is not that scanning is useless. It is that scanning without continuous signal propagation cannot preserve relevance long enough to support meaningful risk decisions.
Practical implication: move assessment triggers into CI/CD and tie them to every commit, dependency update, and container build.
How AI-generated code changes the risk profile
AI-generated code introduces a quality gap between syntactic correctness and security correctness. Code can compile and still contain insecure patterns, weak validation, unsafe defaults, or misused libraries. Because large language models reproduce common patterns rather than guaranteed secure ones, the organisation inherits a new assurance problem: developers may ship faster while the control surface for review stays unchanged. This makes AI-generated code a governance issue, not just a productivity issue. Security review must therefore treat AI-produced output as code requiring validation, context, and policy enforcement before production use.
Practical implication: require security checks and approval gates specifically for AI-assisted code paths before merge or release.
Why software supply chain visibility is now part of application risk assessment
Modern applications are assembled from first-party code, open-source dependencies, containers, and third-party services. That means the risk surface includes everything the application depends on, not only what internal teams wrote. Software composition analysis, SBOM practices, and container scanning are technical mechanisms for surfacing hidden risk, but they only work if the organisation treats dependency visibility as a living control. The supply chain angle matters to identity teams because many compromises pivot through stolen credentials, exposed secrets, or over-permissioned pipeline access rather than through code alone.
Practical implication: extend assessment scope to dependencies, images, and pipeline identities, not just application source code.
Threat narrative
Attacker objective: The attacker aims to turn a latent software weakness into practical access, persistence, or data exposure before the organisation can detect and fix it.
- Entry occurs when attackers exploit vulnerable code, exposed dependencies, or AI-assisted defects before the organisation has a chance to remediate them.
- Escalation follows when the weakness is reachable through a dependency chain, pipeline permission, or service credential that expands access beyond the original flaw.
- Impact occurs when the flaw is weaponised into data exposure, service disruption, or downstream compromise across applications that share the same component or identity trust.
NHI Mgmt Group analysis
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.
AI-generated code creates an assurance gap that security teams cannot treat as a developer productivity issue. The central question is not whether AI can write code, but whether organisations can prove that the code is safe to ship. That proof requires policy, validation, and traceability around AI-assisted changes, especially where generated code interacts with secrets, APIs, or privileged services. The practitioner conclusion is to govern AI output as a controlled software input, not an unreviewed shortcut.
Software supply chain visibility is becoming a trust boundary for identity governance. When dependencies, containers, and build systems are part of the application attack surface, identity controls extend beyond users into pipeline identities and machine credentials. This is where application security and NHI governance converge most clearly. The practitioner conclusion is to treat identities used in software delivery as part of the assessment surface, not just the authentication layer.
Demonstrable Software Trust is the new outcome boards will expect. The market is moving from asking whether teams scanned code to whether they can prove risk was identified, prioritised, and remediated fast enough to matter. That changes the reporting burden for security leaders because evidence must now be operational, not anecdotal. The practitioner conclusion is to build board-ready metrics around exposure window, remediation latency, and trust evidence rather than raw finding counts.
What this signals
Exposure window discipline: application risk teams will be judged less on how many findings they detect and more on how quickly they can reduce the time a vulnerability or secret remains exploitable. That is a governance shift, not just a tooling update, and it lines up closely with the lifecycle controls described in the NHI Lifecycle Management Guide.
As AI-assisted development scales, identity and secrets controls will become part of software quality assurance rather than a separate security track. Teams that cannot trace which pipeline identity, service account, or token touched a release will struggle to defend their assurance story to auditors and boards.
The practical signal is that boards will expect evidence, not scanning volume. Security leaders should prepare reporting that links exposure duration, remediation speed, and pipeline trust to business risk, using the NIST Cybersecurity Framework 2.0 as a governance language for the wider programme.
For practitioners
- 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.
- Translate findings into board-level risk evidence Report remediation latency, exposure window, and business impact in a format that shows whether the organisation can prove software trust rather than simply count vulnerabilities.
Key takeaways
- Application risk assessments are no longer reliable when they happen only on a schedule, because software, dependencies, and AI-assisted code change too quickly.
- The real governance problem is proving software trust across the delivery chain, including the identities and secrets that move code into production.
- Security leaders should shift from counting findings to demonstrating exposure reduction, remediation speed, and controlled AI-assisted change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | The article is about governing application risk continuously across the software lifecycle. |
| NIST SP 800-53 Rev 5 | RA-5 | Continuous vulnerability monitoring is central to the assessment model described here. |
| CIS Controls v8 | CIS-16 , Application Software Security | Application security controls map directly to the article's secure development and assessment themes. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0009 , Collection; TA0010 , Exfiltration | The article's risk framing includes dependency abuse, secrets exposure, and downstream compromise. |
Map exposed secrets and compromised build paths to attack tactics that drive detection and containment priorities.
Key terms
- Continuous application risk assessment: A model for evaluating software risk as a live control rather than a scheduled event. It integrates scanning and validation into development, build, and release workflows so findings are generated close to the moment risk is introduced, improving relevance and remediation speed.
- Software Trust: Software trust is the ability to prove that code was produced, approved, deployed, and maintained under controlled conditions. It goes beyond finding defects to include provenance, verification, remediation, and evidence that the running software matches the trusted state.
- AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
- Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
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.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern security programmes. It helps practitioners connect identity controls to broader operational risk and governance evidence.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
