Supply Chain Attack Prevention: What a Supplier Assessment Actually Tests

A supply chain attack is not an attack on your network. It is an attack on a decision you already made: which code you run, which vendor holds your data, which account sits inside your environment with standing privileges. That is why the usual prevention list - more vendor questionnaires, an annual review, a risk score in a spreadsheet - changes so little. The attacker does not need to beat your controls. They need one supplier whose build pipeline, administrator account or domain registration they can take, and then they inherit every trust relationship that supplier already had with you. Prevention, done properly, is the discipline of reducing what a compromised supplier would actually be able to do, rather than writing down how much you trust them.

What changed between 2023 and 2026, in four numbers

Supply chain risk has been discussed for a decade. What changed recently is the shape of the incidents, and four public numbers carry most of the argument.

The first is third-party involvement in breaches. Verizon's 2025 Data Breach Investigations Report, built from roughly 22,000 incidents and 12,195 confirmed breaches, put third-party involvement at 30 percent - double the 15 percent it recorded the year before. The same report found exploitation of vulnerabilities up 34 percent as an initial access route, which is the mechanism most supply chain compromises actually use: not a clever new technique, but a known bug in something a supplier runs that the victim never sees.

The second is what a single supplier failure looks like at scale. When Cl0p exploited a zero-day in Progress Software's MOVEit Transfer in May 2023, Emsisoft's running tally had reached 2,773 affected organisations and 95.8 million individuals by June 2024. The detail that matters for this article is smaller and more useful: of 2,098 known victim organisations at the time TechTarget reported the campaign, 1,690 - about four in five - were not MOVEit customers at all. They were reached through someone else. That ratio is the whole problem in one sentence: most victims of a supply chain incident never chose the vulnerable product.

The third is how long a leaked secret stays alive. The same Verizon report measured a median of 94 days to remediate secrets exposed in a public GitHub repository - roughly three months during which a credential that grants write access to a codebase, a package registry or a cloud account sits in the open. A token is not a password you can rotate casually on a Friday; in CI it is often the identity of the build itself.

The fourth is the cost of the paperwork gap. SOC 2 reports and ISO 27001 certificates describe controls a supplier designed and, for Type II, operated over a sample period. They do not describe whether the supplier's integration account in your tenant has admin rights, whether its support engineers can impersonate your users, or whether it would tell you promptly if it were breached. Those three questions decide most outcomes, and none of them appear on a certificate.

Two failure modes, and a third that gets forgotten

Strip away the vocabulary and supplier risk reduces to two mechanisms plus one obligation.

The third mechanism is not technical. It is the data you handed over. A processor that holds your customer records, your source code, your telemetry or your backups is a supply chain exposure even if it never runs a line of code inside your network, because the breach lands on your notification obligations regardless of who caused it. Under GDPR you remain the controller, and under most contracts you remain the party whose customers are told.

This split matters because prevention differs by mechanism. Code exposure is reduced by pinning, provenance and rebuild discipline - controls that live in your repository. Credential exposure is reduced by access design: fewer standing accounts, narrower scopes, shorter lifetimes, stronger logging. Data exposure is reduced by minimisation and by contract. A programme that only does the third is compliance. A programme that only does the first is engineering hygiene. Neither alone is supply chain security.

The four supplier types that produce most incidents

Supplier inventories tend to be organised by spend, which is the wrong axis. Organise them by what the supplier can reach.

Software dependencies are the ones people mean when they say supply chain. A mid-sized application pulls in hundreds of direct and transitive packages, a base container image that itself layers dozens more, and often a handful of scripts loaded at runtime from somebody else's domain. The exposure is not that a package is malicious on the day you install it; it is that the version you resolve changes, that the maintainer account changes hands, and that your build runs whatever the registry serves at that moment.

SaaS processors hold the data and usually arrive with an OAuth grant. The characteristic incident is not the vendor's application server being breached - it is a token issued to the vendor's integration being used from somewhere unexpected, or a support console that can read tenant data without a customer-side action. The prevention question is not whether they are certified but what that grant can do if it is stolen, and whether you would see it happen.

