The Component Supplier Security Standard: Accept, Conditional, or Reject

This standard is for the engineering manager, technical founder, or sourcer who has to decide whether one commercial SDK, library, or embedded component is good enough to ship inside a product. It grades the supplier's SBOM, disclosure channel, patch record, VEX output, and support period against fixed pass lines. It ends in an Accept, Conditional, or Reject record that a second reviewer would reproduce and an auditor can follow, plus the contract clauses that close any conditional gaps.

What this standard decides, and what it does not

This standard decides one thing: whether one commercial component supplier, for the one release you plan to ship, meets a written security bar. It does not rate the vendor as a company, replace a code audit, or stand in for a full vendor-risk questionnaire.

Most of what is published on supplier due diligence falls into two kinds. One is the long questionnaire with no pass line. The other is the SBOM format explainer that stops at whether the file parses. Neither tells two reviewers when to say no. This standard does, and it uses three verdicts:

• Accept. Every criterion passes. Ship it and file the record.
• Conditional. Nothing fails, at least one criterion is Conditional, and every Conditional gap has a contract clause and a due date. Ship it under those clauses.
• Reject. Any criterion fails. Do not ship this release. The supplier can fix the gap and resubmit.

Under the Cyber Resilience Act (CRA), Article 13(5) is the legal hook. Commission guidance reads it as requiring the manufacturer to work out what the product needs from each component, then verify in a risk-based way that the component meets those needs. Verification can use specifications, security documentation, assurance documentation, or testing. A filled-in verdict record from this standard is one way to show that verification happened.

How to evaluate a vendor SBOM against the minimum elements

Parsing is not enough. Grade a vendor SBOM on four things: component hashes with a named algorithm, generation context, coverage of transitive components, and explicitly declared unknowns. Those four separate an SBOM that describes the binary you received from one that only describes the supplier's source tree.

The bar has moved. The original CISA minimum elements had 7 fields. The updated document, co-authored by CISA, NSA, FBI, BSI, ANSSI and others and revised after more than 90 public comments, has 23 elements in three groups: nine SBOM Metadata fields, eight Component Data fields, and six Practices and Processes. The new elements are:

• SBOM Author Signature
• Data Format Name and Version
• Generation Context, meaning the point in the software lifecycle where the SBOM was produced
• Tool Name and Version
• SBOM Version
• Component Hash Value and Algorithm
• Component License

Two older ideas changed shape. Depth was replaced by Coverage, which counts horizontal breadth as well as vertical breadth. Known Unknowns stopped being a data field and became a practice that runs through the SBOM lifecycle.

The four checks: what each proves and how it lies

• Hash value and algorithm. Proves the SBOM describes the artifact you actually hold. With a hash and a named algorithm, you can check the SBOM against the binary you received. It lies by absence: a parser reading package-lock.json, pom.xml, or requirements.txt never touches an executable artifact, so both hash fields come back unknown.
• Generation context. Proves when in the lifecycle the file was made. It lies because some validators accept any non-empty value, so a label can claim "build" on a file that has no hashes.
• Coverage. Proves that every component, transitive dependencies included, is listed. It lies through links: pointing to other SBOMs counts toward Coverage only if you can actually open every linked SBOM.
• Declared unknowns. Proves the supplier knows where its own gaps are. Missing data has three states: unknown, withheld or redacted, and not applicable. It lies through silence. An explicit NOASSERTION is honest, while a field that simply isn't there tells you nothing.

Which baseline to grade against

The baselines disagree, and that is why the rule above exists.

My default is the CISA minimum elements, because it sets the transitive-coverage floor. If your customers or regulators expect BSI TR-03183-2, add its format floor and say so in the record. One practical consequence: SPDX 2.3 has no place for generation context or signatures. An SPDX 2.3 file therefore cannot meet those elements however carefully it is filled in. Ask for SPDX 3.0.1 or CycloneDX 1.6.

Pass lines for the SBOM criteria

The hard-fail and soft-fail split below is my own rule, derived from what each field can prove. It is not a published regulatory threshold. Hard fails are a schema failure, missing hashes in an SBOM that claims to be post-build, and missing transitive coverage. Explicit unknown markers are soft fails, graded Conditional.

How to grade disclosure, patch record, VEX, and support period

You can check all four of these from outside, using public evidence, in a few hours and without the supplier's help. Together they answer the question the SBOM cannot: once a vulnerability turns up in this component, how fast and how visibly will the supplier deal with it, and for how long?

Disclosure channel

Start with security.txt, the file defined by RFC 9116 that tells researchers where to report a vulnerability. Contact and Expires are its only mandatory fields, and a file without Expires fails RFC 9116. The RFC itself warns that having no security.txt may be better than having one with stale information. An optional CSAF field can link to a provider-metadata.json file so that advisories can be found automatically. CSAF is a machine-readable advisory format.

A valid file only proves the file is valid. A common failure is a contact address nobody reads. So send a test message and log whether a person replies.

