Secure development lifecycle controls are failing at the commit stage

At a glance

What this is: Arnica argues that secure development lifecycle controls fail when they are concentrated at release time instead of enforced at commit, design and pipeline stages.

Why it matters: For IAM, NHI and broader security practitioners, the article matters because secrets, dependency risk and developer behaviour are governance problems that only become controllable when security is embedded into the development workflow.

By the numbers:

• The average breach now costs $4.88 million, according to IBM 2024 Data Breach Report cited by Arnica.

Context

A secure development lifecycle is a governance model for software delivery, not a late-stage testing activity. The control failure described here is simple: when security checks are pushed to the end of the release cycle, teams discover problems after code, secrets and dependencies have already spread through the build.

This matters for identity and access as much as for application security. Commit-stage controls determine whether hardcoded credentials, token misuse and over-permissive development workflows are blocked before they become persistent access paths in production. A mature SDL treats developer behaviour, pipeline gates and post-release monitoring as one control surface, not separate tasks.

The article’s starting position is typical for many teams: they have tools, but not a governed lifecycle. That gap is common, especially in AI-assisted development where code volume rises faster than manual review capacity.

Key questions

Q: What breaks when secure development controls are only applied at release time?

A: Release-only security misses the point where insecure code, secrets and vulnerable dependencies first enter the system. By the time a final test or pen test finds them, they are harder to fix, costlier to remediate and more likely to have reached shared branches or deployed environments.

Q: Why do commit-stage security gates reduce software supply chain risk?

A: They stop unsafe code, secrets and third-party components before they become part of the build artefact. That matters because the earlier a defect is blocked, the smaller the blast radius and the lower the chance that downstream systems inherit the problem.

Q: What do teams get wrong about secrets scanning at scale?

A: They treat scanning as the control instead of one input to lifecycle governance. At scale, the harder problems are ownership, rotation, revocation, and central inventory. A tool that finds secrets but cannot support remediation prioritisation still leaves governance gaps unresolved.

Q: Should organisations use OWASP SAMM or framework checklists to manage SDL maturity?

A: Use a maturity model when you need to measure whether security practices are actually embedded across the lifecycle. Checklists tell you what to do, but a maturity model shows where governance, design, implementation, verification and operations are still weak.

Technical breakdown

Why commit-stage controls are the real enforcement point

The commit stage is where code, dependencies and secrets first become part of a shared control path. Static analysis, secrets scanning and dependency checks are most effective here because they can stop insecure material before it is merged, built and propagated into multiple environments. Once code moves past commit, each downstream step adds cost and blast radius. In an SDL, this is the point where policy becomes executable rather than advisory.

Practical implication: fail builds and pull requests on unresolved critical findings instead of waiting for release approval.

How threat modeling and secure coding connect to pipeline gates

Threat modeling belongs upstream because it shapes what the pipeline should be looking for. If design does not define trust boundaries, data flows and abuse cases, later SAST or DAST results become isolated findings rather than evidence of a controlled development process. Secure coding standards translate that design intent into implementation checks, while SAST and code review verify whether the code actually follows them. The lifecycle only works when each phase hands context to the next.

Practical implication: tie design-time threat models to specific commit-time checks so findings map back to a known risk assumption.

Why secrets and dependency controls need lifecycle governance

Secrets scanning and software composition analysis are not point tools. They are lifecycle controls because hardcoded credentials and vulnerable libraries often enter during normal developer activity and persist until someone actively blocks them. In AI-assisted environments, that persistence risk increases because generated code can copy unsafe patterns at speed. A governed SDL treats secret leakage, dependency integrity and post-release monitoring as continuous obligations, not one-off checks at release.

Practical implication: treat secret leakage and vulnerable dependencies as control failures that require automatic enforcement, not manual follow-up.

Threat narrative

Attacker objective: Exploit development-introduced weaknesses before they are caught, then gain durable access or extract value from shipped code and secrets.

1. Entry occurs when developers introduce hardcoded credentials, insecure code patterns or vulnerable dependencies during ordinary implementation work.
2. Escalation happens when those weaknesses bypass late-stage review and move into shared branches, build artifacts and deployed environments.
3. Impact is delayed detection, higher remediation cost and wider exposure when an attacker or auditor finds issues after release.

Breaches seen in the wild

• Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Commit-stage enforcement is the point where secure development either becomes real or remains aspirational. A lifecycle that relies on end-of-release review is structurally out of date in fast-moving and AI-assisted development. The decisive question is whether security findings can stop code before merge, not whether they can be documented after the fact. Practitioners should treat commit-stage gating as the primary control boundary.

