Software Supply Chain Security: Beyond the Vendor Questionnaire

Your software inherits the security of everything it depends on, most of which you did not choose. Dependencies, build pipelines and the update channel as an attack path.

GuardsArm Team

Security Experts

May 13, 2025

Software supply chain

Vendor risk management asks whether your suppliers are secure. Software supply chain security asks a harder question: whether the code running in your estate — including the parts nobody chose deliberately — can be trusted.

A typical application directly depends on a few dozen libraries and transitively on several hundred. Those were selected by other people, are maintained by volunteers, and update automatically. The organisational diligence in vendor risk scoring does not reach any of it.

Mostly transitive

The large majority of dependencies were never chosen by you

Update as attack path

A trusted update channel delivers to every customer at once

SBOM answers "are we affected"

The question you will be asked within hours of the next event

Three distinct problems

1. Vulnerable dependencies. A library you use has a flaw. Common, well-tooled, and mostly a patching problem.

2. Malicious dependencies. A package is deliberately compromised — typosquatting a popular name, or a maintainer account taken over and a malicious version published. Less common, far more damaging, and not caught by vulnerability scanning because there is no CVE.

3. Build and distribution compromise. The source is clean but the artefact is not, because the build pipeline or update channel was compromised. The hardest to detect and the reason signing matters.

Controls, by problem

Problem	Control
Vulnerable dependencies	Dependency scanning in CI and on the registry; patch on a schedule
Malicious packages	Pin versions and use a lockfile; use an internal proxy registry; review new dependencies before adoption
Typosquatting	Allow-list, or at minimum flag newly-introduced package names for review
Build compromise	Reproducible builds where feasible; sign artefacts; restrict who can publish
Update channel	Verify signatures on vendor updates; stage before broad deployment
Everything	An SBOM, so the exposure question is answerable in minutes

Pin and lock, then update deliberately

A dependency specified as "latest compatible" means your build output changes without a decision being made. Lockfiles turn dependency updates into reviewable changes rather than silent ones — which is what catches a compromised release before it ships.

SBOMs, used rather than filed

An SBOM lists what is in a piece of software. Its value is operational: when the next widely-exploited library lands, "are we affected, and where" should take minutes.

To be useful it has to be:

Generated at build time, not written afterwards
Stored and queryable across all your software, not attached to a release
Requested from vendors as a procurement requirement
Actually searched when an advisory lands — which requires someone owning that

Most SBOM programmes fail at the last two. A file in a repository that nobody queries has cost effort and delivered nothing.

Ask suppliers the questions that matter

Beyond the standard questionnaire:

Will you provide an SBOM for each release?
How quickly do you patch a critical dependency vulnerability, contractually?
How are your build systems protected, and who can publish a release?
Are releases signed, and how do we verify them?
What is your disclosure process, and will you notify us directly?
What third parties does your product depend on at runtime?

The build-system question is the revealing one. A supplier who has thought about who can publish a release has thought about this problem; one who has not, has not.

For healthcare specifically

Clinical software supply chains have an extra constraint: you often cannot patch quickly because the vendor must certify the change — see patch management. That makes knowing your exposure faster, and compensating sooner, more important than in most sectors, because the remediation path is slower.

When a supplier is compromised

Software supply chain incidents have a distinct shape: you learn from the news or the vendor, everyone affected learns simultaneously, and the initial information is incomplete and often wrong.

A workable sequence:

Establish whether you run it, and which versions — the SBOM question again
Assume the affected version is compromised until the vendor is specific
Isolate rather than uninstall, so evidence survives
Hunt for the published indicators, and for the behaviour rather than just the hashes, which change
Check what the software could reach. Supply chain compromises are valuable precisely because the software is trusted and well-connected
Do not rely solely on the vendor's assessment of whether you are affected

The vendor’s first statement is usually optimistic

Initial disclosures routinely understate scope, not through bad faith but because the investigation is ongoing. Plan for the assessment to widen, and avoid telling your own stakeholders anything more definite than the evidence supports.

Where to start

Ask for an SBOM from your three most critical software vendors. The responses — including any refusals — tell you a great deal about how seriously each takes this, and the request itself is increasingly expected.

GuardsArm assesses software supply chain risk for healthcare technology estates. Book a scoping call.

Topics

Written by GuardsArm Team

Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.