Supply Chain complete

Control over software supply chain, dependencies, and third-party components

L0 Unaware

No visibility into software dependencies or third-party components; no SBOM exists and supply chain risks are unquantified

Criteria

SUPPLY-L0-C1 The organisation has no Software Bill of Materials (SBOM) and cannot enumerate its third-party dependencies

Evidence guidance

Ask the team to produce a complete list of third-party and transitive dependencies for any one production application. If no SBOM exists and the answer is a manual guess from memory or a partial reading of a manifest file, this criterion is met. A package manifest (package.json, requirements.txt, pom.xml) is not an SBOM: it names direct dependencies only and omits the transitive graph where most supply-chain risk lives.
SUPPLY-L0-C2 Dependencies are pulled directly from public registries at build time with no pinning, verification, or caching

Evidence guidance

Inspect the build configuration and lockfiles for one production service. If builds resolve packages from public registries (npm, PyPI, Maven Central) at build time with floating version ranges and no integrity hashes, this criterion is met. The presence of a lockfile with pinned versions and integrity digests, or a build that resolves from a controlled mirror, is evidence the organisation has moved beyond this level.

Indicators

Developers install packages from public registries without reviewing licences, maintainers, or known vulnerabilities
No process exists to evaluate the trustworthiness of a new dependency before adoption
When asked which open-source components ship in a given product, the organisation cannot answer without reading source by hand

Regulatory mappings

Regulation	Articles	Risk	Note
`NIS2`	art-21	high	Art 21(2)(d) requires supply-chain security measures, including managing the risks of direct suppliers. An organisation that cannot enumerate its dependencies has no basis on which to apply any such measure, so the requirement is unmet at the most basic level.
`DORA`	art-28	high	DORA Art 28 requires financial entities to maintain a register of ICT third-party arrangements and to manage the associated risk. Without a dependency inventory the software supply chain is absent from that register, leaving a material part of the third-party surface unrecorded.
`GDPR`	art-28	medium	Where a dependency processes personal data (an embedded library, an SDK that phones home), Art 28 obligations on processors and sub-processors attach to it. An organisation with no SBOM cannot identify which of its components carry those obligations.

Upgrade path

Generate SBOMs for all production applications, in SPDX or CycloneDX format, so the dependency graph including transitive packages becomes a recorded artefact. Introduce dependency pinning with integrity hashes, and begin scanning the resulting inventory for known vulnerabilities and incompatible licences.

Risk if stagnant

Without supply-chain visibility the organisation is exposed to dependency-confusion attacks, compromised upstream packages, and undisclosed vulnerabilities in transitive dependencies. A single poisoned dependency can compromise the entire production environment, and when an advisory lands for a widely used package the organisation cannot even tell whether it is affected.

L1 Dependent

Basic dependency tracking exists but relies entirely on provider-managed tools with no independent verification or policy enforcement

Criteria

SUPPLY-L1-C1 Dependencies are tracked through a provider-managed tool (e.g., GitHub Dependabot, Snyk) but the organisation has no independent SBOM generation

Evidence guidance

Ask how the dependency inventory is produced and where it lives. If the only source of truth is a provider tool's dashboard, and the organisation cannot export or regenerate an SBOM without that tool, this criterion is met. Confirm the dependency: ask the team to produce an SBOM with the provider tool switched off or unavailable. If they cannot, visibility is bound to the provider. A tool that happens to emit CycloneDX output still counts here if the organisation has no second, provider-independent means of generating the same inventory.
SUPPLY-L1-C2 Vulnerability alerts are received from the provider but there is no defined SLA for remediation or escalation

Evidence guidance

Request the remediation policy and the ticket history for the last several dependency advisories. If alerts arrive from the provider but no documented SLA governs how fast a critical or high-severity finding must be fixed, and no escalation path exists when one is missed, this criterion is met. A backlog of open advisories with no triage decisions recorded against them is corroborating evidence. The scope here is the absence of a governing process, not the patching itself.
SUPPLY-L1-C3 AI For each SaaS tool with embedded AI features, the organisation has recorded which underlying model and which model provider powers that feature

Evidence guidance

