Secure SDLC hardening shifts left, build and runtime still matter

At a glance

What this is: Rapidsort argues that secure SDLC hardening only works when intake, build, and runtime are treated as one continuous control plane, not separate security gates.

Why it matters: IAM, NHI, and software security teams should care because container images, SBOMs, and runtime profiling shape what actually executes, what can be exploited, and what evidence survives audit.

By the numbers:

• 85% of enterprise software is open source.
• It can take 10 hours from vulnerability disclosure to active exploit.

Context

Secure SDLC hardening is the discipline of reducing vulnerability exposure before code reaches production and then confirming that the running workload still matches what was analysed. The governance gap is that many programmes optimise for release speed, while attackers exploit the time between disclosure, build, and runtime drift.

For identity and platform teams, that gap matters because software supply chain controls increasingly govern who and what gets to run, not just who gets to sign in. When container images, build pipelines, and production workloads are all part of the trust boundary, security and compliance need lifecycle evidence rather than a one-time scan.

Key questions

Q: What breaks when secure SDLC hardening stops at the build stage?

A: The main failure is that teams mistake a hardened artifact for a hardened service. Build-stage controls can remove obvious vulnerabilities, but runtime drift, unused package activation, and environment-specific exposure still create paths to compromise. A secure SDLC only works when the running workload is checked against the build intent and remediated continuously.

Q: Why do open source dependency risks keep overwhelming application security teams even when they scan regularly?

A: Regular scanning only sees what is already in the artifact. It does not control how dependencies were selected, where they came from, or whether they were remediated before build time. When malicious packages move quickly and AI coding agents add dependencies faster than review can keep up, backlog grows because the control point is too late in the chain.

Q: How do security teams know if runtime protection is actually working?

A: Look for evidence that suspicious behaviour is detected fast enough to contain it before the session or workload expands the blast radius. Effective runtime protection produces actionable alerts, ties them to containment steps, and shows that abnormal access can be limited during active execution, not only reviewed afterward.

Q: When should organisations prioritise build hardening over later remediation?

A: They should prioritise it as soon as the same component or image is reused across multiple applications or environments. Early hardening prevents the same vulnerable artefact from propagating downstream, which is far cheaper than fixing the issue after release. The right sequence is to reduce inherited risk before it becomes repeat exposure.

Technical breakdown

Curated container images reduce starting attack surface

A curated base image is a pre-hardened operating system or runtime image that removes unnecessary packages and known vulnerable components before developers build on top of it. In SDLC terms, this shifts risk reduction left by shrinking the number of exploitable libraries and services that enter the pipeline in the first place. The practical value is not just fewer findings, but fewer findings that are already baked into every downstream build. That matters because traditional image scanning often discovers problems after the image has been reused across multiple services, environments, and releases.

Practical implication: standardise approved base images and treat image provenance as a control point, not a convenience choice.

SBOMs and exploit-aware prioritisation change build-stage decisions

A software bill of materials lists the components inside a build, but the control value comes from pairing it with applicability analysis. Not every CVE in a dependency or package is exploitable in a given application, so build-stage governance needs to distinguish theoretical exposure from risk that can actually be reached. An exploit-aware score helps teams focus remediation on components that matter in the current configuration, while build hardening removes unused packages that expand the attack surface without adding business value. That reduces noise and makes CI/CD more governable.

Practical implication: require SBOM generation in CI/CD and rank findings by exploitability, not by raw vulnerability count.

Runtime bill of materials closes the gap between installed and executed code

Runtime control is different from build control because software often ships with components that never execute in production, while other libraries or processes become active only under real workloads. A runtime bill of materials shows what actually runs, which is essential for separating theoretical exposure from live risk. This matters for compliance evidence as well, because audit-ready posture depends on the running environment, not just a build artifact. Continuous profiling also helps teams detect configuration drift and understand whether deployed services still match the security assumptions made during release.

Practical implication: compare build output to runtime execution regularly so compensating controls reflect the environment that is really live.

Threat narrative

Attacker objective: The attacker aims to exploit exposed software components in deployed workloads before teams can remove or validate them.