If the listed contact bounces or goes quiet, you still need to find out who owns product security at the supplier, both to grade the channel fairly and to know who signs the notification clause later. Refolk handles that search in plain English, across public profiles and the open web, without you building a boolean string.

Advisories, CVE IDs, and VEX

VEX (Vulnerability Exploitability eXchange) is a statement of whether a known vulnerability actually affects a given product. OWASP suggests that a supplier either become a CVE Numbering Authority (CNA) or work with one, so that fixed vulnerabilities get CVE IDs and published CSAF or VEX advisories. Check for three things:

1. Do fixed vulnerabilities carry CVE IDs?
2. Are advisories published in CSAF or as VEX statements?
3. Does the advisory feed resolve, and does it cover the release you are shipping?

There are two limits. First, I could not confirm from a primary source how CNA scope or exploited-vulnerability catalogue listings mislead, so do not treat CNA status by itself as proof of quality. Grade the advisories, not the listing. Second, a supplier with no advisories at all is ambiguous: it may have had no vulnerabilities, or it may not disclose them. If its SBOM lists components that you know have had public CVEs and there is no supplier statement about them, grade Fail.

Patch record

To measure patch lag, take the date each vulnerability was reported or disclosed and the date the fixed release shipped, and compute the days between them. The best public benchmark comes from Project Zero's fix-time metrics:

The average across all vendors in that window was 61 days, and vendors exceeded the deadline plus grace period about 5% of the time. The caveat matters: Project Zero is a reporter vendors fear, because public disclosure is a real threat. Its numbers probably understate how long a typical supplier takes. Use them to set the line, then measure this supplier's own advisories. I found no public benchmark for the gap between CVE reservation and disclosure, so do not grade it.

My line, derived from Project Zero's 90-day deadline and 14-day grace period rather than from any regulation:

• Pass: median lag of 90 days or less across the sample.
• Conditional: median lag of 91 to 104 days.
• Fail: median lag over 104 days.
• Cap: any single advisory over 104 days caps the grade at Conditional, even if the median passes.

Support period

CRA Article 13(8) requires a support period that reflects expected use, of at least five years unless the product is expected to be used for less. The guidance says five years is not the default for every product. The clock starts when the product is placed on the market, not when a customer buys it. Every security update issued during the support period must stay available for at least ten years.

Manufacturers may take into account the support horizons of third-party components that provide core functions. The guidance gives an example: if a chipset vendor ends support in year four of a seven-year period, you need a plan or a different component. No public source sets a specific gap that counts as a fail. My rule, derived from that example, is that a supplier end date earlier than your product's declared end date is a Fail for a core-function component.

How to run the component supplier review, step by step

Run the eight steps in order, and decide what you need from the component before you collect anything. Commission guidance puts determining needs first. Some compliance checklists put component vetting last, after the SBOM work. I follow the guidance, because the core-function judgment in step 1 changes how step 7 is graded.

Plan for half a day to a day of effort in total, plus legal review. Steps 3 and 4 need someone who can read raw SBOM fields. sbom-tools ships a CISA minimum-elements profile. In that profile, a creator list that names only a tool does not satisfy SBOM Author, and silently omitting a license fails where an explicit NOASSERTION passes. The CVD Portal browser validator reports BSI and CISA results side by side, which shows you the baseline split described above.

Who should run the review

Pair an engineer who can read raw SBOM fields and recompute hashes with the engineering manager who owns the verdict. In some markets that engineer is hard to find, and the shortage decides how fast you can clear a supplier.

The mix of people differs by market, not just the count:

These figures come from Refolk's index, from a sample of 25 profiles per market. Germany leans toward manager titles, and one employer accounts for 20% of the sample. That suggests fewer people there are available for hands-on review. The German sample also contains the title "Cyber Resilience Act Compliance Manager", a sign that some teams staff CRA work as a dedicated role. If you need a reviewer and have no one in house, a Refolk search such as "Engineers who maintain CycloneDX or SPDX tooling on GitHub, based in Europe" surfaces people whose public work shows they read these files for a living.

How the review goes wrong: false passes and misreads

Most bad verdicts come from trusting a summary instead of the evidence behind it: a validator score, a label, a benchmark average. Each failure mode below says what it looks like and what check catches it.

1. Validator false pass. sbomify's own review found that a creator listed as "Tool: syft" passed as author, and so did "banana". Generation Context accepted any non-empty value. Check: read the raw author, generation context, and license fields yourself, and don't stop at the score.
2. Unknown read as omitted, or the reverse. SPDX marks unknowns with NOASSERTION and NONE, but CycloneDX has no reserved marker, so an honest CycloneDX file can look silently incomplete. Check: ask the supplier for its convention for marking unknowns before you grade a gap as a Fail.
3. Pre-build SBOM sold as a release SBOM. It looks complete, but it carries no hashes because it was generated from manifests. Check: compare the Generation Context value with whether the hash fields are filled. Empty hashes win the argument.
4. Stale or unread security.txt. The file validates, but the inbox is dead. Check: Expires must be in the future, and a test message must get a reply from a person.
5. Benchmark bias. Project Zero lags come from a reporter vendors fear, so they understate what a typical supplier takes. Check: measure this supplier's own advisories and grade on its median, not on the industry average.
6. Five years assumed to be enough. A product left in the field for a decade outlives a five-year supplier window. Check: compare against your own declared end date, counted from market placement.
7. Index keyword noise when staffing. An "SBOM" keyword search in Germany returns 88 profiles in Refolk's index. But 9 of the 25 sampled profiles come from Snom Technology, and some titles include "EBOM", which suggests substring matching. Check: do not treat 88 as a count of SBOM specialists. Search by role and work history instead.