Managed service providers and remote support tools are the highest-value target of the four, because the access is deliberately deep. An RMM agent on every endpoint, a remote-access tool with unattended sessions, a backup operator with domain credentials - each is a designed backdoor that exists because it is useful. The 2021 Kaseya incident and the long tail of remote-management abuse that followed made the pattern explicit: compromise the tool, inherit every customer. If you cannot answer which accounts can push software to all your endpoints and who can use them without your approval, that is your largest single exposure regardless of what your vendors score.

Physical and human suppliers - contractors, facilities, hardware with firmware, an outsourced helpdesk - are usually excluded from cyber supply chain reviews and are how a lot of real intrusions begin: a laptop imaged by a supplier, a network port patched by a contractor, a firmware update delivered through a vendor portal. Their control set is different (device attestation, port security, onboarding and offboarding of people, firmware verification), but the question is identical: what can this party reach, and how would we know if they were compromised.

Build-time prevention: pinning, lockfiles and what provenance proves

The engineering half of supply chain defence is unglamorous and mostly already invented. Four controls carry most of the weight.

Pin what you install, and install from a lockfile. A floating range in a manifest means the artifact that lands in production is whatever the registry had at build time. A committed lockfile with integrity hashes means the same bytes every time, and a changed hash becomes a signal rather than a silent upgrade. This is the cheapest control in the list and the most commonly skipped, because a version range just works until the day it does not.

Rebuild rather than trust a prebuilt artifact. The XZ Utils backdoor, CVE-2024-3094, is the case everyone now cites, and the technical detail is the part worth keeping: the malicious payload was not in the git history. It was in the release tarballs, injected at build time by a macro present only in the packaged source, and it hooked authentication inside sshd through liblzma. A pipeline that downloads a tarball and compiles it inherits that; a pipeline that builds from a reviewed commit and compares the result does not.

Know where the artifact was built. SLSA - Supply-chain Levels for Software Artifacts - defines build levels that answer a narrow, useful question: who produced this artifact, from what source, on what builder. Level 1 means the build is documented and provenance exists. Level 2 means a hosted build platform generates and signs that provenance, so it is not something a developer typed into a file. Level 3 means build runs are isolated from each other and the signing credential is unreachable from user-defined build steps - the answer to the SolarWinds failure mode, where the build system itself was the compromise. SLSA finalised its 1.0 specification in April 2023 and is implemented by the major hosted builders, so which level a supplier claims, and whether you can verify it, is a fair question to ask.

Verify rather than assume. npm has published provenance attestations since April 2023: a package built on a supported hosted runner can carry a Sigstore-signed statement naming the source repository, the commit and the workflow, plus a publish attestation issued by the registry. Since npm trusted publishing became generally available in mid-2025, that provenance is generated by default for publishers using it. None of it is checked for you: npm audit signatures is the command that verifies signatures and attestations against the registry keys, and running it in CI converts a vendor claim into a measured fact about your dependency tree.

Be exact about what provenance proves. It proves an artifact came from a particular repository at a particular commit, built by a particular workflow. It does not prove the code is safe, that the maintainer was not coerced, or that a dependency that workflow pulled in was honest. Provenance rules out one attack class - somebody publishing a package that pretends to be your dependency, or republishing a modified artifact under another project's name - and does nothing about the maintainer-account class described in the next section. Treat it as a control with a scope, never as a badge.

An SBOM is the inventory that makes the rest possible. The minimum elements published by NTIA in July 2021 set a modest floor: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and a timestamp. The floor is deliberately low, and the practical value sits in the dependency relationship field - the ability to answer, within an hour of a disclosure, which of your systems contains the affected component and at which version. A team that needs a week to answer that question is not doing supply chain response, whatever the generator output says.

The registry and the maintainer account are the perimeter

Two 2025 incidents define the current threat model for open source dependencies, and both attacked the publishing path rather than the code.

In March 2025 the widely used GitHub Action tj-actions/changed-files was compromised: tags from v1 to v45.0.7 were repointed at a malicious commit, so any workflow referencing a version tag - the normal, recommended practice - executed attacker code and printed CI secrets into build logs. StepSecurity's analysis counted more than 23,000 repositories affected before the tags were restored and a fixed release published; CISA issued an alert on 18 March 2025. The lesson is not "avoid GitHub Actions". It is that a mutable tag is a pointer somebody else can rewrite, and pinning to a commit SHA rather than a tag is the difference between executing reviewed code and executing whatever the tag said today.

