TL;DR: Application security programmes still struggle with fragmented visibility, secrets exposure, and policy enforcement across the SDLC, according to LEGIT Security’s analysis of software risk management. The practical issue is not just finding issues faster, but governing code, pipelines, and runtime with enough context to reduce blast radius before weaknesses become incidents.
At a glance
What this is: This is a commentary on SDLC security that argues visibility, policy enforcement, secrets management, and vulnerability prioritisation must be tied together.
Why it matters: It matters to IAM and NHI practitioners because software pipelines, service credentials, and runtime access decisions increasingly intersect, making identity-aware governance essential across application delivery.
👉 Read LEGIT Security's blog on SDLC visibility, secrets management, and AppSec prioritisation
Context
Software development security fails when teams treat code, pipelines, secrets, and runtime as separate control planes. A useful SDLC view has to connect those layers, because exposed credentials, weak policy enforcement, and poor asset inventory all expand the same operational blast radius. The identity angle is real here: secrets, service accounts, and pipeline access are non-human identities that need lifecycle governance, not just point-in-time scanning.
The article frames Legit Security as a visibility and prioritisation layer for application security, but the underlying governance problem is broader than any one product. Enterprises need to know where software assets live, which credentials and dependencies they use, and how policy decisions follow the application from build to deployment. That is typical of modern AppSec programmes, especially where DevSecOps and identity governance have not yet been fully joined up.
Key questions
Q: How should teams govern secrets in infrastructure as code pipelines?
A: Teams should keep secrets out of code and move them into a dedicated runtime secrets service, then enforce policy that prevents repository storage and console exposure. The goal is to make credential lifecycle controls independent from the IaC repository, so revocation, rotation, and access review can happen without editing infrastructure templates.
Q: Why do SDLC visibility gaps increase application security risk?
A: Because teams cannot protect what they cannot connect. If code, pipelines, dependencies, and runtime assets are not mapped together, security teams miss how a compromise in one layer affects another. Visibility gaps also hide ownership, which slows response and lets risky access persist longer than it should.
Q: What breaks when asset context is missing from vulnerability prioritisation?
A: Teams often fix the loudest findings instead of the riskiest ones. Without ownership, reachability, and identity dependency data, it is hard to tell whether a vulnerability sits on a low-value internal system or on an internet-facing service with privileged back-end access.
Q: How do organisations decide which secrets incidents need immediate action?
A: Prioritise secrets that are still valid, linked to privileged access, or embedded in high-reach systems such as CI/CD, code signing, and vendor integrations. A credential with broad trust and no current owner should be treated as urgent even if the leak appears small. The key is to measure exploitability, not just volume.
Technical breakdown
How SDLC visibility works across code, pipelines, and runtime
SDLC visibility means tracing an application from source code through build systems, CI/CD pipelines, dependencies, and deployment environments so security teams can see where risk enters and where it lands. The technical challenge is that each stage produces different artefacts, owners, and trust assumptions. Without a linked inventory, teams detect issues in isolation and miss how one exposed dependency or misconfigured pipeline credential affects downstream runtime exposure. This is where application context matters, because ownership, business criticality, and deployment path determine real risk.
Practical implication: map application journey, ownership, and runtime dependencies into one inventory before trying to prioritise fixes.
Why secrets management in pipelines is really NHI governance
Secrets in AppSec are credentials, tokens, API keys, and certificates used by services, tools, and deployment workflows. Once a secret is embedded in code, logs, or build artefacts, it becomes a non-human identity control problem because the credential can be reused outside its intended lifecycle. Scanning is only the first step. Real governance requires blocking new secret introduction, detecting leaked credentials quickly, and rotating or revoking them based on exposure context rather than waiting for an annual review.
Practical implication: treat leaked secrets as NHI lifecycle failures and enforce rotation, revocation, and prevention controls together.
How contextual vulnerability prioritisation reduces noise
Contextual prioritisation links a vulnerability to the application’s criticality, deployment path, owner, and runtime blast radius. That matters because a medium-severity issue in a sensitive production service may create more exposure than a high-severity issue in a low-impact test system. AppSec tools that ingest asset context can help teams sort what is urgent from what is merely visible. The architectural point is that vulnerability management becomes far more useful when it is joined to identity and access context, especially for pipelines and service accounts that move software into production.
Practical implication: score vulnerabilities by application criticality and runtime exposure, not by severity alone.
NHI Mgmt Group analysis
SDLC visibility is now an identity governance problem, not just an AppSec problem. When build systems, pipelines, and runtime services all carry credentials and permissions, the boundary between application security and NHI governance disappears. The operational question becomes whether teams can continuously account for service credentials, deployment access, and application ownership across the lifecycle. Practitioners should therefore treat pipeline identity as part of the same governance model as human and machine access.
Secrets management fails when organisations stop at detection and ignore lifecycle control. Finding leaked credentials is useful, but exposure only becomes manageable when rotation, revocation, and prevention are tied to the application context that created the secret. The article reflects a common industry pattern: teams collect tooling, but do not unify the response path. Practitioners need lifecycle controls that follow the secret from creation to disposal.
Contextual prioritisation is the right answer to AppSec noise, but only when ownership data is reliable. Risk scoring by criticality, runtime blast radius, and application context can improve decision-making, yet it collapses if asset inventory is stale or ownership is unclear. This is where governance debt accumulates, because every unowned service account or pipeline credential weakens triage. Practitioners should make ownership data a security control, not an admin field.
Software supply chain security and identity security are converging around one concept: runtime trust. Policies, attestations, SBOMs, and pipeline controls matter because they define what can move into production and under what conditions. That is increasingly inseparable from who or what is allowed to sign, deploy, and call services. NHI programmes should align with supply chain controls so credentials, attestations, and deployment rights are governed together.
What this signals
SDLC governance is moving toward a single control question: can you prove which identities, secrets, and deployment rights exist at each stage of software delivery? That is why application security teams and identity teams will keep converging around shared inventories, scoped access, and lifecycle evidence.
Runtime trust: the next maturity step is not more scanning, but better linkage between attestation, pipeline identity, and production access. Teams that cannot connect those three layers will keep generating findings without reducing exposure.
Practitioners who already operate NHI Lifecycle Management Guide processes can extend the same discipline to software delivery paths, especially where service credentials and automation tokens behave like persistent identities.
For practitioners
- Map software assets to owners and runtime dependencies Create a continuously updated SDLC inventory that links code, pipelines, deployments, and service ownership. Use it to identify which components carry secrets, which systems can deploy changes, and where access decisions depend on non-human identities.
- Enforce secret prevention before code reaches shared workflows Block new secrets from entering repositories, build logs, and pipeline artefacts, then route any detection into automated revocation and rotation. This reduces the window between exposure and abuse.
- Prioritise vulnerabilities by business context and blast radius Tie vulnerability scoring to application criticality, deployment path, and runtime exposure so teams fix issues that can actually affect production. That keeps remediation aligned with real operational risk.
- Treat pipeline credentials as governed non-human identities Apply lifecycle controls to service accounts, tokens, and certificates used in CI/CD, including issuance, scoped use, periodic review, and offboarding. This is the control model that stops build-time access from becoming persistent production access.
Key takeaways
- Application security improves when visibility, policy, secrets, and prioritisation are governed as one SDLC control system.
- Secrets in pipelines are identity risks as much as code risks, because exposed credentials behave like unmanaged non-human identities.
- The practical win comes from linking application context to ownership, access, and remediation, not from collecting more findings.
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 | PR.AC-1 | Identity and access control underpin software delivery and pipeline governance. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is central to controlling build and deployment access. |
| CIS Controls v8 | CIS-5 , Account Management | Account governance applies directly to CI/CD service identities and automation tokens. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0004 , Privilege Escalation | Exposed secrets and over-privileged automation are common attack paths in software delivery. |
Track exposed credentials and deployment privileges as attack surfaces that need rapid containment.
Key terms
- SDLC visibility: The ability to see how software moves from code to build, test, deploy, and runtime, with the related assets and owners connected. It matters because security teams cannot prioritise or contain risk well when application components, dependencies, and automation paths are treated as separate records.
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines — typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
- Contextual prioritisation: Contextual prioritisation ranks findings by exploitability, reachability, and business impact rather than by severity alone. This approach reduces alert fatigue and helps practitioners focus on the risks most likely to be used in a real attack path.
What's in the full article
LEGIT Security's full blog covers the operational detail this post intentionally leaves for the source:
- Specific product workflows for tracing software assets from source to runtime
- Policy and compliance feature examples for regulated SDLC environments
- Secrets scanning and mitigation workflow detail for pipeline use cases
- Vulnerability prioritisation features that link issues to owner and runtime blast radius
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle fundamentals. It is designed for practitioners who need to connect identity control with operational security programmes.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
