An SBOM Is an Ingredient List, Not a Health Inspection

Key Takeaways

• CISA’s 2026 minimum elements replaced the 2021 National Telecommunications and Information Administration (NTIA) baseline on July 29, 2026, and set 17 data fields.
• The Office of Management and Budget (OMB) rescinded the federal secure software attestation memos in January 2026, leaving SBOM requests to each agency’s discretion.
• CRA SBOM requirements take effect on December 11, 2027, and set top-level dependencies as the minimum coverage.
• A component can be accurately listed in an SBOM and still be malicious, tampered with, or abandoned without a fix.

SBOM requirements are moving. The Office of Management and Budget (OMB) rescinded its federal attestation memos in January 2026; the FDA reissued its medical device cybersecurity guidance in February; CISA replaced the 2021 baseline for SBOM data in July, and the EU’s Cyber Resilience Act (CRA) starts requiring SBOMs from manufacturers in December 2027. Wherever an SBOM is required, what you hand over is a list of what’s inside your software.

That list is useful. An ingredients panel on a food package indicates that the product contains peanuts, which matters if you’re allergic. Checking whether the factory was clean, or whether the supplier is who it claims to be, requires an inspection, which is a separate job.

An SBOM works the same way. Writing one doesn’t change your exposure because any vulnerable, tampered, or abandoned component remains in your software after the list is created. And none of those four rules stop at the list. The federal requirement placed the SBOM among a wider set of secure development practices. CISA’s own document says the SBOM is data that still needs analysis, and the FDA and the CRA go further by pairing it with a duty to assess the components it lists and to patch them.

What SBOM Requirements Ask For As of October 2026

Four sets of rules matter most right now. The table provides the short version, and the sections that follow provide the details.

What’s Left of the SBOM Federal Requirement

Executive Order 14028, signed in May 2021, marked the start of the federal SBOM requirement. Section 4(e)(vii) called for NIST guidance on giving purchasers an SBOM for each product, either directly or on a public website. The order hasn’t been revoked, but most of the machinery around it has been pulled back. A June 2025 executive order (EO 14306) removed the attestation provisions that EO 14144, signed in January 2025, had added, including CISA’s central validation of vendor attestations. Then, on January 23, 2026, OMB memo M-26-05 rescinded M-22-18 and M-23-16, the memos behind the Secure Software Development Attestation Form.

Agencies can still use the form and still include SBOM delivery in contract terms, but government-wide policy no longer requires either. If you sell software to a federal buyer, whether you owe an SBOM now depends on that agency’s own policy and the contract in front of you.

The 2026 CISA Baseline for SBOM Data

On July 29, 2026, CISA, NSA, FBI, and 15 international partner organizations published the 2026 Minimum Elements for a Software Bill of Materials. It replaces the 2021 document from the National Telecommunications and Information Administration (NTIA) prompted by EO 14028, and it increases the minimum number of data fields from 7 to 17. The new ones include an SBOM author signature, a hash value and hash algorithm for each component, component licenses, the name and version of the generating tool, and a generation context indicating which lifecycle phase the SBOM was generated in, such as before or after the build.

Two other changes matter in practice. Coverage should now include transitive dependencies with no minimum depth, whereas the 2021 version only required top-level dependencies. And each component needs at least one machine-processable identifier, such as a Package-URL.

The document says its elements don’t create new requirements, only refine how organizations generate and request SBOMs. It also places the confirmation of an SBOM’s accuracy, coverage, and completeness outside the minimum elements, as these require different quality measures than a signature provides.

Note: CISA’s own conclusion is that an SBOM, by itself, is data about software components, and that analysis is what turns that data into insight.

FDA SBOM Requirements Under Section 524B

Congress added section 524B to the FD&C Act through the Food and Drug Omnibus Reform Act in December 2022. It applies to premarket submissions made on or after March 29, 2023, for a “cyber device,” meaning a device that includes software, can connect to the internet, and has characteristics that could be vulnerable to cyber threats. FDA reads that broadly, treating firmware as software and counting connectors such as USB and serial ports as means of connection. The covered submission types are 510(k), PMA, PDP, De Novo, and HDE. Under 524B(b)(3), the manufacturer must provide an SBOM covering commercial, open-source, and off-the-shelf components.

FDA’s guidance, reissued on February 3, 2026, asks for more than the baseline fields. It recommends that each component’s entry include its support status (such as actively maintained, no longer maintained, or abandoned) and its end-of-support date, and that manufacturers plan how to update or replace third-party components when support ends. That guidance isn’t binding, predates CISA’s 2026 update, and still cites NTIA’s 2021 work on baseline attributes. The statute itself adds a patching duty. Section 524B(b)(2) requires cyber device makers to make updates and patches available on a regular cycle for known unacceptable vulnerabilities and out of cycle for critical ones that could cause uncontrolled risk.

CRA SBOM Requirements and What They Leave Open

