FOSS compliance check processCopy Anchor Link

A compliance check is the repeatable inspection you run against one release candidate to decide whether it may ship — and to produce the evidence that the decision was made properly. This page specifies the whole thing: the flow, the entry requirements, the activities, seventeen check tasks written step by step, the gates between them, and the work product each one emits.

Not legal advice. Licence obligations are contracts; sector duties are statutory. This page describes how compliance programmes are structured and checked — confirm scope, wording and timelines with counsel for your products and markets.

What a check isCopy Anchor Link

A check is not "run a scanner". A check is an inspection with a scope, a named decision, an owner, and an artefact. It answers four questions about one build: what components are in it, what licences apply, whether each use was approved, and what source is owed. Those are the same four branches as the audit question in the assurance framework; this page is the procedure that produces them.

Two properties make a check worth running. It is reproducible — a newcomer following the steps reaches the same conclusion — and it is evidential — every conclusion has a record that outlives the people who made it.

TriggersCopy Anchor Link

A delta check re-runs the full procedure but only on material that changed since a named baseline build — with the baseline's serial number recorded. A delta is cheaper; it is also where programmes hide drift, so re-run a full check at least once per release train.

Process diagramCopy Anchor Link

(Figure 1 in the HTML version: seven phases in a column — 1 Initiate & scope, 2 Inventory, 3 Identify & triage, 4 Obligation & decision, 5 Fulfil, 6 Verify & gate, 7 Publish & retain — with entry inputs on the left, work products on the right, four blocking gates on the connectors (G1 after phase 2, G2 after phase 4, G3 after phase 5, G4 after phase 6), and a feedback loop from phase 7 back to phase 1 carrying the assurance loop: a recurring finding changes the policy, matrix or toolchain, not just this build.)

A failed gate returns the build to the phase that produced the finding, not to the start.

Workflow & rolesCopy Anchor Link

The flow runs in time order but is not strictly sequential: phases 2 and 3 iterate as new material is discovered, and phase 5 is redone after the final build. What makes it a workflow rather than a checklist is that each phase has an entry condition, an exit condition, and exactly one accountable owner.

RolesCopy Anchor Link

RACICopy Anchor Link

R does the work · A accountable, one per row · C consulted · I informed. Two A's in a row means the process will stall at the gate — the most common structural defect in a compliance programme.

RequirementsCopy Anchor Link

These are preconditions. Running a check without them produces output that looks like evidence and is not: an SBOM nobody can tie to an artefact, an approval by someone with no authority, a notice set assembled for a build that no longer exists. Each requirement has a test.

R1–R4 and R9–R11 map to the expectations of ISO/IEC 5230 (OpenChain licence compliance) and ISO/IEC 18974 (OpenChain security assurance); R5–R8 are what make the NTIA minimum elements and the CRA technical documentation duty answerable.

ActivitiesCopy Anchor Link

A1 · Initiate & scopeCopy Anchor Link

• Record the trigger, product, version, build ID, date and requester.
• Declare the material boundary: repositories and commit SHAs, build outputs, container images and base layers, firmware partitions, installer, OTA payload, documentation, models and datasets.
• Classify every item: in scope, out of scope with a reason (for example build-time-only tooling), or unknown.
• Choose full or delta; for delta, name the baseline build and the diff basis.
• Instantiate the check plan — which tasks run, sample sizes, who reviews, when the gates sit.
• Freeze the scope. Material added after freeze restarts phase 2 for that subtree.

A2 · InventoryCopy Anchor Link

• Collect declared material: intake records, manifests, lockfiles, recipe files, kernel and BSP configuration.
• Scan each material type with the appropriate tool — package manifests, binaries, container layers, firmware images — plus snippet analysis where vendoring is suspected.
• Generate the SBOM in the pinned format and spec version; merge declared with discovered; de-duplicate by purl + version; keep provenance for every entry (which tool, which file, which evidence).
• Validate against the schema; write the completeness assertion naming what is covered and what is not.
• Reconcile in both directions: discovered-but-undeclared, and declared-but-not-found.

A3 · Identify & triageCopy Anchor Link