In September 2025 the npm ecosystem got its first well-documented self-replicating worm. CISA's advisory of 23 September described Shai-Hulud as having compromised over 500 packages: the malware ran from an install hook, harvested credentials from the environment and the filesystem - GitHub personal access tokens, cloud keys for AWS, GCP and Azure, npm tokens - exfiltrated them to an attacker endpoint and to a public GitHub repository, then used the stolen npm tokens to republish itself into every other package the victim could publish. CERT/CC tracked it as VU#534320. The mechanism is the important part: the worm did not need a vulnerability. It needed the credentials that a normal developer workstation or CI runner legitimately holds.

What follows for prevention is concrete and cheap.

• Pin CI actions to commit SHAs, not tags, and review the diff when you bump one. A tag is a promise; a SHA is a fact.
• Scope registry tokens to the packages they need, and prefer short-lived OIDC-based publishing over a long-lived token in repository settings. A stolen token that cannot publish anything you care about is a much smaller incident.
• Treat install scripts as code execution. A postinstall hook runs with the build user's privileges and network access. Disabling scripts for packages that do not need them, or building inside a container with no cloud credentials mounted, breaks the first step of every registry worm.
• Keep cloud credentials out of the build environment. The reason Shai-Hulud was so damaging is that CI runners held cloud keys to deploy with. Deploy-time credentials should come from a short-lived role assumed at deploy, not from environment variables present during a dependency install.
• Watch for the two anomalies that matter: a dependency resolving to a new version without a lockfile change, and a credential being used from a new location. Both are cheap to alert on and both precede published incidents by days.

This is also where a supplier assessment earns its keep. Asking a software vendor whether their release tags are protected, whether publishing uses trusted publishing or a shared token, and whether build credentials are scoped per repository sounds pedantic until you consider that these three answers describe the exact attack surface of every dependency incident of the last two years.

The browser is a supply chain too, and nobody puts it in the inventory

In June 2024, researchers at Sansec and C/Side found that the domain cdn.polyfill.io - a JavaScript polyfill service used by roughly 110,000 websites - was injecting malicious code that redirected visitors to scam destinations. The domain and its GitHub account had been acquired in February 2024 by a company called Funnull, and the original author had publicly warned that the new owner should not be trusted. Cloudflare and Fastly published their own mirrors of the service; Google blocked ads on sites still referencing the original. Sites that had embedded a script tag years earlier, with no maintenance since, were compromised by a change in a domain's ownership that they never heard about.

That is the browser-side supply chain, and it fails differently from a package dependency. The attacker does not need your servers. They need any script your page loads, and any domain that script resolves through. The controls are correspondingly different.

An inventory of third-party origins. Every script, iframe, font, analytics tag, chat widget and tag manager container your pages load is a supplier with code execution in your users' browsers. Most organisations can name their payment provider and cannot name the eleven marketing scripts on their own homepage. A Content Security Policy written as a report-only rule is the fastest way to discover the real list, because it logs what the page actually requests rather than what the developer remembers adding.

A policy that fails closed on origins. A CSP with an explicit script-src allowlist, no unsafe-inline, and a report endpoint gives you two properties at once: a limited set of parties who can run code on your pages, and an alert when a new one appears. Subresource Integrity hashes go further for stable libraries - the browser refuses to execute a file whose bytes changed - though it is impractical for anything the vendor versions continuously.

A rule about domain ownership. The polyfill lesson generalises: any domain you load code from can change hands. Prefer vendors whose script you can pin to a version or a hash, prefer self-hosting where licensing allows, and treat an acquisition announcement about any supplier in your script inventory as a security event with a deadline.

For a site owner this is the same question as the software supply chain, asked about a different artifact: what third-party code runs with my authority, and would I notice if it changed.

Maintenance is a security property, and it is measurable

