The Supply Chain Is the Attack Surface
If 2024 was the year the industry woke up to software supply chain risk, 2025 is the year it started doing something about it. The aftershocks of the XZ Utils backdoor, the continued fallout from Log4Shell, and a steady drumbeat of compromised npm packages have moved supply chain security from conference-talk material to boardroom agenda.
OWASP — the Open Worldwide Application Security Project — has responded with updated guidance that makes one thing unmistakably clear: you cannot secure what you do not inventory, and you cannot inventory what you do not scan.
What Changed in the Guidance
OWASP's refreshed recommendations for addressing "Vulnerable and Outdated Components" now emphasise several practices that were previously treated as optional:
Continuous Software Composition Analysis (SCA)
Point-in-time scans are no longer sufficient. OWASP now recommends that SCA runs on every commit and as part of every CI pipeline execution. The rationale is simple: a dependency that was safe on Monday can have a published CVE by Tuesday. If your SCA only runs during quarterly audits, you are operating with a three-month blind spot.
Transitive Dependency Visibility
Direct dependencies — the packages you explicitly install — account for only a fraction of your attack surface. OWASP's guidance now stresses that teams must have visibility into the full transitive dependency tree, including dependencies of dependencies. In JavaScript ecosystems, a typical project with 30 direct dependencies may pull in 800+ transitive ones. Each is a potential entry point for a malicious or vulnerable package.
SBOM as a Baseline
The Software Bill of Materials (SBOM) has graduated from "nice to have" to "expected practice". OWASP aligns with U.S. Executive Order 14028 and the EU Cyber Resilience Act in recommending that every production deployment be accompanied by a machine-readable SBOM in CycloneDX or SPDX format. This is not just a compliance exercise — SBOMs enable automated vulnerability matching across your entire fleet.
Credential and Secret Leak Detection
A newer addition to the guidance acknowledges that supply chain risk is not limited to vulnerable code. Hardcoded credentials, API keys committed to repositories, and secrets leaked through build logs are all vectors that attackers exploit. OWASP now recommends integrating secret scanning alongside dependency scanning as part of a unified security posture assessment.
Real-World Implications
For engineering teams, these updated recommendations translate into concrete changes:
CI pipelines need more gates. If your pipeline currently runs linting, unit tests, and a build step, it now needs an SCA step and a secret scan step. Both should be configured to fail the build on critical findings — not just log a warning.
Dependency update PRs need security context. When Renovate or Dependabot proposes a version bump, the PR description should include whether the new version addresses known CVEs and whether the upgrade introduces breaking changes. This context turns a "should we merge this?" conversation into a risk-informed decision.
Architecture reviews need a supply chain lens. When evaluating a new library or framework, teams should assess not just its API and performance, but its maintenance health: How frequently is it released? How quickly are CVEs patched? How deep is its transitive dependency tree? A library that is well-designed but poorly maintained is a liability.
The Tooling Landscape
The market for supply chain security tooling has expanded rapidly. Snyk, Sonatype, Mend (formerly WhiteSource), and Grype all offer SCA capabilities. GitHub's Dependabot and GitLab's dependency scanning provide native integrations. For SBOM generation, Syft and Trivy have become popular open-source choices.
But tooling alone is not enough. The challenge most teams face is not detecting vulnerabilities — it is prioritising and acting on them. A scan that returns 200 findings is not actionable unless those findings are ranked by exploitability, reachability, and business impact. This is where drift intelligence — understanding not just what is outdated but how far behind and what the upgrade requires — becomes critical.
Beyond Vulnerability Counts
One of the most important shifts in the updated OWASP guidance is the move away from raw vulnerability counts toward risk-contextualised assessments. A project with 50 low-severity findings in dev dependencies may be safer than a project with 3 high-severity findings in production runtime dependencies. The guidance encourages teams to build scoring models that account for:
- Exploitability: Is there a known exploit in the wild?
- Reachability: Does your code actually invoke the vulnerable function?
- Environment: Is the dependency used in production, staging, or development only?
- Data sensitivity: Does the affected component handle PII, credentials, or financial data?
This nuanced approach prevents teams from drowning in noise while missing the signals that matter.
What to Do This Quarter
If your team has not yet operationalised supply chain security, here is a pragmatic starting point:
- Run an SCA scan today and establish a baseline of known vulnerabilities. Triage the critical and high findings immediately.
- Generate an SBOM for your main production applications. Store it alongside your deployment artefacts.
- Add SCA to CI. Configure it to block merges for critical-severity findings.
- Integrate secret scanning. At minimum, scan for AWS keys, database connection strings, and API tokens.
- Schedule a monthly review of your dependency health. Track trends over time — are you getting better or worse?
Supply chain security is not a one-time project. It is a posture — and like any posture, it requires continuous attention. The organizations that invest now will be the ones best prepared for the regulatory and threat landscape of 2026 and beyond.