Annex I, Part II, point 1 of the Cyber Resilience Act requires manufacturers to identify and document vulnerabilities and components, including by producing an SBOM in a commonly used, machine-readable format that covers, at a minimum, the top-level dependencies. The regulation entered into force on December 10, 2024, and the main obligations, including the SBOM duty, apply from December 11, 2027. The SBOM is included in the technical documentation, and a market surveillance authority can request it, with reasons, when it needs it to check compliance. Sharing it with users is optional.

Part II of the same annex also requires manufacturers to address and remediate vulnerabilities without delay, including by providing security updates. Article 13 imposes a due diligence duty when you integrate third-party components, including open-source ones, and requires manufacturers who discover a vulnerability in a component to report it to its maintainer and then fix it in their own product. The SBOM duty, therefore, comes with duties that the SBOM itself doesn’t meet. The list shows what’s in the product, but vetting those components and fixing them is work the manufacturer still has to do. The top-level floor also works against those duties in practice: when an advisory lands, the affected component is often a transitive dependency, and an SBOM that stops at top-level dependencies won’t tell you whether you carry it. Meeting the remediation duty is easier with an SBOM built above the minimum.

Where NIST Fits

If you’re looking for NIST SBOM requirements, the first thing to know is that NIST doesn’t publish SBOM data elements of its own. NTIA set the baseline in 2021, and CISA set the current one. NIST’s part is process guidance. The Secure Software Development Framework (SSDF, SP 800-218, version 1.1) lists an SBOM as an example of the provenance data that producers should retain for every component of a release. The SSDF mattered to federal vendors because the attestation form that OMB rescinded in January required them to confirm compliance with the SSDF. Since that rescission, an agency can still ask for the attestation, but government-wide policy no longer requires it.

If a contract says to follow NIST, map your development practices to the SSDF, produce an SBOM that meets the CISA 2026 elements, and regenerate it with every release. No regulator mandates the 2026 elements yet, but they are the strictest published baseline, and an SBOM built to them satisfies the FDA and CRA floors as well. Read the contract language first, since it decides which of those the buyer cares about.

These rules cover who produces an SBOM and what it includes. The FDA and the CRA also name the follow-on duties, patching and due diligence, but say little about how to perform them. That is where the SBOM stops being enough.

What a Compliant SBOM Can’t Do on Its Own

Meet every SBOM requirement above, and you’ll have a document that records what’s in your software. It can record more than names and versions, such as a hash and an author signature for each component. Other documents can travel with it, too. A VEX (Vulnerability Exploitability eXchange) statement says whether a listed vulnerability affects the product, and a provenance attestation ties an artifact to the build that produced it. Even with all of that in hand, three checks still happen outside of them.

Does the artifact match its source?

The 2026 baseline asks for a hash value for each component’s executable artifact and a signature from the SBOM’s author. The hash identifies the described artifact, and the signature assures you that the claimed author signed the SBOM and that it has not been altered afterward. Neither compares the artifact with the source repository the project points to. If a hijacked maintainer account publishes a tampered release, or a registry package contains code that isn’t in the project’s repository, the SBOM records it like any other entry, with a hash that matches the file you downloaded.

Checking an artifact against its source can be done in different ways. A provenance attestation, for example, ties the artifact to the build that produced it. A rebuild from source replaces the registry artifact with one you built yourself, so what you ship contains only what’s in the repository. Both of these have the same limit. They settle whether the artifact matches the source, not whether the source is clean. A hijacked account or a malicious commit passes either check.

Should the component have been admitted at all?

Typosquats, namespace impersonation, and packages with hostile install behavior all get listed like any other package. The SBOM’s job is to record what was resolved, and it did that. Whether to resolve the package was decided earlier, and the CRA frames that decision as an exercise in due diligence when you integrate third-party components.

Some ecosystems run package code during install or build. An npm lifecycle script runs during install, a Rust build.rs script runs during the build, and a Python .pth startup hook can run code every time the interpreter starts. Many pipelines generate the SBOM at build time or later, so the package gets documented after it has had a chance to run.

Is there a fix, and who’s going to write it?

An SBOM plus advisory data tells you a component has a known vulnerability. A VEX document can indicate whether a vulnerability affects your product, and the support status that FDA guidance recommends recording indicates whether upstream is still around to fix it. All of that describes the problem, and none of it produces a patch.

Picture a component in your tree with a known vulnerability in a version line that is no longer maintained upstream. Sometimes the project is still active on a newer major release; sometimes it has been abandoned outright. Either way, you can upgrade, replace, or patch the version you run. Upgrading isn’t available when no fixed release exists, and it isn’t always safe even when one does. Replacing means a rewrite scoped to whatever used the component, which is harder when it arrived as a transitive dependency you never chose. That leaves patching the version you run. Someone has to write the fix or backport it from the newer major line, if the project is still active there, and then verify that the component’s behavior remains compatible. That’s narrow work, and it’s the work upstream isn’t going to do for a component it no longer maintains.

