AppSec is evolving, not dying, in the age of coding agents

At a glance

What this is: This is an independent analysis of why AI-assisted code security improves finding and fixing, but does not eliminate the broader AppSec and DevSecOps control stack.

Why it matters: It matters to IAM, PAM, and security teams because the article makes a clear identity-adjacent point: access, pipeline trust, developer accounts, and machine-generated changes still need governance beyond code scanning.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Boost Security's analysis of why AppSec is evolving in the age of coding agents

Context

AppSec is no longer just about finding flaws in first-party code. Modern software risk spans developer identities, CI/CD trust, third-party dependencies, cloud runtime, and the controls that govern how changes move from code to production. AI tools can improve discovery and remediation, but they do not remove the need for governance across the software factory, especially where access and machine-generated actions intersect with IAM and PAM.

Boost Security's article uses Claude Code Security as a trigger for a broader argument: better code-level analysis does not replace inventory, prioritisation, policy enforcement, or incident response. That is a familiar pattern in security programmes. New tooling often improves one control plane while exposing the gaps around it, and this case is typical of enterprise software security maturity rather than an exception.

Key questions

Q: What breaks when AI security is limited to AppSec scanning?

A: Static scanning misses emergent behaviour, so the organisation can approve code that later behaves outside policy in production. The failure is a mismatch between what was reviewed and what actually runs. Teams end up with technical assurance on the build, but no visibility into runtime drift, tool misuse, or overreach.

Q: Why do coding agents not replace shift-left security?

A: Because shift-left is only one point in the delivery lifecycle. Coding agents may help produce cleaner code, but new vulnerabilities, compromised packages, and broken build trust can still appear after development time. Security teams need continuous verification, not a one-time check at generation or commit.

Q: What do security teams get wrong about AI auto-fix in application security?

A: They often assume a convincing patch means the finding is real and the fix is safe. In practice, remediation is only trustworthy when it is grounded in a confirmed, reproducible vulnerability from the actual codebase. Otherwise developers inherit uncertainty, and security teams lose confidence in the control.

Q: How should teams govern service accounts and CI jobs in software delivery?

A: Treat them as privileged identities with lifecycle ownership, scope limits, and revocation rules. Use least privilege, short-lived credentials where possible, and separate build, test, and release permissions so one compromised automation path cannot reach every repository or environment.

Technical breakdown

Why AI-assisted code scanning still leaves control gaps

AI-assisted scanning uses large language model reasoning to identify patterns in source code, infer likely defects, and suggest fixes. That can outperform rule-based SAST on business logic flaws, broken authorisation paths, and context-sensitive mistakes. But the mechanism is still bounded by the code it sees at the moment it runs. It does not inherently model later dependency compromise, pipeline misconfiguration, endpoint abuse, or runtime drift. In other words, better detection at generation time does not equal continuous assurance across the full delivery chain.

Practical implication: treat AI code scanning as one detection layer, not the control boundary for software security.

Why software factory risk extends beyond first-party code

The article is right to separate first-party code from the rest of the software factory. Developer endpoints, source control, CI jobs, container images, infrastructure-as-code, and logical access surfaces each create different risk paths. A malicious pull request, compromised IDE extension, poisoned package, or insecure pipeline can all bypass code-only review. That is why software security has to include identity controls on developers and machines, plus policy enforcement around build and deployment systems, not just vulnerability discovery in application code.

Practical implication: map controls to the full delivery chain, including developer identity, pipeline trust, and machine-to-machine access.

Why runtime and incident response remain mandatory

AI can accelerate finding and fixing, but enterprises still need continuous monitoring because threats change after deployment. A library can become vulnerable overnight, a package can be compromised in the supply chain, and an environment can drift away from its original security posture. Runtime signals, dependency intelligence, and incident response workflows are what close that gap. This is especially important where access tokens, service accounts, and deployment credentials allow one compromised path to affect many systems.

Practical implication: combine AI-assisted review with runtime detection and access control over secrets, service accounts, and pipelines.

Threat narrative

Attacker objective: The attacker wants to turn a trusted software delivery path into a vehicle for code execution, data exposure, or broader supply chain compromise.

1. Entry occurs through a compromised developer path, such as a malicious pull request, poisoned dependency, or misconfigured pipeline that accepts untrusted change.
2. Escalation happens when build or deploy trust is abused, allowing attacker-controlled code or configuration to move from development into production workflows.
3. Impact follows when the compromised software path enables data exposure, unauthorized execution, or supply chain propagation across downstream systems.

NHI Mgmt Group analysis

AppSec is becoming a control-plane problem, not just a code-quality problem. The article correctly rejects the idea that code scanning alone defines software security. In practice, the boundary now includes developer identities, CI/CD permissions, secret handling, runtime signals, and dependency integrity. That makes the security model closer to governance of a distributed execution environment than classic application testing. Practitioners should plan for software security as an identity and control-plane discipline as much as a code discipline.