• Determine each component's declared licence from the SPDX identifier in its own metadata or headers, the LICENSE file in the artefact, and upstream at the exact commit — in that order, recording the evidence.
• Resolve conflicts with a written precedence rule; escalate what cannot be resolved.
• Run the triage playbook on unknown, dual, custom and deprecated licences; contact upstream where it will actually answer; treat unresolved as deny by default.
• Analyse snippets, vendored directories and applied patches — patches carry the upstream licence and are a modification.
• Check non-code material: fonts, icons, datasets, model weights, documentation assets.
• Cross-check components against vulnerability sources and open VEX-relevant findings.
• Verify any supplier delivery against the contract and reconcile it with your own scan.

A4 · Obligation & decisionCopy Anchor Link

• Establish use context per component from build evidence, not assumption: link type, modification, distribution model, network interaction, user-product status, patent exposure.
• Apply the matrix to each (licence, use) pair and derive obligations: attribution, notice preservation, source disclosure and its scope, installation information, patent notices, trademark limits, reciprocity boundary, network source offer.
• Determine copyleft scope — what counts as a derivative or a modification — with counsel on boundary cases.
• Check compatibility where licences combine into one work.
• Merge into a release obligation set, keeping traceability back to components, and route exceptions.
• Record approvals against the (component, version, use) triple, citing the matrix version in force.

A5 · FulfilCopy Anchor Link

• Collect verbatim licence texts for every licence in the release, including transitive ones.
• Take copyright lines from the actual files rather than a template; include modification notices, patent notices and required warranty disclaimers.
• Render the notice set exactly as it will ship — same encoding, same path, same UI surface.
• Build the complete corresponding source package from the exact build inputs: sources, build scripts, configuration, patches, and licence files.
• Where a written offer is used instead, verify its text, delivery mechanism and validity window, and that it travels with the product.
• Re-assemble after the final build. Notices produced before the final build describe an artefact that no longer exists.

A6 · Verify & gateCopy Anchor Link

• Rescan the shipped artefact and diff against the pre-build SBOM; every difference gets an explanation.
• Run SBOM quality checks: NTIA seven elements non-empty, spec version stated, serial number unique, author/tool/timestamp present, completeness assertion, sharing classification, signature or attestation if required.
• Verify fulfilment inside the artefact: notice files present and correct, source archive hash recorded, offer text present.
• Confirm no component in the image is missing from the SBOM, and none that was removed still ships.
• Apply the gate criteria and record the decision: ship, ship with conditions (owner and due date), or block.

A7 · Publish & retainCopy Anchor Link

• Publish the SBOM and notice set through the required channel — customer portal, authority, in-product — and record what was published, to whom, and when.
• Assemble the evidence pack, index it by build ID and serial number, and store it under change control with the retention rule applied.
• Record the release decision and its signatories.
• Route recurring findings to the owners of policy, matrix and toolchain; set re-check triggers for CVEs, relicensing, abandonment and OTA.

Anatomy of a check taskCopy Anchor Link

(Figure 2 in the HTML version: the six-field check-task card — purpose, entry input, numbered steps, exit criteria, work product, owner/gate — under the rule "one task = one decision = one artefact".)

A task that leaves no record did not happen — that is the only test that matters.

The check tasksCopy Anchor Link

Seventeen tasks. Not every release needs all of them, but every release needs a recorded decision about each one — "not applicable, because …" counts, and is itself evidence.

CT-01 · Scope declaration and material boundaryCopy Anchor Link

• Purpose — define precisely what is being checked before anything is scanned, so completeness can later be asserted rather than hoped for.
• Entry input — release plan, build ID, repository and image list, supplier delivery list.
• Steps
  1. Record trigger, product, version, build ID, date and requester.
  2. Enumerate release material: source repos with commit SHAs, build outputs, container images and base layers, firmware partitions, installer, OTA payload, documentation, models, weights, datasets.
  3. Mark each item in scope, out of scope with a stated reason, or unknown.
  4. Declare full or delta; for delta, name the baseline build and the diff basis.
  5. Instantiate the check plan: which CTs run, sample sizes, reviewers, gate dates.
  6. Obtain the release owner's signature and freeze the scope.
• Exit criteria — every material item classified; zero "unknown"; scope signed and frozen.
• Work product — WP-01 scope declaration. Owner — OSC lead.