Side by side, the three checks look like this.

What the Rest of the Work Looks Like

Each of the three checks is a task someone must complete. Screening decides whether a package should be admitted before it reaches a developer machine or a build agent. Rebuilding from source gives you an artifact that matches the code in the project’s repository. Continued patching keeps components fixed after upstream slows down or stops.

From the SSDF: NIST’s framework lists, as examples for third-party components, reviewing them before use, checking that each is still maintained, planning for the ones that aren’t, and building from source when a binary’s provenance can’t be confirmed.

You still need the SBOM to answer “are we affected?” when an advisory lands. It answers that well only when it covers transitive dependencies and reflects what actually shipped, which is one reason to build it to CISA’s 2026 baseline rather than the CRA floor.

When you evaluate any of the supply chain security tools on the market, ask where in the sequence each one acts: before the package reaches you, during install, or after the artifact is in place. Many tools in the category report on what’s already there, and an attack that runs during install, build, or interpreter startup has already run by the time a report arrives.

TuxCare’s SecureChain acts before the package reaches you. It scans packages for hidden malware and suspicious code, blocking those that fail the scan. It then rebuilds packages from source in isolated build environments. For active components, it patches vulnerabilities under SLA as CVEs emerge, and when upstream stops maintaining a package, Endless Lifecycle Support (ELS) keeps the fixes coming. Coverage spans JavaScript, Python, Java, Go, Rust, and PHP packages.

What to Do Once the SBOM Exists

SBOM requirements have shifted several times since 2021, so treat the document as something you regenerate with each release, and put the controls that reduce risk ahead of it. If you don’t have one yet, build it to the CISA 2026 elements, including transitive dependencies. If you already have one, check that it goes beyond top-level dependencies and reflects what actually shipped. If it doesn’t, generate a new one from the resolved dependency tree or the built artifact, with no depth limit, before you do anything else with it. Then match it against advisory data, sort the vulnerable components by whether an upstream fix exists, and decide what to do with those without a fix. You can replace the component, have someone patch the version you run, or record an explicit risk acceptance.

If your SBOM keeps flagging packages that nobody maintains, see how SecureChain for Open Source blocks risky packages before they reach your environment and continues patching them after upstream support ends.

FAQ

What are SBOM requirements?

SBOM requirements are rules that make software producers provide a software bill of materials, a list of the components in a product. The main ones are FDA section 524B for medical devices, in effect since 2023; the EU Cyber Resilience Act, effective December 11, 2027; and federal procurement terms that US agencies now set on a contract-by-contract basis. CISA’s 2026 Minimum Elements define the baseline data fields.

Is there still an SBOM federal requirement?

Executive Order 14028, which directed guidance on giving purchasers an SBOM, still stands. The Office of Management and Budget (OMB) rescinded the memos that required secure software attestations (M-22-18 and M-23-16) on January 23, 2026. US agencies can still ask for an SBOM in contract terms, so whether you owe one depends on the buyer.

What are the FDA SBOM requirements for medical devices?

Section 524B of the FD&C Act requires an SBOM covering commercial, open-source, and off-the-shelf software in premarket submissions for cyber devices, meaning devices with software that can connect to the internet and could be vulnerable to cyber threats. FDA’s February 2026 guidance also recommends listing each component’s support status and end-of-support date.

What are the CRA SBOM requirements?

The EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. The duty applies from December 11, 2027, and market surveillance authorities can request the SBOM, with reasons, to check compliance. The CRA also requires manufacturers to fix vulnerabilities in their products and components without delay.

How do you comply with the NIST SBOM requirements?

NIST doesn’t set SBOM data elements. Those come from CISA’s 2026 Minimum Elements, which replaced the 2021 baseline from the National Telecommunications and Information Administration (NTIA), a US Commerce Department agency. NIST’s part is process guidance in the Secure Software Development Framework (SP 800-218), so compliance usually means aligning your development practices to it, producing an SBOM that meets the CISA elements, and updating it with each release.

Does an SBOM make software more secure?

Not by itself. An SBOM records which components are in the software, which helps you respond when a vulnerability is announced. It doesn’t verify that a package matches its source, judge whether it should have been installed, or supply a patch.

What can you do about a component that has a vulnerability but no upstream fix?

You can replace the component or patch the version you run. Replacing can mean a rewrite, and patching means someone has to write and test the fix, since no upstream release has one. A vendor that provides extended support for end-of-life open-source packages can supply that patch. Listing the component in an SBOM documents the exposure without changing it.

Summary

Article Name

SBOM Requirements and What a Bill of Materials Cannot Do

Description

SBOM requirements differ across US agencies, FDA, and the EU CRA. Learn what an SBOM can't do and the three checks that happen outside it.

Author

Artem Karasev

Publisher Name

TuxCare

Publisher Logo