What a bank-grade AI vendor supply chain looks like (DORA angle)

Why the software supply chain is a DORA question¶

DORA was adopted on 14 December 2022 and has applied to EU financial entities since 17 January 2025. Its Chapter V, "Managing of ICT third-party risk", governs how a financial entity contracts for external technology. The definitions do the initial work. Article 3(19) defines an ICT third-party service provider as "an undertaking providing ICT services", a definition broad enough to cover essentially every AI vendor. Article 3(22) defines a critical or important function as one whose disruption, or whose discontinued, defective or failed performance, would materially impair the financial performance of the entity, the soundness or continuity of its services, or its continuing compliance with the conditions of its authorisation. An AI system that screens transactions, triages AML alerts, or gates payment release will frequently support such a function once the bank performs the documented self-assessment.

That classification raises the bar for the whole engagement. Article 28(4) requires the financial entity, before entering the contract, to identify and assess all relevant risks and to undertake all due diligence on the prospective provider. Article 28(5) permits contracting only with providers that comply with appropriate information security standards, and requires, for critical or important functions, due consideration of the provider’s use of the most up-to-date and highest quality information security standards. Article 30(3)(c) then obliges the contract itself, where critical or important functions are supported, to require the provider to have ICT security measures, tools and policies in line with the entity’s regulatory framework.

A compromised or unverifiable vendor build pipeline is a direct route to the harms those provisions target. If the vendor cannot state which exact artifact runs in production, the bank cannot answer its own change-management and patching duties under Article 9(4)(e) and (f) for the outsourced function, cannot scope a major incident report under Article 19 to the affected versions, and cannot honor the audit rights Article 30(3)(e) requires the contract to grant. Supply-chain evidence is therefore assessment material for the bank’s Article 28 file rather than vendor marketing.

Reproducible builds: the same source produces the same digest¶

A build is reproducible when an independent rebuild of the same source revision produces a bit-identical artifact, which for container images means the same image digest. Reproducibility converts "trust our pipeline" into a property anyone can test. If a rebuild from the published source produces the running digest, then nothing was injected between source review and production, and no unreviewed compiler flag, dependency drift, or manual patch sits inside the artifact.

The engineering behind it is specific and checkable. Build timestamps are pinned to the source revision rather than the wall clock, so two builds of the same commit embed the same times. The builder itself is pinned by digest, so the toolchain cannot drift silently. Layer timestamps are rewritten to the pinned value. Dependencies resolve from a lockfile, and the build rejects unpinned inputs. In KLA’s release pipeline, a reproducibility gate performs two clean rebuilds of each covered first-party service image with caches disabled and fails the release when the digests differ, and the release digest must equal the rebuilt digest before promotion.

For a DORA reviewer, reproducibility underpins the Article 28(6) audit right with something stronger than interview evidence: the audit can rerun the build. It also gives the Article 30(2)(a) service description real content, because "the software we provide" resolves to a digest instead of a version string a human typed.

• Evidence to request: the reproducibility check output for a recent release showing rebuild digest equals release digest.
• Evidence to request: the pipeline configuration proving pinned build timestamps, digest-pinned builders, and locked dependencies.
• Evidence to request: the scope statement: which images are covered by the reproducibility gate and what the plan is for the remainder.
• Red flag: a vendor that cannot name the digest currently running for their own service.

Signed images, verified where it counts: at admission¶

A signature on a container image binds the artifact to an identity. Sigstore’s Cosign has become the common tooling: the pipeline signs the image digest after build, and verification checks both the signature and the signer identity. Keyless signing strengthens the identity claim, because the certificate is issued against the CI system’s OIDC identity for a specific repository and workflow, so the signature asserts "built by this pipeline on this branch" rather than "signed by whoever held a key file".

Signing alone is decorative unless something refuses to run unsigned artifacts. The enforcement point that matters is cluster admission. A Kubernetes admission controller, Kyverno in KLA’s deployment, verifies the signature on every first-party image before the pod is admitted, resolves tags to immutable digests so what was verified is what runs, and fails closed in production: when the policy cannot be evaluated, the workload does not start. Rollout is staged, with audit-mode observation in development before enforcement in production namespaces.

This is the control a bank team should probe hardest, because it converts the whole signing story from process into physics. It also maps cleanly onto DORA language: Article 9(4)(e) requires documented change-management controls ensuring changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner, and admission-time verification is the "verified" step made mechanical. For the contract, it is a concrete Article 30(3)(c) security measure whose configuration an auditor can read.

The negative paths deserve equal attention. Ask what happens when verification fails, when the signature transparency log is unreachable, and when someone attempts to deploy an image built outside the sanctioned pipeline. A bank-grade answer shows a blocked admission event and an alert, and the vendor should be able to demonstrate the block on request. Alerting on the verification policy itself, so a silently disabled policy pages someone, closes the loop.

