In 2021, OWASP ranked software supply chain vulnerabilities in its newly created A08 category ("Software and Data Integrity Failures"). In the 2025 update, OWASP moved this category up to A03: "Injection and Supply Chain." That promotion reflects a measurement shift: when the security industry started examining supply chain attack surfaces seriously, the attack surface turned out to be far larger than the category's original position implied.
Every team member on this post could explain what the SolarWinds compromise was. Most organisations have not asked what their own software supply chain attack surface looks like or what testing it actually involves.
This post covers both: what the software supply chain attack surface encompasses, and what security testing of that surface actually requires.
Modern application development is almost entirely assembly work. The average production application contains hundreds of open-source dependencies. Those dependencies have their own dependencies. A dependency graph of a moderately complex Node.js or Python application extends to thousands of packages from thousands of maintainers, most of them unknown to the development team. Each of those packages is a component of the software supply chain, and each has an independent security posture that the consuming organisation did not review.
The security concern is not that open-source software is inherently untrustworthy. It is that the trust relationships in software dependency graphs are largely implicit. A developer who adds a package is implicitly trusting that the package maintainer's account has not been compromised, that the package registry has not been tampered with, that the package itself does not contain malicious code, and that the build pipeline that produces the final artifact has not been modified. Those trust assumptions are frequently untested.
Dependency confusion attacks exploit the way package managers resolve package names across public and private registries. If an organisation uses a private package registry for internal packages and also consumes packages from the public registry, a package manager that checks the public registry first will resolve a public package with the same name as a private package, even if the private package is the intended dependency.
An attacker who registers a package on npm, PyPI, or the RubyGems registry with the same name as an organisation's known internal package, at a higher version number, can cause the organisation's build system to silently install the attacker's package rather than the intended internal one. This attack does not require compromising any system: it exploits a configuration default.
Testing implication: Dependency confusion is testable by auditing package manager configuration for registry resolution order and verifying that internal package names are reserved on public registries or that scoped package names are used to eliminate the name collision surface.
Typosquatting attacks register packages with names visually similar to widely used packages (crypyo for crypto, lodash variations, reqests for requests. Developers who mistype a package name during installation pull down the attacker's package rather than the intended one.
While the attack requires developer error to succeed, it is persistent in the supply chain once the malicious package is present in a package-lock.json, requirements.txt, or other lock file, subsequent developers who install the project dependencies from the lock file pull the typosquatted package without making the original typo themselves.
Testing implication: SCA (Software Composition Analysis) tooling that checks installed packages against known typosquat registries, combined with periodic audit of lock files for packages with unusual names or low download counts relative to purported popularity.
The XZ Utils attack of 2024 is the canonical example of a long-term maintainer account compromise: a new contributor built trust over two years before injecting a backdoor into the compression library used by OpenSSH across Linux distributions. The attack was sophisticated, patient, and nearly succeeded.
Less sophisticated versions of this attack are more common: maintainers of high-value packages have their accounts compromised through credential stuffing or phishing, and attackers publish a new malicious version of the legitimate package. Any organisation that consumes the package without version pinning or integrity verification automatically receives the malicious version.
Testing implication: Version pinning in combination with hash-based integrity verification (using integrity fields in npm lock files, hash pinning in requirements files) ensures that the exact artifact tested is the artifact deployed. Supply chain security assessment reviews whether pinning and integrity checks are enforced throughout the dependency graph.
The build pipeline itself is an attack surface that many security programmes do not include in their assessment scope. CI/CD systems (GitHub Actions, Jenkins, GitLab CI, CircleCI) execute code from multiple sources: repository code, third-party actions, pulled Docker images, and environment variables that may carry secrets. An attacker who can modify any of these inputs can inject malicious code into the build pipeline in ways that do not appear in the source code that developers review.
Third-party GitHub Actions are a particularly high-risk surface. An action that is widely used across thousands of repositories may be maintained by a single individual whose account can be compromised. The actions/checkout supply chain incident and subsequent compromises of third-party actions demonstrated that organisations using actions without version pinning or hash pinning have implicit trust relationships with the maintainers of every action their pipelines use.
Testing implication: Build pipeline security review covers pipeline configuration for third-party dependency pinning, secret handling (whether secrets are exposed to third-party actions, how they are scoped), pipeline privilege review (what permissions the pipeline runner holds in the target environment), and whether build artifacts are signed for integrity verification downstream.
The emergence of MCP (Model Context Protocol) as the standard for connecting AI agents to tools has created a new supply chain attack surface in AI development environments. MCP servers are packages distributed through npm, PyPI, and emerging MCP registries. An AI agent that connects to a third-party MCP server is trusting that server's code at a level that is at least as sensitive as trusting any other privileged dependency: the MCP server has direct access to the tools and data the agent uses.
MCP security: what model context protocol means for AI agent safety covers the MCP attack surface in detail. For supply chain purposes: MCP server packages inherit all the supply chain risks of the npm/PyPI ecosystems (typosquatting, compromised maintainer accounts, dependency confusion) with the additional risk that a malicious MCP server has privileged access to the AI agent's tool execution context. Agentic AI security: what it means and why it's different covers the full AI agent security model within which MCP supply chain risk sits.
This is the half of the topic that the SERP does not have. Defining supply chain attacks is well-covered. What security testing of the supply chain involves is not covered anywhere in the current results.
SCA is the baseline tool for supply chain security. It scans the application's dependency manifest and lock files, enumerates all direct and transitive dependencies, and checks each against known CVE databases and vulnerability advisory feeds.
What SCA covers: Known CVEs in enumerated dependencies at known versions. OWASP Dependency Check, Snyk, FOSSA, and GitHub's Dependabot are the primary tools. SCA is continuous by nature: it runs on every build and on a scheduled basis to catch new CVEs published against versions already in use.
What SCA misses: SCA checks declared dependencies against known CVEs. It does not detect malicious packages that have not yet been CVE-catalogued (newly injected malware, zero-day compromised maintainer releases). It does not assess whether packages are pinned to specific versions and hash values. It does not review build pipeline configuration. It does not audit package registry access controls. These gaps require additional testing layers. The security gaps DAST and standard testing misses covers the broader class of vulnerabilities that automated tooling structurally cannot find; the same principle applies to SCA's coverage limits.
An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all components in a software application (direct dependencies, transitive dependencies, version information, and licensing data. SBOM generation has moved from optional to standard practice in many regulated environments following Executive Order 14028 in the US and similar regulatory signals in the EU.
What SBOM enables for security: An accurate SBOM makes it possible to answer the question "are we affected by CVE-X?" in minutes rather than hours of manual dependency graph traversal. When a new vulnerability is published against a popular library, organisations with current SBOMs can immediately determine whether any of their products include the affected version.
Testing SBOMs: Supply chain security assessment reviews whether SBOMs exist and are current, whether the SBOM generation is integrated into the build pipeline (so it is automatically regenerated with each build rather than maintained manually), whether the SBOM format is compatible with the organisation's downstream vulnerability management tooling, and whether the SBOM captures transitive dependencies accurately rather than only direct dependencies.
A build pipeline security review examines the configuration of CI/CD pipelines for supply chain attack surfaces:
Third-party action pinning: GitHub Actions used in workflows should be pinned by commit hash rather than by tag. Tags are mutable: a compromised maintainer can move a tag to point to a malicious commit. A hash-pinned action resolves to a specific, immutable commit regardless of tag changes.
Secret scoping: CI/CD pipelines frequently have access to deployment credentials, signing keys, and API tokens. Supply chain security review assesses whether secrets are scoped to the minimum required permissions, whether they are exposed to third-party actions or only to first-party steps, and whether secret values appear in pipeline logs.
Pipeline privilege review: The permissions that the pipeline runner holds in the target environment determine the blast radius of a pipeline compromise. A pipeline with administrator access to the production environment and access to signing keys represents a much larger supply chain attack surface than one with minimal scoped permissions.
Artifact integrity: Whether build artifacts are signed before distribution (code signing for binaries, container image signing, npm publish signing) and whether the signing infrastructure itself is protected.
Active testing for dependency confusion vulnerability involves:
Enumerating internal package names used across the organisation's codebases and verifying that those names are either scoped (preventing public registry collision), reserved on public registries, or that the package manager configuration is explicitly locked to the private registry for those names.
Auditing package manager configuration files for registry resolution order to confirm the private registry takes precedence over public registries for internal packages.
Reviewing whether build systems can be configured to allow-list approved registries rather than resolving from all registries by default.
The registries an organisation uses to publish and consume packages have their own access control requirements. Supply chain security assessment reviews whether package registry accounts use MFA, whether publishing rights are restricted to CI/CD systems and specific individuals, whether there is a process for rotating publishing credentials, and whether package versions can be unpublished (creating dependency resolution failures).
SLSA (Supply chain Levels for Software Artifacts, pronounced "salsa") is an industry framework developed by Google that defines levels of supply chain security assurance. Each level makes testable claims about the build process:
SLSA Level 1: Build processes are scripted and the provenance (information about how the artifact was built) is available. This is the baseline: it establishes that the build can be reproduced and that the process is documented.
SLSA Level 2: Source control and build service are used. Build service generates signed provenance. Builds are not executable from a developer's local machine.
SLSA Level 3: Source and build platforms meet specific security requirements. Provenance is generated and signed by the build service in a way that is unforgeable. Build is isolated and cannot influence other builds.
SLSA Level 4 (aspirational): All build dependencies are fully tracked, reviewed, and verified. The highest assurance level, currently aspirational for most organisations.
Supply chain security assessment evaluates where an organisation sits on the SLSA framework and what specific controls are required to advance to the next level. SLSA provides a progression model that makes supply chain security improvement plannable rather than abstract.
Software supply chain security intersects with three other major security programme areas:
The CTEM framework: Continuous threat exposure management requires continuous validation of exposure. The supply chain represents a continuously changing exposure surface: new dependencies are added, new CVEs are published against existing dependencies, and build pipeline configuration drifts. CTEM's discovery stage should include the dependency inventory, and its validation stage should include SCA tooling.
DevSecOps and shift-left security: Shift-left security testing places security testing in the CI/CD pipeline. Supply chain security gates (SCA scanning, SBOM generation, dependency pinning verification) belong at the earliest possible pipeline stage: at the PR gate or the build stage, not as a post-deployment review. SAST tools: what they catch and what they miss covers how SAST and SCA complement each other as shift-left controls.
Cloud infrastructure supply chain: Container base images, Terraform modules, Helm charts, and cloud provider marketplace solutions are all components of the cloud infrastructure supply chain. Cloud security assessment: what it covers and why you need one covers cloud security assessment including the container image scanning and infrastructure-as-code review that covers the cloud layer of the supply chain. Vulnerability management automation covers how SCA fits within the broader VM pipeline alongside application security testing.
A dedicated supply chain security assessment is a distinct engagement from standard application penetration testing. Where application penetration testing validates whether the application is exploitable, supply chain security assessment validates the integrity of the components and processes that produce the application.
The scope of a supply chain security assessment typically covers:
Dependency audit: SCA scan of all repositories in scope with enumeration of direct and transitive dependencies, CVE mapping, and identification of packages that are unpinned, outdated, or sourced from unusual registries.
SBOM assessment: Whether SBOMs exist, whether they are current and accurate, and whether they capture transitive dependencies rather than only direct dependencies.
Build pipeline review: Configuration review of all CI/CD pipelines for the repositories in scope, covering third-party action pinning, secret handling, pipeline privilege, and artifact signing.
Registry access control: Review of package registry accounts for publishing rights, MFA enforcement, and credential rotation practices.
Dependency confusion testing: Active testing for dependency confusion vulnerability across internal package namespaces.
SLSA assessment: Evaluation of the organisation's current SLSA level and specific gaps to reach the next level.
The findings from this assessment feed the same remediation cycle as application security findings: the same triage, routing, and SLA framework applies. For penetration testing services in the US covering supply chain security assessment alongside application and API security testing, agentic penetration testing for continuous application-layer coverage that complements supply chain assessment, and PTaaS for ongoing security programme coverage, the 10x Pentest platform covers the application and supply chain security layers. See pricing or get in touch to discuss supply chain security testing requirements. Broken access control: why it is still the number one web risk covers the OWASP A01 category that accompanies A03 in the updated 2025 framework.
Q1. What is software supply chain security?
Software supply chain security is the set of practices, controls, and testing methodologies that protect the components, processes, and infrastructure used to build and distribute software. It covers open-source and third-party dependencies (which components are used, whether they contain known vulnerabilities, whether they have been tampered with), the build pipeline (whether the CI/CD system that compiles and packages software can be compromised), package registries (whether packages are distributed through authenticated and integrity-verified channels), and the tools used in development environments. The threat model is that an attacker who cannot compromise the application directly may be able to compromise a dependency or build process to introduce malicious code into the application at the point of production.
Q2. What are the most common software supply chain attacks?
The most common attack vectors are: dependency confusion (registering a public package with the same name as an organisation's internal package to cause package managers to resolve the malicious public package); typosquatting (registering packages with names visually similar to widely-used packages to catch developer installation errors); compromised maintainer accounts (gaining control of a legitimate package maintainer's account and publishing a malicious version of a trusted package); build pipeline injection (modifying CI/CD configuration, third-party actions, or environment to introduce malicious code into the build process without modifying reviewed source code); and malicious packages in AI tool ecosystems, where MCP server packages and AI development tools inherit supply chain risks from the package registries that distribute them.
Q3. What is an SBOM and why does it matter for security?
An SBOM (Software Bill of Materials) is a machine-readable inventory of all components in a software application (direct dependencies, transitive dependencies, version information, and licensing data. For security, an accurate SBOM enables rapid response to newly published vulnerabilities: rather than manually traversing a dependency graph to determine whether a new CVE affects any product, an organisation with current SBOMs can immediately query which products include the vulnerable version. SBOMs also support supply chain integrity verification: a signed SBOM can be used to verify that deployed software matches the expected component inventory. Following US Executive Order 14028 and equivalent regulatory signals in the EU, SBOM generation is increasingly a compliance requirement rather than an optional practice.
Q4. What is the SLSA framework for software supply chain security?
SLSA (Supply chain Levels for Software Artifacts) is a framework developed by Google that defines four levels of supply chain security assurance, each making progressively stronger claims about the integrity of the build process. Level 1 requires scripted builds and provenance availability. Level 2 adds signed provenance generated by the build service and removes developer-local build capability. Level 3 requires the build platform to meet specific security requirements and makes provenance unforgeable. Level 4 (aspirational) requires comprehensive verification of all build dependencies. Organisations use SLSA as a progression framework for improving supply chain security systematically: knowing their current level and what specific controls are required to advance provides a concrete improvement roadmap.
Q5. How does supply chain security relate to application penetration testing?
Application penetration testing validates whether the running application is exploitable: it tests the application's code, authentication, authorization, API security, and business logic. Supply chain security assessment validates the integrity of the components and processes that produced the application: it reviews dependency inventories, build pipeline configuration, registry access controls, and SBOM accuracy. The two are complementary: an application with no exploitable vulnerabilities can still be at risk from a compromised dependency that was introduced through the build pipeline. A mature security programme covers both: penetration testing for the runtime application layer, and supply chain security assessment for the build and distribution layer. Both feed the same remediation and vulnerability management programme.
A medium IDOR plus a low session token issue plus an informational error disclosure is not three low-risk findings. It can be a full account takeover. Attack path analysis reveals which chains lead to real breach routes.
Tejas Dhokane Oct 5, 2026 
Broken access control has topped the OWASP Top 10 since 2021. Most testing misses it. Scanners cannot find authorization flaws. Here is what broken access control actually looks like and how multi-role testing finds it.
Tejas Dhokane Oct 1, 2026 
The pentest report is the beginning of the security work, not the end. This guide maps the full remediation lifecycle — triage, routing, developer handoff, SLAs, retest, and compliance evidence.
Tejas Dhokane Sep 18, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