The XZ Utils backdoor is usually told as a story about a clever attacker. The more useful version is a story about a maintainership model. A contributor spent years doing real work in a small, underfunded project, gradually became a trusted maintainer, and then inserted a payload through the build scripts. Nobody was phished. The compromise was social in the sense that it exploited a governance gap: one person could change what shipped, in a project whose output several distributions compiled into an authentication path.

You cannot audit your way out of that for every dependency. What you can do is ask measurable questions about the ones that matter, defined as the ones that run with privilege: anything in your authentication path, anything that parses untrusted input, anything with network access, anything in the container base layer.

These questions are answerable from public data in about ten minutes per project, which is why they are worth asking before you adopt something, not after. The last one is the only predictor that consistently correlates with pain: projects that ship fixes slowly are the ones that leave you exposed for weeks on a bug that was public on day one.

Two structural answers follow. First, prefer a dependency you can replace: the project with three maintainers and a governance document over the one person publishing from a laptop, when the cost is similar. Second, reduce the number of things running with privilege. A dependency graph that is 400 packages deep is not inherently unsafe, but every package in it is a party that can ship code into your process, and the honest reason teams do not know their graph is that nobody ever had to answer for it.

What a supplier assessment should actually test

Here is where most vendor-risk programmes and most "supply chain audits" diverge from what an attacker does. The programme asks the supplier to describe its controls. The attacker asks what the supplier's credentials can reach inside the customer. A real assessment asks the second question, with evidence, and it starts with a document most organisations have never drawn: the access map.

For each supplier, list every mechanism by which it touches you - SSO application, OAuth grant, API key, service account, agent installed on endpoints, VPN tunnel, shared mailbox, data export, support impersonation - and for each one, write four fields: what it can read, what it can change, whether the credential is standing or short-lived, and who at the supplier can use it without your approval. The map is usually the finding. An integration account with tenant-wide read access, created for a proof of concept three years ago and never reviewed, is more dangerous than any control gap in a questionnaire, and it is invisible to the questionnaire because it is your configuration, not theirs.

Four properties of the access map decide the outcome of an incident.

Privilege. Does the supplier's account hold the minimum it needs, or did it get admin because that was simpler during onboarding? An integration that only needs to read one table but holds database owner is a supplier breach that becomes your breach.

Lifetime. Is the credential standing, or does it expire and get reissued against a fresh authorization? Standing credentials are what make a supplier compromise a long dwell time rather than a short one.

Attribution. When the supplier's account acts, can you tell which human at the supplier did it? Shared service accounts with a single key are common and make forensic reconstruction after an incident nearly impossible.

Reversibility. How long does it take to revoke everything a supplier holds, and have you ever tested it? An offboarding that requires three teams and a support ticket is an offboarding that will not happen at 2am on a Saturday when the supplier discloses a breach.

The questionnaire ceiling: what a SOC 2 report cannot tell you

A SOC 2 Type II report is a useful document, and it is routinely asked to carry weight it cannot bear. It states that an auditor examined controls a service organisation designed and operated over a period, against criteria the organisation and auditor agreed. That is a statement about process, sampled. It is not a statement that the supplier's integration into your environment is configured safely, because your configuration is not in their scope at all.

ISO 27001 certification has the same shape: it certifies a management system, not the security of a specific integration. Neither document answers the four questions that actually determine your exposure: what can this supplier reach, how would I know if they were compromised, how fast would they tell me, and what happens to my data when the relationship ends.

So use the paperwork for what it is - a filter that removes suppliers with no process at all - and replace the rest with evidence you can inspect.

• The access configuration itself, reviewed in your own tenant rather than described by the vendor: scopes granted, roles assigned, accounts that exist, MFA enforced on them.
• A written incident notification commitment with a number in it - hours, not "promptly" - and the name of the role that makes the call.
• The subprocessor list, and the commitment to tell you before it changes, since a fourth party is a supplier you did not assess.
• An exit test: what exactly do you get back, in what format, in what timeframe, and what is deleted. Ask for the deletion certificate format before you sign, not after you leave.
• Their last three post-incident reports in summary form, or an equivalent account of what broke and what changed. A supplier that has never had an incident is either young or not measuring.

