Supply Chain Security Explained: Vendor Risk and SBOM for Security+

Supply chain attacks compromise a trusted supplier in order to reach that supplier's customers. They are effective because they exploit the one thing security controls are designed to grant: trust.

A signed update from your software vendor is applied without question. That is exactly the point, and it is why a single compromised vendor can reach thousands of organisations at once.

The three supply chains

Software supply chain. Compromise the vendor's build process so malicious code is included in a legitimately signed release. Also covers open-source dependencies, package repositories, and the build tooling itself.

Hardware supply chain. Counterfeit components, tampering in manufacturing or transit, and malicious firmware. Harder to execute and much harder to detect.

Service provider supply chain. Managed service providers, cloud services and outsourced IT. An MSP with administrative access to hundreds of client networks is an unusually attractive target.

Why it works so well

Trust is inherited. You vetted the vendor once; you do not re-vet every update. The delivery mechanism is legitimate, so code signing and update channels work in the attacker's favour rather than against them. Detection is hard because the activity originates from software you installed deliberately. And the blast radius is enormous — one compromise, every customer.

The related exam concept is fourth-party risk: your vendor's vendors. Your data may sit with a subcontractor you never assessed and cannot name.

Software bills of materials

An SBOM is a formal inventory of the components in a piece of software, including versions and dependencies. The argument for it is straightforward: when a critical vulnerability is announced in a widely used library, the first question is "are we affected?" — and without an SBOM that question takes weeks to answer.

Formats to recognise are SPDX, an ISO standard originating from the Linux Foundation, and CycloneDX, an OWASP project oriented toward security use cases.

The limitation worth knowing: an SBOM tells you what is present, not whether it is exploitable in context. It is an inventory, not an assessment.

Integrity controls

Code signing proves a package came from the claimed publisher and has not been altered — but it proves nothing about whether the publisher was compromised when they signed it.

Reproducible builds allow independent parties to build from the same source and obtain a bit-identical artefact, which detects a tampered build process.

Artefact signing and provenance attestation record how, where and from what an artefact was built.

Dependency pinning fixes exact versions so an upstream compromise does not silently arrive in the next build, and lock files make that reproducible.

Private registries and vetting control what enters the build at all, defending against typosquatting and dependency confusion.

Vendor risk management

The process CompTIA tests, in order.

Before engagement: security questionnaire, independent audit reports such as SOC 2 Type II or ISO 27001 certification, breach history, financial viability, data location, and identification of their subcontractors.

In the contract: security requirements, right to audit, breach notification timelines, data ownership and return, sub-processor notification, and end-of-life terms.

During the relationship: periodic reassessment, monitoring for news of their breaches, and reviewing when they are acquired or change architecture.

At exit: data return or destruction, access revocation, and confirmation that it happened.

The important framing: due diligence is not a one-off checkbox before signature. It is continuous, because the vendor's risk profile changes.

Limiting the blast radius

Because prevention is imperfect, containment matters. Give vendors least privilege rather than broad administrative access — an MSP rarely needs standing domain administrator rights. Segment vendor access to only the systems they support. Use just-in-time access that expires. Monitor vendor accounts as closely as privileged internal ones, since a compromised vendor looks like a legitimate vendor. Test updates in a staging environment where the risk justifies the delay. And include supplier compromise as a scenario in incident response exercises.

What to remember

Supply chain attacks exploit inherited trust and reach every customer of one compromised supplier. The three vectors are software, hardware and service providers, and fourth-party risk extends the problem to your vendor's vendors. An SBOM answers "are we affected" quickly; SPDX and CycloneDX are the formats. Code signing does not protect against a compromised publisher. Vendor assessment is continuous, and least privilege limits what a compromise reaches.

Related reading: SBOM · Due diligence and due care · Secrets scanning