WebOTG-SCF-001 — Software Supply Chain Security Review

Objective

Modern applications rarely consist entirely of internally developed code. They depend on operating systems, runtimes, frameworks, libraries, packages, containers, build tools, CI/CD systems, third-party services and other software components.

A supply chain failure can therefore occur even when the application's own source code is secure. A vulnerable dependency, compromised package, malicious build change, stolen CI/CD credential or untrusted artifact can introduce risk before software reaches production.

Scope

Review the complete software supply chain where applicable:

Prerequisites

Methodology

The assessment should establish what software enters the application, where it comes from, which versions are actually used, whether those components remain supported and whether changes to the supply chain are controlled.

Test procedure

Software component inventory

The first requirement of effective supply-chain security is knowing what software is actually present. An inventory should include direct and transitive dependencies and, where practical, their versions, sources and identifiers.

Example dependency declaration

{
    "dependencies": {
        "example-framework": "4.2.1",
        "example-library": "2.8.0",
        "example-client": "1.6.4"
    }
}

Supply chain risk assessment

Vulnerability verification

A vulnerability reported by a dependency scanner should not automatically be treated as a confirmed exploitable finding. Verification should establish that the affected component and relevant vulnerable functionality are actually present in the assessed software.

Failure criteria

Remediation

Establish a continuous software supply chain management process rather than treating dependency updates as an occasional maintenance task.

Recommended controls

1. Maintain a current inventory of direct and transitive dependencies.
2. Generate and maintain a Software Bill of Materials for released software where appropriate.
3. Monitor relevant vulnerability databases and vendor security advisories.
4. Remove unused dependencies and unnecessary components.
5. Prefer maintained components with a clear security update path.
6. Obtain dependencies from trusted package sources.
7. Use lock files or equivalent dependency resolution controls where appropriate.
8. Protect source repositories and package publication credentials.
9. Apply MFA and least privilege to critical supply-chain accounts and systems.
10. Protect CI/CD workflow configuration against unauthorized modification.
11. Separate code development, build approval and production promotion responsibilities where the risk warrants it.
12. Protect artifacts through controlled repositories, provenance and integrity mechanisms.
13. Test dependency updates before production deployment.
14. Use staged or controlled deployment for high-risk updates where appropriate.
15. Maintain a documented process for responding to newly discovered supply-chain vulnerabilities.

Example dependency update

Before

"example-library": "2.8.0"


After

"example-library": "2.8.7"


Required verification

1. Confirm advisory status.
2. Review release notes.
3. Update dependency lock data.
4. Run automated security checks.
5. Run application tests.
6. Build the release artifact.
7. Verify artifact provenance/integrity.
8. Deploy through the approved pipeline.
9. Re-scan the deployed software.

Evidence requirements

Classification

References

OWASP identifies A03:2025 as an expanded category covering failures across dependencies, development tooling, CI/CD, repositories, artifacts and related supply-chain processes. :contentReference[oaicite:2]{index=2}

The current OWASP Top 10:2025 list places Software Supply Chain Failures at A03, following Broken Access Control and Security Misconfiguration. :contentReference[oaicite:3]{index=3}