CT-02 · Build identity and artefact bindingCopy Anchor Link

• Purpose — prove that this check applies to the artefact you actually ship, and to nothing else.
• Entry input — build system output, registry digests, commit SHAs, SBOM serial number.
• Steps
  1. Bind build ID to commit SHAs and to the artefact hash set (image digest, firmware checksum, package hashes).
  2. Issue one SBOM serial number for this build and confirm it has never been used before.
  3. Confirm artefact immutability — signed tag or registry digest, no mutable latest.
  4. Record toolchain and base-image digests so the build can be reasoned about later.
  5. Store the binding with the release, not with the pipeline log.
• Exit criteria — one build → one serial number → one hash set; no reuse, no mutable references.
• Work product — WP-02 build identity record. Owner — release engineering (G1).

CT-03 · Bill-of-materials completenessCopy Anchor Link

• Purpose — produce an inventory of the release you can defend, including the parts that never appear in a manifest.
• Entry input — frozen scope; declared material; pinned scanners.
• Steps
  1. Collect declared material from intake records, manifests, lockfiles and build recipes.
  2. Run the appropriate scanner per material type: manifests, binaries, container layers, firmware images.
  3. Merge declared and discovered; de-duplicate by purl + version; retain provenance per entry.
  4. Reconcile both directions — discovered but undeclared, and declared but not found.
  5. Validate the SBOM against the schema for the declared spec version.
  6. Write the completeness assertion: what is covered, what is not, and why.
• Exit criteria — SBOM validates; every entry has provenance; unexplained deltas = 0; completeness asserted (G1).
• Work products — WP-03 SBOM (per build), WP-04 raw scan output, WP-05 completeness assertion. Owner — release engineering with OSC.

CT-04 · Licence identification per componentCopy Anchor Link

• Purpose — establish, with evidence, the licence of every component: a conclusion, not a guess.
• Entry input — SBOM; access to the artefact contents; upstream repositories.
• Steps
  1. Prefer the SPDX-License-Identifier declared in the component's own metadata or file headers.
  2. Verify it against the licence file actually shipped in the artefact.
  3. Verify it against upstream at the exact commit; record the commit.
  4. Normalise to an SPDX expression, handling WITH, OR, AND and + correctly.
  5. Record the evidence for each conclusion: file path, hash, and the text relied upon.
  6. Flag deprecated, custom and non-standard identifiers for triage in CT-05.
• Exit criteria — every component has an SPDX expression plus evidence, or is an open triage item with an owner and a date.
• Work product — WP-06 licence inventory and findings. Owner — OSC analyst (feeds G2).

CT-05 · Conflict, dual-licence and unknown triageCopy Anchor Link

• Purpose — resolve the cases where sources disagree or no licence can be found, which is where most real risk hides.
• Entry input — licence inventory; triage playbook; upstream contact channel.
• Steps
  1. Apply the precedence rule: licence file in the artefact > upstream at the pinned commit > package metadata.
  2. For dual or multi-licensing, record which option you elect and why it is available to you.
  3. For unknown or custom terms, run the playbook: search upstream, check README and COPYING, check relicensing history, contact the maintainer.
  4. Treat still-unresolved material as deny by default and route it to replacement, removal or legal opinion.
  5. Record decision, evidence, date, and a re-check trigger if upstream may still answer.
• Exit criteria — no component in the release has an undetermined licence at gate time; accepted residual risk is signed by the accountable owner and counsel.
• Work product — WP-07 triage decision log. Owner — OSC lead with legal (G2).

CT-06 · Snippet, vendoring and patch provenanceCopy Anchor Link

• Purpose — catch material that never appears in a manifest: copied code, vendored trees, patches, fonts, weights, datasets.
• Entry input — first-party source tree, vendored directories, patch queues, CI images, asset directories.
• Steps
  1. Run snippet and pattern analysis over first-party source; triage matches by size, licence and context.
  2. Inspect vendored and third-party directories, including subtree merges and generated code.
  3. Inventory patches applied to kernel, BSP or upstream trees — a patch carries the upstream licence and is a modification.
  4. Inspect build scripts, CI images and base container layers for components nobody declared.
  5. Check non-code assets: fonts, icons, datasets, model weights, documentation with its own licence terms.
  6. Note any outbound obligation you have accepted, for example contribution terms for code you ship upstream.
