CON-CLS-007 — Supplier Security Clause Set

1. Why this clause set exists

A bought component becomes ACME's CRA obligation the moment it ships (SDL-POL-005 §1). ACME cannot discharge that obligation with effort alone: if the supplier does not tell us about a vulnerability, we cannot triage it; if the supplier stops patching in year four of a seven-year support period, we cannot update; if we hold no source and no escrow, we cannot fix it ourselves.

These clauses buy the three things that make a component supportable for its whole life in our products: notice, patches, and a fallback if the supplier disappears. They are commercial terms, not technical requirements — a supplier that meets every technical criterion in SDL-POL-005 §2 and refuses these clauses is still a component we cannot support.

2. When the clause set is mandatory

Purchasing does not sign a component contract without the PSL's written confirmation that the clause set is present or that a deviation has been accepted per §5.

3. The clauses

C1 — Vulnerability notification. The supplier notifies ACME of any vulnerability affecting the supplied component without undue delay, and in any case within 72 hours of the supplier becoming aware, whether the supplier discovered it, received it from a third party, or learned of it from public disclosure. Notification goes to security@acme-embedded.example and names the affected versions, the severity as assessed by the supplier, exploitation status if known, and the available mitigation. Silence during an embargo is not a permitted reason to delay notification to ACME.

C2 — Security patches for the agreed term. The supplier provides fixes or mitigations for vulnerabilities in the component for a contractually named term that ends no earlier than the declared support period of the ACME product plus 12 months (the margin ACME requires under SDL-POL-005 §2(1)). The term is written into the contract as an absolute date, not as a rolling commitment.

C3 — End-of-life notice. The supplier gives at least 24 months' written notice before ending maintenance, security support or availability of the component, and states what succeeds it. A shorter notice period is a breach, not a change of plan.

C4 — SBOM delivery. The supplier delivers a machine-readable SBOM (CycloneDX preferred, SPDX accepted) with every release, listing components and their transitive dependencies where technically feasible, each with a unique identifier (CPE, PURL or SWHID) and a hash. Where the component is delivered as a binary, the SBOM covers what is inside that binary — this is the only way the component enters ACME's own SBOM honestly.

C5 — Source availability or escrow. ACME must be able to patch the component itself if the supplier cannot or will not. Either the source is delivered with a licence permitting ACME to modify it for defect and vulnerability correction, or the source is placed in escrow with release conditions that include the supplier's insolvency, discontinuation of the component, and failure to meet C2 within the timelines of PSM-PROC-002 §3. Escrow is verified at deposit and re-verified annually — an escrow nobody has ever tested is a document, not a fallback.

C6 — Right to fix and to distribute the fix. ACME may develop a correction itself where C2 is not met in time, and may distribute it to its customers as part of an ACME firmware image, without additional licence fees. Where ACME develops such a fix, it offers it back to the supplier.

C7 — Disclosure cooperation. The supplier cooperates with coordinated disclosure: it accepts vulnerability reports from ACME, agrees a disclosure timeline, and does not prohibit ACME from publishing an advisory naming the affected component once a fix or mitigation is available to ACME's users. ACME's obligations under CRA Art. 14 are stated as overriding — no confidentiality term may prevent or delay a regulatory notification.

C8 — Flow-down to subcontractors. The supplier imposes C1 to C5 on its own suppliers for anything it integrates and passes on to ACME, and remains ACME's single point of contact for all of it.

C9 — Evidence on request. On reasonable request the supplier provides evidence of its vulnerability handling: the security contact, the advisory channel, and the fix history for the last three published CVEs — the same spot check SDL-POL-005 §2(2) requires before selection, repeatable during the relationship.

C10 — Remedies. Failure to meet C1, C2 or C3 entitles ACME to the escrow release under C5, to terminate for cause, and to recover the cost of the resulting unplanned component migration. The clause set survives termination for as long as the ACME products containing the component remain in their support period.

4. Negotiation notes

• C3 and C5 are the ones suppliers resist. C3 costs them roadmap freedom; C5 costs them nothing until it matters, so it is usually the easier of the two to win. Where only one can be obtained, C5 protects ACME further — a component we can patch ourselves survives a supplier who vanishes without notice.
• C1's 72 hours is a supplier obligation, not an ACME deadline. It exists so that ACME's own Art. 14 clock — which runs from our awareness — does not start unnecessarily late.
• A supplier offering "notification via our public advisory feed" has offered nothing: that is disclosure, not notice, and it arrives at the same time as it arrives for attackers.

5. Deviations

A deviation is a documented risk acceptance, signed by the PSL and the Managing Director, recorded against the component in /quality/components/registry.yaml and re-reviewed at every major release. It states which clause is missing, what compensating measure applies (self-maintenance capability, a pinned fork, a planned second source), and the date by which the gap is closed or the component is replaced.

6. Open cases

7. Records

Signed contracts, the PSL confirmation per §2, deviation approvals, escrow deposit and annual verification records, and supplier notifications received under C1. Retained for the support period of every product containing the component, plus 10 years.

Revision history