Modern software is largely assembled, not written from scratch. Developers pull libraries from package registries, layer on front-end frameworks, and wire everything together with relatively small amounts of custom code. The original source article (published on opensource.com) estimated that more than 90% of a typical application’s code comes from borrowed or open-source components rather than first-party authorship. Whether that figure is exact or not, the directional truth is undeniable: the attack surface of your application is dominated by code you did not write and may never have audited.
Static analysis tools help teams find defects in their own code, but they rarely cover the full dependency tree. This article explains three concrete steps—drawn from a DevSecOps framing—for closing that gap.
The Old Way: Late-Stage, Manual Security Reviews
For much of software engineering history, security assessment happened near the end of the development lifecycle—if it happened at all. Long waterfall or spiral-model release cycles meant that security reviews were scheduled events, usually triggered by an external audit or a customer contractual requirement rather than by engineering discipline.
Several factors compounded the problem:
- Infrequent reviews meant known defects aged in backlogs without remediation pressure.
- Feature priority consistently outranked security fixes that “normal users would never see.”
- Lack of defensive-coding education meant many engineers had no practical training in writing secure code.
- Tool gaps left teams without automated ways to catalogue or assess open-source dependencies.
Information-security teams focused on producing findings reports to satisfy auditors rather than on preventing defects at the source. The result was a security posture that was reactive, not preventive.
The New Way: DevSecOps
DevOps collapsed the wall between software development and infrastructure operations by automating delivery pipelines and enabling teams to iterate continuously. DevSecOps applies the same philosophy to security: instead of a gate near the end of the pipeline, security controls are embedded throughout the software development lifecycle (SDLC).
The central principle is often called shifting left—moving security testing and open-source composition analysis earlier in the process, ideally into the design and development phases rather than pre-production or production. Defects found earlier are cheaper and faster to fix, and they are far less likely to reach end users.
Just as DevOps gives developers the tools to define and version infrastructure, DevSecOps gives them tools to own and act on security information without waiting for a centralised InfoSec team to run a periodic review.
Step 1: Start Security in the Design Phase
The fastest way for open-source risk to accumulate is to start a new project with whatever libraries happen to be on a developer’s workstation from the last project—possibly years out of date and carrying unpatched CVEs.
Before writing the first line of code on a new project, establish a bill of materials (BOM): an explicit, versioned inventory of every open-source framework and library the application will use. Then vet that list against known vulnerability databases.
Practical actions at design time:
- Choose the most current stable release of each framework rather than carrying forward a version from a previous project.
- Use software composition analysis (SCA) tools to generate and validate the BOM before significant development work begins. Many commercial and open-source options exist (the original article mentioned SourceClear, which has since been acquired; equivalent capabilities are available in tools such as OWASP Dependency-Check, Snyk, or GitHub’s native dependency graph).
- Define an acceptable policy for dependency freshness and known vulnerabilities before the project begins, not after.
Catching a problematic dependency at design time costs a conversation. Catching it in production costs an incident response.
Step 2: Automate Everything
Developers already carry significant cognitive load. Adding manual security checklists, approval workflows, or portal sign-offs to every deployment will reliably produce one outcome: developers will route around those controls.
The solution is to make security checks automatic, asynchronous, and invisible to the developer’s primary workflow. Security tooling should run in the CI/CD pipeline—triggered automatically on every commit or pull request—and surface actionable results without blocking the developer’s flow unless a critical threshold is crossed.
Key automation patterns:
- Static application security testing (SAST) runs against first-party code on every push.
- Software composition analysis (SCA) scans the dependency manifest on every build and alerts on newly disclosed CVEs, even for code that has not changed.
- Secrets scanning checks for accidentally committed credentials or API keys.
- Policy gates can be configured to fail a build automatically if a critical vulnerability is present, while lower-severity findings are reported asynchronously so they do not interrupt a fast-moving sprint.
The InfoSec principle that “security is everyone’s job” only becomes real when security tooling integrates into the workflow developers already use—version control, CI pipelines, and chat notifications—rather than requiring separate logins to separate portals.
Step 3: Build Good Citizens, Not Just Good Builds
The traditional deployment pipeline looks like this:
Design → Code → Integration Test → QA → InfoSec Review → Production
That model breaks down entirely when a DevOps team ships multiple times per day. There is no time for a manual InfoSec Review gate before every production push.
But consider what you are actually verifying at that gate. If security feedback has been automated and delivered to developers from the design phase onward, the InfoSec Review is not discovering new information—it is simply checking whether developers acted on what they already knew. That is a question of trust and process verification, not technical discovery.
When security is genuinely integrated earlier in the lifecycle, the pre-production InfoSec Review can be replaced with a lightweight, evidence-based checklist during change control:
- Have automated security scans (SAST and SCA) completed successfully at every stage of the pipeline for this application?
- Have developers been triaging and resolving critical and high-severity findings consistently throughout the sprint cycle?
- Does the most recent completed assessment meet the organisation’s defined security policy?
If the answer to all three is yes, deployment can proceed. The bottleneck gate is gone. The cultural shift here is significant: InfoSec moves from being a gatekeeper who approves releases to being the team that defines policy, provisions tools, and monitors compliance metrics—enabling developers rather than blocking them.
Putting It Together
Securing open-source-heavy DevOps pipelines does not require a separate security team running parallel reviews. It requires embedding security practices where development decisions are made:
- Audit and approve your dependency inventory at design time, before significant code is written.
- Automate SAST and SCA in your CI/CD pipeline so security feedback is continuous and does not require manual intervention.
- Replace manual pre-production security gates with evidence-based policy checks that verify developers acted on the information they received throughout the cycle.
This is the operational definition of DevSecOps: security that is continuous, automated, developer-facing, and proportionate to the pace at which modern teams actually ship software.