• Exit criteria — every snippet, vendored tree and patch has an origin and a licence conclusion, or an open item with owner and date.
• Work products — WP-08 provenance and snippet findings, WP-09 patch inventory. Owner — OSC analyst with the component owner (G2).

CT-07 · Use-context determinationCopy Anchor Link

• Purpose — establish how each component is actually used, because obligations depend on the use, not the package.
• Entry input — build outputs, linker results, ELF dependency lists, container layers, firmware images, deployment model.
• Steps
  1. For each component record: link type (static, dynamic, separate process, remote call), modified or not, distributed or internal or service-only, network-interactive, part of a user product, inside a signed-boot device.
  2. Confirm each answer against build evidence — linker output, dependency lists, image contents — not assumption.
  3. Record patent and trademark exposure where relevant to the decision.
  4. Attach approvals to the use: the same library may be fine in a test tool and unacceptable statically linked into a shipped module.
  5. Re-determine context after any version bump, link change or relicensing.
• Exit criteria — every component has a use record backed by build evidence; no use is inferred.
• Work product — WP-10 use-context register. Owner — component owner with OSC (G2).

CT-08 · Obligation derivation and compatibilityCopy Anchor Link

• Purpose — turn licences and uses into one concrete, traceable list of what this release must do.
• Entry input — licence inventory, use-context register, licence matrix, counsel's standing interpretations.
• Steps
  1. Apply the matrix to each (licence, use) pair and derive the obligation list.
  2. Enumerate obligations explicitly: attribution, notice preservation, source disclosure and its scope, installation information for user products, patent notices, trademark limits, reciprocity boundary, network source offer.
  3. Determine copyleft scope — what counts as a derivative or a modification — and take counsel's view on boundary cases.
  4. Check compatibility where licences combine into one work; resolve or remove the combination.
  5. Merge into a release obligation set, keeping traceability to components and clauses.
  6. Route anything the matrix does not cover to an exception with a written opinion.
• Exit criteria — complete obligation set; each obligation traceable to at least one component and one licence term; exceptions enumerated (G2).
• Work product — WP-11 obligation matrix instance for this release. Owner — OSC lead with legal (G2).

CT-09 · Approval decision recordsCopy Anchor Link

• Purpose — prove that each use was authorised, by someone with authority, before it shipped.
• Entry input — obligation set; policy and matrix version in force; intake records.
• Steps
  1. Confirm every (component, version, use) triple has an approval record citing the matrix version.
  2. Confirm the approver's authority matches the policy — who may approve conditional uses, who must approve exceptions to a deny entry.
  3. Confirm approvals were raised before the code shipped; flag retroactive approvals as findings.
  4. Confirm conditional approvals carry a condition, an owner and a due date.
  5. Re-approve after any material change: version bump, link-type change, relicensing, new use.
• Exit criteria — 100% coverage; zero retroactive approvals; every exception dated and expiring.
• Work product — WP-12 approval register. Owner — OSC lead (G2).

CT-10 · Notice and attribution correctnessCopy Anchor Link

• Purpose — ship attribution that is complete, verbatim, and actually present where a user can see it.
• Entry input — obligation set; licence texts; copyright lines from the shipped files; the final artefact.
• Steps
  1. Collect full verbatim licence texts for every licence in the release, transitive ones included.
  2. Take copyright lines from the actual files — not from a template or a previous release.
  3. Include required statements: modification notices, patent notices, warranty disclaimers, your own NOTICE content.
  4. Render the notice set exactly as it ships: same encoding, same path, same UI surface.
  5. Verify in the shipped artefact — mount the image, open the UI — not in the build directory.
  6. Check the in-product credits surface where the licence or a contract requires one.
• Exit criteria — notice set verified present and correct in the final artefact; diff against the obligation set is zero (G3).
• Work products — WP-13 notice set (THIRD-PARTY-NOTICES), WP-14 fulfilment verification evidence. Owner — OSC analyst with release engineering (G3).

CT-11 · Source disclosure and written offerCopy Anchor Link