AI-assisted remediation changes the economics of discovery, but not the governance model. The article's strongest point is that faster finding and fixing does not eliminate the need to decide what is in scope, what is exposed, and what must be prioritised. This is where inventory and policy matter more than raw detection volume. The decisive issue is not whether AI can find a bug, but whether the organisation can govern thousands of repositories, agents, pipelines, and credentials consistently. Practitioners should treat AI as an accelerator for control execution, not a substitute for control design.

Developer identity and machine identity are now part of AppSec scope. Once coding agents, CI jobs, and deployment automation are making or moving changes, access governance becomes inseparable from software security. Standing privileges, over-broad service accounts, and weak pipeline segregation create the conditions for fast propagation of bad change. The article points toward a named concept we see increasingly in the field: software factory trust sprawl, where too many identities, tools, and automation paths can alter production with insufficient oversight. Practitioners should inventory and govern every identity that can change code or ship artifacts.

Traditional shift-left still matters, but only when paired with runtime visibility. The article is right that not every threat exists at commit time. New CVEs, compromised packages, and environment-specific exposures appear after code is written. That means the mature model is shift-left plus continuous verification, not one or the other. For identity and access teams, the important lesson is that secrets, tokens, and service accounts used in software delivery need lifecycle controls that survive beyond the build stage. Practitioners should align AppSec with PAM and identity governance, not leave them in separate silos.

What this signals

Software factory trust sprawl: as AI-assisted development spreads, the number of identities and automated paths that can influence production grows faster than most governance models. That means the practical control problem is no longer only vulnerability detection, but permissioning, segmentation, and lifecycle control for every human and machine actor that can ship code or change infrastructure.

The next maturity jump is to connect AppSec telemetry with identity governance and PAM. If a CI job, service account, or developer token can alter build output, then offboarding, rotation, and privilege review become software security controls, not just IAM hygiene. Practitioners should expect tighter coupling between pipeline security, secrets management, and access governance.

AI will keep improving at code reasoning, but security programmes will still fail if they cannot answer a more basic question: which identity changed what, where, and under whose policy. That question now defines how enterprises operationalise secure software at scale.

For practitioners

• Inventory the full software factory Map developers, IDE extensions, CI jobs, repositories, container images, ML models, and deployment identities before choosing where AI scanning fits. Use the inventory to decide which paths can alter production, which ones handle sensitive data, and which ones require stronger identity controls.
• Separate code findings from delivery-path findings Classify vulnerabilities that live in first-party code differently from risks in pipelines, packages, and developer endpoints. That separation improves prioritisation and stops AI-assisted code review from obscuring non-code attack paths.
• Tighten access around build and release identities Apply least privilege to CI jobs, service accounts, and release automation so a single compromised token cannot move freely across repositories or environments. Pair that with short-lived credentials and offboarding controls for automation accounts.
• Use runtime signals to validate post-commit risk Track whether a vulnerability is actually exploitable in the running environment, not just whether it exists in code. Feed dependency intelligence, runtime telemetry, and incident response into the same workflow so newly disclosed CVEs and compromised packages can be triaged fast.

Key takeaways

• AppSec is not dying, but its control surface is widening beyond code into identities, pipelines, and runtime governance.
• AI improves discovery and remediation, yet the decisive risk remains whether enterprises can govern software delivery end to end.
• Teams that align AppSec with IAM, PAM, and lifecycle controls will handle coding agents without losing control of production change.

Key terms

• Software Factory Trust Sprawl: The accumulation of too many trusted identities, tools, and automation paths that can influence code, builds, and releases. It describes a governance problem where control ownership becomes diffuse, making it hard to know which account, job, or system actually changed production.
• Code-Time Security Scanning: Security analysis performed while code is being written or generated, rather than after deployment. It can improve early defect detection, but it only covers the code under inspection and not the wider delivery chain, runtime environment, or identity and access paths around it.
• Build Pipeline Trust Boundary: A build pipeline trust boundary is the point where code, credentials, and automation meet during software delivery. It is a control boundary because compromise there can spread from package installs into release systems, repositories, and cloud environments if secrets are present and privileges are broad.
• Runtime assurance: Runtime assurance is the practice of validating how an application actually behaves after deployment. It matters because configuration, identity flow, and integration state can change security outcomes in ways that source code analysis alone cannot prove.

What's in the full article

Boost Security's full blog post covers the operational detail this post intentionally leaves for the source:

• How Claude Code Security handles security triage, severity prioritisation, and fix generation at code level
• The specific scenarios Boost Security uses to explain why code-time scanning misses dependency, pipeline, and runtime risk
• The enterprise operational requirements the article says still matter, including inventory, compliance, and incident response
• The article's own framing of how AI should fit alongside AppSec, DevSecOps, and software factory controls

👉 Boost Security's full post covers the code-time scenarios, pipeline risks, and enterprise controls discussed in the argument.

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. It helps security practitioners connect identity controls to the broader delivery and runtime risks that modern software programmes face.