1. Entry begins with vulnerable open-source components and container images entering the software supply chain before release.
2. Escalation occurs when unused packages, excessive dependencies, or unverified build content expand the number of exploitable paths available to attackers.
3. Impact appears when production workloads run with a larger attack surface than developers or auditors assume, increasing the chance of compromise and audit failure.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

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

Secure SDLC hardening has become a governance problem, not just a build problem. The article shows that risk now spans intake, build, and runtime, which means the control objective is lifecycle integrity rather than point-in-time scanning. That is a familiar pattern in identity security: if the trusted state is only checked once, drift becomes the real attack surface. Practitioners should treat software supply chain evidence as continuously governed state.

Runtime visibility is the missing layer in many security programmes. Build security can reduce the number of vulnerable components, but production reality decides which components actually matter. That creates a gap between inventory and execution, similar to the gap between assigned access and effective access in identity governance. The named concept here is execution-state mismatch: what is built, what is installed, and what actually runs are not the same control problem. Practitioners should align detection and compliance to runtime behaviour, not just artifact metadata.

Attack surface management is now inseparable from compliance readiness. The article ties CIS and STIG benchmarking to hardened images and runtime evidence, which signals that assurance is moving closer to operational controls. For teams running regulated environments, this means auditability depends on how quickly the organisation can prove what was hardened, what was deployed, and what actually executed. Practitioners should design compliance evidence to come from the same pipeline that reduces risk.

SBOM discipline only matters when it drives action. A software bill of materials is useful, but the article makes clear that applicability analysis and continuous hardening are what convert inventory into control. That distinction matters across identity and platform security because lists do not reduce exposure unless they change prioritisation or configuration. Practitioners should use component inventory to drive remediation, not reporting for its own sake.

Continuous hardening reflects where software security is heading. Static hardening at build time is not enough when vulnerabilities continue to surface after deployment and when workloads change over time. The broader market signal is that security teams need controls that follow the software lifecycle end to end. Practitioners should expect governance models to move from periodic review toward continuous verification of software state.

What this signals

Execution-state mismatch: the real governance gap in secure SDLC programmes is the distance between the image that was approved and the workload that actually runs. Once that gap exists, vulnerability reduction becomes partly theoretical because the organisation is no longer controlling the same state it audited.

For identity and platform teams, the practical shift is toward continuous proof rather than periodic reassurance. Build artefacts, runtime profiles, and compliance evidence need to line up, or the programme cannot credibly claim that risk has been reduced across the lifecycle.

For practitioners

• Adopt approved hardened base images Standardise on curated container images that remove unnecessary packages and known vulnerable components before new services are built.
• Generate SBOMs in the CI/CD pipeline Require build-stage software bills of materials so component inventory, applicability analysis, and remediation priorities are available before release.
• Prioritise exploitable findings over raw CVE volume Use exploit-aware scoring to separate theoretically present vulnerabilities from issues that are reachable in the current build context.
• Compare runtime execution to build inventory Profile production workloads so teams can see what actually executes and reconcile that with the hardened image and SBOM evidence.
• Make compliance evidence continuous Tie runtime profiling and build hardening into the same reporting chain so audit-ready evidence is produced from the live environment.

Key takeaways

• Secure SDLC hardening only works when teams govern the full path from intake to runtime, not just the release gate.
• Runtime profiling matters because the executable state in production can differ materially from the image or SBOM reviewed at build time.
• Lifecycle controls that combine hardened images, exploit-aware prioritisation, and runtime evidence reduce both attack surface and audit friction.

Key terms

• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
• Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.
• Attack Surface Reduction: Attack surface reduction is the practice of removing or constraining the externally reachable paths an attacker can use to find, authenticate to, or exploit a system. In operational terms, it means shrinking public exposure, closing unused interfaces, and limiting what reachable services can do if compromised.
• Exploit-Weighted Prioritisation: Exploit-weighted prioritisation is the practice of ranking remediation work by whether a vulnerability is actively exploited, not just by technical severity. It combines external threat signals, fix availability, and asset exposure so teams can reduce real attacker opportunity first.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management in a format designed for security and identity practitioners. It helps teams connect identity controls to the broader assurance and governance decisions their programmes depend on.