Topic starter
02/08/2026 11:35 am
TL;DR: Modern applications reuse large volumes of old open-source code, with nearly 90% of codebases containing code over four years old and 80% of application code originating from open source, according to OXSecurity. The implication is that security, access control, and pipeline governance must be built into development from design through maintenance, not deferred to testing.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “SDLC Security: Everything You Need to Know”.
By the numbers:
- Nearly 90% of codebases contain open-source code over four years old, according to OXSecurity.
- 80% of code in modern applications originates with open-source projects, according to OXSecurity.
- Command injection appears in 15.4% of applications, according to OXSecurity.
Key questions
Q: Where does secure SDLC fail when teams leave security to the testing stage?
A: It fails because vulnerabilities, unsafe dependencies, and weak access decisions have already propagated into code, builds, and release candidates.
Q: Why do open-source components and CI/CD pipelines increase software supply chain risk?
A: Open-source components and CI/CD pipelines expand the attack surface because they introduce third-party code, automation, and many trusted handoffs.
Q: How should security teams govern credentials used by CI/CD pipelines?
A: Security teams should treat CI/CD credentials as production-grade machine identities and apply least privilege, short lifetimes, and continuous monitoring.
Practitioner guidance
- Define security requirements before design starts Capture threat assumptions, access boundaries, and secure data flow expectations in the same requirements process used for functionality.
- Inventory and govern dependency age Track open-source and third-party component age, provenance, and patch status so stale libraries are visible before they reach release.
- Apply least privilege to pipeline identities Scope build, test, signing, and deployment credentials tightly, and assign clear owners for every automation identity used in CI/CD.
Bottom line: Secure SDLC treats software security as a lifecycle control problem, not a last-minute review step.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:49 pm
Secure SDLC is now a governance model, not just an engineering practice. Once code reuse, automated pipelines, and continuous delivery dominate software delivery, security cannot be an end-stage review function. The control point moves upstream into requirements, design, and identity-aware pipeline governance. Practitioners should treat software delivery as a governed risk surface, not a development preference.
A question worth separating out:
Q: What should organisations do when secure code findings keep reappearing?
A: They should move the decision point earlier and assign accountability for repeated defects. If the same weakness keeps returning, the problem is usually not one missed scan but a workflow that lets the same insecure pattern pass through design, development, or component selection. Fix the control gap, not just the individual issue.
👉 Read our full editorial: Secure SDLC shifts software risk left before code reaches production