Assurance Framework
Five layers of FOSS compliance assurance, cross-cutting evidence and feedback, the maturity ladder.
FOSS compliance assurance framework
Five layers, two cross-cutting mechanisms, one question. The framework is deliberately boring: every layer exists to answer a question an auditor will actually ask, and every layer has to emit one artefact under change control. A layer that produces no artefact is a belief, not a control.
Not legal advice. Licence obligations are contracts; sector duties are statutory. This page describes how assurance programmes are structured — confirm scope, dates and wording with counsel for your products and markets.
The five layers
(Figure 1 in the HTML version: the layered stack — an assurance statement at the top, five layers beneath it, and evidence/records plus the assurance loop as cross-cutting mechanisms.)
| Layer | Question it answers | Artefact it emits | Typical failure |
|---|---|---|---|
| 1 · Govern | Who is allowed to decide, and on what basis? | Policy, licence matrix, role assignments, published contact point | Policy exists, nobody owns it |
| 2 · Know | What is actually in this build? | SBOM per build, scan results, approval records per use | Inventory produced at release, not in CI |
| 3 · Control | Can an unapproved thing still ship? | Gate log, notice set, source archive or written offer | Gate advisory rather than blocking |
| 4 · Assure the chain | Is what we were told true? | Contract schedule, acceptance record, reconciliation report, flow-down evidence | Flow-down assumed, not contracted |
| 5 · Sustain | Is it still true a year from now? | VEX statements, patch records, per-campaign notice sets, audit reports | OTA treated as maintenance |
Layers are ordered by dependency: you cannot know what you have not scoped, and you cannot control what you have not inventoried.
1 · Govern
Scope and authority before tooling. Define what counts as open source for this programme — libraries, build scripts, kernel and BSP patches, fonts, icon sets, ML models and weights, datasets, and code pasted from a forum — and state that "no licence found" means "not approved". Name an owner with authority to say no, publish an external contact point for licence and security enquiries (required by both OpenChain standards), and write the licence matrix as allow / conditional / deny. Anchor the programme externally: ISO/IEC 5230 for licence compliance, ISO/IEC 18974 for security assurance.
2 · Know
Inventory with use-context. A developer declares the component, version and intended use; an automated scan runs in CI; triage resolves unknowns; a board decides; the decision is recorded against the part number or repository. Two properties matter: the SBOM is generated per build with a pinned format and spec version, and approval attaches to a use, not to a package — the same library is fine in a test tool and unacceptable statically linked into a safety-relevant module. See Tooling for the pipeline and the NTIA element mapping for what "complete" means.
3 · Control
Make the policy executable. A release gate that fails the build when an unapproved licence or unapproved use appears; a collector that assembles licence texts, NOTICE content and attribution exactly as they will ship; a source archive or written offer for every copyleft component; and change control so the SBOM's serial number identifies one artefact and one only. The test for this layer is blunt: can a developer merge something non-compliant by asking nicely? If yes, layer 3 does not exist.
4 · Assure the chain
Verification across the corporate boundary. Define the deliverable in the contract — format, spec version, contents, cadence — preferably in the Cybersecurity Interface Agreement that ISO/SAE 21434 already requires for distributed development. Apply written acceptance criteria, diff each delivery against the previous one, rescan the delivered artefact independently and reconcile, and require flow-down to sub-suppliers with evidence on request. See OEM & supplier playbook for the full treatment.
5 · Sustain
The layer most programmes discover late. Continuous vulnerability monitoring with VEX that separates "contains a vulnerable library" from "is exploitable here"; a contractual patch window; an upstream-abandonment trigger; treating every over-the-air update as a fresh distribution — notices and source offers ship with it; and internal plus external audit with records retained for the support period and the statutory tail.
The two cross-cutting mechanisms
Evidence & records. Every layer emits exactly one artefact that is versioned, dated and attributable. Artefacts live under change control, not in someone's home directory. Retention is the support period plus the statutory tail. Records must outlive the programme team — auditors ask for history, not the current build.
The assurance loop. Audit findings, scan deltas and supplier discrepancies feed back into policy. A recurring finding means the matrix or the gate is wrong, not that people are careless. Re-scan, re-baseline and re-approve after every material architecture change. A programme with no feedback path ossifies within about two release cycles.
The one question
The framework collapses to a single question an auditor under UN R155 — or any equivalent regime — will ask. It has four branches, and all four have to be answerable for any build you have ever shipped.
(Figure 2 in the HTML version: any shipped build → components, licences, approvals, source owed.)
If any branch is missing or has to be reconstructed from memory, the build is not assured.
Maturity ladder
Useful for self-assessment, and honest about the fact that most organisations sit at level two:
| Level | What it looks like | How to test it |
|---|---|---|
| Ad hoc | Someone runs a scanner when a customer asks. No policy, no owner, no retention. | Ask for the SBOM of a build from 18 months ago. |
| Documented | Policy and licence matrix exist; inventory produced near release; notices assembled by hand. | Ask for the approval record for one specific component in one specific build. |
| Enforced | SBOM in CI, blocking release gate, source archive automated, supplier deliverable contracted. | Try to merge a component with a denied licence and see whether the build stops. |
| Assured | Everything above, plus independent verification, VEX, audit findings feeding back into policy, and records retained for the statutory tail. | Pick a random serial number and reproduce all four branches without asking anyone. |
Where each piece lives in this wiki
- Govern — anatomy of an OEM policy, licence decision matrix, OpenChain and the standards
- Know — SPDX, CycloneDX, tooling and pipeline
- Control — licence obligations, applying and attributing
- Assure the chain — OEM & supplier playbook, supply-chain security
- Sustain — VEX, regulatory drivers
Compiled September 2026 from UNECE R155/R156, ISO/SAE 21434, the OpenChain Project standards (ISO/IEC 5230 and 18974), the NTIA minimum elements and published OEM sourcing practice. Regulatory facts are dated — verify before relying on them. Nothing here is legal advice.