Contract clauses that close conditional gaps

Every Conditional grade has to map to a numbered clause with a due date. Otherwise the verdict is a hope, not a decision. The clauses that matter most under the CRA are exploited-vulnerability notice, inbound reporting, and support-period alignment.

The CRA reporting duties became binding on the day ENISA switched on its Single Reporting Platform, and they cover products already on the market. Your report on an actively exploited vulnerability runs on a 24-hour clock that starts when you become aware of the exploitation. The final report is due 14 days after a corrective or mitigating measure becomes available. Separately, if you find a vulnerability in a component, you must report it to whoever makes or maintains that component.

Here is why the 24-hour notice clause matters. If you learn about exploitation from a customer or a threat feed, your clock has already started. A supplier allowed more than 24 hours to send you affected versions and mitigations leaves you filing your report without its facts.

C1 SBOM per release. For every release delivered, Supplier provides a post-build SBOM in CycloneDX 1.6 or SPDX 3.0.1 or later, covering all components including transitive dependencies, with a hash value and named algorithm for each delivered artifact, and marks every unknown, withheld, or not-applicable field explicitly using a convention stated in writing.
C2 Exploited-vulnerability notice. Supplier notifies Customer within 24 hours of becoming aware of an actively exploited vulnerability in the Component, through [named channel], stating affected versions and known mitigations.
C3 Inbound reports. Supplier maintains a monitored channel for vulnerability reports from Customer and acknowledges each report within [n] business days.
C4 Fix time. Supplier makes a fixed release available within 90 days of a vulnerability being reported or disclosed, and publishes a CVE ID and a CSAF or VEX statement for each fix.
C5 Final-report support. Supplier provides details of each corrective or mitigating measure in time for Customer to file its final report within 14 days of the measure becoming available.
C6 Support period. Supplier provides security updates until at least [date], which is on or after Customer's declared product support end date, gives [n] months written notice of any earlier end, and keeps every security update available for at least ten years after issue.
C7 Disclosure channel upkeep. Supplier keeps a security.txt with a future Expires date, a working Contact, and a Policy link for the life of the agreement.

The verdict record and final check

The verdict record is one page: eight graded criteria, each linked to its evidence, and a verdict reached by a fixed rule. Two reviewers grade separately and compare. If they disagree, the record shows which criterion they disagreed on and how it was settled.

Component and exact version:
Supplier:
Reviewer 1:            Reviewer 2:
Review date:
Baseline graded against: CISA minimum elements [plus BSI TR-03183-2 format floor: yes / no]
Core function (yes / no) and why:
Product declared support end date (from market placement):

#  Criterion                                   Evidence link   Grade (Pass / Conditional / Fail)
1  SBOM schema and format
2  Coverage, transitive included
3  Hashes present and match received binary
4  Unknowns declared explicitly
5  Disclosure channel and test message
6  CVE IDs and CSAF or VEX advisories
7  Patch lag (N =   median =   worst =   )
8  Supplier support end vs product end

Verdict rule: any Fail = Reject. Otherwise any Conditional = Conditional. Otherwise Accept.
Verdict:
Clauses attached (clause number, gap closed, due date):
Re-review trigger (next release, Expires date, clause due date):
Signed, engineering manager:
Signed, legal:

Keeping the standard current

A verdict holds for one supplier, one release, and one version of each baseline. Re-run the parts that have changed rather than the whole review. These are the triggers I use:

• New release from the supplier. Repeat steps 3, 4, and 6. The SBOM must match the exact release you ship.
• security.txt Expires date passes. Repeat step 5. An expired file drops that criterion to Conditional at best.
• Clause due date passes without delivery. Re-grade that criterion as Fail. The next release becomes a Reject until the supplier delivers.
• Baseline revised. The CISA minimum elements were rewritten after public comment, and validator profiles follow those revisions. When a new version appears, update your validator profile and re-grade any open Conditional records against it.
• Regulatory timetable moves. CRA obligations phase in on fixed dates. Check the Commission's current timetable and ENISA's reporting platform at each annual review, not from memory.
• Supplier announces an earlier end of support. Repeat step 7. For a core-function component this flips the verdict to Reject unless you have a replacement plan.

Store each verdict record next to the component in your SBOM inventory. When an auditor asks why this component shipped, the answer is then a signed page with linked evidence, not someone's recollection.