The practical rule: certification tells you whether to start a conversation. Evidence of the access path tells you whether to finish it.

Testing the access path: what a supplier assessment does with hands on keyboards

Everything above can be done from a document and a console. The next level is a technical assessment of the supplier's integration with you, and it needs to be scoped carefully because you are testing, or asking to test, systems that are not yours.

Two lawful routes exist. The first is testing your own side of the integration: the endpoints you expose to the supplier, the tokens you issued, the roles you granted. That is your system, and it is in scope of your own security testing without involving the supplier at all. Most of the interesting findings live there - an integration endpoint that authenticates the token but never checks which tenant it belongs to, a support account whose token still works after the contract ended, an export job that writes to a bucket with public read.

The second is testing the supplier's system, and it requires written authorization from the supplier, not from you. A contract clause granting audit rights is not a penetration test authorization, and a supplier assessment performed against a vendor's production tenancy without a signed scope is unauthorized access regardless of intent. When a supplier will not permit testing - which is common - the substitute is evidence: their own test summaries, their bug bounty scope, and the parts of their surface you legitimately own, such as the integration configuration and the data flows out of your environment.

That list is deliberately short. It is also the list that a general-purpose penetration test of your own estate will not cover, because it lives in the seam between two organisations, and each side assumes the other is checking it.

Fourth parties: the suppliers your suppliers buy from

An assessment that stops at your direct suppliers covers a fraction of the chain. The supplier that processes your support tickets has a subprocessor for transcription; the transcription vendor uses a model provider; the model provider runs on a cloud you have never heard of; the cloud runs on hardware somebody else maintains. Each hop is a party whose compromise reaches your data, and none of them signed anything with you.

You cannot audit that chain. What you can do is make the first hop accountable for the rest.

• Require a written subprocessor list, with the obligation to notify you in advance of changes and a right to object. The list is not a security control by itself; it is what makes the change visible.
• Flow your obligations down. If you must notify a regulator within 72 hours of becoming aware of a breach, the supplier needs the same clock, plus an obligation to tell you without undue delay. A supplier with a 30-day notification window has made your regulatory deadline impossible to meet.
• Ask about concentration, not just names. Five subprocessors on the same cloud is one failure domain. The question that matters is which single dependency, if it went down or was compromised, would take several of your suppliers with it.
• Track it in the access map, not a separate register. A fourth party that can reach your data through a first party belongs on the same page as the first party, with the same four fields.

The concentration question is the one most programmes skip, and it is the one that MOVEit answered: thousands of organisations were exposed by one vulnerable product because their suppliers had all chosen the same file-transfer tool.

Deliverables: what to demand from an assessment and what to read first

Whether the work is done internally or commissioned, the output has a shape that separates a useful assessment from a document that will be filed and forgotten. Four artifacts do most of the work.

An access map with owners. Every mechanism in the scope, its privilege, its lifetime, who can use it and who is accountable for reviewing it. This is the artifact that survives the engagement; findings age, the map is the thing you keep updating.

Findings written as reachability, not category. A finding that says "insufficient logging" is a checkbox. A finding that says "the billing integration token is accepted by the reporting API of any tenant, and here is the request" is a decision. Each finding should state what an attacker with the supplier's foothold could reach, what evidence proves it, and what the fix costs.

What could not be tested. Every assessment has a boundary - a system the supplier would not open, a tenancy that cannot be cloned, an endpoint that could not be reached without breaking production. Stating those exclusions is not weakness; it is the difference between a report you can rely on and one that implies coverage it never had.

The retest criterion per finding. The same request now returning a refusal, or the credential now failing after revocation. A finding is closed when a test proves it, not when a ticket says fixed.

Read the report in the order of blast radius: tenant isolation and token audience first, then deprovisioning, then privilege, then detection. Anything that would let one supplier's compromise become several customers' breach is the first conversation, regardless of severity scores, because severity scores describe a single system rather than a chain.

Contract terms that survive an incident

Contracts are not security controls, but they determine how much of the response you control when something goes wrong. Six clauses do the heavy lifting, and most of them can be added to an existing agreement without renegotiating price.

