Notifications
Clear all
Topic starter
21/08/2026 4:47 pm
TL;DR: Secure software development has to address intake, build, and runtime together, Rapidsort argues, citing 85% open-source software adoption, 10 hours from disclosure to active exploit, and more than 235,000 known-fix CVEs identified from 2016 to 2025. The governance lesson is that vulnerability reduction, SBOM discipline, and runtime visibility now need to be treated as a continuous control system, not a late-stage patching exercise.
NHIMG editorial — based on content published by Rapidsort: Secure Software Development Lifecycle and the RapidFort approach to eliminating vulnerabilities at every stage of the SDLC
By the numbers:
- 85% of enterprise software is open source
- 10 hrs from vulnerability disclosure to active exploit
Questions worth separating out
Q: How should security teams reduce vulnerability exposure in containerised SDLC pipelines?
A: Teams should reduce exposure before workloads reach production by standardising on hardened base images, pruning unused components, and tying vulnerability prioritisation to exploitability.
Q: Why do build-time vulnerability scans often create more noise than risk reduction?
A: Build-time scans often over-report because they list every known CVE in an artifact, whether or not the component is loaded, reachable, or exploitable in the target workload.
Q: What breaks when runtime profiling is missing from software supply chain governance?
A: Without runtime profiling, teams cannot tell whether a vulnerability exists only in the image inventory or in an active production component.
Practitioner guidance
- Reduce inherited exposure at intake Standardise on curated base images for approved workloads and require evidence that high-risk packages are removed before build promotion.
- Use exploit-aware CVE triage Rank findings by whether the vulnerable component is actually reachable, loaded, or executed in the target workload.
- Govern CI/CD machine identities Inventory the service accounts, tokens, and API keys used by build, scan, and deployment systems, then apply least privilege and rotation controls.
What's in the full article
Rapidsort's full white paper covers the operational detail this post intentionally leaves for the source:
- The curated image library approach and how it is organised across Ubuntu, Debian, Red Hat, and Alpine variants.
- The Rapid Risk Score method used to decide which CVEs are actually applicable in build contexts.
- How runtime profiling produces RBOM evidence for audit and compliance workflows.
- How the platform integrates with existing CI/CD pipelines without changing application code.
👉 Read Rapidsort's white paper on secure SDLC hardening and runtime visibility →
Secure SDLC hardening: what do build and runtime controls change?
Explore further
21/08/2026 5:06 pm
Shift-left security is incomplete unless it reaches runtime. Build-time hardening can reduce the number of exposed components, but it cannot tell teams what is actually live in production. Continuous profiling and runtime visibility are therefore the governance layer that separates assumed risk from executable risk. For identity programmes, that distinction mirrors the difference between issued credentials and actively used credentials. Practitioner conclusion: secure SDLC controls must extend past build artifacts into runtime evidence.
A question worth separating out:
Q: How do software supply chain controls intersect with machine identity risk?
A: They intersect wherever CI/CD tools, registries, scanners, and deployment systems authenticate with service accounts, tokens, or API keys. If those machine identities are over-privileged or poorly rotated, attackers can manipulate the pipeline that creates trusted software. Governance must cover both the artifact and the identities that move it.
👉 Read our full editorial: Secure SDLC hardening shifts left, build and runtime still matter