Secret leakage in development is an identity control failure, not just a coding issue. Hardcoded credentials, tokens and API keys create standing access that can outlive the code change that introduced them. That makes SDL governance directly relevant to NHI security, because machine credentials become durable attack paths when commit controls do not block them early. Practitioners should govern secrets as lifecycle-bound identities, not as incidental text strings.

Measurement matters because maturity is visible in remediation speed, not policy language. The article’s emphasis on mean time to remediate and enforcement thresholds is the right lens. Programs that cannot show faster closure of findings, fewer escaped defects and higher gate failure rates at commit are not really operating an SDL. Practitioners should benchmark the control as a measurable operating model, not as a documentation exercise.

OWASP SAMM is the right kind of yardstick for this problem because it measures practice maturity, not tool count. Too many teams confuse scanners with governance. A scored maturity model exposes whether security is embedded across governance, design, implementation, verification and operations. Practitioners should use maturity scoring to identify where commit-stage controls are missing the broader lifecycle.

Agentic development increases the need for automated lifecycle controls rather than reducing it. As code volume rises, human review becomes a bottleneck, and the control point shifts even earlier into policy-enforced commit checks. That is especially relevant where AI-assisted coding can amplify secrets exposure, dependency risk and insecure reuse. Practitioners should plan for stronger automation, not looser review discipline.

From our research library:

• Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and insufficient risk controls.
• Read next: Agentic AI Identity Maturity Model

What this signals

Commit-time controls are now the practical boundary for development security. Security teams can no longer rely on a late testing phase to catch defects that were introduced days or weeks earlier. The operational question is whether your pipeline can reject insecure code before it becomes a shared dependency, build artifact or production release.

Secrets management is an identity problem inside the software delivery process. Hardcoded credentials and tokens create standing access that can outlive the code path that introduced them, which is why commit-stage blocking matters. For programmes that also manage NHIs, this is a reminder that machine credential governance begins in the developer workflow, not only in the vault.

Control maturity should be judged by remediation velocity, not scanner count. If mean time to remediate does not improve, the SDL is probably producing findings without changing behaviour. That is where programmes should shift from tool inventory to enforceable thresholds and governance metrics.

For practitioners

• Enforce commit-stage security gates Block merges when critical SAST findings, hardcoded credentials or high-severity dependency issues remain unresolved.
• Bind threat models to pipeline checks Map design-phase trust boundaries and misuse cases to the specific static and dependency rules your CI/CD system must enforce.
• Treat secrets as release-stopping defects Require immediate remediation or formal exception handling when secrets scanners detect credentials in code, branches or build output.
• Measure SDL maturity by remediation speed Track mean time to remediate, gate failure rates and escaped defects to show whether the lifecycle is reducing risk or just adding process.
• Baseline against a maturity model Use OWASP SAMM to identify one practice area that can be improved over the next 90 days, then verify change with operational metrics.

Key takeaways

• A secure development lifecycle fails when it is treated as a release checkpoint instead of a continuous control model.
• Development-introduced vulnerabilities still carry material financial impact, with IBM cited by Arnica placing average breach cost at $4.88 million.
• Commit-stage enforcement, secrets blocking and measurable remediation targets are the controls that separate paper SDL from operating SDL.

Key terms

• Secure Software Development Lifecycle: A secure software development lifecycle is the practice of building security into every phase of software work, from planning through operations. It aligns requirements, design, testing, deployment, and maintenance so vulnerabilities are prevented earlier and remediated faster, rather than discovered only after release.
• Commit-stage Security Gate: A commit-stage security gate is an automated control that can block code from merging or progressing when defined security conditions are not met. It turns policy into enforcement by stopping insecure code, secrets or vulnerable dependencies before they become part of shared build artefacts.
• Software Assurance Maturity Model: The Software Assurance Maturity Model is a maturity framework for software security practices. It gives organisations a way to evaluate how well security is embedded across the development lifecycle, then improve step by step. Its value is in turning broad security goals into practical, measurable actions that can be tracked over time.
• Secret Scanner: A secret scanner is a detection tool that searches code, commits, and related assets for exposed credentials or sensitive patterns. It helps teams find leaks before attackers do, but detection alone does not confirm whether a secret is active, externally reachable, or already exploited. That limitation makes remediation and revocation essential.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners connect lifecycle controls to the access paths that code can create.