Provenance and SBOM: what it is and where it came from¶

Provenance is a signed attestation recording how an artifact was built: the source revision, the builder, the workflow, and the build parameters. The SLSA framework standardises the format and defines integrity levels for the pipeline that produces it. A software bill of materials (SBOM) lists the components inside the artifact in a machine-readable format such as SPDX or CycloneDX. Provenance answers "who built this from what"; the SBOM answers "what is inside it". A serious vendor generates both in the pipeline at build time, attaches them to the image, and signs them, so they share the artifact’s integrity guarantees instead of living in a wiki.

For the bank, the SBOM is what turns a vulnerability disclosure into a bounded question. When the next critical CVE lands in a common library, the bank can ask the vendor which deployed versions contain the affected component and expect an answer derived from the SBOMs of the running digests, within hours. That capability feeds the bank’s own Article 9(4)(f) patch and update policies for the outsourced function, and it feeds Article 19 incident reporting, where the report must scope which services and versions were affected. Provenance serves the Article 30(3)(e) monitoring right: an auditor holding the attestation can independently confirm the running artifact was built by the sanctioned pipeline from the stated revision.

Two follow-up questions separate practiced vendors from aspirational ones. First, coverage: are attestations produced for every release artifact or only the flagship image? Second, verification: does anything consume the attestations, or are they produced and never checked? Producing provenance that nothing verifies still has value for incident forensics, and a vendor who states that boundary honestly is more credible than one who implies checks that do not exist.

A controlled release path: no side doors¶

The remaining question is whether the controls above can be bypassed. A controlled release path means the route from merged source to production traffic is closed: every runtime image is referenced by immutable digest rather than mutable tag, the deployment state is declared in version-controlled configuration (GitOps) so cluster changes trace to reviewed commits, and the CI pipeline’s own dependencies, including third-party CI actions, are pinned to exact revisions so the build system cannot be altered upstream of the signature.

Digest pinning deserves its own check because it is where good pipelines quietly leak. A tag like v1.4 can be repointed at the registry after review; a digest cannot. KLA’s pipeline validates that runtime manifests reference images by digest and keeps the exception list empty; third-party images that must run in the cluster are mirrored, scanned, and signed under the same identity as first-party images so the admission policy holds for everything.

This is also where the human factor gets tested. Ask who can push directly to production, under what break-glass procedure, and what record a break-glass deployment leaves. Article 30(3)(b) requires the contract to carry notice and reporting obligations for developments that materially affect the provider’s ability to deliver; an emergency release outside the standard path is exactly such a development, and a bank-grade vendor can show the procedure, the approval trail it produces, and how the artifact still gets signed and verified even in the emergency case.

The buyer checklist: questions and what a good answer looks like¶

The table below is the lift-and-use asset. Put the questions in front of any AI vendor, record the answers in the Article 28(4) assessment file, and treat the "good answer" column as the scoring anchor. Every good answer shares one property: it points at an artifact or a demonstration rather than a policy PDF.

Reading the answers: scoring and contract follow-through¶

Scoring is straightforward. An answer backed by an artifact the bank can verify scores full marks. An answer describing a real control without independent evidence scores partial and generates an evidence request. An answer that redirects to a certification scores zero for this checklist: a SOC 2 report attests to the audit period and the controls in scope, and it rarely proves reproducibility, admission enforcement, or provenance for the specific artifact the bank will run. Certifications complement artifact-level evidence; they do not substitute for it.

Honest boundary statements should score up, and this cuts both ways. KLA publishes its own boundaries on the Trust Center, including which controls are enforced today and which are staged, because a vendor claiming a perfect pipeline is describing a pipeline nobody has inspected. Expect coverage gaps; judge whether the vendor knows where they are, monitors them, and sequences the closure.

Then move the results into the contract. Article 30(1) requires the full contract in one written document; Article 30(2)(b) requires the processing and storage locations with advance notice of changes; Article 30(3)(e) requires unrestricted access, inspection, and audit rights for critical or important functions. The supply-chain practices verified during due diligence become the concrete content of the Article 30(3)(c) security-measures clause, and the verification commands become the mechanism through which the bank exercises its monitoring rights without scheduling a vendor call. Article 28(8) requires exit strategies; reproducible builds and complete SBOMs materially reduce exit risk, because the bank knows exactly what it was running when it leaves.

For teams assessing KLA specifically: the standing supply-chain claims live on the Security page, the review pre-answers and subprocessor disclosures on the Trust Center, and the banking context in Solutions for financial services.