Request the AI feature inventory. For each AI-enabled SaaS tool in use, the inventory should name the model family and version where the vendor discloses it (e.g. GPT-4o behind a given Copilot capability, Claude 3.5 Sonnet behind a given assistant) and the legal entity operating the inference endpoint (OpenAI, Anthropic, the SaaS vendor's own model team, an Azure OpenAI deployment). An entry that lists only the SaaS vendor and a marketing name for the AI feature does not satisfy this criterion. Where the vendor refuses to disclose the model or provider, record that refusal explicitly so the gap is visible rather than hidden.

Indicators

Automated dependency alerts are enabled but frequently ignored or unactioned
The organisation cannot produce a complete SBOM independently of its tooling provider
An AI feature inventory names the model and the model-providing entity for each AI-enabled SaaS tool, with explicit notes where the vendor will not disclose

Regulatory mappings

Regulation	Articles	Risk	Note
`NIS2`	art-21	high	Art 21(2)(d) supply-chain risk management requires the entity to assess and manage the risk of its suppliers, not merely to receive alerts about them. Provider-tool dependency with no remediation SLA means findings are surfaced but not governed, and the AI sub-processor chain (a SaaS tool whose embedded AI is powered by an undisclosed third party) is a supplier dependency the organisation cannot yet risk-manage.
`DORA`	art-28	high	DORA Art 28 requires the financial entity to own its third-party ICT risk management and to maintain the register of arrangements. Relying on a provider tool for visibility, with no independent inventory and no remediation SLA, leaves that ownership delegated and the register incomplete on the software-component tier.
`GDPR`	art-28	medium	Art 28 obligations attach to processors and sub-processors. Where an AI-enabled SaaS tool routes data to an undisclosed model provider, that provider is an unrecorded link in the Art 28 chain. Recording the model and the model-providing entity is the minimum step toward mapping that chain.
`AI-ACT`	art-25	medium	Art 25 places obligations along the AI value chain, which only function if the deployer can identify the upstream provider behind a SaaS AI feature. An inventory that stops at the SaaS vendor name leaves the AI Act value-chain surface unmapped.

Upgrade path

Establish contractual requirements for supply chain transparency with all software vendors. Define remediation SLAs for critical and high-severity vulnerabilities. Begin generating provider-independent SBOMs as part of the CI/CD pipeline.

Risk if stagnant

Reliance on a single tool for supply chain visibility creates a false sense of security. If the tool misses a vulnerability or the provider discontinues the service, the organisation has no fallback. Unactioned alerts accumulate into a growing attack surface. Where AI features are in use without a recorded model identity, the supplier chain is materially longer than the contract suggests, and the organisation cannot answer a regulator asking which model processed which data.

L2 Contractual

Supply chain requirements are formalised through contracts with vendors and internal policies for dependency management

Criteria

SUPPLY-L2-C1 Contracts with software vendors require SBOM delivery in a standard format (SPDX or CycloneDX) and timely disclosure of known vulnerabilities

Evidence guidance

Review the supply-chain clauses in vendor contracts for critical software. The clause should name a machine-readable SBOM format (SPDX or CycloneDX), state when the SBOM is delivered (at onboarding and on each release), and oblige the vendor to disclose newly discovered vulnerabilities within a defined window. A contract that asks only for a security questionnaire, or that references SBOMs without a format or a delivery trigger, does not satisfy this criterion. Confirm at least one SBOM has actually been received under the clause rather than merely promised.
SUPPLY-L2-C2 Internal policy defines approved dependency sources, licence compatibility requirements, and vulnerability remediation SLAs

Evidence guidance

Request the dependency-management policy. It should name the approved sources from which dependencies may be drawn, the licences that are permitted and those that are prohibited, and the remediation SLAs for each vulnerability severity. A policy that states a general intent to manage dependencies without naming sources, licence rules, or time-bound SLAs does not satisfy this criterion. At this level the control is the existence and content of the policy; technical enforcement of it is assessed at Level 3.
SUPPLY-L2-C3 AI For SaaS tools with embedded AI features, contracts require advance written notice before the underlying model, model version, or model-providing entity is changed, with a defined notice period and the organisation's right to evaluate the change

Evidence guidance

Review the AI-specific clauses in each SaaS contract. The clause should name a minimum notice period (typically 30 to 90 days) before any model swap, version upgrade, or change of the underlying model provider takes effect for the tenant. Acceptable evidence includes a contractual right to a written change notice describing what changes (model family, version, provider), a defined evaluation window during which the organisation can assess impact, and a documented escalation path. A general 'service may be updated from time to time' clause does not satisfy this criterion. Where the SaaS vendor refuses such terms, document the refusal and the residual risk rather than treating silence as agreement.
SUPPLY-L2-C4 AI Where a SaaS vendor offers fine-tuning or customer-specific model adaptation, the contract requires disclosure of the training-data sources and licensing terms of the base model used as the starting point

Evidence guidance

Applies only to SaaS tools where the customer's data is used to fine-tune or otherwise adapt a model (vendor-managed fine-tunes, customer-specific embeddings backed by a vendor model, retrieval-augmented configurations that produce a customer model artefact). For each such tool, the contract or vendor documentation should describe the base model's training-data provenance at a useful level of detail (publicly disclosed corpora, vendor-curated datasets, third-party licensed data) and the licensing terms attached to outputs derived from that base. A clause that names only the customer's own fine-tune contribution and is silent on the base model's training data does not satisfy this criterion. Tools that do not offer fine-tuning are out of scope for this criterion and should be marked not applicable.
SUPPLY-L2-C5 Contracts with critical software vendors permit the organisation to obtain or reproduce the deployable artefact (source escrow, mirror rights, or a build-from-source entitlement) so that loss of the vendor does not strand the dependency

Evidence guidance

Identify the software vendors whose products the organisation cannot operate without, then review those contracts for an artefact-continuity provision: a source-code escrow agreement with defined release triggers (insolvency, end of support, licence termination), a right to mirror and continue running the delivered artefact, or an entitlement to build the product from source. For escrow, confirm a deposit actually exists and has been verified or refreshed on a defined cadence; an escrow clause under which nothing was ever deposited does not satisfy this criterion. A binary-only deposit without build instructions, or a clause that covers documentation but not the artefact itself, also fails. At this level the control is contractual; exercising it is not expected, but the trigger conditions and the mechanics of release should be specific enough to act on.

Indicators

SBOMs are received from vendors as part of software procurement and reviewed before deployment
Contracts for business-critical software include an artefact-continuity provision: source escrow with verified deposits, mirror rights, or a build-from-source entitlement
A dependency policy document exists and is enforced through CI/CD pipeline gates
AI clauses in SaaS contracts include a model-change notice period with a defined evaluation window for the tenant
For SaaS tools offering fine-tuning, the contract or vendor documentation describes the base model's training-data sources and the licensing terms attached to derived outputs

Regulatory mappings

Regulation	Articles	Risk	Note
`NIS2`	art-21	medium	Art 21(2)(d) supply-chain risk management is addressed contractually at this level: SBOM-delivery and vulnerability-disclosure clauses oblige suppliers to surface the information the entity needs. The control is on paper and relies on supplier compliance. A model swap by an AI sub-processor is a supplier change in everything but name, so a contractual notice obligation is the minimum measure consistent with the requirement.
`DORA`	art-28, art-29	medium	DORA Art 28(2) requires assessment of ICT third-party risk including planned material changes to the service, and Art 29 requires the entity to weigh the risks of long or complex subcontracting chains, particularly where a subcontractor sits in a third country. SBOM-delivery and model-change-notice clauses are the contractual instruments that make those subcontracting chains visible enough to assess.
`GDPR`	art-28	medium	Art 28 requires the controller to authorise sub-processors and to flow processing obligations down the chain. A contractual notice obligation before a model provider or sub-component changes is how the controller keeps its Art 28 sub-processor record accurate rather than discovering a substitution after the fact.
`AI-ACT`	art-10, art-25	medium	Art 10 governs the data used to train and adapt AI systems; the deployer cannot assess that data without the provider disclosing the base model's training corpus. Art 25 places obligations along the AI value chain that depend on contractual visibility into model changes; a notice-on-swap clause is the deployer's mechanism to keep its value-chain map current.

Upgrade path

Deploy a private package registry that mirrors approved dependencies. Implement automated SBOM generation and vulnerability scanning integrated into every build pipeline. Begin verifying package signatures and provenance attestations.

Risk if stagnant

Contractual requirements improve transparency but rely on vendor honesty and compliance. Without independent verification, the organisation cannot detect supply chain compromises that vendors themselves may not be aware of. A silent model swap by an AI sub-processor changes the behaviour, jurisdiction, and training surface of the service overnight without the tenant being notified, and a fine-tune built on an opaque base model carries forward whatever licensing risk the base model's training data introduces.

L3 Controlled

Full SBOM generation with automated vulnerability scanning, private package registries, and verified dependency provenance

Criteria

SUPPLY-L3-C1 All builds produce machine-readable SBOMs automatically, and a private package registry serves as the sole source for all production dependencies

Evidence guidance

Inspect the CI/CD pipeline configuration and the registry. Confirm that an SBOM is generated as a build step for every production artefact, without manual action, and that build environments resolve dependencies only from the private registry (Artifactory, Nexus, a self-hosted proxy) with public registries unreachable from the build network. A pipeline that generates an SBOM on request, or build nodes that can still reach npm or PyPI directly as a fallback, do not satisfy this criterion. Ask to see a recent build's SBOM artefact and the network policy that blocks direct public-registry access.
SUPPLY-L3-C2 Dependency signatures and provenance attestations (e.g., SLSA, Sigstore) are verified before any package enters the private registry

Evidence guidance

Request the registry ingestion policy and a log of verification outcomes. Confirm that signature and provenance checks (Sigstore/cosign signatures, SLSA provenance attestations) run before a package is admitted, and that a failed check blocks ingestion rather than warning and proceeding. A scanner that records provenance metadata for reporting but admits the package regardless does not satisfy this criterion. Look for at least one recorded instance where ingestion was actually blocked on a verification failure.
SUPPLY-L3-C3 AI For each AI model in production use, a current model card or equivalent provenance record documents the model's identity, version, training-data categories, intended use, known limitations, and the upstream provider's evaluation results

Evidence guidance

Request the model card library. For each model behind an in-production AI feature (vendor-hosted SaaS model, self-hosted model, fine-tune of a base model), the record should cover: model identity and version, the legal entity producing the model, training-data categories at the level the provider discloses (e.g. publicly disclosed corpora, licensed datasets, vendor-curated data), declared intended use and out-of-scope use, known limitations and bias evaluations, and version history with the date of the most recent change. Acceptable formats include the original Hugging Face model card, the provider's published model documentation (OpenAI system card, Anthropic model card, Microsoft Responsible AI transparency note), or an internally maintained record where the provider does not publish one. A marketing page describing the AI feature does not satisfy this criterion. Records older than the current model version in production are out of date and should be flagged as such.

Indicators

No production build can pull dependencies directly from public registries; all packages flow through the private registry
Provenance verification failures automatically block package ingestion with alerts to the security team
A model-card library is maintained, with one current record per model in production use; records lagging the production version are flagged for refresh

Regulatory mappings

Regulation	Articles	Risk	Note
`NIS2`	art-21	low	Art 21(2)(d) supply-chain risk management is met by technical enforcement rather than paper at this level: automated SBOM generation, a private registry as the sole dependency source, and provenance verification before ingestion are measures the entity controls and can demonstrate. The same discipline extends to the AI tier through verifiable model provenance for each model in production.
`DORA`	art-28, art-30	low	DORA Art 28 concentration-risk assessment and the Art 30 contractual provisions on monitoring and access to information both assume the entity holds documentation of the underlying components of a critical service. Automated SBOMs per build, verified provenance, and a current model card per model give the entity that evidence from infrastructure it controls rather than from a supplier attestation.
`AI-ACT`	art-13, art-25	low	Art 13 instructions for use and Art 25 value-chain responsibilities both assume the deployer holds documentation of the model in operation. Maintaining a current model-card library converts those obligations from paperwork commitments into an artefact a deployer or auditor can read.

Upgrade path

Audit the most critical dependencies at the source-code level rather than trusting upstream review alone. Maintain organisation-controlled forks or mirrors of the components the business cannot tolerate losing, so their continued availability does not depend on an upstream maintainer remaining active or willing. Extend cryptographic provenance to cover the full path from reviewed source to deployed artefact, targeting SLSA Level 3 or higher.

Risk if stagnant

Automated scanning and private registries significantly reduce supply chain risk, but the organisation still depends on upstream maintainers for critical open-source components. A key maintainer abandoning a project or introducing a backdoor remains a residual risk. For the AI tier, model cards depend on what the upstream provider chooses to disclose; opaque training data and undisclosed evaluation results remain residual risks even where the documentation surface is current.

L4 Autonomous

Fully audited sovereign supply chain with source-level review of critical dependencies, organisation-maintained forks of essential components, and end-to-end provenance guarantees

Criteria

SUPPLY-L4-C1 Critical dependencies are audited at the source-code level, and the organisation maintains forks or mirrors of essential open-source components

Evidence guidance

Ask for the list of components classified as critical and the audit records for them. Confirm that for each critical component the organisation holds a source-level review (not just a vulnerability scan) and maintains its own fork or mirror that a build can use even if the upstream project disappears. Verify the fork is real and current: ask when it was last synced and whether a build can be produced from it today without reaching upstream. A dependency the organisation depends on but neither reviews at source nor mirrors does not satisfy this criterion. The capability assessed here is custody and independent review, not participation in the upstream project.
SUPPLY-L4-C2 End-to-end supply chain provenance is cryptographically verifiable from source code to production deployment, meeting SLSA Level 3 or higher

Evidence guidance

Request a production artefact and walk its provenance chain. Confirm that signed provenance links the deployed artefact back through the build to the reviewed source commit, that the build platform meets SLSA Level 3 (hardened, with provenance generated by the platform rather than the build itself), and that deployment admission verifies the chain before running the artefact. Provenance metadata that is generated but never checked at deployment does not satisfy this criterion. A self-attestation by the build script, rather than provenance issued by an isolated build service, falls short of SLSA Level 3.

Indicators

The organisation maintains its own forks or mirrors of its most critical open-source dependencies and can build from them with no upstream access
Every production artefact carries a cryptographically signed provenance chain traceable to reviewed source code
Deployment admission refuses any artefact whose provenance chain does not verify against the expected source
A critical upstream project going dark would not interrupt the organisation's ability to build and ship

Regulatory mappings

Regulation	Articles	Risk	Note
`NIS2`	art-21	minimal	Art 21(2)(d) supply-chain risk management is met to its fullest extent when the entity reviews critical components at source, holds its own forks so availability does not depend on an upstream maintainer, and can verify provenance end to end. The residual supply-chain risk the requirement targets is reduced to what the organisation itself introduces.
`DORA`	art-28, art-29	minimal	DORA Art 28 third-party risk and the Art 29 concern with long subcontracting chains and non-substitutable providers are addressed structurally rather than contractually: maintained forks remove the substitutability problem for critical components, and source-level audit plus verifiable provenance let the entity monitor the contracted function from evidence it holds.
`CLOUD-ACT`	18-usc-2703	minimal	Holding source, builds, and mirrors of critical components in infrastructure the organisation controls means a foreign provider cannot, by withholding or being compelled over a hosted registry or repository, sever the organisation's access to the code it runs. The build path does not depend on a counterparty that could be ordered to act against it.
`AI-ACT`	art-25	minimal	Art 25 value-chain responsibilities are most defensible when the deployer holds reviewed, mirrored copies of the model and library components in the path and can verify the provenance of what it deploys, rather than relying on what an upstream provider continues to publish.

Risk if stagnant

Maintaining a sovereign supply chain is resource-intensive. Source-code audits and maintained forks require dedicated staff and sustained investment. Without that commitment, audit coverage degrades, forked components drift from upstream and accumulate unpatched vulnerabilities, and the provenance pipeline that gives the chain its guarantees can silently fall out of enforcement after a tooling change.