• Purpose — satisfy source-disclosure obligations with a package a recipient could actually use.
• Entry input — obligation set; exact build inputs; archive builder; offer template; hosting location.
• Steps
  1. Determine which components require disclosure and the exact scope: modified files, the whole work, or complete corresponding source.
  2. Build the package from the exact build inputs — sources, build scripts, configuration, patches, kernel or BSP configuration where relevant.
  3. Include licence files and the instructions needed to rebuild.
  4. Verify the archive: file list against the obligation, hashes recorded, a sample rebuild attempted where feasible.
  5. If a written offer is used, verify its text, delivery mechanism and validity window, and that it travels with the product.
  6. Record where it is hosted, who can serve it, and for how long it must remain available.
• Exit criteria — archive or offer exists for every disclosure obligation, verified against the shipped build, hash recorded, retention set.
• Work products — WP-15 source archive and manifest, WP-16 written offer record. Owner — release engineering with OSC (G3).

CT-12 · SBOM quality gateCopy Anchor Link

• Purpose — ensure the SBOM you publish survives a competent reader: regulator, customer or auditor.
• Entry input — SBOM; declared spec version; schema; sharing policy.
• Steps
  1. Validate against the schema for the declared spec version — CycloneDX 1.7 or SPDX 3.0.1, stated explicitly in the document.
  2. Check the seven NTIA minimum elements are present and non-empty for every component.
  3. Check the serial number is a unique URN UUID and has not been reused.
  4. Check author, tool and timestamp; confirm the SBOM was generated from the final artefact.
  5. Check the completeness assertion and the sharing classification (for example a TLP marking) are present.
  6. Check signature or attestation where a customer or regime requires it — CycloneDX CDXA or SPDX signing.
  7. Record any accepted deviation rather than silently passing it.
• Exit criteria — all checks pass, or each failure is recorded as an accepted deviation with an owner (G4).
• Work product — WP-17 SBOM validation report. Owner — release engineering (G4).

CT-13 · Final-artefact reconciliationCopy Anchor Link

• Purpose — close the gap between what you analysed and what you are about to ship.
• Entry input — shipped artefact; pre-build SBOM; build identity record.
• Steps
  1. Rescan the shipped artefact with the same pinned toolchain.
  2. Diff against the pre-build SBOM and explain every addition, removal and version change — stripped build-time dependencies, resolved static linking, generated files.
  3. Confirm no component present in the image is missing from the SBOM.
  4. Confirm no component that was removed or replaced still ships.
  5. Record the reconciliation with the build ID and the signer.
• Exit criteria — zero unexplained differences; reconciliation signed (G4).
• Work product — WP-18 final-artefact reconciliation report. Owner — OSC analyst with release engineering (G4).

CT-14 · Vulnerability and VEX cross-checkCopy Anchor Link

• Purpose — separate "contains a vulnerable library" from "is vulnerable here", and record the difference in a publishable form.
• Entry input — SBOM with purl or CPE identifiers; advisory sources; product architecture; patch policy.
• Steps
  1. Match components to advisories using purl or CPE; record the match basis.
  2. Remove false positives with version and version-range analysis.
  3. For each remaining candidate determine reachability and exploitability in this product, and set a VEX status: affected, not affected, under investigation, or fixed.
  4. Reconcile against the patch SLA and any reporting duty that applies to your market.
  5. Publish the VEX alongside the SBOM and reference it from the release record.
• Exit criteria — every open candidate above threshold has a status, an owner and a date; VEX published with the release.
• Work product — WP-19 VEX document. Owner — security with OSC (G4 and sustainment).

CT-15 · Supplier deliverable verificationCopy Anchor Link

• Purpose — decide whether what a supplier told you can be the basis of your own release gate.
• Entry input — supplier delivery; contract schedule or Cybersecurity Interface Agreement; previous delivery for diffing.
• Steps
  1. Check the delivery against the schedule: format, spec version, contents, cadence.
  2. Validate it, then diff against the previous delivery and investigate every delta.
  3. Rescan the delivered artefact independently and reconcile with the supplier's SBOM.
  4. Check that notices, source archive or offer, and approvals are present and coherent.
  5. Check flow-down evidence to sub-suppliers where the contract gives you the right to ask.
  6. Raise nonconformances against the acceptance criteria and track to closure.
