Notifications
Clear all
Topic starter
18/08/2026 2:18 pm
TL;DR: Claude Code Security can find and triage vulnerabilities at scale, including issues missed by rule-based SAST, but Boost Security argues that this does not replace enterprise AppSec because software risk also lives in dependencies, pipelines, endpoints, and runtime controls. The real shift is toward combining AI with inventory, prioritisation, policy enforcement, and incident response across the full software factory.
NHIMG editorial — based on content published by Boost Security: The Death of AppSec Is Greatly Exaggerated
Questions worth separating out
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.
Q: Why do coding agents not replace shift-left security?
A: Because shift-left is only one point in the delivery lifecycle.
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.
Practitioner guidance
- 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.
- Separate code findings from delivery-path findings Classify vulnerabilities that live in first-party code differently from risks in pipelines, packages, and developer endpoints.
- 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.
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
👉 Read Boost Security's analysis of why AppSec is evolving in the age of coding agents →
AI code security is changing AppSec, but what should teams do now?
Explore further
18/08/2026 3:10 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AppSec is evolving, not dying, in the age of coding agents