Two details are worth insisting on because they are routinely missing. First, the notification clock must start when the supplier becomes aware, not when it finishes its investigation - a supplier that waits for root cause before calling you has already consumed your regulatory window. Second, the cooperation clause must name artifacts, because "reasonable assistance" produces a slide deck rather than the authentication logs you need.

Four regulatory clocks that now write the deadline for you

Supply chain security used to be a matter of judgement. In the EU and the US it is increasingly a matter of dates, and those dates determine what your contract clauses must achieve rather than the other way round.

NIS2, Directive (EU) 2022/2555, had to be transposed by 17 October 2024 and applies to essential and important entities across eighteen sectors. Its Article 21 risk-management measures explicitly include supply chain security - the security of relationships with direct suppliers and service providers - and its incident reporting duties create a 24-hour early warning and a 72-hour notification for significant incidents. For a company in scope, "we asked the vendor for a SOC 2" is not a supply chain measure. The regulator's question is what you did about the risk the supplier represents.

DORA, Regulation (EU) 2022/2554, applies from 17 January 2025 to financial entities and their ICT third-party providers. It is more prescriptive than NIS2 on exactly the point this article has been making: a register of information on contractual arrangements with ICT third-party providers, contractual requirements on audit and exit, concentration risk assessment, and - for entities designated by their competent authority - threat-led penetration testing of critical functions at least every three years.

The Cyber Resilience Act, Regulation (EU) 2024/2847, splits into two dates that matter. From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a corrective measure becoming available, submitted through ENISA's Single Reporting Platform. The broader product-security obligations, including vulnerability handling and the SBOM expectations that support it, apply from 11 December 2027. If you buy software that goes into the EU market, these are now questions you can ask with a legal basis: does the supplier have a reporting process, and can they meet a 24-hour clock.

In the United States, a public company must file a Form 8-K under Item 1.05 within four business days of determining that a cybersecurity incident is material - and the determination itself must be made without unreasonable delay. A supplier breach that touches material data triggers that clock from your side, which is why the supplier's notification window has to be measured in hours: you cannot make a four-business-day filing credible if you learn the facts on day thirty.

Notice what these instruments have in common. They do not require you to prevent every supplier compromise, because that is not achievable. They require you to know what your suppliers can reach, to have a contractual clock, and to be able to produce evidence on demand. A programme built around those three things satisfies most of the regulatory text as a side effect.

When the supplier is breached, not you: the first 72 hours

Response planning usually assumes the incident starts inside your perimeter. The supplier case inverts the sequence: you begin with partial information from a third party, a clock you did not start, and a strong incentive on their side to describe the incident narrowly.

Six decisions, in order, and each one has an owner who should be named before the event.

One: freeze the access, not the relationship. Revoke the supplier's credentials and tokens first, then work out the rest. The instinct to preserve functionality for a business-critical integration is what turns a supplier compromise into a long dwell time. If revocation breaks a critical process, that is a finding about the design, not a reason to wait.

Two: establish what the supplier's credentials could reach, from your side. Not what they say the credentials were - what your access map says they could reach. This is the moment the map earns its cost, and the moment a missing map costs days.

Three: preserve your own evidence before it rotates. Authentication logs, API access logs, database audit records, the integration's request history. Many platforms keep these for days, not months, and the supplier's incident may not be disclosed until after yours have expired. Export first, analyse later.

Four: decide the legal and regulatory position early. Whether the incident is notifiable, to whom, and by when. Under GDPR the 72-hour clock runs from awareness of a personal data breach, and awareness can arrive with the supplier's notice. Under NIS2 and DORA there are parallel clocks. Under SEC rules the materiality determination starts its own four business days. These are decisions for counsel, and they need facts, which is why steps two and three come first.

Five: get the timeline in writing, and keep asking for artifacts. Which systems, which credential, from when to when, what the attacker did with it, what logs exist. A supplier that cannot produce authentication logs for the window in question is telling you something important about its own maturity.

Six: assume the credential was used even if the evidence is incomplete. The failure mode in supplier incidents is a narrow disclosure - "one API key was exposed for six hours" - followed weeks later by a wider one. Rotating everything the supplier held, and reviewing what happened in the window rather than what the supplier says happened, is the cheaper error.