• Exit criteria — acceptance recorded, or a nonconformance is open with owner and date; unverified supplier data cannot support G4.
• Work product — WP-20 supplier acceptance and reconciliation report. Owner — supplier manager with OSC (G1 and G4).

CT-16 · Evidence pack, sign-off and retentionCopy Anchor Link

• Purpose — leave behind one pack that answers the audit question years later, without asking anyone who has left.
• Entry input — all work products from WP-01 to WP-20; the gate decision.
• Steps
  1. Assemble: scope, build identity, SBOM and validation, inventory, triage log, use register, obligation set, approvals, notice set, source records, VEX, reconciliation, gate decisions.
  2. Index the pack by build ID and serial number; state the retention period that applies.
  3. Record the release decision and its signatories, including any conditions.
  4. Store under change control with an access log; confirm the pack is complete and readable.
  5. Route recurring findings to the owners of policy, matrix and toolchain; set re-check triggers.
• Exit criteria — one pack per release that yields components, licences, approvals and source owed without human recollection.
• Work products — WP-21 compliance evidence pack, WP-22 assurance statement and sign-off. Owner — OSC lead (after G4).

CT-17 · Classification and publicationCopy Anchor Link

• Purpose — get the right artefacts to the right audience without leaking what should not leave.
• Entry input — SBOM, notice set, VEX, evidence pack; contractual and regulatory publication duties.
• Steps
  1. Classify each artefact: internal, customer, authority, or public; apply a TLP marking where it leaves the organisation.
  2. Confirm the channel matches the duty — customer portal, authority submission, in-product display, public download.
  3. Remove what should not leave: internal paths, unrelated internal identifiers, unreleased roadmap material. Do not redact licensing facts.
  4. Record what was published, in which version, to whom, and when.
  5. Re-publish whenever the artefact changes; keep version and date aligned with the build.
• Exit criteria — every published artefact is classified, versioned and recorded with recipient and date.
• Work product — WP-23 publication and classification record. Owner — OSC lead (after G4).

Gate criteriaCopy Anchor Link

A gate that can be argued with is not a gate. Each of the four is blocking: a failed gate returns the build to the phase that produced the finding, and the re-check is recorded as a new iteration rather than an edit of the old one.

Conditional passes are allowed exactly once per item, and only with a written condition, an owner, a due date, and a stated consequence if it slips. A conditional item with no date is a permanent exception wearing a temporary badge.

Work productsCopy Anchor Link

Retention. Support period plus the statutory tail. In practice that means the written-offer window that copyleft licences set, and — where the EU Cyber Resilience Act applies — the technical documentation retention period that runs for years after the product is placed on the market. Confirm the exact period with counsel; then write it on the pack so nobody has to guess later.

TraceabilityCopy Anchor Link

Common findingsCopy Anchor Link

Where checks fail

• Only package manifests are scanned — vendored code, patches and base images are invisible.
• The SBOM describes a source tree, not the shipped artefact.
• Approvals are recorded per package instead of per use.
• Notices are assembled before the final build and never regenerated.
• Source archives lack build scripts, configuration or patches.
• Triage items stay open at release with no owner and no date.
• Supplier data is accepted without an independent rescan.
• An OTA update ships without notices or a source offer.

What good looks like

• Every build has a serial number nobody else has ever used.
• A random pack from two years ago answers the four-branch question unaided.
• Merging a denied licence stops the build without negotiation.
• Triage conclusions are reproducible by a second analyst.
• Conditional approvals have dates, and they expire.
• Findings change the matrix more often than they change the build.
• Supplier deliveries are diffed, not just filed.
• Retention is written on the pack, not in someone's memory.

---

Compiled September 2026 from the NTIA minimum elements, ISO/IEC 5230 and 18974 (OpenChain), ISO/SAE 21434, UN R155/R156 and EU Regulation 2024/2847, plus published OEM and supplier practice. Requirements are described at the level a programme can implement — confirm obligations, wording and timelines with counsel. Nothing here is legal advice. See the assurance framework for the layered model this process serves, tooling for the pipeline, and the OEM & supplier playbook for the cross-boundary case.