In May 2021, Executive Order 14028 gave the software industry an 18-month countdown to start producing Software Bills of Materials for anything sold to the U.S. federal government. That countdown ended in 2022, but the deadline pressure never really stopped — the FDA has required SBOMs for medical device premarket submissions since October 2023, the EU Cyber Resilience Act starts enforcing SBOM-adjacent obligations in 2027, and enterprise procurement teams now ask for an SBOM before they'll even open a security questionnaire. Generating one is no longer the hard part; most build pipelines can spit out a CycloneDX or SPDX file in minutes. The hard part is generating an SBOM that's accurate, generating it on every build instead of once a quarter, and exporting it in a format the person asking for it can actually use. This is where most teams — and most tools, including Endor Labs — start to diverge.
What Is an SBOM and Why Does It Matter in 2026?
An SBOM is a machine-readable inventory of every component, library, and dependency in a piece of software, along with version numbers, licenses, and supplier data — think of it as a nutrition label for code. It matters now because SBOMs have moved from "nice to have" to contractual requirement in a five-year span: NTIA published its minimum elements guidance in July 2021, CISA followed with SBOM-in-practice guidance for federal contractors, and by 2024 roughly 60% of enterprise software RFPs in regulated industries (finance, healthcare, defense) included an SBOM delivery clause, according to procurement data cited across multiple industry SBOM surveys. When Log4Shell hit in December 2021, organizations without SBOMs spent an average of several days just figuring out whether they were exposed — teams with an SBOM on hand queried it in minutes. That gap is the entire reason SBOMs exist.
Which SBOM Format Should You Use: SPDX or CycloneDX?
Use SPDX if your primary driver is license compliance and legal review, and CycloneDX if your primary driver is vulnerability management and security operations — most mature programs end up producing both. SPDX, now at version 3.0 (released April 2024) and maintained under the Linux Foundation, was born out of open-source license auditing and has deep fields for licensing, copyright, and provenance. CycloneDX, currently at 1.6 (OWASP, 2024), was purpose-built for application security and adds native support for vulnerability data (VEX), pedigree, and service dependencies. NTIA's minimum elements — supplier name, component name, version, dependency relationship, unique identifiers, author, and timestamp — are satisfiable in either format, so the "right" choice is really about who consumes the document downstream: a federal contracting officer will often accept SPDX tag-value or JSON; a security team piping data into a vulnerability scanner will usually want CycloneDX JSON.
What Regulations Actually Require SBOM Generation?
Three regulatory regimes currently drive SBOM requirements with real enforcement teeth: U.S. federal procurement under EO 14028 and OMB Memo M-22-18, FDA premarket cybersecurity requirements under Section 3305 of the Consolidated Appropriations Act of 2023, and the EU Cyber Resilience Act (CRA), which entered into force in December 2024 with substantive obligations phasing in through December 2027. M-22-18 requires federal software vendors to attest to secure development practices and, on request, produce an SBOM for any software delivered to an agency. The FDA has rejected or delayed 510(k) and premarket submissions since late 2023 specifically for missing or incomplete SBOM documentation. The CRA goes further than either, requiring manufacturers of "products with digital elements" sold in the EU to maintain an SBOM covering at least top-level dependencies, with fines up to €15 million or 2.5% of global annual turnover for non-compliance once enforcement is fully active. None of these regimes mandate a specific tool — they mandate an artifact, a cadence, and a level of accuracy, which is exactly where tool selection starts to matter.
How Do SBOM Generation Tools Like Endor Labs Compare on Accuracy and Coverage?
Endor Labs generates SBOMs as a byproduct of its dependency and reachability analysis platform, which is strong for open-source risk scoring but was not built primarily as an SBOM system of record — a distinction that shows up in three places: build-time source coverage, container and binary composition, and export flexibility. Endor Labs performs well on source-repo-level dependency graphing for languages it directly parses (it added function-level reachability analysis as a headline feature), but teams running polyglot environments with compiled binaries, container base images, or vendored code report needing a second tool to fill SBOM gaps for artifacts that never pass through a source-code scan. This matters because an SBOM generated only from manifest files (package.json, pom.xml, requirements.txt) captures declared dependencies but can miss transitive dependencies pulled in at build time, statically linked libraries, and OS-level packages baked into a container image — exactly the layers where incidents like the 2024 XZ Utils backdoor (CVE-2024-3094, embedded three layers deep in a compression library used by OpenSSH) actually live. A generation tool's real accuracy score is measured by how many of those layers it reaches, not by how fast it produces a JSON file.
How Do You Export and Distribute SBOMs to Customers and Auditors?
You export SBOMs in the format your recipient's tooling expects, on a schedule tied to your release cadence rather than a fixed calendar date, and through a channel that preserves version history for audit lookback. In practice this means three things: first, support both SPDX 2.3/3.0 and CycloneDX 1.5/1.6 output so you're not renegotiating format with every customer contract; second, generate a new SBOM on every release build (not quarterly or annually) since a stale SBOM is functionally useless the moment a new dependency is merged; third, keep every historical SBOM addressable by build ID or release tag, because auditors and incident responders frequently need to answer "what did we ship on March 14th" months after the fact. A common failure mode is treating SBOM export as a manual, once-a-quarter compliance exercise — teams doing this typically discover during an actual incident, like a new CVE disclosure, that the SBOM they can produce fastest is six months out of date and doesn't reflect what's actually in production.
How Safeguard Helps
Safeguard generates CycloneDX and SPDX SBOMs automatically as part of every scan, so the SBOM is a build-time artifact rather than a quarterly compliance chore — the same run that surfaces vulnerabilities also produces the export your auditors, customers, or FDA submission need. Coverage extends beyond source manifests to container images, OS packages, and binary artifacts, so the SBOM reflects what's actually running rather than only what a package manager declared, closing the gap that leaves XZ-style deeply nested dependencies invisible. Every SBOM is versioned against the build or release it was generated from, so answering "what were we running on a given date" is a lookup, not a reconstruction project. Because Safeguard ties SBOM data directly to reachability and exploitability analysis, teams don't just get a component inventory — they get an inventory annotated with which components are actually reachable in the running application, which shrinks the list a security team has to triage after a disclosure like Log4Shell or XZ Utils from thousands of entries to the handful that matter. For teams evaluating SBOM generation tools against platforms like Endor Labs, the practical test is straightforward: pull the SBOM for a container-based service with vendored binaries and see how much of it is actually populated. Safeguard is built to pass that test out of the box, with export formats and cadence designed around what NTIA, the FDA, and the CRA actually require — not the minimum needed to check a box.