Metrics that predict the next incident rather than describe the last one

Vendor risk dashboards tend to measure activity: assessments completed, questionnaires returned, suppliers rated. Those numbers go up when the programme is working and also when it is not. Six measurements describe whether the exposure is actually smaller this quarter.

• Standing accounts held by suppliers. Count them, then count them again next quarter. The number should fall as integrations move to short-lived credentials. It is the single best proxy for blast radius.
• Median time from vendor advisory to patched or mitigated in your estate, for the components you actually run. A number in days, not a policy. If you cannot compute it, your SBOM is not being used.
• Coverage of the dependency inventory. The share of production systems whose dependency graph is generated automatically and reachable in one query. Anything below complete is a known blind spot, and the size of the gap is the interesting figure.
• Count of CI actions pinned to mutable references. Tags and floating versions in workflow files. This should trend to zero, because it is a one-line fix per action and a direct inheritance of someone else's compromise.
• Deprovisioning test results. The share of supplier offboardings where every credential was proven dead within the target window. A percentage you can only produce if you actually test.
• Hours from supplier notification to access frozen. Measured in drills, not assumed. This one number tells you whether the 72-hour regulatory response is feasible at all.

All six are computable from systems you already have, and none of them require a new product. That is not a coincidence: supply chain risk is mostly about configuration that nobody reviewed, and configuration is measurable.

First thirty days, cheapest first

Most organisations cannot start a twelve-month programme, and do not need to. Six steps in this order produce most of the available reduction in risk, and the first three cost nothing but attention.

Week one: draw the access map. Every supplier credential, agent, token and OAuth grant that touches production or customer data, with privilege, lifetime, attribution and owner. Expect it to be worse than assumed, especially in the proof-of-concept integrations nobody closed.

Week one: freeze what can be frozen. Revoke supplier accounts with no owner, expire OAuth grants nobody recognises, remove admin roles that were granted for an onboarding that finished years ago. This is a deletion exercise, and it is safe because unused access has no function.

Week two: pin the build. Commit lockfiles, pin CI actions to commit SHAs, and run the signature check your registry already supports in CI. Then look at which of your dependencies run install scripts and whether they need to.

Week two: list what runs in the browser. Turn on a report-only Content Security Policy and read the violations for a week. The list of third-party origins your pages actually load is usually longer than the list in anyone's head.

Week three: test deprovisioning on one supplier. Pick a low-risk integration, remove it through the ordinary admin path, and verify that every credential it held is dead. Whatever fails, fix, then repeat on the next supplier. This is the cheapest real test in the programme and the one that most often finds a live defect.

Week four: put a number in the contracts. Notification within a defined number of hours from awareness, subprocessor notice, cooperation artifacts. Where renegotiation is impossible, add it at renewal and record the exposure in the meantime.

Then repeat the measurement, not the project. A quarter in which standing supplier accounts fall, mutable CI references fall and deprovisioning tests pass is a quarter in which a supplier compromise would cost less than it would have three months earlier. That is what prevention means in practice: not the absence of incidents, but the shrinking of what one incident can reach.

Where an assessment fits, and where it does not

Commissioning work from outside makes sense in three situations: the access map is too political to draw internally because it names systems owned by four departments; the integration surface is large enough that testing it needs people who do it weekly; or a regulator, customer or board needs an independent artifact rather than a self-assessment.

What an external assessment cannot do is substitute for the two decisions only the owner can make: which access to keep, and which suppliers to remove. An authorized penetration test of the integration surface will tell you exactly what a supplier credential can reach; it will not revoke anything. A vulnerability assessment will tell you which components are out of date; it will not stop your CI from installing whatever the registry serves. Those remain internal choices, and they are the ones that change the number.

The honest summary for a buyer: supply chain security is not a vendor score. It is an inventory of access, a build you can prove, a contract with a clock in it, and a rehearsed hour in which you can turn a supplier off. Everything else is documentation.

On the device side of the same problem - third-party SDKs, WebView bridges and storage inside a shipped app - the mobile app penetration testing guide covers the tests that produce findings.