# Sbomify, Full Content > Your Security Artifact Hub. From zero to SBOM hero. Generate, manage, and share SBOMs and compliance documents. Built for CRA compliance and seamless integration with your existing tools. This file contains the full text of https://sbomify.com/ in Markdown, intended for consumption by large language models. A shorter index is available at https://sbomify.com/llms.txt --- # About Us URL: https://sbomify.com/about/ Description: We empower software vendors and software buyers to seamlessly manage security compliance and software supply chain transparency. Our Mission At sbomify, we believe that software transparency is the foundation of trust in the digital age. As software supply chains become increasingly complex, the need for clear, manageable, and actionable security compliance data has never been greater. We exist to bridge the gap between software vendors and buyers, providing the tools and infrastructure needed to make transparency a seamless part of the development and procurement lifecycle. Whether you are a software vendor ensuring compliance with regulations like the EU Cyber Resilience Act (CRA) or a buyer verifying the security of your software assets, sbomify provides the platform to manage, share, and analyze SBOMs with confidence. The Origin Story sbomify was born out of necessity. It was created by Viktor Petersson, driven by his firsthand experience as co-founder of Screenly, a leading secure digital signage platform, while implementing a "Secure by Design" and "Secure by Default" philosophy. During this journey, Viktor discovered significant shortcomings in existing solutions for SBOM lifecycle management – challenges that were later echoed in CISA's SBOM Sharing Primer. While tools existed for generation, the ecosystem for managing, sharing, and enriching these artifacts was fragmented and insufficient for modern security needs. Another key insight was the need to accurately describe real-world products by grouping components directly under each product, as outlined in our lifecycle guide. sbomify was built to fill these gaps, offering a streamlined platform that addresses the real-world challenges of software supply chain transparency. Our technology is deeply rooted in industry best practices. Our SBOM generation tool is based on the blueprint from the CISA working group on SBOM generation, which Viktor co-led. This ensures that our approach aligns with the highest standards of security and compliance from the ground up. Leadership Viktor Petersson Founder Viktor is a serial entrepreneur and cybersecurity innovator, currently focused on shaping the future of software security and compliance. As the founder of sbomify, he simplifies Software Bill of Materials (SBOM) management, helping organizations navigate emerging cybersecurity regulations such as the Cyber Resilience Act (CRA). Community Leadership: CISA SBOM Working Group: Co-led the working group on SBOM generation. ECMA TC54: Invited expert to the working group focusing on security artifacts and the Transparency Exchange API. An advocate for secure and efficient technology practices, Viktor is passionate about helping companies adapt to the rapidly evolving cybersecurity landscape. He shares insights and industry trends through his podcast, Nerding Out With Viktor. --- # From Zero to SBOM Hero URL: https://sbomify.com/zero-to-hero/ Description: Generate your first compliance-ready SBOM in under 5 minutes. A quick-start guide to SBOM generation, quality, and distribution.
--- ## The Quality Problem Most SBOM generation tools produce incomplete SBOMs that: - Miss critical metadata (supplier info, licenses, contact details) - Lack unique identifiers (PURLs, CPEs) needed for vulnerability matching - Don't capture transitive dependencies properly - Fail to meet compliance requirements ### Why Quality Matters - **Vulnerability insights**: Without proper identifiers, you can't match components to CVE databases - **EOL detection**: Can't identify end-of-life components without enriched metadata - **License compliance**: Missing license data means legal blind spots - **Compliance failures**: [NTIA minimum elements](/compliance/ntia-minimum-elements/), [CISA requirements](/compliance/cisa-minimum-elements/), and [EU CRA](/compliance/eu-cra/) all set quality bars that raw generation tools don't meet
### The sbomify Difference The [sbomify action](https://github.com/sbomify/sbomify-action) is **fully open source** and the only tool that produces compliance-ready SBOMs out of the box by automatically: - Augmenting with supplier/author/manufacturer metadata - Data comes from your [sbomify profile](https://app.sbomify.com/) or a `sbomify.json` file in your repo - Enriching from **12 data sources** including: - Pre-computed databases (LicenseDB, Lifecycle Database for EOL dates) - Native registries (PyPI, crates.io, pub.dev, Debian) - Aggregators (deps.dev, ecosyste.ms) - Fallback sources (ClearlyDefined, Repology) - Adding proper identifiers for vulnerability matching - Meeting NTIA minimum elements without manual intervention See [Integrations](/features/integrations/) for the full list of enrichment sources.
### Runs Anywhere - No Vendor Lock-in - **GitHub Actions** - Native integration - **Any CI/CD** - GitLab CI, Bitbucket Pipelines, Jenkins, CircleCI, Travis CI, etc. - **Python package** - `uvx sbomify-action` for standalone use - **Docker** - `ghcr.io/sbomify/sbomify-action` runs anywhere ### Deployment Flexibility - **Hosted by sbomify** - SaaS, we manage everything - **Self-hosted** - Run on your own infrastructure for full control, keep your SBOMs in-house, and avoid dependency on any external vendor Your SBOMs, your infrastructure, your choice. Use the action standalone or with the sbomify platform. --- ## Step-by-Step Guide ### Step 1: Understand the Basics A Software Bill of Materials (SBOM) is like the ingredients list on a food package - but for software. It documents every component, library, and dependency in your application.
**Key takeaway:** SBOMs catalog all your dependencies, but **quality matters**. A low-quality SBOM is like an incomplete ingredients list - worse than useless because it gives false confidence. [What is an SBOM? →](/what-is-sbom/) ### Step 2: Choose Your Stack sbomify supports all major ecosystems: | Language/Platform | Package Managers | | --------------------------------- | ----------------------- | | [Python](/guides/python/) | pip, Poetry, Pipenv, uv | | [JavaScript](/guides/javascript/) | npm, yarn, pnpm, Bun | | [Java](/guides/java/) | Maven, Gradle | | [Go (Golang)](/guides/go/) | Go Modules | | [Rust](/guides/rust/) | Cargo | | [Ruby](/guides/ruby/) | Bundler | | [PHP](/guides/php/) | Composer | | [.NET/C#](/guides/dotnet/) | NuGet | | [Docker](/guides/docker/) | Container images | [View all guides →](/guides/) ### Step 3: Generate a Compliance-Ready SBOM Choose the option that fits your environment: **Setup wizard** (quickest) ```bash docker run --rm -it \ -v "$(pwd):/github/workspace" \ -w /github/workspace \ ghcr.io/sbomify/sbomify-action \ sbomify-action wizard ``` The interactive [setup wizard](/faq/how-do-i-use-the-sbomify-setup-wizard/) scans your repo for lockfiles, creates your product and components in sbomify, registers [OIDC trusted publishing](/faq/how-do-i-set-up-oidc-trusted-publishing/) (so you never store a token secret), and writes a ready-to-commit `.github/workflows/sboms.yml`. **GitHub Actions** (manual setup) ```yaml - name: Generate SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'requirements.txt' OUTPUT_FILE: 'sbom.cdx.json' ENRICH: true UPLOAD: false ``` **Other CI/CD environments** - We have ready-to-use templates for GitLab CI, Bitbucket Pipelines, and a Docker image for any environment. [View all CI/CD integrations →](/features/integrations/) All options handle generation + augmentation + enrichment automatically. The Docker image comes **bundled with all SBOM generation tools** - no need to install cdxgen, syft, or other tools separately. ### Step 4: Sign in CI/CD **If an SBOM isn't signed at generation time, can you trust it?** SBOMs generated outside CI/CD (or without signing) could be altered post-generation. No cryptographic proof means no way to verify authenticity or integrity.
Signing in CI/CD creates an unbroken chain of trust from build to distribution: - Customers receiving your SBOM can verify it hasn't been tampered with - Reduces reliance on trusting the distribution platform - Aligns with supply chain security best practices The sbomify action supports attestation via GitHub Actions (Sigstore) and other signing mechanisms. [Learn about SBOM attestation →](/2024/10/31/github-action-update-and-attestation/) ### Step 5: Understand the Full Lifecycle (Optional) For those who want to understand what's happening under the hood:
The sbomify action automates the entire authoring flow: **Generation → Augmentation → Enrichment → Signing** [SBOM Lifecycle Deep Dive →](/features/generate-collaborate-analyze/) ### Step 6: Manage and Share at Scale When you're generating one SBOM, management is easy. When you have dozens or hundreds across multiple products, services, and release cycles, you need: - **Logical grouping** - Organize SBOMs by product, team, or release - **SBOM Hierarchy** - Link related SBOMs (e.g., backend + frontend + container = product SBOM) - **Version tracking** - Keep historical SBOMs for audit trails - **Automated distribution** - Share with customers/regulators without manual work [Learn about SBOM Hierarchy →](/features/sbom-hierarchy/)
### Trust Center: Turn Transparency into Competitive Advantage The Trust Center is where "hero" status really shines. It's not just about generating SBOMs - it's about sharing them professionally with stakeholders. - **Your domain** - Host on your own domain (e.g., trust.yourcompany.com) - **Branded portal** - Your logo, your colors, professional presentation - **Automated publishing** - Syncs with CI/CD, always up-to-date - **Flexible access** - Public for transparency or private for invited stakeholders - **More than SBOMs** - Share SOC 2, ISO 27001, pentest reports, compliance attestations in one place - **Self-service** - Customers get what they need 24/7, no email chains [Explore Trust Center →](/features/trust-center/) --- ## The Litmus Test **SBOMs are becoming the litmus test for whether you actually know what goes into your software.** Regulators and buyers are no longer asking "do you have security?" - they're asking "prove it." SBOMs are the proof. ### Already Required - **EU Cyber Resilience Act (CRA)** - SBOMs mandatory for products with digital elements sold in EU - **PCI DSS 4.0** - Software component inventories required for payment card security (Req 6.3.2) ### More Regulation is Coming - FDA medical device guidance recommends SBOMs - CISA minimum elements expanding requirements - UK Software Security Code of Practice references software composition **The message:** If you can't produce a quality SBOM on demand, you're signaling that you don't know what's in your software. That's increasingly a dealbreaker for enterprise buyers and regulators alike. [SBOM Compliance Guide →](/compliance/) | [Why Now? →](/features/why-now/) ---

Ready to become an SBOM Hero?

Start generating compliance-ready SBOMs in minutes with sbomify.

Get Started Free

Or explore our guides to learn more.

--- # Pricing URL: https://sbomify.com/pricing/ Description: Simple, transparent pricing for teams of all sizes Pricing Plans Choose the plan that's right for your team Monthly Annual Save 20% Community $0 / Month Ideal For OSS maintainers / hobby projects Test-drive sbomify Features 1 Product 5 Components Unlimited SBOMs & compliance documents Public documents only Public trust center OSV vulnerability scanning (weekly re-scans) Manual exports only Basic compliance reporting Single user with community support Sign Up Business 14-day free trial $159 / Month billed annually Ideal For Mid-size teams needing private SBOMs, compliance documents & integrations Features 5 Products 200 Components Unlimited SBOMs & compliance documents Private documents with optional public sharing Custom trust center on your domain Transparency Exchange API (TEA) CRA Compliance Wizard Dependency Track integration Standard Integrations Automated reports & vulnerability insights (daily re-scans) Team/role-based access Priority email support Start 14-day free trial Or talk to sales → Or chat with us on Slack → Enterprise Custom Quote Ideal For Large orgs with advanced security & compliance needs Features Unlimited Products Unlimited Components Unlimited SBOMs & compliance documents Custom trust center on your domain Enterprise-grade controls (RBAC, audits, etc.) Custom & Advanced Integrations Advanced dashboards & compliance modules Org-wide roles, SSO/SCIM Dedicated account manager & SLA-backed support Contact Us Or chat with us on Slack → Frequently Asked Questions What's included in the free tier? The Community tier is perfect for open source projects and includes public SBOM hosting, 1 product with 5 components, and community support. Can I upgrade or downgrade at any time? Yes, you can change your plan at any time. Your billing will be prorated accordingly. What payment methods do you accept? We accept all major credit cards and can arrange alternative payment methods for enterprise customers. Do you offer custom solutions? Yes, our enterprise tier can be customized to meet your specific needs. Contact our sales team to learn more. Can I self-host Sbomify? Yes! Sbomify is open source and available for self-hosting. Check out our GitHub repository for installation instructions and documentation. --- # Privacy Policy URL: https://sbomify.com/privacy/ Description: Our commitment to protecting your privacy and personal data Last updated: September 10, 2026 This Privacy Policy describes Our policies and procedures on the collection, use and disclosure of Your information when You use the Service and tells You about Your privacy rights and how the law protects You. We are committed to protecting your privacy in accordance with the UK General Data Protection Regulation (UK GDPR), the Data Protection Act 2018, and other applicable UK data protection laws. We use Your Personal data to provide and improve the Service. By using the Service, You agree to the collection and use of information in accordance with this Privacy Policy. ## Data Controller Information sbomify ltd (Company Registration Number: 16181507) is the Data Controller for personal data collected through our Services. Our registered office is at 17-18 Berkeley Square, Clifton, Bristol, BS8 1HB, England. For data protection matters, you can contact our Data Protection Officer at . ## Your Data Protection Rights Under UK data protection law, you have the following rights: - **Right to be informed** about how we use your personal data - **Right of access** to your personal data - **Right to rectification** if your personal data is inaccurate or incomplete - **Right to erasure** (also known as the 'right to be forgotten') - **Right to restrict processing** of your personal data - **Right to data portability** allowing you to obtain and reuse your data - **Right to object** to processing of your personal data - **Rights related to automated decision making** including profiling To exercise any of these rights, please contact us using the details provided in this policy. We will respond to your request within one month. There is no fee for making a request. ## Interpretation and Definitions ### Interpretation The words of which the initial letter is capitalized have meanings defined under the following conditions. The following definitions shall have the same meaning regardless of whether they appear in singular or in plural. ### Definitions For the purposes of this Privacy Policy: - **Account** means a unique account created for You to access our Service or parts of our Service. - **Affiliate** means an entity that controls, is controlled by or is under common control with a party, where "control" means ownership of 50% or more of the shares, equity interest or other securities entitled to vote for election of directors or other managing authority. - **Company** (referred to as either "the Company", "We", "Us" or "Our" in this Agreement) refers to sbomify ltd, 17-18 Berkeley Square, Clifton, Bristol, BS8 1HB, England. - **Cookies** are small files that are placed on Your computer, mobile device or any other device by a website, containing the details of Your browsing history on that website among its many uses. - **Country** refers to: United Kingdom - **Device** means any device that can access the Service such as a computer, a cellphone or a digital tablet. - **Personal Data** is any information that relates to an identified or identifiable individual. - **Service** refers to the Website. - **Service Provider** means any natural or legal person who processes the data on behalf of the Company. It refers to third-party companies or individuals employed by the Company to facilitate the Service, to provide the Service on behalf of the Company, to perform services related to the Service or to assist the Company in analyzing how the Service is used. - **Third-party Social Media Service** refers to any website or any social network website through which a User can log in or create an account to use the Service. - **Usage Data** refers to data collected automatically, either generated by the use of the Service or from the Service infrastructure itself (for example, the duration of a page visit). - **Website** refers to sbomify, accessible from [https://sbomify.com](https://sbomify.com) - **You** means the individual accessing or using the Service, or the company, or other legal entity on behalf of which such individual is accessing or using the Service, as applicable. ## Collecting and Using Your Personal Data ### Types of Data Collected #### Personal Data While using Our Service, We may ask You to provide Us with certain personally identifiable information that can be used to contact or identify You. Personally identifiable information may include, but is not limited to: - Email address - First name and last name - Usage Data #### Usage Data Usage Data is collected automatically when using the Service. Usage Data may include information such as Your Device's Internet Protocol address (e.g. IP address), browser type, browser version, the pages of our Service that You visit, the time and date of Your visit, the time spent on those pages, unique device identifiers and other diagnostic data. When You access the Service by or through a mobile device, We may collect certain information automatically, including, but not limited to, the type of mobile device You use, Your mobile device unique ID, the IP address of Your mobile device, Your mobile operating system, the type of mobile Internet browser You use, unique device identifiers and other diagnostic data. We may also collect information that Your browser sends whenever You visit our Service or when You access the Service by or through a mobile device. #### Information from Third-Party Social Media Services The Company allows You to create an account and log in to use the Service through the following Third-party Social Media Services: - Google - GitHub If You decide to register through or otherwise grant us access to a Third-Party Social Media Service, We may collect Personal data that is already associated with Your Third-Party Social Media Service's account, such as Your name, Your email address, Your activities or Your contact list associated with that account. You may also have the option of sharing additional information with the Company through Your Third-Party Social Media Service's account. If You choose to provide such information and Personal Data, during registration or otherwise, You are giving the Company permission to use, share, and store it in a manner consistent with this Privacy Policy. #### Tracking Technologies and Cookies We use Cookies and similar tracking technologies to track the activity on Our Service and store certain information. Tracking technologies used are beacons, tags, and scripts to collect and track information and to improve and analyze Our Service. The technologies We use may include: - **Cookies or Browser Cookies.** A cookie is a small file placed on Your Device. You can instruct Your browser to refuse all Cookies or to indicate when a Cookie is being sent. However, if You do not accept Cookies, You may not be able to use some parts of our Service. Unless you have adjusted Your browser setting so that it will refuse Cookies, our Service may use Cookies. - **Web Beacons.** Certain sections of our Service and our emails may contain small electronic files known as web beacons (also referred to as clear gifs, pixel tags, and single-pixel gifs) that permit the Company, for example, to count users who have visited those pages or opened an email and for other related website statistics (for example, recording the popularity of a certain section and verifying system and server integrity). Cookies can be "Persistent" or "Session" Cookies. Persistent Cookies remain on Your personal computer or mobile device when You go offline, while Session Cookies are deleted as soon as You close Your web browser. We use both Session and Persistent Cookies for the purposes set out below: - **Necessary / Essential Cookies** Type: Session Cookies Administered by: Us Purpose: These Cookies are essential to provide You with services available through the Website and to enable You to use some of its features. They help to authenticate users and prevent fraudulent use of user accounts. Without these Cookies, the services that You have asked for cannot be provided, and We only use these Cookies to provide You with those services. - **Cookies Policy / Notice Acceptance Cookies** Type: Persistent Cookies Administered by: Us Purpose: These Cookies identify if users have accepted the use of cookies on the Website. - **Functionality Cookies** Type: Persistent Cookies Administered by: Us Purpose: These Cookies allow us to remember choices You make when You use the Website, such as remembering your login details or language preference. The purpose of these Cookies is to provide You with a more personal experience and to avoid You having to re-enter your preferences every time You use the Website. - **Analytics Cookies** Type: Persistent Cookies Administered by: PostHog Inc., acting as Our processor Purpose: These Cookies tell Us how the Website is used in aggregate — which pages are read, which links are followed — so that We can improve it. They are never used for advertising and are set only if You accept them. Data is processed on PostHog's United States infrastructure under appropriate safeguards for international transfers. #### Your Cookie Choices Analytics Cookies are not strictly necessary for the Website to work, so We ask for Your consent before setting any of them. Until You accept, the PostHog script is not loaded at all: nothing is requested from PostHog, and nothing is written to Your device apart from Your own choice. What is stored once You accept: - `sbomify_cookie_consent` (browser local storage) — records whether You accepted or declined, so that We do not ask again. Stored on Your device only and never sent to Us or to any third party. This entry is also written when You decline. - `ph__posthog` (Cookie, expires after 365 days) — PostHog's pseudonymous visitor and session identifier. - Further `ph_*` entries in browser local storage — session state and feature flag values used by PostHog. You can change Your decision at any time through the **Cookie settings** link in the footer of every page. Declining, or withdrawing an acceptance You gave earlier, stops analytics collection and deletes the PostHog Cookies and local storage entries this Website has already set. You can also refuse or delete Cookies through Your browser settings. ### Use of Your Personal Data The Company may use Personal Data for the following purposes: - **To provide and maintain our Service**, including to monitor the usage of our Service. - **To manage Your Account:** to manage Your registration as a user of the Service. The Personal Data You provide can give You access to different functionalities of the Service that are available to You as a registered user. - **For the performance of a contract:** the development, compliance and undertaking of the purchase contract for the products, items or services You have purchased or of any other contract with Us through the Service. - **To contact You:** To contact You by email, telephone calls, SMS, or other equivalent forms of electronic communication, such as a mobile application's push notifications regarding updates or informative communications related to the functionalities, products or contracted services, including the security updates, when necessary or reasonable for their implementation. - **To provide You** with news, special offers and general information about other goods, services and events which we offer that are similar to those that you have already purchased or enquired about unless You have opted not to receive such information. - **To manage Your requests:** To attend and manage Your requests to Us. - **For business transfers:** We may use Your information to evaluate or conduct a merger, divestiture, restructuring, reorganization, dissolution, or other sale or transfer of some or all of Our assets, whether as a going concern or as part of bankruptcy, liquidation, or similar proceeding, in which Personal Data held by Us about our Service users is among the assets transferred. - **For other purposes**: We may use Your information for other purposes, such as data analysis, identifying usage trends, determining the effectiveness of our promotional campaigns and to evaluate and improve our Service, products, services, marketing and your experience. We may share Your personal information in the following situations: - **With Service Providers:** We may share Your personal information with Service Providers to monitor and analyze the use of our Service, to contact You. - **For business transfers:** We may share or transfer Your personal information in connection with, or during negotiations of, any merger, sale of Company assets, financing, or acquisition of all or a portion of Our business to another company. - **With Affiliates:** We may share Your information with Our affiliates, in which case we will require those affiliates to honor this Privacy Policy. Affiliates include Our parent company and any other subsidiaries, joint venture partners or other companies that We control or that are under common control with Us. - **With business partners:** We may share Your information with Our business partners to offer You certain products, services or promotions. - **With other users:** when You share personal information or otherwise interact in the public areas with other users, such information may be viewed by all users and may be publicly distributed outside. If You interact with other users or register through a Third-Party Social Media Service, Your contacts on the Third-Party Social Media Service may see Your name, profile, pictures and description of Your activity. Similarly, other users will be able to view descriptions of Your activity, communicate with You and view Your profile. - **With Your consent**: We may disclose Your personal information for any other purpose with Your consent. ### Retention of Your Personal Data The Company will retain Your Personal Data only for as long as is necessary for the purposes set out in this Privacy Policy. We will retain and use Your Personal Data to the extent necessary to comply with our legal obligations (for example, if we are required to retain your data to comply with applicable laws), resolve disputes, and enforce our legal agreements and policies. The Company will also retain Usage Data for internal analysis purposes. Usage Data is generally retained for a shorter period of time, except when this data is used to strengthen the security or to improve the functionality of Our Service, or We are legally obligated to retain this data for longer time periods. ### Transfer of Your Personal Data Your information, including Personal Data, is processed at the Company's operating offices and in any other places where the parties involved in the processing are located. It means that this information may be transferred to – and maintained on – computers located outside of Your state, province, country or other governmental jurisdiction where the data protection laws may differ than those from Your jurisdiction. Your consent to this Privacy Policy followed by Your submission of such information represents Your agreement to that transfer. The Company will take all steps reasonably necessary to ensure that Your data is treated securely and in accordance with this Privacy Policy and no transfer of Your Personal Data will take place to an organization or a country unless there are adequate controls in place including the security of Your data and other personal information. ### Delete Your Personal Data You have the right to delete or request that We assist in deleting the Personal Data that We have collected about You. Our Service may give You the ability to delete certain information about You from within the Service. You may update, amend, or delete Your information at any time by signing in to Your Account, if you have one, and visiting the account settings section that allows you to manage Your personal information. You may also contact Us to request access to, correct, or delete any personal information that You have provided to Us. Please note, however, that We may need to retain certain information when we have a legal obligation or lawful basis to do so. ### Disclosure of Your Personal Data #### Business Transactions If the Company is involved in a merger, acquisition or asset sale, Your Personal Data may be transferred. We will provide notice before Your Personal Data is transferred and becomes subject to a different Privacy Policy. #### Law enforcement Under certain circumstances, the Company may be required to disclose Your Personal Data if required to do so by law or in response to valid requests by public authorities (e.g. a court or a government agency). #### Other legal requirements The Company may disclose Your Personal Data in the good faith belief that such action is necessary to: - Comply with a legal obligation - Protect and defend the rights or property of the Company - Prevent or investigate possible wrongdoing in connection with the Service - Protect the personal safety of Users of the Service or the public - Protect against legal liability ### Security of Your Personal Data The security of Your Personal Data is important to Us, but remember that no method of transmission over the Internet, or method of electronic storage is 100% secure. While We strive to use commercially acceptable means to protect Your Personal Data, We cannot guarantee its absolute security. ## Children's Privacy Our Service does not address anyone under the age of 13. We do not knowingly collect personally identifiable information from anyone under the age of 13. If You are a parent or guardian and You are aware that Your child has provided Us with Personal Data, please contact Us. If We become aware that We have collected Personal Data from anyone under the age of 13 without verification of parental consent, We take steps to remove that information from Our servers. If We need to rely on consent as a legal basis for processing Your information and Your country requires consent from a parent, We may require Your parent's consent before We collect and use that information. ## Links to Other Websites Our Service may contain links to other websites that are not operated by Us. If You click on a third party link, You will be directed to that third party's site. We strongly advise You to review the Privacy Policy of every site You visit. We have no control over and assume no responsibility for the content, privacy policies or practices of any third party sites or services. ## Changes to this Privacy Policy We may update Our Privacy Policy from time to time. We will notify You of any changes by posting the new Privacy Policy on this page. We will let You know via email and/or a prominent notice on Our Service, prior to the change becoming effective and update the "Last updated" date at the top of this Privacy Policy. You are advised to review this Privacy Policy periodically for any changes. Changes to this Privacy Policy are effective when they are posted on this page. ### Legal Basis for Processing Personal Data We process your personal data on the following legal bases: 1. **Contract fulfillment:** Processing necessary for the performance of a contract with you 2. **Legal obligation:** Processing necessary for compliance with our legal obligations 3. **Legitimate interests:** Processing necessary for our legitimate interests, provided these interests don't override your fundamental rights 4. **Consent:** Processing based on your specific consent ### International Data Transfers Following the UK's exit from the European Union, we ensure that any transfer of personal data outside the UK is done so in accordance with UK data protection laws. We implement appropriate safeguards when transferring data to countries that have not received an adequacy decision from the UK government. ### Security of Your Personal Data We implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including: - Encryption of personal data where appropriate - Regular testing and evaluation of security measures - Staff training on data protection and security - Access controls and authentication procedures - Regular backups and disaster recovery procedures While we strive to use commercially acceptable means to protect Your Personal Data, no method of transmission over the Internet or electronic storage is 100% secure. ## Complaints If you are unhappy with how we handle your personal data, you have the right to lodge a complaint with the Information Commissioner's Office (ICO), the UK supervisory authority for data protection issues. You can contact the ICO at: Information Commissioner's Office Wycliffe House Water Lane Wilmslow Cheshire SK9 5AF Website: [Information Commissioner's Office](https://ico.org.uk) Telephone: 0303 123 1113 --- # SBOM Examples: Real CycloneDX and SPDX Files, Annotated URL: https://sbomify.com/sbom-examples/ Description: Real SBOM examples in CycloneDX and SPDX, annotated field by field, with the same software shown in both formats. Includes live SBOMs you can download and check against the NTIA minimum elements. Most SBOM articles describe the idea and stop. This page shows the files. Every example below is either taken from a real, published SBOM you can download yourself, or is a minimal document reduced to the fields that matter, and each one is annotated so you can see what each field is for. If you want the concept first, start with [what an SBOM is](/what-is-sbom/) and come back. ## The shape of an SBOM Whatever the format, an SBOM has two halves: 1. **A header about the SBOM itself.** Who produced it, with which tool, when, and what software it describes. This is the part people forget, and it is the part auditors ask about first. 2. **A list of components.** Each with a name, a version, a supplier and, ideally, a unique identifier and a license. The formats disagree only on vocabulary. CycloneDX calls them `components`; SPDX calls them `packages`. ## A minimal CycloneDX example This is close to the smallest document that is still a useful SBOM. CycloneDX will validate with only `bomFormat`, `specVersion` and `version`, but a document without a timestamp, a producer or a subject tells a consumer nothing. ```json { "bomFormat": "CycloneDX", "specVersion": "1.6", "serialNumber": "urn:uuid:6a6df004-b6c9-4f38-9b5a-1f0c2f1c4d3e", "version": 1, "metadata": { "timestamp": "2026-07-30T13:45:53Z", "tools": [ { "vendor": "sbomify, ltd", "name": "sbomify", "version": "26.7.1" } ], "component": { "type": "application", "name": "sbomify", "version": "26.7.1" } }, "components": [] } ``` Reading it field by field: | Field | What it is for | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `bomFormat`, `specVersion` | Identifies the document as CycloneDX and pins the schema version. A consumer needs both before it can parse anything else. | | `serialNumber` | A UUID URN unique to this document. Together with `version` it lets you tell a re-issued SBOM from a different one. | | `version` | The revision of _this_ SBOM, not of the software. Bump it when you republish an SBOM for the same build. | | `metadata.timestamp` | When the SBOM was assembled. One of the NTIA minimum elements. | | `metadata.tools` | What produced the SBOM. The other half of the "author of SBOM data" element. | | `metadata.component` | The subject: the thing this SBOM is _about_. Without it, a consumer has a list of parts and no idea what they add up to. | | `components` | The inventory. Empty here; populated below. | ## The same document in SPDX SPDX describes the same facts with different names. This is the SPDX 2.3 equivalent of the header above. ```json { "spdxVersion": "SPDX-2.3", "dataLicense": "CC0-1.0", "SPDXID": "SPDXRef-DOCUMENT", "name": "sbomify", "documentNamespace": "https://sbomify.com/spdxdocs/sbomify-26.7.1", "creationInfo": { "created": "2026-07-30T13:45:53Z", "creators": [ "Organization: sbomify, ltd", "Tool: sbomify-26.7.1" ] }, "packages": [], "relationships": [] } ``` The mapping is close to one-to-one: | CycloneDX | SPDX | Notes | | -------------------- | ----------------------- | ---------------------------------------------------------------------------------- | | `specVersion` | `spdxVersion` | Schema version. | | `serialNumber` | `documentNamespace` | SPDX uses a URI rather than a UUID URN. | | `metadata.timestamp` | `creationInfo.created` | Same field, different spelling. | | `metadata.tools` | `creationInfo.creators` | SPDX puts organisation and tool in one list, prefixed `Organization:` and `Tool:`. | | `components` | `packages` | The inventory. | | implicit nesting | `relationships` | CycloneDX can nest components; SPDX always states relationships explicitly. | `dataLicense` is an SPDX quirk with no CycloneDX equivalent: it is the license of _the SBOM document itself_, and the spec requires `CC0-1.0`. For the differences that go beyond naming, governance, license depth, native vulnerability support, and which compliance frameworks expect which, see our [comparison of the two formats](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/). ## A real component entry An empty `components` array is not much of an example. This entry is taken verbatim from an SBOM generated against the `alpine:3.18` container image, and it is what a well-formed component actually looks like: ```json { "bom-ref": "pkg:apk/alpine/alpine-baselayout-data@3.4.3-r1?arch=x86_64&distro=3.18.12", "type": "library", "name": "alpine-baselayout-data", "version": "3.4.3-r1", "supplier": { "name": "Natanael Copa " }, "hashes": [ { "alg": "SHA-1", "content": "602007ee374ed96f35e9bf39b1487d67c6afe027" } ], "licenses": [ { "license": { "id": "GPL-2.0-only" } } ], "purl": "pkg:apk/alpine/alpine-baselayout-data@3.4.3-r1?arch=x86_64&distro=3.18.12" } ``` Three things are worth pointing out. **The `purl` is the identifier that matters.** A [Package URL](https://github.com/package-url/purl-spec) encodes ecosystem, namespace, name, version and qualifiers in one string, which is what makes automated vulnerability matching possible. `pkg:apk/alpine/...` says this is an Alpine `apk` package; a Python dependency would read `pkg:pypi/requests@2.32.3`. Name and version alone are ambiguous across ecosystems. **The license is an SPDX identifier, not free text.** `GPL-2.0-only` is a value from the [SPDX license list](https://spdx.org/licenses/). Writing `"GPLv2"` instead is the single most common way to make a license field useless to automation. **`supplier` is a minimum element and is usually missing.** Most generators leave it out because the upstream package metadata does not carry it. If you are producing SBOMs for customers, this is the field to check first. ## Checking an example against the minimum elements A file that validates against the schema is not automatically a _good_ SBOM. The US baseline is the [CISA 2026 minimum elements](/compliance/cisa-minimum-elements/), published on 29 July 2026, which updates and replaces the [NTIA 2021 minimum elements](/compliance/ntia-minimum-elements/). Against that baseline, the component above scores: | Minimum element | In the example? | | ------------------------ | ----------------------------------------------------- | | Supplier name | Yes, `supplier.name` | | Component name | Yes, `name` | | Version | Yes, `version` | | Other unique identifiers | Yes, `purl` | | Dependency relationship | Only at document level, via nesting or `dependencies` | | Author of SBOM data | In the header, `metadata.tools` | | Timestamp | In the header, `metadata.timestamp` | Note that two of the seven elements live in the header, not in the component. An SBOM that is nothing but a component list cannot meet the baseline no matter how good the entries are. ## Live SBOMs you can download Hand-written snippets are tidy in a way that real SBOMs are not. sbomify publishes the SBOMs for its own product, in both formats, on its [public Trust Center](https://trust.sbomify.com/product/sbomify/), including the product-level SBOM that references the SBOMs of each underlying component rather than flattening everything into one list. Two other sources worth knowing, both from the projects that maintain the specifications themselves: - The [CycloneDX BOM examples repository](https://github.com/CycloneDX/bom-examples), maintained by the OWASP CycloneDX project, covering SBOM, VEX, VDR and CBOM documents. - The [SPDX specification](https://spdx.dev/use/specifications/), maintained by the Linux Foundation, whose annexes include worked examples in each supported serialisation. For background on why these documents are being asked for, [CISA's SBOM resources](https://www.cisa.gov/sbom) and the [OpenSSF](https://openssf.org/) guidance are the primary references, and [ENISA](https://www.enisa.europa.eu/) covers the European position. ## Generating your own Reading examples only gets you so far. Every ecosystem has a different route from lockfile to SBOM, and our [language guides](/guides/) cover them one by one, from `uv.lock` and `Cargo.lock` through to container images. The short version: generate from a lockfile where you can, enrich the result so the supplier and license fields are actually populated, and publish it somewhere your customers can find it without emailing you. --- # SBOM Resources URL: https://sbomify.com/resources/ Description: Discover the full SBOM life cycle: Generation, Distribution, and Analysis. Explore tools, benchmarks, and resources for creating, sharing, and utilizing Software Bills of Materials. New to SBOMs? Start with [What is an SBOM?](/what-is-sbom/) to learn the basics. The SBOM life cycle can be broken down into three phases: [generation, distribution, and analysis](/features/generate-collaborate-analyze/). The structure below aligns with the life cycle. ![Lifecycle](/assets/images/d2/lifecycle.svg) There's also a GitHub repository called [sbom-benchmarks](https://github.com/sbomify/sbom-benchmarks) that sets to benchmark the various tools (from the Generation phase) against each other, along with providing examples how they are used. For step-by-step guides on generating SBOMs for specific languages and platforms, see our comprehensive [SBOM Guides](/guides/). **Related educational content:** - [SBOM Generation Tools Compared](/2026/01/26/sbom-generation-tools-comparison/) – In-depth comparison of Syft, Trivy, cdxgen, and more - [Trivy Compromise: Hardening sbomify-action](/2026/03/26/trivy-compromise-hardening-sbomify-action/) – March 2026 supply chain advisory - [SBOM Formats: CycloneDX vs SPDX](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/) – Choosing the right format for your use case - [SBOM Scanning: Vulnerability Detection](/2026/02/01/sbom-scanning-vulnerability-detection/) – How to scan SBOMs for known vulnerabilities - [SBOM Management Best Practices](/2026/01/18/sbom-management-best-practices/) – Organizing, monitoring, and acting on SBOMs at scale --- ## Video Resources ### CRA-Ready SBOMs: A Practical Blueprint for High-Quality Generation See also the [FOSDEM schedule page](https://fosdem.org/2026/schedule/event/UYTGWA-sbom-generation/) for more details. ### Introduction to SBOMs: sbomify at Ubuntu Engineering Sprint ### Interview with the creator of CycloneDX: Steve Springett ### Interview with "the father of SBOMs": Allan Friedman ### A deep dive into the SBOM format SPDX ### CRA deep dive with Sarah Fluchs ### SBOMs & CRA Deep Dive: Compliance, Liability & the Future of Secure Products ### How SBOMs and Engineering Discipline Can Help You Avoid Trivy's Compromise Also available on [Spotify](https://open.spotify.com/episode/5wzJM6Sk3ZRbvC8sfmFBPb) and [Apple Podcasts](https://podcasts.apple.com/gb/podcast/how-sboms-and-engineering-discipline-can-help-you/id1106971805?i=1000761075185). --- ## Articles & Press - [QCon London 2026: SBOMs Move from Best Practice to Legal Obligation as CRA Enforcement Looms](https://www.infoq.com/news/2026/03/sbom-viktor-petersson/) – InfoQ coverage of Viktor Petersson's QCon London 2026 talk on how the EU CRA and existing US regulations are turning SBOMs into a mandatory compliance requirement. - [U.S. Army, Lockheed Martin detail SBOM progress](https://www.techtarget.com/searchitoperations/feature/366611692/US-Army-Lockheed-Martin-detail-SBOM-progress) – TechTarget reporting on how the U.S. Army and Lockheed Martin are operationalizing SBOMs, with commentary from sbomify. - [Cybersecurity Legislation Driving SBOMs](https://www.eetimes.eu/cybersecurity-legislation-driving-sboms/) – EE Times Europe on how cybersecurity legislation is driving SBOM adoption. --- ## Generation / Authoring The SBOM generation phase, also known as authoring, is where you create an SBOM from a source. There are various strategies for generating SBOMs, but this phase generally involves taking a set of inputs (such as a dependency file) and generating an SBOM in either the [CycloneDX](https://cyclonedx.org/) or [SPDX](https://spdx.dev/) format. ### Generic Tools that spans multiple formats and languages. - [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) from sbomify - [Snyk](https://github.com/snyk/cli) from Snyk - [Syft](https://github.com/anchore/syft) from Anchore - ~~[Trivy](https://github.com/aquasecurity/trivy) from Aqua~~ ([removed from sbomify-action](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise) ### Specific Language or format-specific tools. #### Docker / Containers See guide [SBOM Generation Guide for Docker and Containers](/guides/docker/) for more details. You can see how they compare side-by-side in the [sbom-benchmark](https://github.com/sbomify/sbom-benchmarks/tree/master/docker) repository. - [bom](https://github.com/kubernetes-sigs/bom) from The Linux Foundation - [Tern](https://github.com/tern-tools/tern) #### Python See guide [The ultimate SBOM guide for Python](/guides/python/) for more language specific details. You can see how they compare side-by-side in the [sbom-benchmark](https://github.com/sbomify/sbom-benchmarks/tree/master/python) repository. - [CycloneDX Python](https://github.com/CycloneDX/cyclonedx-python) from CycloneDX - [sbom4python](https://github.com/anthonyharrison/sbom4python) from Anthony Harrison - [SPDX Python](https://github.com/spdx/tools-python) from SPDX #### Rust See guide [SBOM Generation Guide for Rust - Cargo](/guides/rust/) for more language specific details. - [CycloneDX Rust](https://github.com/CycloneDX/cyclonedx-rust-cargo) from CycloneDX - [sbom-rs](https://github.com/psastras/sbom-rs) from Paul Sastrasinh - [sbom4rust](https://github.com/anthonyharrison/sbom4rust) from Anthony Harrison #### Go See guide [SBOM Generation Guide for Go - Go Modules](/guides/go/) for more language specific details. - [CycloneDX Go](https://github.com/CycloneDX/cyclonedx-gomod) from CycloneDX - [SPDX Golang](https://github.com/spdx/tools-golang) from SPDX #### .NET See guide [SBOM Generation Guide for .NET - NuGet](/guides/dotnet/) for more language specific details. - [CycloneDX .NET](https://github.com/CycloneDX/cyclonedx-dotnet-library) from CycloneDX - [SBOM Tool](https://github.com/microsoft/sbom-tool) from Microsoft #### Java See guide [SBOM Generation Guide for Java - Maven, Gradle](/guides/java/) for more language specific details. - [CycloneDX Java](https://github.com/CycloneDX/cyclonedx-core-java) from CycloneDX - [SPDX Java](https://github.com/spdx/Spdx-Java-Library) from SPDX #### JavaScript See guide [SBOM Generation Guide for JavaScript - npm, yarn, pnpm, Bun](/guides/javascript/) for more language specific details. - [CycloneDX JavaScript](https://github.com/CycloneDX/cyclonedx-javascript-library) - [Retire.js](https://github.com/RetireJS/retire.js) from RetireJS - [sbom4js](https://github.com/anthonyharrison/sbom4js) from Anthony Harrison #### Ruby See guide [SBOM Generation Guide for Ruby - Bundler](/guides/ruby/) for more language specific details. - [CycloneDX Ruby](https://github.com/CycloneDX/cyclonedx-ruby-gem) from CycloneDX #### PHP See guide [SBOM Generation Guide for PHP - Composer](/guides/php/) for more language specific details. - [CycloneDX PHP Composer](https://github.com/CycloneDX/cyclonedx-php-composer) from CycloneDX #### Swift See guide [SBOM Generation Guide for Swift - Swift Package Manager](/guides/swift/) for more language specific details. #### Dart / Flutter See guide [SBOM Generation Guide for Dart and Flutter - pub](/guides/dart/) for more language specific details. #### Elixir See guide [SBOM Generation Guide for Elixir - Mix](/guides/elixir/) for more language specific details. #### Scala See guide [SBOM Generation Guide for Scala - sbt](/guides/scala/) for more language specific details. #### C/C++ See guide [SBOM Generation Guide for C/C++ - Conan](/guides/cpp/) for more language specific details. Related blog posts by [Chris Swan](/authors/cswan/): - [The C conundrum - generating SBOMs when there's no lockfile](/2024/11/18/c-conundrum/) - [Using Conan for C SBOMs](/2025/09/04/conan/) #### Terraform See guide [SBOM Generation Guide for Terraform - Infrastructure as Code](/guides/terraform/) for more language specific details. #### Yocto See guide [SBOM Generation Guide for Yocto - Embedded Linux](/guides/yocto/) for more details. Related blog posts: - [Mastering SBOM Generation with Yocto](/2025/02/21/mastering-sbom-generation-with-yocto/) #### Raspberry Pi See guide [SBOM Generation Guide for Raspberry Pi - rpi-image-gen](/guides/raspberry-pi/) for more details. Related blog posts: - [Unpacking Raspberry Pi's Built-In SBOM Magic](/2025/04/17/unpacking-raspberry-pi-s-built-in-sbom-magic/) #### Others - [Hoppr](https://hoppr.dev/) from Lockheed Martin Corporation - [OSS Review Toolkit](https://github.com/oss-review-toolkit/ort) (ORT) - [protobom](https://github.com/protobom/protobom) ### Assembly and Enrichment - [CycloneDX Editor/Validator](https://github.com/Festo-se/cyclonedx-editor-validator/) from Festo - [jq](https://github.com/jqlang/jq) is commonly used for assembly - [Parlay](https://github.com/snyk/parlay) from Snyk - [sbomasm](https://github.com/interlynk-io/sbomasm) from Interlynk - [sbomaudit](https://github.com/anthonyharrison/sbomaudit) from Anthony Harrison --- ## Distribution / Transportation The distribution phase, also known as Transportation, focuses on how you share the SBOM with internal and external stakeholders. - [sbomify]() - [Project Koala](https://github.com/CycloneDX/transparency-exchange-api) (a.k.a. Transparency Exchange API) from CycloneDX --- ## Analysis The analysis phase involves how you use the SBOM, typically for compliance or security purposes. Mature organizations may use multiple tools or services for different purposes. - [bomber](https://github.com/devops-kung-fu/bomber) from DKFM - [bomshell](https://github.com/puerco/bomshell) from Adolfo García Veytia (a.k.a. Puerco) - [Cybellum](https://cybellum.com/) from Cybellum - [Dependency Track](https://dependencytrack.org/) from OWASP - [Eclipse SW360](https://github.com/eclipse-sw360/sw360) - [Grype](https://github.com/anchore/grype) from Anchore - [GUAC](https://guac.sh) from OpenSSF - [Helm](https://www.medcrypt.com/solutions/helm) from Medcrypt - [NTIA Conformance Checker](https://github.com/spdx/ntia-conformance-checker) from SPDX - [Open Source Vulnerabilities](https://osv.dev/) (OSV) from Google - [SBOM Observer](https://sbom.observer/) from Bitfront - [sbomaudit](https://github.com/anthonyharrison/sbomaudit) from Anthony Harrison - [sbommerge](https://github.com/anthonyharrison/sbommerge) from Anthony Harrison - [sbomqs](https://github.com/interlynk-io/sbomqs) from Interlynk - [sbom-tools](https://github.com/sbom-tool/sbom-tools) from sbom-tool - [SecObserve](https://github.com/SecObserve/SecObserve) from Stefan Fleckenstein --- ## Compliance & Standards For detailed information on SBOM compliance requirements across NTIA, CISA, EU CRA, FDA, and schema mappings to CycloneDX/SPDX, see our [SBOM Compliance Requirements](/compliance/) page. **External resources:** - [OpenChain CRA Compliance](https://openchainproject.org/cracompliance) – The OpenChain Project's CRA requirement and self-certification checklist, developed in the open on [GitHub](https://github.com/OpenChain-Project/CRA-Compliance) and building on ISO/IEC 18974 (open source security assurance). Where [BSI TR-03183-2](/compliance/bsi-tr-03183/) specifies what a CRA-ready SBOM must contain, OpenChain's checklist covers the process and policy side of getting an organisation ready. The two complement each other. - [Open Regulatory Compliance Working Group (ORC WG)](https://orcwg.org/) – Hosted by the Eclipse Foundation, ORC WG is where open source foundations, maintainers, and industry work out what the CRA means for open source in practice. Its [CRA Hub](https://github.com/orcwg/cra-hub) collects an FAQ, a resource inventory, a summary of the requested harmonised standards, and input on the important and critical product categories. Start here if you are working out whether you are an **open-source steward** under [CRA Article 24](/compliance/eu-cra/) rather than a manufacturer.
Edit this page on GitHub
--- # Share and Collaborate on SBOMs URL: https://sbomify.com/share-and-collaborate/ Description: Centralize SBOM management and share software transparency artifacts with customers, auditors, and internal teams through sbomify's Trust Center and integrations. sbomify is a central hub for managing and sharing SBOMs and compliance artifacts. Suppliers upload SBOMs automatically through CI/CD integrations, while stakeholders (customers, auditors, and internal teams) access them through the [Trust Center](/features/trust-center/) or direct exports.
## Centralized SBOM Hub Instead of sharing SBOMs over email or scattered file shares, sbomify provides a single source of truth. Vendors and internal teams upload SBOMs via [CI/CD integrations](/features/integrations/) (GitHub Actions, GitLab CI, etc.), and sbomify stores, enriches, and distributes them automatically. Because an SBOM is a snapshot of a specific point in time, having a centralized platform where the latest versions are always available is critical. sbomify ensures stakeholders can access the most current SBOMs at any time, whether for compliance audits, vulnerability management, or procurement decisions. Both CycloneDX and SPDX formats are fully supported. ## Hierarchical Organization Most real-world products are composed of multiple backend services, frontend components, and infrastructure, each with its own SBOM. sbomify organizes these by grouping **Components** directly under **Products**, reflecting how your software is actually structured.
In the example above, a Smart Thermostat product contains both an IoT device firmware and a backend composed of Python, Node, and Docker SBOMs. With sbomify, you can share individual component SBOMs or the entire product SBOM (aggregating all sub-components) with stakeholders. This hierarchical approach uses linkage rather than flattening, so no contextual data is lost. You always know exactly where an affected component lives. Learn more about [SBOM hierarchy and release management](/features/sbom-hierarchy/). ## Trust Center The [Trust Center](/features/trust-center/) is the primary way to share SBOMs and compliance artifacts with external stakeholders. It's a branded portal on your own domain where customers and auditors can access: - Current SBOMs for your products - Compliance documents and certifications - Penetration test results and security assessments The Trust Center stays in sync with your CI/CD pipeline, automatically publishing new SBOMs with every release. Access can be public (for broad transparency) or private (for invited stakeholders only). Available on Business and Enterprise plans. --- # Terms of Service URL: https://sbomify.com/terms/ Description: Terms and conditions for using sbomify Last updated: May 2, 2025 These Terms of Service ("Terms") constitute a legally binding agreement between you and sbomify ltd ("Company", "we", "our", or "us"), a company registered in England and Wales (Company Registration Number: 16181507), with its registered office at 17-18 Berkeley Square, Clifton, Bristol, BS8 1HB, England. By accessing or using any sbomify products or services, you agree to be bound by these Terms. If you disagree with any part of these terms, you may not access or use the Service. We may update these Terms at any time. We will take appropriate measures to notify you of any updates, and you can always find the latest version of these Terms at sbomify.com/terms. Your continued use of the Service after any changes constitutes acceptance of the updated Terms. ## Definitions "Agreement" means these Terms of Service. "Company", "we", "our", or "us" refers to sbomify ltd, registered in England and Wales. "Services" refers to our websites, including sbomify.com, and any product created and maintained by sbomify ltd. This includes the sbomify platform and all associated services, whether delivered within a web browser, desktop application, mobile application, or another format. "User", "you", or "your" refers to the individual, company, or legal entity accessing or using the Services. "Content" means any information, data, text, software, music, sound, photographs, graphics, video, messages, or other materials. ## Account Terms 1. You must provide accurate, complete, and up-to-date information when creating an account. Failure to do so constitutes a breach of these Terms. 2. You are responsible for safeguarding your account credentials and for any activities or actions under your account. We strongly recommend enabling two-factor authentication. 3. You must notify us immediately upon becoming aware of any breach of security or unauthorized use of your account. 4. You may not use the Services for any unlawful purpose or in any way that violates applicable laws in England and Wales or your local jurisdiction. 5. Automated account creation is prohibited. Each account must be created and managed by a human user. ## Payment and Billing 1. Free Services: Our free tier is provided without charge and does not require payment information. 2. Paid Services: - All prices are in GBP and exclude VAT unless otherwise stated - Payment is required in advance for continued access to paid Services - Trial periods, when offered, will be clearly communicated at signup - We accept payment via our approved payment processors 3. Billing Cycles: - Charges for paid plans begin on the date of upgrade - Plan changes take effect from the next billing cycle 4. Taxes: - UK VAT will be added where applicable - You are responsible for any additional taxes or duties in your jurisdiction 5. Refunds: - Refunds are handled in accordance with UK consumer protection laws - No partial refunds are provided for unused periods - Refund requests must be submitted in writing to our support team ## Data Protection and Privacy 1. We process personal data in accordance with: - The UK General Data Protection Regulation (UK GDPR) - The Data Protection Act 2018 - Our Privacy Policy 2. We act as a data processor for any personal data you submit through the Services 3. You remain the data controller for any personal data you process using our Services 4. You warrant that you have: - All necessary rights to process the data you submit - Obtained all necessary consents from data subjects - Complied with all applicable data protection laws 5. We will: - Process data only on your documented instructions - Implement appropriate technical and organizational measures - Assist you in responding to data subject rights requests - Notify you of any personal data breaches without undue delay ## Intellectual Property Rights 1. Our Rights: - All intellectual property rights in the Services remain our property - This includes copyrights, trademarks, database rights, and trade secrets 2. Your Rights: - You retain ownership of your Content - You grant us a limited license to host, display, and process your Content 3. Restrictions: - You may not copy, modify, or create derivative works of our Services - You may not reverse engineer or decompile our Services - You may not remove any proprietary notices from our Services ## Service Level and Support 1. Service Availability: - We aim to maintain high service availability but do not guarantee 100% uptime - Scheduled maintenance will be communicated in advance where possible 2. Support: - Technical support is provided according to your service tier - Support hours are UK business hours unless otherwise specified 3. Usage Limits: - We may impose reasonable usage limits to maintain service quality - You will be notified if you approach or exceed these limits ## Termination 1. Your Rights: - You may terminate this Agreement at any time by canceling your account - Cancellation requests must be made through your account settings 2. Our Rights: - We may terminate or suspend access immediately for material breach - We may discontinue the Services with reasonable notice 3. Effects of Termination: - Access to Services will cease immediately - Your Content will be deleted after 60 days - You remain liable for any outstanding charges ## Liability and Indemnity 1. Our Liability: - Nothing in these Terms excludes our liability for death, personal injury, or fraud - Subject to the above, our total liability is limited to the amount paid by you in the 12 months preceding the claim - We are not liable for any indirect or consequential losses 2. Your Liability: - You agree to indemnify us against claims arising from your use of the Services - This includes breaches of these Terms or applicable laws 3. Force Majeure: - Neither party is liable for failures caused by circumstances beyond reasonable control ## API Usage 1. API access is provided subject to: - Fair usage limits - Our API documentation and policies - Additional terms specific to API services 2. We reserve the right to: - Modify the API with reasonable notice - Suspend access for excessive or abusive usage - Charge for API usage beyond fair use limits ## Governing Law 1. These Terms are governed by the laws of England and Wales 2. Any disputes will be subject to the exclusive jurisdiction of the courts of England and Wales 3. Nothing in these Terms affects your statutory rights as a consumer under UK law ## Severability If any provision of these Terms is found to be unenforceable, the remaining provisions will remain in effect. ## Contact Information For legal notices: sbomify ltd 17-18 Berkeley Square Clifton, Bristol BS8 1HB England --- # What is an SBOM? URL: https://sbomify.com/what-is-sbom/ Description: A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in a piece of software. What goes in one, what the fields mean, how CycloneDX and SPDX differ, and what an SBOM cannot tell you. ## What is an SBOM? A **Software Bill of Materials (SBOM)** is a machine-readable inventory of every component, library, and dependency that makes up a piece of software. It records what each component is, which version is present, who produced it, and how the components relate to one another. The analogy people reach for is the ingredients list on the back of a chocolate bar, and it holds up well enough: an SBOM tells you what is inside something you would otherwise have to take on trust. The analogy breaks down in one important way, though. A chocolate bar has perhaps fifteen ingredients. A modern web application routinely has **several thousand** components, most of which arrived indirectly, pulled in by something else you chose deliberately. That is the actual problem an SBOM solves. Not "what did I install", which you already know, but "what is actually in the thing I am shipping", which almost nobody knows without generating one.
What is an SBOM
## What is actually in an SBOM? Most explanations stop at the definition. Here is the substance: an SBOM is a structured document with two layers of information — data about the document itself, and data about each component. The clearest published specification of what belongs in one is [CISA's 2026 Minimum Elements](/compliance/cisa-minimum-elements/), which defines 17 data fields. ### Component-level fields For every component in the software: | Field | What it records | | ---------------------------- | ----------------------------------------------------- | | **Component Name** | The name the producer assigned to the component | | **Component Version** | Which version is present | | **Component Producer** | The entity that created and identified the component | | **Component Identifiers** | Machine-readable lookup keys, typically a PURL or CPE | | **Component Hash Value** | A cryptographic digest of the actual artifact | | **Component Hash Algorithm** | Which algorithm produced that digest | | **Component License** | The licence the component is available under | | **Dependency Relationship** | Which components depend on which others | ### Document-level fields About the SBOM itself: | Field | What it records | | --------------------------------- | ----------------------------------------------- | | **SBOM Author** | Who created the SBOM data | | **SBOM Author Signature** | A digital signature attributable to that author | | **SBOM Timestamp** | When the data was last updated | | **SBOM Tool Name and Version** | What generated it | | **SBOM Generation Context** | Which lifecycle phase it was captured in | | **SBOM Data Format Name/Version** | Which format and version the file uses | | **SBOM Version** | Which revision of this SBOM this is | The document-level fields are the ones people forget, and they are the reason two SBOMs of the same software can disagree. An SBOM generated from source at build time and one generated by scanning a finished container image will produce different answers, and **SBOM Generation Context** is the field that tells you which you are holding. If you would rather read the files than read about them, our [annotated SBOM examples](/sbom-examples/) show the same software in both CycloneDX and SPDX, field by field. ## Why SBOMs matter ### Vulnerability response This is the use case that drives adoption. When a serious vulnerability lands in a widely used library, the question every organisation has to answer within hours is: **are we affected?** Without an SBOM, answering that means engineers grepping through repositories and lockfiles, and the answer arrives in days and is not trustworthy. With SBOMs, it is a query. The value is not that an SBOM finds the vulnerability — a scanner does that — but that it tells you _where you have the component_, across every product and version you ship. ### Licence obligations Every open source component carries a licence, and some carry obligations that attach to how you distribute your software. Copyleft licences in particular can require you to make source available. Discovering a GPL component in a proprietary product at audit time is considerably worse than discovering it at build time. The **Component License** field exists for this. ### Regulatory requirements SBOMs have moved from good practice to legal requirement in several jurisdictions. The [EU Cyber Resilience Act](/compliance/eu-cra/) makes them binding for products with digital elements sold in the EU. In the US, [Executive Order 14028](/compliance/eo-14028/) and [CISA's minimum elements](/compliance/cisa-minimum-elements/) set expectations for federal procurement, and the [FDA](/compliance/fda-medical-device/) requires them for medical devices. For the full picture — which frameworks apply to you, what each requires, and how the fields map — see the [SBOM Compliance Guide](/compliance/). ### Supplier due diligence If you buy software, an SBOM lets you assess what you are taking on before you deploy it, rather than discovering it during an incident. ## CycloneDX and SPDX Two formats matter in practice, and CISA's 2026 guidance names both: **[CycloneDX](https://cyclonedx.org/)** comes from OWASP and is standardised as ECMA-424. It was designed for application security use cases, and its structure reflects that — vulnerability and exploitability data are first-class. **[SPDX](https://spdx.dev/)** comes from the Linux Foundation and is standardised as ISO/IEC 5962. It grew out of licence compliance work and remains especially strong there, with a well-developed licence expression syntax. Both are machine-readable, both are actively maintained, and both are accepted by every major compliance framework. You do not need to pick a winner; you need to pick the one your tooling and your customers expect, and be able to produce the other when asked. Our [detailed comparison](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/) covers where they genuinely differ. ## What an SBOM cannot tell you Understanding the limits matters as much as understanding the definition, and this is where most introductions leave people with a false impression. **An SBOM is not a vulnerability report.** It lists components. Determining which of those components have known vulnerabilities is a separate step, performed by scanning the SBOM against a vulnerability database. The SBOM is the input, not the output. **A component with a vulnerability is not necessarily exploitable.** The vulnerable function may never be called. This gap is what [VEX](/faq/how-do-i-use-vex/) exists to close — it lets a producer state that a listed vulnerability does not affect the product, and why. **An SBOM is only as complete as the process that generated it.** Tools that read package manifests will not see a binary copied into a container image during the build. This is why [generating an SBOM by scanning a finished container image](/guides/docker/) captures the system packages accurately and can miss your application entirely. **An SBOM describes one version.** Every build produces a different artifact and needs its own SBOM. A single SBOM attached to a product generically, rather than to a specific release, is of limited use. **An unsigned SBOM asserts nothing about its own integrity.** Anyone can generate a document claiming to describe your software. The **SBOM Author Signature** field is what turns an inventory into evidence. ## Where SBOMs come from An SBOM has a lifecycle, and the parts after generation are where most organisations struggle. 1. **Generation** — produced during the build, when the dependency graph is authoritative. Our [language guides](/guides/) cover Python, JavaScript, Java, Go, Rust, C/C++, and a dozen others. 2. **Enrichment** — raw generator output is frequently missing licences, supplier names and hashes. These are precisely the fields regulators ask for. 3. **Distribution** — the SBOM has to reach the people who need it, whether that is a customer, an auditor, or your own security team. 4. **Analysis** — scanning against vulnerability data, checking licence obligations, and comparing versions over time. The generation step is well served by open source tooling. The later steps are where the [SBOM lifecycle](/features/generate-collaborate-analyze/) tends to break down. ## Frequently Asked Questions ### What does SBOM stand for? SBOM stands for **Software Bill of Materials**. It is a machine-readable inventory of the components, libraries, and dependencies that make up a software product. The term borrows from manufacturing, where a bill of materials lists every part used to build a physical product. ### What is the meaning of SBOM? An SBOM is a structured document listing every component in a piece of software — open source libraries, third-party packages, their versions, licences, and the relationships between them. It provides the transparency needed for vulnerability management, licence compliance, and supply chain security. ### How is SBOM pronounced? Usually "**S-bomb**", rhyming with "bomb". Some say it letter by letter, "S-B-O-M". Both are understood. ### What format should an SBOM be in? [CycloneDX](https://cyclonedx.org/) or [SPDX](https://spdx.dev/), in JSON. Both are accepted by every major compliance framework, and CISA's 2026 minimum elements name both. Some regimes are stricter: BSI TR-03183-2, which governs [EU CRA](/compliance/eu-cra/) compliance in Germany, requires CycloneDX 1.6+ or SPDX 3.0.1+. ### Who is responsible for producing an SBOM? Whoever produces the software. In practice generation is automated in CI, so it becomes an engineering responsibility rather than a compliance one — which is the right outcome, since only the build knows what actually went into the artifact. ### How often should an SBOM be regenerated? Every release. CISA's Frequency element expects each software version or update to have an associated SBOM, and a new one when component details change or an error is corrected. ### Is an SBOM confidential? That is your decision. An SBOM reveals your dependency graph, which some organisations treat as sensitive. Access controls may limit who receives it, but CISA's guidance is explicit that they should not prevent sharing with authorised parties, such as customers performing due diligence. ## Next steps - **[Generate your first SBOM](/guides/)** — step-by-step guides for 15+ languages and platforms - **[See real SBOMs](/sbom-examples/)** — the same software annotated in CycloneDX and SPDX - **[Compliance requirements](/compliance/)** — which frameworks apply to you and what each demands - **[SBOM formats compared](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/)** — CycloneDX and SPDX in detail - **[What is a dependency?](/2026/01/29/what-is-a-dependency-in-software/)** — the components SBOMs document ## Going deeper For a longer discussion of where SBOMs came from and where they are going, this interview with Allan Friedman, formerly of CISA, is the best single source: --- # Features URL: https://sbomify.com/features/ Description: Explore sbomify's comprehensive feature set for managing, sharing, and analyzing Software Bill of Materials (SBOMs) ## Core Features ### Generate, Collaborate, and Analyze Streamline your SBOM workflow from creation to analysis. Our comprehensive toolset helps you generate accurate SBOMs, collaborate with your team, and gain insights from your software supply chain data. Triage vulnerabilities with [multi-format VEX](/faq/how-do-i-use-vex/) (CycloneDX, OpenVEX, CSAF), and inventory your cryptography with [CBOMs](/faq/what-is-a-cbom/) including post-quantum readiness scoring. [Learn more about the SBOM lifecycle →](/features/generate-collaborate-analyze/) ### Trust Center Turn transparency into a competitive advantage. Share SBOMs, VEX statements, and security certifications (like SOC 2 and ISO 27001) with stakeholders through a branded, automated portal. Support for both public transparency and private, invited access ensures you stay in control. [Explore Trust Center →](/features/trust-center/) ### SBOM Hierarchy Understand complex relationships between your software components with our hierarchical view. Map dependencies across your entire software portfolio and identify potential vulnerabilities at any level. [Discover SBOM Hierarchy →](/features/sbom-hierarchy/) ## Integration & Automation ### Integrations Seamlessly connect sbomify with your existing tools and workflows. Our integration ecosystem supports popular CI/CD platforms, security tools, and development environments. [View available integrations →](/features/integrations/) ### Why Now? Understand the critical importance of SBOM adoption in today's software landscape. Learn how recent security mandates and industry trends are shaping the future of software supply chain security. [Read more about timing →](/features/why-now/) --- # A primer on the SBOM lifecycle for SBOM producers URL: https://sbomify.com/features/generate-collaborate-analyze/ Description: Streamline your Software Bill of Materials (SBOM) workflow with our comprehensive guide. Learn about SBOM generation, collaboration, and analysis best practices, and discover how to automate distribution with sbomify. The Software Bill of Materials (SBOM) lifecycle comprises three key stages: **Authoring**, **Distribution**, and **Analysis**.
> **TL;DR:** If this workflow sounds overly complex, rest assured that sbomify automates the entire process for you. All you need is a few lines of YAML in your CI/CD pipeline using the [sbomify Action](/sbomify-action/). --- ## Generation (a.k.a Authoring) Newcomers to SBOMs often underestimate the complexities involved in creating a complete SBOM (also known as 'authoring'). There are many [SBOM generation tools](/resources/#generation--authoring) available, so it might seem like it's just a matter of running one of these tools and you're done. While this _might_ suffice for internal SBOM needs when starting out, the reality is far more complicated if you need to meet industry requirements, such as the NTIA Minimum Elements. But don’t worry – we’re here to help. To produce an SBOM that complies with standards like the NTIA Minimum Elements, it's helpful to view the process in four phases.
### 1. Generate In the generation phase, you produce the actual SBOM. Generally speaking, there are two main ways to generate an SBOM: from **source** (e.g., using a lock file like `requirements.txt`) or during **build** (e.g., after installing dependencies from the lock file). Technically, you can also generate an SBOM during **run** time, but this approach is far less common. To meet the NTIA Minimum Elements, we generally recommend generating the SBOM during the build process. Whether you capture all **transitive dependencies** from the source depends on the ecosystem. Modern package managers like **uv** and **Poetry** for Python capture these dependencies, as do build tools for modern languages like **Rust** and **Go**. However, generating from source without a lock file (or using an older package manager) likely won’t capture all **transitive dependencies**. This is why tools like GitHub's Dependency Graph often cannot produce NTIA-compliant SBOMs. ### 2. Augment After generating your SBOM, you often need to _augment_ it with information that the generation tool likely missed. This may include details like: - Who are you? - What is the software’s license? - What version of the software is this? - Depending on the generation tool, this might already be set, but you may need to override it. - Who is supplying the software? - How can I get in touch with you? Many teams do this manually by merging a metadata SBOM file into the original SBOM, often using `jq`. While labor-intensive and error-prone, `jq` (and now [`jd`](https://github.com/josephburnett/jd)) remain the standard tools for this task. _If you want to avoid this step, our agent automates the entire process for you._ ### 3. Enrich Next is the _enrichment_ phase. Depending on the tool used to generate the SBOM, this step might be optional. Some tools automatically enrich the SBOM, typically by calling out to a third-party service (like PyPI) during generation to gather component details, such as licensing data. For example, the [sbomify Action](/sbomify-action/) (which can be used either with sbomify or in standalone mode) automatically augments your SBOM with identity data and enriches it with metadata from [ecosyste.ms](https://ecosyste.ms) to create the most complete SBOM possible – all within your CI pipeline before upload. ### 4. Signing / Attestation If you're serious about supply chain security, consider adding cryptographic signing and attestation to your workflow. This process involves not only generating an SBOM in your CI/CD pipeline but also cryptographically signing it. The primary security advantage is the ability to verify the SBOM’s integrity and authenticity at any time, reducing the need to blindly trust the distribution platform (like sbomify). You can read more about this in our [blog post on attestation](/2024/10/31/github-action-update-and-attestation/). --- ## Distribution (a.k.a Transportation) Each stage of the SBOM lifecycle is crucial to maintaining transparency and security within the software supply chain. Yet, effective collaboration remains a significant challenge. SBOMs must be shared efficiently with internal teams and external stakeholders, such as customers and partners – a process often referred to as "Transportation." Unfortunately, many organizations still rely on outdated distribution methods. Conversations with CTOs and CISOs reveal that email remains the primary sharing tool, reminiscent of how software patches were distributed in the 1990s. As a result, SBOMs are often stored haphazardly on internal file shares, leading to labor-intensive processes, disorganized storage, and outdated information. The limitations of these traditional sharing methods pose real risks to supply chain integrity. The [CISA SBOM Sharing Primer](https://www.cisa.gov/sites/default/files/2024-05/SBOM%20Sharing%20Primer.pdf) underscores the need for streamlined SBOM “Transport” to improve visibility and reduce risk. The document advocates for automated, standardized processes, cautioning that manual methods create inconsistencies and errors that could compromise the entire ecosystem. This is where sbomify transforms the landscape. sbomify automates the distribution and collaboration process, integrating directly into the Continuous Integration/Continuous Deployment (CI/CD) workflow to eliminate manual distribution and ad-hoc storage. Instead of relying on scattered email chains and file shares, sbomify ensures that stakeholders always have access to accurate, up-to-date SBOM data. By automating the process, sbomify minimizes manual work and significantly enhances security, reducing the risk of circulating outdated or incorrect information. You can learn more about this in our [SBOM Hub & Trust Center](/features/trust-center/) feature page. A frequently overlooked but essential step in the SBOM lifecycle is the creation of a consolidated [SBOM hierarchy](/features/sbom-hierarchy/), which is especially valuable in complex software architectures. Take a basic SaaS product, for instance: with an API service running in a Docker container and a JavaScript-based frontend, you’ll quickly accumulate multiple SBOMs – for the backend, the Docker environment, and the JavaScript libraries.
In such setups, merging the JavaScript and backend SBOMs might be feasible, but backend and Docker SBOMs remain distinct (at least in CycloneDX format). To maintain clarity, you can create a parent SBOM that links these individual SBOMs. The consolidation process, whether in CycloneDX or SPDX, often requires either complex scripts or a custom tool. With sbomify, this is built-in. _If this sounds complex, reach out, and we can automate SBOM hierarchy generation for you._ As the software industry increasingly recognizes the value of SBOMs for security and transparency, the need for efficient, automated collaboration tools becomes critical. Solutions like sbomify address this need by modernizing SBOM workflows and aligning with CISA’s best practices. For organizations aiming to streamline SBOM processes and bolster their cybersecurity, implementing a solution like sbomify is not just beneficial – it’s essential. --- ## Analysis The final phase in the SBOM lifecycle is the analysis phase. Generally, teams have two primary goals for an SBOM: - **Security Audit:** Identify all CVEs in a given SBOM. - **License Audit:** Ensure all software in the SBOM complies with internal policies. There are many tools available that focus on different problem spaces (many are listed [here](/resources/#analysis)). Two popular open-source tools for SBOM analysis are [Dependency Track](https://dependencytrack.org/) and [guac](https://github.com/guacsec/guac).
sbomify aims to be the [SBOM Hub](/features/trust-center/) that not only simplifies sharing SBOMs with stakeholders but also integrates with your existing toolset. For instance, sbomify integrates with [Dependency Track](/features/integrations/#dependency-track) and [OSV](/features/integrations/#osv) for analysis, enabling you to export SBOMs directly to your analysis tools. --- # Comprehensive SBOM Management for Complex Software Architectures URL: https://sbomify.com/features/sbom-hierarchy/ Description: Understanding Software Bill of Materials (SBOM) Hierarchy: Learn how to manage complex software architectures by grouping components under products, simplifying SBOM management and sharing. Creating a Software Bill of Materials (SBOM) for a simple microservice or a single dependency file is relatively straightforward. However, when it comes to representing an entire product or service, the process becomes significantly more complex. Most modern software systems are composed of multiple backend services, often written in different programming languages and running in separate Docker containers. Additionally, the architecture typically includes front-end components that are integral to the product. Capturing all of these elements accurately in SBOMs is essential but can quickly lead to a proliferation of SBOMs, each representing a different aspect of the system. As the complexity of your software architecture increases, so does the challenge of managing and sharing these SBOMs with stakeholders. For a even small product or service, you could end up with a dozen or more SBOMs, each detailing different parts of the system. Even with the aid of automated tooling, the sheer number of SBOMs can create confusion for stakeholders who need to understand the overall structure and security of the software. Without a clear and organized way to present these SBOMs, the risk of miscommunication and errors increases, potentially compromising the effectiveness of the SBOMs in enhancing transparency and security. ![SBOM hub](/assets/images/d2/sbom-hierarchy.svg) At sbomify, we recognize this challenge and have developed a solution that simplifies SBOM management for complex software architectures. By grouping components directly under products, sbomify allows you to organize your SBOMs in a way that reflects the structure of your entire system. This approach not only makes it easier to manage multiple SBOMs but also provides stakeholders with a clear, organized view of the software's architecture. Whether you're dealing with backend services, front-end components, or both, sbomify ensures that every part of your product is captured and presented in a way that's easy to understand and analyze. Moreover, you can both export and share SBOMs on any of these levels. This fits perfectly into our [Generate, Collaborate, and Analyze](/features/generate-collaborate-analyze/) workflow. The product–component grouping in sbomify is designed to reduce confusion and streamline the SBOM sharing process. Instead of dealing with a disjointed collection of SBOMs, stakeholders can view and interact with a structured representation of the software, with products and components neatly organized. This approach not only improves the clarity and usability of SBOMs but also enhances the overall efficiency of your software development and security processes. By leveraging sbomify's grouping capabilities, you can ensure that your SBOMs are both comprehensive and easily accessible, enabling better collaboration and more informed decision-making across your organization. You can distribute these hierarchies easily using our [SBOM Hub & Trust Center](/features/trust-center/). ## Release Management & Component Reuse Beyond static hierarchies, sbomify supports full **release management** for your SBOMs. You can define a Product Release that points to specific versions of component SBOMs. This means: - **Accurate History**: When you create a new release, your old SBOMs remain unchanged and accurate for that point in time. - **Efficient Reuse**: Because we leverage linkage, multiple products (or versions of a product) can reuse the same component SBOMs. You simply create a composition that points to the relevant artifacts for a given release, avoiding duplication and keeping your data clean.
--- # Integrations URL: https://sbomify.com/features/integrations/ Description: Seamlessly integrate SBOM generation, analysis, and enrichment into your existing workflow. CI/CD & Generation Generate SBOMs automatically in your pipelines. We support all major CI/CD providers. New: Interactive Setup Wizard Read the FAQ → The fastest way to get started. Run the wizard from the root of your repository and it scans your lockfiles, creates your products and components, registers OIDC trusted publishing, and writes a ready-to-commit .github/workflows/sboms.yml. No tokens to copy, no YAML to hand-write. docker run --rm -it \ -v "$(pwd):/github/workspace" \ -w /github/workspace \ ghcr.io/sbomify/sbomify-action \ sbomify-action wizard GitHub Documentation →View on Marketplace → GitHub is at the core of many organizations. Our sbomify Action supports OIDC trusted publishing, so no long-lived token secret is needed. permissions: id-token: write # OIDC trusted publishing, no token needed steps: - name: Upload SBOM uses: sbomify/sbomify-action@master env: COMPONENT_ID: 'my-component-id' LOCK_FILE: 'requirements.txt' COMPONENT_NAME: 'my-awesome-app' COMPONENT_VERSION: ${{ github.ref_name }} AUGMENT: true ENRICH: true Prefer token auth, or using another CI system? Set TOKEN: ${SBOMIFY_TOKEN} instead. GitLab Documentation → View on GitHub → Use our Docker image directly in GitLab CI with built-in caching support. generate-sbom: image: ghcr.io/sbomify/sbomify-action cache: key: sbomify-cache paths: - .sbomify-cache/ variables: SBOMIFY_CACHE_DIR: "${CI_PROJECT_DIR}/.sbomify-cache/sbomify" SYFT_CACHE_DIR: "${CI_PROJECT_DIR}/.sbomify-cache/syft" LOCK_FILE: poetry.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action Bitbucket Documentation → View on GitHub → Seamlessly integrate with Bitbucket Pipelines using our Docker image with built-in caching. pipelines: default: - step: caches: - sbomify script: - pipe: docker://ghcr.io/sbomify/sbomify-action:latest variables: SBOMIFY_CACHE_DIR: "${BITBUCKET_CLONE_DIR}/.sbomify-cache/sbomify" SYFT_CACHE_DIR: "${BITBUCKET_CLONE_DIR}/.sbomify-cache/syft" LOCK_FILE: poetry.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" definitions: caches: sbomify: .sbomify-cache Docker Documentation → View on GHCR → For any other CI/CD system, use our multi-arch (amd64 and arm64) Docker image directly. Generators are fetched on first use, digest-pinned and cached — nothing to install. # Create persistent cache volume docker volume create sbomify-cache docker run --rm \ -v $(pwd):/github/workspace \ -v sbomify-cache:/cache \ -w /github/workspace \ -e SBOMIFY_CACHE_DIR=/cache/sbomify \ -e SYFT_CACHE_DIR=/cache/syft \ -e LOCK_FILE=/github/workspace/requirements.txt \ -e OUTPUT_FILE=/github/workspace/sbom.cdx.json \ -e UPLOAD=false \ -e ENRICH=true \ ghcr.io/sbomify/sbomify-action Local CLI View on PyPI → Run the CLI on your machine with uvx or pipx for local development, one-off SBOMs and the setup wizard. Generators are downloaded on first use and cached, exactly as they are in the Docker image, so there is nothing else to install. Read the guide → # Run without installing anything uvx sbomify-action --lock-file requirements.txt \ --enrich --no-upload -o sbom.cdx.json # Or with pipx pipx run sbomify-action --lock-file requirements.txt \ --enrich --no-upload -o sbom.cdx.json # Environment variables work too export LOCK_FILE=requirements.txt export ENRICH=true export UPLOAD=false uvx sbomify-action Supported Ecosystems Generate SBOMs from lockfiles across 17 ecosystems, plus container images, directory scans and Yocto/OpenEmbedded builds. Python requirements.txt poetry.lock Pipfile.lock uv.lock pyproject.toml JavaScript package.json package-lock.json yarn.lock pnpm-lock.yaml bun.lock Java pom.xml build.gradle build.gradle.kts gradle.lockfile Go go.mod go.sum Rust Cargo.lock Ruby Gemfile.lock PHP composer.json composer.lock .NET / C# packages.lock.json Swift Package.swift Package.resolved Dart pubspec.lock Elixir mix.lock Scala build.sbt C++ conan.lock Terraform .terraform.lock.hcl Haskell stack.yaml.lock stack.yaml cabal.project.freeze Erlang rebar.lock Clojure deps.edn project.clj Container Images Generate SBOMs directly from container images using DOCKER_IMAGE instead of a lockfile. Scans all layers and installed packages. Yocto / OpenEmbedded Batch process SPDX SBOMs from Yocto builds. Extracts .spdx.tar.zst archives, uploads package SBOMs, and tags them with a product release. SBOM Generators Four generators with automatic fallback. The best tool for each ecosystem is selected automatically. cyclonedx-py Priority 10 Native Python generator. Most accurate for Python ecosystems. Python cargo-cyclonedx Priority 10 Native Rust generator. Most accurate for Rust ecosystems. Rust cdxgen Priority 20 Broadest ecosystem support. Best choice for Java/Gradle and multi-language projects. Python JS Java Go Rust Ruby +8 more Syft Priority 35 Comprehensive scanner by Anchore. Supports CycloneDX and SPDX output including Terraform. Python JS Go Terraform Docker +7 more CycloneDX Default format. Versions 1.3 through 1.7 supported depending on generator. SBOM_FORMAT=cyclonedx SPDX Versions 2.2, 2.3, and 3.0.1 supported, validated against official schemas. SBOM_FORMAT=spdx Beyond SBOMs The same pipeline can upload pre-authored VEX, CBOM, and HBOM documents verbatim with BOM_TYPE=vex, cbom, or hbom. Vulnerability Analysis Comprehensive scanning powered by industry-leading databases. Google OSV We integrate with the Open Source Vulnerability (OSV) database to provide precise, distributed vulnerability intelligence across a wide range of ecosystems. Dependency Track Leverage the power of OWASP Dependency-Track for continuous component analysis. Upload SBOMs directly from CI/CD with UPLOAD_DESTINATIONS=dependency-track. CI/CD Direct Upload: sbomify-action can upload SBOMs directly to your Dependency Track instance from any CI pipeline. Enterprise Bring Your Own: Enterprise customers can connect their existing Dependency Track instance for unified visibility. Enrichment Data Sources We integrate with 12 data sources to add metadata to your SBOM components: descriptions, licenses, supplier information, and more. Pre-computed Databases (Fastest) Local data with zero network latency. Checked first for maximum performance. LicenseDB Pre-computed license database covering 28 Linux distro versions. Provides authoritative license data for APK, DEB, and RPM packages. pkg:apk/* pkg:deb/* pkg:rpm/* Lifecycle Database CLE lifecycle dates (release, end-of-support, end-of-life) for major runtimes and frameworks following ECMA-428. Python PHP Go Rust Django Rails +more Native Package Registries Authoritative data direct from the ecosystem's official source. PyPI Python Package Index pkg:pypi/* crates.io Rust Package Registry pkg:cargo/* pub.dev Dart/Flutter Packages pkg:pub/* Debian Sources Debian Package Archive pkg:deb/debian/* Conan Center C/C++ (Conan) pkg:conan/* Package Aggregators Multi-ecosystem services providing broad coverage. deps.dev Google Open source dependency insights from Google. Covers most major ecosystems. Community-driven package metadata and project health metrics across ecosystems. Fallback Sources Additional coverage when primary sources do not have data. PURL Extraction Local extraction from package URLs. Maps namespaces to suppliers without API calls. ClearlyDefined Community-curated license and metadata for open source components. Repology Cross-distribution package tracking for Linux packages. How it works: Enrichment happens automatically when using our GitHub Action or CLI with the enrich flag. ENRICH=true or --enrich Augmentation Providers Add organizational metadata to your SBOM: supplier info, manufacturer details, VCS context, and more. sbomify API Pull organizational metadata from your sbomify workspace: supplier, manufacturer, authors, and declared license. Local Config Override metadata via sbomify.json in your repository for supplier, authors, license, and VCS info. CI/CD Auto-Detection Automatically detects VCS URL, commit SHA, and branch from GitHub Actions, GitLab CI, and Bitbucket Pipelines environment variables. Fields Added Supplier, manufacturer, authors, license, lifecycle phase, repository URL, commit SHA, branch/ref. How it works: Augmentation pulls metadata from sbomify and your CI environment. AUGMENT=true or --augment --- # The Growing Importance of SBOMs in Cybersecurity Compliance URL: https://sbomify.com/features/why-now/ Description: Why SBOMs matter now: Executive Order 14028, the EU Cyber Resilience Act, PCI DSS 4.0, and the FDA are turning SBOMs into a baseline compliance requirement across industries. The cybersecurity landscape has evolved rapidly in recent years, driven largely by increased awareness of software supply chain vulnerabilities. A significant milestone in this evolution was the US government's introduction of [Executive Order 14028](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity) in May 2021. This executive order responded directly to escalating cyber threats targeting critical infrastructure, government agencies, and private enterprises. One of its key components mandated Software Bill of Materials (SBOMs) for all vendors selling software to the federal government. This SBOM mandate has profoundly impacted the entire software industry. SBOMs provide detailed documentation of software components and are now recognized as essential tools for ensuring supply chain transparency and security. The requirement's cascading effect is particularly evident in compliance-related areas, where major regulatory frameworks and standards bodies increasingly incorporate SBOM requirements into their guidelines. A prime example is the EU's Cyber Resilience Act (CRA), which has established these firm implementation dates: - Goes into force: **December 10, 2024** () - Mandatory reporting begins: **September 11, 2026** () - Full implementation required: **December 11, 2027** () These dates represent critical milestones for organizations operating in or selling to the EU market. Similarly, in the United States, the NIST Cybersecurity Framework has established SBOMs as a crucial element of comprehensive cybersecurity practices. As regulatory requirements continue to evolve, SBOMs are becoming the de facto standard for software supply chain transparency. Organizations that haven't yet implemented SBOM practices risk falling behind in both compliance and overall cybersecurity posture. The benefits of adoption are clear: - Enhanced visibility into software components - Improved vulnerability identification and remediation - Stronger trust relationships with customers and partners Time is critical in this evolving landscape. Organizations that delay SBOM adoption risk falling out of compliance with regulatory requirements and industry best practices. More importantly, they expose themselves to increased risk in an era of increasingly sophisticated cyber threats. For organizations that haven't yet integrated SBOMs into their software development and procurement processes, the urgency is clear: SBOM adoption isn't just about compliance – it's fundamental to ensuring the security and resilience of modern software infrastructure. --- # Trust Center URL: https://sbomify.com/features/trust-center/ Description: Build customer confidence with a dedicated trust center. Share SBOMs, compliance documents, and security artifacts publicly to demonstrate transparency. Turn transparency into a competitive advantage. Showcase your security posture with a branded, automated Trust Center. View Live Trust Center Explore Demo Everything You Need A complete platform for managing and sharing your security posture Branded Portal Your trust center, your brand. Use your own domain and logo to present a unified professional image to customers. Automated Publishing Stop manual uploads. Your trust center stays in sync with your CI/CD pipeline, automatically publishing new SBOMs for every software release. Manage complex hierarchies with ease. Flexible Access Control Choose your audience. Make your Trust Center public for broad transparency, or private for invited internal and external stakeholders only. Why Now The New Standard for Transparency Trust Centers are becoming essential. Buyers now expect vendors to provide near real-time data about security posture and compliance status. EU Cyber Resilience Act (CRA) SBOMs are now expected as part of Trust Centers for stakeholders PCI DSS 4.0 First major framework adopting SBOMs as security posture requirement Built on Open Principles Vendor agnostic No lock-in SBOM-driven CRA-focused Self-hostable Comprehensive Coverage Share More Than Just SBOMs A complete trust center goes beyond dependencies. Provide a comprehensive view of your security posture by hosting all critical artifacts in one searchable library. Everything is also consumable programmatically via the Transparency Exchange API (TEA), and your security contact details can be published as an RFC 9116 security.txt. ✓ VEX and CBOM Artifacts Release-level VEX and CBOM downloads next to every SBOM, with a VEX-applied vulnerability posture card ✓ Signed Artifacts Signature and provenance badges so consumers can verify authenticity ✓ Security Certifications SOC 2, ISO 27001, and other audits ✓ Penetration Test Reports Share summaries or full reports securely ✓ Compliance Attestations Proof of regulatory adherence ✓ Programmatic Compliance Express compliance documents programmatically alongside your SBOMs SOC 2 Type II Report Verified Updated 2 days ago Widget Service v1.8 SBOM Automated via GitHub Actions Pentest Summary Public Latest report Future-Proof Your Compliance Regulations like the EU Cyber Resilience Act (CRA) and US Executive Order 14028 are making transparency mandatory. A public trust center isn't just about marketing – it's about staying compliant. EU CRA Ready Meets requirements for documentation, vulnerability disclosure, and supply chain transparency. NIST & NTIA Aligned Supports minimum elements, VEX, and standard formats required for federal procurement. Real-World Impact See how Trust Centers transform the way you do business Accelerate Sales "Do you have a SOC 2?" Send a link instead of scheduling a call. Reduce questionnaire response times from weeks to minutes. Sales Enablement Build Trust Show, don't just tell. Proactive transparency proves your commitment to security before a prospect even asks. Brand Reputation Streamline Ops Eliminate ad-hoc email requests. Give customers self-service access to the documents they need, 24/7. Operational Efficiency Ready to build trust? Start Your Trust Center View Integrations --- # The Ultimate SBOM Compliance Guide (2026) URL: https://sbomify.com/compliance/ Description: Complete SBOM compliance guide covering the CISA 2026 minimum elements, NIST 800-53, NIST 800-171, EU Cyber Resilience Act (CRA), NIS2 Directive, UK Software Security Code of Practice, FDA medical device requirements, and PCI DSS 4.0. Includes CycloneDX and SPDX schema mappings. New to SBOMs? Start with [What is an SBOM?](/what-is-sbom/) to learn the basics, or explore our [SBOM generation guides](/guides/) for language-specific tutorials. Software Bill of Materials (SBOM) compliance requirements are rapidly evolving across the United States and European Union. Whether you're navigating the **NTIA minimum elements**, preparing for the **EU Cyber Resilience Act (CRA)**, meeting **NIS2 Directive** obligations, or submitting medical devices to the **FDA**, this guide provides a comprehensive reference for SBOM requirements across all major frameworks.

Feeling overwhelmed? If all these frameworks, acronyms, and requirements look like gibberish, you're not alone. SBOM compliance can be complex, but you don't have to figure it out on your own.

Get Help With Compliance
**Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. --- ## Compliance Frameworks ### US Frameworks - **[Executive Order 14028 (2021)](/compliance/eo-14028/)** - The binding US directive that kicked off federal SBOM adoption. _Updated:_ OMB Memorandum M-26-05 (January 2026) rescinded the mandatory attestation memos (M-22-18, M-23-16), shifting to an agency-led, risk-based approach. EO 14028 itself remains in effect. - _Who it affects:_ US federal agencies and software vendors selling to the government - **[NTIA Minimum Elements (2021)](/compliance/ntia-minimum-elements/)** - The foundational US baseline for SBOM data fields - _Who it affects:_ Software producers selling into federal or critical-infrastructure supply chains. Referenced by FDA, CISA, and other frameworks as the baseline. - **[CISA Minimum Elements (2025 Draft)](/compliance/cisa-minimum-elements/)** - Updated US guidance with new fields for hash, license, and generation context - _Who it affects:_ Organizations in US public-sector and critical-infrastructure contexts - **[FDA Medical Device Guidance (2025)](/compliance/fda-medical-device/)** - Healthcare sector SBOM requirements with lifecycle properties - _Who it affects:_ Medical device manufacturers and their software suppliers - **[NIST SP 800-53 Rev 5](/compliance/nist-800-53/)** - Federal security control catalog with supply chain risk management controls - _Who it affects:_ US federal agencies and organizations subject to FISMA - **[NIST SP 800-171 Rev 3](/compliance/nist-800-171/)** - CUI protection requirements for nonfederal systems - _Who it affects:_ DoD contractors and organizations handling Controlled Unclassified Information (CUI) ### EU Frameworks - **[EU Cyber Resilience Act (CRA)](/compliance/eu-cra/)** - Binding EU law requiring SBOMs for products with digital elements - _Who it affects:_ Manufacturers, importers, and distributors placing digital products on the EU market - **[EU NIS2 Directive](/compliance/eu-nis2/)** - EU cybersecurity law for essential and important entities - _Who it affects:_ EU entities responsible for cybersecurity risk management and incident reporting - **[BSI TR-03183-2 (v2.1.0)](/compliance/bsi-tr-03183/)** - German Federal Office for Information Security technical guideline defining concrete SBOM format and content requirements aligned with the EU CRA - _Who it affects:_ Manufacturers placing products with digital elements on the EU market, and vendors selling into German federal procurement ### UK Frameworks - **[Software Security Code of Practice (UK, May 2025)](/compliance/uk-software-security-code-of-practice/)** - Voluntary UK government code setting baseline secure software development, supply chain resilience, and customer communication expectations - _Who it affects:_ Organisations that **develop and/or sell software to businesses or other organisations** (especially B2B/proprietary software vendors and SaaS) ### Industry Standards - **[PCI DSS 4.0](/compliance/pci-dss/)** - Payment card industry software component inventory requirements - _Who it affects:_ Merchants and service providers handling cardholder data ### Reference Documents - **[CISA Framing Document (3rd Edition)](/compliance/cisa-framing/)** - Baseline attribute definitions and format normalization - _Who it affects:_ SBOM producers/consumers needing shared terminology and format crosswalk - **[CISA SBOM Sharing Lifecycle Report](/compliance/cisa-sharing-lifecycle/)** - Operational guidance for SBOM distribution - _Who it affects:_ Organizations distributing or retrieving SBOMs across supply chains --- ## Technical Resources - **[Schema Crosswalk: CycloneDX and SPDX](/compliance/schema-crosswalk/)** - Complete field mappings for CycloneDX 1.7, SPDX 2.3, and SPDX 3.0 - **[CLE: Common Lifecycle Enumeration](/compliance/cle/)** - Standard for machine-readable component lifecycle events (EOL, EOS) --- ## Master Requirements Comparison This table compares SBOM data field expectations across major frameworks. All frameworks assume machine-readable SBOMs in a commonly used format (e.g., CycloneDX, SPDX). **Framework context:** - **EO 14028** is a binding US Executive Order for federal agencies and influences procurement expectations for software suppliers - **NTIA 2021** and **CISA 2025** are US guidance documents (not law) - **NIST 800-53** is the federal security control catalog; **NIST 800-171** applies to nonfederal organizations handling CUI - **CRA** and **NIS2** are binding EU legislation - **FDA 2025** is guidance for medical device premarket submissions - **PCI DSS 4.0** is an industry standard for payment card security - **UK SSCoP 2025** is voluntary UK government guidance for software vendors | Property | EO 14028 | NTIA 2021 | CISA 2025 | CRA | NIS2 | FDA 2025 | PCI DSS 4.0 | UK SSCoP 2025 | | ------------------------------- | :------: | :-------: | :-------: | :-: | :--: | :------: | :---------: | :-----------: | | **Document-Level Metadata** | | | | | | | | | | SBOM Author | - | ✓ | ✓ | - | - | ✓ | - | - | | Timestamp | - | ✓ | ✓ | - | - | ✓ | - | - | | Tool Name/Version | - | - | ✓ | - | - | - | - | - | | Generation Context | - | - | ✓ | - | - | - | - | - | | **Component Identification** | | | | | | | | | | Supplier / Software Producer | - | ✓ | ✓ | - | - | ✓ | - | - | | Component Name | - | ✓ | ✓ | - | ● | ✓ | - | - | | Component Version | - | ✓ | ✓ | - | ● | ✓ | - | - | | Unique Identifiers (purl/CPE) | - | ✓ | ✓ | - | - | ✓ | - | - | | Component Hash | - | - | ✓ | - | - | - | - | - | | **Relationships** | | | | | | | | | | Dependency Relationship | ● | ✓ | ✓ | ✓* | - | ✓ | - | - | | **Legal** | | | | | | | | | | License | - | - | ✓ | - | - | - | - | - | | **Lifecycle** | | | | | | | | | | Support Level | - | - | - | - | - | ✓ | - | ✓‡ | | End-of-Support Date | - | - | - | - | - | ✓ | - | ✓‡ | | **Process / Access** | | | | | | | | | | SBOM provision to purchasers | ✓ | - | - | - | - | - | - | - | | SBOM production required | - | - | - | ✓ | - | - | ✓† | - | | Authority access on request | - | - | - | ● | - | - | - | - | | User access location disclosure | - | - | - | ● | - | - | - | - | | Supply chain security measures | ✓ | - | - | - | ✓ | - | ✓† | ✓‡ | | Vulnerability handling process | ✓ | - | - | - | ✓ | - | ✓† | ✓‡ | **Legend:** - **✓** = Expected (NTIA/CISA minimum element, FDA recommended, EO 14028/NIS2 required) - **✓*** = CRA requires at least top-level (direct) dependencies - **✓†** = PCI DSS Req 6.3.2 (best practice until 31 Mar 2025, then required) - **✓‡** = UK SSCoP voluntary guidance (not as SBOM fields, but as customer-facing expectations) - **●** = Conditional or implied (EO 14028: SBOM must include "supply chain relationships"; CRA: where applicable; NIS2: for in-scope entities per Regulation 2024/2690) - **-** = Not specified by this framework **Important notes:** - EO 14028 requires SBOM provision in federal procurement but defers field-level requirements to NTIA minimum elements. Note: OMB M-26-05 (January 2026) rescinded the mandatory attestation memos (M-22-18, M-23-16), making vendor attestations optional and shifting to agency-led risk-based assurance. EO 14028's core SBOM and supply chain provisions remain in effect - NTIA 2021 and CISA 2025 define "minimum elements" as guidance, not legal requirements - NTIA 2021 discusses license information as a key SBOM use case and useful content, but it is not listed among the minimum SBOM data fields - CISA 2026 is final guidance and explicitly does not create new requirements - FDA uses "should" language (recommendations for premarket submissions) - CRA is binding law but does not specify individual data fields beyond dependency scope - NIS2 does not mandate SBOMs by name, but the implementing regulation (2024/2690) requires "information describing the hardware and software components used" for in-scope entities - PCI DSS 4.0 requires software component inventories for bespoke/custom software (Req 6.3.2) to facilitate vulnerability and patch management - UK SSCoP 2025 is voluntary guidance; it does not mandate SBOMs by name but expects software composition awareness, vulnerability management, and customer lifecycle communication --- ## Frequently Asked Questions ### What is SBOM compliance? SBOM compliance refers to meeting the requirements set by various government regulations and industry standards for creating, maintaining, and sharing Software Bills of Materials. Key frameworks include the US [NTIA minimum elements](/compliance/ntia-minimum-elements/), the EU [Cyber Resilience Act](/compliance/eu-cra/), and sector-specific requirements like [FDA medical device guidance](/compliance/fda-medical-device/). ### Is an SBOM legally required? It depends on your jurisdiction and industry. In the EU, the [Cyber Resilience Act](/compliance/eu-cra/) legally requires SBOMs for products with digital elements. In the US, SBOMs are required for software sold to the federal government (per [Executive Order 14028](/compliance/eo-14028/)) and recommended for [FDA medical device submissions](/compliance/fda-medical-device/). The [NIS2 Directive](/compliance/eu-nis2/) requires supply chain security measures that SBOMs help evidence. ### What format should my SBOM be in? Both [CycloneDX](https://cyclonedx.org/) and [SPDX](https://spdx.dev/) are widely accepted. The EU CRA requires a "commonly used and machine-readable format," and both formats qualify. See our [schema crosswalk](/compliance/schema-crosswalk/) for field mappings between formats. ### What are the minimum SBOM fields required? The [CISA 2026 minimum elements](/compliance/cisa-minimum-elements/) define 23 elements in three groups: nine SBOM Metadata fields, eight Component Data fields, and six Practices and Processes. They replaced the seven fields of the [NTIA 2021 baseline](/compliance/ntia-minimum-elements/) on 29 July 2026, adding ten new elements including Component Hash Value, Component Hash Algorithm, Component License, and SBOM Author Signature. ### How do I generate an SBOM? See our comprehensive [SBOM generation guides](/guides/) covering Python, JavaScript, Java, Go, Rust, and 10+ other languages and platforms. For a list of tools, visit our [SBOM resources page](/resources/). --- ## Additional Resources **Official Source Documents:** - [Executive Order 14028 – Improving the Nation's Cybersecurity (2021)](https://www.gsa.gov/technology/government-it-initiatives/cybersecurity/executive-order-14028) - [NTIA Minimum Elements for a Software Bill of Materials (2021)](https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf) - [2026 Minimum Elements for a Software Bill of Materials (SBOM)](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom) - [CISA Framing Software Component Transparency (3rd Edition)](https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf) - [CISA SBOM Sharing Lifecycle Report](https://www.cisa.gov/sites/default/files/2023-04/sbom-sharing-lifecycle-report_508.pdf) - [EU Cyber Resilience Act (Regulation 2024/2847)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [EU NIS2 Directive (Directive 2022/2555)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32022L2555) - [PCI DSS v4.0.1 (June 2024)](https://www.pcisecuritystandards.org/document_library/) - [NIST SP 800-53 Rev 5 (September 2020, updated December 2024)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) - [NIST SP 800-171 Rev 3 (May 2024)](https://csrc.nist.gov/pubs/sp/800/171/r3/final) - [Software Security Code of Practice (UK Government, May 2025)](https://www.gov.uk/government/publications/software-security-code-of-practice) - [CLE Specification (ECMA-428)](https://ecma-international.org/publications-and-standards/standards/ecma-428/) **Related sbomify Resources:** - [What is an SBOM?](/what-is-sbom/) - Introduction to Software Bills of Materials - [SBOM Generation Guides](/guides/) - Language and platform-specific tutorials - [SBOM Resources & Tools](/resources/) - Comprehensive tool directory
Edit this page on GitHub
--- # BSI TR-03183-2: SBOM Requirements (v2.1.0) URL: https://sbomify.com/compliance/bsi-tr-03183/ Description: Guide to the German Federal Office for Information Security (BSI) Technical Guideline TR-03183-2 v2.1.0, which defines SBOM format and content requirements aligned with the EU Cyber Resilience Act. [← Back to Compliance Overview](/compliance/) **Who it affects:** Manufacturers placing products with digital elements on the EU market who need a concrete technical baseline for SBOM format and content. BSI TR-03183-2 is widely treated as the de facto reference for satisfying the [EU Cyber Resilience Act](/compliance/eu-cra/)'s SBOM expectations, especially for German federal procurement.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The [BSI Technical Guideline TR-03183-2](https://bsi.bund.de/dok/TR-03183-en) ("Cyber Resilience Requirements - Part 2: SBOM"), published by Germany's Federal Office for Information Security (BSI), specifies the format and content of Software Bills of Materials. Where the [EU Cyber Resilience Act](/compliance/eu-cra/) tells manufacturers _that_ an SBOM is required, BSI TR-03183-2 spells out _what_ that SBOM must look like in practice. The current version is **v2.1.0** (2025-08-20), and it remains current as of August 2026. It is binding for German federal procurement and is increasingly referenced by EU-market vendors as a concrete baseline that aligns with CRA expectations. TR-03183 is now a four-part family. Part 2 is the SBOM specification covered on this page; the other parts surround it: | Part | Version | Date | Scope | | --------------------------------------------------- | ------- | -------------- | --------------------------------------------------------------------------------------------- | | Part 1 - General requirements | 1.0.0 | 31 July 2026 | Risk-based control selection (Adaptable Risk-based Controls), with an OSCAL control catalogue | | **Part 2 - Software Bill of Materials (SBOM)** | 2.1.0 | 20 August 2025 | SBOM format, content, data fields, dependency depth, licences | | Part 3 - Vulnerability Reports and Notifications | 1.0.0 | September 2025 | Receiving vulnerability reports: security.txt (RFC 9116), CVD policy, CSAF v2.0 advisories | | Part H - Conformity based on full quality assurance | 1.1.0 | 30 May 2026 | Demonstrating CRA conformity via an ISO/IEC 27001 ISMS (Module H) | BSI is explicit that the guideline creates no obligations and gives no presumption of conformity, and that TR-03183 "will be gradually developed further and replaced by the corresponding harmonized European standards as soon as they become available." See our [EU CRA page](/compliance/eu-cra/) for where those standards stand. ## Format requirements (§4) | Requirement | Detail | | ----------- | ------------------------------------------------ | | Encoding | JSON or XML | | Format | CycloneDX v1.6 or later, OR SPDX v3.0.1 or later | ## SBOM-level required fields (§5.2.1) | Field | Description | | --------------- | ------------------------------------------------ | | Creator of SBOM | Email address or URL identifying the SBOM author | | Timestamp | Date and time the SBOM was compiled | ## Component-level required fields (§5.2.2) | Field | Description | | --------------------- | ----------------------------------------------------------------------- | | Component creator | Email address or URL | | Component name | Name of the component | | Component version | Version string, or RFC 3339 file modification date if no version exists | | Filename | Actual filename of the component (not a path) | | Dependencies | Dependency relationships, with a completeness indicator | | Distribution licences | SPDX identifiers or expressions | | Hash | SHA-512 of the deployable component | | Executable property | Whether the component is executable | | Archive property | Whether the component is an archive | | Structured property | Whether the component is structured or unstructured | ## Conditional fields - required if present (§5.2.3, §5.2.4) - **SBOM-URI** - canonical URI of the SBOM document - **Source code URI** - location of the component's source code - **URI of deployable form** - location of the deployable artifact - **Other unique identifiers** - CPE, purl, etc. - **Original licences** - upstream licence declarations ## Critical requirements - **No vulnerability data in the SBOM** (§3.1) - vulnerability information must be exchanged out-of-band (e.g. via VEX/VDR), not embedded in the SBOM itself. - **SPDX licence identifiers** (§6.1) - all licence values must use SPDX identifiers or expressions; free-form licence strings are not compliant. ## Score uploaded SBOMs against the BSI checklist sbomify ships a **BSI TR-03183-2 v2.1.0** plugin that grades each uploaded SBOM against the format, SBOM-level, and component-level requirements above and surfaces the result on the SBOM detail page. Enable it from the **Plugins** page in your workspace sidebar: ## Related frameworks - [EU Cyber Resilience Act (CRA)](/compliance/eu-cra/) - the regulation BSI TR-03183-2 is designed to support - [Schema Crosswalk](/compliance/schema-crosswalk/) - field mappings across CycloneDX 1.7, SPDX 2.3, and SPDX 3.0 - [NTIA Minimum Elements (2021)](/compliance/ntia-minimum-elements/) - the US baseline; BSI's component fields go further ## Additional resources - [BSI TR-03183 official page (English)](https://bsi.bund.de/dok/TR-03183-en) - [BSI CycloneDX Property Taxonomy](https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy) - the property names BSI uses to express its extra fields in CycloneDX --- **Disclaimer:** This page represents our interpretation of the referenced framework. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # CISA 2026 SBOM Minimum Elements: All 23 Elements Listed URL: https://sbomify.com/compliance/cisa-minimum-elements/ Description: The 2026 Minimum Elements for a Software Bill of Materials, published 29 July 2026 by CISA with 17 partner agencies. Updates and replaces the NTIA 2021 baseline. Covers all 23 elements across SBOM Metadata, Component Data, and Practices and Processes, with the full change log from 2021. [← Back to Compliance Overview](/compliance/) **Who it affects:** Organizations that produce software, procure software, or operate software. The 2026 minimum elements apply to SBOMs for all software, including open source software, AI software, and SaaS.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The [2026 Minimum Elements for a Software Bill of Materials (SBOM)](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom) was published on **29 July 2026** by the US Cybersecurity and Infrastructure Security Agency (CISA), together with the NSA, the FBI, and fifteen international partner agencies. In CISA's own words, the document "updates and replaces the Minimum Elements for a Software Bill of Materials published by the National Telecommunications and Information Administration (NTIA)." The [NTIA 2021 minimum elements](/compliance/ntia-minimum-elements/) are no longer the operative US baseline. **This is not a new compliance obligation.** The document is explicit: "The minimum elements do not create new requirements; they refine how organizations should generate and request SBOMs." Data management, storage practices, and precise encoding details are out of scope. The 2026 update incorporates public feedback from the 2025 draft comment period. Relative to 2021 it adds **10 new elements**, substantially revises **8**, makes minor updates to **5**, and **removes 1**. ### Co-authoring organizations CISA, NSA, FBI, ASD's ACSC (Australia), Cyber Centre (Canada), NÚKIB (Czechia), ANSSI (France), BSI (Germany), CERT-In (India), ACN (Italy), METI and NCO (Japan), NIS/NCSC (Netherlands and UK), KISA (South Korea), NCSC-NL, NCSC-NZ, NASK (Poland), and NBU (Slovakia). ## The 23 Elements The minimum elements fall into three groups. **Data Fields** covers what goes in the SBOM document, split into SBOM Metadata and Component Data. **Practices and Processes** covers how organizations generate, share, and maintain SBOMs. Only the Data Fields appear in the document's Appendix A table; Coverage and the other practices are elements too, but they are not data fields. ### SBOM Metadata (9 elements) Information about the SBOM document itself. | Element | Status | Definition (CISA Appendix A) | | ------------------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SBOM Author | Major update | The name of the entity that creates the SBOM data for the target component. | | SBOM Author Signature | **New** | A digital signature attributable to the SBOM author. | | SBOM Data Format Name | **New** | The name of the data format used to represent the SBOM data. | | SBOM Data Format Version | **New** | Identifier designated by the SBOM data format to specify the version of the data format. | | SBOM Generation Context | **New** | The relative software lifecycle phase and data available at the time the SBOM author generated the SBOM. | | SBOM Timestamp | Minor update | Record of the date and time of the most recent update to the SBOM data. | | SBOM Tool Name | **New** | The name of the tool used by the SBOM author to generate or amend the SBOM. | | SBOM Tool Version | **New** | Identifier for the version of the tool identified in the SBOM Tool Name element. | | SBOM Version | **New** | Identifier designated by the SBOM author to specify a change in the SBOM document from a previously identified version, or to indicate that it is the first version. | Seven of the nine SBOM Metadata elements are new. If you generated SBOMs against the 2021 baseline, this is where most of the gap sits. ### Component Data (8 elements) Information about each component in the software. | Element | Status | Definition (CISA Appendix A) | | --------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Component Producer | Major update | The name of an entity that creates, defines, and identifies components. | | Component Name | Minor update | The name assigned by the component producer to a software component. | | Component Version | Major update | Identifier used by the component producer to specify a change in a software component from a previously identified version, or to indicate that it is the first version. | | Component Identifiers | Major update | Identifiers used to identify a component or serve as a look-up key for relevant databases. | | Component Hash Value | **New** | The output generated from applying a cryptographic hash algorithm to an executable component artifact. | | Component Hash Algorithm | **New** | The cryptographic algorithm used to compute the Component Hash Value of the software component. | | Component License | **New** | The identifiers for the licenses under which the software component is available. | | Component Dependency Relationship | Minor update | The relationship between two components, where one component is necessary for the operation of the other. | Note that the hash is **two** elements, not one: the digest and the algorithm used to produce it. ### Practices and Processes (6 elements) | Element | Status | What the document says | | ------------------------------------------ | ------------ | --------------------------------------------------------------------------------------------------------------------- | | Accommodation of Updates to SBOM Data | Major update | Organizations should accommodate updates including corrections; SBOM authors should correct errors promptly. | | Coverage | Major update | All components including transitive dependencies. **There is no minimum depth.** | | Distribution and Delivery | Minor update | SBOMs available promptly to those who need them. Access controls must not prevent sharing between authorized parties. | | Explicitly Identifying Unknown Information | Major update | State whether missing information is unknown to the author or is being withheld. | | Frequency | Minor update | Each software version or update should have an associated SBOM. | | Machine-Processable Data | Major update | SPDX and CycloneDX are named as the two widely used formats. | ## What Changed From NTIA 2021 ### The 10 new elements SBOM Author Signature · SBOM Data Format Name · SBOM Data Format Version · SBOM Generation Context · SBOM Tool Name · SBOM Tool Version · SBOM Version · Component Hash Value · Component Hash Algorithm · Component License ### The 8 major updates Several are renames, and the old name is what you will recognise from 2021: | 2021 name | 2026 name | | ------------------------- | ------------------------------------------ | | Author of SBOM Data | SBOM Author | | Supplier Name | Component Producer | | Version of the Component | Component Version | | Other Identifiers | Component Identifiers | | Depth | Coverage | | Known Unknowns | Explicitly Identifying Unknown Information | | Accommodation of Mistakes | Accommodation of Updates to SBOM Data | | Automation Support | Machine-Processable Data | ### The 5 minor updates SBOM Timestamp · Component Name · Component Dependency Relationship · Distribution and Delivery · Frequency ### The 1 removal **Access Control** is removed as a standalone element. Access control considerations are now folded into Distribution and Delivery. ## Details Worth Catching These are the specifics most likely to trip up an existing SBOM pipeline. **Timestamps should follow RFC 9557**, not a generic ISO 8601 profile. Each version of an SBOM gets a new timestamp. **Component Identifiers requires at least one identifier**, but does not mandate a specific scheme. The document says the field _should_ use common identifiers "such as Common Platform Enumeration (CPE) and Package-URL (PURL)". It also permits UUIDs, organization-specific identifiers, commit hashes, and intrinsic identifiers such as OmniBOR and SWHID. If there are multiple identifiers, include all of them. **Coverage has no minimum depth.** An SBOM should cover all components including transitive dependencies. Where multiple instances of a component differ in metadata, each instance should be listed separately. Linking to other SBOM documents can satisfy Coverage, provided the recipient has access to all linked SBOMs. **SWID Tags are gone** from the list of data formats. The Machine-Processable Data element names only SPDX and CycloneDX. **Component Producer needs a fallback.** Where provenance is unknown, the document expects an explicit designation indicating unknown provenance rather than an empty field. **Withholding is not the same as unknown.** If a field is absent, the author should say which it is, and should have a process for recipients to ask about redacted security-related information. An SBOM may be considered incomplete if essential component data is withheld. ## Scope The 2026 minimum elements apply to SBOMs for all software, including open source software, AI software, and SaaS. The document notes that more complex systems such as AI or SaaS may need additional elements to be transparent, but that those additional elements are out of scope here. Separate joint guidance, _Software Bill of Materials for AI – Minimum Elements_, was released by CISA and G7 partners in May 2026. ## Schema Mappings For CycloneDX and SPDX field mappings, see our [Schema Crosswalk](/compliance/schema-crosswalk/). ## Related Frameworks - [NTIA Minimum Elements (2021)](/compliance/ntia-minimum-elements/) - The superseded baseline this replaces - [CISA Framing Document](/compliance/cisa-framing/) - Conceptual definitions and format crosswalk - [EU Cyber Resilience Act](/compliance/eu-cra/) - EU SBOM requirements, where BSI is also a co-author of this document ## Official Source - [2026 Minimum Elements for a Software Bill of Materials (SBOM)](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom) - CISA, 29 July 2026 --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # CISA Framing Software Component Transparency (3rd Edition) URL: https://sbomify.com/compliance/cisa-framing/ Description: Guide to the CISA Framing document, the authoritative source for SBOM baseline attributes and CycloneDX/SPDX schema crosswalk. [← Back to Compliance Overview](/compliance/) **Who it affects:** SBOM producers and consumers who need shared terminology and a consistent crosswalk between SBOM formats (CycloneDX/SPDX) for policy, tooling, and interoperability.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The [CISA Framing Software Component Transparency](https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf) document provides conceptual definitions and serves as the normalization layer across SBOM formats. It defines "Baseline Attributes" and provides the authoritative crosswalk between CycloneDX and SPDX (including SPDX 3.0). ## Key Terminology The Framing document establishes shared terminology for SBOM discussions: - **Author** - The source of the descriptive metadata (not the author of the software itself) - **Dependency** - The relationship between two components, including types: static, dynamic, remote, provided, direct, transitive ## Baseline Attributes The Framing document defines baseline attributes that should be present in every SBOM. These align closely with the [NTIA minimum elements](/compliance/ntia-minimum-elements/) but provide additional context and cross-format mappings. ## Why This Document Matters The Framing document is particularly useful as: 1. **The canonical source for schema field mappings** - See our [Schema Crosswalk](/compliance/schema-crosswalk/) 2. **A normalization layer** - Enables consistent interpretation across CycloneDX and SPDX 3. **The reference for other frameworks** - FDA and other guidance documents point to the Framing document for baseline attributes ## Related Frameworks - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - The original baseline guidance - [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/) - The current US baseline - [Schema Crosswalk](/compliance/schema-crosswalk/) - CycloneDX and SPDX field mappings ## Official Source - [CISA Framing Software Component Transparency (3rd Edition)](https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # CISA SBOM Sharing Lifecycle Report (2023) URL: https://sbomify.com/compliance/cisa-sharing-lifecycle/ Description: Guide to the CISA SBOM Sharing Lifecycle Report, covering discovery, access, and transport patterns for SBOM distribution across supply chains. [← Back to Compliance Overview](/compliance/) **Who it affects:** Organizations that distribute or retrieve SBOMs across supply chains (vendors, buyers, operators) that need practical patterns for discovery, access, and transport.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The [CISA SBOM Sharing Lifecycle Report](https://www.cisa.gov/sites/default/files/2023-04/sbom-sharing-lifecycle-report_508.pdf) focuses on operational aspects of SBOM distribution rather than adding new data fields. It defines the SBOM sharing lifecycle as three phases: **Discovery** (locating SBOMs), **Access** (authorization and retrieval), and **Transport** (delivery mechanisms). This report does not prescribe additional SBOM properties but provides guidance on infrastructure and processes needed for effective SBOM sharing across the supply chain. ## The Three Phases ### 1. Discovery How do consumers find out that an SBOM exists and where to get it? - Discoverability mechanisms for locating SBOMs - Metadata and pointers that indicate SBOM availability ### 2. Access Who is allowed to retrieve the SBOM and how is authorization managed? - Authorization and access control patterns - Public vs. private SBOM distribution models - Role-based access considerations ### 3. Transport How are SBOMs physically delivered from producer to consumer? - Repository portals and package registries - APIs for SBOM retrieval - Out-of-band delivery mechanisms (email, secure file transfer) - Enrichment workflows where downstream consumers add information and re-share ## Key Concepts - **Discoverability mechanisms** for locating SBOMs - **Authorization and access control patterns** for managing who can retrieve SBOMs - **Transport protocols and sharing patterns** (repository portals, APIs, out-of-band delivery) - **Enrichment workflows** where downstream consumers add information and re-share ## Practical Applications This report is valuable for: - Organizations setting up SBOM distribution infrastructure - Procurement teams defining SBOM delivery requirements in contracts - Security teams designing SBOM ingestion workflows ## Related Frameworks - [CISA Framing Document](/compliance/cisa-framing/) - Conceptual definitions - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - What goes in the SBOM ## Official Source - [CISA SBOM Sharing Lifecycle Report](https://www.cisa.gov/sites/default/files/2023-04/sbom-sharing-lifecycle-report_508.pdf) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # CLE: Common Lifecycle Enumeration for SBOMs URL: https://sbomify.com/compliance/cle/ Description: Guide to CLE (ECMA-428), the standard for machine-readable component lifecycle events including end-of-life, end-of-support, and provenance changes. [← Back to Compliance Overview](/compliance/) [CLE (ECMA-428)](https://ecma-international.org/publications-and-standards/standards/ecma-428/) is a standard for machine-readable component lifecycle events, including end-of-life (EOL), end-of-support (EOS), aliasing, and provenance changes.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## CLE vs. SBOM Lifecycle Phase **Important distinction:** CycloneDX's `metadata.lifecycles[].phase` represents the SDLC context of when the SBOM was generated (build-time vs runtime, etc.). CLE addresses a different concept: the lifecycle status of individual components (whether they are supported, approaching EOL, etc.). These are complementary, not overlapping. | Concept | What it represents | Where it lives | | -------------------- | ---------------------------------------------- | --------------------------------- | | SBOM Lifecycle Phase | When/how the SBOM was generated (SDLC context) | `metadata.lifecycles[].phase` | | CLE Lifecycle Events | Support status of individual components | `components[].properties[]` (CLE) | --- ## Representing CLE in CycloneDX CycloneDX supports CLE-style lifecycle data without breaking schema compliance: ### 1. BOM Lifecycle Phase (SDLC Context) Use `metadata.lifecycles[].phase` to indicate when/how the SBOM was captured: - design - pre-build - build - post-build - operations - discovery - decommission ### 2. Component Lifecycle Events (CLE) Use `components[].properties[]` with CLE-namespaced keys for per-component lifecycle status: ```json { "components": [{ "name": "example-library", "version": "1.2.3", "properties": [ { "name": "cle:eos", "value": "2027-06-30" }, { "name": "cle:eol", "value": "2028-12-31" }, { "name": "cle:supportLevel", "value": "security-fixes-only" } ] }] } ``` ### 3. External Reference Optionally link to authoritative CLE documents via `externalReferences[]`. --- ## Key Naming Convention **Note on key naming:** The property keys shown above (`cle:eos`, `cle:eol`, `cle:supportLevel`) are illustrative examples. For interoperability, key naming should follow ECMA-428's data model or a published property taxonomy/namespace. --- ## FDA Requirements and CLE This approach satisfies [FDA's lifecycle requirements](/compliance/fda-medical-device/) (support level and end-of-support date) while aligning with emerging standards. --- ## Related Pages - [Schema Crosswalk](/compliance/schema-crosswalk/) - CycloneDX and SPDX field mappings - [FDA Medical Device Guidance](/compliance/fda-medical-device/) - Healthcare sector lifecycle requirements ## Official Source - [CLE Specification (ECMA-428)](https://ecma-international.org/publications-and-standards/standards/ecma-428/) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # EU Cyber Resilience Act (CRA) SBOM Requirements URL: https://sbomify.com/compliance/eu-cra/ Description: Complete guide to CRA SBOM requirements with the BSI TR-03183 family (Parts 1, 2, 3 and H). Covers format requirements, data fields, dependency depth, the ENISA Single Reporting Platform and the 11 September 2026 reporting deadline, harmonised standards status, and a compliance checklist. [← Back to Compliance Overview](/compliance/) **Who it affects:** Manufacturers (and, depending on role, importers/distributors) placing "products with digital elements" on the EU market, plus their software/component supply chains.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## What Changed Recently This page is current as of **September 2026**. The CRA landscape has moved substantially since the regulation entered into force: | Development | Date | Why it matters for SBOM | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | [Commission Implementing Regulation (EU) 2025/2392](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392) - technical descriptions of important and critical products | 28 November 2025 | Determines your conformity assessment route, and therefore how much scrutiny your technical documentation (including the SBOM) gets | | [BSI TR-03183-3](https://bsi.bund.de/dok/TR-03183-en) v1.0.0 - Vulnerability Reports and Notifications | September 2025 | The intake side of vulnerability handling: security.txt, CVD policy, CSAF advisories | | [BSI TR-03183-H](https://bsi.bund.de/dok/TR-03183-en) v1.1.0 - Conformity based on full quality assurance (Module H) | 30 May 2026 | Lets manufacturers demonstrate CRA conformity through an ISO/IEC 27001 ISMS rather than per-product assessment | | [Commission CRA guidance](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation) C(2026) 5252 | 27 July 2026 | 84 pages and 67 worked examples on scope, open source, support periods and reporting. Non-binding, but shapes enforcement | | [ENISA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp) step-by-step instructions | 31 July 2026 | You need EU Login accounts and named representatives registered before the 24-hour clock can ever start | | [BSI TR-03183-1](https://bsi.bund.de/dok/TR-03183-en) v1.0.0 - General requirements | 31 July 2026 | First stable release of BSI's general CRA requirements guideline, after two years in draft | | [ENISA CRA SRP FAQ](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions) updated, and the SRP portal opens | 9-11 September 2026 | The operational detail: EU Login, Assigned Representative roles, CSIRT selection, and the fields you type inside a 24-hour window | The single most important thing on that list is the one that is not a document: **reporting obligations bind from 11 September 2026**, and the [Single Reporting Platform](#reporting-obligations-from-11-september-2026) is where those notifications have to go. --- ## Overview The [EU Cyber Resilience Act (CRA)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) (Regulation EU 2024/2847) mandates cybersecurity requirements for products with digital elements, including an SBOM requirement. Unlike US guidance documents, the CRA is **binding law** in the EU. This page covers: - **CRA legal baseline** - what the regulation text requires - **The BSI TR-03183 family** - Germany's Federal Office for Information Security (BSI) publishes a four-part [Technical Guideline](https://bsi.bund.de/dok/TR-03183-en) that is the most concrete public interpretation of CRA obligations, with Part 2 specifying SBOM format and content - **Harmonised standards** - where the EN 40000 series stands, and why it does not yet give you a presumption of conformity > **Terminology note:** In BSI TR-03183-2, RFC 2119 keywords (MUST, SHALL, SHOULD, etc.) are normative **only when written in ALL CAPS**. (BSI TR-03183-2, Section 2) --- ## CRA Timeline: Where Things Stand The CRA applies in stages (Article 71): | Date | Milestone | Status | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------- | | 10 December 2024 | CRA entered into force | Done | | 21 December 2025 | Implementing Regulation (EU) 2025/2392 (technical descriptions of important and critical products) entered into force | Done | | 11 June 2026 | Rules on notified bodies and conformity assessment (Chapter IV, Articles 35-51) began to apply | Done | | 27 July 2026 | Commission published its first set of CRA application guidance (C(2026) 5252) | Done | | 11 September 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents begin (Article 14) | Upcoming | | 31 October 2026 | Proposed deadline for the horizontal (Type A) and vulnerability-management (Type B) harmonised standards under mandate M/606 | Proposed | | 11 December 2026 | Member States to "strive to ensure" a sufficient number of notified bodies in the Union (Article 35(2)) | Upcoming | | 31 December 2026 | Proposed deadline for product-specific (Type C) harmonised standards | Proposed | | 11 December 2027 | Full application: all essential requirements, including the SBOM obligation, become enforceable for products placed on the EU market | Upcoming | The nearest deadline is the most consequential for SBOM practice: from **11 September 2026**, manufacturers must report actively exploited vulnerabilities and severe incidents. Meeting the reporting clock in practice depends on knowing what is in your products, which is exactly what an SBOM provides. --- ## Reporting Obligations from 11 September 2026 From 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents affecting their products with digital elements. Notifications are submitted through the [CRA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp) (SRP), operated by ENISA under Article 16(1), and are addressed to the **CSIRT designated as coordinator (CDaC)** of the Member State where the manufacturer has its main establishment. The platform is at [portal.cra-srp.enisa.europa.eu](https://portal.cra-srp.enisa.europa.eu). A submitted notification is made available to **ENISA simultaneously**, while the receiving CDaC disseminates it without delay to CSIRTs in other Member States where the product is available, and shares information with market surveillance authorities so they can enforce. Only **one notification per event** is required, even where a manufacturer has multiple EU branches or subsidiaries and a parent company outside the EU; coordinating internally so that exactly one goes out is the manufacturer's responsibility. The deadlines are tight (Article 14): | Deadline | Obligation | | -------- | -------------------------------------------------------------------------------------------- | | 24 hours | Early warning after becoming aware of an actively exploited vulnerability or severe incident | | 72 hours | Full notification, including corrective or mitigating measures | | 14 days | Final vulnerability report, after a corrective measure is available | | 1 month | Final report for severe incidents, after the initial notification | ### What is in scope at launch The platform's launch scope is narrower than the regulation: | Who | Legal basis | Status from 11 September 2026 | | ------------------------------- | ------------- | ---------------------------------------------------------------------------------------------- | | Manufacturers | Article 14 | **In scope.** Mandatory reporting through the SRP | | Open-source software stewards | Article 24(3) | Not until **11 December 2027**, per Article 71(2) | | Anyone, voluntary notifications | Article 15 | **Not implemented at launch.** Planned for a later phase | | Non-manufacturers | - | Contact the relevant national CSIRT directly; an SRP submission "might be marked as 'invalid'" | At launch the platform is available in **English only**. ENISA will progressively translate the factsheet and supporting materials into all EU languages and will review translation of the platform itself in a later phase. ### Registration: EU Login and Assigned Representatives You do not register a company on the SRP - you register **people**, called Assigned Representatives (ARs). - ARs sign in with an **EU Login account with multi-factor authentication enabled**. Accounts can be created in advance at [ecas.ec.europa.eu](https://ecas.ec.europa.eu/cas/login). ENISA states there is no additional corporate entity authentication mechanism, and that EU Login accounts are personal - so each AR who will submit needs their own, not a shared mailbox login. - There is **one Primary AR per manufacturer and up to 20 Secondary ARs**. The Primary registers directly, selects the CDaC, and creates the manufacturer association; it can then invite Secondary ARs once its own association shows as "Verified". Both roles can submit and update notifications, but the Primary sees all of the manufacturer's notifications while a Secondary sees only its own. A Secondary may claim the Primary role, subject to review and approval by the designated CSIRT. - The AR-manufacturer association is validated by the designated CSIRT, and ENISA is upfront that the procedure and processing time **vary between CSIRTs**. Validation runs **in parallel** with reporting, and an AR whose association is not yet verified may submit **up to 20 notifications** before verification becomes mandatory. - To limit CSIRT validation workload, ENISA advises manufacturers to register and start validation **only when they need to submit a notification**. Registration takes a few minutes if the EU Login account already exists. Read together, that suggests splitting the two steps: create the EU Login accounts and name your Primary and Secondary ARs now, because that is the part with an unpredictable tail, and leave the SRP registration itself until you need it. ### Choosing the right CSIRT is your job The platform does not route notifications for you. ENISA: "If the wrong CDaC is selected, the notification may be invalidated and will need to be resubmitted to the correct CDaC." Article 14(7) gives a cascade, applied in order: | Order | Test | | ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | The Member State of your **main establishment** - where decisions about the cybersecurity of your products with digital elements are predominantly taken | | 2 | If that cannot be determined: the Member State where your EU establishment has the **highest number of employees** | | 3 | No EU establishment: where your **authorised representative** acts for the highest number of your products | | 4 | Failing that: where the **importer** places the highest number of your products on the market | | 5 | Failing that: where the **distributor** makes the highest number of your products available | | 6 | Failing all of the above: the Member State with the **highest number of users** of your products | Step 1 is not "where we are headquartered" and not "where engineering sits." Make and record the determination once, in advance. ENISA publishes the [list of CSIRTs designated as coordinators](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators) so you can map the answer to an entry in the dropdown. ### What you actually submit ENISA's [SRP Glossary](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2) documents 43 fields with their meaning, expected format, and the reporting stage at which each applies. Fields are marked required, optional, mandatory if the information is available, or carried forward from the previous stage. **Required at the 24-hour early warning:** notification type and level, title, summary, manufacturer name, **product name**, **product version**, the date and time you became aware, the Member States where the product is available (if known), and - for incidents - whether unlawful or malicious acts are suspected. **Added at 72 hours:** general information about the vulnerability or the nature of the incident, an initial assessment, considered sensitivity of the information, and corrective or mitigating measures taken plus measures users can take. **Added in the final report:** detailed severity and impact descriptions, the date a corrective measure became available, the type of threat or root cause, and the malicious actor where that information is available. Fields that remain optional throughout are the ones an SBOM programme is best placed to fill: **component name**, CVE ID, EUVD ID, and attack vector. ### Operational details that catch teams out - **There is no reporting API at launch.** ENISA states that no Application Programming Interface will be provided at the initial release; notifications must go through the platform interface, with API functionality possibly considered in a future phase. You can automate your internal workflow right up to submission, but a human types the final form into a browser. That makes the quality of your internal triage data the rate-limiting factor, not your integration work. - **The platform's 72-hour counter is not your legal clock.** In the current release the 72-hour counter displays a due date **48 hours after the 24-hour early warning was submitted**, so a notification can be flagged overdue before 72 hours have elapsed since you became aware. ENISA says a future release will calculate it from the "date/time when you became aware" field. There is currently no final-report counter for vulnerabilities at all; for severe incidents it runs one month from the 72-hour notification. - **Particularly exceptional circumstances (PEC) are assessed during the 72-hour window.** Under Article 16(2), the receiving CSIRT may delay or withhold dissemination, including at the manufacturer's request; [Commission Delegated Regulation (EU) 2026/881](https://eur-lex.europa.eu/eli/reg_del/2026/881/oj/eng) of 11 December 2025 specifies the conditions. Where PEC is actively marked in the 72-hour notification, ENISA receives only partial information until the receiving CSIRT releases the full notification. Decide in advance who may invoke it and on what grounds. - **If the SRP is unavailable, you wait and then submit.** You may contact your designated CSIRT directly if immediate communication is necessary, but the notification must still be submitted through the SRP once it is available again. A phone call does not discharge the obligation. **The SBOM connection:** a 24-hour early-warning window leaves no time for manual component archaeology, and the fields required at that stage are inventory questions - which product, which version, which Member States. When a vulnerability in a widely used library starts being exploited, you need to answer "which of our products and versions contain this component?" in minutes. That requires up-to-date, machine-readable SBOMs for every shipped version, matched continuously against vulnerability intelligence. Manufacturers who wait until December 2027 to build their SBOM pipeline will find the September 2026 reporting obligations hard to meet. ### Two clarifications from the Commission's July 2026 guidance **Third-party components (paragraph 218).** Where your product contains an actively exploited vulnerability originating from a third-party component, you must notify it. But if you are aware that a third-party component contains a vulnerability and that vulnerability either (i) cannot be exploited in your product - the guidance's example is that the vulnerable code is not reachable - or (ii) has not been exploited in your product, it does not qualify as an actively exploited vulnerability contained in your product and is not subject to mandatory reporting by you. You may still notify voluntarily under Article 15, and the vulnerability handling requirements of Annex I Part II still apply, as does the duty to report it upstream to the component's maintainer under Article 13(6). That is a VEX-shaped determination, and making it credibly under time pressure presupposes an SBOM you trust plus a reachability answer you can defend. **No retroactive reporting (paragraph 217).** You do not have to report vulnerabilities whose active exploitation you were already aware of before 11 September 2026. But if you knew about a vulnerability before that date without knowing it was being exploited, and exploitation occurs or comes to your attention afterwards, it becomes reportable then. Note that the guidance does **not** address SBOM format or content - the words "software bill of materials" and "SBOM" do not appear in it at all. For that, BSI TR-03183-2 remains the only detailed public reference. --- ## Penalties (Article 64) Enforcement is national: Member States lay down the penalty rules, and market surveillance authorities or national courts impose the fines (Article 64(1), (7) and (8)). The administrative fine ceilings, however, are set EU-wide: | Infringement | Maximum administrative fine | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Non-compliance with the essential cybersecurity requirements (Annex I) or the manufacturer obligations in Articles 13 and 14, which include the SBOM duty and the reporting obligations above (Article 64(2)) | EUR 15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher | | Non-compliance with other operator obligations, including those of importers and distributors (Articles 18 to 23, 28, 30 to 32, 33(5), 39, 41, 47, 49 and 53) (Article 64(3)) | EUR 10,000,000 or up to 2% of total worldwide annual turnover, whichever is higher | | Supplying incorrect, incomplete or misleading information to notified bodies and market surveillance authorities (Article 64(4)) | EUR 5,000,000 or up to 1% of total worldwide annual turnover, whichever is higher | When setting the amount, authorities must take into account the nature, gravity and duration of the infringement, whether fines have already been applied for similar infringements, and the size and market share of the offender, with particular regard to microenterprises, SMEs and start-ups (Article 64(5)). Article 64(10) carves out two derogations from the fines in paragraphs (3) to (9): manufacturers that qualify as microenterprises or small enterprises cannot be fined for missing the 24-hour early-warning deadlines in Article 14(2), point (a), or Article 14(4), point (a), and **open-source software stewards** cannot be fined under those paragraphs for any infringement of the Regulation. **Timing:** the reporting obligations bind from 11 September 2026 and the essential requirements, including the SBOM obligation, from 11 December 2027 (Article 71). The fine ceilings above are the exposure once the corresponding obligation applies. ### Who enforces this in Germany Germany is putting the BSI at the centre of CRA enforcement. The **CRA-Durchführungsgesetz** (Gesetz zur Durchführung der Cyberresilienz-Verordnung, [Bundestag Drucksache 21/6134](https://dserver.bundestag.de/btd/21/061/2106134.pdf) of 26 May 2026) amends the BSI Act (BSI-Gesetz) so that the BSI becomes "die zuständige nationale Marktüberwachungsbehörde" and "die notifizierende Behörde" under Regulation (EU) 2024/2847. The Bundestag held its first reading on 11 June 2026 and referred the bill to committee, with the Interior Committee in the lead; the Bundesrat raised no objections. The bill was still in the parliamentary process as of August 2026, so details may change, but the authority architecture is unlikely to. This matters for how you read TR-03183: the authority writing the technical guideline is the same authority that will be knocking on the door. --- ## CRA Legal Baseline ### SBOM Requirement Annex I, Part II(1) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, **including by drawing up a software bill of materials** in a commonly used and machine-readable format covering **at least the top-level dependencies** of the product." | CRA Requirement | Description | Reference | | ---------------------- | ------------------------------------------------------- | ------------------- | | Machine-readable SBOM | SBOM must be in a machine-readable format | Annex I, Part II(1) | | Commonly used format | Must use a commonly used format (e.g., CycloneDX, SPDX) | Annex I, Part II(1) | | Top-level dependencies | Must include at least top-level (direct) dependencies | Annex I, Part II(1) | Top-level dependencies are the **legal floor**, not the target. Vulnerability triage under a 24-hour clock depends on transitive depth, and BSI TR-03183-2 requires considerably more (see [Scope and Dependency Depth](#scope-and-dependency-depth)). ### Technical Documentation and Authority Access The SBOM is part of the technical documentation, and the technical documentation is what market surveillance authorities audit. | Requirement | Description | Reference | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | | SBOM in technical documentation | The specification of vulnerability handling processes must include the SBOM, the CVD policy, evidence of a vulnerability contact address, and the secure update distribution design | Annex VII, point 2(b) | | Authority access | The SBOM must be produced further to a reasoned request from a market surveillance authority, where necessary to check compliance with Annex I | Annex VII, point 8 | | Cooperation duty | Manufacturers must supply all information and documentation demonstrating conformity upon reasoned request | Article 13(22) | | Kept continuously updated | Technical documentation must be drawn up before placing on the market and continuously updated, at least during the support period | Article 31(2) | | Retention | Technical documentation must be kept at the disposal of market surveillance authorities for at least **10 years** after the product is placed on the market, or for the support period, whichever is longer | Article 13(13) | The retention and continuous-update duties together are the ones teams underestimate: you are not producing one SBOM, you are running an archive of per-version SBOMs that has to stay retrievable for a decade. ### User Disclosure (Optional) Annex II, Part I, point 9: "If the manufacturer decides to make available the software bill of materials to the user, [provide] information on where the software bill of materials can be accessed." | Requirement | Description | Status | | -------------------------- | ----------------------------------------------------------- | ------------------- | | User delivery | Providing SBOM to end users | Optional | | Access location disclosure | If SBOM is shared with users, must state where to access it | Required if sharing | ### Future Specifications, Standards, and Guidance **Article 13(24)** empowers the European Commission, by means of implementing acts and taking into account European or international standards and best practices, to "specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I." **No such implementing act has been adopted.** That is why BSI TR-03183-2 remains the most concrete technical interpretation available. Related implementation work: - **Commission guidance (27 July 2026):** the Commission approved the content of its first set of CRA application guidance as [C(2026) 5252 final](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation), an 84-page annex containing 67 numbered practical examples. It covers scope (including remote data processing and free and open-source software), what counts as a substantial modification, support periods, product classification, and reporting obligations. It is explicitly non-binding: only the Court of Justice can authoritatively interpret the CRA. It nevertheless steers market surveillance authorities and notified bodies toward a consistent reading. It says nothing about SBOM format or content. - **Commission FAQ:** the Commission maintains a living [CRA implementation FAQ](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions) covering scope questions, the open-source regime, support periods, and reporting obligations. - **Product classification:** [Implementing Regulation (EU) 2025/2392](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392) (adopted 28 November 2025, in force 21 December 2025) fills in the technical descriptions behind the Annex III "important" and Annex IV "critical" product categories, and clarifies that a product's **core functionality** drives classification rather than ancillary or embedded features. Classification determines the conformity assessment route, which determines whether a notified body reads your technical documentation. --- ## Harmonised Standards: Not Yet Available CEN, CENELEC and ETSI [accepted the Commission's CRA standardisation request (M/606) on 3 April 2025](https://www.cencenelec.eu/news-events/news/2025/newsletter/ots-62-cra/). The Commission [describes M/606](https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation) as covering a set of **41 standards**, horizontal and product-specific. The horizontal work is being developed by CEN-CLC/JTC 13 as the **EN 40000** series, with vertical, product-specific standards in the **EN 50770** series. | Standard | Scope | Status (as of mid-2026) | | --------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | prEN 40000-1-1 | Vocabulary | Public enquiry completed, under approval | | prEN 40000-1-2 | Cyber resilience principles, risk management | Public enquiry completed, under approval; not currently expected to be cited in the Official Journal | | prEN 40000-1-3 | Vulnerability handling | Most advanced; the one horizontal part currently expected to be cited | | prEN 40000-1-4 | Technical security controls | Not scheduled until autumn 2027 | | prEN 50770-1..6 | Vertical OT products (firewalls, network management, VPN, routers/switches, SIEM) | In development, leaning on IEC 62443 | Drafts are not public documents, so the status column above is drawn from CEN/CENELEC communications and public standardisation trackers rather than from the Official Journal. Treat it as directional. Two things follow from it that matter more than the standard numbers: 1. **No CRA harmonised standard has been cited in the Official Journal yet.** Until one is, the Article 27 presumption of conformity is not available to anyone. Everybody is currently demonstrating conformity by describing the solutions they adopted. 2. **The deadlines slipped.** In early July 2026 the Commission issued a draft amendment to M/606 pushing delivery back two months: Type A and Type B (vulnerability management) from 30 August 2026 to 31 October 2026, and Type C (product-specific) from 30 October 2026 to 31 December 2026. The implementing decision had not been published at the time of writing, so those dates remain proposed rather than binding. BSI states plainly that TR-03183 "will be gradually developed further and replaced by the corresponding harmonised European standards as soon as they become available." Treat TR-03183 as the best available bridge, not the destination. --- ## The BSI TR-03183 Family [BSI TR-03183](https://bsi.bund.de/dok/TR-03183-en) is no longer a single SBOM document. It is now a four-part family covering the CRA's manufacturer obligations end to end: | Part | Version | Date | What it covers | | ------------------------------------------------------- | ------- | -------------- | ----------------------------------------------------------------------------------------------------- | | **Part 1** - General requirements | 1.0.0 | 31 July 2026 | Risk-based selection of security controls for products with digital elements, with an OSCAL catalogue | | **Part 2** - Software Bill of Materials (SBOM) | 2.1.0 | 20 August 2025 | SBOM format, content, data fields, dependency depth, licences | | **Part 3** - Vulnerability Reports and Notifications | 1.0.0 | September 2025 | Receiving vulnerability reports: security.txt, CVD policy, CSAF advisories | | **Part H** - Conformity based on full quality assurance | 1.1.0 | 30 May 2026 | Demonstrating conformity via an ISO/IEC 27001 ISMS (Module H) instead of per-product assessment | > **Note on interpretations:** BSI TR-03183 remains the **first and most detailed technical interpretation** of CRA requirements published by an EU member state authority. Other EU countries may publish their own interpretations, which could differ. BSI is explicit that its guideline creates no obligations, gives no presumption of conformity, and does not describe the only way to meet the CRA's essential requirements. ### Part 1: General requirements (v1.0.0, July 2026) Part 1 is not a new document, but 1.0.0 is its **first stable release**. It has been a living draft since 2023 (v0.9.0, then v0.10.0 in October 2025); the document carrying version 1.0.0 is dated 31 July 2026, and BSI [announced it on 5 August 2026](https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/TR-03183_Einstiegshilfe_CRA_260805.html). It is aimed squarely at manufacturers who do not yet have mature secure-development and vulnerability-handling processes, and is positioned as an entry aid to the CRA for the "default" product class. What it contains: - **Adaptable Risk-based Controls (ARC)** - the framing that is genuinely new in 1.0.0. Each control is paired with one or more risk scenarios describing affected assets and impact, plus environment parameters (access restriction, interface restriction, user capabilities). You match your product's assets and environment against the scenarios to select controls, rather than applying a flat checklist. The underlying risk-scenario method was already present in v0.10.0; 1.0.0 names and structures it. - **A machine-readable OSCAL control catalogue**, published at [github.com/tr-03183/tr-03183-1](https://github.com/tr-03183/tr-03183-1), with access and usage notes provided on request to BSI. This is not new in 1.0.0 either - the same repository was referenced in v0.10.0 - but it remains the most useful part for tooling. Expressing CRA controls in [OSCAL](https://pages.nist.gov/OSCAL/) makes filtering, custom catalogues, and structured assessment evidence practical. - **An assessment report template** that mirrors Annex VII. Its required contents include the product identification, versions of hardware and software, and the **SBOM where applicable**, alongside the risk assessment, design documentation, selected controls, and vulnerability handling description. In other words, the news is the release status rather than a wholesale change in content. If you evaluated the October 2025 draft, re-read it for the ARC structure rather than expecting a different document. Part 1 restates the SBOM's home in the CRA: technical documentation under Article 31 must include a cybersecurity risk assessment and an SBOM. If you have been treating SBOM generation as a build-pipeline concern, Part 1 is a useful reminder that it is a documentation-of-conformity concern. ### Part 3: Vulnerability Reports and Notifications (v1.0.0, September 2025) Part 3 covers the **intake** side of vulnerability handling, not the Article 14 outbound reporting to the SRP. It is the complement to the SBOM: Part 2 tells you what you shipped, Part 3 tells you how people tell you it is broken. Concretely, it requires or specifies: - A **`security.txt`** file per [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html) on the manufacturer's website. Section 4.2 is prescriptive about its contents: | Field | Requirement | Detail (Section 4.2) | | --------------------- | ----------- | ------------------------------------------------------------------------------------------------- | | Location | MUST | `/.well-known/security.txt`, served over HTTPS, plain ASCII or UTF-8 (4.2.1) | | `Canonical` | MUST | Authoritative URI, reachable without redirects (4.2.2) | | `Contact` | MUST | Three entries in order: PSIRT mailbox, CSIRT mailbox, URI of the incoming-report web page (4.2.3) | | `Encryption` | MUST | OpenPGP keys covering every listed contact (4.2.4) | | `Preferred-Languages` | MUST | At least `en` (4.2.6) | | `Policy` | MUST | URI of the CVD policy page (4.2.7) | | `Expires` | MUST | RFC 3339, at most one year ahead, reviewed at least quarterly (4.2.9) | | Digital signature | MUST | OpenPGP signature per RFC 9580; key validity capped at five years (4.2.10) | | `CSAF` | SHOULD | URI of `provider-metadata.json`, prefixed with the `CSAF:` tag (4.2.8) | | `Acknowledgments` | SHOULD | URI of the researcher acknowledgements page (4.2.5) | | Crawler visibility | MUST | Firewall and DDoS rules must not block automated discovery (4.2.11) | - A dedicated **web page for incoming vulnerability reports**, including a web form, published contact options, and the CVD policy. - A **CVD policy** covering the corresponding national CSIRT, assurances to reporters, a code of conduct, guaranteed response times, an anonymous reporting option, and how disclosure ends. - Publication of security advisories on the manufacturer's website using **OASIS CSAF v2.0**, with BSI pointing at the open-source [CSAF Provider](https://github.com/gocsaf/csaf/blob/main/docs/csaf_provider.md) tooling. The CSAF requirement is the same architectural decision as Part 2's ban on vulnerability data inside SBOMs, seen from the other end: static component inventory in the SBOM, dynamic vulnerability state in CSAF/VEX. > **Publishing a `security.txt` with sbomify:** every sbomify [Trust Center](/faq/what-is-a-trust-center/) can serve an RFC 9116 `security.txt` at `/.well-known/security.txt`, populated from your workspace security contacts, covering `Canonical`, `Encryption`, `Preferred-Languages` and `Expires`. Enable it under **Settings > Trust Center**; the [CRA Compliance Wizard](/faq/how-do-i-use-cra-compliance/) reuses those values in its vulnerability-handling step. For full TR-03183-3 conformance you will additionally need the `Policy` link, the `CSAF` pointer, the PSIRT/CSIRT contact ordering, and an OpenPGP signature over the file. ### Part H: Module H conformity (v1.1.0, May 2026) Article 32(1)(c) allows conformity assessment based on full quality assurance (Module H, Annex VIII). BSI opened a [commenting phase on TR-03183-H from 27 February to 31 March 2026](https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/Kommentierungsphase_TR-03183-H_260227.html) and published v1.1.0 on 30 May 2026. Module H assesses the manufacturer's **processes** rather than each individual product, and TR-03183-H maps that onto an ISO/IEC 27001-compliant ISMS. For SBOM programmes this is a meaningful lever: if your SBOM generation, storage, and distribution are auditable ISMS processes rather than per-release heroics, Module H lets that investment cover a whole product portfolio at once instead of being re-demonstrated product by product. --- ## BSI TR-03183-2: Concrete SBOM Requirements [BSI TR-03183-2](https://bsi.bund.de/dok/TR-03183-en) **v2.1.0 (20 August 2025)** remains the current SBOM specification; there is no newer version as of August 2026. Key requirements follow. For the standalone summary, see our [BSI TR-03183-2 page](/compliance/bsi-tr-03183/). ### Compliance Versioning To be compliant with the Technical Guideline, the **most recent version MUST be used** for generating SBOMs. Any earlier version MUST NOT be applied, except the immediately preceding one, which MAY be used for up to **six months** after a new version is issued. (Section 7) Importantly for anyone worried about the 10-year retention duty: an SBOM that was compliant at its **delivery date remains compliant**, even after BSI publishes newer versions of the guideline. You do not have to regenerate your archive every time the TR moves. Consumers of SBOMs SHOULD be able to interpret versions that were compliant when delivered. (Section 7) ### Required Formats SBOMs MUST be in JSON or XML format and follow one of these specifications: | Format | Minimum Version | Reference | | --------- | --------------- | --------- | | CycloneDX | 1.6 or higher | Section 4 | | SPDX | 3.0.1 or higher | Section 4 | Only officially released versions are compliant. (Section 4) ### Scope and Dependency Depth BSI requires a **"delivery item SBOM"** - recursive dependency resolution MUST be performed on each path downward at least up to and including the **first component outside the scope of delivery**. That first external component must at least be **identified** (creator, name, version, other unique identifiers). (Section 5.1) "Scope of delivery" means all software parts delivered with the product; parts acquired separately are not included. (Section 8.1.11) This is materially deeper than the CRA's "at least the top-level dependencies" floor, and it is the gap most manufacturers discover late. ### Required Data Fields: SBOM Level Each SBOM MUST contain (Table 2, Section 5.2.1): | Data Field | Description | | --------------- | --------------------------------------------------------------------------- | | Creator of SBOM | Email address of the SBOM creator; if unavailable, a URL (homepage/project) | | Timestamp | Date and time of SBOM compilation (UTC recommended) | ### Required Data Fields: Each Component For each component, the following MUST be provided (Table 3, Section 5.2.2): | Data Field | Description | | ---------------------------- | -------------------------------------------------------------------------------------------- | | Component creator | Email address or URL of the entity that created/maintains the component | | Component name | Name assigned by creator; if none, the actual filename | | Component version | Version identifier (SemVer/CalVer recommended); if none, file modification date per RFC 3339 | | Filename | Actual filename of the component (not file system path) | | Dependencies | Enumeration of direct dependencies; **completeness MUST be clearly indicated** | | Distribution licences | SPDX licence identifier/expression for licences under which the component can be used | | Hash of deployable component | SHA-512 checksum of the deployed/deployable component | | Executable property | "executable" or "non-executable" | | Archive property | "archive" or "no archive" | | Structured property | "structured" or "unstructured" (if component has both, use "structured") | ### Additional Data Fields (Conditional) These MUST be provided **if they exist** and fit the SBOM format (Tables 4-5, Sections 5.2.3-5.2.4): **SBOM level:** | Data Field | Description | | ---------- | ---------------- | | SBOM-URI | URI of this SBOM | **Component level:** | Data Field | Description | | ----------------- | ----------------------------------------------------------- | | Source code URI | URI of the source code (repository URL or specific version) | | Deployable URI | URI pointing directly to the downloadable form | | Other unique IDs | CPE, Package URL (purl), SWID, etc. | | Original licences | Licence(s) assigned by the component creator | ### Optional Data Fields May be included if they exist (Table 6, Section 5.2.5): | Data Field | Description | | ----------------- | ------------------------------------------------------- | | Effective licence | Licence under which the SBOM creator uses the component | | Source code hash | Checksum of source code (algorithm TBD by BSI) | | security.txt URL | URL of the component creator's security.txt (RFC 9116) | That last one is where Part 2 and Part 3 meet: the security.txt Part 3 makes you publish is the same artefact your downstream consumers may record against your component in their SBOM. ### Licence Requirements Licences MUST be referenced by **SPDX licence identifier or expression**. Licence text MUST NOT be used as a substitute for an identifier. (Section 6.1) If no SPDX identifier exists, consult the [Scancode LicenseDB](https://scancode-licensedb.aboutcode.org/) using prefix `LicenseRef-scancode-[...]`. For truly unknown licences, use `LicenseRef--[...]`. (Section 6.1) ### Vulnerability Information **SBOMs MUST NOT contain vulnerability information.** SBOM data is static; vulnerability information is dynamic. Use **CSAF** or **VEX** for vulnerability communication instead. (Section 3.1, 8.1.14) ### One SBOM Per Version A **separate SBOM MUST be generated for each software version**. If any component changes, a new software version MUST be assigned. (Section 3.1) ### Logical Components and BOM References v2.1.0 introduced **logical components** - an abstraction level combining multiple components, for example an operating system, application, framework or container, used to preserve product-level structure that a flat component list would lose. Only a reduced set of data fields must be populated for them. (Sections 3.2.2, 5.2) SBOMs of used components MAY be referenced instead of merged, if they are TR-03183-2 compliant. The SBOM provider is responsible for availability of referenced SBOMs. When referencing, the referencing SBOM MUST extract and include creator, name, and version from the referenced BOM. (Section 3.2.5, 5.1) ### Digital Signature Ideally, SBOMs should be digitally signed so recipients can verify their authenticity. (Section 8.1.15) --- ## Practical Compliance Checklist **For the reporting obligations (in force from 11 September 2026):** 1. **Get EU Login sorted for the ENISA Single Reporting Platform** - personal accounts with MFA, created in advance, with your one Primary AR and up to 20 Secondary ARs named. There is no submission API, so make sure the humans who will submit have working access. 2. **Determine and record your CSIRT designated as coordinator** using the Article 14(7) cascade. Selecting the wrong one can invalidate a notification and force a resubmission inside the 24-hour window. 3. **Track the 24- and 72-hour clocks internally.** The platform's 72-hour counter currently runs from your early-warning submission rather than from the moment you became aware. 4. **Decide who may invoke particularly exceptional circumstances**, and on what grounds, before you are inside the 72-hour window. 5. **Stand up SBOM-driven vulnerability monitoring** so you can answer "which products and versions contain this component?" inside the 24-hour early-warning window. 6. **Publish a security.txt and CVD policy** per BSI TR-03183-3 and RFC 9116, and be ready to issue CSAF v2.0 advisories. **Before 11 December 2027:** 7. **Generate an SBOM** for each software version as required by CRA Annex I, Part II(1). 8. **Use CycloneDX 1.6+ or SPDX 3.0.1+** in JSON or XML format. 9. **Cover the scope of delivery** plus recursive dependencies to the first external component (at minimum, identify that component) - deeper than the CRA's top-level floor. 10. **Indicate completeness** of dependency enumeration for each component. 11. **Include all required component fields**: creator, name, version, filename, dependencies, distribution licences, SHA-512 hash, executable/archive/structured properties. 12. **Use SPDX licence identifiers** - never use licence text as a substitute. 13. **Do not embed vulnerability information** - use CSAF/VEX instead. 14. **Digitally sign** the SBOM so recipients can verify authenticity (recommended). 15. **File the SBOM in your technical documentation** alongside the CVD policy, vulnerability contact address, and secure update design (Annex VII, point 2(b)). 16. **Keep it current and keep it for 10 years** - continuously updated during the support period (Article 31(2)), retained for 10 years or the support period, whichever is longer (Article 13(13)). 17. **Be prepared to provide** the SBOM to market surveillance authorities upon reasoned request (Annex VII, point 8). 18. **If sharing with users**, document where the SBOM can be accessed (Annex II, Part I, point 9). 19. **Check your product classification** against Implementing Regulation (EU) 2025/2392 - "important" or "critical" changes your conformity assessment route. --- ## Schema Mappings BSI TR-03183-2 Section 8.2 provides detailed JSON mappings for CycloneDX 1.6 and SPDX 3.0.1. For general CycloneDX and SPDX field mappings, see our [Schema Crosswalk](/compliance/schema-crosswalk/). BSI maintains a CycloneDX property taxonomy for TR-03183-2 specific fields: [github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy](https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy) --- ## Related Frameworks - [BSI TR-03183-2](/compliance/bsi-tr-03183/) - the SBOM specification in detail - [EU NIS2 Directive](/compliance/eu-nis2/) - EU cybersecurity law for critical entities - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - US baseline for SBOM content - [CISA Framing Document](/compliance/cisa-framing/) - CISA guidance on SBOM attributes --- ## Official Sources - [EU Cyber Resilience Act (Regulation 2024/2847)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [Commission Implementing Regulation (EU) 2025/2392](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392) - technical descriptions of important and critical products - [European Commission: CRA application guidance, C(2026) 5252 (27 July 2026)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation) - [European Commission: CRA Implementation factpage](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation) - [European Commission: CRA Reporting Obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) - [European Commission: CRA Implementation FAQ](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions) - [ENISA: CRA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp) - [ENISA: CRA SRP Frequently Asked Questions](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions) - [ENISA: CRA Single Reporting Platform Factsheet v1.0](https://www.enisa.europa.eu/sites/default/files/2026-07/ENISA_CRA_SRP_Factsheet_v1.0_0.pdf) (PDF) - [ENISA: CRA SRP Glossary](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2) - field-by-field reporting guidance - [ENISA: List of CSIRTs designated as coordinators](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators) - [CRA SRP portal](https://portal.cra-srp.enisa.europa.eu) - live from 11 September 2026 - [Commission Delegated Regulation (EU) 2026/881](https://eur-lex.europa.eu/eli/reg_del/2026/881/oj/eng) - delaying dissemination of notifications - [BSI TR-03183: Cyber Resilience Requirements](https://bsi.bund.de/dok/TR-03183-en) - Parts 1 (v1.0.0), 2 (v2.1.0), 3 (v1.0.0) and H (v1.1.0) - [BSI TR-03183-1 OSCAL controls](https://github.com/tr-03183/tr-03183-1) --- **Disclaimer:** This page represents our interpretation of the EU Cyber Resilience Act and the BSI TR-03183 Technical Guideline family. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # EU NIS2 Directive SBOM Requirements URL: https://sbomify.com/compliance/eu-nis2/ Description: Understanding NIS2 Directive cybersecurity requirements and how SBOMs support supply chain security, asset management, and incident response. [← Back to Compliance Overview](/compliance/) **Who it affects:** EU "essential" and "important" entities (and their management) responsible for cybersecurity risk management and incident reporting across their operations and supply chains.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The [NIS2 Directive](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32022L2555) is the EU's baseline cybersecurity law for "essential" and "important" entities. Unlike the CRA, **NIS2 does not explicitly mandate SBOMs by name or define SBOM field-level requirements**. Instead, it mandates cybersecurity risk-management outcomes (supply chain security, secure acquisition/development, vulnerability handling, and asset management) that SBOMs are commonly used to evidence. ## What NIS2 Requires (SBOM-Relevant) NIS2 requires risk-management measures including **supply chain security** and **security in acquisition, development and maintenance**, including **vulnerability handling and disclosure**, plus **asset management**. It also introduces strict incident reporting expectations (24h/72h timelines for significant incidents), which increases the operational need to rapidly determine whether a newly disclosed vulnerability affects your systems. ## NIS2 Implementing Rules Get Closer to "SBOM Language" For certain NIS2 "relevant entities" (DNS, cloud, data centres, CDNs, managed services/MSSPs, online marketplaces/search engines/social networks, trust services), the [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32024R2690) specifies procurement and supply chain controls and explicitly requires **"information describing the hardware and software components used in the ICT services or ICT products"** as part of secure acquisition processes. This is effectively an "SBOM/HBOM or equivalent component inventory" expectation in procurement form. | NIS2 Requirement | Description | Status | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | Supply chain security | Security measures covering relationships with direct suppliers/service providers | Required | | Secure acquisition, development, maintenance | Includes vulnerability handling and disclosure | Required | | Asset management | Part of required cybersecurity risk-management measures | Required | | Incident reporting speed | Significant incident notification within 24h/72h timelines | Required | | Component information for acquired ICT | "Information describing the hardware and software components used" (for in-scope entities under Implementing Regulation 2024/2690) | Required for in-scope entities | ## Practical SBOM Takeaways for NIS2 Even though NIS2 does not say "you must publish an SBOM", SBOMs are a practical way to operationalize and evidence NIS2 controls: - **Procurement:** Request SBOM/HBOM (or equivalent component inventory) from suppliers, and require updates over the lifecycle - **Vulnerability response:** Correlate SBOMs with vulnerability advisories to answer "are we affected?" within incident-reporting timelines - **Supplier governance:** Tie SBOM delivery + vulnerability handling obligations into supplier contracts and reviews ## Key Takeaway Since NIS2 does not define SBOM fields, align with [NTIA](/compliance/ntia-minimum-elements/)/[CISA](/compliance/cisa-minimum-elements/) minimum elements for component identity, version, supplier, identifiers, and dependency relationships. Treat that as your "NIS2-ready" SBOM baseline. ## Related Frameworks - [EU Cyber Resilience Act](/compliance/eu-cra/) - EU law that explicitly requires SBOMs - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - Recommended baseline for SBOM content ## Official Sources - [EU NIS2 Directive (Directive 2022/2555)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32022L2555) - [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32024R2690) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # Executive Order 14028 SBOM Requirements URL: https://sbomify.com/compliance/eo-14028/ Description: Understanding Executive Order 14028 and its SBOM requirements for US federal agencies and software vendors selling to the government. [← Back to Compliance Overview](/compliance/) **Who it affects:** US federal agencies and any software vendors/providers that sell software to the US federal government (directly or through integrators).

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview [Executive Order 14028](https://www.gsa.gov/technology/government-it-initiatives/cybersecurity/executive-order-14028) ("Improving the Nation's Cybersecurity", issued May 12, 2021) is a binding directive for US federal agencies that kicked off modern US government SBOM adoption. It directs the Department of Commerce to publish minimum elements for an SBOM and directs NIST to issue software supply chain security guidance that includes **providing a purchaser an SBOM for each product** (directly or by publishing it on a public website). EO 14028 defines an SBOM as "a formal record containing the details and supply chain relationships of various components used in building software." ## Key Requirements EO 14028 requires: - **SBOM provision to purchasers** - Software vendors must provide an SBOM directly or publish it on a public website - **Supply chain security measures** - Enhanced security practices for the software supply chain - **Vulnerability handling process** - Processes for identifying and addressing vulnerabilities ## What EO 14028 Does NOT Specify EO 14028 **does not specify SBOM field-level requirements**. Instead, it defers to the [NTIA minimum elements](/compliance/ntia-minimum-elements/) and subsequent guidance for the actual SBOM content requirements. ## Policy Updates (2025–2026) EO 14028 itself has **not been rescinded** and remains in effect. However, the implementing guidance has changed significantly: - **[EO 14144](https://www.federalregister.gov/documents/2025/01/17/2025-01470/strengthening-and-promoting-innovation-in-the-nations-cybersecurity) (16 January 2025):** The Biden administration issued EO 14144 to strengthen EO 14028 with more rigorous third-party attestation requirements, including mandatory machine-readable attestations submitted to CISA, high-level artifacts such as SBOMs, and centralized validation. - **[EO 14306](https://www.whitehouse.gov/presidential-actions/2025/06/sustaining-select-efforts-to-strengthen-the-nations-cybersecurity-and-amending-executive-order-13694-and-executive-order-14144/) (6 June 2025):** The Trump administration rescinded key portions of EO 14144, removing the enhanced attestation mandates, the requirement for vendors to provide SBOMs as "high-level artifacts," the CISA centralized validation role, and several other provisions. NIST guidance updates (SP 800-53, SP 800-218) and FedRAMP requirements were retained. EO 14028's own text was left intact. - **[OMB Memorandum M-26-05](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf) (23 January 2026):** OMB rescinded Memorandums M-22-18 and M-23-16, which had required agencies to obtain standardized self-attestation forms from software vendors. The new approach allows each agency to develop its own risk-based assurance processes. The universal attestation requirement is now **optional** – agencies may use CISA's common form at their discretion. Notably, M-26-05 states that agencies adopting contractual terms for cloud service providers should specify that the producer must provide an **SBOM of the runtime production environment upon request**. ### What This Means in Practice The shift is from a centralized, one-size-fits-all attestation mandate to a decentralized, agency-led approach: 1. EO 14028's core SBOM and supply chain security principles remain in effect 2. Agencies are **no longer required** to use the standardized CISA attestation form – but they **may** choose to 3. Agencies can now tailor their assurance requirements to their specific risk profiles 4. SBOMs remain relevant – agencies may require them contractually, and M-26-05 specifically encourages SBOM requirements for cloud service providers 5. Your SBOM should still follow the [NTIA minimum elements](/compliance/ntia-minimum-elements/) at a minimum ## Official Sources - [Executive Order 14028 – Improving the Nation's Cybersecurity](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity) (Federal Register, May 2021) - [GSA: Executive Order 14028 implementation](https://www.gsa.gov/technology/government-it-initiatives/cybersecurity/executive-order-14028) - [Executive Order 14144 – Strengthening and Promoting Innovation in the Nation's Cybersecurity](https://www.federalregister.gov/documents/2025/01/17/2025-01470/strengthening-and-promoting-innovation-in-the-nations-cybersecurity) (Federal Register, January 2025) - [Executive Order 14306 – Sustaining Select Efforts to Strengthen the Nation's Cybersecurity](https://www.whitehouse.gov/presidential-actions/2025/06/sustaining-select-efforts-to-strengthen-the-nations-cybersecurity-and-amending-executive-order-13694-and-executive-order-14144/) (White House, June 2025) - [OMB Memorandum M-26-05 – Adopting a Risk-based Approach to Software and Hardware Security](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf) (January 2026) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # FDA Medical Device SBOM Requirements (2025) URL: https://sbomify.com/compliance/fda-medical-device/ Description: Guide to FDA cybersecurity guidance for medical devices, including SBOM requirements, support level, and end-of-support date expectations. [← Back to Compliance Overview](/compliance/) **Who it affects:** Medical device manufacturers preparing FDA premarket submissions (and their software suppliers) who must document cybersecurity, including SBOM expectations, for devices marketed in the US.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The [FDA Cybersecurity in Medical Devices guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions) (June 2025) adds sector-specific SBOM expectations for medical device manufacturers. The guidance recommends providing a machine-readable SBOM consistent with the [minimum elements](/compliance/ntia-minimum-elements/) (also referred to as baseline attributes) identified in NTIA's _Framing Software Component Transparency_ (October 2021), plus additional lifecycle properties. **Important:** This is FDA guidance, not a regulation. The document uses "should" language, meaning these are strong recommendations that FDA expects manufacturers to follow for premarket submissions, but they are not legally binding requirements in the same way as regulations. ## SBOM Requirements | Field | Description | Status | | -------------------------------- | ----------------------------------------------------------------------------- | ------------------- | | Baseline attributes | SBOM consistent with CISA Framing baseline attributes | FDA recommends | | Software Component Support Level | Current support status (e.g., full support, security-fixes-only, unsupported) | SBOM should include | | End-of-Support Date | Date when support for the component will end | SBOM should include | ## Why Lifecycle Properties Matter These lifecycle properties are critical for medical device security because: - Medical devices have long operational lifetimes (often 10+ years) - Healthcare organizations need to plan for component end-of-life - Unsupported components represent elevated security risk ## Representing Lifecycle Data For technical guidance on representing support level and end-of-support date in CycloneDX and SPDX, see: - [Schema Crosswalk](/compliance/schema-crosswalk/) - Field mappings for lifecycle properties - [CLE (Common Lifecycle Enumeration)](/compliance/cle/) - Standard for machine-readable lifecycle events ## Related Frameworks - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - Baseline attributes referenced by FDA - [CISA Framing Document](/compliance/cisa-framing/) - Source of baseline attribute definitions ## Score uploaded SBOMs against the FDA checklist sbomify ships an **FDA Medical Device (2025)** plugin that grades each uploaded SBOM against the FDA baseline attributes plus the support-level and end-of-support lifecycle properties. Enable it from the **Plugins** page in your workspace sidebar: ## Additional Resources For more details, see our [FDA Medical Device SBOM Requirements guide](/2026/01/09/fda-medical-device-sbom-requirements/). ## Official Source - [FDA Cybersecurity in Medical Devices Guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # NIST 800-53 and SBOM Requirements: Security Controls for Software Supply Chains URL: https://sbomify.com/compliance/nist-800-53/ Description: How NIST SP 800-53 Rev 5 security controls relate to SBOM requirements, covering the SA and SR control families for software supply chain risk management. [← Back to Compliance Overview](/compliance/) **Who it affects:** U.S. federal agencies, contractors handling federal information systems, and any organization that adopts NIST 800-53 as its security control baseline (including those pursuing FedRAMP authorization or aligning with the NIST Cybersecurity Framework).

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview [NIST Special Publication 800-53 Revision 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) ("Security and Privacy Controls for Information Systems and Organizations") is the most comprehensive catalog of security and privacy controls published by the National Institute of Standards and Technology (NIST). Originally released in 2005 and most recently updated in September 2020 (with ongoing updates), NIST SP 800-53 provides a structured set of controls that federal agencies must implement to protect their information systems. While NIST 800-53 does not use the term "SBOM" explicitly, several control families directly address the software supply chain transparency, component tracking, and provenance requirements that SBOMs are designed to satisfy. Organizations that generate and maintain SBOMs are well-positioned to demonstrate compliance with these controls. NIST 800-53 Rev 5 is part of a broader ecosystem of NIST risk management frameworks. It works alongside [NIST SP 800-37](https://csrc.nist.gov/pubs/sp/800/37/r2/final) (Risk Management Framework), [NIST SP 800-171](/compliance/nist-800-171/) (Protecting CUI), and the [NIST Cybersecurity Framework (CSF) 2.0](https://www.nist.gov/cyberframework). Understanding how these standards interconnect is essential for building a complete compliance program. ## Key Control Families Relevant to SBOMs NIST 800-53 Rev 5 organizes its controls into 20 families. The following families have the most direct relevance to SBOM requirements and software supply chain security. ### SA – System and Services Acquisition The SA family addresses security throughout the system development life cycle, including controls for secure development practices, supply chain protections, and component documentation. **SA-4 (Acquisition Process)** requires organizations to include security and privacy requirements in acquisition contracts. For software acquisitions, this increasingly means requiring vendors to provide SBOMs alongside their products – aligning with the requirements of [Executive Order 14028](/compliance/eo-14028/). **SA-8 (Security and Privacy Engineering Principles)** calls for applying security engineering principles throughout the system development life cycle. SBOM generation during the build process is a practical implementation of these principles. **SA-9 (External System Services)** addresses risks from external service providers and requires organizations to understand the components and dependencies in externally provided software. SBOMs provide exactly this visibility. **SA-17 (Developer Security and Privacy Architecture and Design)** requires developers to produce and maintain documentation of the security architecture. An SBOM, as a machine-readable inventory of all software components, contributes directly to this documentation requirement. ### SR – Supply Chain Risk Management The SR family, introduced in NIST 800-53 Rev 5, is dedicated entirely to supply chain risk management. This is the most directly SBOM-relevant control family. **SR-1 (Supply Chain Risk Management Policy and Procedures)** establishes the requirement for a formal supply chain risk management program. SBOMs are a foundational tool for implementing such a program. **SR-3 (Supply Chain Controls and Processes)** requires organizations to employ supply chain controls throughout the system development life cycle. Continuous SBOM generation and monitoring satisfies this control. **SR-4 (Provenance)** is the control most directly aligned with SBOMs. It requires organizations to document, monitor, and maintain the provenance of systems and components. Provenance – knowing where each component came from, who supplied it, and what version it is – is precisely what an SBOM records. SR-4 enhancement (1), "Identity," requires establishing and maintaining unique identification of supply chain elements, processes, and personnel. Enhancement (2), "Track and Trace," addresses tracking the unique identification of components through the supply chain. SBOM generation with unique identifiers (such as [Package URL](https://github.com/package-url/purl-spec)) and SBOM signing (using tools like [Sigstore](https://www.sigstore.dev/)) directly satisfies these enhanced requirements. **SR-5 (Acquisition Strategies, Tools, and Methods)** addresses using diversified acquisition strategies to manage supply chain risk, including assessing suppliers and their development practices. **SR-11 (Component Authenticity)** requires organizations to develop and implement anti-counterfeit policies for system components. SBOMs with cryptographic hashes and signed provenance data help verify that components are authentic and unmodified. ### CM – Configuration Management **CM-8 (System Component Inventory)** requires maintaining an up-to-date inventory of system components. While traditionally interpreted as hardware and deployed software, modern implementations increasingly include software dependency inventories – which is what SBOMs provide at the application level. ### SI – System and Information Integrity **SI-2 (Flaw Remediation)** requires identifying, reporting, and correcting software flaws. SBOMs make this practical by providing the component inventory needed to match against vulnerability databases like the [National Vulnerability Database](https://nvd.nist.gov/) (NVD). **SI-5 (Security Alerts, Advisories, and Directives)** requires monitoring and responding to security advisories. With SBOMs, organizations can automate the correlation between new vulnerability advisories and their deployed software components. ## NIST 800-53 in the Broader NIST Framework Ecosystem NIST publishes several complementary standards. Understanding the relationships between them helps organizations build a coherent compliance program. | Standard | Focus | Relationship to 800-53 | | ------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **NIST SP 800-53 Rev 5** | Security and privacy controls catalog | The controls catalog itself | | **NIST SP 800-37 Rev 2** | Risk Management Framework (RMF) | Defines the process for selecting and implementing 800-53 controls | | **NIST SP 800-171 Rev 3** | Protecting Controlled Unclassified Information (CUI) | Derives its controls from 800-53; required for DoD contractors via [CMMC](/compliance/nist-800-171/) | | **NIST CSF 2.0** | Cybersecurity Framework | Maps to 800-53 controls; provides a higher-level risk management structure | | **NIST SP 800-218** | Secure Software Development Framework (SSDF) | Addresses secure development practices that complement 800-53 SA/SR controls | | **NIST SP 800-161 Rev 1** | Cybersecurity Supply Chain Risk Management (C-SCRM) | Provides detailed guidance for implementing 800-53 SR controls | For organizations subject to [Executive Order 14028](/compliance/eo-14028/), NIST 800-53 SR controls provide the detailed implementation guidance that the Executive Order references. EO 14028 directed NIST to issue supply chain security guidance, and the SR family is part of that response. ## Practical Implications ### For Federal Agencies Federal agencies are required to implement NIST 800-53 controls as part of the FISMA (Federal Information Security Management Act) process. This means: 1. **Require SBOMs from software vendors** as part of your acquisition process (SA-4) 2. **Maintain a component inventory** for all deployed software (CM-8), using SBOMs as the authoritative source 3. **Implement provenance tracking** for all software components (SR-4), which SBOMs directly support 4. **Automate vulnerability correlation** by matching SBOM data against NVD feeds (SI-2, SI-5) ### For Software Vendors Selling to the Federal Government If you supply software to federal agencies, expect that your customers will invoke NIST 800-53 controls in their contracts. Be prepared to: 1. Provide SBOMs in a standard format ([CycloneDX](https://cyclonedx.org/) or [SPDX](https://spdx.dev/)) 2. Document the provenance of your components 3. Maintain vulnerability disclosure and response processes 4. Update SBOMs with each release [sbomify](https://sbomify.com) helps organizations meet these requirements by automating SBOM generation, enrichment, and vulnerability monitoring in CI/CD pipelines, with a [Trust Center](/features/trust-center/) for distributing SBOMs and compliance documents to federal customers. See our [SBOM generation guides](/guides/) for language-specific instructions. ### For Private Sector Organizations While NIST 800-53 is mandatory for federal systems, many private sector organizations voluntarily adopt it (or its derivative, 800-171) as a security baseline. The NIST Cybersecurity Framework 2.0 maps directly to 800-53 controls and is widely adopted across industries. If you are implementing CSF 2.0, you are effectively implementing a subset of 800-53 – including the supply chain and component management controls where SBOMs add value. ## FedRAMP and NIST 800-53 [FedRAMP](https://www.fedramp.gov/) (Federal Risk and Authorization Management Program) uses NIST 800-53 as its control baseline for cloud service providers. FedRAMP Authorization requires implementing 800-53 controls at Low, Moderate, or High baselines depending on the sensitivity of the data processed. Cloud service providers pursuing FedRAMP Authorization should treat SBOM generation and supply chain documentation as part of their 800-53 control implementation, particularly for SA-4, SR-3, SR-4, and CM-8. ## Official Sources - [NIST SP 800-53 Rev 5 (with updates)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) – Full control catalog - [NIST SP 800-53B](https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final) – Control baselines for information systems - [NIST SP 800-161 Rev 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final) – Cybersecurity Supply Chain Risk Management Practices - [NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final) – Secure Software Development Framework (SSDF) - [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) --- ## Frequently Asked Questions ### What is NIST 800-53? NIST Special Publication 800-53 is a comprehensive catalog of security and privacy controls for federal information systems and organizations, published by the National Institute of Standards and Technology. Currently in Revision 5, it contains over 1,000 controls organized into 20 families covering everything from access control to supply chain risk management. ### Does NIST 800-53 require SBOMs? NIST 800-53 does not explicitly use the term "SBOM." However, several controls – particularly SR-4 (Provenance), CM-8 (System Component Inventory), and SA-17 (Developer Security Architecture) – require the exact type of software component documentation and supply chain transparency that SBOMs provide. SBOMs are a practical and widely accepted method for satisfying these controls. ### What is the difference between NIST 800-53 and NIST 800-171? NIST 800-53 is the full security control catalog for federal information systems. [NIST SP 800-171](/compliance/nist-800-171/) is a derived subset focused specifically on protecting Controlled Unclassified Information (CUI) in nonfederal systems – most commonly relevant to Department of Defense contractors through the CMMC program. 800-171 controls trace back to 800-53 but are scoped for nonfederal environments. ### How does NIST 800-53 relate to the NIST Cybersecurity Framework? The NIST Cybersecurity Framework (CSF) 2.0 provides a high-level, voluntary risk management structure organized around six functions (Govern, Identify, Protect, Detect, Respond, Recover). CSF references map directly to specific 800-53 controls. Organizations implementing CSF are effectively adopting a curated subset of 800-53 controls, including those related to supply chain risk management. ### What is NIST SP 800-53 Rev 5? Revision 5, published in September 2020, is the current version of NIST 800-53. Key changes from Rev 4 include the addition of the SR (Supply Chain Risk Management) control family, integration of privacy controls alongside security controls, and removal of the federal-only designation – making the controls applicable to any organization. The supply chain controls in Rev 5 are directly relevant to SBOM requirements. --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # NIST SP 800-171 SBOM Requirements: Protecting CUI in Software Supply Chains URL: https://sbomify.com/compliance/nist-800-171/ Description: How NIST SP 800-171 Rev 3 supply chain and component inventory controls relate to SBOM requirements for organizations handling Controlled Unclassified Information. Includes the CMMC phased rollout timeline through 2028. [← Back to Compliance Overview](/compliance/) **Who it affects:** Nonfederal organizations (primarily Department of Defense contractors) that process, store, or transmit Controlled Unclassified Information (CUI). Also relevant to organizations pursuing Cybersecurity Maturity Model Certification (CMMC) Level 2 or higher.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview [NIST Special Publication 800-171 Revision 3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) ("Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations"), published in May 2024, defines the security requirements that nonfederal organizations must implement to protect Controlled Unclassified Information (CUI). CUI is information that the government creates or possesses that requires safeguarding, such as technical data, export-controlled information, and law enforcement sensitive data. NIST SP 800-171 is most commonly encountered through Department of Defense (DoD) contracts. The DFARS clause 252.204-7012 requires DoD contractors to implement NIST 800-171, and the [Cybersecurity Maturity Model Certification](https://dodcio.defense.gov/CMMC/) (CMMC) program uses 800-171 as the basis for its Level 2 assessment. > **Which revision applies?** Rev 3 is NIST's current publication, but DoD contracts do not yet require it. [Class Deviation 2024-O0013](https://www.acq.osd.mil/dpap/policy/policyvault/USA001074-24-DPC.pdf) pins DFARS 252.204-7012 compliance to **Rev 2**, and CMMC assessments under [32 CFR Part 170](https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170) are conducted against Rev 2's 110 requirements. The deviation remains in effect until rescinded, and moving CMMC to Rev 3 requires formal rulemaking. Contractors should comply with Rev 2 today while tracking Rev 3, since its supply chain controls signal where DoD requirements are heading. While NIST 800-171 does not explicitly use the term "SBOM," Revision 3 introduced three new control families – including Supply Chain Risk Management – that create strong requirements for the kind of software component transparency that SBOMs provide. ## Relationship to NIST SP 800-53 NIST SP 800-171 Rev 3 derives its controls from [NIST SP 800-53 Rev 5](/compliance/nist-800-53/), making 800-53 the "single authoritative source" for the underlying security requirements. Specifically, 800-171 Rev 3 controls are drawn from the 800-53 moderate control baseline defined in [NIST SP 800-53B](https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final), tailored for nonfederal environments. | Standard | Scope | Audience | Controls | | ------------------------- | ------------------------------------------------- | ----------------------------------------- | ---------------------------------- | | **NIST SP 800-53 Rev 5** | Full security control catalog for federal systems | Federal agencies | 1,000+ controls across 20 families | | **NIST SP 800-171 Rev 3** | Protecting CUI in nonfederal systems | DoD contractors, nonfederal organizations | 97 requirements across 17 families | | **NIST SP 800-172** | Enhanced requirements for high-value CUI | CMMC Level 3 organizations | 35 enhanced requirements | Understanding this hierarchy matters because some 800-53 controls highly relevant to SBOMs (such as SR-4, Provenance) are not directly included in 800-171 but may be required through DoD supplemental guidance or CMMC Level 3 assessments. > **Note:** NIST published [SP 800-172 Rev 3](https://csrc.nist.gov/pubs/sp/800/172/r3/final) in May 2026, together with the SP 800-172A Rev 3 assessment procedures. CMMC Level 3 remains anchored to the requirements DoD selected from the 2021 version of 800-172 until the program adopts the revision through rulemaking. ## Key Control Families Relevant to SBOMs NIST 800-171 Rev 3 organizes its 97 requirements into 17 control families. Revision 3 added three new families that are particularly relevant to software supply chain security. ### 03.17 – Supply Chain Risk Management (New in Rev 3) This family was added in Rev 3 to address the growing threat to software supply chains. It maps to the SR family in NIST SP 800-53. **03.17.01 – Supply Chain Risk Management Plan** (maps to 800-53 SR-2) Requires organizations to develop, review, and update a plan for managing supply chain risks across the system development life cycle, from acquisition through disposal. SBOMs are a practical implementation tool for the component visibility this plan requires. **03.17.02 – Acquisition Strategies, Tools, and Methods** (maps to 800-53 SR-5) Requires organizations to develop acquisition strategies that identify and mitigate supply chain risks. For software acquisitions, this increasingly means requiring SBOM delivery from vendors. **03.17.03 – Supply Chain Requirements and Processes** (maps to 800-53 SR-3) Requires establishing processes for identifying and addressing weaknesses in supply chain elements. The NIST discussion for this control explicitly mentions maintaining **provenance** – knowing where each component came from and ensuring it has not been tampered with. SBOMs provide exactly this component-level provenance documentation. ### 03.04 – Configuration Management **03.04.10 – System Component Inventory** (maps to 800-53 CM-8, CM-8(1)) Requires maintaining an up-to-date inventory of system components and updating it as part of installations, removals, and system updates. NIST specifies that the inventory should include system names, software version numbers, software owners, and software license information. At the application level, this is precisely what an SBOM documents. **03.04.08 – Authorized Software – Allow by Exception** Requires identifying all software programs authorized to execute on the system and implementing a deny-all, allow-by-exception policy. Maintaining an SBOM makes it possible to verify that deployed software components match authorized inventories. ### 03.16 – System and Services Acquisition (New in Rev 3) **03.16.02 – Unsupported System Components** Requires replacing system components when the developer, vendor, or manufacturer no longer provides support. SBOMs with lifecycle data (such as [CLE](/compliance/cle/) – Common Lifecycle Enumeration) make it possible to automatically detect end-of-life and end-of-support components. **03.16.03 – External System Services** Requires that providers of external system services comply with the organization's security requirements. For software services, this can include requiring SBOMs as part of the vendor assessment process. ### 03.14 – System and Information Integrity **03.14.01 – Flaw Remediation** Requires identifying, reporting, and correcting system flaws, with security-relevant updates applied within defined timeframes. SBOMs enable this by providing the component inventory needed to match against vulnerability databases like the [NVD](https://nvd.nist.gov/) and the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). **03.14.03 – Security Alerts, Advisories, and Directives** Requires receiving security alerts and advisories from external organizations on an ongoing basis. SBOMs make it possible to automatically correlate new advisories with your deployed components, rather than relying on manual cross-referencing. ## CMMC and NIST 800-171 The [Cybersecurity Maturity Model Certification](https://dodcio.defense.gov/CMMC/) (CMMC) is the DoD's program for verifying that contractors have implemented the security requirements in NIST 800-171. CMMC 2.0 defines three levels: - **Level 1** – 15 basic safeguarding requirements (self-assessment) - **Level 2** – Full NIST SP 800-171 implementation (third-party assessment by a C3PAO) - **Level 3** – NIST SP 800-171 plus selected 800-172 enhanced requirements (government-led assessment) CMMC Level 2 assessments are currently conducted against the **110 requirements of NIST 800-171 Rev 2**, using the assessment objectives in NIST SP 800-171A. The 97 requirements and 422 determination statements of Rev 3 will only apply to CMMC once DoD transitions the program to Rev 3 through formal rulemaking. The DoD CIO publishes [Organization-Defined Parameters](https://dodcio.defense.gov/CMMC/) (ODPs) that specify values for customizable fields in the 800-171 Rev 3 controls ahead of that transition. Organizations preparing for CMMC should treat SBOM generation and management as supporting evidence for multiple controls, particularly 03.17.01 (Supply Chain Risk Management Plan), 03.04.10 (System Component Inventory), and 03.14.01 (Flaw Remediation). ### CMMC Rollout Timeline CMMC requirements are being phased into DoD contracts under [32 CFR 170.3](https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170) and the [DFARS acquisition final rule](https://www.federalregister.gov/documents/2025/09/10/2025-17359/defense-federal-acquisition-regulation-supplement-assessing-contractor-implementation-of) (effective 10 November 2025, adding contract clause 252.204-7021 and solicitation provision 252.204-7025): | Phase | Start Date | What Applies | | ------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Phase 1 | 10 November 2025 | CMMC clauses appear in solicitations; Level 1 and Level 2 self-assessments required, at DoD's discretion | | Phase 2 | 10 November 2026 | CMMC Level 2 third-party (C3PAO) certification requirements begin appearing in applicable solicitations | | Phase 3 | 10 November 2027 | Level 2 certification requirements broaden; Level 3 (government-led DIBCAC) assessments introduced | | Phase 4 | 10 November 2028 | Full implementation: all applicable DoD contracts involving FCI or CUI include the required CMMC level as a condition of award | The practical takeaway: contractors handling CUI who will need a Level 2 certification should be assessment-ready before Phase 2 begins in November 2026. Evidence for the supply chain and component inventory controls, including SBOMs for the software you build and buy, takes time to put in place. ## Key Changes from Rev 2 to Rev 3 | Change | Details | | ------------------------- | ---------------------------------------------------------------------------------------------------- | | **Control count** | Reduced from 110 to 97 requirements (but maps to 156 underlying 800-53 controls) | | **3 new families** | Planning (03.15), System and Services Acquisition (03.16), Supply Chain Risk Management (03.17) | | **33 controls withdrawn** | Various consolidations and removals | | **ODPs introduced** | 88 Organization-Defined Parameters across 49 requirements, replacing vague terms like "periodically" | | **Assessment scope** | 422 determination statements (32% more than Rev 2) | | **800-53 alignment** | Full alignment with 800-53 Rev 5; "basic/derived" distinction eliminated | The addition of the Supply Chain Risk Management family (03.17) is the most significant change for SBOM relevance. Rev 2 had no dedicated supply chain controls. ## Practical Implications ### For DoD Contractors If you handle CUI as a DoD contractor: 1. **Implement a supply chain risk management plan** (03.17.01) that includes SBOM generation and monitoring for your software products 2. **Maintain a software component inventory** (03.04.10) using SBOMs as the authoritative source for application-level components 3. **Automate flaw remediation** (03.14.01) by matching SBOM data against vulnerability databases and the CISA KEV catalog 4. **Require SBOMs from your subcontractors** as part of your acquisition strategy (03.17.02), ensuring supply chain transparency flows down ### For Software Vendors to DoD Contractors If you sell software to organizations that handle CUI: 1. Be prepared to provide SBOMs in a standard format ([CycloneDX](https://cyclonedx.org/) or [SPDX](https://spdx.dev/)) 2. Maintain vulnerability disclosure and response processes 3. Provide component lifecycle information (end-of-support dates) [sbomify](https://sbomify.com) helps organizations meet these requirements by automating SBOM generation, enrichment, and vulnerability monitoring, with built-in distribution capabilities for sharing SBOMs with prime contractors and assessors. See our [SBOM generation guides](/guides/) for language-specific instructions. ## Official Sources - [NIST SP 800-171 Rev 3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) – Full publication - [NIST SP 800-171A Rev 3](https://csrc.nist.gov/pubs/sp/800/171/a/r3/final) – Assessment procedures - [NIST SP 800-172 Rev 3](https://csrc.nist.gov/pubs/sp/800/172/r3/final) – Enhanced requirements (May 2026) - [NIST SP 800-53 Rev 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) – Parent control catalog - [CMMC Program](https://dodcio.defense.gov/CMMC/) – DoD certification program - [32 CFR Part 170](https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170) – CMMC Program rule, including the phased implementation in 170.3 - [DFARS Final Rule (Case 2019-D041)](https://www.federalregister.gov/documents/2025/09/10/2025-17359/defense-federal-acquisition-regulation-supplement-assessing-contractor-implementation-of) – Acquisition rule adding CMMC clauses to contracts, effective 10 November 2025 - [DFARS 252.204-7012](https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting.html) – Contract clause requiring 800-171 implementation - [Class Deviation 2024-O0013, Revision 1](https://www.acq.osd.mil/dpap/policy/policyvault/USA001074-24-DPC.pdf) – Pins DFARS 252.204-7012 to NIST SP 800-171 Rev 2 --- ## Frequently Asked Questions ### What is NIST 800-171? NIST Special Publication 800-171 is a set of security requirements for protecting Controlled Unclassified Information (CUI) in nonfederal systems and organizations. Currently in Revision 3 (published May 2024), it contains 97 requirements across 17 control families. It is most commonly required through DoD contracts and the CMMC certification program. ### Does NIST 800-171 require SBOMs? NIST 800-171 Rev 3 does not explicitly use the term "SBOM." However, several controls create requirements that SBOMs directly support: 03.04.10 requires a system component inventory including software names, versions, and license information; 03.17.03 requires maintaining provenance in supply chain processes; and 03.14.01 requires timely flaw remediation, which depends on knowing what software components are deployed. SBOMs are the practical tool for satisfying these requirements. ### What is the difference between NIST 800-171 and NIST 800-53? [NIST SP 800-53](/compliance/nist-800-53/) is the comprehensive security control catalog for federal information systems, containing over 1,000 controls across 20 families. NIST SP 800-171 is a derived subset of 97 requirements tailored for protecting CUI in nonfederal systems. 800-171 Rev 3 controls map directly to 800-53 Rev 5 controls from the moderate baseline. ### What is CMMC and how does it relate to NIST 800-171? CMMC (Cybersecurity Maturity Model Certification) is the DoD's program for verifying that contractors have implemented NIST 800-171 requirements. CMMC Level 2 assessments are currently conducted against the 110 requirements of NIST 800-171 Revision 2, because a DoD class deviation keeps DFARS 252.204-7012 pinned to Rev 2 until the CMMC program transitions to Rev 3 through rulemaking. Organizations seeking DoD contracts that involve CUI must achieve CMMC Level 2 through a third-party assessment. ### When do I need CMMC certification? CMMC requirements are being phased into DoD contracts under 32 CFR 170.3. Phase 1 began on November 10, 2025, when the DFARS acquisition rule took effect and self-assessment requirements started appearing in solicitations. Phase 2 begins on November 10, 2026, when CMMC Level 2 third-party (C3PAO) certification requirements start appearing in applicable solicitations. Full implementation across all applicable DoD contracts arrives with Phase 4 on November 10, 2028. ### What changed in NIST 800-171 Rev 3? The most significant changes include the addition of three new control families (Planning, System and Services Acquisition, and Supply Chain Risk Management), full alignment with NIST SP 800-53 Rev 5, the introduction of 88 Organization-Defined Parameters across 49 requirements, and an increase to 422 assessment determination statements. The new Supply Chain Risk Management family (03.17) is the most relevant addition for SBOM requirements. --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # NTIA Minimum Elements for SBOM (2021, Superseded) URL: https://sbomify.com/compliance/ntia-minimum-elements/ Description: The NTIA 2021 Minimum Elements for a Software Bill of Materials, the original US SBOM baseline, updated and replaced by the CISA 2026 Minimum Elements on 29 July 2026. Covers the original seven data fields and how each maps to its 2026 successor. [← Back to Compliance Overview](/compliance/) > **Superseded.** On 29 July 2026 CISA published the [2026 Minimum Elements for a Software Bill of Materials](/compliance/cisa-minimum-elements/), which "updates and replaces" this 2021 NTIA document. This page is kept as a historical reference and for mapping legacy SBOMs forward. **For current guidance, use the [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/).** **Who it affects:** Software producers and suppliers (and their customers) who need a baseline SBOM structure, especially when selling into US federal or regulated/critical-infrastructure supply chains. Other frameworks like [FDA medical device guidance](/compliance/fda-medical-device/) and [CISA Framing](/compliance/cisa-framing/) reference these minimum elements as the baseline for SBOM content.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The [NTIA Minimum Elements for a Software Bill of Materials](https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf) is the foundational baseline for SBOM guidance in the United States. Published in July 2021, it defines seven core data fields that every SBOM should contain, plus implementation practices for SBOM generation and sharing. This document emerged from a multi-stakeholder process and represents the consensus "minimum viable SBOM" that balances utility with practicality. It remains the operative published baseline for US SBOM content: CISA's proposed successor has not been finalized, and other frameworks (such as [FDA medical device guidance](/compliance/fda-medical-device/)) continue to reference the NTIA elements. **Note:** NTIA frames these as "minimum elements" (guidance), not legally binding requirements. However, they are widely adopted as the de facto standard. ## Status: Superseded by the CISA 2026 Minimum Elements The 2021 minimum elements are the starting point of an evolving lineage, and several things have moved recently: - **These elements were superseded on 29 July 2026.** CISA, with the NSA, FBI and fifteen international partner agencies, published the [2026 Minimum Elements for a Software Bill of Materials](/compliance/cisa-minimum-elements/), which in its own words "updates and replaces" this NTIA document. The 2026 version adds 10 new elements, substantially revises 8, makes minor updates to 5, and removes 1. **If you are building an SBOM practice today, work from the 2026 elements.** - **The minimum elements concept has been extended to AI.** In May 2026, CISA and its G7 partners released [Software Bill of Materials for AI - Minimum Elements](https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements), joint guidance applying SBOM-style transparency to AI systems, covering models, datasets, and their dependencies. - **Federal procurement expectations became agency-led.** In January 2026, OMB memo [M-26-05](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf) rescinded the government-wide secure software attestation "common form" requirement from M-22-18 and M-23-16 in favor of risk-based, agency-defined assurance requirements. Agencies may still require SBOMs where they judge it appropriate, which makes the NTIA elements the natural baseline for those requests. The practical consequence: the seven NTIA fields below remain a useful historical reference, and every one of them survives in some form in the 2026 elements. But they are no longer sufficient on their own. See [what changed](/compliance/cisa-minimum-elements/#what-changed-from-ntia-2021). ## Required Data Fields | Data Field | Description | Status | | ------------------------ | ----------------------------------------------------------------------------------------- | --------------- | | Supplier Name | The name of the entity that creates, defines, and identifies components | Minimum element | | Component Name | Designation assigned to a unit of software defined by the original supplier | Minimum element | | Version | Identifier used by the supplier to specify a change in software | Minimum element | | Other Unique Identifiers | Other identifiers used to identify a component or serve as a lookup key (e.g., purl, CPE) | Minimum element | | Dependency Relationship | Characterizing the relationship that an upstream component has to software | Minimum element | | Author of SBOM Data | The name of the entity that creates the SBOM data | Minimum element | | Timestamp | Record of the date and time of the SBOM data assembly | Minimum element | ### How the 2021 fields map to 2026 Every 2021 data field survives into the [2026 minimum elements](/compliance/cisa-minimum-elements/), though four were renamed and one practice absorbed another. | NTIA 2021 field | CISA 2026 equivalent | Change | | ------------------------ | --------------------------------- | ------------ | | Supplier Name | Component Producer | Major update | | Component Name | Component Name | Minor update | | Version | Component Version | Major update | | Other Unique Identifiers | Component Identifiers | Major update | | Dependency Relationship | Component Dependency Relationship | Minor update | | Author of SBOM Data | SBOM Author | Major update | | Timestamp | SBOM Timestamp | Minor update | The 2026 version adds ten elements that have no 2021 equivalent, seven of which describe the SBOM document itself rather than its components: SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, plus Component Hash Value, Component Hash Algorithm, and Component License. ## Implementation Practices Beyond the seven data fields, NTIA also defines implementation practices: | Practice | Description | | ----------------------- | -------------------------------------------------------------- | | Frequency | SBOMs should be generated for each new release or update | | Depth | How deep dependency capture goes (direct vs transitive) | | Known Unknowns | Explicitly identifying components that could not be enumerated | | Distribution & Delivery | How SBOMs are made available to consumers | | Access Control | Roles and permissions for SBOM access | | Accommodation of Errors | Process for handling mistakes in SBOM data | ## Schema Mappings For CycloneDX and SPDX field mappings, see our [Schema Crosswalk](/compliance/schema-crosswalk/). ## Related Frameworks - [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/) - The current US baseline, which updates and replaces NTIA 2021 - [Executive Order 14028](/compliance/eo-14028/) - The directive that led to NTIA minimum elements ## Official Sources - [NTIA Minimum Elements for a Software Bill of Materials (2021)](https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf) - [Federal Register: Request for Comment on 2025 Minimum Elements for a Software Bill of Materials](https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials) - [CISA: Software Bill of Materials for AI - Minimum Elements](https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements) (May 2026) - [OMB Memorandum M-26-05: Adopting a Risk-based Approach to Software and Hardware Security](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf) (January 2026) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # PCI DSS 4.0 SBOM and Software Inventory Requirements URL: https://sbomify.com/compliance/pci-dss/ Description: Guide to PCI DSS 4.0 software component inventory requirements, including Requirement 6.3.2 for bespoke software and third-party dependencies. [← Back to Compliance Overview](/compliance/) **Who it affects:** Any merchant or service provider whose environment includes systems/processes that store, process, or transmit cardholder data or sensitive authentication data, plus systems that are connected to those systems or that could impact their security.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The Payment Card Industry Data Security Standard (PCI DSS) is a security standard for protecting payment card account data. The current version is **PCI DSS v4.0.1** (June 2024). PCI DSS does **not** mandate SBOMs by name or prescribe SBOM fields/schemas, but it _does_ create SBOM-adjacent requirements around software/component inventories and third-party dependencies. ## Scope PCI DSS scope covers: - The **Cardholder Data Environment (CDE)** - systems that store, process, or transmit cardholder data - Systems with **unrestricted connectivity** to the CDE - Systems that could **impact** cardholder data or sensitive authentication data security "System components" in scope explicitly include **software**, with examples including applications, software, and software components, including SaaS and bespoke/custom software. ## SBOM-Relevant Requirements | PCI DSS Requirement (v4.0.1) | What It Requires | Status | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | **6.3.2 Software component inventory (custom + embedded third-party)** | Maintain an **inventory of bespoke/custom software and third-party software components incorporated into bespoke/custom software** to support **vulnerability and patch management** (and validate inventory coverage). | **Best practice until 31 Mar 2025**, then required | | **6.4.3 Payment page script inventory + integrity** | For payment pages, maintain an **inventory of all scripts** (with justification) and implement methods to confirm each script is **authorized** and to assure **integrity**. | Required (where applicable) | | **12.8 Third-party service provider (TPSP) inventory** | Maintain a **list of TPSPs** with which account data is shared or that could affect account data security, including a description of services. Examples include payment gateways/processors and providers that manage in-scope components. | Required | ## Requirement 6.3.2 in Detail **Requirement 6.3.2** is the most SBOM-relevant requirement in PCI DSS. It explicitly requires: - An inventory of **bespoke and custom software** - An inventory of **third-party software components incorporated into bespoke/custom software** - The purpose is to facilitate **vulnerability and patch management** This is effectively an SBOM requirement for custom software, though PCI DSS does not prescribe a specific format (CycloneDX, SPDX, etc.). **Timeline:** This requirement is a best practice until March 31, 2025, after which it becomes mandatory. ## Payment Page Script Inventory (6.4.3) For e-commerce payment pages, **Requirement 6.4.3** requires: - An inventory of all scripts loaded on payment pages - Justification for each script's presence - Authorization controls for scripts - Integrity verification mechanisms This addresses the risk of Magecart-style attacks where malicious scripts are injected into payment pages. ## Assessment Approach PCI DSS v4.x supports two assessment approaches: - **Defined Approach** - Follow the specific requirements as written - **Customized Approach** - Meet the security objective through alternative controls This affects how you evidence compliance with inventory requirements. ## Practical SBOM Recommendations To satisfy PCI DSS inventory requirements: 1. **Generate SBOMs for custom/bespoke software** in your cardholder data environment 2. **Include third-party dependencies** in your SBOMs (this is what 6.3.2 explicitly requires) 3. **Maintain script inventories** for payment pages with justification and integrity controls 4. **Use SBOMs for vulnerability correlation** to support patch management processes 5. **Align with [NTIA minimum elements](/compliance/ntia-minimum-elements/)** for SBOM content ## Key Takeaway While PCI DSS doesn't mandate SBOMs by name, **Requirement 6.3.2 effectively requires an SBOM** for bespoke/custom software (including embedded third-party components). Organizations should treat their software component inventory as an SBOM and follow established SBOM practices. ## Related Frameworks - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - Recommended baseline for SBOM content - [CISA Framing Document](/compliance/cisa-framing/) - Terminology and format guidance ## Official Source - [PCI DSS v4.0.1 (June 2024)](https://www.pcisecuritystandards.org/document_library/) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # SBOM Schema Crosswalk: CycloneDX and SPDX Field Mappings URL: https://sbomify.com/compliance/schema-crosswalk/ Description: Field mapping reference for the CISA 2026 SBOM Minimum Elements across CycloneDX 1.6/1.7, SPDX 2.3 and SPDX 3.0, plus a general crosswalk for SBOM properties across formats. [← Back to Compliance Overview](/compliance/) This page maps the [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/), and SBOM properties generally, to their specific field paths in CycloneDX, SPDX 2.3, and SPDX 3.0.

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
**Note:** The CISA Framing document's published crosswalk table references CycloneDX v1.6. This page uses CycloneDX 1.7 schema paths, which are largely compatible but include some updates (e.g., tools object structure). **BSI TR-03183-2 Note:** For EU CRA compliance via BSI TR-03183-2, SBOMs MUST use **CycloneDX 1.6+** or **SPDX 3.0.1+** in JSON or XML format. See the [EU CRA page](/compliance/eu-cra/) for full requirements. --- ## CISA 2026 Minimum Elements: Format Mappings The [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/) define 23 elements, of which 17 are data fields. The tables below map each data field to its representation in SPDX and CycloneDX. **Provenance:** element names and definitions are quoted from the [CISA 2026 Minimum Elements](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom) (29 July 2026). The format mappings come from an OpenSSF working document produced with the SPDX and CycloneDX communities. That mapping work is in progress and should be treated as community guidance rather than a ratified standard — verify against the format specifications before relying on it for conformance. As CISA notes, the correspondence is not one-to-one: "Each Data Fields element need not correlate directly with a particular data field in an SBOM data format, and an implemented data field may satisfy one or more of the minimum elements." ### Component Data | CISA 2026 Element | SPDX 2.3 | SPDX 3.0 | CycloneDX 1.6 | CycloneDX 1.7 | | --------------------------------- | --------------------------------------------- | ------------------------------------------------------- | ------------------------------------------- | ------------- | | Component Producer | `packages[].originator` | `Package.originatedBy` | `manufacturer.name` or `authors[].name` | Same | | Component Name | `packages[].name` | `Package.name` | `components[].name` | Same | | Component Version | `packages[].versionInfo` | `Package.packageVersion` | `components[].version` | Same | | Component Identifiers | `packages[].externalRefs[]` incl. SWID/gitoid | `packageURL`; `externalIdentifier`; `contentIdentifier` | `cpe`, `purl`, `swid`, `omniborId`, `swhid` | Same | | Component Hash Value | `packages[].checksums[].checksumValue` | `Hash.hashValue` | `components[].hashes[].content` | Same | | Component Hash Algorithm | `packages[].checksums[].algorithm` | `Hash.algorithm` | `components[].hashes[].alg` | Same | | Component License | `packages[].licenseDeclared` | `hasDeclaredLicense` | `licenses[]`; `acknowledgement=declared` | Same | | Component Dependency Relationship | `relationships[]` (`DEPENDS_ON`) | `Relationship: dependsOn` | `dependencies[].ref` / `dependsOn[]` | Same | ### SBOM Metadata | CISA 2026 Element | SPDX 2.3 | SPDX 3.0 | CycloneDX 1.6 | CycloneDX 1.7 | | ------------------------ | ------------------------------------ | --------------------------------------- | ------------------------------------------------ | ------------------- | | SBOM Author | `creationInfo.creators[]` Person/Org | `creationInfo.createdBy` → `Agent.name` | `metadata.manufacturer.name` or `authors[].name` | Same | | SBOM Author Signature | External signed envelope | External signed envelope | `signature` (JSF) | `signature` (JSF) | | SBOM Data Format Name | `spdxVersion = "SPDX-2.3"` | `creationInfo.specVersion = "3.0.1"` | `bomFormat` + media type | Same | | SBOM Data Format Version | `spdxVersion` | `creationInfo.specVersion` | `specVersion = 1.6` | `specVersion = 1.7` | | SBOM Generation Context | `creationInfo.comment` | `Software/Sbom.sbomType` | `metadata.lifecycles[].phase` | Same | | SBOM Timestamp | `creationInfo.created` | `creationInfo.created` | `metadata.timestamp` | Same | | SBOM Tool Name | `creationInfo.creators[]` Tool entry | `createdUsing` → `Tool.name` | `metadata.tools.components[].name` | Same | | SBOM Tool Version | Parsed from `creators[]` Tool entry | `Tool` → versioned Package | `metadata.tools.components[].version` | Same | | SBOM Version | `documentNamespace` | `SBOM-SPDXIdentifier` | `version` + `serialNumber` | Same | ### Notes on the mappings **SBOM Author Signature has no native SPDX representation.** In SPDX 2.2 through 3.0 it requires an external signed envelope. SPDX 3.1 (candidate) introduces `Artifact` plus an external signature. CycloneDX has supported JSF signatures since 1.5, and CycloneDX 2.0 (candidate) moves to a list of JSS signature objects. **Component Producer moved in CycloneDX 1.6.** In 1.5 it maps to `components[].author` with a property where needed; from 1.6 onward `manufacturer.name` or `authors[].name` is the better fit. CycloneDX 2.0 (candidate) replaces both with `components[].parties[]`. **Component Producer is not the same as `supplier`.** The older crosswalk below maps NTIA's "Supplier Name" to `components[].supplier.name`. The OpenSSF mapping for CISA 2026's Component Producer uses `manufacturer`/`authors` instead, reflecting that Component Producer means the entity that _originated_ the software rather than the one that supplied it. If you populate only `supplier`, review whether it carries the meaning the 2026 element expects. **Component License in CycloneDX should be explicit about acknowledgement.** The mapping specifies `acknowledgement=declared`, distinguishing a declared licence from a concluded one. --- ## Document-Level Metadata | Property | CycloneDX 1.7 | SPDX 2.3 | SPDX 3.0 | | ------------------ | ---------------------------------------------------------------- | ------------------------------------------- | ---------------------------- | | SBOM Author | `metadata.authors[]` | `creationInfo.creators[]` | `creationInfo.createdBy` | | Timestamp | `metadata.timestamp` | `creationInfo.created` | `creationInfo.created` | | Tool Name/Version | `metadata.tools.components[]` and/or `metadata.tools.services[]` | `creationInfo.creators[]` (tool identifier) | `creationInfo.createdUsing` | | Generation Context | `metadata.lifecycles[].phase` | `CreatorComment` or `DocumentComment` | Profile-dependent properties | **Notes:** - The CISA Framing crosswalk maps "SBOM Author Name" to `metadata.authors` (CycloneDX v1.6). CycloneDX 1.7 additionally provides `metadata.manufacturer` for organizational authorship if needed. - In CycloneDX 1.7, `metadata.tools` is an object containing `components` and/or `services` arrays. The legacy array format is deprecated. - The `metadata.lifecycles[].phase` field captures the stage(s) in which data in the BOM was captured (design, pre-build, build, post-build, operations, discovery, decommission). - **SBOM Generation Context** (per CISA 2026) is "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM." For complete representation, you may also use `metadata.tools` (to express tooling) and `metadata.properties[]` (for additional context). --- ## Component Identification | Property | CycloneDX 1.7 | SPDX 2.3 | SPDX 3.0 | | ------------------ | ---------------------------- | --------------------------- | ------------------------------------ | | Supplier Name | `components[].supplier.name` | `packages[].supplier` | Organization agent linked to element | | Component Name | `components[].name` | `packages[].name` | Element name field | | Component Version | `components[].version` | `packages[].versionInfo` | Element version field | | Package URL (purl) | `components[].purl` | `packages[].externalRefs[]` | External identifier support | | CPE | `components[].cpe` | `packages[].externalRefs[]` | External identifier support | | Component Hash | `components[].hashes[]` | `packages[].checksums[]` | Verification/checksum properties | --- ## Relationships | Property | CycloneDX 1.7 | SPDX 2.3 | SPDX 3.0 | | ----------------------- | --------------------------------------------------- | ------------------------------ | ------------------------------ | | Dependency Relationship | `dependencies[].ref` + `dependencies[].dependsOn[]` | `relationships[]` (DEPENDS_ON) | Relationships between elements | --- ## Legal & Security | Property | CycloneDX 1.7 | SPDX 2.3 | SPDX 3.0 | | -------- | ------------------------- | ------------------------------------------------------------ | ---------------------------------------- | | License | `components[].licenses[]` | `packages[].licenseDeclared` / `packages[].licenseConcluded` | Rich licensing model (profile-dependent) | --- ## Lifecycle Properties (FDA/CLE) | Property | CycloneDX 1.7 | SPDX 2.3 | SPDX 3.0 | | ------------------- | --------------------------- | ------------------------------- | --------------------------- | | Support Level | `components[].properties[]` | `annotations` or `externalRefs` | Extension/property modeling | | End-of-Support Date | `components[].properties[]` | `packages[].validUntilDate` | Extension/property modeling | **Note:** SPDX 2.3's `validUntilDate` field is defined as the "end of support period for the package from the supplier," making it the most appropriate mapping for FDA's end-of-support date requirement. --- ## BSI TR-03183-2 Component Properties BSI TR-03183-2 requires additional component properties not covered by standard SBOM fields. These use the [BSI CycloneDX property taxonomy](https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy) for CycloneDX and `software_additionalPurpose` for SPDX. | Property | CycloneDX 1.6+ | SPDX 3.0.1 | | ----------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Filename | `components[].properties[name="bsi:component:filename"]` | `software_File.name` via `hasDistributionArtifact` relationship | | Executable property | `components[].properties[name="bsi:component:executable"]` | Add `executable` to `software_additionalPurpose` list | | Archive property | `components[].properties[name="bsi:component:archive"]` | Add `archive` to `software_additionalPurpose` list | | Structured property | `components[].properties[name="bsi:component:structured"]` | Add `container` (structured) or `firmware` (unstructured) to `software_additionalPurpose` | | Effective licence | `components[].properties[name="bsi:component:effectiveLicense"]` | Custom relationship with `relationshipType: other` and `comment: hasEffectiveLicense` | | Hash (deployable) | `components[].externalReferences[type="distribution"].hashes[alg="SHA-512"]` | `software_File.verifiedUsing` via `hasDistributionArtifact` relationship | | Dependency completeness | `compositions[].aggregate` (complete/incomplete/unknown) | `Relationship.completeness` (complete/incomplete/noAssertion) | **Notes:** - BSI requires **SHA-512** specifically for the deployable component hash - The BSI property taxonomy uses the `bsi:` namespace prefix for CycloneDX properties - For detailed JSON examples, see [BSI TR-03183-2 Section 8.2](https://bsi.bund.de/dok/TR-03183-en) --- ## Related Pages - [EU CRA Requirements](/compliance/eu-cra/) - CRA SBOM requirements with BSI TR-03183-2 specifications - [CLE: Common Lifecycle Enumeration](/compliance/cle/) - Standard for machine-readable lifecycle events - [CISA Framing Document](/compliance/cisa-framing/) - Authoritative source for baseline attribute definitions - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - US baseline for SBOM data fields --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # Software Security Code of Practice (UK, May 2025) URL: https://sbomify.com/compliance/uk-software-security-code-of-practice/ Description: Guide to the UK Software Security Code of Practice, a voluntary government code for secure software development, supply chain resilience, and customer communication. [← Back to Compliance Overview](/compliance/) **Who it affects:** Organisations that **develop and/or sell software to businesses or other organisations**, including standalone software, software services, and goods/services that contain software (most relevant for B2B proprietary software vendors and SaaS).

Need help with compliance? We can help you navigate your SBOM compliance journey.

Get in Touch
--- ## Overview The **Software Security Code of Practice (May 2025)** is a **voluntary** UK government code designed to help **software vendors and their customers** reduce the likelihood and impact of **software supply chain attacks** and improve software resilience. It sets out **14 principles** vendors are expected to implement as a consistent baseline across the market. Unlike binding legislation such as the EU Cyber Resilience Act, this Code of Practice is voluntary guidance intended to establish industry norms and baseline expectations for software security in the UK market. --- ## What It Requires (SBOM-Relevant) The Code does **not** mandate SBOMs by name or define SBOM field-level requirements, but it establishes SBOM-adjacent expectations: | Requirement Area | Description | Status | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------- | | Software composition awareness | Vendors should understand composition and assess risks linked to ingestion and maintenance of third-party components | Expected | | Vulnerability disclosure | Vendors should implement and publish a vulnerability disclosure process | Expected | | Vulnerability management | Vendors should have processes/documentation for detecting, prioritising, and managing vulnerabilities in software components | Expected | | Customer lifecycle communication | Vendors should provide customers with support/maintenance level information | Expected | | End-of-support notice | Vendors should provide at least **1 year's notice** before the software is no longer supported/maintained | Expected | --- ## Key Principles The Code establishes 14 principles across several areas: ### Secure Development - Implement secure development practices throughout the software lifecycle - Maintain awareness of software composition and third-party component risks ### Vulnerability Management - Establish and publish a vulnerability disclosure process - Implement processes for detecting, prioritising, and remediating vulnerabilities - Provide timely security updates to customers ### Customer Communication - Communicate support and maintenance levels clearly to customers - Provide at least 1 year's notice before end of support/maintenance ### Supply Chain Resilience - Assess and manage risks from third-party components - Maintain documentation of software composition --- ## Relationship to SBOMs While the Code does not explicitly require SBOMs, maintaining a Software Bill of Materials is a practical way to meet several of its expectations: - **Composition awareness:** An SBOM provides the foundation for understanding what third-party components are in your software - **Vulnerability management:** SBOMs enable efficient vulnerability tracking across your component inventory - **Supply chain transparency:** SBOMs document the provenance and relationships of software components Organisations already generating SBOMs for other compliance requirements (e.g., [EU CRA](/compliance/eu-cra/), [NTIA minimum elements](/compliance/ntia-minimum-elements/)) will find they are well-positioned to meet the Code's expectations. --- ## Related Frameworks - [EU Cyber Resilience Act (CRA)](/compliance/eu-cra/) - Binding EU law with SBOM requirements - [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) - US baseline for SBOM data fields - [CISA SBOM Sharing Lifecycle Report](/compliance/cisa-sharing-lifecycle/) - Operational guidance for SBOM distribution --- ## Official Source - [Software Security Code of Practice (UK Government)](https://www.gov.uk/government/publications/software-security-code-of-practice) --- **Disclaimer:** This page represents our interpretation of the referenced frameworks and standards. While we strive for accuracy, we may have made errors or omissions. This content is provided for informational purposes only and does not constitute legal advice. For compliance decisions, consult the official source documents and seek qualified legal counsel. [← Back to Compliance Overview](/compliance/) --- # SBOM Guides URL: https://sbomify.com/guides/ Description: Comprehensive guides for generating Software Bill of Materials across all major programming languages and platforms. Step-by-step guides for generating SBOMs across all major programming languages and platforms. New to SBOMs? Start with [What is an SBOM?](/what-is-sbom/) to learn the basics. For a complete list of SBOM tools, see our [SBOM Resources](/resources/) page. ## Language Guides - [Python](/guides/python/) - pip, Poetry, Pipenv, uv - [JavaScript](/guides/javascript/) - npm, yarn, pnpm, Bun - [Java](/guides/java/) - Maven, Gradle - [Go (Golang)](/guides/go/) - Go Modules - [Rust](/guides/rust/) - Cargo - [Ruby](/guides/ruby/) - Bundler - [PHP](/guides/php/) - Composer - [.NET/C#](/guides/dotnet/) - NuGet - [Swift](/guides/swift/) - Swift Package Manager - [Dart/Flutter](/guides/dart/) - pub - [Elixir](/guides/elixir/) - Mix - [Scala](/guides/scala/) - sbt - [C/C++](/guides/cpp/) - Conan ## Platform Guides - [Docker/Containers](/guides/docker/) - [Terraform](/guides/terraform/) - [Yocto](/guides/yocto/) - Embedded Linux - [Raspberry Pi](/guides/raspberry-pi/) - rpi-image-gen - [CI/CD Integration](/guides/ci-cd/) - Why SBOMs belong in your build pipeline ## The sbomify Action The [sbomify action](/sbomify-action/) generates an SBOM from any of the lock files above, enriches it, and publishes it - in one step, on any CI platform. - [Full documentation](/sbomify-action/) - complete reference for generating SBOMs in any pipeline - [Quick start](/sbomify-action/quickstart/) - Setup wizard and your first run - [Why SBOM quality matters](/sbomify-action/why/) - scanners versus pipelines, and signing at origin - [Configuration reference](/sbomify-action/configuration/) - Every option - [Runtimes](/sbomify-action/runtimes/) - GitHub Actions, GitLab CI, Bitbucket, Jenkins, CircleCI, Travis CI, Azure DevOps, TeamCity and more ## General Guides - [How to Version SBOMs](/guides/how-to-version-sboms/) ## Additional Resources Looking for more tools and resources? Check out our [SBOM Resources](/resources/) page for: - SBOM generation tools (generic and language-specific) - Assembly and enrichment tools - Distribution and transportation solutions - Analysis and vulnerability scanning tools - Official SBOM documentation from CISA and NTIA --- # How to Version SBOMs - SemVer, CalVer, and Rolling Releases URL: https://sbomify.com/guides/how-to-version-sboms/ Description: Learn best practices for versioning Software Bill of Materials. Guide covers Semantic Versioning, Calendar Versioning, rolling releases, and linking SBOMs to your release process. ## Introduction Depending on the type of software you are producing, versioning may or may not be straightforward. The most widely known scheme is [Semantic Versioning](https://semver.org/) (SemVer), which encodes API compatibility into the version number (`MAJOR.MINOR.PATCH`). It works well for libraries and tools where consumers care about breaking changes. It is not the only established scheme, though. [Calendar Versioning](https://calver.org/) (CalVer) derives version numbers from the release date instead, and is used by projects like Ubuntu (`24.04`) and pip. CalVer is a great fit when releases follow a time-based cadence rather than an API-compatibility contract, and it is what we use for sbomify itself. Either scheme gives you what matters for SBOMs: unique, ordered, human-readable version identifiers. Neither model works as effectively for software delivered as a service, or anything with rolling releases. Many tech companies deploy new versions to production numerous times per day, and in this case, maintaining any hand-assigned version number creates a lot of friction. Since SBOMs are directly related to software releases, the way you version and/or deploy your software will determine how you version your SBOM. Both CycloneDX and SPDX recognize that the way you version your software is highly customized, and neither enforces any specific versioning scheme. Instead, they treat version identifiers as a text string. For clarity, when we discuss versioning, we are referring to the version of the top-level component (i.e., your software), not the document-level `version` field found in CycloneDX. If that distinction is new to you, read the next section carefully, as this is one of the most common mistakes people make with SBOMs. ## A Common Pitfall: The Top-Level `version` Field If you are new to SBOMs and open up a CycloneDX document, the first `version` field you will see sits at the very top of the file, right next to `serialNumber`. It is tempting to put your software version there. Don't. That field versions the SBOM document itself, not the software it describes. In CycloneDX, your software version belongs in [`metadata.component.version`](https://cyclonedx.org/docs/1.6/json/#metadata_component), the top-level component that represents your application. The document-level [`version`](https://cyclonedx.org/docs/1.6/json/#version) field exists for one narrow purpose: amending an SBOM you have already published. If you need to correct a published SBOM (say you discover a missing component or a licensing error), you keep the same [`serialNumber`](https://cyclonedx.org/docs/1.6/json/#serialNumber) and increment the document `version` (1, 2, 3, and so on). The unchanged `serialNumber` tells consumers that both documents describe the same release, and the higher `version` tells them which one supersedes the other. Amending should be an edge case. In the normal flow, every release of your software gets a brand-new SBOM: a freshly generated `serialNumber`, a document `version` of `1`, and your actual software version in `metadata.component.version`. That component version is what you (and anyone consuming your SBOMs) should be tracking from release to release. If your document `version` says anything other than `1` and you have not deliberately amended a published SBOM, something in your pipeline is misusing the field. SPDX works the same way in spirit. Your software version goes in the [`versionInfo`](https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field) field of the package your document describes, and each new document gets a unique [document namespace](https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#65-spdx-document-namespace-field). SPDX has no built-in revision counter like CycloneDX. Instead, a correction is a new document that declares an [`AMENDS` relationship](https://spdx.github.io/spdx-spec/v2.3/relationships-between-SPDX-elements/) pointing back to the document it amends. Again, this is only for fixing an SBOM you have already published, not for shipping a new version of your software. ## Best Practices One of the most authoritative documents on versioning SBOMs is CISA's [Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)](https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf). The document states the following about versioning: _"The Version is a supplier-defined identifier that specifies an update change in the software from a previously identified version. This Attribute helps to further identify a Component and should be separate from the Component Name. As there is a wide range of versioning schemes in use, recording what is provided from the Supplier accurately is the primary goal. Semantic versioning is preferred._ _If the Component does not have a unique semantic version available to declare, make sure that a cryptographic hash is provided for the Component. Be aware that this will not indicate the relative release of the Component to its predecessors and successors. As a minimum expectation, declare the version string as provided by the Supplier."_ While CISA states a preference for Semantic Versioning, note that their primary goal is "recording what is provided from the Supplier accurately." A CalVer version satisfies this just as well as a SemVer one: both are unique, ordered version strings that identify a specific release. What matters is that you use a well-defined scheme consistently, whichever one fits your release process. If you are creating your SBOMs in GitHub, you are likely using [git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) to manage releases, and this works identically whether your tags are SemVer (`v2.1.3`) or CalVer (`2026.07.1`). You can leverage these for SBOM versioning automatically. For instance, if you are using our [GitHub Actions Module](https://github.com/sbomify/sbomify-action), you can set `COMPONENT_VERSION` to `${{ github.ref_name }}`, which will then automatically populate the corresponding version you created. However, if you are not using a versioning scheme at all, the document advises using a "cryptographic hash." Assuming your source code lives in a `git` repository, you can automatically derive a hash from there. If you are not using GitHub, you can use `git rev-parse HEAD` to get this. If you are using GitHub Actions (perhaps together with our GitHub Actions Module), you can then use `${{ github.sha }}` as a shorthand for this. ## When to Release SBOMs The timing largely depends on when you are releasing your software. For instance, if you are using git tags for releases, this is likely when you want to trigger SBOM generation. If you are using rolling releases, you may want to limit SBOM generation to production deployments. How you do this will vary greatly depending on your internal organization. In some cases, production corresponds to a specific git branch, while in other organizations, you "promote" what is in your staging environment to production. Regardless of whether this is a merge from one branch to another or a build/release promotion, this is the point at which you want to generate the SBOM. ## Conclusion If you're building SBOMs, please consider leveraging a well-defined versioning scheme, whether that is Semantic Versioning or Calendar Versioning, together with git tags. This approach will help ensure that your SBOM is accurate and reproducible. --- # SBOM Generation Guide for .NET - NuGet URL: https://sbomify.com/guides/dotnet/ Description: Learn how to generate Software Bill of Materials for .NET and C# projects. Complete guide with packages.lock.json, PackageReference, and Microsoft SBOM Tool examples. ## Source vs Build SBOMs The .NET ecosystem has evolved significantly in its dependency management. Understanding the landscape is crucial for accurate SBOM generation: - **Legacy:** `packages.config` (NuGet 2.x style) - **Modern:** `PackageReference` in `.csproj` files - **Recommended:** `packages.lock.json` for reproducible builds For the most accurate SBOMs, generate from `packages.lock.json` which contains resolved transitive dependencies with exact versions. ## Lockfile Deep Dive ### Generating packages.lock.json .NET doesn't create a lockfile by default. Enable it in your `.csproj`: ```xml true true ``` Or via CLI: ```bash dotnet restore --use-lock-file ``` ### packages.lock.json Structure The lockfile contains detailed dependency information: ```json { "version": 2, "dependencies": { "net8.0": { "Microsoft.Extensions.Logging": { "type": "Direct", "requested": "[8.0.0, )", "resolved": "8.0.0", "contentHash": "h1:abc123...", "dependencies": { "Microsoft.Extensions.DependencyInjection.Abstractions": "8.0.0", "Microsoft.Extensions.Logging.Abstractions": "8.0.0" } }, "Newtonsoft.Json": { "type": "Transitive", "resolved": "13.0.3", "contentHash": "def456..." } } } } ``` Key fields: - **type**: Direct or Transitive dependency - **requested**: Version range from your `.csproj` - **resolved**: Actual resolved version - **contentHash**: Package integrity hash - **dependencies**: Transitive dependencies ### PackageReference in .csproj Without a lockfile, dependencies are declared in `.csproj`: ```xml ``` **Warning:** Version ranges (like `13.0.*` or `[3.0.0,4.0.0)`) make reproducible SBOMs impossible without a lockfile. ## .NET Framework vs .NET Core vs .NET 5+ Different .NET versions handle dependencies differently: | Version | Package Format | Recommended SBOM Source | | -------------- | ----------------------------------- | ----------------------- | | .NET Framework | packages.config or PackageReference | packages.lock.json | | .NET Core | PackageReference | packages.lock.json | | .NET 5+ | PackageReference | packages.lock.json | ## Multi-Targeting .NET projects can target multiple frameworks: ```xml net6.0;net8.0;netstandard2.1 ``` Your `packages.lock.json` will contain separate dependency trees for each target: ```json { "dependencies": { "net6.0": { /* dependencies */ }, "net8.0": { /* dependencies */ }, "netstandard2.1": { /* dependencies */ } } } ``` Consider generating separate SBOMs for each target framework if they differ significantly. ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For .NET, sbomify uses **cdxgen** under the hood with fallback to Syft. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: packages.lock.json OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-dotnet-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: packages.lock.json OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **Microsoft SBOM Tool (official):** ```bash dotnet tool install --global Microsoft.Sbom.DotNetTool sbom-tool generate -b ./bin/Release -bc . -pn MyApp -pv 1.0.0 -ps MyCompany ``` **CycloneDX .NET Tool:** ```bash dotnet tool install --global CycloneDX dotnet CycloneDX MySolution.sln -o sbom.cdx.json -j ``` **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t dotnet -o sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: packages.lock.json OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Azure DevOps Integration For Azure Pipelines: ```yaml trigger: - main pool: vmImage: 'ubuntu-latest' steps: - task: UseDotNet@2 inputs: version: '8.0.x' - script: dotnet restore --use-lock-file displayName: 'Restore dependencies' - script: | dotnet tool install --global CycloneDX dotnet CycloneDX *.sln -o sbom.cdx.json -j displayName: 'Generate SBOM' - publish: sbom.cdx.json artifact: sbom ``` ## Handling NuGet Sources For projects using private NuGet feeds: ```xml ``` Ensure your CI environment has access to all NuGet sources for accurate SBOM generation. ## Best Practices 1. **Always use lockfiles** - Enable `RestorePackagesWithLockFile` for reproducible builds 2. **Pin exact versions** - Avoid floating versions in production 3. **Use locked mode in CI** - Set `RestoreLockedMode` to `true` in CI builds 4. **Separate runtime and dev dependencies** - Consider excluding test packages from SBOMs 5. **Include framework dependencies** - Don't forget the .NET runtime itself 6. **Document private packages** - Ensure metadata is available for internal NuGet packages ## Common Issues ### Missing Transitive Dependencies If your SBOM is missing transitive dependencies: 1. Ensure you're using `packages.lock.json` 2. Run `dotnet restore --force-evaluate` to regenerate the lockfile ### Framework-Specific Dependencies Different target frameworks may have different dependencies. Choose the target framework most relevant to your deployment: ```bash # Generate for specific framework dotnet CycloneDX MyProject.csproj -o sbom.cdx.json -j -f net8.0 ``` ### Self-Contained Deployments For self-contained deployments that include the .NET runtime: ```bash dotnet publish -c Release -r linux-x64 --self-contained true ``` Consider generating an SBOM that includes runtime components using Microsoft SBOM Tool on the published output. ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional .NET-specific tools like CycloneDX .NET library and Microsoft SBOM Tool. --- # SBOM Generation Guide for C/C++ - Conan URL: https://sbomify.com/guides/cpp/ Description: Learn how to generate Software Bill of Materials for C/C++ projects. Complete guide with conan.lock examples, vcpkg, and handling vendored dependencies. ## The C/C++ Dependency Challenge Unlike most modern language ecosystems, C/C++ doesn't have a single standard package manager. This creates unique challenges for SBOM generation: - **Multiple package managers**: Conan, vcpkg, Hunter, CPM, and others - **System libraries**: Dependencies installed via apt, yum, brew - **Vendored code**: Source files copied directly into projects - **Header-only libraries**: No binary artifacts to track - **Manual dependency management**: Many projects still manage dependencies manually This guide focuses on Conan as the most SBOM-friendly option, with guidance for other scenarios. ## Using Conan for SBOMs [Conan](https://conan.io/) is the most mature C/C++ package manager for SBOM generation because it provides: - A lockfile format (`conan.lock`) - Version pinning and reproducible builds - Package metadata from ConanCenter ### conan.lock Structure Generate a lockfile: ```bash conan lock create . ``` The `conan.lock` file contains dependency information: ```json { "version": "0.5", "requires": [ "openssl/3.2.0#abc123", "zlib/1.3.1#def456", "boost/1.84.0#ghi789" ], "build_requires": [], "python_requires": [] } ``` For Conan 2.x: ```json { "version": "0.5", "requires": { "openssl/3.2.0": { "ref": "openssl/3.2.0#abc123...", "package_id": "xyz...", "requires": ["zlib/1.3.1"] } } } ``` ### conanfile.txt Basic dependency declaration: ```ini [requires] boost/1.84.0 openssl/3.2.0 zlib/1.3.1 [generators] CMakeDeps CMakeToolchain ``` ### conanfile.py More advanced dependency management: ```python from conan import ConanFile class MyAppConan(ConanFile): name = "myapp" version = "1.0.0" requires = [ "boost/1.84.0", "openssl/3.2.0", "zlib/1.3.1" ] def requirements(self): if self.settings.os == "Windows": self.requires("winsock/2.0") ``` ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For C/C++ with Conan, sbomify uses **cdxgen** under the hood with fallback to Syft. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: conan.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-cpp-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: conan.lock OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t cpp -o sbom.cdx.json ``` **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` **Conan graph export:** ```bash conan graph info . --format=json > deps.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action before_script: - pip install conan - conan lock create . variables: LOCK_FILE: conan.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Alternative: vcpkg [vcpkg](https://vcpkg.io/) is Microsoft's C/C++ package manager: ```json // vcpkg.json (manifest mode) { "name": "myapp", "version": "1.0.0", "dependencies": [ "boost-asio", "openssl", "zlib" ] } ``` vcpkg doesn't have native lockfile support, but you can use versioning: ```json { "name": "myapp", "version": "1.0.0", "builtin-baseline": "abc123def456...", "dependencies": [ { "name": "boost", "version>=": "1.84.0" } ] } ``` For SBOM generation, export the installed packages: ```bash vcpkg list --x-json > vcpkg-installed.json ``` ## Handling System Libraries System libraries installed via package managers aren't captured by C++ package managers: ```cmake # CMakeLists.txt find_package(OpenSSL REQUIRED) find_package(ZLIB REQUIRED) ``` Document these using `ADDITIONAL_PACKAGES`: ```yaml env: LOCK_FILE: 'conan.lock' ADDITIONAL_PACKAGES: "libssl-dev:3.0.2,zlib1g-dev:1.2.13" ``` Or create a manifest file for system dependencies: ```yaml # system-deps.yml - name: openssl version: "3.0.2" type: system package-manager: apt - name: zlib version: "1.2.13" type: system package-manager: apt ``` ## Vendored Dependencies Many C/C++ projects vendor (copy) dependencies directly: ``` myproject/ ├── src/ ├── vendor/ │ ├── json/ # nlohmann/json │ ├── spdlog/ # gabime/spdlog │ └── catch2/ # catchorg/Catch2 └── CMakeLists.txt ``` For vendored code, you must manually document dependencies: ```yaml env: ADDITIONAL_PACKAGES: "nlohmann-json:3.11.3,spdlog:1.12.0,catch2:3.5.0" ``` Or maintain a manifest: ```json // vendored-deps.json { "dependencies": [ { "name": "nlohmann-json", "version": "3.11.3", "source": "https://github.com/nlohmann/json", "commit": "abc123" }, { "name": "spdlog", "version": "1.12.0", "source": "https://github.com/gabime/spdlog" } ] } ``` ## CMake FetchContent For projects using CMake's FetchContent: ```cmake include(FetchContent) FetchContent_Declare( json GIT_REPOSITORY https://github.com/nlohmann/json GIT_TAG v3.11.3 ) FetchContent_Declare( spdlog GIT_REPOSITORY https://github.com/gabime/spdlog GIT_TAG v1.12.0 ) FetchContent_MakeAvailable(json spdlog) ``` These dependencies aren't automatically captured. Extract them from CMakeLists.txt or use a wrapper script to generate metadata. ## Best Practices 1. **Use Conan when possible** - It provides the best SBOM support 2. **Generate lockfiles** - Always use `conan lock create` for reproducibility 3. **Document system libraries** - Use ADDITIONAL_PACKAGES for apt/yum dependencies 4. **Track vendored code** - Maintain a manifest for copied source files 5. **Consider container SBOMs** - For complete visibility, generate SBOMs from your Docker image 6. **Automate in CI** - Generate SBOMs alongside your build ## Complete Example For a comprehensive C++ SBOM covering all dependency types: ```yaml --- name: Complete C++ SBOM on: [push] jobs: sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install system dependencies run: | sudo apt-get update sudo apt-get install -y libssl-dev zlib1g-dev - name: Set up Conan run: | pip install conan conan lock create . - name: Generate SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'conan.lock' OUTPUT_FILE: 'sbom.cdx.json' ADDITIONAL_PACKAGES: "libssl-dev:3.0.2,zlib1g-dev:1.2.13,nlohmann-json:3.11.3" ENRICH: true ``` ## Further Reading For more details on C/C++ SBOM generation, see these blog posts by [Chris Swan](/authors/cswan/): - [The C conundrum - generating SBOMs when there's no lockfile](/2024/11/18/c-conundrum/) - Explores the challenges of generating SBOMs for C/C++ projects, reviewing cmake-sbom, Conan, cve-bin-tool, and CISA working group efforts - [Using Conan for C SBOMs](/2025/09/04/conan/) - How to use the Conan package manager to generate SBOMs for C and C++ projects ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes general SBOM utilities for generation, distribution, and analysis. --- # SBOM Generation Guide for Dart and Flutter - pub URL: https://sbomify.com/guides/dart/ Description: Learn how to generate Software Bill of Materials for Dart and Flutter projects. Complete guide with pubspec.lock examples and CycloneDX output. ## Source vs Build SBOMs Dart's package manager (pub) provides excellent lockfile support through `pubspec.lock`. This makes source SBOM generation reliable for both Dart and Flutter projects. - **Source SBOMs** are generated from `pubspec.lock` - **Build SBOMs** can be generated from the `.dart_tool/package_config.json` For most Dart/Flutter projects, generating from `pubspec.lock` is preferred because it contains exact resolved versions and content hashes. ## Lockfile Deep Dive ### pubspec.yaml (Manifest) The `pubspec.yaml` file declares your dependencies: ```yaml name: my_app description: A sample Dart/Flutter application version: 1.0.0 environment: sdk: '>=3.0.0 <4.0.0' flutter: '>=3.16.0' dependencies: flutter: sdk: flutter http: ^1.2.0 provider: ^6.1.0 shared_preferences: ^2.2.0 dev_dependencies: flutter_test: sdk: flutter flutter_lints: ^3.0.0 build_runner: ^2.4.0 ``` ### pubspec.lock The `pubspec.lock` file contains resolved dependencies: ```yaml # Generated by pub # See https://dart.dev/tools/pub/glossary#lockfile packages: http: dependency: "direct main" description: name: http sha256: "761a297c042deedc1ffbb156d6e2f13c3eb84c6cf7cb8dc2d5f2d5b0b8cb9c7b" url: "https://pub.dev" source: hosted version: "1.2.0" http_parser: dependency: transitive description: name: http_parser sha256: "2aa08ce0341cc9b354a498388e30986515406668dbcc4f7c950c3e715496693b" url: "https://pub.dev" source: hosted version: "4.0.2" provider: dependency: "direct main" description: name: provider sha256: "7e4a68b2a6e459ff1a3ce8a35c79cd2ad9b96742e5a81c8a83e1d7e3e9c27f22" url: "https://pub.dev" source: hosted version: "6.1.1" sdks: dart: ">=3.0.0 <4.0.0" flutter: ">=3.16.0" ``` Key information: - **dependency**: "direct main", "direct dev", or "transitive" - **sha256**: Content hash for integrity verification - **source**: "hosted" (pub.dev), "git", or "path" - **version**: Exact resolved version ## Flutter-Specific Dependencies Flutter projects have additional dependency types: ### Flutter SDK Dependencies ```yaml dependencies: flutter: sdk: flutter flutter_localizations: sdk: flutter ``` These are part of the Flutter SDK and typically not included in SBOMs as they're versioned with Flutter itself. ### Platform-Specific Dependencies Flutter plugins may have native dependencies: ```yaml dependencies: url_launcher: ^6.2.0 # Has iOS/Android native code sqflite: ^2.3.0 # SQLite bindings ``` The native code dependencies aren't captured in `pubspec.lock`. Consider documenting them separately. ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Dart/Flutter, sbomify uses **cdxgen** or **Syft** under the hood. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: pubspec.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-flutter-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: pubspec.lock OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen (recommended for manual use):** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t dart -o sbom.cdx.json ``` **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` **sbom (Dart-native, SPDX only):** ```bash dart pub add --dev sbom ``` Note: The `sbom` Dart package currently only supports SPDX format, not CycloneDX. Use cdxgen or Syft for CycloneDX output. When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: pubspec.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Handling Special Cases ### Git Dependencies Packages from Git repositories: ```yaml dependencies: my_package: git: url: https://github.com/example/my_package.git ref: v1.0.0 ``` In `pubspec.lock`: ```yaml my_package: dependency: "direct main" description: path: "." ref: v1.0.0 resolved-ref: "abc123def456..." url: "https://github.com/example/my_package.git" source: git version: "1.0.0" ``` ### Path Dependencies Local packages: ```yaml dependencies: my_local_package: path: ../my_local_package ``` These won't have pub.dev metadata. Document them with `ADDITIONAL_PACKAGES` if needed. ### Hosted Dependencies (Private) For private package servers: ```yaml dependencies: my_private_package: hosted: name: my_private_package url: https://packages.example.com version: ^1.0.0 ``` Ensure your CI has authentication configured: ```bash # Set up authentication dart pub token add https://packages.example.com ``` ## Monorepo Support (Melos) For Dart/Flutter monorepos using [Melos](https://melos.invertase.dev/): ```yaml # melos.yaml name: my_workspace packages: - packages/* - apps/* ``` Generate SBOMs per package or use Melos to run across all: ```bash melos exec -- "cdxgen -t dart -o sbom.cdx.json" ``` ## pub.dev Metadata Enrichment pub.dev provides rich metadata for packages: - License information - Repository URLs - Author information - Documentation links When using `ENRICH: true`, this metadata is added to your SBOM automatically. ## Best Practices 1. **Always commit pubspec.lock** - Essential for reproducible builds 2. **Use caret syntax carefully** - `^1.0.0` allows minor/patch updates 3. **Pin versions for production** - Consider exact versions for releases 4. **Separate dev dependencies** - Keep test/build tools in `dev_dependencies` 5. **Document native dependencies** - Flutter plugins have native code not in pubspec 6. **Run `dart pub outdated`** - Check for updates regularly ## Security Considerations ```bash # Check for vulnerable packages dart pub deps --json | jq '.packages[].name' # Export for scanning # Use Flutter's built-in checks flutter pub outdated ``` Combine dependency checks with SBOM generation in CI: ```yaml - name: Check dependencies run: dart pub outdated --json > outdated.json - name: Generate SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'pubspec.lock' OUTPUT_FILE: 'sbom.cdx.json' ENRICH: true ``` ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes general SBOM utilities for generation, distribution, and analysis. --- # SBOM Generation Guide for Docker and Containers URL: https://sbomify.com/guides/docker/ Description: Generate a Software Bill of Materials for Docker images and containers: what image scanning does and does not capture, multi-stage builds, distroless images, signing, and combining container and application SBOMs. ## Source vs Build SBOMs Container SBOMs are fundamentally different from source code SBOMs. A container image includes: - **Base image packages** - OS-level packages from Debian, Alpine, etc. - **Application dependencies** - Your app's runtime dependencies - **Build artifacts** - Compiled binaries, static files - **System libraries** - Shared libraries your application links against This means container SBOMs are primarily **build SBOMs** - they represent what's actually in the image, not what was declared in source files. ## Understanding Container Layers Docker images consist of layers, each representing filesystem changes: ```dockerfile FROM python:3.12-slim # Layer 1: Base image (many packages) WORKDIR /app # Layer 2: Metadata change COPY requirements.txt . # Layer 3: Add file RUN pip install -r requirements.txt # Layer 4: Install packages COPY . . # Layer 5: Add application CMD ["python", "app.py"] # Layer 6: Metadata ``` SBOM tools analyze all layers to build a complete picture of the image contents. ## Base Image Selection Your base image significantly impacts your SBOM: | Base Image | Typical Package Count | Use Case | | ------------------------ | --------------------- | ----------------------- | | `ubuntu:24.04` | ~100+ packages | General purpose | | `debian:bookworm-slim` | ~80+ packages | Smaller general purpose | | `alpine:3.19` | ~15 packages | Minimal Linux | | `gcr.io/distroless/base` | ~2 packages | Ultra-minimal | | `scratch` | 0 packages | Static binaries only | ### Distroless Images Google's distroless images contain only your application and its runtime dependencies: ```dockerfile # Build stage FROM golang:1.21 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED=0 go build -o /app/server # Runtime stage FROM gcr.io/distroless/static-debian12 COPY --from=builder /app/server / CMD ["/server"] ``` Distroless SBOMs are much simpler but still include: - Base distroless packages (glibc, etc.) - Your application binary - Any files you COPY into the image ## Multi-Stage Builds Multi-stage builds separate build-time dependencies from runtime: ```dockerfile # Stage 1: Build (not in final image) FROM node:20 AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # Stage 2: Runtime (this is what gets scanned) FROM node:20-slim WORKDIR /app COPY --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules CMD ["node", "dist/index.js"] ``` **Important:** SBOMs should be generated from the **final stage only**, not intermediate build stages. ## What Image Scanning Does and Does Not Capture Before generating an SBOM from a container image, it is worth being clear about what that process can and cannot see. Scanning the image is convenient, but it is not equivalent to knowing what is in your software. A container image typically arrives at its final state in two phases: system packages and runtime dependencies get installed, and then your application code is copied in. Capturing the first phase is reliable. Tools read the system package database and, for mainstream base images, produce an accurate list. The second phase is where it breaks down. **If you copy a compiled binary into the image, essentially no SBOM generation tool will capture it**, because the tools work from the package database rather than from the filesystem contents. A package database that is incomplete, or has been tampered with, produces an SBOM that looks complete and is not. Multi-stage builds make this harder still, since the artifacts that land in the final stage were produced somewhere the scanner never sees. Tools such as Syft are good at picking up installed packages across programming language ecosystems, but quality varies by language. **The practical consequence: separate the container SBOM from the application SBOM.** Generate the application SBOM from your lockfile, where the dependency graph is authoritative, and the container SBOM from the image, where the system packages are. See [Combining Application and Container SBOMs](#combining-application-and-container-sboms) below for how to run both. ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For container images, sbomify uses **Syft** under the hood with fallback to cdxgen. Use `DOCKER_IMAGE` instead of `LOCK_FILE`. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: DOCKER_IMAGE: ghcr.io/myorg/myapp:${{ github.sha }} OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: myapp COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` The `DOCKER_IMAGE` references the image built in a previous step (typically tagged with the commit SHA), while `COMPONENT_VERSION` uses the git tag for semantic versioning. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id DOCKER_IMAGE: myapp:latest OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` For images in registries: ```yaml DOCKER_IMAGE: ghcr.io/myorg/myapp:latest ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **Syft:** ```bash syft myapp:latest -o cyclonedx-json=sbom.cdx.json ``` **cdxgen:** ```bash cdxgen -t docker myapp:latest -o sbom.cdx.json ``` **Docker Scout:** ```bash docker scout sbom myapp:latest --format cyclonedx > sbom.cdx.json ``` **Docker Desktop:** ```bash docker sbom --format spdx-json nginx:stable > docker.spdx.json ``` Docker uses Syft behind the scenes, with some additions of its own, but is more restrictive about output formats. See [How to create an SBOM](/2024/04/07/how-to-create-an-sbom/) for more on that. When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action services: - docker:dind before_script: - docker build -t myapp:latest . variables: DOCKER_IMAGE: myapp:latest OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Signing and Attestation ### Using Sigstore/Cosign Sign your container images and attach SBOMs as attestations: ```bash # Sign the image cosign sign --key cosign.key myapp:latest # Attach SBOM as attestation cosign attest --key cosign.key --predicate sbom.cdx.json --type cyclonedx myapp:latest # Verify attestation cosign verify-attestation --key cosign.pub myapp:latest ``` ### GitHub Container Registry Attestations GitHub Actions can automatically generate and attach attestations: ```yaml - name: Build and push with attestations uses: docker/build-push-action@v5 with: context: . push: true tags: ghcr.io/myorg/myapp:latest sbom: true provenance: true ``` ## Combining Application and Container SBOMs For complete visibility, combine your application SBOM with the container SBOM: 1. **Application SBOM** - From your lockfile (package-lock.json, go.mod, etc.) 2. **Container SBOM** - From the built image ```yaml jobs: sbom: steps: - name: Generate Application SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'package-lock.json' OUTPUT_FILE: 'app-sbom.cdx.json' - name: Build and push image run: docker build -t myapp:latest --push . - name: Generate Container SBOM uses: sbomify/sbomify-action@master env: DOCKER_IMAGE: 'myapp:latest' OUTPUT_FILE: 'container-sbom.cdx.json' ``` ## Best Practices 1. **Use minimal base images** - Smaller images mean smaller attack surface and simpler SBOMs 2. **Multi-stage builds** - Keep build tools out of production images 3. **Pin base image digests** - Use `FROM nginx@sha256:...` for reproducibility 4. **Generate SBOMs in CI** - Automate SBOM generation on every build 5. **Attach as attestations** - Store SBOMs with the image in your registry 6. **Sign everything** - Use Cosign or Notary for image and attestation signing 7. **Scan before shipping** - Use SBOM-based vulnerability scanning in your pipeline ## Common Issues ### Missing Application Dependencies If your container SBOM is missing application-level dependencies, the scanner may not recognize your package manager files. Ensure: - Lockfiles are present in the final image - Or generate a separate application SBOM before containerizing ### Large SBOMs from Base Images If your SBOM is too large, consider: - Using slimmer base images - Using distroless images - Filtering the SBOM to focus on your application dependencies ### Layer Caching Issues When using BuildKit caching, ensure SBOM generation sees the final image state: ```dockerfile # syntax=docker/dockerfile:1 FROM python:3.12-slim # ... rest of Dockerfile ``` ## Further Reading Related blog posts: - [GitHub Action module with Attestation](/2024/10/31/github-action-update-and-attestation/) - SLSA build provenance attestation for Docker images ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional container-specific tools like bom from the Linux Foundation and Tern. --- # SBOM Generation Guide for Elixir - Mix URL: https://sbomify.com/guides/elixir/ Description: Learn how to generate Software Bill of Materials for Elixir projects. Complete guide with mix.lock examples, Hex packages, and umbrella applications. ## Source vs Build SBOMs Elixir's Mix build tool provides excellent dependency management through `mix.lock`. This makes source SBOM generation reliable. - **Source SBOMs** are generated from `mix.lock` - **Build SBOMs** can analyze compiled dependencies in `deps/` and `_build/` For most Elixir projects, generating from `mix.lock` is preferred because it contains exact versions and content hashes from Hex.pm. ## Lockfile Deep Dive ### mix.exs (Manifest) The `mix.exs` file declares your dependencies: ```elixir defmodule MyApp.MixProject do use Mix.Project def project do [ app: :my_app, version: "1.0.0", elixir: "~> 1.16", deps: deps() ] end defp deps do [ {:phoenix, "~> 1.7"}, {:phoenix_ecto, "~> 4.4"}, {:ecto_sql, "~> 3.10"}, {:postgrex, ">= 0.0.0"}, {:jason, "~> 1.2"}, {:plug_cowboy, "~> 2.5"}, # Dev/test dependencies {:phoenix_live_reload, "~> 1.2", only: :dev}, {:credo, "~> 1.7", only: [:dev, :test], runtime: false}, {:dialyxir, "~> 1.4", only: [:dev, :test], runtime: false} ] end end ``` ### mix.lock The `mix.lock` file contains resolved dependencies: ```elixir %{ "castore": {:hex, :castore, "1.0.4", "sha256hash...", [:mix], [], "hexpm", "checksum..."}, "cowboy": {:hex, :cowboy, "2.10.0", "sha256hash...", [:make, :rebar3], [ {:cowlib, "2.12.1", [hex: :cowlib, repo: "hexpm", optional: false]}, {:ranch, "1.8.0", [hex: :ranch, repo: "hexpm", optional: false]} ], "hexpm", "checksum..."}, "ecto": {:hex, :ecto, "3.11.1", "sha256hash...", [:mix], [ {:decimal, "~> 2.0", [hex: :decimal, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:telemetry, "~> 0.4 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]} ], "hexpm", "checksum..."}, "phoenix": {:hex, :phoenix, "1.7.10", "sha256hash...", [:mix], [ {:castore, ">= 0.0.0", [hex: :castore, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:phoenix_pubsub, "~> 2.1", [hex: :phoenix_pubsub, repo: "hexpm", optional: false]}, {:phoenix_template, "~> 1.0", [hex: :phoenix_template, repo: "hexpm", optional: false]}, {:plug, "~> 1.14", [hex: :plug, repo: "hexpm", optional: false]}, {:plug_cowboy, "~> 2.6", [hex: :plug_cowboy, repo: "hexpm", optional: true]} ], "hexpm", "checksum..."}, } ``` Key information: - **Package format**: `{:hex, :package_name, "version", "hash", build_tools, dependencies, "hexpm", "checksum"}` - **Checksum**: SHA-256 hash for integrity verification - **Dependencies**: Nested dependency specifications ## Hex Package Manager Hex.pm is Elixir's package repository, similar to npm or RubyGems: ```bash # Get dependencies mix deps.get # Update dependencies mix deps.update --all # Check for outdated packages mix hex.outdated ``` ## Umbrella Applications Elixir umbrella projects contain multiple applications: ``` my_umbrella/ ├── mix.exs ├── mix.lock # Shared lockfile ├── apps/ │ ├── core/ │ │ ├── mix.exs │ │ └── lib/ │ ├── web/ │ │ ├── mix.exs │ │ └── lib/ │ └── worker/ │ ├── mix.exs │ └── lib/ ``` The root `mix.lock` contains dependencies for all applications. ### Umbrella mix.exs ```elixir defmodule MyUmbrella.MixProject do use Mix.Project def project do [ apps_path: "apps", version: "1.0.0", deps: deps() ] end defp deps do [] # Shared deps can go here end end ``` ## Development Dependencies Elixir clearly separates dev/test dependencies: ```elixir defp deps do [ # Runtime dependencies {:phoenix, "~> 1.7"}, # Dev only {:phoenix_live_reload, "~> 1.2", only: :dev}, # Dev and test {:credo, "~> 1.7", only: [:dev, :test], runtime: false}, # Test only {:mock, "~> 0.3.0", only: :test} ] end ``` For production SBOMs, filter out `:dev` and `:test` dependencies. ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Elixir, sbomify uses **cdxgen** or **Syft** under the hood. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: mix.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-elixir-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: mix.lock OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t elixir -o sbom.cdx.json ``` **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` **sbom (Elixir-native):** ```elixir # Add to mix.exs {:sbom, "~> 0.8", only: :dev, runtime: false} ``` ```bash mix sbom.cyclonedx ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: mix.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Handling Special Cases ### Git Dependencies Dependencies from Git: ```elixir {:my_dep, git: "https://github.com/example/my_dep.git", tag: "v1.0.0"} ``` In `mix.lock`: ```elixir "my_dep": {:git, "https://github.com/example/my_dep.git", "abc123...", [tag: "v1.0.0"]} ``` ### Path Dependencies Local dependencies: ```elixir {:shared, path: "../shared"} ``` These won't have Hex metadata and need manual documentation. ### Private Hex Repositories For private Hex repos: ```elixir {:private_dep, "~> 1.0", organization: "myorg"} ``` Configure authentication: ```bash mix hex.organization auth myorg ``` ### Override Dependencies Forcing specific versions: ```elixir defp deps do [ {:phoenix, "~> 1.7"}, {:plug, "~> 1.14", override: true} # Force version ] end ``` Overrides affect the final dependency tree captured in `mix.lock`. ## Native Dependencies (NIFs) Elixir packages may include Native Implemented Functions (NIFs): ```elixir {:rustler, "~> 0.30"}, # Rust NIFs {:bcrypt_elixir, "~> 3.0"} # C NIFs ``` These have native code dependencies not captured in `mix.lock`. Document them: ```yaml env: ADDITIONAL_PACKAGES: "openssl:3.0,rust:1.75" ``` ## Best Practices 1. **Always commit mix.lock** - Essential for reproducible builds 2. **Use exact versions for releases** - Pin versions in production 3. **Separate dev dependencies** - Use `only: :dev` and `only: :test` 4. **Check for vulnerabilities** - Use `mix hex.audit` 5. **Document NIFs** - Track native dependencies separately 6. **Update regularly** - Use `mix hex.outdated` to track updates ## Security Integration ```bash # Audit dependencies for vulnerabilities mix hex.audit # Generate SBOM and audit in CI mix deps.get mix hex.audit --format json > audit.json ``` ```yaml - name: Security audit run: mix hex.audit - name: Generate SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'mix.lock' OUTPUT_FILE: 'sbom.cdx.json' ``` ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes general SBOM utilities for generation, distribution, and analysis. --- # SBOM Generation Guide for Go - Go Modules URL: https://sbomify.com/guides/go/ Description: Learn how to generate Software Bill of Materials for Go projects. Complete guide with go.mod and go.sum examples, CycloneDX and SPDX output. ## Source vs Build SBOMs Go has one of the most straightforward dependency management systems thanks to Go Modules, introduced in Go 1.11. The distinction between source and build SBOMs in Go is important: - **Source SBOMs** are generated from `go.mod` and `go.sum` files - **Build SBOMs** are generated from the compiled binary using `go version -m` Go's design philosophy of reproducible builds means these should be nearly identical, but there are edge cases (build tags, CGO dependencies) where they may differ. ## Lockfile Deep Dive ### go.mod The `go.mod` file declares your module and its dependencies: ```go module github.com/example/myapp go 1.21 require ( github.com/gin-gonic/gin v1.9.1 github.com/lib/pq v1.10.9 go.uber.org/zap v1.26.0 ) require ( // indirect dependencies github.com/bytedance/sonic v1.10.2 // indirect github.com/gabriel-vasile/mimetype v1.4.3 // indirect ) ``` **Key points:** - Direct dependencies are listed under `require` - Indirect dependencies are marked with `// indirect` - The Go version specifies minimum language version ### go.sum The `go.sum` file contains cryptographic checksums for each module version: ``` github.com/gin-gonic/gin v1.9.1 h1:4idEAncQnU5cB7BeOkPtxjfCSye0AAm1R0RVIqJ+Jmg= github.com/gin-gonic/gin v1.9.1/go.mod h1:hPrL7YrpYKXt5YId3A/Tnip5kqbEAP+KLuI3SUcPTeU= github.com/lib/pq v1.10.9 h1:YXG7RB+JIjhP29X+OtkiDnYaXQwpS4JEWq7dtCCRUEw= github.com/lib/pq v1.10.9/go.mod h1:AlVN5x4E4T544tWzH6hKfbfQvm3HdbOxrmggDNAPY9o= ``` Each entry has two lines: 1. Hash of the module contents (`h1:`) 2. Hash of the `go.mod` file **Important:** Always commit both `go.mod` and `go.sum` to version control. ### The replace Directive The `replace` directive allows you to substitute module paths: ```go replace ( github.com/old/module => github.com/new/module v1.0.0 github.com/example/local => ../local-module ) ``` **SBOM implications:** - Replaced modules should be reflected in the SBOM - Local replacements (`../local-module`) won't have version information - Some SBOM tools may not handle replacements correctly ### The exclude Directive ```go exclude github.com/vulnerable/package v1.0.0 ``` Excluded versions should not appear in your SBOM. ## Go's Reproducible Builds Go excels at reproducible builds. The same source code with the same `go.mod`/`go.sum` produces the same binary. This means: 1. Source SBOMs from lockfiles should match build SBOMs from binaries 2. You can verify builds by comparing SBOMs 3. Signed attestations are meaningful Extract dependency information from a compiled binary: ```bash go version -m ./mybinary ``` Output: ``` ./mybinary: go1.21.5 path github.com/example/myapp mod github.com/example/myapp (devel) dep github.com/gin-gonic/gin v1.9.1 h1:4idEAncQnU5cB7BeOkPtxjfCSye0AAm1R0RVIqJ+Jmg= dep github.com/lib/pq v1.10.9 h1:YXG7RB+JIjhP29X+OtkiDnYaXQwpS4JEWq7dtCCRUEw= ``` ## Vendoring Go supports vendoring dependencies in a `vendor/` directory: ```bash go mod vendor ``` This creates a `vendor/` directory with all dependencies. For SBOM generation: - Vendored projects should generate the same SBOM as non-vendored - Some tools analyze `vendor/` directly for additional accuracy - The `vendor/modules.txt` file provides a manifest ## Private Modules For private modules, ensure your SBOM tools can access them: ```bash # Configure private module patterns go env -w GOPRIVATE=github.com/mycompany/* # Use .netrc for authentication echo "machine github.com login USERNAME password TOKEN" >> ~/.netrc ``` ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Go, sbomify uses **cyclonedx-gomod** under the hood, which reads the module graph the Go toolchain itself resolved. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: go.mod OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-go-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: go.mod OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` The action supports both `go.mod` and `go.sum`. ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t go -o sbom.cdx.json ``` **cyclonedx-gomod (Go-native):** ```bash go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest cyclonedx-gomod mod -output sbom.cdx.json ``` **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: go.mod OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## CGO Dependencies If your Go project uses CGO, you have additional considerations: ```go // #cgo LDFLAGS: -lssl -lcrypto // #include import "C" ``` CGO dependencies (system libraries) won't appear in `go.mod`. You may need to: 1. Document them manually using `ADDITIONAL_PACKAGES` 2. Use a tool that analyzes the binary's dynamic linking ```yaml env: ADDITIONAL_PACKAGES: "openssl:1.1.1,libcrypto:1.1.1" ``` ## Best Practices 1. **Always commit go.sum** - It contains the integrity hashes needed for verification 2. **Use specific versions** - Avoid pseudo-versions when possible 3. **Regularly run `go mod tidy`** - Keep dependencies clean 4. **Consider vendoring** - For reproducibility and offline builds 5. **Handle replace directives carefully** - Document local replacements 6. **Generate both source and binary SBOMs** - Compare for verification ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional Go-specific tools like CycloneDX Go and SPDX Golang libraries. --- # SBOM Generation Guide for Java - Maven, Gradle URL: https://sbomify.com/guides/java/ Description: Learn how to generate Software Bill of Materials for Java projects. Complete guide with pom.xml, build.gradle, and gradle.lockfile examples, CycloneDX and SPDX output. ## Source vs Build SBOMs Java has a mature dependency management ecosystem with Maven and Gradle as the primary build tools. Understanding the difference between source and build SBOMs is particularly important in Java due to: - **Transitive dependency resolution**: Java's dependency managers resolve complex transitive dependency trees - **Scope differences**: Dependencies can be compile-time, runtime, test, or provided - **Multi-module projects**: Enterprise Java applications often consist of many modules For source SBOMs, you're generating from `pom.xml`, `build.gradle`, or `gradle.lockfile`. For build SBOMs, you're analyzing the actual JARs in your classpath or the final packaged artifact. ## Lockfile Deep Dive ### Maven (pom.xml) Maven's `pom.xml` is both a manifest and a build file. Dependencies are declared with optional version ranges: ```xml org.springframework.boot spring-boot-starter-web 3.2.0 com.fasterxml.jackson.core jackson-databind 2.16.0 ``` **Important considerations:** - Maven doesn't have a traditional lockfile - versions in `pom.xml` can be ranges or managed by parent POMs - Use the `maven-enforcer-plugin` with `` to ensure consistent versions - Consider using a BOM (Bill of Materials) POM for version management To get the effective dependencies with resolved versions: ```bash mvn dependency:tree mvn dependency:list ``` ### Gradle (build.gradle / build.gradle.kts) Gradle supports both Groovy (`build.gradle`) and Kotlin (`build.gradle.kts`) DSLs: ```groovy // build.gradle dependencies { implementation 'org.springframework.boot:spring-boot-starter-web:3.2.0' implementation 'com.fasterxml.jackson.core:jackson-databind:2.16.0' testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0' } ``` ```kotlin // build.gradle.kts dependencies { implementation("org.springframework.boot:spring-boot-starter-web:3.2.0") implementation("com.fasterxml.jackson.core:jackson-databind:2.16.0") testImplementation("org.junit.jupiter:junit-jupiter:5.10.0") } ``` ### Gradle Lockfile (gradle.lockfile) For reproducible builds, Gradle supports dependency locking: ```bash # Enable dependency locking gradle dependencies --write-locks ``` This creates a `gradle.lockfile`: ``` # This is a Gradle generated file for dependency locking. com.fasterxml.jackson.core:jackson-annotations:2.16.0=compileClasspath,runtimeClasspath com.fasterxml.jackson.core:jackson-core:2.16.0=compileClasspath,runtimeClasspath com.fasterxml.jackson.core:jackson-databind:2.16.0=compileClasspath,runtimeClasspath org.springframework.boot:spring-boot-starter-web:3.2.0=compileClasspath,runtimeClasspath ``` To enable locking in your `build.gradle`: ```groovy dependencyLocking { lockAllConfigurations() } ``` ## Transitive Dependency Resolution Both Maven and Gradle resolve transitive dependencies, but with different strategies: | Aspect | Maven | Gradle | | ------------------- | -------------------------------- | ----------------------------------------------------------------- | | Conflict resolution | Nearest definition wins | Newest version wins (default) | | Dependency scope | compile, provided, runtime, test | implementation, api, compileOnly, runtimeOnly, testImplementation | | BOM support | `` | `platform()` | Understanding these differences is crucial because your SBOM should accurately reflect what ends up in your final artifact. ## Multi-Module Projects Enterprise Java applications often use multi-module structures: ``` my-app/ ├── pom.xml (parent) ├── core/ │ └── pom.xml ├── api/ │ └── pom.xml └── web/ └── pom.xml ``` For SBOM generation, you have two approaches: 1. **Per-module SBOMs**: Generate an SBOM for each module 2. **Aggregate SBOM**: Generate a single SBOM for the entire project ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Java, sbomify uses **cyclonedx-maven** for `pom.xml` and **cyclonedx-gradle** for Gradle build scripts, and reads a `gradle.lockfile` directly without running Gradle at all. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: pom.xml OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-java-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: pom.xml OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` The action supports: `pom.xml`, `build.gradle`, `build.gradle.kts`, and `gradle.lockfile`. ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen (recommended for manual use):** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t maven -o sbom.cdx.json ``` **CycloneDX Maven Plugin:** ```xml org.cyclonedx cyclonedx-maven-plugin 2.9.1 ``` ```bash mvn cyclonedx:makeAggregateBom ``` **CycloneDX Gradle Plugin:** ```groovy plugins { id 'org.cyclonedx.bom' version '3.1.0' } ``` ```bash gradle cyclonedxBom ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: pom.xml OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Best Practices 1. **Use dependency locking** - Enable Gradle lockfiles for reproducible builds 2. **Pin versions explicitly** - Avoid version ranges in production dependencies 3. **Use BOMs for version management** - Spring Boot BOM, Jackson BOM, etc. 4. **Separate compile and runtime scopes** - Be clear about what goes into your final artifact 5. **Exclude test dependencies** - Unless required for compliance 6. **Consider shaded/uber JARs** - These need special handling for accurate SBOMs ## Handling Shaded/Uber JARs If you use the Maven Shade Plugin or Gradle Shadow Plugin to create uber JARs, the dependencies are bundled inside. For accurate SBOMs: 1. Generate the SBOM **before** shading 2. Use tools that can analyze the shaded JAR contents 3. Consider using cdxgen's `--deep` flag: ```bash cdxgen -t java --deep -o sbom.cdx.json ``` ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional Java-specific tools like CycloneDX Java and SPDX Java libraries. --- # SBOM Generation Guide for JavaScript - npm, yarn, pnpm, Bun URL: https://sbomify.com/guides/javascript/ Description: Learn how to generate Software Bill of Materials for JavaScript and Node.js projects. Complete guide with package-lock.json, yarn.lock, pnpm-lock.yaml, and bun.lock examples. ## Source vs Build SBOMs In the JavaScript ecosystem, SBOMs can be generated either from lockfiles (source/pre-build) or from the installed `node_modules` directory (build/post-install). The JavaScript ecosystem has one of the most mature dependency management systems, with multiple package managers each providing their own lockfile format. For most JavaScript projects, generating SBOMs from lockfiles is the preferred approach because: - Lockfiles contain exact versions and integrity hashes - They're committed to version control, ensuring reproducibility - They capture the full dependency tree including transitive dependencies ## Lockfile Deep Dive JavaScript projects have several package managers, each with their own lockfile format. Understanding these differences is crucial for accurate SBOM generation. ### npm (package-lock.json) The `package-lock.json` file is npm's lockfile, introduced in npm 5. It contains: - Exact resolved versions of all dependencies - Integrity hashes (SHA-512) for verification - The full dependency tree structure Example structure: ```json { "name": "my-app", "version": "1.0.0", "lockfileVersion": 3, "packages": { "": { "name": "my-app", "dependencies": { "express": "^4.18.2" } }, "node_modules/express": { "version": "4.18.2", "resolved": "https://registry.npmjs.org/express/-/express-4.18.2.tgz", "integrity": "sha512-5/PsL6iGPdfQ/lKM1UuielYgv3BUoJfz1aUwU9vHZ+J7gyvwdQXFEBIEIaxeGf0GIcreATNyBExtalisDbuMqQ==" } } } ``` **Important:** Always commit your `package-lock.json` to version control. Without it, you only have the version ranges from `package.json`, which makes reproducible SBOMs impossible. ### yarn (yarn.lock) Yarn's lockfile uses a custom format (YAML-like in v1, YAML in v2+): ```yaml # yarn.lock (Classic v1) express@^4.18.2: version "4.18.2" resolved "https://registry.yarnpkg.com/express/-/express-4.18.2.tgz" integrity sha512-5/PsL6iGPdfQ/lKM1UuielYgv3BUoJfz1aUwU9vHZ+J7gyvwdQXFEBIEIaxeGf0GIcreATNyBExtalisDbuMqQ== dependencies: accepts "~1.3.8" body-parser "1.20.1" ``` Yarn Berry (v2+) uses a different format with more metadata and supports PnP (Plug'n'Play) installations. ### pnpm (pnpm-lock.yaml) pnpm's lockfile is YAML-based and includes additional information about the content-addressable store: ```yaml lockfileVersion: '9.0' settings: autoInstallPeers: true packages: express@4.18.2: resolution: {integrity: sha512-5/PsL6iGPdfQ/lKM1UuielYgv3BUoJfz1aUwU9vHZ+J7gyvwdQXFEBIEIaxeGf0GIcreATNyBExtalisDbuMqQ==} engines: {node: '>= 0.10.0'} dependencies: accepts: 1.3.8 ``` ### Bun (bun.lock) Bun uses a binary lockfile format (`bun.lockb`) by default for performance, but also supports a text format (`bun.lock`). For SBOM generation, you'll want the text format: ```bash # Generate text lockfile bun install --save-text-lockfile ``` ## The node_modules Problem JavaScript's dependency resolution creates a flat or nested `node_modules` structure depending on the package manager: - **npm (v3+)**: Flat structure with hoisting - **yarn (Classic)**: Similar flat structure - **pnpm**: Symlinked structure using content-addressable storage - **Bun**: Symlinked structure similar to pnpm This affects SBOM generation because build-time SBOMs analyze what's actually installed, which may differ from the lockfile in edge cases (platform-specific optional dependencies, for example). ## npm audit vs SBOM-based Vulnerability Scanning While `npm audit` provides quick vulnerability checking, SBOM-based scanning offers advantages: | Feature | npm audit | SBOM + Scanner | | -------------------------- | --------- | -------------- | | Offline analysis | No | Yes | | Historical tracking | No | Yes | | Cross-project analysis | No | Yes | | Multiple vulnerability DBs | npm only | OSV, NVD, etc. | | License compliance | No | Yes | ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For JavaScript, sbomify uses **cdxgen** under the hood as it has excellent support for all JavaScript lockfile formats. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-node-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` The action supports all JavaScript lockfiles: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, and `bun.lock`. ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen (recommended for manual use):** ```bash npm install -g @cyclonedx/cdxgen cdxgen -o sbom.cdx.json ``` **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Monorepo Considerations For monorepos with multiple `package.json` files, you have several options: 1. **Generate per-workspace SBOMs**: Run SBOM generation for each workspace 2. **Use workspace-aware tools**: cdxgen supports npm/yarn workspaces natively 3. **Aggregate SBOMs**: Generate individual SBOMs and merge them ```bash # cdxgen with workspace support cdxgen --type npm -o sbom.cdx.json --include-subprojects ``` ## Best Practices 1. **Always commit your lockfile** - This ensures reproducible SBOMs 2. **Use exact versions in production** - Avoid version ranges for deployed applications 3. **Regularly update dependencies** - Use tools like Renovate or Dependabot 4. **Include dev dependencies carefully** - Consider whether they belong in your SBOM 5. **Verify integrity hashes** - Modern package managers do this automatically ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional JavaScript-specific tools and general SBOM utilities for generation, distribution, and analysis. --- # SBOM Generation Guide for PHP - Composer URL: https://sbomify.com/guides/php/ Description: Learn how to generate Software Bill of Materials for PHP projects. Complete guide with composer.lock examples, dev dependencies, and CycloneDX output. ## Source vs Build SBOMs PHP's dependency management is handled primarily through Composer, which provides excellent lockfile support through `composer.lock`. This makes source SBOM generation straightforward and reliable. - **Source SBOMs** are generated from `composer.lock` - **Build SBOMs** are generated from the installed `vendor/` directory For most PHP projects, the lockfile approach is preferred because `composer.lock` contains: - Exact resolved versions - Package hashes for integrity verification - Full dependency tree including transitive dependencies ## Lockfile Deep Dive ### composer.json vs composer.lock | File | Purpose | Commit to VCS? | | --------------- | -------------------------------------------- | -------------- | | `composer.json` | Dependency declarations, version constraints | Always | | `composer.lock` | Resolved versions, hashes, full tree | Always | ### composer.json The `composer.json` file declares your dependencies: ```json { "name": "mycompany/myapp", "require": { "php": "^8.2", "laravel/framework": "^11.0", "guzzlehttp/guzzle": "^7.8" }, "require-dev": { "phpunit/phpunit": "^11.0", "phpstan/phpstan": "^1.10" } } ``` ### composer.lock The `composer.lock` file contains resolved dependencies: ```json { "_readme": [ "This file locks the dependencies of your project to a known state" ], "content-hash": "abc123def456...", "packages": [ { "name": "guzzlehttp/guzzle", "version": "7.8.1", "source": { "type": "git", "url": "https://github.com/guzzle/guzzle.git", "reference": "abc123..." }, "dist": { "type": "zip", "url": "https://api.github.com/repos/guzzle/guzzle/zipball/abc123", "reference": "abc123...", "shasum": "" }, "require": { "php": "^8.1", "guzzlehttp/promises": "^2.0", "guzzlehttp/psr7": "^2.5" } } ], "packages-dev": [ { "name": "phpunit/phpunit", "version": "11.0.0" } ] } ``` Key sections: - **packages**: Production dependencies - **packages-dev**: Development dependencies (tests, tools) - **content-hash**: Hash of composer.json for integrity ## Dev Dependencies (require-dev) Composer separates production and development dependencies: ```json { "require": { "monolog/monolog": "^3.0" }, "require-dev": { "phpunit/phpunit": "^11.0", "mockery/mockery": "^1.6" } } ``` For production SBOMs, you typically exclude dev dependencies: ```bash # Install without dev dependencies composer install --no-dev ``` Most SBOM tools can filter dev dependencies from the generated SBOM. ## Platform Requirements Composer tracks platform requirements: ```json { "require": { "php": "^8.2", "ext-json": "*", "ext-pdo": "*", "ext-openssl": "*" } } ``` These platform requirements specify: - PHP version constraints - Required PHP extensions - System library dependencies Consider including these in your SBOM for completeness. ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For PHP, sbomify uses **cdxgen** under the hood with fallback to Syft. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: composer.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-php-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: composer.lock OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **CycloneDX PHP Composer Plugin:** ```bash composer require --dev cyclonedx/cyclonedx-php-composer composer make-bom --output-file=sbom.cdx.json ``` **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t php -o sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: composer.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Private Packages (Satis/Private Packagist) For projects using private Composer repositories: ```json { "repositories": [ { "type": "composer", "url": "https://packages.example.com" } ] } ``` Ensure your CI environment has authentication configured: ```bash # Using auth.json { "http-basic": { "packages.example.com": { "username": "user", "password": "token" } } } # Or via environment variable COMPOSER_AUTH='{"http-basic":{"packages.example.com":{"username":"user","password":"token"}}}' ``` ## Handling Special Cases ### Path Repositories Local packages via path repositories: ```json { "repositories": [ { "type": "path", "url": "../my-local-package" } ] } ``` These won't have Packagist metadata. Consider documenting them with `ADDITIONAL_PACKAGES`. ### VCS Repositories Packages from Git/SVN: ```json { "repositories": [ { "type": "vcs", "url": "https://github.com/example/package" } ] } ``` These appear in `composer.lock` with Git references instead of version numbers. ### Platform Overrides If you use platform overrides: ```json { "config": { "platform": { "php": "8.2.0", "ext-gd": "1.0.0" } } } ``` Document these in your SBOM metadata to ensure accurate representation. ## Monorepo Support For monorepos with multiple `composer.json` files: ``` myproject/ ├── app/ │ └── composer.json ├── packages/ │ ├── core/ │ │ └── composer.json │ └── utils/ │ └── composer.json └── composer.json (root) ``` Generate SBOMs per component or use a tool that supports monorepo detection. ## Best Practices 1. **Always commit composer.lock** - Essential for reproducible builds 2. **Use exact versions for production** - Avoid `^` and `~` in production requirements 3. **Separate dev and production** - Use `--no-dev` for production installations 4. **Run `composer audit`** - Check for known vulnerabilities alongside SBOM generation 5. **Include platform requirements** - Document PHP version and extensions 6. **Update regularly** - Use `composer outdated` to track updates ## Security Tooling Integration ```bash # Check for vulnerabilities composer audit # Generate SBOM and audit in CI composer install --no-dev composer audit --format=json > audit.json composer make-bom --exclude-dev --output-file=sbom.cdx.json ``` ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional PHP-specific tools like CycloneDX PHP Composer plugin. --- # SBOM Generation Guide for Python - UV, Poetry, Pipenv URL: https://sbomify.com/guides/python/ Description: Learn how to generate Software Bill of Materials for Python projects. Complete guide with uv.lock, poetry.lock, and Pipfile.lock examples. ## Source vs Build SBOMs Before we dive into the actual guide, let's start by talking about SBOM generation. Generally speaking, an SBOM is either built from source (also known as 'pre-build' in CycloneDX terminology) or built after installation. When we talk about source SBOMs, we normally refer to generating an SBOM from a lockfile, and for built SBOMs, we look at what has been installed by the package manager. These might seem interchangeable, and the output might be identical. However, this really boils down to the quality of the lockfile, so let's dive into this with some examples. ## Lockfile Example Modern Python package managers like [UV](https://docs.astral.sh/uv/) and [Poetry](https://python-poetry.org/) automatically generate complete lockfiles with all transitive dependencies and cryptographic hashes. This makes them ideal for SBOM generation. ### Why Migrate Away from requirements.txt? If you're still using `requirements.txt` with `pip`, consider migrating to UV or Poetry. The traditional `requirements.txt` approach has several limitations that affect SBOM quality: - **Missing transitive dependencies**: A `requirements.txt` often only lists direct dependencies. Flask might be listed, but its dependencies (Werkzeug, Jinja2, etc.) are missing unless you manually run `pip freeze`. - **No hashes by default**: Adding cryptographic hashes requires extra tooling like pip-tools, and even then, SBOM tools have inconsistent support for this format. - **Version ranges cause ambiguity**: Expressions like `flask>=3.0.0` make it impossible to generate accurate source/pre-build SBOMs since the exact version is unknown. UV and Poetry solve all of these issues automatically. For a Flask-based Python server, your `pyproject.toml` would declare: ```toml [project] dependencies = ["flask>=3.0.3"] ``` Running `uv lock` generates a `uv.lock` file that captures Flask and all its dependencies with exact versions and hashes – ready for accurate SBOM generation. Similarly, with Poetry, running `poetry lock` generates a `poetry.lock` file with the same completeness. The key point is that the SBOM is directly correlated to the quality of the lockfile. UV and Poetry solve this by automatically: - Capturing all transitive dependencies - Including cryptographic hashes - Using precise version pinning ### Hashes Are Included Automatically UV and Poetry automatically add cryptographic hashes to all packages in their lockfiles. This is required for NTIA Minimum Elements compliance – no extra tooling needed. ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ![Lifecycle](/assets/images/d2/lifecycle.svg) ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Python, sbomify uses **cyclonedx-py** under the hood as it provides the most accurate results for Python lockfiles, including proper hash support. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: uv.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-python-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: uv.lock OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` The action supports all Python lockfiles: `uv.lock`, `poetry.lock`, `Pipfile.lock`, and `pyproject.toml`. **Still on requirements.txt?** If you haven't migrated to UV or Poetry yet, sbomify-action can still help. When given a `requirements.txt`, the action uses [pipdeptree](https://github.com/tox-dev/pipdeptree) to discover transitive dependencies that aren't listed in your requirements file and automatically adds them to the SBOM. This means you get a more complete SBOM even without a proper lockfile, though we still recommend migrating to UV or Poetry for the best results. ### Alternative Tools If you prefer to run SBOM generation tools manually: **cyclonedx-py (Python-native, recommended for manual use):** ```bash pip install cyclonedx-bom cyclonedx-py environment --output-format json -o sbom.cdx.json ``` This is the same tool sbomify uses under the hood. It reads from your installed environment and properly handles hashes. **cdxgen:** ```bash cdxgen -o sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. See our [Resources page](/resources/#python) for more Python SBOM tools. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: uv.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action ``` ## PEP 770: Shipping SBOMs Inside Python Packages [PEP 770](https://peps.python.org/pep-0770/) standardizes including SBOMs directly inside Python wheels via the `.dist-info/sboms/` directory. If you publish Python packages to PyPI, this means your users get the SBOM automatically when they `pip install` your package. Build backends like hatchling (>= 1.28.0) already support it. Read our [full write-up on PEP 770](/2026/03/05/pep-770-sboms-in-python-packages/) for implementation details and real-world examples. ## Further Reading Related blog posts: - [PEP 770: SBOMs Are Now a First-Class Citizen in Python Packages](/2026/03/05/pep-770-sboms-in-python-packages/) - How PEP 770 works and how we adopted it in two projects with minimal effort - [How to Generate SBOMs for Python Packages with pipdeptree and cyclonedx-py](/2024/07/30/generate-sboms-for-python-packages-with-pipdeptree-and-cyclonedx-py/) - Tutorial on generating CycloneDX SBOMs including transitive dependencies and best practices for pinning with hashes ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional Python-specific tools like CycloneDX Python, sbom4python, and SPDX Python libraries. --- # SBOM Generation Guide for Raspberry Pi - rpi-image-gen URL: https://sbomify.com/guides/raspberry-pi/ Description: Learn how to generate Software Bill of Materials for Raspberry Pi custom images using rpi-image-gen. Complete guide with SPDX output and quality analysis. ## Source vs Build SBOMs The Raspberry Pi Foundation's [rpi-image-gen](https://github.com/raspberrypi/rpi-image-gen) tool generates **build SBOMs** automatically when creating custom Raspberry Pi images. Every image built with rpi-image-gen includes an SPDX SBOM out of the box. This is a significant advancement for embedded device manufacturers who need to provide SBOMs for compliance with regulations like the EU Cyber Resilience Act or US Executive Order 14028. ## rpi-image-gen Overview rpi-image-gen is a flexible image builder designed for developers and device makers who need custom Raspberry Pi images. Unlike the older [pi-gen](https://github.com/RPi-Distro/pi-gen) tool used for official Raspberry Pi OS builds, rpi-image-gen is optimized for bespoke images. ### Requirements - Run on Raspberry Pi OS (Raspbian) for best compatibility - Running on plain Debian or Ubuntu may cause architecture mismatches ### Building an Image ```bash # Clone the repository git clone https://github.com/raspberrypi/rpi-image-gen.git cd rpi-image-gen # Install dependencies sudo ./install_deps.sh # Build a minimal Debian 12 image for 64-bit devices ./build.sh ``` ## SBOM Generation rpi-image-gen generates SPDX SBOMs automatically during the build process. No additional configuration is required. ### Locating the SBOM After the build completes, find the SBOM in the output directory: ```bash ls output/ # Look for: [image-name].sbom.spdx.json ``` ### SBOM Quality The generated SBOMs achieve high quality scores. Using [sbomqs](https://github.com/interlynk-io/sbomqs): ```bash $ sbomqs score output/*.sbom.spdx.json SBOM Quality by Interlynk Score: 7.8 ``` Key quality attributes: - ✅ Component names and versions - ✅ Supplier information - ✅ Package identifiers (PURLs) - ✅ Valid SPDX licenses - ✅ Creation timestamps ## SBOM Structure The generated SPDX SBOM includes comprehensive package information: ```json { "spdxVersion": "SPDX-2.3", "SPDXID": "SPDXRef-DOCUMENT", "name": "raspberry-pi-image", "creationInfo": { "created": "2025-04-17T10:00:00Z", "creators": ["Tool: rpi-image-gen"] }, "packages": [ { "SPDXID": "SPDXRef-Package-apt", "name": "apt", "versionInfo": "2.6.1", "supplier": "Organization: Debian", "downloadLocation": "https://packages.debian.org/...", "licenseConcluded": "GPL-2.0-or-later" } ] } ``` ## Working with the SBOM ### Converting to CycloneDX If you need CycloneDX format: ```bash # Using cyclonedx-cli cyclonedx convert \ --input-file output/image.sbom.spdx.json \ --output-file image.cdx.json ``` ### Quality Analysis Validate your SBOM before distribution: ```bash # Using sbomqs sbomqs score output/*.sbom.spdx.json # Using NTIA conformance checker ntia-conformance-check output/*.sbom.spdx.json ``` ### Enrichment Add additional metadata using sbomify: ```bash # Enrich with package registry metadata sbomify enrich --input output/*.sbom.spdx.json --output enriched.spdx.json ``` ## CI/CD Integration Automate image builds with SBOM generation: ```yaml # GitHub Actions example - name: Build Raspberry Pi image run: | cd rpi-image-gen ./build.sh - name: Upload SBOM uses: actions/upload-artifact@v4 with: name: raspberry-pi-sbom path: output/*.sbom.spdx.json ``` ```yaml # GitLab CI example build-image: stage: build tags: - raspberry-pi script: - cd rpi-image-gen - ./build.sh artifacts: paths: - output/*.sbom.spdx.json ``` ## Enrichment and Augmentation with sbomify While rpi-image-gen generates SBOMs natively, you can use the [sbomify action](/sbomify-action/) to enrich and augment them further. The action accepts existing SBOMs via the `SBOM_FILE` input. **Standalone (enrichment only, no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: SBOM_FILE: output/image.sbom.spdx.json OUTPUT_FILE: enriched-sbom.cdx.json ENRICH: true UPLOAD: false ``` **With sbomify platform (enrichment + augmentation):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-raspberry-pi-image SBOM_FILE: output/image.sbom.spdx.json OUTPUT_FILE: enriched-sbom.cdx.json ENRICH: true AUGMENT: true ``` This enriches the rpi-image-gen SBOM with additional package metadata from public registries and optionally augments it with your business metadata (supplier, authors, licenses) from sbomify. Use sbomify for complete SBOM lifecycle management: 1. **Upload** - Upload the enriched SBOM to sbomify 2. **Augment** - Add vendor and supplier information 3. **Distribute** - Share with customers and stakeholders 4. **Monitor** - Track vulnerabilities across releases ## Best Practices 1. **Build on Raspberry Pi OS** - Ensures architecture compatibility 2. **Archive SBOMs with releases** - Store alongside image files 3. **Validate before distribution** - Check quality with sbomqs 4. **Sign your SBOMs** - Add cryptographic signatures 5. **Version your images** - Track SBOM changes across releases 6. **Enrich metadata** - Add supplier and contact information ## Limitations - **SPDX only** - rpi-image-gen generates SPDX format (no CycloneDX) - **Debian packages** - Captures Debian/Raspbian packages only - **Build environment** - Best run on Raspberry Pi OS ## Further Reading Related blog posts: - [Unpacking Raspberry Pi's Built-In SBOM Magic](/2025/04/17/unpacking-raspberry-pi-s-built-in-sbom-magic/) - How rpi-image-gen generates SBOMs for Raspberry Pi images ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes tools for SBOM generation, distribution, and analysis. --- # SBOM Generation Guide for Ruby - Bundler URL: https://sbomify.com/guides/ruby/ Description: Learn how to generate Software Bill of Materials for Ruby projects. Complete guide with Gemfile.lock examples, platform-specific gems, and CycloneDX output. ## Source vs Build SBOMs Ruby's Bundler package manager provides excellent lockfile support through `Gemfile.lock`. This makes source SBOM generation reliable and reproducible. - **Source SBOMs** are generated from `Gemfile.lock` - **Build SBOMs** are generated from installed gems in the bundle path For most Ruby projects, generating from `Gemfile.lock` is preferred because it contains: - Exact gem versions - Platform specifications - Complete dependency tree including transitive dependencies - Git references for git-sourced gems ## Lockfile Deep Dive ### Gemfile vs Gemfile.lock | File | Purpose | Commit to VCS? | | -------------- | -------------------------------------------- | ---------------------------------- | | `Gemfile` | Dependency declarations, version constraints | Always | | `Gemfile.lock` | Resolved versions, full dependency tree | Always for apps, Optional for gems | ### Gemfile The `Gemfile` declares your dependencies: ```ruby source 'https://rubygems.org' ruby '3.3.0' gem 'rails', '~> 7.1' gem 'puma', '~> 6.0' gem 'pg', '~> 1.5' group :development, :test do gem 'rspec-rails', '~> 6.0' gem 'rubocop', '~> 1.60' end group :development do gem 'web-console' end ``` ### Gemfile.lock The `Gemfile.lock` contains resolved dependencies: ``` GEM remote: https://rubygems.org/ specs: actioncable (7.1.3) actionpack (= 7.1.3) activesupport (= 7.1.3) nio4r (~> 2.0) websocket-driver (>= 0.6.1) actionmailbox (7.1.3) actionpack (= 7.1.3) activejob (= 7.1.3) pg (1.5.4) puma (6.4.2) nio4r (~> 2.0) rails (7.1.3) actioncable (= 7.1.3) actionmailbox (= 7.1.3) PLATFORMS arm64-darwin-23 x86_64-linux DEPENDENCIES pg (~> 1.5) puma (~> 6.0) rails (~> 7.1) rspec-rails (~> 6.0) rubocop (~> 1.60) web-console RUBY VERSION ruby 3.3.0p0 BUNDLED WITH 2.5.6 ``` Key sections: - **GEM specs**: All resolved gems with versions and dependencies - **PLATFORMS**: Target platforms for the bundle - **DEPENDENCIES**: Direct dependencies from Gemfile - **RUBY VERSION**: Ruby version constraint - **BUNDLED WITH**: Bundler version used ## Platform-Specific Gems Ruby gems can have platform-specific variants: ```ruby # Gemfile gem 'nokogiri', '~> 1.16' # Has native extensions # Platform-specific gems gem 'wdm', '>= 0.1.0', platforms: [:mingw, :mswin, :x64_mingw] ``` Add platforms to ensure proper resolution: ```bash # Add platforms to Gemfile.lock bundle lock --add-platform x86_64-linux arm64-darwin ruby ``` The lockfile will include platform-specific versions: ``` nokogiri (1.16.0) nokogiri (1.16.0-arm64-darwin) nokogiri (1.16.0-x86_64-linux) ``` **SBOM consideration:** Platform-specific gems may have different native dependencies that aren't captured in the lockfile. ## Git-Sourced Gems Gems can come from Git repositories: ```ruby # Gemfile gem 'my-gem', git: 'https://github.com/example/my-gem.git', branch: 'main' gem 'another-gem', git: 'https://github.com/example/another.git', tag: 'v1.0.0' ``` In `Gemfile.lock`: ``` GIT remote: https://github.com/example/my-gem.git revision: abc123def456 branch: main specs: my-gem (1.0.0) ``` The Git revision is captured, but these gems won't have RubyGems metadata for enrichment. ## Groups and Development Dependencies Bundler organizes gems into groups: ```ruby group :development do gem 'debug' end group :test do gem 'rspec' gem 'factory_bot' end group :production do gem 'rails_12factor' end ``` For production SBOMs, exclude development/test groups: ```bash bundle install --without development test ``` ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Ruby, sbomify uses **cdxgen** under the hood with fallback to Syft. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: Gemfile.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-ruby-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: Gemfile.lock OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **CycloneDX Ruby Gem:** ```bash gem install cyclonedx-ruby cyclonedx-ruby -p . -o sbom.cdx.json ``` **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t ruby -o sbom.cdx.json ``` **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: Gemfile.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Rails Applications For Rails applications, consider these additional aspects: ### Asset Pipeline Dependencies If using Webpacker/Shakapacker, also generate a JavaScript SBOM: ```yaml - name: Generate Ruby SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'Gemfile.lock' OUTPUT_FILE: 'ruby-sbom.cdx.json' - name: Generate JS SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'yarn.lock' OUTPUT_FILE: 'js-sbom.cdx.json' ``` ### Database Adapters Native database adapters (`pg`, `mysql2`, `sqlite3`) have system library dependencies not captured in the lockfile. Document these: ```yaml env: ADDITIONAL_PACKAGES: "libpq:14.0,openssl:1.1.1" ``` ## Handling Special Cases ### Path Gems Local gems via path: ```ruby gem 'my-local-gem', path: '../my-local-gem' ``` These won't have RubyGems metadata and may need manual documentation. ### Private Gem Sources For private gem servers (Gemfury, private RubyGems): ```ruby source 'https://rubygems.org' source 'https://gems.example.com' do gem 'private-gem' end ``` Ensure your CI has authentication configured: ```bash bundle config set --global gems.example.com user:password ``` ### Bundler Settings Consider your bundler configuration when generating SBOMs: ```bash # View current settings bundle config list # Common settings that affect dependencies bundle config set --local without development:test bundle config set --local path vendor/bundle ``` ## Best Practices 1. **Always commit Gemfile.lock** - Essential for reproducible builds 2. **Add all target platforms** - Use `bundle lock --add-platform` 3. **Pin Ruby version** - Use `.ruby-version` or specify in Gemfile 4. **Exclude dev dependencies** - For production SBOMs, use `--without development test` 5. **Run `bundle audit`** - Check for vulnerabilities alongside SBOM generation 6. **Update regularly** - Use `bundle outdated` to track updates ## Security Tooling Integration ```bash # Install bundler-audit gem install bundler-audit # Check for vulnerabilities bundle audit check --update # Generate SBOM and audit in CI bundle audit --format json > audit.json cyclonedx-ruby -p . -o sbom.cdx.json ``` ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional Ruby-specific tools like CycloneDX Ruby gem. --- # SBOM Generation Guide for Rust - Cargo URL: https://sbomify.com/guides/rust/ Description: Learn how to generate Software Bill of Materials for Rust projects. Complete guide with Cargo.lock examples, workspace dependencies, and CycloneDX output. ## Source vs Build SBOMs Rust has excellent support for reproducible builds through Cargo, its package manager. The `Cargo.lock` file provides precise dependency information, making source SBOMs highly accurate. The Rust ecosystem's security focus means: - Crates are immutable once published - `Cargo.lock` contains exact versions and checksums - Reproducible builds are a first-class concern For source SBOMs, you generate from `Cargo.lock`. For build SBOMs, you analyze the compiled binary (which embeds dependency information in debug builds). ## Lockfile Deep Dive ### Cargo.lock Structure The `Cargo.lock` file contains precise dependency information: ```toml # This file is automatically @generated by Cargo. # It is not intended for manual editing. version = 3 [[package]] name = "actix-web" version = "4.4.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "e43428f1a9b00f007c853a2adf1e46700a2d81e1d498299a9d5198d417c8e030" dependencies = [ "actix-codec", "actix-http", "actix-router", ] [[package]] name = "serde" version = "1.0.193" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "25dd9975e68d0cb5aa1120c288333fc98731bd1dd12f561e468ea4728c042b89" dependencies = [ "serde_derive", ] ``` Each package entry includes: - **name**: Crate name - **version**: Exact semantic version - **source**: Where the crate comes from (usually crates.io) - **checksum**: SHA-256 hash for integrity verification - **dependencies**: Direct dependencies of this crate ### Cargo.toml vs Cargo.lock | File | Purpose | Commit to VCS? | | ------------ | ---------------------------------------- | --------------------------------------------- | | `Cargo.toml` | Dependency declarations (can use ranges) | Always | | `Cargo.lock` | Exact resolved versions | Yes for binaries/apps, Optional for libraries | **Important for SBOMs:** Always use `Cargo.lock` for SBOM generation, as it contains the resolved versions. ## Workspace Dependencies Rust workspaces allow sharing dependencies across multiple crates: ``` my-project/ ├── Cargo.toml # Workspace root ├── Cargo.lock # Shared lockfile ├── app/ │ └── Cargo.toml ├── lib-core/ │ └── Cargo.toml └── lib-utils/ └── Cargo.toml ``` Workspace root `Cargo.toml`: ```toml [workspace] members = ["app", "lib-core", "lib-utils"] [workspace.dependencies] serde = { version = "1.0", features = ["derive"] } tokio = { version = "1.0", features = ["full"] } ``` Member crate `Cargo.toml`: ```toml [package] name = "app" version = "0.1.0" [dependencies] serde = { workspace = true } tokio = { workspace = true } lib-core = { path = "../lib-core" } ``` For workspace SBOMs, generate from the root `Cargo.lock` which covers all members. ## Build vs Runtime Dependencies Cargo distinguishes between dependency types: ```toml [dependencies] serde = "1.0" # Runtime dependency [dev-dependencies] mockall = "0.12" # Test-only dependency [build-dependencies] cc = "1.0" # Build script dependency ``` **SBOM considerations:** - `[dependencies]` - Should always be in your SBOM - `[dev-dependencies]` - Usually excluded from production SBOMs - `[build-dependencies]` - Consider including if build-time supply chain matters ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Rust, sbomify uses **cargo-cyclonedx** under the hood, because Cargo resolves a Rust project more accurately than a generic scanner can. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: Cargo.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-rust-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: Cargo.lock OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **cargo-sbom (Rust-native):** ```bash cargo install cargo-sbom cargo sbom > sbom.cdx.json ``` **cargo-cyclonedx:** ```bash cargo install cargo-cyclonedx cargo cyclonedx --format json > sbom.cdx.json ``` **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t rust -o sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: Cargo.lock OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Handling Special Cases ### Git Dependencies Cargo supports dependencies from Git: ```toml [dependencies] my-crate = { git = "https://github.com/example/my-crate", rev = "abc123" } ``` These appear in `Cargo.lock` with Git-specific information: ```toml [[package]] name = "my-crate" version = "0.1.0" source = "git+https://github.com/example/my-crate?rev=abc123#abc123def456" ``` SBOM tools should capture the Git commit hash as the version identifier. ### Path Dependencies Local path dependencies won't have version information from crates.io: ```toml [dependencies] my-local-crate = { path = "../my-local-crate" } ``` These are useful for workspaces but require special handling in SBOMs. ### Features Cargo features affect what code is compiled: ```toml [dependencies] tokio = { version = "1.0", features = ["full"] } serde = { version = "1.0", features = ["derive"], default-features = false } ``` Features can enable additional dependencies, so your SBOM should reflect the features used. ### Vendored Dependencies For offline builds or additional supply chain control: ```bash cargo vendor ``` This creates a `vendor/` directory. Your `.cargo/config.toml`: ```toml [source.crates-io] replace-with = "vendored-sources" [source.vendored-sources] directory = "vendor" ``` ## Best Practices 1. **Always commit Cargo.lock** - Essential for reproducible builds and accurate SBOMs 2. **Use exact versions in production** - Pin versions in `Cargo.toml` for applications 3. **Audit regularly** - Use `cargo audit` alongside SBOM generation 4. **Review dependencies** - Use `cargo deny` for license and security policies 5. **Consider vendoring** - For high-security environments 6. **Document unsafe code** - Note any crates using `unsafe` in your SBOM metadata ## Security Tooling Integration Rust's security ecosystem complements SBOM generation: ```bash # Install cargo-audit cargo install cargo-audit # Check for vulnerabilities cargo audit # Use RustSec advisory database cargo audit --db ./advisory-db ``` Combine `cargo audit` results with your SBOM for comprehensive vulnerability tracking. ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes additional Rust-specific tools like CycloneDX Rust, sbom-rs, and sbom4rust. --- # SBOM Generation Guide for Scala - sbt URL: https://sbomify.com/guides/scala/ Description: Learn how to generate Software Bill of Materials for Scala projects. Complete guide with build.sbt examples, cross-compilation, and dependency management. ## Source vs Build SBOMs Scala's primary build tool, sbt (Scala Build Tool), manages dependencies through `build.sbt`. Unlike some other ecosystems, sbt doesn't use a traditional lockfile by default, which creates challenges for SBOM generation. - **Source SBOMs** are generated from `build.sbt` and resolved dependencies - **Build SBOMs** analyze compiled artifacts in the `target/` directory For accurate SBOMs, you need to resolve dependencies first using sbt plugins. ## Dependency Declaration ### build.sbt Dependencies are declared in `build.sbt`: ```scala name := "my-app" version := "1.0.0" scalaVersion := "3.3.1" libraryDependencies ++= Seq( "org.typelevel" %% "cats-core" % "2.10.0", "io.circe" %% "circe-core" % "0.14.6", "io.circe" %% "circe-generic" % "0.14.6", "io.circe" %% "circe-parser" % "0.14.6", "org.http4s" %% "http4s-ember-server" % "0.23.24", "org.http4s" %% "http4s-circe" % "0.23.24", "org.http4s" %% "http4s-dsl" % "0.23.24", // Test dependencies "org.scalatest" %% "scalatest" % "3.2.17" % Test, "org.scalamock" %% "scalamock" % "5.2.0" % Test ) ``` ### Understanding %% vs % ```scala // %% appends Scala version (cross-compiled) "org.typelevel" %% "cats-core" % "2.10.0" // Resolves to: cats-core_3 or cats-core_2.13 // % uses artifact as-is (Java libraries) "org.postgresql" % "postgresql" % "42.7.0" ``` ## Cross-Compilation Scala libraries are often published for multiple Scala versions: ```scala // project/build.properties sbt.version=1.9.8 // build.sbt crossScalaVersions := Seq("2.13.12", "3.3.1") scalaVersion := "3.3.1" ``` This means dependencies resolve to different artifacts based on Scala version: - `cats-core_2.13` for Scala 2.13 - `cats-core_3` for Scala 3 Your SBOM should reflect the specific Scala version used for your build. ## sbt-dependency-graph Plugin For detailed dependency analysis, use the sbt-dependency-graph plugin: ```scala // project/plugins.sbt addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.10.0-RC1") ``` Generate dependency information: ```bash # ASCII tree sbt dependencyTree # Export to file sbt "dependencyList" > dependencies.txt # Generate DOT graph sbt dependencyDot ``` ## sbt-dependency-lock Plugin For lockfile-based reproducibility: ```scala // project/plugins.sbt addSbtPlugin("io.github.davidgregory084" % "sbt-dependency-lock" % "1.1.0") ``` ```bash # Generate lockfile sbt dependencyLockWrite # Verify against lockfile sbt dependencyLockCheck ``` This creates `build.sbt.lock`: ``` # This file was generated by sbt-dependency-lock org.scala-lang:scala-library:2.13.12 org.typelevel:cats-core_2.13:2.10.0 org.typelevel:cats-kernel_2.13:2.10.0 ``` ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Scala, sbomify uses **cyclonedx-sbt** under the hood. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: build.sbt OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-scala-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: build.sbt OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen (recommended for manual use):** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t sbt -o sbom.cdx.json ``` **sbt-sbom plugin:** ```scala // project/plugins.sbt addSbtPlugin("com.github.sbt" % "sbt-sbom" % "0.4.0") ``` ```bash sbt sbom ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: build.sbt OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Multi-Module Projects Scala projects often have multiple modules: ```scala // build.sbt lazy val root = (project in file(".")) .aggregate(core, api, web) lazy val core = (project in file("core")) .settings( libraryDependencies ++= Seq( "org.typelevel" %% "cats-core" % "2.10.0" ) ) lazy val api = (project in file("api")) .dependsOn(core) .settings( libraryDependencies ++= Seq( "io.circe" %% "circe-core" % "0.14.6" ) ) lazy val web = (project in file("web")) .dependsOn(api) .settings( libraryDependencies ++= Seq( "org.http4s" %% "http4s-ember-server" % "0.23.24" ) ) ``` Generate SBOMs per module or aggregate: ```bash # All modules sbt dependencyTree # Specific module sbt "project api" dependencyTree ``` ## Handling Special Cases ### Resolvers and Private Repositories ```scala resolvers ++= Seq( "Sonatype Releases" at "https://oss.sonatype.org/content/repositories/releases/", "Private Repo" at "https://repo.example.com/maven2" ) credentials += Credentials(Path.userHome / ".sbt" / ".credentials") ``` ### Exclusions and Overrides ```scala libraryDependencies ++= Seq( "org.example" %% "library" % "1.0.0" exclude("commons-logging", "commons-logging") ) // Force specific version dependencyOverrides += "com.google.guava" % "guava" % "32.1.3-jre" ``` ### Provided Dependencies ```scala libraryDependencies ++= Seq( "javax.servlet" % "javax.servlet-api" % "4.0.1" % Provided ) ``` Provided dependencies should be documented but noted as provided by the runtime environment. ### Compile-time Only ```scala libraryDependencies ++= Seq( "org.wartremover" %% "wartremover" % "3.1.6" % "compile->compile" ) ``` ## Best Practices 1. **Use dependency locking** - Install sbt-dependency-lock for reproducibility 2. **Pin Scala version** - Be explicit about scalaVersion 3. **Document cross-compilation** - Note which Scala version your SBOM represents 4. **Resolve before generating** - Run `sbt update` before SBOM generation 5. **Separate test dependencies** - Use `% Test` scope appropriately 6. **Check for updates** - Use `sbt dependencyUpdates` with sbt-updates plugin ## Security Scanning Use sbt-dependency-check for vulnerability scanning: ```scala // project/plugins.sbt addSbtPlugin("net.vonbuchholtz" % "sbt-dependency-check" % "5.1.0") ``` ```bash # Run vulnerability check sbt dependencyCheck # Generate report sbt dependencyCheckReport ``` Combine with SBOM generation: ```yaml - name: Security check run: sbt dependencyCheck - name: Generate SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'build.sbt' OUTPUT_FILE: 'sbom.cdx.json' ``` ## Mill Build Tool For projects using Mill instead of sbt: ```scala // build.sc import mill._ import mill.scalalib._ object myapp extends ScalaModule { def scalaVersion = "3.3.1" def ivyDeps = Agg( ivy"org.typelevel::cats-core:2.10.0", ivy"io.circe::circe-core:0.14.6" ) } ``` Mill has different tooling but similar SBOM approaches: ```bash mill show myapp.ivyDepsTree ``` ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes general SBOM utilities for generation, distribution, and analysis. --- # SBOM Generation Guide for Swift - Swift Package Manager URL: https://sbomify.com/guides/swift/ Description: Learn how to generate Software Bill of Materials for Swift projects. Complete guide with Package.resolved examples, Xcode integration, and CycloneDX output. ## Source vs Build SBOMs Swift Package Manager (SPM) is Apple's official dependency manager for Swift projects. It provides good lockfile support through `Package.resolved`. - **Source SBOMs** are generated from `Package.resolved` - **Build SBOMs** can be generated from the built `.build` directory For most Swift projects, generating from `Package.resolved` is preferred because it contains exact resolved versions with Git references. ## Lockfile Deep Dive ### Package.swift (Manifest) The `Package.swift` file declares your dependencies: ```swift // swift-tools-version: 5.9 import PackageDescription let package = Package( name: "MyApp", platforms: [ .macOS(.v14), .iOS(.v17) ], dependencies: [ .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.8.0"), .package(url: "https://github.com/apple/swift-argument-parser.git", from: "1.3.0"), .package(url: "https://github.com/vapor/vapor.git", from: "4.90.0") ], targets: [ .executableTarget( name: "MyApp", dependencies: [ "Alamofire", .product(name: "ArgumentParser", package: "swift-argument-parser"), .product(name: "Vapor", package: "vapor") ] ) ] ) ``` ### Package.resolved (Lockfile) The `Package.resolved` file contains resolved dependencies: ```json { "pins" : [ { "identity" : "alamofire", "kind" : "remoteSourceControl", "location" : "https://github.com/Alamofire/Alamofire.git", "state" : { "revision" : "f455c2975872ccd2d9c81594c658af65716e9b9a", "version" : "5.8.1" } }, { "identity" : "swift-argument-parser", "kind" : "remoteSourceControl", "location" : "https://github.com/apple/swift-argument-parser.git", "state" : { "revision" : "c8ed701c513cf5c02baf09b3c5eb3e4a7e7920ca", "version" : "1.3.0" } }, { "identity" : "vapor", "kind" : "remoteSourceControl", "location" : "https://github.com/vapor/vapor.git", "state" : { "revision" : "abc123...", "version" : "4.90.0" } } ], "version" : 2 } ``` Key information: - **identity**: Package identifier (lowercase) - **location**: Git repository URL - **revision**: Exact Git commit hash - **version**: Semantic version tag ### Xcode Project Location In Xcode projects, `Package.resolved` is typically located at: - **SPM projects**: Root directory - **Xcode projects**: `MyProject.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved` - **Xcode workspaces**: `MyWorkspace.xcworkspace/xcshareddata/swiftpm/Package.resolved` ## Xcode Integration ### Adding Package.resolved to Version Control For reproducible builds, commit `Package.resolved`: ```bash # For Xcode projects git add MyProject.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved # For SPM projects git add Package.resolved ``` ### Resolving Dependencies ```bash # Resolve and update Package.resolved swift package resolve # Update to latest versions within constraints swift package update ``` ## Binary Dependencies and XCFrameworks Swift packages can include binary dependencies: ```swift .binaryTarget( name: "MyFramework", url: "https://example.com/MyFramework-1.0.0.xcframework.zip", checksum: "abc123..." ) ``` Or local XCFrameworks: ```swift .binaryTarget( name: "MyFramework", path: "Frameworks/MyFramework.xcframework" ) ``` **SBOM considerations:** - Binary targets have checksums but limited metadata - Local XCFrameworks need manual documentation - Consider using `ADDITIONAL_PACKAGES` for binary dependencies ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Swift, sbomify uses **Syft** under the hood. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: Package.resolved OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-swift-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: Package.resolved OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` For Xcode projects, use the full path to `Package.resolved`: ```yaml LOCK_FILE: MyProject.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **cdxgen:** ```bash npm install -g @cyclonedx/cdxgen cdxgen -t swift -o sbom.cdx.json ``` **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` When using these tools directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: Package.resolved OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## iOS/macOS App Considerations ### CocoaPods Integration If your project also uses CocoaPods: ```yaml - name: Generate Swift SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'Package.resolved' OUTPUT_FILE: 'swift-sbom.cdx.json' - name: Generate CocoaPods SBOM run: | # CocoaPods lockfile is Podfile.lock cdxgen -t cocoapods -o pods-sbom.cdx.json ``` ### Carthage Integration For projects using Carthage: ```bash # Carthage resolved file cat Cartfile.resolved ``` Generate separate SBOMs and merge them. ### System Frameworks Apple system frameworks (UIKit, Foundation, etc.) are typically not included in SBOMs as they're part of the OS. However, you may want to document the minimum deployment target: ```yaml env: ADDITIONAL_PACKAGES: "iOS-SDK:17.0,macOS-SDK:14.0" ``` ## Best Practices 1. **Always commit Package.resolved** - Essential for reproducible builds 2. **Use exact version requirements carefully** - `from:` allows minor updates 3. **Pin to specific versions for releases** - Use `.exact()` for critical dependencies 4. **Document binary dependencies** - XCFrameworks need explicit tracking 5. **Run on macOS for accuracy** - Some tools work better with Xcode available 6. **Include platform information** - Document iOS/macOS version requirements ## Version Pinning Strategies ```swift dependencies: [ // Allows 5.8.0 up to next major version .package(url: "...", from: "5.8.0"), // Exact version only .package(url: "...", exact: "5.8.1"), // Version range .package(url: "...", "5.8.0"..<"6.0.0"), // Branch (not recommended for production) .package(url: "...", branch: "main"), // Specific commit .package(url: "...", revision: "abc123...") ] ``` For the most reproducible SBOMs, prefer `exact:` or specific revision pinning in production. ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes general SBOM utilities for generation, distribution, and analysis. --- # SBOM Generation Guide for Terraform - Infrastructure as Code URL: https://sbomify.com/guides/terraform/ Description: Learn how to generate Software Bill of Materials for Terraform projects. Complete guide with .terraform.lock.hcl examples, provider dependencies, and security considerations. ## Why SBOMs for Terraform? Terraform manages infrastructure as code, and its providers are software components with their own supply chain risks: - **Provider supply chain attacks**: Malicious providers could compromise infrastructure - **Compliance requirements**: Track what software manages your infrastructure - **Vulnerability management**: Providers may have security vulnerabilities - **Audit trails**: Document exactly what versions were used for deployments ## Source vs Build SBOMs Terraform's dependency management centers around providers: - **Source SBOMs** are generated from `.terraform.lock.hcl` - **Build SBOMs** can analyze the downloaded providers in `.terraform/providers/` The lockfile approach is preferred as it contains cryptographic hashes for integrity verification. ## Lockfile Deep Dive ### .terraform.lock.hcl The `.terraform.lock.hcl` file is created when you run `terraform init`: ```hcl # This file is maintained automatically by "terraform init". # Manual edits may be lost in future updates. provider "registry.terraform.io/hashicorp/aws" { version = "5.31.0" constraints = "~> 5.0" hashes = [ "h1:abc123...", "zh:def456...", "zh:ghi789...", ] } provider "registry.terraform.io/hashicorp/random" { version = "3.6.0" hashes = [ "h1:xyz123...", "zh:abc456...", ] } provider "registry.terraform.io/hashicorp/kubernetes" { version = "2.25.0" constraints = ">= 2.0.0" hashes = [ "h1:hash123...", ] } ``` Key information: - **provider address**: Full provider path (registry/namespace/name) - **version**: Exact resolved version - **constraints**: Version constraints from configuration - **hashes**: Multiple hash formats for integrity verification ### Provider Version Constraints In your Terraform configuration: ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } kubernetes = { source = "hashicorp/kubernetes" version = ">= 2.0.0, < 3.0.0" } } } ``` ### Hash Formats The lockfile contains multiple hash types: ```hcl hashes = [ "h1:...", # Hash of provider package (zip file) "zh:...", # Hash of provider binary contents ] ``` The `zh:` hashes provide cross-platform verification. ## Provider Versioning and Hashes ### Updating the Lockfile ```bash # Initialize and create/update lockfile terraform init # Upgrade providers within constraints terraform init -upgrade # Add platform-specific hashes terraform providers lock \ -platform=linux_amd64 \ -platform=darwin_amd64 \ -platform=darwin_arm64 ``` ### Multi-Platform Support For teams using different operating systems: ```bash terraform providers lock \ -platform=linux_amd64 \ -platform=linux_arm64 \ -platform=darwin_amd64 \ -platform=darwin_arm64 \ -platform=windows_amd64 ``` This ensures the lockfile has hashes for all platforms. ## Module Dependencies Terraform modules are another type of dependency: ```hcl module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "5.4.0" # ... configuration } module "eks" { source = "terraform-aws-modules/eks/aws" version = "19.21.0" # ... configuration } ``` **Important:** Module versions are tracked in configuration, not in the lockfile. For complete SBOMs, you need to extract module references from your `.tf` files. ## Generating an SBOM SBOM generation is the first step in the [SBOM lifecycle](/features/generate-collaborate-analyze/). After generation, you typically need to enrich your SBOM with package metadata and augment it with your organization's details. ### Using sbomify GitHub Action (Recommended) The [sbomify action](/sbomify-action/) is a swiss army knife for SBOMs that automatically selects the best generation tool for your ecosystem, enriches the output with package metadata, and optionally augments it with your business information – all in one step. It runs on [any CI platform](/sbomify-action/runtimes/), not just GitHub, and the source is [on GitHub](https://github.com/sbomify/sbomify-action/). For Terraform, sbomify uses **Syft** under the hood. **Standalone (no account needed):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: .terraform.lock.hcl OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-terraform-infra COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false ``` Using `github.ref_name` automatically captures your git tag (e.g., `v1.2.3`) as the SBOM version. For rolling releases without tags, use `github.sha` instead. See our [SBOM versioning guide](/guides/how-to-version-sboms/) for best practices. **With sbomify platform (adds augmentation and upload):** ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: my-component-id LOCK_FILE: .terraform.lock.hcl OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true ``` ### Alternative Tools If you prefer to run SBOM generation tools manually: **Syft:** ```bash syft . -o cyclonedx-json=sbom.cdx.json ``` Syft is currently the only widely-available open source tool that supports generating SBOMs from Terraform lockfiles. When using Syft directly, you'll need to handle enrichment and augmentation separately. ### GitLab CI ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action before_script: - terraform init variables: LOCK_FILE: .terraform.lock.hcl OUTPUT_FILE: sbom.cdx.json UPLOAD: "false" ENRICH: "true" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` ## Terraform Cloud/Enterprise For Terraform Cloud workspaces: ```yaml jobs: sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 with: cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }} - name: Initialize run: terraform init - name: Generate SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: '.terraform.lock.hcl' OUTPUT_FILE: 'sbom.cdx.json' ``` ## Supply Chain Security for IaC ### Provider Verification Terraform verifies provider signatures: ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "5.31.0" } } } ``` Providers from the official registry are signed by HashiCorp or the provider maintainer. ### Private Provider Registries For organizations using private registries: ```hcl terraform { required_providers { internal = { source = "registry.example.com/myorg/internal" version = "1.0.0" } } } ``` These providers appear in the lockfile with the custom registry path. ### Mirroring Providers For air-gapped environments: ```bash # Create a provider mirror terraform providers mirror /path/to/mirror # Use the mirror # In .terraformrc or terraform.rc: provider_installation { filesystem_mirror { path = "/path/to/mirror" include = ["registry.terraform.io/*/*"] } } ``` Document mirrored providers in your SBOM metadata. ## Handling Modules in SBOMs Since modules aren't in the lockfile, extract them separately: ```bash # List modules terraform providers # Or parse from configuration grep -r "source\s*=" *.tf | grep "module" ``` Add module information using `ADDITIONAL_PACKAGES`: ```yaml env: ADDITIONAL_PACKAGES: "terraform-aws-modules/vpc/aws:5.4.0,terraform-aws-modules/eks/aws:19.21.0" ``` ## Complete Terraform SBOM Workflow ```yaml --- name: Complete Terraform SBOM on: push: branches: [main] jobs: sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 - name: Initialize Terraform run: terraform init - name: Validate configuration run: terraform validate - name: Generate provider SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: '.terraform.lock.hcl' OUTPUT_FILE: 'sbom.cdx.json' ENRICH: true - name: Security scan run: | # Use checkov, tfsec, or similar pip install checkov checkov -d . --output-file checkov-results.json - name: Upload artifacts uses: actions/upload-artifact@v4 with: name: terraform-security path: | sbom.cdx.json checkov-results.json ``` ## Best Practices 1. **Always commit .terraform.lock.hcl** - Essential for reproducible infrastructure 2. **Add multi-platform hashes** - Support all team platforms 3. **Pin provider versions** - Use exact versions in production 4. **Track modules separately** - Document module versions in your SBOM 5. **Use private registries** - Consider mirroring for security-sensitive environments 6. **Combine with security scanning** - Use tools like checkov, tfsec alongside SBOMs ## Security Considerations Terraform providers have elevated privileges: - They create/modify cloud infrastructure - They may store credentials - They make API calls to cloud providers Your SBOM helps track: - Which providers are in use - What versions are deployed - When updates are available - Known vulnerabilities in providers ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes general SBOM utilities for generation, distribution, and analysis. --- # SBOM Generation Guide for Yocto - Embedded Linux URL: https://sbomify.com/guides/yocto/ Description: Learn how to generate Software Bill of Materials for Yocto-based embedded Linux projects. Complete guide covering SPDX 2.2 and SPDX 3.0.1 with bitbake integration. ## Source vs Build SBOMs Yocto is unique among build systems because it builds everything from source. This means Yocto generates true **build SBOMs** that accurately represent every component compiled into your Linux distribution. Unlike application-level SBOMs generated from lockfiles, Yocto's SBOMs capture: - Every package built from source - Complete file-level details including checksums - Licensing information from the OpenEmbedded catalog - Relationships between packages This makes Yocto one of the most comprehensive SBOM solutions available for embedded Linux development. ## Identifying Your Yocto Release Your Yocto release determines which SPDX versions are available. Starting with **scarthgap (Yocto 5.0, LTS)**, you can generate SPDX 3.0.1 documents alongside the existing SPDX 2.2 support. | Release | Default SPDX | bbclass | Output | | ------------------------------- | ------------- | ----------------- | ------------------------------ | | Honister (3.4) to pre-scarthgap | 2.2 | `create-spdx` | Per-package SBOMs + index.json | | Scarthgap (5.0)+ | 2.2 (default) | `create-spdx` | Per-package SBOMs + index.json | | Scarthgap with 3.0 | 3.0.1 | `create-spdx-3.0` | Single consolidated SBOM | **Note:** SBOM support was first introduced in Yocto 3.4 (Honister). Releases before Honister do not have built-in SPDX generation. To check your release and current SPDX version: ```bash # Check your Yocto release grep DISTRO_CODENAME meta-poky/conf/distro/poky.conf ``` ```bash # Check the active SPDX version bitbake -e core-image-base | grep "^SPDX_VERSION=" ``` See the [Yocto scarthgap documentation](https://docs.yoctoproject.org/scarthgap/) for full release details. ## Yocto's Built-in SBOM Generation Yocto has native SBOM support through dedicated bbclasses that generate SPDX format SBOMs automatically during the build process. ### Enabling SBOM Generation #### SPDX 2.2 (Default) SBOM generation is typically enabled by default in modern Yocto releases. If not, add to your `local.conf`: ```bash INHERIT += "create-spdx" ``` #### SPDX 3.0.1 (Scarthgap and Later) To switch to SPDX 3.0.1 on scarthgap or later, update your `local.conf`: ```bash INHERIT:remove = "create-spdx" INHERIT += "create-spdx-3.0" ``` This replaces the default `create-spdx` class with the new `create-spdx-3.0` class, which produces a single consolidated SBOM instead of per-package files. ### Build and Extract SBOMs After running `bitbake` to build your image: ```bash # Build your image bitbake core-image-minimal # Find the SBOM archive in your deploy folder ls tmp/deploy/images/*/ # Look for: [image-name].spdx.tar.zst # Extract the SBOMs mkdir sboms tar --zstd -xvf tmp/deploy/images/*/*.spdx.tar.zst -C sboms/ ``` ### Understanding the Output #### SPDX 2.2 Yocto generates a separate SBOM for each package: ```bash $ ls sboms/ avahi-daemon.spdx.json base-files.spdx.json base-passwd.spdx.json bash.spdx.json busybox.spdx.json ca-certificates.spdx.json index.json ... ``` **Note:** A full Yocto image can contain hundreds or even thousands of packages, each producing its own SBOM file. Be mindful of this when planning storage and tooling around SPDX 2.2 output. The `index.json` file links all individual SBOMs together using SPDX document linking: ```json { "documents": [ { "documentNamespace": "http://spdx.org/spdxdocs/bash-0139ef99-...", "filename": "bash.spdx.json", "sha1": "e9353b8e26447ef425aa740060f57411420c817a" }, ... ] } ``` #### SPDX 3.0.1 With `create-spdx-3.0`, Yocto produces a single consolidated SBOM containing all packages in one document. There is no `index.json` – everything is in a single file: ```bash $ ls sboms/ core-image-minimal.spdx.json ``` This is a significant simplification over the per-package approach in SPDX 2.2. **Note:** Because everything is consolidated into a single file, SPDX 3.0.1 output is large. A `core-image-minimal` build produces roughly 260 MB of uncompressed JSON-LD. Keep this in mind when choosing tools and storage, as some may struggle with files of this size. ## SBOM Structure ### SPDX 2.2 Each package SBOM includes detailed metadata: ```json { "SPDXID": "SPDXRef-DOCUMENT", "creationInfo": { "created": "2025-02-18T21:58:47Z", "creators": [ "Tool: OpenEmbedded Core create-spdx.bbclass", "Organization: OpenEmbedded ()" ], "licenseListVersion": "3.14" }, "dataLicense": "CC0-1.0", "documentNamespace": "http://spdx.org/spdxdocs/bash-...", "files": [ { "SPDXID": "SPDXRef-PackagedFile-bash-1", "checksums": [ {"algorithm": "SHA1", "checksumValue": "..."}, {"algorithm": "SHA256", "checksumValue": "..."} ], "fileName": "usr/bin/bash.bash", "fileTypes": ["BINARY"] } ] } ``` ### SPDX 3.0.1 SPDX 3.0.1 uses a different top-level structure with a `@graph` array containing all elements in a single document: ```json { "@context": "https://spdx.org/rdf/3.0.1/spdx-context.jsonld", "@graph": [ { "type": "SpdxDocument", "spdxId": "SPDXRef-DOCUMENT", "creationInfo": { "created": "2025-02-18T21:58:47Z", "createdBy": ["Tool: OpenEmbedded Core create-spdx-3.0.bbclass"], "specVersion": "3.0.1" } }, { "type": "software_Package", "spdxId": "SPDXRef-Package-bash", "name": "bash", "software_packageVersion": "5.2.21" } ] } ``` All packages, files, and relationships are consolidated into the single `@graph` array instead of being spread across separate documents. ## CI/CD Integration The SBOM output format depends on your SPDX version. SPDX 2.2 produces a `.spdx.tar.zst` archive containing per-package SBOMs. SPDX 3.0.1 produces a single `.spdx.json` file. Both are written to `tmp/deploy/images/MACHINE/`. #### SPDX 2.2 ```yaml # GitHub Actions example - name: Build Yocto image run: | source oe-init-build-env bitbake core-image-minimal - name: Upload SBOMs uses: actions/upload-artifact@v4 with: name: yocto-sboms path: tmp/deploy/images/*/*.spdx.tar.zst ``` #### SPDX 3.0.1 ```yaml # GitHub Actions example - name: Build Yocto image run: | source oe-init-build-env bitbake core-image-minimal - name: Upload SBOMs uses: actions/upload-artifact@v4 with: name: yocto-sboms path: tmp/deploy/images/*/*.spdx.json ``` ## Release Management with sbomify You've generated your SBOMs. Now what? Regulations like the [EU Cyber Resilience Act](/compliance/eu-cra/) require manufacturers to tag SBOMs to specific product releases and retain them for up to 5 years. This means you need a system for release management and long-term storage, not just generation. [sbomify-action](/sbomify-action/) has built-in Yocto support that handles this. It detects the SPDX version automatically, uploads SBOMs, and creates tagged releases. It works in CI/CD pipelines or standalone. ### SPDX 2.2 (tar.zst archive) Point sbomify-action at the `.spdx.tar.zst` archive directly, no need to extract it first: ```bash sbomify-action --token $SBOMIFY_TOKEN \ --augment --enrich \ yocto tmp/deploy/images/qemux86-64/core-image-base.rootfs.spdx.tar.zst \ --release "my-product:1.0.0" ``` ### SPDX 3.0.1 (single JSON file) For SPDX 3.0.1, point it at the consolidated `.spdx.json` file. Since this is a single document, you also need to specify a `--component-id` to map it to a component in sbomify: ```bash sbomify-action --token $SBOMIFY_TOKEN \ --augment --enrich \ yocto tmp/deploy/images/qemux86-64/core-image-minimal.spdx.json \ --component-id "my-component-id" \ --release "my-product:1.0.0" ``` ### What happens under the hood - **SPDX 2.2:** sbomify-action extracts the archive, uploads each per-package SBOM, and creates a release tagging them all together. - **SPDX 3.0.1:** sbomify-action uploads the single consolidated SBOM and creates a release. In both cases, the release in sbomify ties the SBOMs to a specific product version, giving you a complete audit trail. ### Enriching your SBOMs You can pass `--augment` and `--enrich` flags to enhance your SBOMs with additional metadata. If you've configured an augmentation profile in sbomify, metadata from the profile is automatically merged during upload. See [How do I achieve NTIA/CISA compliance?](/faq/how-do-i-achieve-ntia-cisa-compliance/) for details on setting up profiles. Got questions? [Get in touch](https://app.sbomify.com/enterprise-contact/). ## Best Practices 1. **Enable SBOM generation by default** - Add `create-spdx` (or `create-spdx-3.0` on scarthgap+) to your distro configuration 2. **Prefer SPDX 3.0.1 on scarthgap and later** - The consolidated output simplifies distribution and eliminates the need for merging 3. **Archive SBOMs with releases** - Store SBOMs alongside your image artifacts 4. **Consider hierarchy** - Use sbomify's [hierarchy support](/features/sbom-hierarchy/) to organize per-package SBOMs, especially with SPDX 2.2 5. **Track package updates** - Map components to track changes across releases 6. **[Sign your SBOMs](/faq/how-do-i-sign-an-sbom/)** - Add cryptographic signatures for authenticity ## Limitations - **SPDX only** - Yocto generates SPDX format only (no native CycloneDX) - **Per-package SBOMs (SPDX 2.2)** - May need merging for simpler distribution (resolved in SPDX 3.0.1) - **No runtime dependencies** - Only captures build-time components - **Large SPDX 3.0.1 documents** - The consolidated single-file output can reach 260 MB or more for full images, which may cause issues with some tools and storage systems - **SPDX 3.0 tooling maturity** - Some downstream tools may not yet fully support SPDX 3.0.1; verify your toolchain before switching ## Frequently Asked Questions ### What is the difference between SPDX 2.2 and SPDX 3.0? SPDX 2.2 uses a flat JSON structure where tools like Yocto generate a separate `.spdx.json` file per package, linked together by an `index.json` and bundled in a `.spdx.tar.zst` archive. SPDX 3.0 replaces this with a graph-based JSON-LD model using a single `@graph` array, consolidating everything into one file. SPDX 3.0 also introduces a profile system that extends the spec beyond software to cover security, build information, and AI/ML metadata. The trade-off is file size: a single SPDX 3.0.1 document can exceed 260 MB for a full Yocto image, and tooling support is still maturing. If your build system supports SPDX 3.0 (Yocto scarthgap or later), it simplifies distribution by producing a single file instead of hundreds. If downstream tooling compatibility is a concern, SPDX 2.2 remains a safe choice. See [Exploring the New SPDX 3.0](/2024/04/28/exploring-the-new-spdx-3-0-a-game-changer-for-sboms/) for more details. ### Can I use CycloneDX with Yocto? No. Yocto only supports SPDX format natively and there is no built-in CycloneDX generation. Converting SPDX output to CycloneDX is not recommended either, as the two formats have different data models and conversion inevitably loses context. See [Can I convert between CycloneDX and SPDX?](/faq/can-i-convert-between-cyclonedx-and-spdx/) for a detailed explanation of why format conversion is problematic. ## Further Reading Related blog posts: - [Mastering SBOM Generation with Yocto](/2025/02/21/mastering-sbom-generation-with-yocto/) - Deep dive into Yocto's SPDX generation and quality analysis - [Exploring the New SPDX 3.0](/2024/04/28/exploring-the-new-spdx-3-0-a-game-changer-for-sboms/) - Overview of what SPDX 3.0 brings to the table - [What's New in SPDX 3: Enhanced Referencing](/2024/07/22/whats-new-in-spdx-3-enhanced-referencing-capabilities/) - Deep dive into SPDX 3.0 referencing capabilities Additional resources: - [Yocto scarthgap documentation](https://docs.yoctoproject.org/scarthgap/) ## Further Resources For more SBOM tools and resources, see our [SBOM Resources](/resources/) page, which includes tools for SBOM generation, distribution, and analysis. --- # SBOM Generation in CI/CD Pipelines URL: https://sbomify.com/guides/ci-cd/ Description: Why SBOMs belong in your build pipeline, what to generate on every commit versus every release, and where to find setup instructions for your CI platform. ## Why build time An SBOM describes what went into a build. The only moment that information is complete and unambiguous is **while the build is happening** - when the lockfile, the resolved dependency tree, the commit SHA and the build environment all exist together. Afterwards you are reconstructing. Scanning a released artifact tells you what can be detected from the outside, which is not the same as what went in: vendored code, statically linked libraries and files copied between Docker build stages are routinely invisible to an external scan. Generating in CI gives you five things: 1. **Consistency** - every build produces an SBOM the same way, with the same tools. 2. **Automation** - no manual step anyone can forget before a release. 3. **Attestation** - the SBOM can be signed where it was made, tied to the pipeline run and commit that produced it. 4. **Compliance** - obligations under the [EU CRA](/compliance/eu-cra/), [EO 14028](/compliance/eo-14028/) and [FDA guidance](/compliance/fda-medical-device/) are met continuously rather than scrambled for at audit time. 5. **Traceability** - a complete path from source commit to deployed artifact. ## Signing at origin The reason build-time generation matters so much is that it is the only point at which you can sign the SBOM as the party that actually produced it. A signature made in your pipeline binds the document to a specific commit and a specific build. Anyone can verify it later without trusting the platform that stored it. That property only holds if nothing modifies the artifact afterwards - which is why sbomify [never alters an SBOM you upload](/sbomify-action/why/#the-part-most-platforms-get-wrong). See [how to sign an SBOM](/faq/how-do-i-sign-an-sbom/). ## What to generate, and when | Trigger | What to do | Why | | ------------------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------- | | Every commit on the main branch | Generate, do not upload | Catches breakage early, costs nothing | | Pull requests | Generate, do not upload | Verifies the pipeline still works; CI secrets are usually unavailable to forks anyway | | Tagged releases | Generate, upload, tag a product release | This is the artifact customers and auditors will ask for | | Container builds | Generate from the image, not the lockfile | Captures OS packages as well as application dependencies | For what to put in the version field, see [how to version SBOMs](/guides/how-to-version-sboms/). ## Set it up The [sbomify action](/sbomify-action/) is a CLI shipped as a container image. It selects the right generator for your ecosystem, adds your business metadata, and enriches every component from package registries - in one step. Configuration is environment variables, and they are identical on every platform. Pick your runtime: - [GitHub Actions](/sbomify-action/runtimes/github-actions/) - native action, OIDC trusted publishing, attestation - [GitLab CI](/sbomify-action/runtimes/gitlab-ci/) - container image, automatic VCS detection - [Bitbucket Pipelines](/sbomify-action/runtimes/bitbucket/) - container image via a Docker pipe - [Jenkins](/sbomify-action/runtimes/jenkins/) - declarative and scripted pipelines - [CircleCI](/sbomify-action/runtimes/circleci/) - container executor - [Travis CI](/sbomify-action/runtimes/travis/) - `docker run` from the job - [Azure DevOps](/sbomify-action/runtimes/azure-devops/) - container job or Docker task - [TeamCity](/sbomify-action/runtimes/teamcity/) - Docker Wrapper build feature - [Any container runner](/sbomify-action/runtimes/docker/) - Drone, Woodpecker, Buildkite, Concourse - [Your local machine](/sbomify-action/runtimes/local/) - `uvx`, `pipx` or Docker If your platform can run a container, it is supported even without a dedicated page. ## Good practice - **Do not fail the build on SBOM generation errors** while you are still rolling this out. Once it is stable, do - a missing SBOM should be as loud as a failing test. - **Store SBOMs as build artifacts** as well as uploading them, so they are available even if an upload fails. - **Cache the license database.** It avoids re-downloading 20-50 MB on every run and reduces exposure to [rate limits](/sbomify-action/enrichment/#license-database-rate-limits). - **Set `GITHUB_TOKEN`** whatever platform you are on. License databases come from GitHub Releases, and unauthenticated requests are throttled hard enough that enrichment quietly degrades. - **Prefer short-lived credentials.** On GitHub Actions, [OIDC trusted publishing](/sbomify-action/publishing/#oidc-trusted-publishing) removes the long-lived token entirely. - **Keep the audit trail.** `audit_trail.txt` records every change the pipeline made and where it came from - archive it next to the SBOM. ## Related reading - [Why SBOM quality matters](/sbomify-action/why/) - scanners versus pipelines, and chain of custody - [Language and platform guides](/guides/) - ecosystem-specific instructions - [SBOM generation tools compared](/2026/01/26/sbom-generation-tools-comparison/) - [GitHub Action with attestation](/2024/10/31/github-action-update-and-attestation/) - [SBOM resources](/resources/) - the wider tooling landscape --- # sbomify Action: Generate Compliance-Grade SBOMs in Any CI Pipeline URL: https://sbomify.com/sbomify-action/ Description: Complete documentation for the sbomify action - a CLI shipped as a container that generates, augments and enriches SBOMs in GitHub Actions, GitLab CI, Bitbucket, Jenkins, CircleCI and any other pipeline. ## What this is `sbomify-action` is a **command-line tool shipped as a container image**. Point it at a lockfile, a Docker image or an existing SBOM, and it produces a complete, standards-ready SBOM in CycloneDX or SPDX format. It ships as a GitHub Action, a container image and a Python package - but those are just delivery vehicles. The tool, its configuration and its behaviour are **identical on every runtime**. On anything other than GitHub Actions you pull the same container image and set the same environment variables. Learn it once, run it anywhere. You do not need a sbomify account to use it. Generation, augmentation and enrichment all work standalone. ## Why not just run Trivy? Because a scanner and an SBOM pipeline are different things. A generator's job is **detection**. Trivy, Syft and cdxgen are all good at answering "what packages are in here?" - and they answer it with a name, a version and a PURL. Almost everything else is left empty: no supplier, no license, no description, no hashes. That is not a criticism of those tools; it is what they are built to do. The problem is that the fields they leave empty are exactly the fields [NTIA](/compliance/ntia-minimum-elements/), [CISA](/compliance/cisa-minimum-elements/) and the [EU CRA](/compliance/eu-cra/) actually ask for. A raw scan is a dependency list. Compliance needs an SBOM. `sbomify-action` wraps generation in three more steps:
The difference is measurable. On the seven fields the NTIA Minimum Elements require, a bare scanner typically populates a small fraction; the same SBOM after augmentation and enrichment populates all of them. See [how it works](/sbomify-action/how-it-works/) for the full pipeline, or our [comparison of SBOM generation tools](/2026/01/26/sbom-generation-tools-comparison/) for a look at the generators themselves. ## Generated in CI. Never touched again. This is the part that matters most, and it is worth being precise about. Everything `sbomify-action` does happens **inside your pipeline, at build time** - the one moment when the full build context actually exists. Every modification it makes is written to an [audit trail](/sbomify-action/advanced/#audit-trail) with UTC timestamps, so you can see exactly what was added and where it came from. You can then sign or attest the result **at origin**, before it goes anywhere. **sbomify never modifies an artifact you upload.** The bytes that arrive are the bytes that are stored and later served. No server-side enrichment, no normalisation, no "improvement". That is a deliberate design decision, and it exists to close a specific gap. If a platform rewrites your SBOM after ingestion, you have no way to audit what changed. Removing a vulnerable component and tidying up metadata are the same operation from the outside: a write you cannot inspect. At that point "this SBOM has no known vulnerabilities" stops being something you can verify and becomes something you have to take on faith - and an inconvenient CVE disappearing looks exactly like housekeeping. Signing at origin collapses that ambiguity. Either the bytes still match what your pipeline produced and signed, or they do not. Anyone can check, including an auditor who does not trust either of us. It also has a practical consequence: because the artifact is never altered, **the signature stays valid**. Platforms that modify after ingestion either invalidate your signature or re-sign with their own key - which breaks the chain of custody and moves the trust anchor from you to them. > **One clarification, so this is not overstated.** This guarantee covers artifacts you _upload_. sbomify does create genuinely new artifacts on your behalf - aggregate product-level SBOMs, VEX and VDR documents, derived compliance reports. Those are new creations, clearly distinguished from your uploads, not edits to them. If you distribute them with the same guarantees, sign them yourself. Related: [how to sign an SBOM](/faq/how-do-i-sign-an-sbom/) and [OIDC trusted publishing](/faq/how-do-i-set-up-oidc-trusted-publishing/). ## Runtime support The core tool behaves identically everywhere. What differs is how you invoke it, how you authenticate, and how much the runtime tells it about your build. | Runtime | Integration | Auth | VCS auto-detect | Wizard | Attestation | | ---------------------------------------------------------- | --------------- | ------------- | --------------- | ------------------ | ----------- | | [GitHub Actions](/sbomify-action/runtimes/github-actions/) | Native action | OIDC or token | Yes | Generates workflow | Yes | | [GitLab CI](/sbomify-action/runtimes/gitlab-ci/) | Container image | Token | Yes | No | No | | [Bitbucket](/sbomify-action/runtimes/bitbucket/) | Container image | Token | Yes | No | No | | [Jenkins](/sbomify-action/runtimes/jenkins/) | Container image | Token | Yes | No | No | | [CircleCI](/sbomify-action/runtimes/circleci/) | Container image | Token | Yes | No | No | | [Travis CI](/sbomify-action/runtimes/travis/) | Container image | Token | Vendor + git | No | No | | [Azure DevOps](/sbomify-action/runtimes/azure-devops/) | Container image | Token | From git | No | No | | [Any container runner](/sbomify-action/runtimes/docker/) | Container image | Token | From git | No | No | | [TeamCity](/sbomify-action/runtimes/teamcity/) | Container image | Token | Git roots | No | No | | [Local machine](/sbomify-action/runtimes/local/) | `uvx` or `pipx` | Token | Opt-in | Yes | No | **Yes** means the runtime publishes repository URL, commit SHA and ref as environment variables and they are read from there. **From git** means it does not, so the action reads the checkout it is running in - no configuration either way, as long as the `.git` directory is present and the repository has a remote. Jenkins and CircleCI do both: the vendor's variables first, the checkout when a job publishes none, which is a job on [Subversion or Perforce](/sbomify-action/runtimes/jenkins/#falling-back-to-the-checkout) or one that [never ran `checkout`](/sbomify-action/runtimes/circleci/#falling-back-to-the-checkout). **Vendor + git** means Travis CI, which publishes the commit and the branch a build was triggered for but no repository URL - only an `owner/repo` slug with no host attached, and Travis serves several forges. The commit and ref come from the job, the URL from the checkout, and no URL is guessed from the slug. See [Travis CI](/sbomify-action/runtimes/travis/#vcs-information). **Git roots** means TeamCity, which is VCS-agnostic: detection runs only when the repository URL positively identifies Git, and stays silent otherwise rather than recording a Subversion revision as if it were a commit. See [TeamCity](/sbomify-action/runtimes/teamcity/#vcs-information). **Opt-in** means a local run reads the checkout only when you set `SBOMIFY_LOCAL_VCS=true`, so an internal remote does not end up in a document by accident. `vcs_url`, `vcs_commit_sha` and `vcs_ref` in [`sbomify.json`](/sbomify-action/augmentation/) override whatever is detected, on every runtime. OIDC trusted publishing and build provenance attestation are GitHub-only today because they depend on GitHub-issued identity tokens. Support for other runtimes will follow as those platforms expose equivalent primitives. ## Documentation **Start here** - [Quick start](/sbomify-action/quickstart/) - the setup wizard, and your first pipeline run - [Why SBOM quality matters](/sbomify-action/why/) - the long-form case, and how the output maps to NTIA, CISA and CRA - [How it works](/sbomify-action/how-it-works/) - the full pipeline, step by step **Reference** - [Configuration](/sbomify-action/configuration/) - every input, environment variable and CLI flag - [Input sources](/sbomify-action/sources/) - lockfiles, container images, Yocto, additional packages - [Augmentation](/sbomify-action/augmentation/) - your business metadata via `sbomify.json` - [Enrichment](/sbomify-action/enrichment/) - registry metadata, license databases, lifecycle data, hashes - [Publishing](/sbomify-action/publishing/) - uploading, releases, Dependency Track - [Advanced](/sbomify-action/advanced/) - attestation, audit trail, caching, telemetry, troubleshooting **Per-runtime guides** - [All runtimes](/sbomify-action/runtimes/) - pick your CI platform ## Where the code lives | Channel | Location | | ------------------------ | --------------------------------------------------------------------- | | Source and GitHub Action | [`sbomify/sbomify-action`](https://github.com/sbomify/sbomify-action) | | Container image | `ghcr.io/sbomify/sbomify-action` | | Python package | [`sbomify-action`](https://pypi.org/project/sbomify-action/) | There is one source repository and one image. Every runtime other than GitHub Actions pulls that image directly - there is no separate integration to install or keep in sync. The project is Apache-2.0 licensed. Security issues go to . --- # Advanced Usage: Attestation, Audit Trail, Caching and Troubleshooting URL: https://sbomify.com/sbomify-action/advanced/ Description: Attestation and signing, the SBOM audit trail, cache configuration, monorepo layouts, telemetry, version pinning and troubleshooting for the sbomify action. ## Attestation The action does not sign SBOMs itself. It produces a file, and you attest that file with your platform's provenance tooling - which keeps signing under your control and your identity, rather than a vendor's. On GitHub Actions: ```yaml permissions: contents: read id-token: write attestations: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: sbomify/sbomify-action@master env: LOCK_FILE: Cargo.lock OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false - uses: actions/attest-build-provenance@v4 with: subject-path: sbom.cdx.json ``` You can also attest the build artifact itself and attach the SBOM to it, with [`actions/attest-sbom`](https://github.com/actions/attest-sbom), passing your build output as `subject-path` and the generated SBOM as `sbom-path`. ### Where attestation is available `actions/attest-build-provenance` is not available everywhere, and the failure mode is a broken build rather than a graceful skip. Check before you add it: | Repository | Availability | | -------------------------------------------- | ----------------- | | Public repository, any plan | Works | | Private or internal, GitHub Enterprise Cloud | Works | | Private or internal, Free, Pro or Team | **Not available** | | Any repository on GitHub Enterprise Server | **Not available** | If your repository falls into one of the unsupported rows, either gate the step on repository visibility or sign with [cosign](/faq/how-do-i-sign-an-sbom/) instead, which has no such restriction. ### Why sign in CI Signing at build time binds the SBOM to the pipeline run and the source commit that produced it. Since [sbomify never modifies uploaded artifacts](/sbomify-action/why/#the-part-most-platforms-get-wrong), that signature keeps validating for as long as the document exists - anyone can verify it independently, without trusting sbomify. See [how to sign an SBOM](/faq/how-do-i-sign-an-sbom/) and [working with signature files](/faq/how-do-i-use-signature-files/). ## Audit trail Every modification the pipeline makes is recorded. This is what turns "we generated an SBOM" into something you can hand to an auditor. Three outputs: **A summary table**, always printed: ```text ┌─────────────────────┬───────┐ │ Metric │ Value │ ├─────────────────────┼───────┤ │ Overrides applied │ 3 │ │ Components enriched │ 42 │ │ Sanitization fixes │ 5 │ └─────────────────────┴───────┘ ``` **`audit_trail.txt`**, written next to your SBOM: ```text # SBOM Audit Trail # Generated: 2026-01-18T12:34:56Z # Input: requirements.txt # Output: sbom.cdx.json ## Override [2026-01-18T12:34:56Z] OVERRIDE component.version SET "2.0.0" (source: cli/env) [2026-01-18T12:34:56Z] OVERRIDE component.name MODIFIED "old-name" -> "my-app" (source: cli/env) ## Enrichment [2026-01-18T12:34:57Z] ENRICHMENT pkg:pypi/requests@2.31.0 license ADDED (source: pypi) [2026-01-18T12:34:57Z] ENRICHMENT pkg:pypi/requests@2.31.0 description ADDED (source: pypi) ``` **A collapsible group** in GitHub Actions logs containing the full trail. Four categories are tracked: overrides from the CLI or environment, augmentation values and their source, per-component enrichment additions, and sanitization fixes such as PURL normalisation. Timestamps are UTC, ISO 8601. File paths in the trail are recorded relative to the working directory, and anything outside it is reduced to its file name. The trail is meant to be handed to someone who did not run the build, and the absolute path of your lock file tells them nothing while publishing the build machine's directory layout and username. Archive `audit_trail.txt` alongside your SBOM. Together they answer "where did every field in this document come from?" - which is the question that actually gets asked in an audit. ## Caching Two caches are worth persisting: the license databases, at roughly 20-50 MB, and Syft's package metadata cache. **GitHub Actions** ```yaml - uses: actions/cache@v6 with: path: .sbomify-cache key: sbomify-${{ runner.os }} - uses: sbomify/sbomify-action@master env: SBOMIFY_CACHE_DIR: ${{ github.workspace }}/.sbomify-cache SYFT_CACHE_DIR: ${{ github.workspace }}/.sbomify-cache/syft LOCK_FILE: requirements.txt ENRICH: true UPLOAD: false ``` **GitLab CI** ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action cache: key: sbomify-cache paths: - .sbomify-cache/ variables: SBOMIFY_CACHE_DIR: "${CI_PROJECT_DIR}/.sbomify-cache/sbomify" SYFT_CACHE_DIR: "${CI_PROJECT_DIR}/.sbomify-cache/syft" LOCK_FILE: poetry.lock ENRICH: "true" UPLOAD: "false" script: - sbomify-action ``` **Plain Docker** - use a named volume: ```bash docker volume create sbomify-cache docker run --rm \ -v "$(pwd):/workspace" \ -v sbomify-cache:/cache \ -e SBOMIFY_CACHE_DIR=/cache/sbomify \ -e SYFT_CACHE_DIR=/cache/syft \ -e LOCK_FILE=requirements.txt \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` Caching reduces network calls, which also reduces exposure to the [license database rate limit](/sbomify-action/enrichment/#license-database-rate-limits). ## Tool runtimes Only `cyclonedx-py` ships in the image, as a dependency of the CLI itself. Every other generator is fetched: Syft, cdxgen, the JVM toolchain, Go, Rust, PHP, .NET, `crane` and `cosign` are downloaded on first use, verified against a digest pinned at build time, and unpacked into a cache directory. This is why the image is small, why the same tool selection works identically under `uvx`, and why the tool set cannot change without a release - which matters for something whose output is a provenance document. Two things follow that are worth configuring: **Cache the runtimes.** Without a persistent cache every run re-downloads them. Set `SBOMIFY_TOOL_CACHE` to a path your CI restores between builds. If it is unset, the cache falls back to `XDG_CACHE_HOME`, then `$HOME/.cache`, then the temp directory - the last of which does not survive a run. ```yaml env: SBOMIFY_TOOL_CACHE: ${{ github.workspace }}/.sbomify-cache/runtimes ``` **Air-gapped builds need an opt-out.** Set `SBOMIFY_FETCH_RUNTIMES=0` to refuse downloads and use only preinstalled tools. Be deliberate about that flag. Declining to fetch does not leave the tool without an opinion - it silently falls back to whatever generator is already available, which is usually the worse one. A Rust project resolved by Syft instead of `cargo-cyclonedx` is not a neutral outcome, and nothing in the output says so. If you set it, make sure the native generators you care about are installed. Bundles published by sbomify also carry a Sigstore attestation, verified with `cosign` before use. `cosign` itself is digest-pinned only, since verifying it would require it to already be present. ## Monorepos Use the `working-dir` input to point at a subdirectory: ```yaml - uses: sbomify/sbomify-action@master with: working-dir: packages/my-app env: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false ``` > The workflow-level `working-directory:` setting **does not affect this action**, because it runs in a container. Use the `working-dir` input. On other runtimes, set `WORKING_DIR` or change the container's working directory. For several components in one repository, use a matrix: ```yaml jobs: sbom: runs-on: ubuntu-latest strategy: matrix: include: - name: frontend lock_file: frontend/package-lock.json component_id: abc123 - name: backend lock_file: backend/requirements.txt component_id: def456 steps: - uses: actions/checkout@v7 - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: ${{ matrix.component_id }} LOCK_FILE: ${{ matrix.lock_file }} OUTPUT_FILE: sbom-${{ matrix.name }}.cdx.json ENRICH: true ``` Each component gets its own SBOM and its own component ID. See [the SBOM hierarchy](/features/sbom-hierarchy/) for how these roll up into a product. ## Version pinning Three levels, in increasing order of strictness: ```yaml # Pinned to a release tag - readable, and what most projects want - uses: sbomify/sbomify-action@v26.8.0 # Pinned to a commit SHA - immutable, and what we recommend for production - uses: sbomify/sbomify-action@a1b2c3d4e5f6... # Floating - convenient for trying things out, not for production - uses: sbomify/sbomify-action@master ``` A full 40-character commit SHA is the only reference GitHub treats as immutable; tags can be moved. If your threat model includes a compromised upstream action, pin to a SHA. The [setup wizard](/sbomify-action/quickstart/) does this automatically for the workflows it generates. Releases use CalVer, so `v26.8.0` is the eighth release of 2026. ## Telemetry and privacy **Error telemetry is enabled by default.** Unhandled exceptions are reported to Sentry to help find crashes. To disable it: ```yaml env: TELEMETRY: "false" ``` Or pass `--no-telemetry` on the CLI. To send reports to your own Sentry instance instead, set `SENTRY_DSN`. If your organisation restricts outbound connections from build agents, turn this off explicitly rather than relying on the network to block it. ## Troubleshooting **Enrichment added far fewer fields than expected.** Almost always GitHub API rate limiting on the license database download. Set `GITHUB_TOKEN` - see [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). **"No transitive dependencies discovered".** Informational, not an error. The stage inspects the installed environment, so it finds nothing in a clean checkout. Install dependencies before generating if you want it to contribute. **Trusted publishing returns 403.** The trusted publisher binding does not exist on the component yet, or it points at a different repository. Create it under Component, Settings, Trusted Publishing. Also confirm the workflow grants `id-token: write`. **"No generator found for input".** Either the file is not a recognised lockfile, or you asked for a spec version nothing can emit - `SPEC_VERSION=3.0.1` is the usual culprit, since SPDX 3.0.1 can be processed but not generated. **The action ignores my `working-directory`.** Expected. Use the `working-dir` input instead. **Generation fails in CI but works locally.** Usually missing dependencies. Some generators inspect the installed environment rather than only the lockfile, so run your install step first. Confirm the lockfile is committed and the path is right relative to the working directory. **Uploads time out on a large SBOM.** Raise `SBOMIFY_UPLOAD_TIMEOUT` above its 120-second default. **Fork pull requests fail on upload.** CI secrets are generally not exposed to forks. Gate uploads so fork builds run with `UPLOAD: false` and still verify that generation works. ## Reproducibility Enrichment queries live registries, so the same input can produce slightly different output on different days. That is a deliberate trade: richer, more current metadata in exchange for byte-level reproducibility. The audit trail is what makes this manageable. Any given SBOM records exactly what was added and which source provided it, so it remains fully explainable even though a rerun might differ. If you need strict reproducibility, run with `ENRICH: false` and rely on [augmentation](/sbomify-action/augmentation/) plus lockfile hashes, both of which are entirely local. ## Security - Pin to a commit SHA in production. - Grant the smallest set of `permissions:` the job needs. - Store tokens as CI secrets, and prefer [OIDC trusted publishing](/sbomify-action/publishing/#oidc-trusted-publishing) where it is available. - Review generated SBOMs before publishing them. Internal package names, private registry URLs and hostnames can be more revealing than they look. Vulnerabilities in the action itself go to . --- # Augmentation: Adding Your Business Metadata to an SBOM URL: https://sbomify.com/sbomify-action/augmentation/ Description: How to add supplier, author, license, lifecycle and security contact information to your SBOM with sbomify.json, plus automatic VCS detection from your CI environment. ## Augmentation vs. enrichment Two different problems, two different mechanisms: | | Augmentation | Enrichment | | ---------------- | ------------------------------------------ | ------------------------------------ | | Adds | Metadata about **your** software | Metadata about **your dependencies** | | Source | You, via `sbomify.json` or the sbomify API | Public package registries | | Scope | The document and its root component | Every component | | Account required | No | No | | Enable with | `AUGMENT: true` | `ENRICH: true` | Nobody but you knows who supplies your software, when its support window ends, or where to report a vulnerability in it. That is augmentation. What license `requests` uses is public knowledge - that is [enrichment](/sbomify-action/enrichment/). Most projects want both. ## The config file Create `sbomify.json` in your project root and set `AUGMENT: true`. No account needed. ```json { "lifecycle_phase": "build", "supplier": { "name": "My Company", "url": ["https://example.com"], "contacts": [{"name": "Support", "email": "support@example.com"}] }, "authors": [ {"name": "Jane Doe", "email": "jane@example.com"} ], "licenses": ["Apache-2.0"], "security_contact": "https://example.com/.well-known/security.txt", "release_date": "2026-06-15", "support_period_end": "2028-12-31", "end_of_life": "2030-12-31" } ``` ### Field reference | Field | Description | Where it lands | | -------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------- | | `lifecycle_phase` | The context this SBOM was generated in | CycloneDX `metadata.lifecycles[].phase`; SPDX `creationInfo.creatorComment` | | `supplier` | The organisation supplying the component | CycloneDX `metadata.supplier`; SPDX `packages[].supplier` | | `authors` | Who authored the component | CycloneDX `metadata.authors[]`; SPDX `creationInfo.creators[]` | | `licenses` | SPDX license identifiers for your own software | CycloneDX `metadata.licenses[]`; SPDX document licenses | | `security_contact` | Where to report vulnerabilities | CycloneDX `externalReferences[type=security-contact]`; SPDX `externalRefs[category=SECURITY]` | | `release_date` | When this version was released | CycloneDX lifecycle property; SPDX external ref | | `support_period_end` | When security-only support ends | CycloneDX lifecycle property; SPDX `validUntilDate` | | `end_of_life` | When all support ends | CycloneDX lifecycle property; SPDX external ref | | `vcs_url` | Repository URL, overriding CI detection | CycloneDX `externalReferences[type=vcs]`; SPDX `downloadLocation` | | `vcs_commit_sha` | Full commit SHA | Appended to the VCS URL | | `vcs_ref` | Branch or tag name | Added as build context | ### Valid values **`lifecycle_phase`** is one of `design`, `pre-build`, `build`, `post-build`, `operations`, `discovery`, `decommission`. Most CI pipelines want `build`. When the input is a container image, `post-build` is set automatically. **`security_contact`** accepts a [security.txt](https://securitytxt.org/) URL (recommended), a `mailto:` address, or a disclosure procedure URL. **Dates** are ISO-8601, for example `2028-12-31`. The three lifecycle dates mean different things: - `release_date` - when this version became publicly available - `support_period_end` - bugfixes stop, security patches continue - `end_of_life` - no further updates of any kind These map onto [Common Lifecycle Enumeration](/compliance/cle/), and let downstream consumers automatically flag software that is approaching or past end of support. ## Why this matters for compliance The [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) require a supplier name and an author of the SBOM data. The [EU Cyber Resilience Act](/compliance/eu-cra/) expects a documented vulnerability reporting channel and a defined support period. None of that can be inferred from a lockfile - a scanner has no way to know it. Augmentation is how those fields get populated, and it is the difference between an SBOM that passes a procurement review and one that gets sent back. ## Where values come from Sources are consulted in priority order, and **local values always win**: 1. **`sbomify.json`** in your project root. Highest priority. No account required. 2. **The sbomify API**, using metadata configured on your component. Requires `COMPONENT_ID` and credentials. 3. **CI environment detection**, which fills in VCS information automatically. Keeping metadata in `sbomify.json` means it is version-controlled and reviewable alongside your code. Keeping it in sbomify means you can change it without a commit. Local wins, so you can override centrally-managed values per repository. By default augmentation only fills fields that are empty. Set `OVERRIDE_SBOM_METADATA: true` to make it overwrite values the generator already produced - useful when a generator guesses a name or version you would rather correct. ## Automatic VCS detection Repository URL, commit SHA and branch or tag are detected and added automatically on every CI runtime. No configuration needed. Where a vendor publishes those details as environment variables, they are read from there. Everywhere else the action reads them from the git checkout it is running in, which is why Azure Pipelines and any other container runner get provenance without you writing it out by hand. | Runtime | Source | Notes | | ------------------------------------------------------------------------ | ------------------------------------------------- | ----------------------------------------------------------------------------- | | GitHub Actions | Runner environment | Works with GitHub Enterprise Server | | GitLab CI | Job environment | Works with self-managed instances | | Bitbucket Pipelines | Step environment | Bitbucket Cloud; Data Center needs `vcs_url` in `sbomify.json` | | TeamCity | Build properties file | Git roots only - see [below](#teamcity-is-different) | | Jenkins | Job environment, then the checkout | Git plugin variables; the checkout on a Subversion, Perforce or SCM-less job | | CircleCI | Job environment, then the checkout | The checkout when the job never ran `checkout` | | Travis CI | Job environment for the ref, checkout for the URL | Travis publishes no repository URL - see [below](#travis-ci-is-half-and-half) | | Azure Pipelines, Buildkite, Drone, AppVeyor, AWS CodeBuild, any other CI | The git checkout (`git remote`, `git rev-parse`) | Needs the `.git` directory in the container and a configured remote | | Your own machine | The git checkout, opt-in | Set `SBOMIFY_LOCAL_VCS=true` - see [below](#local-runs-are-opt-in) | Jenkins, CircleCI and Travis CI got platforms of their own after `v26.8.0`; on older tags all three read the checkout, which is still what each falls back to. The reason is the ref: all three check out a detached HEAD, so the checkout can name a tag that happens to point at the commit and nothing else, while the vendor knows which branch the build was for - and on a pull request, which branch the request came _from_. Each records repository URL, commit SHA and branch or tag. A browsable commit URL is added as well for github.com, gitlab.com and bitbucket.org, plus self-hosted GitHub and GitLab, whose commit paths match their cloud products. Everything else - Bitbucket Data Center included, since it lays commit URLs out differently from Bitbucket Cloud - gets the repository URL and the SHA without a link, rather than a guessed one that 404s. What gets written: - **CycloneDX** - a VCS external reference on the root component, in `git+https://...@sha` form - **SPDX** - `downloadLocation` pinned to the commit, plus `sourceInfo` with build context and a VCS external reference This is what makes an SBOM traceable back to a specific commit, which in turn is what makes signing meaningful: the document says exactly which source produced it. ### TeamCity is different TeamCity is VCS-agnostic, and a root can just as easily be Subversion, Perforce or TFVC as Git. Under those, its revision parameter holds a changelist or revision number rather than a commit hash, and the SBOM's VCS fields are Git-shaped - so writing one into the other would put a false claim into a document you may go on to sign. TeamCity exposes no parameter saying which VCS a root uses. Detection therefore runs only when the repository URL positively identifies Git, and emits nothing otherwise. A self-hosted Git server whose URL has neither a `.git` suffix nor a recognised host cannot be detected; set `SBOMIFY_VCS_URL` (and `SBOMIFY_VCS_REF`) and it is trusted as given. See the [TeamCity runtime guide](/sbomify-action/runtimes/teamcity/#vcs-information). ### Travis CI is half and half Travis publishes the commit and the branch, but no repository URL - only `TRAVIS_REPO_SLUG`, an `owner/repo` pair with no host attached. Travis serves GitHub, Bitbucket, GitLab and Assembla projects, so turning that pair into a URL means guessing the forge, and a link that lands on the wrong host is worse than no link. The URL therefore comes from the checkout, and the commit and ref from the job. Nothing is constructed from the slug, and CircleCI's `CIRCLE_PROJECT_USERNAME`/`CIRCLE_PROJECT_REPONAME` pair is left alone for the same reason. Travis jobs run on a VM rather than in a container of your choosing, so a `docker run` has to forward the variables explicitly. See [Travis CI](/sbomify-action/runtimes/travis/#vcs-information). ### Runtimes read from the checkout Azure Pipelines and any other container runner have no vendor integration, and none is needed: they check out a git repository and run a command in it, so the action asks `git` directly. The same path is what Jenkins, CircleCI and Travis CI fall back to. Two conditions have to hold, and both are the default: - **The `.git` directory has to be there.** A shallow clone is fine; an exported tarball or a mount of only your lockfile is not. - **The repository needs a remote.** `origin` is used if present, otherwise the first remote. A checkout with no remote has no URL worth recording, so nothing is emitted. A runner is recognised as CI when it sets `CI=true` or a vendor variable of its own (`CIRCLECI`, `TRAVIS`, `TF_BUILD`, `BUILDKITE`, `DRONE`, `APPVEYOR`, `CODEBUILD_BUILD_ID`, or any of the five Jenkins markers below). Almost every runner sets one; a bare `docker run` from a shell script sets neither and is treated as a local run. Jenkins is detected on any of `JENKINS_URL`, `JENKINS_HOME`, `HUDSON_HOME`, `JENKINS_NODE_COOKIE` or `JENKINS_SERVER_COOKIE`, rather than `JENKINS_URL` alone. A Docker Pipeline agent - the documented way to run the action on Jenkins - forwards the _build_ environment into the container, which carries `HUDSON_HOME` and both cookies but no `JENKINS_URL`, since Jenkins only exports that once the instance URL has been filled in under system settings. A freestyle build is the other way round. If any of that does not hold, or the remote URL is not the one you want in the document, set the fields yourself: ```json { "vcs_url": "https://github.com/my-org/my-repo", "vcs_commit_sha": "abc123def456", "vcs_ref": "main" } ``` `sbomify.json` takes priority over detection, so this is also how you replace an internal remote URL with the public one. ### Local runs are opt-in On your own machine nothing is read from the checkout unless you ask for it. The same lock file would otherwise produce a different SBOM depending on whether a remote happened to be configured, and an internal remote would be written into a document that often leaves the company. Set `SBOMIFY_LOCAL_VCS=true` to opt in, or state the fields in `sbomify.json` as above. On CI it stays automatic - that is the point of it. ### Overriding or disabling The same three fields override auto-detected values, which is useful for self-hosted forges whose URLs are not derivable from the environment. To turn detection off entirely: ```yaml env: DISABLE_VCS_AUGMENTATION: "true" ``` ## Component identity overrides Independently of `sbomify.json`, three variables override the root component's identity: ```yaml env: COMPONENT_NAME: my-app COMPONENT_VERSION: ${{ github.ref_name }} COMPONENT_PURL: pkg:golang/github.com/my-org/my-app@1.2.3 ``` `COMPONENT_VERSION` is the one most projects need, because generators often infer a version from a manifest rather than from the release you are actually shipping. See [how to version SBOMs](/guides/how-to-version-sboms/) for what to put there. Every override is recorded in the [audit trail](/sbomify-action/advanced/#audit-trail), so the fact that a value was changed - and what it was before - is preserved. --- # Enrichment: Filling In Component Metadata URL: https://sbomify.com/sbomify-action/enrichment/ Description: How the sbomify action enriches every component with licenses, suppliers, descriptions and hashes from package registries, distro license databases and lifecycle data. Turn it on with `ENRICH: true`. No account required. ## The problem it solves Generators are built to detect dependencies, not to describe them. A typical scanner component looks like this: ```json { "type": "library", "name": "django", "version": "5.1", "purl": "pkg:pypi/django@5.1" } ``` Accurate, and nearly useless for compliance. After enrichment: ```json { "type": "library", "name": "django", "version": "5.1", "purl": "pkg:pypi/django@5.1", "publisher": "Django Software Foundation", "description": "A high-level Python web framework...", "licenses": [{"expression": "BSD-3-Clause"}], "externalReferences": [ {"type": "website", "url": "https://www.djangoproject.com/"}, {"type": "vcs", "url": "https://github.com/django/django"}, {"type": "distribution", "url": "https://pypi.org/project/Django/"} ] } ``` ## What gets added | Field | Typical coverage | | --------------------- | --------------------------------- | | Supplier or publisher | High on major registries | | License | High - most registries require it | | Description | High | | Homepage | Medium to high | | Repository | Medium to high | | Download URL | High | | Issue tracker | Medium | Coverage varies by ecosystem. Popular packages on PyPI, npm and crates.io have excellent metadata. Obscure or private packages may gain nothing. ## Data sources | Source | Ecosystems | Provides | | -------------- | -------------------------------------------------------------------------- | -------------------------------------------------- | | License DB | Alpine, Wolfi, Debian, Ubuntu, Rocky, Alma, CentOS, Fedora, Amazon Linux | License, description, supplier, homepage | | Lifecycle | Python, PHP, Go, Rust, Django, Rails, Laravel, React, Vue, and OS packages | Release date, end of support, end of life | | PyPI | Python | License, author, homepage | | crates.io | Rust | License, author, homepage, repository, description | | pub.dev | Dart | License, author, homepage, repository | | Conan Center | C and C++ | License, author, homepage, repository, description | | Debian Sources | Debian | Maintainer, description, homepage | | deps.dev | Python, npm, Maven, Go, Ruby, NuGet | License, homepage, repository | | ecosyste.ms | All major ecosystems | License, description, maintainer | | ClearlyDefined | Python, npm, Cargo, Maven, Ruby, NuGet, Go | License, homepage, repository | | Repology | Linux distros | License, homepage | ClearlyDefined is queried through [clearly-cached](https://github.com/sbomify/clearly-cached), a caching front end run at `https://clearly-cached.sbomify.com`. It retries the transient upstream failures that would otherwise be recorded as "this package has no licence", and returns a roughly 0.4 KB projection instead of a definition that can run to 190 KB. Point `SBOMIFY_CLEARLY_CACHED_URL` at your own instance if you prefer. If the service is unreachable or failing, enrichment stops consulting it for the rest of the run and continues with the other sources. ### Priority order Sources are tried in order and stop at the first that answers. Native registries rank above aggregators, which rank above general fallbacks. | Ecosystem | Primary | Fallbacks | | ------------------- | -------------- | ------------------------------------- | | Python | PyPI | deps.dev, ecosyste.ms, ClearlyDefined | | JavaScript | deps.dev | ecosyste.ms, ClearlyDefined | | Rust | crates.io | deps.dev, ecosyste.ms, ClearlyDefined | | Go | deps.dev | ecosyste.ms, ClearlyDefined | | Ruby | deps.dev | ecosyste.ms, ClearlyDefined | | Java and Maven | deps.dev | ecosyste.ms, ClearlyDefined | | NuGet | deps.dev | ecosyste.ms, ClearlyDefined | | Dart | pub.dev | ecosyste.ms | | C and C++ | Conan Center | ecosyste.ms | | Debian | Debian Sources | Repology, ecosyste.ms | | Other Linux distros | License DB | Repology, ecosyste.ms | ## Linux distro license databases Container SBOMs are mostly operating system packages, and those are exactly the packages public aggregators handle worst. Pre-computed license databases are built from official distro sources - Alpine's APKINDEX, Debian and Ubuntu apt repositories, RPM repositories - and normalised into validated SPDX license expressions. | Distro | Versions | | ------------ | ------------------- | | Alpine | 3.13 - 3.21 | | Wolfi | rolling | | Debian | 11, 12, 13 | | Ubuntu | 20.04, 22.04, 24.04 | | Rocky Linux | 8, 9 | | AlmaLinux | 8, 9 | | CentOS | Stream 8, Stream 9 | | Fedora | 39 - 42 | | Amazon Linux | 2, 2023 | They are regenerated on every release, downloaded on demand, and cached locally at `~/.cache/sbomify/license-db` (or wherever `SBOMIFY_CACHE_DIR` points). Expect 20-50 MB. ### License database rate limits Databases are downloaded from GitHub Releases. Unauthenticated requests are limited to **60 per hour per IP address**, and shared CI runners frequently have that budget already spent by someone else. When the limit is hit, **enrichment degrades silently**. You get an SBOM with fewer licenses populated, and no error to tell you why. The fix is to pass a token, which raises the limit to 5,000 per hour: ```yaml env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` This applies on **every runtime**, not just GitHub Actions - it is GitHub's API being called regardless of where you run. On GitLab, Jenkins or anywhere else, set `GITHUB_TOKEN` (or `GH_TOKEN`) to any GitHub personal access token with public read scope. If enrichment coverage looks lower than expected, check this first. ## Lifecycle data Components are annotated with [Common Lifecycle Enumeration](/compliance/cle/) dates - general availability, end of support, end of life - so downstream tools can flag software running on unsupported foundations. **Operating systems**: Debian 10-12, Ubuntu 20.04/22.04/24.04, Alpine 3.13-3.21, Rocky 8-9, AlmaLinux 8-9, CentOS Stream 8-9, Fedora 39-42, Amazon Linux 2 and 2023. **Runtimes and frameworks**: | Package | Tracked versions | Matched on | | ------- | ---------------- | ---------------- | | Python | 2.7, 3.10 - 3.14 | Any package type | | PHP | 7.4, 8.0 - 8.5 | Any package type | | Go | 1.22 - 1.25 | Any package type | | Rust | 1.90 - 1.92 | Any package type | | Django | 4.2, 5.2, 6.0 | PyPI only | | Rails | 7.0 - 8.1 | RubyGems only | | Laravel | 10 - 13 | Composer only | | React | 17 - 19 | npm only | | Vue | 2, 3 | npm only | Version cycles are derived from the full version, so `3.12.7` matches the `3.12` cycle. Dates are written as CycloneDX properties: ```json { "type": "operating-system", "name": "debian", "version": "12.12", "properties": [ {"name": "cdx:lifecycle:milestone:generalAvailability", "value": "2023-06-10"}, {"name": "cdx:lifecycle:milestone:endOfSupport", "value": "2026-06-11"}, {"name": "cdx:lifecycle:milestone:endOfLife", "value": "2028-06-30"} ] } ``` Note that ordinary distro packages - curl, nginx, openssl - do not receive lifecycle data. Only the operating system itself and the tracked runtimes and frameworks above do. ## Integrity hashes Hashes are extracted directly from your lockfile and attached to matching components. This runs locally with no network access, and never overwrites hashes that are already present. | Ecosystem | Lockfiles | | ---------- | -------------------------------------------------- | | Python | `poetry.lock`, `Pipfile.lock`, `uv.lock` | | JavaScript | `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` | | Rust | `Cargo.lock` | | Dart | `pubspec.lock` | Component hashes are a [CISA 2025](/compliance/cisa-minimum-elements/) expectation, and most generators do not populate them. They are what lets someone verify that the component you documented is the component you shipped - the same property that makes the whole [chain of custody](/sbomify-action/why/#the-part-most-platforms-get-wrong) work at the component level rather than just the document level. ## Transitive dependency discovery Some lockfiles record only direct dependencies. Where possible, the installed environment is inspected to find transitive dependencies the generator missed, and they are added to the SBOM. This currently covers Python via `pipdeptree`. Discovered packages are logged, and on GitHub Actions appear in a collapsible group. It only works if the dependencies are actually installed. If you generate an SBOM in a clean checkout without installing anything first, you will see: ```text No transitive dependencies discovered (packages may not be installed, or all deps are direct) ``` That is informational, not an error, and it never fails a build. To get the most out of it, install your dependencies before generating. ## Limitations Worth knowing before you rely on it: - **Network access is required.** Enrichment calls external APIs, so it is not suitable for air-gapped builds. Generation and augmentation still work offline; run with `ENRICH: false`, and set `SBOMIFY_FETCH_RUNTIMES=0` so the [tool runtimes](/sbomify-action/advanced/#tool-runtimes) are not fetched either. - **Responses are cached** on disk between runs. Disable with `SBOMIFY_ENRICHMENT_CACHE=0`, or change the lifetime with `SBOMIFY_ENRICHMENT_CACHE_TTL`. - **Rate limits apply.** Very large dependency trees, in the region of a thousand packages or more, may enrich slowly. Caching and backoff help, but the ceiling is real. - **It is best effort.** Private packages, vendored code and obscure libraries are not in any public registry, so nothing will be found for them. Declare what you know about those through [augmentation](/sbomify-action/augmentation/) instead. - **Results are not deterministic.** Registry data changes over time, so the same input can produce slightly different output on different days. This is the trade-off for richer data. Every value that was added is recorded in the [audit trail](/sbomify-action/advanced/#audit-trail) along with the source it came from, so any given SBOM remains fully explainable even though it is not reproducible byte-for-byte. ## Caching Persisting the cache between runs is worth doing - it avoids re-downloading license databases on every build. See [caching](/sbomify-action/advanced/#caching) for per-runtime recipes. --- # How the sbomify Action Works URL: https://sbomify.com/sbomify-action/how-it-works/ Description: The full sbomify-action pipeline, step by step: generation, package injection, transitive discovery, hash enrichment, augmentation, enrichment, validation and upload. A single invocation runs a fixed pipeline. Understanding the stages makes the log output legible and explains where each field in your SBOM came from. ## The pipeline ```text Input LOCK_FILE, SBOM_FILE or DOCKER_IMAGE │ 1 ├─ Generation .............. pick a generator, produce a base SBOM │ 1b├─ Additional packages ..... inject PURLs the lockfile missed │ 1.4├─ Transitive discovery ... find installed deps not in the lockfile │ 1.5├─ Hash enrichment ........ pull integrity hashes from the lockfile │ 2 ├─ Augmentation ............ add your organisational metadata │ 3 ├─ Enrichment .............. add registry metadata per component │ 4 ├─ Finalization ............ normalise, validate against schema │ 5 ├─ Upload .................. sbomify, Dependency Track, or neither │ 6 └─ Post-upload ............. tag product releases ``` ## 1. Generation One of `LOCK_FILE`, `SBOM_FILE`, `DOCKER_IMAGE` or `SOURCE_DIR` is required. If you pass `SBOM_FILE`, generation is skipped and your existing document is processed instead. Generators are registered with a priority, and the highest-priority generator that supports your input wins. If it fails, the next one is tried automatically. | Priority | Generator | Ecosystems | Output | | -------- | ------------------ | ------------------------------------------------------------------------------------------ | ------------------------------- | | 10 | `cyclonedx-py` | Python | CycloneDX 1.2-1.7 | | 10 | `cargo-cyclonedx` | Rust | CycloneDX 1.3-1.5, SPDX 2.3 | | 10 | `cyclonedx-gomod` | Go | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `cyclonedx-maven` | Java (`pom.xml`) | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `cyclonedx-gradle` | Java (Gradle build scripts) | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `cyclonedx-sbt` | Scala | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `gradle-lockfile` | Java (`gradle.lockfile`), read directly | CycloneDX 1.2-1.7, SPDX 2.2-2.3 | | 20 | `cdxgen` | JavaScript, Ruby, Dart, C++, PHP, .NET, Elixir, Clojure, and elsewhere no native tool wins | CycloneDX 1.4-1.7 | | 35 | Syft | Swift, Terraform, Haskell, Erlang, container images, directory scans | CycloneDX 1.2-1.6, SPDX 2.2-2.3 | Native tools rank above generic scanners because they resolve dependencies the way the ecosystem itself does. Several emit SPDX directly rather than deferring to Syft. See [input sources](/sbomify-action/sources/) for the full routing logic. Apart from `cyclonedx-py`, which ships with the CLI, the generators are not baked into the image - they are fetched on first use, digest-pinned and cached. See [tool runtimes](/sbomify-action/advanced/#tool-runtimes). > Trivy was removed from the tool set after [compromised releases were published in March 2026](/2026/03/26/trivy-compromise-hardening-sbomify-action/). The remaining generators cover every supported ecosystem. ## 1b. Additional package injection Packages that no lockfile knows about are injected here: vendored code, system libraries, binaries copied in during a Docker build. They come from `additional_packages.txt`, `ADDITIONAL_PACKAGES_FILE` or the inline `ADDITIONAL_PACKAGES` variable, and are merged and deduplicated. Injected packages flow through every subsequent stage exactly like generated ones - they get augmented, enriched and validated the same way. See [input sources](/sbomify-action/sources/#additional-packages). ## 1.4. Transitive dependency discovery Some lockfiles record only direct dependencies. This stage inspects the installed environment to find transitive dependencies the generator missed, and adds them. Currently this covers Python via `pipdeptree`. Discovered PURLs are logged - on GitHub Actions they appear in a collapsible group. **This stage only works if your dependencies are actually installed.** If you generate an SBOM without running `pip install` first, there is nothing to inspect, and you will see: ```text No transitive dependencies discovered (packages may not be installed, or all deps are direct) ``` That message is informational. The stage never fails a build. ## 1.5. Hash enrichment Integrity hashes are extracted from your lockfile and attached to the matching components. This is a local operation - no network involved - and existing hashes are never overwritten. Supported lockfiles: | Ecosystem | Lockfiles | | ---------- | -------------------------------------------------- | | Python | `poetry.lock`, `Pipfile.lock`, `uv.lock` | | JavaScript | `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` | | Rust | `Cargo.lock` | | Dart | `pubspec.lock` | This matters for compliance: component hashes are a [CISA 2025](/compliance/cisa-minimum-elements/) expectation, and they are what lets someone verify that the component you documented is the component you shipped. Most scanners do not populate them. ## 2. Augmentation Adds organisational metadata - supplier, authors, licenses, lifecycle phase, security contact, support dates - and VCS information detected from the CI environment, or from the git checkout on runtimes that publish none. Sources are consulted in priority order, and **local values always win**: 1. `sbomify.json` in your project root. No account needed. 2. The sbomify API, using metadata configured on your component. Requires an account. 3. CI environment providers, which contribute repository URL, commit SHA and branch automatically on GitHub Actions, GitLab CI and Bitbucket. By default augmentation only fills empty fields. Set `OVERRIDE_SBOM_METADATA=true` to make it overwrite values the generator already produced. Full field reference: [augmentation](/sbomify-action/augmentation/). ## 3. Enrichment Queries package registries to fill in per-component metadata: license, supplier, description, homepage, repository, download and issue-tracker URLs. Sources are tried in priority order per ecosystem, stopping at the first that answers. Native registries such as PyPI and crates.io rank above aggregators such as deps.dev and ecosyste.ms, which rank above fallbacks such as Repology. Linux distro packages are served from pre-computed license databases. This is the only stage that requires network access, and the only one that makes runs non-deterministic - registry data changes over time, so the same input can produce slightly different output on different days. Full source list, coverage expectations and limitations: [enrichment](/sbomify-action/enrichment/). ## 4. Finalization PURLs are normalised, URLs validated, and stub components added where references would otherwise dangle. The result is validated against the CycloneDX or SPDX JSON schema before it is written. An SBOM that fails schema validation is not emitted. `OUTPUT_FILE` is written here, along with `audit_trail.txt` beside it. ## 5. Upload Skipped entirely when `UPLOAD=false`, which is the right setting if you only want a file on disk. Destinations are set with `UPLOAD_DESTINATIONS` and can be combined: - **sbomify** - the default. Requires `COMPONENT_ID` plus either a token or OIDC trusted publishing. - **Dependency Track** - configured with `DTRACK_*` variables. CycloneDX only. See [publishing](/sbomify-action/publishing/). ## 6. Post-upload If `PRODUCT_RELEASE` is set, the uploaded SBOM is tagged against one or more product releases. Releases are created if they do not exist. A failure here logs a warning but does not fail the build, since the SBOM has already been stored. ## What gets recorded Every stage writes to the audit trail. The summary table at the end of a run shows counts by category, and `audit_trail.txt` lists each individual change with a UTC timestamp and its source: ```text ## Enrichment [2026-01-18T12:34:57Z] ENRICHMENT pkg:pypi/requests@2.31.0 license ADDED (source: pypi) [2026-01-18T12:34:57Z] ENRICHMENT pkg:pypi/requests@2.31.0 description ADDED (source: pypi) ``` This is what makes the pipeline auditable: every field that is not straight from the generator is traceable to the stage and source that added it. Once you sign the output, that record is fixed - and because [sbomify never modifies uploaded artifacts](/sbomify-action/why/#the-part-most-platforms-get-wrong), it stays fixed. See [the audit trail](/sbomify-action/advanced/#audit-trail) for the full format. --- # Input Sources: Lockfiles, Containers, Directories and Yocto URL: https://sbomify.com/sbomify-action/sources/ Description: Every input the sbomify action accepts - 17 lockfile ecosystems, container images, directory scans, Chainguard SBOM reuse, Yocto builds, git submodules and manually declared packages. Exactly one input source is required: `LOCK_FILE`, `SBOM_FILE`, `DOCKER_IMAGE` or `SOURCE_DIR`. ## Lockfiles Set `LOCK_FILE` to the path of your lockfile. Seventeen ecosystems are supported. | Language | Recognised files | | --------------------------------- | ------------------------------------------------------------------------------ | | [Python](/guides/python/) | `requirements.txt`, `poetry.lock`, `Pipfile.lock`, `uv.lock`, `pyproject.toml` | | [JavaScript](/guides/javascript/) | `package.json`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `bun.lock` | | [Java](/guides/java/) | `pom.xml`, `build.gradle`, `build.gradle.kts`, `gradle.lockfile` | | [Go](/guides/go/) | `go.mod`, `go.sum` | | [Rust](/guides/rust/) | `Cargo.lock` | | [Ruby](/guides/ruby/) | `Gemfile.lock` | | [PHP](/guides/php/) | `composer.json`, `composer.lock` | | [.NET and C#](/guides/dotnet/) | `packages.lock.json` | | [Swift](/guides/swift/) | `Package.swift`, `Package.resolved` | | [Dart](/guides/dart/) | `pubspec.lock` | | [Elixir](/guides/elixir/) | `mix.lock` | | [Scala](/guides/scala/) | `build.sbt` | | [C and C++](/guides/cpp/) | `conan.lock` | | [Terraform](/guides/terraform/) | `.terraform.lock.hcl` | | Haskell | `stack.yaml.lock`, `stack.yaml`, `cabal.project.freeze` | | Erlang | `rebar.lock` (rebar3 projects) | | Clojure | `deps.edn`, `project.clj` | For language-specific walkthroughs, see the [SBOM guides](/guides/). ### Manifests defer to lockfiles Naming a _manifest_ that sits beside its lockfile reads the lockfile instead. `package.json` defers to `package-lock.json`, `pyproject.toml` to `poetry.lock`, `Package.swift` to `Package.resolved`. This is deliberate: a manifest states version _ranges_, a lockfile states what was actually _resolved_. You get the more precise answer without having to know which file to point at. ### Which generator runs Generators are registered with a priority. The highest-priority generator that supports your input runs first; if it fails or does not support the input, the next is tried automatically. | Priority | Generator | Ecosystems | Output formats | | -------- | ------------------ | --------------------------------------------------------------------------------------------------------- | ------------------------------- | | 10 | `cyclonedx-py` | Python | CycloneDX 1.2-1.7 | | 10 | `cargo-cyclonedx` | Rust | CycloneDX 1.3-1.5, SPDX 2.3 | | 10 | `cyclonedx-gomod` | Go | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `cyclonedx-maven` | Java (`pom.xml`) | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `cyclonedx-gradle` | Java (`build.gradle`, `build.gradle.kts`) | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `cyclonedx-sbt` | Scala (`build.sbt`) | CycloneDX 1.4-1.6, SPDX 2.3 | | 10 | `gradle-lockfile` | Java (`gradle.lockfile`), read directly with no Gradle run | CycloneDX 1.2-1.7, SPDX 2.2-2.3 | | 20 | `cdxgen` | JavaScript, Ruby, Dart, C++, PHP, .NET, Elixir, Clojure, and Python, Go or Java where no native tool wins | CycloneDX 1.4-1.7 | | 35 | Syft | Swift, Terraform, Haskell, Erlang, container images, and SPDX wherever no native tool emits it | CycloneDX 1.2-1.6, SPDX 2.2-2.3 | The native generators at priority 10 resolve dependencies the way the ecosystem itself does, which is why they outrank the generic scanners. Several emit SPDX directly rather than leaving it to Syft. In practice: 1. **Python** (`requirements.txt`, `poetry.lock`, `Pipfile.lock`) uses `cyclonedx-py` 2. **Rust** (`Cargo.lock`) uses `cargo-cyclonedx` 3. **Go** (`go.mod`, `go.sum`) uses `cyclonedx-gomod` 4. **Java** uses `cyclonedx-maven` for `pom.xml`, `cyclonedx-gradle` for Gradle build scripts, and reads `gradle.lockfile` directly 5. **Scala** (`build.sbt`) uses `cyclonedx-sbt` 6. **Everything else with a lockfile** uses `cdxgen`, then Syft 7. **Container images** use Syft, then `cdxgen` > Trivy was removed from the tool set after [compromised releases were published in March 2026](/2026/03/26/trivy-compromise-hardening-sbomify-action/). The remaining generators cover every supported ecosystem. ### Where the generators come from Apart from `cyclonedx-py`, which ships with the CLI, the generators are not baked into the container image. They are downloaded on first use, verified against a pinned digest, and cached - see [tool runtimes](/sbomify-action/advanced/#tool-runtimes). This is why the image is small and why the same tool selection works identically under `uvx`. ## Container images Set `DOCKER_IMAGE` instead of `LOCK_FILE`: ```yaml env: DOCKER_IMAGE: my-app:latest OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false ``` The image must be pullable from the environment the action runs in. When the input is a container image, the lifecycle phase is automatically recorded as `post-build`. See the [Docker guide](/guides/docker/) for the wider workflow, including generating an application SBOM and a container SBOM for the same release. ### Chainguard images If `DOCKER_IMAGE` points at a [Chainguard](https://www.chainguard.dev/) image, or an image built `FROM` one, the SBOM published by Chainguard is used instead of scanning. That produces a more accurate result, because it comes from the image publisher rather than from inference. Detection works two ways, and needs no configuration: 1. **Direct Chainguard images** (`cgr.dev/chainguard/...`) are identified by reference and verified against the image config. 2. **Images built from Chainguard bases** are identified by parsing the BuildKit SLSA provenance attestations embedded in the image. **Important limitation.** A Chainguard SBOM covers the packages in the Chainguard base image and nothing else. Your application binary, anything brought in with `COPY` or `ADD`, and artifacts pulled from other build stages with `COPY --from=...` will not appear. Declare those explicitly: ```yaml env: DOCKER_IMAGE: my-org/my-app:latest ADDITIONAL_PACKAGES: "pkg:golang/github.com/my-org/my-app@1.2.3" OUTPUT_FILE: sbom.cdx.json UPLOAD: false ``` Chainguard detection needs `crane` and `cosign`, which are fetched automatically like the other tools. ## Directory scanning `SOURCE_DIR` scans a whole tree with Syft rather than reading a manifest. **Treat it as a last resort** - point the action at a lockfile wherever one exists. The two are different claims. A lockfile is the dependency graph its ecosystem _resolved_: every transitive dependency, at the exact version that would be installed, whether or not it is present on this machine. A directory is whatever happens to be _on disk_, catalogued by whatever Syft recognises. In practice a directory scan: - **misses what is not installed** - dev and optional dependencies, anything pruned from a production install, anything the build has not fetched yet - **misses what Syft does not recognise** - an unsupported ecosystem, a vendored tree with no manifest, a statically linked binary carrying no build metadata - and it does not tell you - **reports whatever else is lying around** - build caches, test fixtures, a stale `node_modules`, a second copy of a toolchain - **varies with the machine** - the same commit scanned on a different runner, or at a different point in the build, can produce a different SBOM None of that is Syft doing badly. It is the difference between reading a declaration and inspecting a filesystem. Use `SOURCE_DIR` for what no lockfile can describe: an unpacked release archive, a vendored dependency tree, a build output. ```yaml env: SOURCE_DIR: dist/ OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false ``` If a lockfile exists and you use `SOURCE_DIR` anyway, you are choosing a less complete and less reproducible SBOM. ## Existing SBOMs Set `SBOM_FILE` to process a document you already have. Generation is skipped and the file goes straight into augmentation and enrichment. This is how you enrich an SBOM produced by another tool, or turn one you were handed into something compliance-ready. ## Git submodules `SUBMODULE_PATH` treats the component as a git submodule pinned at that path. The pin is resolved to a version - an exact version tag if one matches, otherwise the short commit SHA - and the component's existing SBOM at that version is attached if one exists. If not, the SBOM is generated and uploaded. This keeps a product SBOM pointing at the exact submodule revision your build used, without regenerating an SBOM that has already been published. Requires `LOCK_FILE` and the `sbomify` upload destination. ## Additional packages Lockfiles do not know about vendored code, system libraries, statically linked dependencies or binaries copied into a container. Declare those as [PURLs](https://github.com/package-url/purl-spec). Injected packages flow through augmentation and enrichment exactly like generated ones. ### A file in your repository If `additional_packages.txt` exists in the working directory it is picked up automatically: ```text # Runtime dependencies not in the lockfile pkg:pypi/requests@2.31.0 pkg:npm/lodash@4.17.21 # System libraries pkg:deb/debian/openssl@3.0.11 ``` One PURL per line. Lines starting with `#` are comments, and blank lines are ignored. Use `ADDITIONAL_PACKAGES_FILE` for a different path. ### Inline ```yaml env: LOCK_FILE: requirements.txt ADDITIONAL_PACKAGES: "pkg:pypi/requests@2.31.0,pkg:npm/lodash@4.17.21" ``` Comma or newline separated. If both a file and inline packages are supplied, they are merged and deduplicated. ### Building the list during the build Because the convention file is read at run time, earlier steps can append to it: ```yaml - name: Record the application binary run: echo "pkg:golang/github.com/my-org/my-app@1.2.3" >> additional_packages.txt - uses: sbomify/sbomify-action@master env: LOCK_FILE: go.mod # picked up automatically ``` ### No lockfile at all Set `LOCK_FILE: none` (or `SBOM_FILE: none`) to build an SBOM containing only the packages you declare: ```yaml env: LOCK_FILE: none ADDITIONAL_PACKAGES: "pkg:pypi/requests@2.31.0,pkg:deb/debian/openssl@3.0.11" OUTPUT_FILE: sbom.cdx.json UPLOAD: false ``` At least one additional package must be configured, or there is nothing to put in the document. ## Yocto and OpenEmbedded Yocto builds emit their own SPDX documents, so they get a dedicated subcommand rather than the normal pipeline. It extracts the archive, discovers the per-package SBOMs, creates the matching components in sbomify, uploads each one, and tags them all against a product release. ```bash sbomify-action --token "$SBOMIFY_TOKEN" \ yocto tmp/deploy/images/qemux86-64/core-image-base.rootfs.spdx.tar.zst \ --release "my-product:1.0.0" \ --enrich ``` | Option | Required | Description | | --------------------------- | -------- | ---------------------------------------------------------------------- | | archive path | Yes | Path to a `.spdx.tar.zst` or `.tar.gz` archive. | | `--token` | Yes | sbomify API token. Pass before the `yocto` subcommand, or set `TOKEN`. | | `--release` | Yes | Product release, as `product_id:version`. | | `--augment`, `--no-augment` | No | Run augmentation per SBOM. Off by default. | | `--enrich`, `--no-enrich` | No | Run enrichment per SBOM. Off by default. | | `--visibility` | No | Visibility for created components: `public`, `private` or `gated`. | | `--max-packages` | No | Cap how many package SBOMs are processed. Useful for testing. | | `--component-id` | No | Target component for SPDX 3 single-file uploads. | | `--dry-run` | No | Show what would happen without calling the API. | | `--verbose` | No | Verbose logging. | Documents named `recipe-*` and `runtime-*` are skipped, since they describe build inputs rather than shipped packages. The archive is normally found at `tmp/deploy/images/{machine}/` in your build output. See the [Yocto guide](/guides/yocto/) for the wider workflow. ## Output formats | Format | Generate | Process | | -------------------------- | -------- | ------- | | CycloneDX 1.2 - 1.7 (JSON) | Yes | Yes | | SPDX 2.2 and 2.3 (JSON) | Yes | Yes | | SPDX 3.0.1 (JSON-LD) | No | Yes | Set the format with `SBOM_FORMAT` and the version with `SPEC_VERSION`. - **CycloneDX** is the default and emits 1.6 unless you ask for something else. The list starts at 1.2 because CycloneDX only gained a JSON representation in that version. - **SPDX** is emitted natively where the ecosystem's own tool can (Maven, Gradle, sbt, Go, Cargo), and by Syft everywhere else. The default is 2.3; select 2.2 with `SPEC_VERSION=2.2`. - **SPDX 3.0.1** cannot be generated - no generator emits it, and asking for it fails with `No generator found for input`. It is fully supported as _input_: pass an existing 3.0.1 document via `SBOM_FILE` and it will be parsed, augmented, enriched and written back as 3.0.1. Every generated SBOM is validated against its JSON schema before it is written. A document that fails validation is not emitted. ## Non-SBOM artifacts `BOM_TYPE` lets you upload related artifacts through the same tooling: `vex`, `cbom` or `hbom`. These are uploaded verbatim to sbomify - augmentation, enrichment, overrides and package injection are all skipped, and Dependency Track and product releases are rejected. External VEX documents are detected by content: OpenVEX by its `@context`, and CSAF VEX by `document.category`. CycloneDX documents containing cryptographic assets are classified as `cbom` automatically. See [how VEX works in sbomify](/faq/how-do-i-use-vex/). --- # Publishing SBOMs: Uploading, Releases and Dependency Track URL: https://sbomify.com/sbomify-action/publishing/ Description: How to upload SBOMs from CI to sbomify using OIDC trusted publishing or an API token, tag them against product releases, and send them to Dependency Track. Uploading is optional. Set `UPLOAD: false` and you get a file on disk and nothing else - useful for storing SBOMs as build artifacts or feeding them into another tool. Destinations are chosen with `UPLOAD_DESTINATIONS`, and can be combined. ## OIDC trusted publishing On GitHub Actions, you do not need a long-lived token. The workflow can exchange a GitHub-issued identity token for a short-lived sbomify token at run time. This is the recommended approach wherever it is available. There is no secret to rotate, no secret to leak, and the resulting credential expires in about 15 minutes. ### Setting it up **1. Create the binding in sbomify first.** Open your component, go to Settings, then Trusted Publishing, and add your GitHub organisation and repository. This step is not optional. sbomify pins the binding to GitHub's immutable owner and repository IDs rather than their names, which defeats repository-resurrection attacks - but it also means **the exchange returns 403 until the binding exists**. If trusted publishing fails with a permission error, this is almost always why. **2. Grant the workflow permission to mint tokens:** ```yaml permissions: contents: read id-token: write jobs: sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: sbomify/sbomify-action@master env: COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: true ENRICH: true ``` No `TOKEN`. The `id-token: write` permission is what makes it work; without it GitHub does not expose the endpoints needed to mint the identity token. ### How it works 1. The workflow grants `id-token: write`, and the runner exposes an OIDC request URL and token. 2. The action mints a JWT with the configured audience, which defaults to `sbomify.com`. 3. It posts that JWT to sbomify, which validates it against the trusted publisher binding. 4. sbomify returns a short-lived access token, valid for roughly 15 minutes. Because CI logs outlive that window, tokens and JWTs are scrubbed from error output before anything is logged. ### Notes and limits - **GitHub Actions only, for now.** The exchange depends on GitHub-issued identity tokens. Other runtimes use a token. - **A token takes precedence.** If `TOKEN` or `SBOMIFY_TOKEN` is set, it is used and OIDC is not attempted. To force OIDC, remove the token. - **Self-hosted** instances derive the audience from `API_BASE_URL`. Override it explicitly with `OIDC_AUDIENCE` if needed. See [the trusted publishing FAQ](/faq/how-do-i-set-up-oidc-trusted-publishing/) for the sbomify-side setup in more detail. ## API tokens On every other runtime, authenticate with an API token stored in your CI platform's secret store. ```yaml env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: true ENRICH: true ``` Precedence is the `--token` flag, then `SBOMIFY_TOKEN`, then `TOKEN`. Good practice: - **One token per consumer.** A token per pipeline or per repository means revoking one does not break everything else, and makes it obvious what stopped working. - **Scope to the workspace** that actually needs it. - **Store it as a secret**, never in the repository. Note that CI secrets are typically not exposed to pull requests from forks, so those builds should run with `UPLOAD: false`. - **Rotate on a schedule.** New tokens expire after 90 days by default. - **Prefer OIDC where you can.** A credential that lives 15 minutes is categorically safer than one that lives 90 days. ## Component IDs `COMPONENT_ID` identifies which sbomify component an SBOM belongs to. Find it in the component's URL or settings page, or let the [setup wizard](/sbomify-action/quickstart/) create components and fill this in for you. A component maps to one buildable thing. A repository containing a frontend and a backend has two components, each with its own ID and its own pipeline step. See [how products, components and releases fit together](/faq/how-do-products-work-in-sbomify/). ## Product releases Tag uploaded SBOMs against one or more product releases: ```yaml env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt PRODUCT_RELEASE: '["your-product-id:v1.0.0"]' ``` The value is a JSON array of `product_id:version` strings, so one SBOM can belong to several releases at once: ```yaml PRODUCT_RELEASE: '["product_one:v1.0.0", "product_two:v2.0.0"]' ``` Behaviour worth knowing: - **Get or create.** Existing releases are reused; missing ones are created. - **Partial failures warn rather than fail.** If some releases tag and others do not, the run logs a warning and continues - the SBOM is already stored, so failing the build would not help. - Requires credentials and `COMPONENT_ID`, since it talks to the sbomify API. A common pattern is to tag releases only on tagged builds: ```yaml PRODUCT_RELEASE: ${{ startsWith(github.ref, 'refs/tags/') && format('["your-product-id:{0}"]', github.ref_name) || '' }} ``` See [how to create a software release](/faq/how-do-i-create-a-software-release/) and [versioning SBOMs](/guides/how-to-version-sboms/). ## Dependency Track Upload to [OWASP Dependency Track](https://dependencytrack.org/) instead of, or alongside, sbomify. ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json UPLOAD: true UPLOAD_DESTINATIONS: dependency-track COMPONENT_NAME: my-app COMPONENT_VERSION: ${{ github.ref_name }} DTRACK_API_KEY: ${{ secrets.DTRACK_API_KEY }} DTRACK_API_URL: https://dtrack.example.com/api DTRACK_AUTO_CREATE: true ENRICH: true ``` The project is identified either by `DTRACK_PROJECT_ID`, or by `COMPONENT_NAME` plus `COMPONENT_VERSION` together. Full variable list in the [configuration reference](/sbomify-action/configuration/#dependency-track). **Dependency Track accepts CycloneDX only.** Combining `SBOM_FORMAT: spdx` with this destination will not work. ### Both at once ```yaml env: LOCK_FILE: requirements.txt UPLOAD_DESTINATIONS: sbomify,dependency-track COMPONENT_NAME: my-app COMPONENT_VERSION: ${{ github.ref_name }} TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: your-component-id DTRACK_API_KEY: ${{ secrets.DTRACK_API_KEY }} DTRACK_API_URL: https://dtrack.example.com/api ENRICH: true ``` The same enriched SBOM goes to both. `COMPONENT_NAME` and `COMPONENT_VERSION` are shared. ## Self-hosted sbomify Point `API_BASE_URL` at your instance: ```yaml env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: your-component-id API_BASE_URL: https://sbomify.yourcompany.com LOCK_FILE: requirements.txt AUGMENT: true ENRICH: true ``` The OIDC audience is derived from that hostname automatically. Override with `OIDC_AUDIENCE` if your deployment expects something different. ## Other artifact types `BOM_TYPE` uploads related artifacts through the same tooling: | Value | Artifact | | ------ | ---------------------------------------- | | `sbom` | Software Bill of Materials. The default. | | `vex` | Vulnerability Exploitability eXchange | | `cbom` | Cryptography Bill of Materials | | `hbom` | Hardware Bill of Materials | Non-SBOM types are uploaded **verbatim** - augmentation, enrichment, overrides and package injection are all skipped, and Dependency Track and `PRODUCT_RELEASE` are rejected. Only the sbomify destination accepts them. ```yaml - uses: sbomify/sbomify-action@master with: bom-type: vex env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: your-component-id SBOM_FILE: vex.json ``` OpenVEX and CSAF VEX documents are detected from their contents. CycloneDX documents containing cryptographic assets are classified as `cbom` automatically. See [using VEX](/faq/how-do-i-use-vex/) and [what a CBOM is](/faq/what-is-a-cbom/). ## What happens after upload Nothing. That is the point. sbomify stores the bytes it received and serves those same bytes back. It does not enrich, normalise, deduplicate or reformat your SBOM. Any signature you made in CI keeps validating indefinitely, and what an auditor downloads is byte-for-byte what your pipeline produced. Analysis - vulnerability scanning, compliance assessment, attestation verification - reads the artifact and writes findings alongside it, never into it. The reasoning behind that design, and why it matters more than it might first appear, is in [why SBOM quality matters](/sbomify-action/why/#the-part-most-platforms-get-wrong). --- # Running the sbomify Action Locally URL: https://sbomify.com/sbomify-action/runtimes/local/ Description: Generate SBOMs on your own machine with uvx, pipx or Docker - for trying things out, debugging a pipeline, or running the setup wizard. Running locally is useful for trying the tool out, debugging a pipeline that behaves unexpectedly, generating a one-off SBOM, and running the [setup wizard](/sbomify-action/quickstart/) - which is interactive and deliberately refuses to run in CI. For actual SBOM generation in a pipeline, use [your CI platform](/sbomify-action/runtimes/). ## Docker Closest to what CI does, which makes it the best choice for reproducing a pipeline problem: ```bash docker run --rm \ -v "$(pwd):/workspace" \ -e LOCK_FILE=requirements.txt \ -e OUTPUT_FILE=sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` Note that the container runs as root, so generated files will be root-owned on the host. Add `--user "$(id -u):$(id -g)"` if that is inconvenient. ## uvx If you have [uv](https://docs.astral.sh/uv/), you can run the CLI without installing anything permanently: ```bash uvx sbomify-action --lock-file requirements.txt --enrich --no-upload -o sbom.cdx.json ``` `uvx` downloads the package into a temporary environment, runs it, and leaves nothing behind. Ideal for a one-off. The setup wizard works the same way: ```bash uvx sbomify-action wizard ``` The license database generator is a separate entry point in the same package: ```bash uvx --from sbomify-action sbomify-license-db --distro alpine --version 3.20 -o alpine-3.20.json.gz ``` ## pipx `pipx run` is the equivalent if you use pipx rather than uv: ```bash pipx run sbomify-action --lock-file requirements.txt --enrich --no-upload -o sbom.cdx.json ``` ```bash pipx run sbomify-action wizard ``` Both `uvx` and `pipx run` keep the tool out of your global Python environment, which is what you want for something you invoke occasionally. ## The generators come down on first use You do not need to install Syft or cdxgen yourself. The tool downloads the generators it needs on first use, verified against a pinned digest and cached under `~/.cache/sbomify/runtimes` (or wherever `SBOMIFY_TOOL_CACHE` points). That means `uvx sbomify-action --lock-file Cargo.lock ...` gets you `cargo-cyclonedx`, not a Syft fallback, without any setup. The first run for a given ecosystem pays a download; later runs reuse the cache. If you would rather use only what is already on your machine, opt out: ```bash SBOMIFY_FETCH_RUNTIMES=0 uvx sbomify-action --lock-file requirements.txt --enrich --no-upload -o sbom.cdx.json ``` Be aware of what that trades away. Opting out does not make the tool fail when a native generator is missing - it falls back to whatever is installed, which is usually a worse answer, and the SBOM does not say so. If you set this flag, install the generators you care about: | Tool | Install | Covers | | -------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------- | | `cyclonedx-py` | Bundled as a dependency | Python | | Syft | `brew install syft` or the [install guide](https://github.com/anchore/syft#installation) | Most ecosystems, container images, SPDX output | | cdxgen | `npm install -g @cyclonedx/cdxgen` | JavaScript, Ruby, PHP, .NET and more | | `cargo-cyclonedx` | `cargo install cargo-cyclonedx` | Rust | | `crane` and `cosign` | `brew install crane cosign` | Chainguard image detection | If a required tool is missing and fetching is disabled, the CLI tells you which one and how to install it. ## Environment variables work too Every CLI flag has an environment variable equivalent, which is convenient in scripts: ```bash export LOCK_FILE=requirements.txt export OUTPUT_FILE=sbom.cdx.json export ENRICH=true export UPLOAD=false uvx sbomify-action ``` Flags take precedence over environment variables. See the [configuration reference](/sbomify-action/configuration/#cli-flags). ## Uploading from your machine ```bash export SBOMIFY_TOKEN="your-token" uvx sbomify-action \ --component-id your-component-id \ --lock-file requirements.txt \ --augment --enrich ``` OIDC trusted publishing is not available locally - it depends on a CI-issued identity token - so use an API token. Be deliberate about uploading from a laptop. An SBOM generated locally reflects your machine rather than a clean build, and it cannot be attested. It is fine for experimenting; for anything you intend to distribute, generate it [in CI](/sbomify-action/why/#build-time-is-the-only-time) where it can be signed at origin. ## VCS information Nothing is read from your checkout unless you ask for it. On CI, repository URL, commit SHA and ref are detected automatically; locally that is deliberately off, because the same lock file would otherwise produce a different SBOM depending on whether a remote happened to be configured, and an internal remote would be written into a document that often gets shared. Opt in when you want it: ```bash SBOMIFY_LOCAL_VCS=true uvx sbomify-action --lock-file requirements.txt --enrich ``` The values come from the checkout in your working directory: `origin` (or the first remote), `HEAD`, and the current branch or the exact tag when HEAD is detached. Or state them yourself in `sbomify.json`, which takes priority either way: ```json { "vcs_url": "https://github.com/my-org/my-repo", "vcs_commit_sha": "abc123def456", "vcs_ref": "main" } ``` See [augmentation](/sbomify-action/augmentation/). ## Debugging a pipeline When CI produces something you did not expect, reproduce it locally with the same image and the same variables: ```bash docker run --rm \ -v "$(pwd):/workspace" \ -e LOCK_FILE=requirements.txt \ -e OUTPUT_FILE=sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ -e VERBOSE=true \ ghcr.io/sbomify/sbomify-action ``` `VERBOSE=true` shows which generator ran, which enrichment sources answered, and where time went. Check `audit_trail.txt` afterwards for the full list of changes. Two differences from CI worth keeping in mind: VCS detection is opt-in locally (`SBOMIFY_LOCAL_VCS=true`) where CI does it automatically, and enrichment coverage may differ if CI is hitting [GitHub API rate limits](/sbomify-action/enrichment/#license-database-rate-limits) that your machine is not. ## Next steps - [Quick start](/sbomify-action/quickstart/) - the setup wizard - [Configuration reference](/sbomify-action/configuration/) - every option - [Your CI platform](/sbomify-action/runtimes/) - moving this into a pipeline --- # SBOM Generation in Azure DevOps URL: https://sbomify.com/sbomify-action/runtimes/azure-devops/ Description: Run the sbomify action in Azure Pipelines as a container job or Docker task, with variable groups, caching and automatic VCS detection. Azure Pipelines can run the container image either as a container job, which is cleaner, or through the Docker task. ## Container job ```yaml trigger: - main pool: vmImage: ubuntu-latest container: ghcr.io/sbomify/sbomify-action steps: - checkout: self - script: sbomify-action displayName: Generate SBOM env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" - publish: $(Build.SourcesDirectory)/sbom.cdx.json artifact: sbom ``` Every step in the job runs inside the container, so the working directory and mounted source are handled for you. ## Docker task Useful when only one step needs the container: ```yaml steps: - task: Docker@2 displayName: Generate SBOM inputs: command: run arguments: > -v $(Build.SourcesDirectory):/workspace -e LOCK_FILE=requirements.txt -e OUTPUT_FILE=sbom.cdx.json -e ENRICH=true -e UPLOAD=false ghcr.io/sbomify/sbomify-action ``` ## Uploading to sbomify Store the token in a variable group backed by Azure Key Vault, or as a secret pipeline variable. ```yaml variables: - group: sbomify steps: - script: sbomify-action displayName: Generate and upload SBOM env: TOKEN: $(SBOMIFY_TOKEN) COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: "true" ENRICH: "true" ``` Secret variables are not exposed to the process environment automatically, so mapping it explicitly under `env:` as above is required. Azure DevOps does not support OIDC trusted publishing - that is currently GitHub-only. ## Versioning ```yaml env: COMPONENT_NAME: my-app COMPONENT_VERSION: $(Build.SourceVersion) ``` For tagged builds, `$(Build.SourceBranchName)` gives the tag when the trigger is a tag push. To tag a product release: ```yaml - script: sbomify-action condition: startsWith(variables['Build.SourceBranch'], 'refs/tags/') env: TOKEN: $(SBOMIFY_TOKEN) COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt COMPONENT_VERSION: $(Build.SourceBranchName) PRODUCT_RELEASE: '["your-product-id:$(Build.SourceBranchName)"]' AUGMENT: "true" ENRICH: "true" ``` ## Caching ```yaml steps: - task: Cache@2 inputs: key: 'sbomify | "$(Agent.OS)"' path: $(Build.SourcesDirectory)/.sbomify-cache displayName: Cache sbomify data - script: sbomify-action env: SBOMIFY_CACHE_DIR: $(Build.SourcesDirectory)/.sbomify-cache/sbomify SYFT_CACHE_DIR: $(Build.SourcesDirectory)/.sbomify-cache/syft GITHUB_TOKEN: $(GITHUB_TOKEN) LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" ``` Set `GITHUB_TOKEN` even though you are not on GitHub. License databases are downloaded from GitHub Releases whatever CI platform you use, and unauthenticated requests are capped at 60 per hour per IP - Microsoft-hosted agents share outbound addresses, so this limit is often already spent. When it is, enrichment degrades silently. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## VCS information Repository URL, commit SHA and branch are detected automatically, read from the git checkout in `$(Build.SourcesDirectory)`. Nothing to configure: `checkout: self` leaves a full git work tree, and the Docker task example above mounts that directory into the container. Two cases still want `sbomify.json`. One is a pipeline whose source is not a git repository - a TFVC repository, or artifacts downloaded rather than checked out. The other is an Azure Repos remote whose URL you would rather record differently. Generate the file from the build variables: ```yaml - script: | cat > sbomify.json < -v /var/run/docker.sock:/var/run/docker.sock -v $(Build.SourcesDirectory):/workspace -e DOCKER_IMAGE=my-app:$(Build.BuildId) -e OUTPUT_FILE=container-sbom.cdx.json -e ENRICH=true -e UPLOAD=false ghcr.io/sbomify/sbomify-action ``` ## Monorepos ```yaml env: WORKING_DIR: packages/my-app LOCK_FILE: package-lock.json ``` For several components, use a matrix strategy with one entry per component. ## Signing Build provenance attestation is GitHub-specific. Use [cosign](/faq/how-do-i-sign-an-sbom/), which works on any platform. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Augmentation](/sbomify-action/augmentation/) - setting VCS details manually - [Advanced](/sbomify-action/advanced/) - caching, audit trail, troubleshooting --- # SBOM Generation in Bitbucket Pipelines URL: https://sbomify.com/sbomify-action/runtimes/bitbucket/ Description: Run the sbomify action in Bitbucket Pipelines using a Docker pipe, with caching, container scanning and automatic VCS detection. Bitbucket Pipelines runs the container image through its Docker pipe mechanism. ## Minimal example ```yaml image: node:20 pipelines: default: - step: name: Build script: - npm ci artifacts: - node_modules/** - step: name: Generate SBOM script: - pipe: docker://ghcr.io/sbomify/sbomify-action:latest variables: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" artifacts: - sbom.cdx.json ``` Quote boolean values - pipe variables are strings. ## Uploading to sbomify Bitbucket does not support OIDC trusted publishing yet, so use an API token stored as a secured repository variable. ```yaml - step: name: Generate and upload SBOM script: - pipe: docker://ghcr.io/sbomify/sbomify-action:latest variables: TOKEN: $SBOMIFY_TOKEN COMPONENT_ID: your-component-id LOCK_FILE: package-lock.json AUGMENT: "true" ENRICH: "true" ``` Add `SBOMIFY_TOKEN` under Repository settings, Repository variables, and tick **Secured** so it is masked in logs. ## Versioning Use `$BITBUCKET_TAG` for tagged releases and `$BITBUCKET_COMMIT` for rolling builds: ```yaml variables: COMPONENT_NAME: my-app COMPONENT_VERSION: $BITBUCKET_TAG ``` A common pattern is a dedicated tag pipeline: ```yaml pipelines: tags: 'v*': - step: name: Release SBOM script: - pipe: docker://ghcr.io/sbomify/sbomify-action:latest variables: TOKEN: $SBOMIFY_TOKEN COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt COMPONENT_VERSION: $BITBUCKET_TAG PRODUCT_RELEASE: '["your-product-id:$BITBUCKET_TAG"]' AUGMENT: "true" ENRICH: "true" ``` See [versioning SBOMs](/guides/how-to-version-sboms/). ## Caching ```yaml pipelines: default: - step: name: Generate SBOM caches: - sbomify script: - pipe: docker://ghcr.io/sbomify/sbomify-action:latest variables: SBOMIFY_CACHE_DIR: "${BITBUCKET_CLONE_DIR}/.sbomify-cache/sbomify" SYFT_CACHE_DIR: "${BITBUCKET_CLONE_DIR}/.sbomify-cache/syft" GITHUB_TOKEN: $GITHUB_TOKEN LOCK_FILE: poetry.lock OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" definitions: caches: sbomify: .sbomify-cache ``` `GITHUB_TOKEN` is worth setting even though you are not on GitHub. License databases are downloaded from GitHub Releases, and unauthenticated requests are capped at 60 per hour per IP - shared runners hit this regularly, and when they do enrichment degrades silently. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## Container images Enable the Docker service: ```yaml - step: name: Container SBOM services: - docker script: - docker build -t my-app:$BITBUCKET_COMMIT . - pipe: docker://ghcr.io/sbomify/sbomify-action:latest variables: DOCKER_IMAGE: my-app:$BITBUCKET_COMMIT OUTPUT_FILE: container-sbom.cdx.json ENRICH: "true" UPLOAD: "false" artifacts: - container-sbom.cdx.json ``` ## VCS detection Automatic. Repository URL, commit SHA and branch or tag are read from `BITBUCKET_GIT_HTTP_ORIGIN`, `BITBUCKET_COMMIT`, `BITBUCKET_BRANCH` and `BITBUCKET_TAG`. Nothing to configure. This is Bitbucket Cloud. **Data Center** exposes a different set of variables, so set `vcs_url` in [`sbomify.json`](/sbomify-action/augmentation/) there - and note that its commit URLs live under `/projects//repos//commits/`, which the action will not guess: you get the repository URL and the SHA without a browsable link. ## Monorepos ```yaml variables: WORKING_DIR: packages/my-app LOCK_FILE: package-lock.json ``` Or use parallel steps, one per component, each with its own `COMPONENT_ID`. ## Signing Build provenance attestation is GitHub-specific. Sign with [cosign](/faq/how-do-i-sign-an-sbom/) instead - it works on any platform. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Publishing](/sbomify-action/publishing/) - tokens, releases, Dependency Track - [Advanced](/sbomify-action/advanced/) - caching, audit trail, troubleshooting --- # SBOM Generation in CircleCI URL: https://sbomify.com/sbomify-action/runtimes/circleci/ Description: Run the sbomify action in CircleCI using the container image as a Docker executor, with caching, contexts and automatic VCS detection from the job environment. CircleCI runs the container image as a Docker executor. ## Minimal example ```yaml version: 2.1 jobs: generate-sbom: docker: - image: ghcr.io/sbomify/sbomify-action environment: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" steps: - checkout - run: name: Generate SBOM command: sbomify-action - store_artifacts: path: sbom.cdx.json workflows: build-and-sbom: jobs: - generate-sbom ``` > If you have an older config calling `/sbomify.sh`, update it. That entrypoint no longer exists; the command is `sbomify-action`. ## Uploading to sbomify Put the token in a CircleCI context rather than a project environment variable, so access can be restricted to specific security groups. ```yaml jobs: generate-sbom: docker: - image: ghcr.io/sbomify/sbomify-action environment: COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: "true" ENRICH: "true" steps: - checkout - run: sbomify-action workflows: build-and-sbom: jobs: - generate-sbom: context: sbomify ``` Define `TOKEN` in the `sbomify` context. CircleCI does not support OIDC trusted publishing - that is currently GitHub-only. ## Caching ```yaml jobs: generate-sbom: docker: - image: ghcr.io/sbomify/sbomify-action environment: SBOMIFY_CACHE_DIR: /home/circleci/project/.sbomify-cache/sbomify SYFT_CACHE_DIR: /home/circleci/project/.sbomify-cache/syft LOCK_FILE: poetry.lock OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" steps: - checkout - restore_cache: keys: - sbomify-cache-v1 - run: sbomify-action - save_cache: key: sbomify-cache-v1 paths: - .sbomify-cache - store_artifacts: path: sbom.cdx.json ``` Set `GITHUB_TOKEN` in your context as well. License databases are downloaded from GitHub Releases regardless of CI platform, and unauthenticated requests are capped at 60 per hour per IP. When that limit is hit, enrichment degrades silently rather than failing. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## Versioning ```yaml environment: COMPONENT_NAME: my-app COMPONENT_VERSION: << pipeline.git.tag >> ``` Use `<< pipeline.git.revision >>` for untagged builds. To tag a product release on tagged builds only: ```yaml workflows: release: jobs: - generate-sbom: context: sbomify filters: tags: only: /^v.*/ branches: ignore: /.*/ ``` ## VCS information Repository URL, commit SHA and branch or tag are detected automatically, read from the variables CircleCI sets in the job. Nothing to configure. Detection landed after `v26.8.0`, so it is present on `master` and in any release tagged since. Older tags read the git checkout instead, which is still the fallback described below. | Field | Read from | | ------------- | ----------------------------------------------- | | Repository | `CIRCLE_REPOSITORY_URL` | | Commit | `CIRCLE_SHA1` | | Branch or tag | `CIRCLE_BRANCH`, or `CIRCLE_TAG` on a tag build | `CIRCLE_REPOSITORY_URL` is the clone URL, which is SSH for most projects; it is normalised to a browsable URL. A commit link is added for github.com, gitlab.com and bitbucket.org, plus self-hosted GitHub and GitLab. Anything else gets the repository URL and the SHA without a link rather than a guessed one that 404s. **Why the environment rather than `git`.** `checkout` leaves a detached HEAD, so the checkout can name a tag that happens to point at the commit but never the branch a build was triggered for. `CIRCLE_BRANCH` knows it. **No URL is guessed from the project slug.** `CIRCLE_PROJECT_USERNAME` and `CIRCLE_PROJECT_REPONAME` name the owner and the repository but not the host, and CircleCI serves GitHub, Bitbucket and GitLab projects alike. A URL built from that pair would look plausible while pointing at the wrong forge, so it is not built. ### Falling back to the checkout A job that never runs the `checkout` step - one building from a workspace attachment, say - gets no `CIRCLE_REPOSITORY_URL`. The action then reads the git checkout in the working directory, the behaviour CircleCI had before it became a platform of its own. That needs the `.git` directory to be present and the repository to have a remote; if neither path yields a repository URL, nothing is emitted rather than a partial claim. CircleCI's default `working_directory` is the literal string `~/project`, and that unexpanded string is exactly what `CIRCLE_WORKING_DIRECTORY` contains. The action expands it before using it, so the fallback works on the default configuration rather than silently finding no repository. ### Overriding Set the fields in `sbomify.json` when you want something other than what the job reports - an internal mirror rewritten to its public URL, for example: ```json { "vcs_url": "https://github.com/my-org/my-repo", "vcs_commit_sha": "abc123def456", "vcs_ref": "main" } ``` `sbomify.json` wins over detection. Writing `CIRCLE_REPOSITORY_URL`, `CIRCLE_SHA1` and `CIRCLE_BRANCH` into it from an earlier step is no longer necessary - those are exactly what the action reads for itself. Set `AUGMENT: "true"` when you are supplying other metadata alongside it. See [augmentation](/sbomify-action/augmentation/). ## Container images Add `setup_remote_docker`: ```yaml jobs: container-sbom: docker: - image: ghcr.io/sbomify/sbomify-action environment: DOCKER_IMAGE: my-app:latest OUTPUT_FILE: container-sbom.cdx.json ENRICH: "true" UPLOAD: "false" steps: - checkout - setup_remote_docker - run: docker build -t my-app:latest . - run: sbomify-action - store_artifacts: path: container-sbom.cdx.json ``` ## Monorepos ```yaml environment: WORKING_DIR: packages/my-app LOCK_FILE: package-lock.json ``` For several components, use a job matrix with a parameter per component. ## Signing Build provenance attestation is GitHub-specific. Use [cosign](/faq/how-do-i-sign-an-sbom/) instead. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Augmentation](/sbomify-action/augmentation/) - setting VCS details manually - [Advanced](/sbomify-action/advanced/) - caching, audit trail, troubleshooting --- # SBOM Generation in GitHub Actions URL: https://sbomify.com/sbomify-action/runtimes/github-actions/ Description: Run the sbomify action in GitHub Actions with OIDC trusted publishing, build provenance attestation, caching and matrix builds. GitHub Actions has a native action, so there is no container syntax to write. It is also the only runtime that currently supports OIDC trusted publishing and build provenance attestation, both of which depend on GitHub-issued identity tokens. ## Minimal example ```yaml name: Generate SBOM on: push: branches: [main] pull_request: jobs: sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: sbomify/sbomify-action@master env: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false - uses: actions/upload-artifact@v7 with: name: sbom path: sbom.cdx.json ``` No account required. Swap the lockfile for whichever one your project uses. ## Uploading without a token Prefer OIDC trusted publishing over a long-lived secret. **Create the trusted publisher binding in sbomify first** - Component, Settings, Trusted Publishing - or the exchange returns 403. ```yaml permissions: contents: read id-token: write jobs: sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: sbomify/sbomify-action@master env: COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: true ENRICH: true ``` The `id-token: write` permission is what makes this work. If `TOKEN` is also set it takes precedence and OIDC is skipped, so remove it to force tokenless publishing. Full details in [publishing](/sbomify-action/publishing/#oidc-trusted-publishing). ### With a token instead ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: true ENRICH: true ``` ## Attestation Sign the SBOM in the same job that produced it: ```yaml permissions: contents: read id-token: write attestations: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: sbomify/sbomify-action@master env: LOCK_FILE: Cargo.lock OUTPUT_FILE: sbom.cdx.json COMPONENT_NAME: my-app COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false - uses: actions/attest-build-provenance@v4 with: subject-path: sbom.cdx.json ``` `actions/attest-build-provenance` is **not available on private or internal repositories on Free, Pro or Team plans, or on GitHub Enterprise Server at all**. Check the [availability table](/sbomify-action/advanced/#where-attestation-is-available) before adding it, or sign with [cosign](/faq/how-do-i-sign-an-sbom/) instead. ## Container images ```yaml - uses: sbomify/sbomify-action@master env: DOCKER_IMAGE: ghcr.io/${{ github.repository }}:${{ github.sha }} OUTPUT_FILE: container-sbom.cdx.json COMPONENT_NAME: ${{ github.repository }} COMPONENT_VERSION: ${{ github.sha }} ENRICH: true UPLOAD: false ``` The image must be pullable from the runner, so push it or load it into the local daemon first. [Chainguard base images](/sbomify-action/sources/#chainguard-images) are detected automatically and their published SBOM is reused. ## Caching Worth doing - it avoids re-downloading the license database on every run, and reduces exposure to [rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ```yaml - uses: actions/cache@v6 with: path: .sbomify-cache key: sbomify-${{ runner.os }} - uses: sbomify/sbomify-action@master env: SBOMIFY_CACHE_DIR: ${{ github.workspace }}/.sbomify-cache SYFT_CACHE_DIR: ${{ github.workspace }}/.sbomify-cache/syft GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LOCK_FILE: requirements.txt ENRICH: true UPLOAD: false ``` Setting `GITHUB_TOKEN` here is strongly recommended even on GitHub Actions - it raises the license database download limit from 60 to 5,000 requests per hour. ## Monorepos The workflow-level `working-directory:` setting **does not affect this action**, because it runs in a container. Use the `working-dir` input: ```yaml - uses: sbomify/sbomify-action@master with: working-dir: packages/my-app env: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false ``` For several components, use a matrix - see [advanced usage](/sbomify-action/advanced/#monorepos). ## Tagging releases ```yaml - uses: sbomify/sbomify-action@master env: COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt COMPONENT_VERSION: ${{ github.ref_name }} PRODUCT_RELEASE: '["your-product-id:${{ github.ref_name }}"]' AUGMENT: true ENRICH: true ``` Run this on tag pushes rather than every commit. See [product releases](/sbomify-action/publishing/#product-releases). ## VCS detection Automatic. Repository URL, commit SHA and branch or tag are read from the environment and added to the SBOM, including on GitHub Enterprise Server. Nothing to configure. ## Pull requests from forks Secrets are not exposed to fork pull requests, so uploads will fail. Verify generation without uploading: ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: ${{ github.event.pull_request.head.repo.fork && 'false' || 'true' }} ``` ## Version pinning The examples on this page use `@master` so they stay correct as the action moves. Do not ship that. Pin to a release tag for something readable, or to a full 40-character commit SHA - the only reference GitHub treats as immutable - for production. The [setup wizard](/sbomify-action/quickstart/) writes SHA pins automatically, and [version pinning](/sbomify-action/advanced/#version-pinning) covers the trade-offs. ## Let the wizard write it The wizard generates a complete workflow, including SHA pins and matrix entries per lockfile: ```bash docker run --rm -it \ -v "$(pwd):/workspace" \ ghcr.io/sbomify/sbomify-action \ sbomify-action wizard ``` It writes `.github/workflows/sboms.yml` and will never overwrite a workflow you wrote yourself. See the [quick start](/sbomify-action/quickstart/). ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Publishing](/sbomify-action/publishing/) - OIDC, releases, Dependency Track - [Advanced](/sbomify-action/advanced/) - attestation, audit trail, troubleshooting --- # SBOM Generation in GitLab CI URL: https://sbomify.com/sbomify-action/runtimes/gitlab-ci/ Description: Run the sbomify action in GitLab CI using the container image, with caching, dependency scanning integration and self-managed instance support. GitLab CI runs the container image directly as the job image. Configuration goes in `variables:`, and the command is `sbomify-action`. ## Minimal example ```yaml generate-sbom: stage: test image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" script: - sbomify-action artifacts: paths: - sbom.cdx.json ``` Boolean values must be quoted - GitLab CI variables are strings. > If you have an older pipeline calling `/sbomify.sh`, update it. That entrypoint no longer exists; the command is `sbomify-action`. ## Feeding GitLab's dependency scanning GitLab natively understands CycloneDX reports, so the SBOM can populate the dependency list in the UI: ```yaml generate-sbom: stage: test image: ghcr.io/sbomify/sbomify-action variables: LOCK_FILE: package-lock.json OUTPUT_FILE: gl-sbom-report.cdx.json ENRICH: "true" UPLOAD: "false" script: - sbomify-action artifacts: reports: cyclonedx: gl-sbom-report.cdx.json ``` Because the SBOM is enriched, the dependency list shows licenses and suppliers that a plain scan would leave blank. ## Uploading to sbomify GitLab CI does not support OIDC trusted publishing yet, so use an API token stored as a masked, protected CI/CD variable. ```yaml generate-sbom: stage: test image: ghcr.io/sbomify/sbomify-action variables: COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: "true" ENRICH: "true" script: - sbomify-action ``` Set `TOKEN` under Settings, CI/CD, Variables. Mark it **Masked** so it is hidden in job logs, and **Protected** if only protected branches should upload. ## Caching ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action cache: key: sbomify-cache paths: - .sbomify-cache/ variables: SBOMIFY_CACHE_DIR: "${CI_PROJECT_DIR}/.sbomify-cache/sbomify" SYFT_CACHE_DIR: "${CI_PROJECT_DIR}/.sbomify-cache/syft" LOCK_FILE: poetry.lock OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" script: - sbomify-action ``` **Set `GITHUB_TOKEN` as well.** License databases are downloaded from GitHub Releases regardless of which CI platform you use, and unauthenticated requests are capped at 60 per hour per IP - a limit shared runners routinely hit. When it is exceeded, enrichment degrades silently. Any GitHub token with public read scope will do. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## Container images Scanning an image needs a Docker daemon: ```yaml container-sbom: stage: test image: ghcr.io/sbomify/sbomify-action services: - docker:dind variables: DOCKER_HOST: tcp://docker:2376 DOCKER_TLS_CERTDIR: "/certs" DOCKER_IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" OUTPUT_FILE: container-sbom.cdx.json ENRICH: "true" UPLOAD: "false" before_script: - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY" - docker pull "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" script: - sbomify-action artifacts: paths: - container-sbom.cdx.json ``` ## Tagging releases ```yaml release-sbom: stage: deploy image: ghcr.io/sbomify/sbomify-action rules: - if: $CI_COMMIT_TAG variables: COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt COMPONENT_VERSION: "$CI_COMMIT_TAG" PRODUCT_RELEASE: '["your-product-id:$CI_COMMIT_TAG"]' AUGMENT: "true" ENRICH: "true" script: - sbomify-action ``` ## VCS detection Automatic. Project URL, commit SHA and ref name are read from `CI_PROJECT_URL`, `CI_COMMIT_SHA` and `CI_COMMIT_REF_NAME`, and **self-managed instances are supported** - the server URL is taken from `CI_SERVER_URL` rather than assumed. To override, for example when your external URL differs from the internal one, set `vcs_url` in [`sbomify.json`](/sbomify-action/augmentation/). ## Monorepos ```yaml variables: WORKING_DIR: packages/my-app LOCK_FILE: package-lock.json ``` Or run several jobs with a matrix: ```yaml generate-sbom: image: ghcr.io/sbomify/sbomify-action parallel: matrix: - NAME: frontend LOCK_FILE: frontend/package-lock.json - NAME: backend LOCK_FILE: backend/requirements.txt variables: OUTPUT_FILE: "sbom-$NAME.cdx.json" ENRICH: "true" UPLOAD: "false" script: - sbomify-action artifacts: paths: - "sbom-$NAME.cdx.json" ``` ## Signing Build provenance attestation is GitHub-specific. On GitLab, sign with [cosign](/faq/how-do-i-sign-an-sbom/), which works anywhere and supports keyless signing via GitLab's OIDC provider. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Publishing](/sbomify-action/publishing/) - tokens, releases, Dependency Track - [Advanced](/sbomify-action/advanced/) - caching, audit trail, troubleshooting --- # SBOM Generation in Jenkins URL: https://sbomify.com/sbomify-action/runtimes/jenkins/ Description: Run the sbomify action in Jenkins declarative and scripted pipelines, with credentials, caching and VCS detection from the Git plugin's variables. Jenkins runs the container image as a pipeline agent. Both declarative and scripted pipelines work. ## Declarative pipeline ```groovy pipeline { agent { docker { image 'ghcr.io/sbomify/sbomify-action' } } environment { LOCK_FILE = 'requirements.txt' OUTPUT_FILE = 'sbom.cdx.json' ENRICH = 'true' UPLOAD = 'false' } stages { stage('Generate SBOM') { steps { sh 'sbomify-action' } } stage('Archive') { steps { archiveArtifacts artifacts: 'sbom.cdx.json' } } } } ``` > If you have an older pipeline calling `/sbomify.sh`, update it. That entrypoint no longer exists; the command is `sbomify-action`. ## With credentials Store the token in the Jenkins credential store as a secret text credential, and inject it only where needed: ```groovy pipeline { agent { docker { image 'ghcr.io/sbomify/sbomify-action' } } environment { COMPONENT_ID = 'your-component-id' LOCK_FILE = 'requirements.txt' AUGMENT = 'true' ENRICH = 'true' } stages { stage('Generate and upload SBOM') { steps { withCredentials([string(credentialsId: 'sbomify-token', variable: 'TOKEN')]) { sh 'sbomify-action' } } } } } ``` `withCredentials` masks the value in console output. Avoid putting the token in a global `environment` block, where it is in scope for every stage. Jenkins does not support OIDC trusted publishing - that is currently GitHub-only. ## Scripted pipeline ```groovy node { checkout scm docker.image('ghcr.io/sbomify/sbomify-action').inside { withCredentials([string(credentialsId: 'sbomify-token', variable: 'TOKEN')]) { sh ''' export COMPONENT_ID="your-component-id" export LOCK_FILE="requirements.txt" export ENRICH="true" sbomify-action ''' } } archiveArtifacts artifacts: 'sbom.cdx.json', allowEmptyArchive: false } ``` ## VCS information Repository URL, commit SHA and branch are detected automatically, read from the variables the Git plugin exports into the build. Nothing to configure. Detection landed after `v26.8.0`, so it is present on `master` and in any release tagged since. Older tags read the git checkout instead, which is still the fallback described below. | Field | Read from | | ------------- | --------------------------------------------------------------------------------- | | Repository | `GIT_URL`, or `GIT_URL_1` when the job has more than one SCM | | Commit | `GIT_COMMIT` | | Branch or tag | `GIT_LOCAL_BRANCH`, then `TAG_NAME`, `CHANGE_BRANCH`, `BRANCH_NAME`, `GIT_BRANCH` | The ref list is in that order for a reason. On a multibranch pull request build `BRANCH_NAME` is Jenkins' own `PR-42` - a job name, not a ref anyone can check out - so `CHANGE_BRANCH`, the branch the request came _from_, is preferred. `GIT_BRANCH` is remote-tracking (`origin/main`, or `refs/remotes/origin/main` on older plugin versions), and the remote is stripped before the branch is recorded. An SSH remote, or one carrying an embedded credential, is normalised to a browsable URL. A commit link is added for github.com, gitlab.com and bitbucket.org, plus self-hosted GitHub and GitLab. An internal Git server gets the repository URL and the SHA without a link rather than a guessed one that 404s. **Why the environment rather than `git`.** `checkout scm` leaves a detached HEAD, so the checkout can name a tag that happens to point at the commit and nothing else. Jenkins knows which branch the job was triggered for, and on a pull request it knows which branch the request came from. Neither is recoverable from the working directory. ### Falling back to the checkout Jenkins is VCS-agnostic. A job on Subversion or Perforce, or with no SCM at all, exports none of the `GIT_*` variables, and so does a scripted pipeline whose `checkout` step does not publish them. When `GIT_URL` is missing the action reads the git checkout in the workspace instead - the behaviour Jenkins had before it became a platform of its own. Two things have to be true for that, and a normal `checkout scm` gives you both: the `.git` directory is present in the workspace the container sees, and the repository has a remote (`origin`, or the first one configured). If neither path yields a repository URL, nothing is emitted rather than a partial claim. ### Overriding Set the fields in `sbomify.json` when you want something other than what the job reports - an internal mirror rewritten to its public URL, for example: ```json { "vcs_url": "https://github.com/my-org/my-repo", "vcs_commit_sha": "abc123def456", "vcs_ref": "main" } ``` `sbomify.json` wins over detection. Writing `GIT_URL`, `GIT_COMMIT` and `GIT_BRANCH` into it from an earlier stage is no longer necessary - those are exactly what the action reads for itself. Set `AUGMENT: 'true'` when you are supplying other metadata alongside it. See [augmentation](/sbomify-action/augmentation/). ## Versioning Use the tag if there is one, and fall back to the commit: ```groovy environment { COMPONENT_NAME = 'my-app' COMPONENT_VERSION = "${env.TAG_NAME ?: env.GIT_COMMIT}" } ``` ## Caching Mount a persistent directory on the agent: ```groovy agent { docker { image 'ghcr.io/sbomify/sbomify-action' args '-v /var/jenkins_cache/sbomify:/cache' } } environment { SBOMIFY_CACHE_DIR = '/cache/sbomify' SYFT_CACHE_DIR = '/cache/syft' } ``` Also set `GITHUB_TOKEN`. License databases come from GitHub Releases whatever CI you use, and unauthenticated requests are limited to 60 per hour per IP. Long-lived Jenkins agents with a stable outbound IP hit that ceiling quickly, and when they do enrichment degrades silently. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## Container images The agent needs access to a Docker daemon, usually by mounting the socket: ```groovy agent { docker { image 'ghcr.io/sbomify/sbomify-action' args '-v /var/run/docker.sock:/var/run/docker.sock' } } environment { DOCKER_IMAGE = "my-app:${env.BUILD_NUMBER}" OUTPUT_FILE = 'container-sbom.cdx.json' ENRICH = 'true' UPLOAD = 'false' } ``` Mounting the Docker socket grants the container control of the host daemon. Use a rootless or remote daemon where you can. ## Monorepos ```groovy environment { WORKING_DIR = 'packages/my-app' LOCK_FILE = 'package-lock.json' } ``` For several components, use a `matrix` block or parallel stages, each with its own `COMPONENT_ID`. ## Signing Build provenance attestation is GitHub-specific. Use [cosign](/faq/how-do-i-sign-an-sbom/), which runs anywhere. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Augmentation](/sbomify-action/augmentation/) - setting VCS details manually - [Advanced](/sbomify-action/advanced/) - caching, audit trail, troubleshooting --- # SBOM Generation in TeamCity URL: https://sbomify.com/sbomify-action/runtimes/teamcity/ Description: Run the sbomify action in TeamCity using the Docker Wrapper build feature or a Kotlin DSL configuration, with caching, parameters and manual VCS configuration. TeamCity runs the container image through the **Docker Wrapper** build feature, which wraps a Command Line step so it executes inside a container. ## Minimal setup In the build configuration: 1. Add a **Command Line** build step. 2. Set **Custom script** to `sbomify-action`. 3. Add the **Docker Wrapper** build feature to that step, with **Docker image** set to `ghcr.io/sbomify/sbomify-action`. No extra run arguments are needed: the wrapper mounts the checkout directory and runs the script inside it. 4. Add the configuration as environment variables under **Parameters**, prefixed `env.`: ```text env.LOCK_FILE = requirements.txt env.OUTPUT_FILE = sbom.cdx.json env.ENRICH = true env.UPLOAD = false ``` TeamCity mounts the checkout directory into the container automatically, so the lockfile path is relative to your repository root. ## Kotlin DSL If your configuration is versioned: ```kotlin object GenerateSbom : BuildType({ name = "Generate SBOM" params { param("env.LOCK_FILE", "requirements.txt") param("env.OUTPUT_FILE", "sbom.cdx.json") param("env.ENRICH", "true") param("env.UPLOAD", "false") } vcs { root(DslContext.settingsRoot) } steps { script { name = "Generate SBOM" scriptContent = "sbomify-action" dockerImage = "ghcr.io/sbomify/sbomify-action" } } artifactRules = "sbom.cdx.json" }) ``` ## Uploading to sbomify TeamCity does not support OIDC trusted publishing - that is currently GitHub-only. Use an API token stored as a **password** parameter so it is masked in the build log. ```kotlin params { password("env.TOKEN", "credentialsJSON:...", display = ParameterDisplay.HIDDEN) param("env.COMPONENT_ID", "your-component-id") param("env.LOCK_FILE", "requirements.txt") param("env.AUGMENT", "true") param("env.ENRICH", "true") } ``` Password parameters are the only kind TeamCity masks in logs. A plain `param` holding a token will be printed. ## Versioning TeamCity exposes the build number and VCS revision as parameters: ```text env.COMPONENT_NAME = my-app env.COMPONENT_VERSION = %build.vcs.number% ``` For tagged releases, use a VCS trigger on tags and read the branch name: ```text env.COMPONENT_VERSION = %teamcity.build.branch% env.PRODUCT_RELEASE = ["your-product-id:%teamcity.build.branch%"] ``` ## Caching TeamCity agents keep their working directories between builds, so pointing the caches at a path outside the checkout directory persists them across runs on the same agent: ```text env.SBOMIFY_CACHE_DIR = %system.agent.home.dir%/cache/sbomify env.SYFT_CACHE_DIR = %system.agent.home.dir%/cache/syft env.SBOMIFY_TOOL_CACHE = %system.agent.home.dir%/cache/sbomify-runtimes env.GITHUB_TOKEN = %github.token% ``` Mount that directory into the container by adding it to the Docker Wrapper's run arguments: ```text -v %system.agent.home.dir%/cache:/cache ``` Two things are worth caching here. The [tool runtimes](/sbomify-action/advanced/#tool-runtimes) are downloaded on first use, so without a cache every build re-fetches them. And `GITHUB_TOKEN` matters even though you are not on GitHub: license databases come from GitHub Releases, unauthenticated requests are capped at 60 per hour per IP, and a pool of agents behind one NAT address exhausts that quickly. When it happens, enrichment degrades silently. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## VCS information Repository URL, commit SHA and branch are detected automatically, the same as on GitHub, GitLab and Bitbucket. Detection landed after `v26.8.0`, so it is present on `master` and in any release tagged since - if you pin to an older tag, use the manual fallback below. TeamCity is not like the other three, and the differences are worth knowing. **The details are configuration parameters, not environment variables.** TeamCity exposes only `TEAMCITY_VERSION`, `BUILD_VCS_NUMBER` and `TEAMCITY_BUILD_PROPERTIES_FILE` to the build. The repository URL and branch live in the build properties file, which points at a second file holding the rest. The action follows that chain for you - but a **containerised step may not be able to see those files**, and this page recommends running in a container. If the properties file is not reachable, set the values explicitly: ```text -e SBOMIFY_VCS_URL=https://git.example.com/team/app.git -e SBOMIFY_VCS_REF=%teamcity.build.vcs.branch.MyVcsRootId% ``` `SBOMIFY_VCS_URL` is always trusted as an operator assertion, and takes precedence over anything detected. **Only Git roots are recorded.** TeamCity is VCS-agnostic - a root can be Subversion, Perforce, TFVC or Mercurial, and under those `BUILD_VCS_NUMBER` is a revision number or changelist rather than a commit hash. The SBOM's VCS fields are Git-shaped, so recording a Perforce changelist there would put a false claim into a document you may go on to sign. TeamCity exposes no VCS-type parameter, so the action emits nothing unless the URL positively identifies Git: a `.git` suffix, a recognised Git host, or an `ssh://` or `git@host:path` form. The practical consequence: **a self-hosted Git server whose URL has neither a `.git` suffix nor a known host** - `https://git.example.com/team/app`, say - cannot be detected. Set `SBOMIFY_VCS_URL` and it is recorded as given. For an attestation artifact, omitting provenance is better than asserting a repository that might not be Git. **No commit URL is emitted**, unlike the other three runtimes. TeamCity is host-agnostic, and the path to a commit differs by forge - `/commit/`, `/-/commit/`, `/commits/` - so the repository URL and the SHA are recorded without a browsable link rather than guessing one that may not resolve. ### Manual fallback To set everything yourself instead, generate `sbomify.json` from build parameters in an earlier Command Line step: ```bash cat > sbomify.json < **Do not use `%teamcity.build.branch%` here.** On the default branch it reports the literal string `` when a branch specification is configured ([TW-23699](https://youtrack.jetbrains.com/issue/TW-23699)), and is absent entirely when one is not. Neither gives you the branch name. Use `%teamcity.build.vcs.branch.%`, substituting your VCS root's ID. ## Container images Scanning an image needs access to a Docker daemon. TeamCity agents that already run Docker builds have one; add the socket to the wrapper's run arguments: ```text -v /var/run/docker.sock:/var/run/docker.sock ``` ```text env.DOCKER_IMAGE = my-app:%build.number% env.OUTPUT_FILE = container-sbom.cdx.json env.ENRICH = true env.UPLOAD = false ``` Mounting the socket gives the container control of the host daemon. Prefer a rootless or remote daemon where your agents support it. ## Monorepos ```text env.WORKING_DIR = packages/my-app env.LOCK_FILE = package-lock.json ``` For several components, use a build configuration per component, each with its own `COMPONENT_ID`, or a single configuration with a matrix parameter. ## Signing Build provenance attestation is GitHub-specific. Sign with [cosign](/faq/how-do-i-sign-an-sbom/) instead, which runs anywhere. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Augmentation](/sbomify-action/augmentation/) - setting VCS details manually - [Advanced](/sbomify-action/advanced/) - tool runtimes, caching, troubleshooting --- # SBOM Generation in Travis CI URL: https://sbomify.com/sbomify-action/runtimes/travis/ Description: Run the sbomify action in Travis CI with the container image, including caching, encrypted tokens and VCS detection from the job environment. Travis CI jobs run on a virtual machine rather than inside a container of your choosing, so the integration is a plain `docker run` from the job with the `docker` service enabled. ## Minimal example ```yaml language: minimal services: - docker script: - | docker run --rm \ -v "$TRAVIS_BUILD_DIR:/workspace" \ -e TRAVIS -e TRAVIS_COMMIT -e TRAVIS_BRANCH \ -e TRAVIS_TAG -e TRAVIS_PULL_REQUEST_BRANCH \ -e LOCK_FILE=requirements.txt \ -e OUTPUT_FILE=sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` The bare `-e TRAVIS` form forwards the variable's value from the job into the container. That part matters: the job runs on the VM, and `docker run` passes nothing through unless you ask it to. Without those five the container sees no Travis environment at all, is treated as a local run, and records no repository details - see [VCS information](#vcs-information). ## Uploading to sbomify Define `TOKEN` as an encrypted environment variable in the repository settings, or with `travis encrypt`, and forward it the same way: ```yaml script: - | docker run --rm \ -v "$TRAVIS_BUILD_DIR:/workspace" \ -e TRAVIS -e TRAVIS_COMMIT -e TRAVIS_BRANCH \ -e TRAVIS_TAG -e TRAVIS_PULL_REQUEST_BRANCH \ -e TOKEN \ -e COMPONENT_ID=your-component-id \ -e LOCK_FILE=requirements.txt \ -e AUGMENT=true \ -e ENRICH=true \ ghcr.io/sbomify/sbomify-action ``` Leave "Display value in build log" off, and keep the variable out of pull request builds unless you need it there - Travis withholds encrypted variables from forked pull requests by default, which is the behaviour you want. Travis CI does not support OIDC trusted publishing; that is currently GitHub-only. ## Caching Travis restores declared directories between builds, so point the tool caches at one of them and mount it into the container: ```yaml cache: directories: - $HOME/.sbomify-cache script: - | docker run --rm \ -v "$TRAVIS_BUILD_DIR:/workspace" \ -v "$HOME/.sbomify-cache:/cache" \ -e TRAVIS -e TRAVIS_COMMIT -e TRAVIS_BRANCH \ -e TRAVIS_TAG -e TRAVIS_PULL_REQUEST_BRANCH \ -e SBOMIFY_CACHE_DIR=/cache/sbomify \ -e SYFT_CACHE_DIR=/cache/syft \ -e SBOMIFY_TOOL_CACHE=/cache/runtimes \ -e LOCK_FILE=poetry.lock \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` Forward `GITHUB_TOKEN` as well. License databases come from GitHub Releases whatever CI you are on, and unauthenticated requests are capped at 60 per hour per IP - when that limit is hit, enrichment degrades silently rather than failing. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## Versioning Use the tag when there is one and fall back to the commit: ```yaml script: - | docker run --rm \ -v "$TRAVIS_BUILD_DIR:/workspace" \ -e TRAVIS -e TRAVIS_COMMIT -e TRAVIS_BRANCH \ -e TRAVIS_TAG -e TRAVIS_PULL_REQUEST_BRANCH \ -e COMPONENT_NAME=my-app \ -e COMPONENT_VERSION="${TRAVIS_TAG:-$TRAVIS_COMMIT}" \ -e LOCK_FILE=requirements.txt \ ghcr.io/sbomify/sbomify-action ``` To upload on tagged builds only, guard the stage with `if: tag IS present`. ## VCS information Repository URL, commit SHA and branch or tag are detected automatically. Detection landed after `v26.8.0`, so it is present on `master` and in any release tagged since. | Field | Read from | | ------------- | --------------------------------------------------------------------- | | Repository | The git checkout (`git remote`) | | Commit | `TRAVIS_COMMIT`, falling back to the checkout | | Branch or tag | `TRAVIS_TAG`, then `TRAVIS_PULL_REQUEST_BRANCH`, then `TRAVIS_BRANCH` | Travis is the one platform here whose repository URL comes from the checkout rather than the vendor, and that is deliberate. Travis publishes only `TRAVIS_REPO_SLUG`, an `owner/repo` pair with no host attached, and it serves GitHub, Bitbucket, GitLab and Assembla projects alike. Turning that pair into a URL means guessing the forge, and a link that lands on the wrong host is worse than no link at all. The remote in the checkout says which host without guessing. The commit and the ref come from the job because the checkout cannot answer them properly: Travis clones with `--branch` and then checks out the commit, leaving a detached HEAD that can name a tag and nothing else. `TRAVIS_TAG` comes first because on a tag build `TRAVIS_BRANCH` repeats the tag name rather than naming a branch. `TRAVIS_PULL_REQUEST_BRANCH` comes before `TRAVIS_BRANCH` because on a pull request build `TRAVIS_BRANCH` is the branch being merged _into_, while the source branch is the one this build actually built. A commit link is added for github.com, gitlab.com and bitbucket.org, plus self-hosted GitHub and GitLab. Anything else gets the repository URL and the SHA without a link rather than a guessed one that 404s. ### Two things have to be true - **The `.git` directory has to be inside the mount.** `-v "$TRAVIS_BUILD_DIR:/workspace"` from the build directory gives you that; a mount of only your lockfile does not. Without a repository URL nothing is emitted, since Travis publishes none of its own to fall back on. - **The Travis variables have to be forwarded.** A `docker run` with no `-e TRAVIS` is not recognisably a Travis job from inside the container, so it counts as a local run - where reading the checkout is opt-in and off by default. Forward `TRAVIS` at minimum; forward `TRAVIS_COMMIT`, `TRAVIS_BRANCH`, `TRAVIS_TAG` and `TRAVIS_PULL_REQUEST_BRANCH` to get the ref the job was triggered for rather than whatever the detached HEAD can name. ### Overriding Set the fields in `sbomify.json` when you want something other than the remote recorded - an internal mirror rewritten to its public URL, for example: ```json { "vcs_url": "https://github.com/my-org/my-repo", "vcs_commit_sha": "abc123def456", "vcs_ref": "main" } ``` `sbomify.json` wins over detection. Set `AUGMENT=true` when you are supplying other metadata alongside it. See [augmentation](/sbomify-action/augmentation/). ## Container images The Docker daemon is already there once the `docker` service is enabled, so build the image first and point the action at it: ```yaml services: - docker script: - docker build -t my-app:latest . - | docker run --rm \ -v "$TRAVIS_BUILD_DIR:/workspace" \ -v /var/run/docker.sock:/var/run/docker.sock \ -e TRAVIS -e TRAVIS_COMMIT -e TRAVIS_BRANCH \ -e TRAVIS_TAG -e TRAVIS_PULL_REQUEST_BRANCH \ -e DOCKER_IMAGE=my-app:latest \ -e OUTPUT_FILE=container-sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` Mounting the Docker socket grants the container control of the host daemon. On a throwaway Travis VM that is a smaller concern than on a long-lived agent, but it is worth knowing. ## Monorepos ```yaml -e WORKING_DIR=packages/my-app -e LOCK_FILE=package-lock.json ``` For several components, use a build matrix with one `COMPONENT_ID` per entry. ## Signing Build provenance attestation is GitHub-specific. Use [cosign](/faq/how-do-i-sign-an-sbom/), which runs anywhere. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Augmentation](/sbomify-action/augmentation/) - setting VCS details manually - [Advanced](/sbomify-action/advanced/) - caching, audit trail, troubleshooting --- # SBOM Generation on Any Container Runner URL: https://sbomify.com/sbomify-action/runtimes/docker/ Description: Run the sbomify action with plain Docker or Podman on any CI platform - Drone, Woodpecker, TeamCity, Buildkite, Concourse - or from a shell script. The container image is the universal integration. Any platform that can run a container can run this, whether or not it has a dedicated page here. ## The pattern ```bash docker run --rm \ -v "$(pwd):/workspace" \ -e LOCK_FILE=requirements.txt \ -e OUTPUT_FILE=sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` Two things matter: 1. **Mount your repository at `/workspace`.** That is the image's working directory, so no `-w` is needed. Any other mount point works as long as `-w` points at it - including an existing `-v "$(pwd):/github/workspace" -w /github/workspace`, which keeps working unchanged. Keep the mount and the `-w` in step: output paths resolve against the working directory, so a mount without a matching `-w` leaves your SBOM inside the container. 2. **Pass configuration as environment variables.** The image entrypoint is `sbomify-action`, so no command is needed. Podman works identically - substitute `podman run`. ## Uploading ```bash docker run --rm \ -v "$(pwd):/workspace" \ -e TOKEN="$SBOMIFY_TOKEN" \ -e COMPONENT_ID=your-component-id \ -e LOCK_FILE=requirements.txt \ -e AUGMENT=true \ -e ENRICH=true \ ghcr.io/sbomify/sbomify-action ``` Take the token from your platform's secret store rather than hardcoding it. Passing secrets with `-e` exposes them in the process list on the host; if that matters, use `--env-file` with a file mode of `0600`, or your container runtime's secret mechanism. ## Caching Use a named volume so the license database survives between runs: ```bash docker volume create sbomify-cache docker run --rm \ -v "$(pwd):/workspace" \ -v sbomify-cache:/cache \ -e SBOMIFY_CACHE_DIR=/cache/sbomify \ -e SYFT_CACHE_DIR=/cache/syft \ -e SBOMIFY_TOOL_CACHE=/cache/runtimes \ -e GITHUB_TOKEN="$GITHUB_TOKEN" \ -e LOCK_FILE=requirements.txt \ -e OUTPUT_FILE=sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` `GITHUB_TOKEN` matters on every platform. License databases are downloaded from GitHub Releases, and unauthenticated requests are capped at 60 per hour per IP. When that is exceeded, enrichment degrades silently. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## Container images Scanning an image needs access to a Docker daemon: ```bash docker run --rm \ -v /var/run/docker.sock:/var/run/docker.sock \ -v "$(pwd):/workspace" \ -e DOCKER_IMAGE=my-app:latest \ -e OUTPUT_FILE=container-sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` Mounting the Docker socket gives the container control of the host daemon. Prefer a rootless or remote daemon where your platform supports it. Pulling from a registry rather than a local daemon avoids the socket entirely. ## VCS information Repository details are auto-detected on every runtime - from the vendor's own variables where it publishes them, and from the git checkout you mounted everywhere else (see [VCS detection](#vcs-detection) below). Set them in `sbomify.json` when you want something else recorded, or when there is no checkout to read: ```json { "vcs_url": "https://git.example.com/my-org/my-repo", "vcs_commit_sha": "abc123def456", "vcs_ref": "main", "supplier": {"name": "My Company"}, "lifecycle_phase": "build" } ``` Generate it from whatever variables your platform provides, then set `AUGMENT=true`. See [augmentation](/sbomify-action/augmentation/). ## Platform examples The syntax differs; the substance does not. **Drone CI and Woodpecker** ```yaml steps: - name: generate-sbom image: ghcr.io/sbomify/sbomify-action commands: - sbomify-action environment: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: "true" UPLOAD: "false" ``` **Buildkite** ```yaml steps: - label: "Generate SBOM" plugins: - docker#v5.11.0: image: "ghcr.io/sbomify/sbomify-action" workdir: /workspace environment: - LOCK_FILE=requirements.txt - OUTPUT_FILE=sbom.cdx.json - ENRICH=true - UPLOAD=false ``` **Concourse** ```yaml jobs: - name: generate-sbom plan: - get: repo - task: sbom config: platform: linux image_resource: type: registry-image source: { repository: ghcr.io/sbomify/sbomify-action } inputs: - name: repo outputs: - name: sbom params: LOCK_FILE: repo/requirements.txt OUTPUT_FILE: sbom/sbom.cdx.json ENRICH: "true" UPLOAD: "false" run: path: sbomify-action ``` **TeamCity** has [its own page](/sbomify-action/runtimes/teamcity/). **A plain shell script** - the `docker run` invocation at the top of this page works in cron, a Makefile, or a deployment script. ## VCS detection Repository URL, commit SHA and branch are detected from the git checkout you mounted, so a plain `docker run` on any CI system records provenance without configuration. It needs the `.git` directory inside the mount - `-v "$(pwd):/workspace"` from a repository root gives you that - and a remote on the repository. One thing to know: the action treats a run as CI when the environment sets `CI=true` or a vendor variable it recognises (`CIRCLECI`, `TRAVIS`, `TF_BUILD`, `BUILDKITE`, `DRONE`, `APPVEYOR`, `CODEBUILD_BUILD_ID`, or one of the Jenkins markers `JENKINS_URL`, `JENKINS_HOME`, `HUDSON_HOME`, `JENKINS_NODE_COOKIE`, `JENKINS_SERVER_COOKIE`). Nearly every CI system sets one of those. If yours does not - a cron job or a shell script on a build box, say - pass `-e CI=true`, or `-e SBOMIFY_LOCAL_VCS=true` to get the same detection without claiming to be CI. Otherwise the run counts as local, where reading the checkout is opt-in. A `docker run` passes nothing from the surrounding job into the container unless you ask it to, which matters on platforms that have a dedicated integration of their own: forward the vendor's variables with the bare `-e NAME` form and the action reads them, rather than falling back to the checkout. See [Jenkins](/sbomify-action/runtimes/jenkins/#vcs-information), [CircleCI](/sbomify-action/runtimes/circleci/#vcs-information) and [Travis CI](/sbomify-action/runtimes/travis/#vcs-information). `sbomify.json` overrides whatever is detected. See [augmentation](/sbomify-action/augmentation/#automatic-vcs-detection). ## What is in the image The image is deliberately small: Python, the sbomify CLI (which brings `cyclonedx-py` with it), `conan` for C and C++ metadata, and `git`. Everything else - Syft, cdxgen, the JVM toolchain, Go, Rust, PHP, .NET, `crane` and `cosign` - is **downloaded on first use**, verified against a digest pinned at build time, and cached. You do not install anything; the tool fetches exactly the versions it was tested against. Two practical consequences: - **Cache the runtimes** or every run re-downloads them. Point `SBOMIFY_TOOL_CACHE` at a volume, as in the caching example above. See [tool runtimes](/sbomify-action/advanced/#tool-runtimes). - **Air-gapped runners need `SBOMIFY_FETCH_RUNTIMES=0`**, plus whatever generators you need preinstalled. Without them the run falls back to a lesser generator rather than failing, so check the output. The container runs as root, because it needs to write to the mounted workspace. Files it creates will be root-owned on the host unless you pass `--user`. ## Next steps - [Configuration reference](/sbomify-action/configuration/) - every option - [Augmentation](/sbomify-action/augmentation/) - your business metadata, and overriding detected VCS details - [Advanced](/sbomify-action/advanced/) - caching, audit trail, troubleshooting --- # sbomify Action Configuration Reference URL: https://sbomify.com/sbomify-action/configuration/ Description: Every input, environment variable and CLI flag for the sbomify action, including precedence rules and deprecated aliases. Configuration is done through **environment variables**, and they behave identically on every runtime. The GitHub Action declares only a handful of native inputs; everything else is passed via `env:` there, `variables:` in GitLab, and `-e` flags with plain Docker. ## Action inputs (GitHub Actions only) These are the only values passed with `with:` rather than `env:`. Each maps to the environment variable of the same name. | Input | Default | Description | | ---------------- | ------------- | -------------------------------------------------------------------------------------------- | | `working-dir` | empty | Working directory, relative to the repository root or absolute. Must be under the workspace. | | `component-purl` | none | Override the component PURL, for example `pkg:npm/@scope/name@1.0.0`. | | `bom-type` | `sbom` | Artifact type recorded on upload: `sbom`, `vex`, `cbom` or `hbom`. | | `oidc-audience` | `sbomify.com` | OIDC audience for trusted publishing. Override for self-hosted. | > **Monorepo gotcha:** the workflow-level `working-directory:` setting has no effect on this action, because it runs in a container. Use the `working-dir` input instead. ## Input source Exactly one of these is required. | Variable | Description | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `LOCK_FILE` | Path to a lockfile. Set to `none` for additional-packages-only mode. | | `SBOM_FILE` | Path to an existing SBOM to process rather than generate. Set to `none` for additional-packages-only mode. | | `DOCKER_IMAGE` | Container image reference, for example `nginx:latest`. | | `SOURCE_DIR` | Directory to scan with Syft. **Last resort** - prefer `LOCK_FILE` whenever one exists, see [directory scanning](/sbomify-action/sources/#directory-scanning). | ## Output | Variable | Default | Description | | -------------- | ------------------ | ----------------------------------------------------------------------------------------------------- | | `OUTPUT_FILE` | `sbom_output.json` | Where to write the final SBOM. | | `SBOM_FORMAT` | `cyclonedx` | `cyclonedx` or `spdx`. | | `SPEC_VERSION` | `1.6` or `2.3` | Spec version to generate, for example `1.7` or `2.2`. SPDX 3.0.1 cannot be generated, only processed. | | `BOM_TYPE` | `sbom` | `sbom`, `vex`, `cbom` or `hbom`. | Non-SBOM `BOM_TYPE` values are uploaded verbatim to sbomify: augmentation, enrichment, overrides, package injection and finalization fixups are all skipped, and Dependency Track and `PRODUCT_RELEASE` are rejected. ## Processing | Variable | Default | Description | | -------------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ENRICH` | `false` | Add per-component metadata from package registries. | | `AUGMENT` | `false` | Add organisational metadata from `sbomify.json` or the sbomify API. | | `OVERRIDE_SBOM_METADATA` | `false` | Let augmentation overwrite existing metadata instead of only filling gaps. | | `COMPONENT_NAME` | none | Override the component name. | | `COMPONENT_VERSION` | none | Override the component version. | | `COMPONENT_PURL` | none | Add or override the component PURL. | | `ADDITIONAL_PACKAGES` | none | Inline PURLs to inject, comma or newline separated. | | `ADDITIONAL_PACKAGES_FILE` | `additional_packages.txt` | Path to a file of PURLs, one per line. | | `DISABLE_VCS_AUGMENTATION` | `false` | Disable automatic VCS detection, whether it comes from the CI environment or the git checkout. | | `SBOMIFY_LOCAL_VCS` | `false` | Read VCS details from the git checkout on a non-CI run. Detection is automatic on CI and opt-in locally. | | `SUBMODULE_PATH` | none | Treat the component as a git submodule pinned at this path. Resolves the pin to a version and reuses an existing SBOM at that version if there is one. Requires `LOCK_FILE` and the `sbomify` destination. | | `WORKING_DIR` | none | Working directory. Relative paths resolve against the current directory, or against the runner workspace on GitHub Actions, where the path must also stay inside it. Prefer the `working-dir` input there. | ## Uploading | Variable | Default | Description | | ------------------------ | ------------------------- | ------------------------------------------------------------------------------- | | `UPLOAD` | `true` | Set to `false` to generate without uploading anywhere. | | `UPLOAD_DESTINATIONS` | `sbomify` | Comma-separated: `sbomify`, `dependency-track`. | | `TOKEN` | none | sbomify API token. | | `SBOMIFY_TOKEN` | none | sbomify API token. **Takes precedence over `TOKEN`.** | | `COMPONENT_ID` | none | sbomify component ID. Required for upload and for sbomify-sourced augmentation. | | `PRODUCT_RELEASE` | none | JSON array of product and version strings. | | `API_BASE_URL` | `https://app.sbomify.com` | Override for self-hosted instances. | | `OIDC_AUDIENCE` | `sbomify.com` | Audience for trusted publishing. Derived from `API_BASE_URL` when self-hosted. | | `SBOMIFY_UPLOAD_TIMEOUT` | `120` | Upload timeout in seconds. Raise for very large SBOMs. | Credential precedence is the `--token` flag, then `SBOMIFY_TOKEN`, then `TOKEN`. If no token is present on GitHub Actions and the workflow grants `id-token: write`, [OIDC trusted publishing](/sbomify-action/publishing/#oidc-trusted-publishing) is used automatically. ### Dependency Track Required when `dependency-track` is in `UPLOAD_DESTINATIONS`. CycloneDX only - Dependency Track does not accept SPDX. | Variable | Required | Description | | ---------------------------------------- | -------- | ---------------------------------------------------------------- | | `DTRACK_API_KEY` | Yes | Dependency Track API key. | | `DTRACK_API_URL` | Yes | Full API base URL, for example `https://dtrack.example.com/api`. | | `DTRACK_PROJECT_ID` | Either | Project UUID. | | `COMPONENT_NAME` and `COMPONENT_VERSION` | Or both | Used to identify the project instead of a UUID. | | `DTRACK_AUTO_CREATE` | No | Create the project if it does not exist. Defaults to `false`. | | `DTRACK_PROJECT_TAGS` | No | Comma-separated tags. | | `DTRACK_PARENT_ID` | No | Parent project ID. | | `DTRACK_PARENT_NAME` | No | Parent project name. | | `DTRACK_PARENT_VERSION` | No | Parent project version. | | `DTRACK_IS_LATEST` | No | Mark this BOM as the latest version. Defaults to `false`. | ## Caching and performance | Variable | Default | Description | | ------------------------------ | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | `SBOMIFY_CACHE_DIR` | `~/.cache/sbomify` | Where license databases are cached. Roughly 20-50 MB. | | `SYFT_CACHE_DIR` | none | Syft's own package metadata cache. | | `XDG_CACHE_HOME` | `~/.cache` | Fallback cache root when `SBOMIFY_CACHE_DIR` is unset. | | `SBOMIFY_TOOL_CACHE` | none | Where fetched tool runtimes are unpacked. Falls back to `XDG_CACHE_HOME`, then `$HOME/.cache`, then the temp directory. | | `SBOMIFY_FETCH_RUNTIMES` | `1` | Set to `0` to refuse downloading tool runtimes, for air-gapped builds. See [tool runtimes](/sbomify-action/advanced/#tool-runtimes). | | `SBOMIFY_ENRICHMENT_CACHE` | `1` | Set to `0` to disable the on-disk enrichment response cache. | | `SBOMIFY_ENRICHMENT_CACHE_TTL` | none | Override how long cached enrichment responses stay valid, in seconds. | | `SBOMIFY_CLEARLY_CACHED_URL` | `https://clearly-cached.sbomify.com` | Point ClearlyDefined lookups at your own [clearly-cached](https://github.com/sbomify/clearly-cached) instance. | | `GITHUB_TOKEN` or `GH_TOKEN` | none | **Strongly recommended.** Authenticates license database downloads. | `GITHUB_TOKEN` is worth calling out. License databases are downloaded from GitHub Releases, and unauthenticated requests are limited to 60 per hour per IP address. On shared CI runners that limit is often already exhausted, and when it is, **enrichment degrades silently** - you get an SBOM with fewer licenses populated and no hard error. This applies on every runtime, not just GitHub Actions. See [license database rate limits](/sbomify-action/enrichment/#license-database-rate-limits). ## Diagnostics and privacy | Variable | Default | Description | | ------------ | ------- | --------------------------------------------------------------------- | | `VERBOSE` | `false` | Verbose logging. Equivalent to `--verbose`. | | `TELEMETRY` | `true` | **Error telemetry is enabled by default.** Set to `false` to disable. | | `SENTRY_DSN` | none | Point error telemetry at your own Sentry instance. | The action reports unhandled errors to Sentry unless you opt out. If your policy prohibits outbound diagnostics, set `TELEMETRY=false` or pass `--no-telemetry`. See [telemetry and privacy](/sbomify-action/advanced/#telemetry-and-privacy). ## Advanced | Variable | Default | Description | | -------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------- | | `SBOMIFY_ENABLE_LICENSE_DB_GENERATION` | `false` | Allow local license database generation when no prebuilt one is available. Slow - Debian and Ubuntu can take hours. | | `SBOMIFY_LICENSE_DB_WORKERS` | `5` | Parallelism for the `sbomify-license-db` tool. | | `SBOMIFY_VCS_URL` | none | TeamCity only. Repository URL, trusted as given and taking precedence over detection. | | `SBOMIFY_VCS_REF` | none | TeamCity only. Branch or tag, used when the build properties file is not readable. | `SBOMIFY_VCS_URL` and `SBOMIFY_VCS_REF` exist because TeamCity keeps repository details in a properties file rather than the environment, and a containerised step may not be able to read it. The other runtimes need no equivalent. See [TeamCity](/sbomify-action/runtimes/teamcity/#vcs-information). ## Deprecated Still honoured, but they log a warning. Use the replacement. | Deprecated | Use instead | | --------------- | ------------------- | | `SBOM_VERSION` | `COMPONENT_VERSION` | | `OVERRIDE_NAME` | `COMPONENT_NAME` | ## Set automatically by CI You do not set these. They are read from the environment to detect VCS information and, on GitHub Actions, to perform the OIDC exchange. - **GitHub Actions** - `GITHUB_REPOSITORY`, `GITHUB_SERVER_URL`, `GITHUB_SHA`, `GITHUB_REF`, `GITHUB_REF_NAME`, `GITHUB_WORKSPACE`, `GITHUB_RUN_ID`, `GITHUB_REPOSITORY_VISIBILITY`, `ACTIONS_ID_TOKEN_REQUEST_URL`, `ACTIONS_ID_TOKEN_REQUEST_TOKEN` - **GitLab CI** - `CI_PROJECT_URL`, `CI_PROJECT_PATH`, `CI_SERVER_URL`, `CI_COMMIT_SHA`, `CI_COMMIT_REF_NAME`, `CI_PIPELINE_ID`, `CI_PROJECT_VISIBILITY` - **Bitbucket** - `BITBUCKET_WORKSPACE`, `BITBUCKET_REPO_SLUG`, `BITBUCKET_COMMIT`, `BITBUCKET_BRANCH`, `BITBUCKET_TAG`, `BITBUCKET_GIT_HTTP_ORIGIN` - **TeamCity** - `TEAMCITY_VERSION`, `BUILD_VCS_NUMBER` (and `BUILD_VCS_NUMBER_` on multi-root builds), `TEAMCITY_BUILD_PROPERTIES_FILE` - **Jenkins** - `JENKINS_URL`, `JENKINS_HOME`, `HUDSON_HOME`, `JENKINS_NODE_COOKIE` or `JENKINS_SERVER_COOKIE` (any one detects the platform), `WORKSPACE`, `GIT_URL` (`GIT_URL_1` with several SCMs), `GIT_COMMIT`, `GIT_LOCAL_BRANCH`, `TAG_NAME`, `CHANGE_BRANCH`, `BRANCH_NAME`, `GIT_BRANCH` - **CircleCI** - `CIRCLECI`, `CIRCLE_WORKING_DIRECTORY`, `CIRCLE_REPOSITORY_URL`, `CIRCLE_SHA1`, `CIRCLE_BRANCH`, `CIRCLE_TAG` - **Travis CI** - `TRAVIS`, `TRAVIS_BUILD_DIR`, `TRAVIS_COMMIT`, `TRAVIS_TAG`, `TRAVIS_PULL_REQUEST_BRANCH`, `TRAVIS_BRANCH`. The repository URL comes from the checkout - `TRAVIS_REPO_SLUG` names no host, so no URL is built from it - **Every other CI system** - `CI`, plus the vendor marker it sets: `TF_BUILD`, `BUILDKITE`, `DRONE`, `APPVEYOR`, `CODEBUILD_BUILD_ID`. These only name the platform in logs and telemetry - the repository details come from the git checkout. The matching checkout-path variables (`BUILD_REPOSITORY_LOCALPATH`, `SYSTEM_DEFAULTWORKINGDIRECTORY`, `BUILDKITE_BUILD_CHECKOUT_PATH`, `DRONE_WORKSPACE`, `APPVEYOR_BUILD_FOLDER`, `CODEBUILD_SRC_DIR`) are used when they point at a directory that exists inside the container, as are the Jenkins, CircleCI and Travis ones above The two OIDC request variables only exist when the workflow grants `permissions: id-token: write`. ## CLI flags Every variable has a matching flag when you invoke the CLI directly. Flags win over environment variables. ```bash sbomify-action --lock-file requirements.txt --enrich --no-upload -o sbom.cdx.json ``` | Flag | Equivalent | | -------------------------------------------------------------- | ---------------------------------- | | `--lock-file`, `--sbom-file`, `--docker-image`, `--source-dir` | input source | | `--submodule-path` | `SUBMODULE_PATH` | | `-o`, `--output-file` | `OUTPUT_FILE` | | `-f`, `--sbom-format` | `SBOM_FORMAT` | | `--spec-version` | `SPEC_VERSION` | | `--bom-type` | `BOM_TYPE` | | `--enrich`, `--no-enrich` | `ENRICH` | | `--augment`, `--no-augment` | `AUGMENT` | | `--override-sbom-metadata` | `OVERRIDE_SBOM_METADATA` | | `--upload`, `--no-upload` | `UPLOAD` | | `--upload-destination` | `UPLOAD_DESTINATIONS`. Repeatable. | | `--token`, `--component-id` | `TOKEN`, `COMPONENT_ID` | | `--component-name`, `--component-version`, `--component-purl` | matching variables | | `--product-release` | `PRODUCT_RELEASE` | | `--api-base-url`, `--oidc-audience` | matching variables | | `--working-dir` | `WORKING_DIR` | | `--telemetry`, `--no-telemetry` | `TELEMETRY` | | `-v`, `--verbose`, `-q`, `--quiet` | `VERBOSE` | ### Subcommands | Command | Purpose | | ----------------------- | ------------------------------------------------------------------------------------------------------------------- | | `sbomify-action wizard` | Interactive setup. `init` is an alias. See [quick start](/sbomify-action/quickstart/). | | `sbomify-action yocto` | Process Yocto and OpenEmbedded SPDX archives. See [input sources](/sbomify-action/sources/#yocto-and-openembedded). | | `sbomify-license-db` | Generate a distro license database locally. Advanced. | --- # sbomify Action Quick Start URL: https://sbomify.com/sbomify-action/quickstart/ Description: Get your first SBOM generated in minutes with the interactive setup wizard, or by writing the configuration by hand. There are two ways to get started: let the wizard configure everything, or write the configuration by hand. The wizard is the fastest path and produces a workflow you can read and edit afterwards. ## Option 1: the setup wizard The wizard is an interactive terminal application. It scans your repository for lockfiles, signs you in to sbomify, creates the matching components, and writes a ready-to-commit GitHub Actions workflow. Run it from the root of your repository: ```bash docker run --rm -it \ -v "$(pwd):/workspace" \ ghcr.io/sbomify/sbomify-action \ sbomify-action wizard ``` If you have [uv](https://docs.astral.sh/uv/) available and would rather not use Docker: ```bash uvx sbomify-action wizard ``` Either way there is nothing else to install - whatever generator your project needs is downloaded on first use and cached. See [running locally](/sbomify-action/runtimes/local/). ### What it does 1. Scans your repository for supported lockfiles and lets you pick which to onboard. 2. Signs you in to sbomify and picks or creates the product and components. 3. Asks how you want releases tagged, how to authenticate, whether to enrich, which SBOM formats to emit, and whether to attest. 4. Writes `.github/workflows/sboms.yml`, plus `sbomify.json` if you opt into local augmentation. ### Options | Option | Description | | ---------------- | --------------------------------------------------------------------------------------- | | `--token` | sbomify API token. Falls back to `$SBOMIFY_TOKEN`, then `$TOKEN`. | | `--api-base-url` | sbomify API base URL. Defaults to `https://app.sbomify.com`; override for self-hosted. | | `--repo-root` | Repository root to scan. Defaults to the current directory. | | `--output-dir` | Where the workflow is written. Defaults to `.github/workflows`, and must resolve there. | | `--dry-run` | Walk through the wizard and preview the plan. Makes no API changes and writes no files. | | `--debug` | Dump debug logs after the wizard exits. | ### Things worth knowing - The wizard is **interactive**, so the `-it` flags are required, and it refuses to launch on any environment it recognises as CI - `CI=true`, or a vendor marker such as `GITHUB_ACTIONS`, `GITLAB_CI` or `JENKINS_URL`. Run it on your machine and commit the result. - The volume mount is what lets it write the generated workflow back into your repository. Without it, the wizard runs but produces nothing you keep. - It only manages `.github/workflows/sboms.yml`, and marks files it generated with a header. It will never overwrite a workflow you wrote by hand. - It pins the action to a specific commit SHA at generation time, which is the recommended practice. - All components in one repository share a single release strategy, credential mode and format set. If you need them to differ, edit the generated workflow or write your own. - The wizard currently emits **GitHub Actions** workflows only. On other runtimes, configure by hand - see the [runtime guides](/sbomify-action/runtimes/). - `sbomify-action init` is a backwards-compatible alias for `wizard`. ## Option 2: configure it by hand The minimum viable configuration is four environment variables. This generates a CycloneDX SBOM from a lockfile, enriches it from package registries, and writes it to disk without uploading anywhere: ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false ``` That is a complete, working setup. No account required. Swap `requirements.txt` for whichever lockfile your project uses - [17 ecosystems are supported](/sbomify-action/sources/). For SPDX output, add `SBOM_FORMAT: spdx`. On any runtime other than GitHub Actions, the same configuration is passed to the container image as environment variables: ```bash docker run --rm \ -v "$(pwd):/workspace" \ -e LOCK_FILE=requirements.txt \ -e OUTPUT_FILE=sbom.cdx.json \ -e ENRICH=true \ -e UPLOAD=false \ ghcr.io/sbomify/sbomify-action ``` ## Adding your own metadata Enrichment fills in what public registries know. It cannot know who supplies your software, who authored it, or when support ends - that is [augmentation](/sbomify-action/augmentation/), and it needs input from you. Create `sbomify.json` in your project root: ```json { "lifecycle_phase": "build", "supplier": { "name": "My Company", "url": ["https://example.com"], "contacts": [{"name": "Support", "email": "support@example.com"}] }, "authors": [ {"name": "Jane Doe", "email": "jane@example.com"} ], "licenses": ["Apache-2.0"], "security_contact": "https://example.com/.well-known/security.txt" } ``` Then set `AUGMENT: true`. No account needed for this either. ## Uploading to sbomify To store SBOMs in sbomify, add a component ID and authenticate. On GitHub Actions, prefer [trusted publishing](/sbomify-action/publishing/#oidc-trusted-publishing) over a long-lived token: ```yaml permissions: contents: read id-token: write jobs: sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: sbomify/sbomify-action@master env: COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: true ENRICH: true ``` This requires a trusted publisher binding on the component first. See [publishing](/sbomify-action/publishing/) for the setup, and for the token-based alternative used on every other runtime. ## Checking the result A successful run prints a summary table showing what was changed: ```text ┌─────────────────────┬───────┐ │ Metric │ Value │ ├─────────────────────┼───────┤ │ Overrides applied │ 3 │ │ Components enriched │ 42 │ │ Sanitization fixes │ 5 │ └─────────────────────┴───────┘ ``` It also writes `audit_trail.txt` next to your SBOM, listing every individual modification with a UTC timestamp and its source. That file is your evidence of what the pipeline did - see [the audit trail](/sbomify-action/advanced/#audit-trail). If `Components enriched` is unexpectedly low, the most common cause is GitHub API rate limiting on the license database download. [Setting `GITHUB_TOKEN` fixes it](/sbomify-action/enrichment/#license-database-rate-limits). ## Next steps - [How it works](/sbomify-action/how-it-works/) - what happens between input and output - [Your runtime](/sbomify-action/runtimes/) - platform-specific setup - [Configuration](/sbomify-action/configuration/) - every option - [Advanced](/sbomify-action/advanced/) - attestation, caching, troubleshooting --- # Why SBOM Quality Matters: Scanners vs. Pipelines URL: https://sbomify.com/sbomify-action/why/ Description: Why a raw scanner output is not a compliance-grade SBOM, and why generating and signing in CI - with no server-side modification afterwards - is what makes an SBOM verifiable. ## The gap between a dependency list and an SBOM Run any scanner over a project and you get something like this: ```json { "type": "library", "name": "django", "version": "5.1", "purl": "pkg:pypi/django@5.1" } ``` That is a correct and useful answer to "what is installed here?". It is not an SBOM that will survive a procurement review. Here is the same component after augmentation and enrichment: ```json { "type": "library", "name": "django", "version": "5.1", "purl": "pkg:pypi/django@5.1", "publisher": "Django Software Foundation", "description": "A high-level Python web framework...", "licenses": [{"expression": "BSD-3-Clause"}], "externalReferences": [ {"type": "website", "url": "https://www.djangoproject.com/"}, {"type": "vcs", "url": "https://github.com/django/django"}, {"type": "distribution", "url": "https://pypi.org/project/Django/"} ] } ``` The difference is not cosmetic. Without a license field you cannot run license compliance. Without a supplier you cannot answer "who do I contact about this?". Without a hash you cannot prove the component you shipped is the component you scanned. ## What the regulations actually require The [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/) define 23 elements across SBOM metadata, component data, and practices, updating and replacing the seven fields in the [NTIA 2021 guidance](/compliance/ntia-minimum-elements/). The [EU Cyber Resilience Act](/compliance/eu-cra/) leans on both. | Required element | Where it comes from | | --------------------------- | --------------------------------------------- | | Supplier name | Augmentation (yours) or enrichment (registry) | | Component name | Generator | | Version | Generator | | Other unique identifiers | Generator (PURL) | | Dependency relationship | Generator | | Author of SBOM data | Augmentation | | Timestamp | Generator | | Component hash (CISA 2025) | Hash enrichment from your lockfile | | License | Enrichment | | Lifecycle and support dates | Augmentation and CLE enrichment | A generator supplies roughly the middle of that table. The top and bottom - the parts that describe _your organisation_ and _the wider ecosystem_ - are not information a scanner has access to. One of them only you know; the other lives in package registries. This is the whole argument for treating SBOM generation as a pipeline rather than a single command. ## Why not just pick the best scanner? Because there isn't one. | Ecosystem | Most accurate generator | | ---------------------------------- | ----------------------- | | Python | `cyclonedx-py` | | Rust | `cargo-cyclonedx` | | Go | `cyclonedx-gomod` | | Java (Maven) | `cyclonedx-maven` | | Java (Gradle) | `cyclonedx-gradle` | | Scala | `cyclonedx-sbt` | | JavaScript, Ruby, PHP, .NET | `cdxgen` | | Container images, Swift, Terraform | Syft | Native tools understand their ecosystem's resolution rules; generic scanners guess from files on disk. `sbomify-action` routes each input to the best available generator and falls back automatically if one fails or does not support the input, so you get the right tool without having to maintain that knowledge yourself. See [input sources](/sbomify-action/sources/) for the full routing table. There is a second, quieter benefit: abstracting over generators means you are not exposed when one of them has a problem. When [Trivy shipped compromised releases in March 2026](/2026/03/26/trivy-compromise-hardening-sbomify-action/), removing it was a configuration change, not a migration. For a broader look at the generators themselves, see our [comparison of SBOM generation tools](/2026/01/26/sbom-generation-tools-comparison/). ## Build time is the only time An SBOM describes what went into a build. The moment that information is complete and unambiguous is **during the build** - when the lockfile, the resolved dependency tree, the commit SHA, the branch and the build environment all exist together. Afterwards, you are reconstructing. Scanning a released artifact tells you what can be detected from the outside, which is not the same as what went in. Vendored code, statically linked libraries and files copied between Docker build stages are routinely invisible. Generating in CI also means the SBOM can be **signed where it was made**, tied to the identity of the pipeline that produced it. That is what turns an SBOM from a document into evidence. ## The part most platforms get wrong Here is the question worth asking any SBOM vendor: **after I upload an SBOM, do you change it?** Many platforms do. They enrich, normalise formats, deduplicate components, "improve" metadata. It sounds helpful. It quietly destroys the thing that made the SBOM trustworthy. Consider what a server-side write actually looks like from the outside. A platform that removes a vulnerable component and a platform that tidies up inconsistent metadata are performing the same operation: modifying bytes you cannot inspect. You have no way to distinguish them. Once that is possible, "this product has no known vulnerabilities" is no longer a verifiable statement - it is a claim resting on the vendor's word, and an inconvenient CVE quietly disappearing is indistinguishable from routine housekeeping. There is a mechanical problem too. If a platform modifies a signed SBOM, **the signature no longer validates**. The platform's options are to break your signature or to re-sign with its own key. Re-signing moves the trust anchor from you to the vendor and breaks the chain of custody: an auditor is now verifying the platform's assertion, not your build. **sbomify never modifies an artifact you upload.** The bytes received are the bytes stored and the bytes served. No enrichment, no normalisation, no transformation of any kind. The authoritative copy of your SBOM lives in your pipeline; sbomify is a distribution and analysis layer over it, not an editor of it. That constraint is what makes the guarantee useful: - Your signature keeps validating, indefinitely. - What an auditor downloads is byte-for-byte what your pipeline produced. - Anyone can verify it independently, without trusting sbomify at all. - Every change made to the SBOM was made in CI, by you, and is listed in the [audit trail](/sbomify-action/advanced/#audit-trail). ### Analysis without modification Not modifying artifacts does not mean doing nothing with them. sbomify analyses SBOMs and produces **separate** output: vulnerability scan results, compliance assessments against NTIA, CISA, CRA and other frameworks, and attestation verification. All of it reads the artifact and writes findings alongside it. None of it touches the artifact. ### One clarification This guarantee covers artifacts you _upload_. sbomify does create new artifacts on your behalf where you ask it to - aggregate product-level SBOMs assembled from component SBOMs, VEX and VDR documents generated from scan results, derived compliance reports. Those are new creations, clearly distinct from your uploads, not edits to them. If you distribute them with the same guarantees you apply to your own artifacts, sign them yourself. ## Putting it together 1. **Generate in CI**, where the build context exists, using the right generator for each ecosystem. 2. **Augment** with the organisational metadata only you have. 3. **Enrich** with registry metadata and integrity hashes. 4. **Sign at origin**, before the artifact leaves your pipeline. 5. **Upload** to a platform that will not touch it. Steps 1 to 3 are what [`sbomify-action`](/sbomify-action/) does in a single step. Step 4 is [attestation](/sbomify-action/advanced/#attestation) or [signing](/faq/how-do-i-sign-an-sbom/). Step 5 is a design guarantee, not a feature. Ready to start? Head to the [quick start](/sbomify-action/quickstart/). --- # Frequently Asked Questions URL: https://sbomify.com/faq/ Description: Common questions about SBOMs, software supply chain security, and the sbomify platform. Get answers about SBOM formats, compliance requirements, and getting started. --- # What is an SBOM (Software Bill of Materials)? URL: https://sbomify.com/faq/what-is-an-sbom/ Description: Learn what a Software Bill of Materials (SBOM) is, why it matters for supply chain security, and how it lists every component in your software. ## What does SBOM stand for? SBOM stands for **Software Bill of Materials**. It is a formal, machine-readable document that lists every component included in a software product - open-source libraries, third-party packages, and their transitive dependencies. Think of it like a nutrition label for software. Just as food labels tell you exactly what ingredients are inside, an SBOM tells you exactly what code is inside your application. ## Why do SBOMs matter? Modern software is built from hundreds or thousands of open-source and third-party components. When a vulnerability is discovered in one of those components (like [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell) in 2021), organizations need to quickly determine whether they are affected. Without an SBOM, this is a slow and error-prone process. SBOMs help you: - **Identify vulnerabilities** - Know immediately if a vulnerable component is in your software - **Meet compliance requirements** - Regulations like the [EU Cyber Resilience Act](/compliance/eu-cra/) and [NTIA minimum elements](/compliance/ntia-minimum-elements/) now require SBOMs - **Build customer trust** - Share your software composition transparently via a [Trust Center](https://trust.sbomify.com/) - **Manage license risk** - Understand which open-source licenses apply to your codebase ## What formats are SBOMs available in? The two most widely adopted SBOM formats are: - **[CycloneDX](https://cyclonedx.org/)** - A lightweight, security-focused format maintained by OWASP - **[SPDX](https://spdx.dev/)** - An ISO/IEC standard (ISO/IEC 5962:2021) originally focused on license compliance Both formats support JSON and XML representations. sbomify supports both CycloneDX and SPDX. ## How do I get started? Generating your first SBOM is straightforward. Check out our [language-specific guides](/guides/) for step-by-step instructions covering Python, JavaScript, Java, Go, Rust, and more. Once you have an SBOM, you can upload it to [sbomify](https://app.sbomify.com) to manage, monitor, and share it. For a deeper introduction, read our full [What is an SBOM?](/what-is-sbom/) page. --- # Why do I need an SBOM? URL: https://sbomify.com/faq/why-do-i-need-an-sbom/ Description: Discover why your organization needs a Software Bill of Materials for vulnerability management, regulatory compliance, and customer trust. ## The software supply chain problem Over 90% of modern applications contain open-source components. When a critical vulnerability is disclosed, the first question every security team asks is: _"Are we affected?"_ Without an SBOM, answering that question requires manually auditing codebases across every product and service - a process that can take days or weeks. ## Key reasons to adopt SBOMs ### Vulnerability response When a new CVE drops, an SBOM lets you search your entire software portfolio in seconds. Instead of scrambling to check repos manually, you can query your SBOMs and know immediately which products contain the affected component. ### Regulatory compliance SBOMs are increasingly required by law and industry standards: - **[EU Cyber Resilience Act (CRA)](/compliance/eu-cra/)** - Requires SBOMs for all products with digital elements sold in the EU - **[NTIA Minimum Elements](/compliance/ntia-minimum-elements/)** - US government baseline for SBOM content - **[NIST 800-171](/compliance/nist-800-171/)** - Supply chain risk management requirements - **[FDA guidance](/compliance/fda-medical-device/)** - Medical device manufacturers must submit SBOMs - **[PCI DSS 4.0](/compliance/pci-dss/)** - Payment industry now references software composition analysis See our full [Compliance guide](/compliance/) for details on each framework. ### Customer trust and procurement Enterprise buyers increasingly ask for SBOMs during procurement. Having your SBOMs ready and accessible through a [Trust Center](https://trust.sbomify.com/) demonstrates transparency and security maturity, giving you a competitive advantage. ### License management SBOMs catalog the licenses of every dependency, helping legal teams identify copyleft or restrictive licenses before they become a problem. ## Getting started You don't need to overhaul your development process. Start by generating an SBOM for one project using our [language guides](/guides/), then gradually expand coverage. [sbomify's free Community tier](https://app.sbomify.com) lets you manage SBOMs for open-source projects at no cost. --- # What SBOM formats does sbomify support? URL: https://sbomify.com/faq/what-sbom-formats-does-sbomify-support/ Description: sbomify supports CycloneDX 1.3-1.7 and SPDX 2.2, 2.3, and 3.0.1 SBOM formats in JSON, with automatic validation and schema compliance checking. ## Supported formats sbomify supports the two major SBOM standards: ### CycloneDX [CycloneDX](https://cyclonedx.org/) is an OWASP project designed specifically for security use cases. It is lightweight, easy to generate, and widely supported by tooling. - **Versions supported:** CycloneDX 1.3 through 1.7 - **Representations:** JSON - **Strengths:** Security-focused, supports VEX (Vulnerability Exploitability eXchange), extensive tooling ecosystem ### SPDX [SPDX](https://spdx.dev/) (Software Package Data Exchange) is an ISO/IEC international standard (5962:2021) with deep roots in license compliance. - **Versions supported:** SPDX 2.2, 2.3, 3.0.1 - **Representations:** JSON (JSON-LD for 3.0.1) - **Strengths:** ISO standard, strong license compliance support, widely used in automotive and enterprise ## Automatic validation When you upload an SBOM to sbomify, it is automatically validated against the official schema for its format and version. This helps catch malformed documents before they enter your pipeline. ## VEX and other BOM types SBOMs are not the only artifacts sbomify accepts. VEX documents are ingested natively in **CycloneDX VEX (JSON and XML), OpenVEX, and CSAF 2.0 VEX** formats, with automatic format detection - see [What VEX formats does sbomify support?](/faq/what-vex-formats-does-sbomify-support/). Cryptography Bills of Materials ([CBOMs](/faq/what-is-a-cbom/)) are detected and classified automatically on upload, and CI pipelines can upload VEX, CBOM, and HBOM artifacts verbatim with the sbomify-action `BOM_TYPE` setting. ## Which format should I choose? Both formats are well supported and meet regulatory requirements. Some considerations: - **CycloneDX** is generally easier to get started with and has stronger security tooling (VEX, VDR) - **SPDX** may be preferred if your industry or customers specifically require an ISO standard Most SBOM generation tools support both formats. See our [language guides](/guides/) for tool-specific instructions. ## Can I convert between formats? We strongly recommend against converting between CycloneDX and SPDX. The two formats have different data models, and conversion is inherently lossy - fields, relationships, and metadata will be dropped or misrepresented in the process. The resulting SBOM may look valid but will be incomplete or inaccurate. Instead, generate your SBOMs natively in the format you need. Tools like Syft support both formats, but many generators only output one. Check our [Resources page](/resources/) for a list of SBOM generation tools and their supported formats. --- # Can I convert between CycloneDX and SPDX? URL: https://sbomify.com/faq/can-i-convert-between-cyclonedx-and-spdx/ Description: Why converting between CycloneDX and SPDX SBOM formats is problematic and what to do instead. ## The short answer You can technically run a conversion tool, but you will almost certainly lose data in the process. CycloneDX and SPDX are not different encodings of the same information - they are fundamentally different data models with different concepts, fields, and relationships. ## Why conversion loses context Each format has fields and structures the other does not: - **CycloneDX** has concepts like services, vulnerabilities (VEX), formulation, licensing expressions on components, lifecycle phases, and attestations that have no direct SPDX equivalent - **SPDX** has concepts like document-level relationships, file-level analysis, snippet tracking, and annotation types that have no direct CycloneDX equivalent - Even fields that look similar (like licensing) use different structures and semantics between the two formats A round-trip conversion (CycloneDX -> SPDX -> CycloneDX) will not give you back what you started with. Data that doesn't map cleanly is either dropped silently or shoehorned into fields where it doesn't belong. ## What to do instead Generate natively in the format you need. [sbomify-action](https://github.com/sbomify/sbomify-action) supports both formats out of the box: ```yaml # CycloneDX (default) - uses: sbomify/sbomify-action@master env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: true # SPDX - uses: sbomify/sbomify-action@master env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.spdx.json SBOM_FORMAT: spdx ENRICH: true ``` If a customer or regulation requires a specific format, generate in that format from the start rather than converting after the fact. ## Further reading - [What SBOM formats does sbomify support?](/faq/what-sbom-formats-does-sbomify-support/) - [Schema Crosswalk](/compliance/schema-crosswalk/) - how fields map (and don't map) across CycloneDX and SPDX --- # Can I combine multiple SBOMs into one? URL: https://sbomify.com/faq/can-i-combine-multiple-sboms-into-one/ Description: Why merging multiple SBOMs into a single file loses context, and how to link them together instead using sbomify's hierarchy. ## The short answer You can, but you probably shouldn't. Merging multiple SBOMs into a single flat file loses important context about where components come from. ## Why merging is problematic Consider a product with a Python backend and a Node frontend, each with its own SBOM. If you merge them into one file: - **Origin is lost** - you can no longer tell whether a dependency belongs to the backend or the frontend - **Deduplication destroys information** - if both SBOMs contain `pkg:pypi/requests@2.31.0`, a naive merge deduplicates it into one entry, but maybe only the backend actually uses it - **Vulnerability triage becomes harder** - when a CVE hits a component, you need to know which service is affected, not just that the component exists somewhere in your product - **Versioning breaks down** - your backend and frontend ship on different release cadences, but a merged SBOM has a single version ## What about SPDX 3 and CycloneDX 2? The latest versions of both formats (SPDX 3.0, which is the current version, and the upcoming CycloneDX 2.0) do support linking multiple documents together without losing context. They allow referencing external SBOM documents while preserving the relationship between components and their source. sbomify uses this natively: aggregated release SBOMs emit SPDX 2.3 external document references and SPDX 3.0 import maps, so each component SBOM keeps its identity while the release-level SBOM ties them together. ## Our recommendation: link, don't merge Instead of merging SBOMs, use sbomify's [hierarchy](/faq/how-do-products-work-in-sbomify/) to link them together: - Each repository gets its own **component** with its own SBOM - Components are grouped directly under **products** (e.g. "My App") - **Releases** snapshot specific SBOM versions across the product This preserves full context - you always know which component a dependency belongs to and which product release it shipped in. Customers and auditors can drill down to any level of detail, and you can share the full product SBOM or individual component SBOMs as needed. ## Further reading - [How do products work in sbomify?](/faq/how-do-products-work-in-sbomify/) - the full hierarchy explained - [SBOM Hierarchy feature page](/features/sbom-hierarchy/) --- # Is sbomify free? URL: https://sbomify.com/faq/is-sbomify-free/ Description: Learn about sbomify's pricing tiers including the free Community plan for open-source projects, the Business plan for teams, and Enterprise options. ## Pricing tiers sbomify offers three plans to fit different needs: ### Community (Free) The Community tier is **completely free** and designed for: - Open-source maintainers who want to publish SBOMs for their projects - Hobby projects and personal use - Developers evaluating sbomify before upgrading It includes core SBOM management features and the ability to share SBOMs publicly. ### Business ($199/month) The Business tier is built for mid-size teams that need: - Private SBOM repositories - Team collaboration features - Custom trust center on your own domain - [Transparency Exchange API (TEA)](/faq/how-do-i-enable-tea-in-sbomify/) - [CRA Compliance Wizard](/faq/how-do-i-use-cra-compliance/) - [Dependency Track integration](/faq/how-do-i-enable-vulnerability-scanning/) and daily vulnerability re-scans - Compliance reporting - Priority support ### Enterprise (Custom pricing) For large organizations with advanced security and compliance needs: - SSO/SAML integration - Custom roles and permissions - Dedicated support - SLA guarantees Visit our [Pricing page](/pricing/) for the full feature comparison, or [sign up for a free account](https://app.sbomify.com) to get started immediately. ## Self-hosting sbomify is also available as a self-hosted solution. If you prefer to run sbomify on your own infrastructure, you can deploy it using Docker. Visit our [GitHub repository](https://github.com/sbomify/sbomify) for setup instructions. ## No credit card required You can create a Community account and start uploading SBOMs right away - no credit card or commitment needed. Upgrade to a paid plan whenever your needs grow. --- # What is the EU Cyber Resilience Act (CRA)? URL: https://sbomify.com/faq/what-is-the-eu-cyber-resilience-act/ Description: Understand the EU Cyber Resilience Act, its SBOM requirements, timeline, and how sbomify helps you achieve CRA compliance. ## Overview The **EU Cyber Resilience Act** (Regulation 2024/2847) is a binding EU regulation that establishes cybersecurity requirements for products with digital elements - essentially any hardware or software product sold in the EU market. It was published in the Official Journal of the EU in November 2024, with a phased enforcement timeline through 2027. ## Key SBOM requirements The CRA explicitly requires manufacturers to: - **Produce a machine-readable SBOM** in a commonly used format (e.g., CycloneDX, SPDX) identifying components and dependencies in their products - **Cover at least top-level dependencies** of the product - **Document vulnerabilities** and provide timely security updates - **Report actively exploited vulnerabilities and severe incidents** within 24 hours, through the ENISA [Single Reporting Platform](/compliance/eu-cra/) - **Maintain cybersecurity** throughout the product's expected lifetime Reporting is not sent to ENISA directly: notifications go through the Single Reporting Platform to the CSIRT designated as coordinator in the relevant Member State, and are made available to ENISA at the same time (Article 16(1)). Germany's BSI has published [TR-03183-2](https://bsi.bund.de/dok/TR-03183-en), which provides concrete technical specifications for CRA-compliant SBOMs, including: - **Format:** CycloneDX 1.6+ or SPDX 3.0.1+ in JSON or XML - **Depth:** Recursive dependency resolution down to and including the first component outside the scope of delivery - **Required fields per component:** Creator, name, version, filename, dependencies, licences (as SPDX identifiers), SHA-512 hash, and executable/archive/structured properties - **No vulnerability data in SBOMs** - use CSAF or VEX instead ## Who does it apply to? The CRA applies to: - Software vendors selling products in the EU (including SaaS with on-premise components) - Hardware manufacturers with embedded software - Open-source projects distributed commercially (non-commercial open source has exemptions) ## Timeline - **11 September 2026** - Article 14 reporting obligations begin for manufacturers, filed through the ENISA [Single Reporting Platform](/compliance/eu-cra/) - **11 December 2027** - Full application: all essential requirements, including the SBOM obligation, become enforceable - **11 December 2027** - Reporting obligations for open-source software stewards begin (Article 24(3)) ## How sbomify helps sbomify provides tooling to help you prepare for CRA compliance: - Manage and monitor SBOMs across your product portfolio - Track vulnerability status with automated scanning - Share compliance artifacts through your [Trust Center](https://trust.sbomify.com/) - CRA compliance plugin to assess your SBOM against CRA requirements For the complete breakdown of CRA requirements and field mappings, see our detailed [EU CRA Compliance Guide](/compliance/eu-cra/). ## FOSDEM 2026: CRA-Ready SBOMs For a practical walkthrough of CRA-ready SBOM generation, watch our FOSDEM 2026 talk: --- # Are SBOMs required for Secure by Design? URL: https://sbomify.com/faq/are-sboms-required-for-secure-by-design/ Description: Learn why SBOMs are a non-optional requirement for Secure by Design and Secure by Default practices, backed by CISA guidance, the EU CRA, and US Executive Orders. ## What is Secure by Design? **Secure by Design** is a software development philosophy - championed by CISA and endorsed by 19+ international partner agencies - that shifts security responsibility from end users to technology manufacturers. It rests on three core principles: 1. **Take ownership of security outcomes** - manufacturers, not customers, bear responsibility for product security 2. **Embrace radical transparency** - openly share security information, including vulnerabilities and software composition 3. **Build organizational leadership commitment** - security is a board-level priority, not just an engineering concern The goal is to make products secure out of the box, rather than relying on customers to layer on security after the fact. For a deeper dive, see our post on [CISA's Secure by Design initiative](/2024/07/24/embracing-cybersecurity-with-cisas-secure-by-design-initiative/). ## Why SBOMs are non-optional SBOMs are not a nice-to-have under Secure by Design - they are foundational to multiple core principles: - **Radical transparency requires component visibility** - you cannot be transparent about your product's security posture without knowing exactly what components are inside it. An SBOM is the mechanism that provides that visibility. - **Vulnerability response depends on inventory** - when a critical vulnerability like Log4Shell or the XZ Utils backdoor is disclosed, SBOMs let you answer "are we affected?" in seconds rather than days. - **Supply chain integrity** - SBOMs make every component and dependency traceable, helping detect tampering and ensuring the provenance of your software. - **Compliance mandates it** - the [EU Cyber Resilience Act](/faq/what-is-the-eu-cyber-resilience-act/), US Executive Order 14028, and CISA's own guidance all require or strongly recommend SBOMs as part of Secure by Design practices. ## Regulatory mandates Several major frameworks now connect Secure by Design directly to SBOM requirements: - **CISA Secure by Design Pledge** - commits signatories to transparency practices that include providing SBOMs and participating in vulnerability disclosure programs - **[EU Cyber Resilience Act (CRA)](/compliance/eu-cra/)** - makes Secure by Design a legal duty for products sold in the EU, with SBOM requirements fully enforceable by September 2027 - **US Executive Order 14028** - directs federal agencies to require SBOMs from software suppliers, with NIST's Secure Software Development Framework (SSDF) reinforcing this - **DoD/Pentagon** - requires SBOMs in all new software contracts as of February 2025 For detailed compliance guidance, see our pages on [EU CRA compliance](/compliance/eu-cra/), [NTIA minimum elements](/compliance/ntia-minimum-elements/), and [CISA framing](/compliance/cisa-framing/). ## How sbomify helps sbomify provides the tooling to put Secure by Design into practice: - **Generate and manage SBOMs** across your entire product portfolio using [sbomify-action](https://github.com/sbomify/sbomify-action) - **Automated vulnerability scanning** against known CVEs so you can respond to disclosures immediately - **Share compliance artifacts** with customers and auditors via your [Trust Center](https://trust.sbomify.com/) - **Track compliance** against [NTIA](/compliance/ntia-minimum-elements/), [CISA](/compliance/cisa-framing/), and [CRA](/compliance/eu-cra/) requirements with built-in compliance plugins Get started for free at [app.sbomify.com](https://app.sbomify.com). --- # How do I sign an SBOM? URL: https://sbomify.com/faq/how-do-i-sign-an-sbom/ Description: Learn how to cryptographically sign your SBOMs using GitHub Attestations, Sigstore, and in-toto so that consumers can verify authenticity without trusting any intermediary. ## Why signing matters An unsigned SBOM is a claim. A signed SBOM is evidence. Without a signature, anyone who receives your SBOM has to trust every system it passed through - your CI pipeline, the SBOM management platform, the file transfer, the download link. If any of those are compromised, the SBOM could be silently altered, and the recipient would never know. Signing eliminates this problem. A cryptographically signed SBOM lets the consumer verify two things independently: 1. **Authenticity** - the SBOM was produced by your organization's CI/CD pipeline, not fabricated by a third party 2. **Integrity** - the SBOM has not been modified since it was signed, regardless of how many systems it passed through This means you never need to trust the transportation layer. Whether the SBOM is hosted on [sbomify](https://app.sbomify.com), downloaded from a [Trust Center](https://trust.sbomify.com/), or received via email, the signature lets you trace it back to the issuing party and verify it has not been tampered with. ## Signing must be the last step A signature is a cryptographic seal over the exact bytes of the SBOM. Any tool that modifies the SBOM after signing - whether it adds fields, strips whitespace, re-formats JSON, merges data, or converts between formats - breaks the chain of trust. The signature no longer matches the file, and verification will fail. This means that all enrichment, augmentation, and transformation must happen _before_ signing. If you need to modify a signed SBOM for any reason, you must re-sign it afterward, and the new signature will reflect the new signer's identity rather than the original issuer's. This is by design: the signature proves exactly who produced the final artifact. In practice, this is why sbomify-action's pipeline runs augmentation and enrichment first, then writes the final SBOM to disk, and only then passes it to the attestation step. Any tool that modifies an SBOM post-generation and post-signing - even with good intentions - invalidates the attestation and forces a re-sign. ## How to sign an SBOM with GitHub Attestations The simplest way to sign an SBOM today is with GitHub's built-in attestation support. Behind the scenes, it uses [Sigstore](/2024/08/12/what-is-sigstore/) for keyless signing and the [in-toto](/2024/08/14/what-is-in-toto/) attestation format - but you do not need to manage any keys or understand the underlying protocols. In your GitHub Actions workflow, generate the SBOM and then pass it to the attestation action: ```yaml permissions: id-token: write attestations: write steps: - name: Generate SBOM uses: sbomify/sbomify-action@master env: COMPONENT_ID: 'your-component-id' LOCK_FILE: 'requirements.txt' AUGMENT: true ENRICH: true UPLOAD: true OUTPUT_FILE: sbom.cdx.json - name: Attest SBOM uses: actions/attest-build-provenance@v1 with: subject-path: '${{ github.workspace }}/sbom.cdx.json' ``` The `id-token: write` permission also enables [OIDC trusted publishing](/faq/how-do-i-set-up-oidc-trusted-publishing/), so the upload itself needs no token secret either. That is it. GitHub signs the SBOM using your workflow's identity, records the signature in a [Sigstore transparency log](/2024/08/12/what-is-sigstore/), and links it to the exact repository and workflow run that produced it. ## Verifying a signed SBOM Anyone can verify a signed SBOM using the GitHub CLI: ```bash gh attestation verify path/to/sbom.cdx.json --owner your-org ``` A successful verification confirms: - The SBOM was generated by a specific GitHub Actions workflow - It was produced from a specific repository and commit - It has not been modified since signing This is exactly the point: the consumer does not need to trust sbomify, your CDN, or any other intermediary. They can independently verify the SBOM's provenance by checking the attestation against the Sigstore transparency log. We use this exact workflow for our own [sbomify-action SBOM](https://github.com/sbomify/sbomify-action/blob/master/.github/workflows/sbomify.yaml). You can download the SBOM from our [public Trust Center page](https://trust.sbomify.com/product/sbomify-action/) and verify it yourself. For a detailed walkthrough, see our [attestation blog post](/2024/10/31/github-action-update-and-attestation/). ## What is happening under the hood When you sign an SBOM with GitHub Attestations, several things happen: 1. **[Sigstore](/2024/08/12/what-is-sigstore/) keyless signing** - a short-lived certificate is issued based on the workflow's OIDC identity. No long-lived keys to manage or rotate. 2. **[in-toto](/2024/08/14/what-is-in-toto/) attestation format** - the SBOM digest and build provenance are wrapped in a standardized [SLSA](/2024/08/17/what-is-slsa/) provenance predicate inside an in-toto envelope. 3. **Transparency log** - the signing event is recorded in Sigstore's Rekor transparency log, creating tamper-evident, publicly auditable proof that the signature existed at a specific time. The combination means the signature is tied to a verified identity (your GitHub repository and workflow), recorded in an immutable log, and verifiable by anyone - without any key distribution. ## sbomify attestation verification sbomify can verify attestations automatically when you upload signed SBOMs. The **SBOM Verification** plugin uses Sigstore and cosign to check signatures on upload, giving you a verified provenance status for every SBOM in your portfolio. It re-computes the SBOM digest, validates any attached cosign signature, and confirms the provenance subject digest matches the SBOM hash. A single check now covers both sbomify-stored signatures and GitHub-published Sigstore attestations. These were [originally handled by two separate plugins](/2026/01/23/announcing-sbomify-v0-25-the-one-with-attestations/); the GitHub Attestation plugin has since been folded into SBOM Verification, so there is only one plugin to enable. Enable it from the **Plugins** page in your workspace sidebar: This closes the loop: your CI pipeline signs the SBOM, sbomify verifies the signature on ingestion, and your customers can independently verify the same signature when they download the SBOM from your Trust Center. ## Alternative: signing with your own certificates GitHub Attestations and Sigstore are not the only way to sign an SBOM. Organizations that already have their own certificate infrastructure can sign SBOMs using standard X.509 certificates and their existing signing keys. The principle is the same: cryptographically bind the SBOM to a known identity so that consumers can verify authenticity and integrity, without depending on an external service like Sigstore or GitHub. Both CycloneDX and SPDX 3.0 support inlining the signature directly within the SBOM document. This makes the SBOM a self-contained bundle where the data and its proof of authenticity travel together in a single file. The trade-off is that both generation and verification are more involved. To sign, you generate the SBOM, sign the content, then assemble the final document with the signature embedded. To verify, you need to disassemble the SBOM to separate the signature from the content, validate the certificate chain (and obtain the public key if the certificate is self-signed), and then verify the signature against the original content. It is more work than running `gh attestation verify`, but the benefit is that everything is in one place and the workflow integrates naturally with enterprise signing infrastructure. It is also possible to sign SBOMs using PGP, though this is less common today given the shift toward Sigstore's keyless model and X.509 certificate-based signing. Whichever method you choose, the core guarantees are the same: the recipient can verify who produced the SBOM and confirm it has not been altered since signing. The best approach depends on your existing infrastructure and your consumers' verification capabilities. ## Further reading - [What is Sigstore?](/2024/08/12/what-is-sigstore/) - how keyless signing works - [What is in-toto?](/2024/08/14/what-is-in-toto/) - the attestation framework behind SBOM signing - [GitHub Action with attestation](/2024/10/31/github-action-update-and-attestation/) - step-by-step walkthrough - [sbomify v0.25: attestation verification](/2026/01/23/announcing-sbomify-v0-25-the-one-with-attestations/) - server-side verification - [What is SLSA?](/2024/08/17/what-is-slsa/) - the provenance framework built on in-toto and Sigstore --- # How do I use CRA compliance in sbomify? URL: https://sbomify.com/faq/how-do-i-use-cra-compliance/ Description: Practical walkthrough of the sbomify CRA Compliance Wizard: scope screening, the five wizard steps, what ends up in the export bundle, and how to sign it. ## Walkthrough ## Plan availability The CRA Compliance Wizard is available on the **Business** and **Enterprise** plans. Community workspaces can still produce CRA-quality SBOMs via the [CRA Compliance plugin](/faq/what-is-the-eu-cyber-resilience-act/), but the structured assessment, OSCAL output, and ready-to-sign export bundle live on Business+. ## Where to start: scope screening Not every product needs to file CRA conformity. Before the wizard opens, sbomify runs a short **scope screening** that asks the questions Article 2 and Article 3 of the [CRA](/compliance/eu-cra/) require you to answer: - Does the product have a remote data connection? - Is it strictly for own-use within the manufacturer? - Is it a testing or pre-production version? - Is it covered by other Union legislation that already imposes equivalent requirements? - Is it a dual-use item subject to export control? If the screening finds the product is out of scope, sbomify records the determination (with a timestamp and the user who made it) and you do not need to fill in the wizard. The screening result itself is part of the audit trail and is included in the export bundle. If anything changes later, a new feature adds a network connection, the product enters the EU market, you can re-run the screening from the same Product page. ## The five wizard steps Once a product is in scope, the wizard walks through the assessment in five steps. You can leave and come back at any point; sbomify saves each step as you go. ### Step 1: Product Profile Captures the classification and lifecycle data the CRA references throughout: - **Product category**: Default, Class I, Class II, or Critical (CRA Annex III/IV) - **Open-source steward status**: for the lighter obligations under Article 24 - **Radio Equipment Directive flags**: `is_radio_equipment`, `processes_personal_data`, `handles_financial_value`. These trigger the [EN 18031](/compliance/eu-cra/) harmonised standards when applicable. - **Harmonised standards applied**: which CRA-aligned standards (BSI TR-03183-2, EN 18031-1/2/3, etc.) the product claims conformity against - **Intended use, target EU markets, and support period**: the lifecycle envelope for vulnerability-handling obligations - **Conformity assessment procedure**: self-assessment, internal control, or notified body involvement, depending on category This is the only step that determines which downstream steps apply (for example, EN 18031 sections only render when the corresponding flags are set in Step 1). ### Step 2: SBOM Compliance Reviews the SBOM coverage of every component attached to the product against [BSI TR-03183-2](https://bsi.bund.de/dok/TR-03183-en), the technical specification the CRA points at. For each component, sbomify shows: - Whether an SBOM is present and which format (CycloneDX 1.6+ or SPDX 3.0.1+) - The BSI assessment findings produced by the CRA Compliance plugin - Inline guidance for any failing finding (for example, missing supplier name, missing licences, embedded vulnerability data) If a finding is failing for a tooling reason that you cannot fix today (for example, a transitive dependency that does not publish a SHA-512 hash), you can record a **tooling-limitation waiver** with a justification. Waivers are tracked per finding and surface in the Step 5 review and the export manifest, so an auditor can see what was waived and why. ### Step 3: Security & Vulnerability Three tabs, mapping to CRA Annex I Part II: - **Security checklist**: an OSCAL-driven control list (the [BSI OSCAL profile](/compliance/eu-cra/) by default). Each control accepts a status of _satisfied_, _not satisfied_, or _not applicable_, plus a free-text justification. The state is stored as OSCAL Assessment Results, not free-form prose, so it is machine-readable in the export. - **Vulnerability handling**: VDP URL, acknowledgement timeline (default 90 days), incident response plan URL. If your workspace has a [Trust Center](/faq/what-is-a-trust-center/) with `security.txt` configured, sbomify reuses those values rather than asking again. - **Incident reporting**: CSIRT contact, ENISA Single Reporting Platform registration status. The [SRP](/compliance/eu-cra/) is live from 2026-09-11, and the wizard tracks whether you have named your Assigned Representatives and identified the CSIRT designated as coordinator you would actually file with. ### Step 4: User Information The end-user-facing information CRA Article 13 and Annex II require: support contact, update frequency and delivery method, secure-decommissioning instructions, data-deletion guidance. The wizard ships product-type templates (web app, embedded, library, IoT, etc.) that pre-fill sensible defaults you can edit in place. ### Step 5: Review & Export The final step shows a single-page summary of every answer, the BSI findings, the waivers you recorded, and the documents that will be included. Two outcomes: - **Mark complete**: flips the assessment to `complete`. Re-running the wizard (for example after an SBOM change) marks the assessment `stale` and surfaces a banner so you know the export no longer reflects the current state. - **Generate compliance bundle**: produces the export ZIP described below. ## What is in the export bundle A single CRA bundle is one ZIP with the following structure: - `oscal/catalog.json`, the OSCAL catalogue the assessment was run against - `oscal/assessment-results.json`, your OSCAL Assessment Results (every control, status, and justification) - `documents/vulnerability-disclosure-policy.md` - `documents/risk-assessment.md` - `documents/user-instructions.md` - `documents/secure-decommissioning.md` - `documents/declaration-of-conformity.md` (EU DoC, plus EN 18031 DoC where applicable) - `article-14/README_REPORTING.md`, Article 14 / Article 16 reporting deadlines, ENISA SRP entry points, and which template to use for early-warning, vulnerability-notification, and final reports - `sboms/-.json`, the latest SBOM for each component in the product, named so it is easy to diff between exports - `metadata/harmonised-standards.json`, embedded snapshot of the CRA harmonised-standards reference, so the bundle is self-contained - `metadata/manifest.json`, every file in the bundle with its SHA-256 digest, the assessment id, the product, the manufacturer, the conformity procedure, and the format version - `metadata/manifest.sha256`, the manifest's own digest, so a verifier can confirm the manifest itself has not been altered - `metadata/INTEGRITY.md`, verification instructions for an auditor or notified body The manifest is what makes the bundle auditable: a single SHA-256 against `metadata/manifest.sha256` proves the entire ZIP is intact, and per-file digests in `manifest.json` let a reviewer spot-check any individual artifact. ## Signing the bundle sbomify produces the bundle but does not sign it in the application. Signing is a single operator step you run after export, the same machinery you would use to [sign an SBOM](/faq/how-do-i-sign-an-sbom/), pointed at the ZIP: ```bash cosign sign-blob \ --bundle cra-bundle.cosign.bundle \ cra-bundle.zip ``` In CI, use `actions/attest-build-provenance` against the downloaded ZIP and store the signature alongside the bundle. Whichever approach you take, distribute the signature with the ZIP, your customers and auditors can then verify the bundle has not been altered between export and review. ## Stale assessments The CRA is a continuous obligation. If a component changes after you marked an assessment complete, a new dependency appears, an SBOM is re-uploaded, a control is updated, sbomify flags the assessment as **stale** and prompts you to re-run the affected steps. Exported bundles still contain a timestamp and the assessment id, so a stale flag in the UI does not invalidate previously distributed bundles; it just tells you the next export will produce different content. ## Further reading - [What is the EU Cyber Resilience Act?](/faq/what-is-the-eu-cyber-resilience-act/) - the regulatory background - [EU Cyber Resilience Act compliance guide](/compliance/eu-cra/) - field-level CRA reference - [How do I sign an SBOM?](/faq/how-do-i-sign-an-sbom/) - same mechanics apply to signing the CRA bundle - [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/) - how the BSI SBOM/VEX split is enforced in Step 2 - [Schema Crosswalk](/compliance/schema-crosswalk/) - field mappings for CycloneDX 1.7, SPDX 2.3, and SPDX 3.0 - [BSI TR-03183-2](https://bsi.bund.de/dok/TR-03183-en) - the technical specification the wizard assesses against --- # How do I generate an SBOM? URL: https://sbomify.com/faq/how-do-i-generate-an-sbom/ Description: Step-by-step guide to generating your first SBOM using sbomify-action, open-source tools, and CI/CD integration. ## Fastest path: the setup wizard If you are starting from scratch, run the interactive [setup wizard](/faq/how-do-i-use-the-sbomify-setup-wizard/) from the root of your repository. The Docker image bundles everything it needs: ```bash docker run --rm -it \ -v "$(pwd):/github/workspace" \ -w /github/workspace \ ghcr.io/sbomify/sbomify-action \ sbomify-action wizard ``` The wizard scans your repo for lockfiles, signs you in to sbomify, creates your product and components, registers [OIDC trusted publishing](/faq/how-do-i-set-up-oidc-trusted-publishing/), and writes a ready-to-commit `.github/workflows/sboms.yml`. Commit the file and your next push generates and uploads an SBOM. ## Recommended: sbomify-action The [sbomify Action](/sbomify-action/) is a CI/CD tool that generates, augments, enriches, and uploads SBOMs from your lockfiles or Docker images. It works as a GitHub Action, Docker image, or pip package, and includes SBOM generators (Syft, cdxgen, and native ecosystem tools) pre-installed. ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json ENRICH: true ``` sbomify-action supports 17 ecosystems (Python, JavaScript, Java, Go, Rust, Ruby, PHP, .NET, Swift, Dart, Elixir, Scala, C++, Terraform, Haskell, Erlang, and Clojure), plus Docker images, directory scans and Yocto/OpenEmbedded builds. It outputs both CycloneDX and SPDX formats. Beyond basic generation, sbomify-action can: - **Enrich** SBOMs with metadata from package registries (PyPI, npm, crates.io, etc.) - **Augment** with business metadata (supplier, authors, licenses, lifecycle phase) - **Inject** additional packages not in lockfiles (vendored code, system libraries) - **Upload** to sbomify for collaboration and vulnerability management - **Attest** with GitHub's build provenance It also works with [GitLab CI and Bitbucket Pipelines](https://github.com/sbomify/sbomify-action#other-cicd-platforms). See our [CI/CD integration guide](/guides/ci-cd/) for details. ### Using Docker directly The sbomify-action Docker image can be used standalone, without any CI platform: ```bash docker run --rm \ -v $(pwd):/github/workspace \ -w /github/workspace \ -e LOCK_FILE=/github/workspace/requirements.txt \ -e OUTPUT_FILE=/github/workspace/sbom.cdx.json \ -e UPLOAD=false \ -e ENRICH=true \ ghcr.io/sbomify/sbomify-action ``` This is useful for local development, scripted workflows, or CI systems that don't have a native sbomify-action integration. ## Standalone tools If you prefer standalone tools outside of CI/CD, **Syft** is a popular option: ```bash # Using Syft syft . -o cyclonedx-json > sbom.cdx.json ``` Note: We [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following two successful supply chain attacks in March 2026 and have removed it from sbomify-action. For language-specific generators, see our [language guides](/guides/) covering Python, JavaScript, Java, Go, Rust, Docker, and more. ## See it in action Watch our FOSDEM 2026 talk for a real-world walkthrough of CRA-ready SBOM generation using sbomify-action: ## Next steps Once you have your SBOM, [upload it to sbomify](https://app.sbomify.com) to monitor for vulnerabilities, track compliance, and share it with customers through your [Trust Center](https://trust.sbomify.com/). --- # How do I use the sbomify setup wizard? URL: https://sbomify.com/faq/how-do-i-use-the-sbomify-setup-wizard/ Description: The interactive setup wizard (sbomify-action wizard) scans your repository, creates your products and components, sets up OIDC trusted publishing, and writes a ready-to-commit GitHub Actions workflow. ## What the wizard does The setup wizard is an interactive terminal UI built into [sbomify-action](https://github.com/sbomify/sbomify-action). It is the recommended way to onboard a repository, because it automates every step that used to be manual: 1. **Scans your repository** for lockfiles across all supported ecosystems (Python, JavaScript, Java, Go, Rust, and more) and proposes one component per lockfile it finds. 2. **Signs you in to sbomify** so it can work against your workspace. 3. **Picks or creates the product and components** your SBOMs will belong to. 4. **Lets you choose your options**: release strategy, SBOM format, enrichment, and attestation. 5. **Registers OIDC trusted publishing** for each component, so your workflow needs no long-lived token secret. See [How do I set up OIDC trusted publishing?](/faq/how-do-i-set-up-oidc-trusted-publishing/) for how that works. 6. **Writes a ready-to-commit `.github/workflows/sboms.yml`** (and an optional `sbomify.json` for business metadata), pinned to the latest sbomify-action release. Commit the generated workflow file and your next push generates, enriches, and uploads an SBOM. ## Running it Run the wizard from the root of your repository with the Docker image. The image bundles every tool the wizard needs, so there is nothing else to install: ```bash docker run --rm -it \ -v "$(pwd):/github/workspace" \ -w /github/workspace \ ghcr.io/sbomify/sbomify-action \ sbomify-action wizard ``` The `-it` flags are required because the wizard is interactive, and the volume mount is what lets it write the generated workflow back into your repo. If you prefer not to use Docker, you can also run `uvx sbomify-action wizard` (or `pipx run sbomify-action wizard`) directly (`sbomify-action init` is a backwards-compatible alias). Useful flags: - `--dry-run` - preview the full plan without making API changes or writing files - `--repo-root ` - point at a repository other than the current directory - `--output-dir ` - where the workflow is written (must resolve to `.github/workflows`) The wizard is designed for interactive use and refuses to run inside CI. It also will not overwrite a hand-authored `sboms.yml`; it only manages workflows it generated. In CI, you run the workflow file the wizard produced. ## When to configure things manually instead The wizard targets GitHub Actions. If you use GitLab CI, Bitbucket Pipelines, or another CI system, use the Docker image or pip package directly - see our [integrations page](/features/integrations/) and [CI/CD guide](/guides/ci-cd/) for ready-to-use templates. Everything the wizard configures can also be set up by hand: components in the [sbomify app](https://app.sbomify.com), workflow YAML from the templates. ## Further reading - [How do I generate an SBOM?](/faq/how-do-i-generate-an-sbom/) - the broader generation options - [How do I set up OIDC trusted publishing?](/faq/how-do-i-set-up-oidc-trusted-publishing/) - tokenless uploads explained - [Zero to Hero](/zero-to-hero/) - the full onboarding walkthrough --- # How do I set up OIDC trusted publishing? URL: https://sbomify.com/faq/how-do-i-set-up-oidc-trusted-publishing/ Description: OIDC trusted publishing lets GitHub Actions upload SBOMs to sbomify without any long-lived token secret, using short-lived OpenID Connect tokens instead. ## What trusted publishing is Long-lived API tokens are a liability: they live in secret stores, they leak, and they need rotating (sbomify personal access tokens expire after 90 days by default for exactly this reason). Trusted publishing, the same model PyPI uses, removes them entirely for CI uploads. Instead of a stored secret, GitHub Actions mints a short-lived OpenID Connect (OIDC) token for each workflow run that cryptographically proves which repository and workflow is running. sbomify verifies that token and exchanges it for a sbomify access token that is valid for about 15 minutes and scoped to the one component the repository is bound to. When the run ends, there is nothing left to steal. ## Setting it up The screencast below walks the whole flow end to end: adding the repository binding, expanding the generated GitHub Actions snippet, the runner exchanging its OIDC token for a short-lived sbomify token, and the resulting SBOM landing on the component. ### 1. Create the trusted publisher binding In the [sbomify app](https://app.sbomify.com), open your component's settings and add a **Trusted Publisher** with your GitHub organization and repository. Private repositories are supported. To defeat repository resurrection attacks, sbomify pins the immutable GitHub repository and owner IDs, not just the names. If you onboard with the [setup wizard](/faq/how-do-i-use-the-sbomify-setup-wizard/), this step happens automatically. ### 2. Update your workflow Grant the OIDC permission and remove the `TOKEN` secret: ```yaml permissions: id-token: write steps: - name: Upload SBOM uses: sbomify/sbomify-action@master env: COMPONENT_ID: 'my-component-id' LOCK_FILE: 'requirements.txt' AUGMENT: true ENRICH: true UPLOAD: true ``` That is the whole setup. sbomify-action auto-detects the OIDC environment when no `TOKEN` is set. If both are present, `TOKEN` takes precedence. Self-hosted sbomify instances can override the token audience with the `oidc-audience` input (default `sbomify.com`). ## Scope and limits - The exchanged token is scoped to the component bound to the repository. A compromised workflow cannot touch the rest of your workspace. - OIDC trusted publishing currently works in **GitHub Actions**. On GitLab CI, Bitbucket Pipelines, and other CI systems, keep using a token via the `TOKEN` environment variable. - Uploads, augmentation, and release tagging all work over the exchanged token. ## Further reading - [How do I use the sbomify setup wizard?](/faq/how-do-i-use-the-sbomify-setup-wizard/) - registers trusted publishing for you - [How do I generate an SBOM?](/faq/how-do-i-generate-an-sbom/) - the generation pipeline the upload belongs to - [How do I sign an SBOM?](/faq/how-do-i-sign-an-sbom/) - complementary provenance for the SBOM itself --- # How do I enable vulnerability scanning in sbomify? URL: https://sbomify.com/faq/how-do-i-enable-vulnerability-scanning/ Description: Guide to enabling vulnerability scanning in sbomify using Google OSV and Dependency Track, including plan availability and scan frequency. ## How to enable Vulnerability scanning is implemented as a plugin. To enable it: 1. Navigate to the **Plugins** page in your workspace sidebar 2. Toggle the **OSV** plugin on (and/or **Dependency Track** if on a Business plan or above) and click **Save** Once enabled, any SBOM you upload is automatically scanned for known vulnerabilities. When you enable the plugin, recent SBOMs are also retroactively scanned. ## Re-scan frequency sbomify periodically re-scans your SBOMs as vulnerability databases are updated. The frequency depends on your plan: - **Community (free)** - weekly re-scans - **Business / Enterprise** - daily re-scans ## Scanning providers ### Google OSV (all plans) [Google OSV](https://osv.dev/) is available on every plan, including the free Community tier. It provides precise, distributed vulnerability intelligence across a wide range of ecosystems. Supports CycloneDX and SPDX 2.x formats. ### Dependency Track (Business+) [OWASP Dependency Track](https://dependencytrack.org/) integration is available on Business plans and above for continuous component analysis. Dependency Track only supports CycloneDX format. Enterprise customers can connect their own Dependency Track instance for unified visibility across their existing security tooling. ## VEX-aware results Scan results are not just a raw CVE dump. If you have uploaded [VEX documents](/faq/how-do-i-use-vex/) or triaged findings in sbomify, your `not_affected` statements suppress those findings in both the OSV and Dependency Track results, so the dashboard shows your actual exposure. Findings listed in the CISA Known Exploited Vulnerabilities (KEV) catalog are flagged so you can prioritize the vulnerabilities attackers actually use, and the in-app triage workflow supports bulk decisions with a dry-run preview before anything is committed. ## Further reading - [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/) - [Integrations - Vulnerability Analysis](/features/integrations/#vulnerability-analysis) - [sbomify-action Dependency Track configuration](https://github.com/sbomify/sbomify-action#dependency-track-configuration) --- # What VEX formats does sbomify support? URL: https://sbomify.com/faq/what-vex-formats-does-sbomify-support/ Description: sbomify natively ingests VEX documents in CycloneDX VEX (JSON and XML), OpenVEX, and CSAF 2.0 VEX formats, with automatic format detection. ## Supported formats sbomify ingests VEX documents in the three formats that matter in practice, and detects which one you uploaded automatically: | Format | Typical producers | Notes | | ----------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------- | | **CycloneDX VEX** | Dependency-Track exports, CycloneDX tooling, sbomify's own triage | JSON and XML accepted; the richest format, with five analysis states | | **OpenVEX** | [vexctl](https://github.com/openvex/vexctl), Chainguard tooling | Lightweight JSON-LD format from the OpenVEX project | | **CSAF 2.0 VEX** | OS and hardware vendor advisories (Red Hat, Cisco, SUSE, and others) | The OASIS standard for machine-readable security advisories | One nuance worth knowing: `not_affected` statements suppress findings from all three formats, while the `false_positive` analysis state is specific to CycloneDX. ## How to upload - **In the app.** Use the upload panel on the component page. VEX artifacts are listed next to SBOMs with their own badge. - **Via the API.** CycloneDX VEX goes to the CycloneDX artifact endpoint with `bom_type=vex`; OpenVEX and CSAF documents go to the format-agnostic `/api/v1/sboms/artifact/vex/` endpoint, which detects the format for you. - **From CI.** Set `BOM_TYPE: vex` in your [sbomify-action](https://github.com/sbomify/sbomify-action) step. The document is uploaded verbatim, byte for byte, with no modification. ## What happens after upload Your VEX statements are applied to existing OSV and Dependency Track scan results, suppressing findings you have marked as not affected. Each release exposes a merged VEX download on both the internal release page and the public Trust Center release page. For the full workflow, including in-app triage, CISA KEV flags, and generating VEX from your own triage decisions, see [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/). ## Further reading - [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/) - the complete VEX workflow - [What SBOM formats does sbomify support?](/faq/what-sbom-formats-does-sbomify-support/) - the SBOM side of the house - [Schema crosswalk](/compliance/schema-crosswalk/) - how vulnerability data maps across CycloneDX, SPDX, CSAF, and VEX --- # How do I use VEX with sbomify? URL: https://sbomify.com/faq/how-do-i-use-vex/ Description: Learn how Vulnerability Exploitability eXchange (VEX) lets you communicate which vulnerabilities actually affect your product, and how to upload, triage, and distribute VEX documents through sbomify. ## Walkthrough The full lifecycle - a scanner finding, a VEX that marks it `not_affected`, the finding dropping out of the component's severity counts, and a re-issued VEX superseding the previous one: And how a VEX artifact renders next to its SBOM once uploaded: ## The problem VEX solves Run any modern vulnerability scanner against a real-world SBOM and you will get a list. A long list. Most of those CVEs do not actually affect your product: - The vulnerable function is in a code path your application never calls. - Your build configuration disables the vulnerable feature. - You have already applied a backport patch but the version string still reports the original. - The CVE applies to a different operating system or runtime than the one you ship. Telling that signal-from-noise story by hand - in spreadsheets, GitHub issues, ticket comments - does not scale. Every customer who downloads your SBOM has to re-derive the same conclusions, and every conclusion is just one engineer's opinion attached to no machine-readable artifact. **VEX (Vulnerability Exploitability eXchange)** is the standardized fix. It is a separate document that says, for each known vulnerability in your dependency tree, whether the vulnerability actually affects your product and why. Consumers feed your SBOM and your VEX into the same scanner together, and the scanner produces a triaged finding list instead of a raw one. ## What a VEX document looks like sbomify ingests VEX in three formats, with automatic format detection: **CycloneDX VEX** (a CycloneDX BOM with `vulnerabilities[]` populated, JSON or XML), **OpenVEX** (the lightweight format used by vexctl and Chainguard), and **CSAF 2.0 VEX** (the OASIS standard used heavily by OS vendors like Red Hat and Cisco). See [What VEX formats does sbomify support?](/faq/what-vex-formats-does-sbomify-support/) for the format-by-format details. A minimal CycloneDX VEX statement looks like this: ```json { "bomFormat": "CycloneDX", "specVersion": "1.6", "vulnerabilities": [ { "id": "CVE-2024-12345", "source": { "name": "NVD" }, "ratings": [{ "severity": "high" }], "affects": [{ "ref": "pkg:pypi/requests@2.32.3" }], "analysis": { "state": "not_affected", "justification": "code_not_reachable", "detail": "We use requests only for outbound HTTPS to a fixed allowlist of internal hosts. The vulnerable XML parser path is never exercised." } } ] } ``` The `analysis.state` field is the heart of VEX. CycloneDX defines five states: | State | When to use | | --------------------- | ------------------------------------------------------------------------------------------------- | | `not_affected` | Vulnerability is present in the dependency tree but not exploitable in your product | | `affected` | Vulnerability is present and your product is exposed - patch is in flight | | `exploitable` | Active exploitation is possible right now - alert your customers | | `under_investigation` | You are still triaging - publish to acknowledge but do not commit yet | | `fixed` | Vulnerability was present in an earlier release; the version your customer is using has the patch | When you mark a finding `not_affected`, you must also provide a `justification` from the standard set: `code_not_present`, `code_not_reachable`, `requires_configuration`, `requires_dependency`, `requires_environment`, `protected_by_compiler`, `protected_at_runtime`, `protected_at_perimeter`, `protected_by_mitigating_control`. Free-form prose goes in `detail`. This structure means a VEX statement is auditable: a regulator or a security team can ask "why did you mark this not_affected" and the JSON has the answer. ## VEX and the EU Cyber Resilience Act [BSI TR-03183-2](https://bsi.bund.de/dok/TR-03183-en) - the technical specification the [CRA](/compliance/eu-cra/) points at - explicitly forbids embedding vulnerability data inside the SBOM itself (§3.1, §8.1.14). Vulnerability handling is the _job_ of VEX or [CSAF](https://oasis-open.github.io/csaf-documentation/), not of the SBOM. In practice this means a CRA-compliant manufacturer publishes: 1. An **SBOM** describing the product's components (no vulnerability fields). 2. A **VEX** document (or CSAF) describing the current exploitability status of the CVEs that affect those components. 3. A **VDR** (Vulnerability Disclosure Report) summarizing the manufacturer's stance over time. sbomify's CRA Compliance plugin checks for the SBOM/VEX split and flags SBOMs that smuggle vulnerability data inline as non-compliant. ## Uploading VEX to sbomify sbomify treats a VEX document as a separate artifact attached to the same component as its SBOM. There is no separate "VEX component" - the relationship is artifact-to-component, the same as SBOMs. You can upload VEX in any supported format through the upload panel on the component page, via the API, or from CI. ### Via the API For CycloneDX VEX, use the same artifact endpoint as a regular SBOM upload, with `bom_type=vex`: ```bash curl -X POST "https://app.sbomify.com/api/v1/sboms/artifact/cyclonedx/?bom_type=vex" \ -H "Authorization: Bearer ${SBOMIFY_TOKEN}" \ -H "Content-Type: application/json" \ --data-binary "@my-product.vex.json" ``` OpenVEX and CSAF 2.0 VEX documents go to the format-agnostic VEX endpoint, where the format is detected automatically: ```bash curl -X POST "https://app.sbomify.com/api/v1/sboms/artifact/vex/" \ -H "Authorization: Bearer ${SBOMIFY_TOKEN}" \ -H "Content-Type: application/json" \ --data-binary "@my-product.openvex.json" ``` A successful upload returns the new artifact's id. The component detail page now lists the VEX alongside the SBOM, and the Trust Center exposes it under the same component. ### Via CI In your existing [sbomify-action](https://github.com/sbomify/sbomify-action) workflow, upload a pre-authored VEX with `BOM_TYPE: vex`. The document is uploaded verbatim, byte for byte, with format detection on the server side. With [OIDC trusted publishing](/faq/how-do-i-set-up-oidc-trusted-publishing/) you do not even need a token secret: ```yaml permissions: id-token: write steps: - name: Generate VEX run: ./scripts/produce-vex.sh sbom.cdx.json > vex.cdx.json - name: Upload VEX to sbomify uses: sbomify/sbomify-action@master env: COMPONENT_ID: ${{ vars.SBOMIFY_COMPONENT_ID }} SBOM_FILE: vex.cdx.json BOM_TYPE: vex UPLOAD: true ``` If your CI platform does not support OIDC, set `TOKEN: ${{ secrets.SBOMIFY_TOKEN }}` instead. The shape of `produce-vex.sh` is up to you - tools like [Dependency-Track's VEX export](https://docs.dependencytrack.org/usage/vex/), [vexctl](https://github.com/openvex/vexctl), or your own triage workflow can produce the input. ## Triaging vulnerabilities in sbomify You do not have to author VEX by hand or in an external tool. sbomify has an in-app triage workflow: - **In-app triage.** Review scanner findings on the vulnerability dashboard, record `not_affected` decisions with justifications, apply bulk decisions across CVEs, and preview the effect with a dry run before committing. - **CISA KEV flags.** Findings that appear in the CISA Known Exploited Vulnerabilities catalog are flagged so you triage the vulnerabilities that attackers actually use first. - **Self-VEX generation.** sbomify generates a CycloneDX VEX from your triage decisions, complete with CISA tracking fields (serial number and statement timestamps), so your published VEX always matches your ledger. - **Dependency Track sync.** If Dependency Track is your triage system of record, opt in and sbomify syncs your DT analysis decisions in as VEX, pinning them to the matching releases so you do not triage the same finding twice. Alternatively, keep a source-controlled `vex/` directory in the same repo that produces the SBOM, merge the per-CVE statements in CI, and upload the result alongside the SBOM. Pull requests on `vex/` carry the audit trail. ## Keeping your statements current A VEX statement is a claim about a specific version of your product, and claims expire. The vulnerable code path you ruled unreachable last quarter may be reachable after a refactor, and a new release can pull in High or Critical findings that no existing statement covers. Left alone, a stale `not_affected` is worse than no VEX at all: it tells your customers you have assessed something you have not. sbomify checks for this on a schedule and tells you when your VEX has drifted away from reality: - **Stale statements.** Statements that no longer match the findings on your current release are surfaced rather than silently carried forward. - **Uncovered High and Critical findings.** New findings at High or Critical severity with no VEX statement covering them are flagged, so the gap between "scanned" and "assessed" does not quietly widen between releases. This runs without configuration. The point is that VEX becomes something you can rely on for audit and customer questions, instead of a document that was accurate on the day it was written. ## Signing your VEX A VEX is a security-relevant claim about your product. Sign it with the same machinery you use to [sign your SBOM](/faq/how-do-i-sign-an-sbom/) - typically `actions/attest-build-provenance` against the VEX file path - so consumers can verify the VEX came from your CI pipeline and was not modified in transit. Without a signature, a VEX is only as trustworthy as the channel that delivered it. ## What sbomify does with VEX - **Scanner suppression.** Findings covered by a `not_affected` VEX statement are suppressed in your OSV and Dependency Track results, so the dashboard shows your triaged exposure instead of raw scanner noise. Uploading a new VEX re-applies it to existing scans automatically. - **Per-component listing.** The component detail page shows VEX artifacts alongside SBOMs, with distinct badges. - **Release-level VEX.** Each release exposes a merged VEX download, on both the internal release page and the public Trust Center release page, next to the release SBOM. - **Trust Center exposure.** Customers downloading from your Trust Center see and can fetch the VEX with the same access controls as the SBOM, and the release vulnerability posture card reflects your VEX-applied status. - **Audit trail.** Every VEX upload is logged the same way as an SBOM upload, with content hash, timestamp, and uploader identity. ## Further reading - [What VEX formats does sbomify support?](/faq/what-vex-formats-does-sbomify-support/) - CycloneDX VEX, OpenVEX, and CSAF 2.0 in detail - [EU Cyber Resilience Act compliance guide](/compliance/eu-cra/) - the regulatory framing for SBOM/VEX separation - [What is the EU Cyber Resilience Act?](/faq/what-is-the-eu-cyber-resilience-act/) - the higher-level FAQ - [How do I sign an SBOM?](/faq/how-do-i-sign-an-sbom/) - sign your VEX the same way - [How do I enable vulnerability scanning?](/faq/how-do-i-enable-vulnerability-scanning/) - the scanner output your VEX is responsive to - [Schema crosswalk](/compliance/schema-crosswalk/) - how vulnerability data maps across CycloneDX, SPDX, CSAF, and VEX - [CycloneDX VEX use case](https://cyclonedx.org/use-cases/#vulnerability-exploitability) - the upstream spec - [OpenVEX](https://github.com/openvex/spec) - a lightweight VEX format, natively supported by sbomify - [CSAF VEX](https://oasis-open.github.io/csaf-documentation/) - the OASIS standard, used heavily in the OS-vendor ecosystem --- # What is a CBOM and how does sbomify support it? URL: https://sbomify.com/faq/what-is-a-cbom/ Description: A Cryptography Bill of Materials (CBOM) inventories the cryptographic assets in your software. sbomify auto-detects CBOMs, builds a crypto inventory, and assesses post-quantum readiness. ## What a CBOM is A **Cryptography Bill of Materials (CBOM)** is a [CycloneDX](https://cyclonedx.org/capabilities/cbom/) BOM whose components include cryptographic assets: the algorithms, keys, certificates, protocols, and crypto libraries your software uses. Where an SBOM answers "what packages are in this product," a CBOM answers "what cryptography does this product depend on." That question is becoming urgent. Migrating to post-quantum cryptography starts with knowing where the quantum-vulnerable algorithms (RSA, ECDSA, classic Diffie-Hellman) live in your stack, and regulators are moving in the same direction: crypto agility features in NIST's post-quantum guidance and in EU CRA discussions alike. You cannot migrate what you have not inventoried. ## What sbomify does with CBOMs - **Auto-detection, whatever produced it.** Upload a CycloneDX document containing cryptographic assets and sbomify automatically classifies it as a CBOM, no special flag needed. Every CBOM lineage is ingested, and assets are normalized against the CycloneDX 1.7 cryptographic registry, so output from different generators lands in the same shape instead of depending on which tool you happened to use. You can also be explicit with `BOM_TYPE: cbom` in [sbomify-action](https://github.com/sbomify/sbomify-action), which uploads the document verbatim. - **Crypto-asset inventory.** The document detail page renders an inventory of the cryptographic assets found: algorithms, key sizes, certificates, and protocols. - **Post-quantum readiness.** The PQC readiness assessment plugin classifies each asset against NIST guidance and gives your component a post-quantum posture view, so you can see at a glance which algorithms are quantum-vulnerable and where. - **Workspace-level crypto posture.** Your workspace dashboard summarizes crypto posture alongside your other artifacts, so post-quantum readiness is visible across the estate rather than one component at a time. - **Trust Center distribution.** CBOMs appear on your public release pages next to SBOMs and VEX, with the same access controls, and are exposed through the [Transparency Exchange API](/faq/how-do-i-enable-tea-in-sbomify/) as a supported artifact type. ## How do I generate a CBOM? CBOM generation tools are still an emerging space. [cbomkit](https://github.com/PQCA/cbomkit) and IBM's CBOM tooling can scan source code for cryptographic usage, and CycloneDX 1.6+ has first-class support for cryptographic asset types. However you produce it, sbomify handles storage, classification, analysis, and distribution: ```yaml - name: Upload CBOM uses: sbomify/sbomify-action@master env: COMPONENT_ID: 'my-component-id' SBOM_FILE: 'my-product.cbom.json' BOM_TYPE: cbom UPLOAD: true ``` ## Further reading - [What SBOM formats does sbomify support?](/faq/what-sbom-formats-does-sbomify-support/) - formats and BOM types overview - [How do I enable TEA in sbomify?](/faq/how-do-i-enable-tea-in-sbomify/) - programmatic artifact discovery, CBOMs included - [sbomify goes quantum-ready](/2026/07/07/announcing-sbomify-v26-7-0-the-one-that-gets-quantum-ready/) - the release announcement with more background --- # How does sbomify count vulnerabilities? URL: https://sbomify.com/faq/how-does-sbomify-count-vulnerabilities/ Description: sbomify counts vulnerabilities against your current posture - the latest artifact per component and format - not by summing findings across every SBOM version you have ever uploaded. ## The short answer Counts reflect **current posture**: the findings present in the latest artifact for each component and format, after VEX statements are applied. They are not a cumulative total of everything ever scanned. This is the behaviour you want, because it means the number responds to your work. Fix a vulnerability, upload a new SBOM, and the count goes down. ## Why your count may have dropped If you have been using sbomify for a while and your totals fell noticeably around v26.7.1, nothing broke and nothing was fixed in your software. The counts were previously aggregated across **every historical SBOM version** for a component rather than the current one. The practical effect was a number that could only ever go up. Upload ten iterations of a component over six months, remediate along the way, and findings from all ten versions were still counted, including ones you had already fixed and superseded. That is now corrected, so expect the totals to drop, in many cases substantially. The new number is the honest one. ## What is included in a count - **The latest artifact per component and format.** A CycloneDX SBOM and an SPDX SBOM for the same component are both current; version 3 of that CycloneDX SBOM supersedes versions 1 and 2. - **Findings from your enabled scanners**, whether that is the built-in OSV scanning or [Dependency Track](/faq/how-do-i-enable-vulnerability-scanning/). - **Minus anything covered by VEX.** Findings you have marked `not_affected` are suppressed, so the dashboard shows triaged exposure rather than raw scanner output. See [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/). Skipped assessments are reported as skipped rather than counted as problems, so a scan that could not run does not inflate or deflate your posture. ## Release-scoped counts A release pins specific artifacts, so a release's vulnerability posture is calculated against the artifacts pinned to it rather than whatever is newest on the component. This is deliberate: a release you shipped six months ago should report the posture of what you actually shipped, not of your current `main`. That release posture is what your customers see on the public [Trust Center](/features/trust-center/) release page. ## Further reading - [How do I enable vulnerability scanning?](/faq/how-do-i-enable-vulnerability-scanning/) - where the findings come from - [How do I use VEX with sbomify?](/faq/how-do-i-use-vex/) - suppressing findings that do not affect you - [How do I create a software release?](/faq/how-do-i-create-a-software-release/) - how artifacts get pinned to a release --- # What is a Trust Center? URL: https://sbomify.com/faq/what-is-a-trust-center/ Description: Learn what a Trust Center is, how it helps you share security artifacts transparently, and how sbomify makes it easy to create one. ## What is a Trust Center? A Trust Center is a dedicated page where your organization publicly shares security and compliance information about your products. Instead of handling security questionnaires and SBOM requests ad-hoc via email, you provide a single URL where customers and partners can find everything they need. A Trust Center typically includes: - **SBOMs** - Current Software Bill of Materials for your products - **Compliance status** - Which frameworks and standards you meet - **Security attestations** - Signed statements about your security practices - **Vulnerability disclosures** - How you handle and communicate security issues ## Why does it matter? Enterprise buyers and regulated industries increasingly require evidence of security practices during procurement. A Trust Center: - **Reduces friction** - Customers self-serve instead of sending questionnaires - **Scales trust** - One page serves all customers, partners, and auditors - **Demonstrates maturity** - Shows you take supply chain security seriously - **Meets compliance requirements** - CRA and other regulations require transparency about software composition ## sbomify's Trust Center sbomify includes a built-in Trust Center on the Business and Enterprise plans that automatically publishes your uploaded SBOMs and compliance artifacts. You can see a live example at [trust.sbomify.com](https://trust.sbomify.com/) - that's sbomify's own Trust Center, built with the same feature available to Business and Enterprise users. Key features: - **Automatic updates** - When you upload a new SBOM, your Trust Center reflects it immediately - **Custom domain** - Map your Trust Center to your own domain (e.g., trust.yourcompany.com) - **Granular access** - Choose which artifacts are public vs. private - **Compliance badges** - Show which standards your products meet ## Getting started 1. [Sign up for sbomify](https://app.sbomify.com) on a Business or Enterprise plan 2. Upload your SBOMs 3. Configure your Trust Center settings 4. Optionally map it to your own domain 5. Share the URL with customers No additional hosting is required - sbomify handles everything. --- # How do I set up a Trust Center in sbomify? URL: https://sbomify.com/faq/how-do-i-set-up-a-trust-center/ Description: Step-by-step guide to enabling and configuring a Trust Center in sbomify, including custom domain setup, security.txt, NDA upload, and component visibility. ## Walkthrough ## Setting up a Trust Center The Trust Center is available on the **Business** plan and above. For background on what a Trust Center is and why it matters, see [What is a Trust Center?](/faq/what-is-a-trust-center/). To set up your Trust Center: 1. Navigate to **Settings** and open the **Trust Center** tab 2. **Enable** your Trust Center 3. (Optional) Toggle on **security.txt** to publish an [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116) `/.well-known/security.txt` file with your security contact details 4. (Optional) Upload your **Company NDA** so it can be presented to visitors who request access to gated content 5. Set your **custom domain** (e.g. `trust.yourcompany.com`) and click **Save Domain** 6. Configure a CNAME record with your DNS provider pointing to sbomify, then wait for the domain to validate Once enabled, your uploaded SBOMs and compliance documents are automatically published to your Trust Center. Public release pages also expose release-level [VEX](/faq/how-do-i-use-vex/) and [CBOM](/faq/what-is-a-cbom/) downloads next to the release SBOM. You can see a live example at [trust.sbomify.com](https://trust.sbomify.com/). ## Component visibility Not everything in a Trust Center needs to be public. Each component has a **visibility** setting on its detail page that controls how visitors interact with it: - **Public** - artifacts are listed and downloadable by anyone visiting the Trust Center - **Gated** - artifacts are listed but visitors must request access (and, if you uploaded one, accept your Company NDA) before they can download - **Private** - the component is hidden from the Trust Center entirely Gated content lets you keep control over sensitive artifacts like penetration test reports or detailed SBOMs. When the Company NDA is uploaded, gated requests must accept it; otherwise visitors simply request access and you approve or deny manually. Approval requests show up in your sbomify dashboard so you can review them. --- # How do I enable the Transparency Exchange API (TEA) in sbomify? URL: https://sbomify.com/faq/how-do-i-enable-tea-in-sbomify/ Description: Step-by-step guide to enabling the Transparency Exchange API (TEA) in sbomify for automated SBOM discovery and distribution. ## Walkthrough ## What is TEA? The [Transparency Exchange API (TEA)](https://github.com/CycloneDX/transparency-exchange-api) is a standardized, format-agnostic API for automating software supply chain transparency. Developed within ECMA TC54, it provides a standard way for vendors and open-source projects to share transparency artifacts with downstream consumers. TEA goes beyond just SBOMs. It supports sharing a range of artifact types: - **SBOMs** - Software Bill of Materials - **VEX/VDR** - Vulnerability exploitability and disclosure reports - **CLE** - Common Lifecycle Enumeration (ECMA-428) - **CDXA** - CycloneDX Attestations for standards compliance - **HBOM, AI/ML-BOM, SaaSBOM, CBOM** - Hardware, AI/ML, SaaS, and Cryptography BOMs Instead of manually exchanging files via email or portals, TEA lets consumers programmatically discover and retrieve artifacts for any product release using a standard API. ## Enabling TEA TEA is available on the **Business** plan and above. It is delivered through your Trust Center, so the Trust Center must be enabled and reachable on a validated custom domain before TEA can be turned on. To enable it: 1. Navigate to **Settings** and open the **Trust Center** tab 2. **Enable** the Trust Center 3. Set a **custom domain** (e.g. `trust.yourcompany.com`) and click **Save Domain** 4. Configure the CNAME record at your DNS provider so the domain points to sbomify, then wait for validation 5. Once the domain is validated, toggle **TEA** on After TEA is enabled, sbomify exposes a discovery URL at `https:///.well-known/tea`. Consumers can hit that endpoint to programmatically discover and pull your published SBOMs and other transparency artifacts. --- # How do products work in sbomify? URL: https://sbomify.com/faq/how-do-products-work-in-sbomify/ Description: Understand sbomify's hierarchy of components, products, and releases for organizing and managing SBOMs across your software portfolio. ## The hierarchy sbomify uses a tree-like structure to organize your SBOMs in a way that reflects how your software is actually built: **Components → Products → Releases** Unlike tools that flatten everything into a single SBOM file (losing critical context like where an affected component lives), sbomify leverages CycloneDX and SPDX to link multiple SBOMs into a nested structure.
### Components Components are the foundation. Each component usually maps to a single repository (e.g., a GitHub repository) and holds the actual SBOMs as well as compliance documents and other artifacts. SBOMs are uploaded to components and versioned here. Note that the component SBOM version is different from the product version - a component may have many SBOM versions uploaded over time as its dependencies change, independent of product releases. ### Products A product represents the thing you actually sell or distribute. A product groups one or more components directly. For example, a "Smart Thermostat" product might attach backend, IoT, and compliance components, Python SBOM, Node SBOM, Docker SBOM, Yocto SBOM, SOC 2 Type II, CE Certificate, all under the one product. ### Releases A product can have releases. A release is a versioned snapshot that points to specific component SBOM versions. When you create a new release, your old SBOMs remain unchanged - giving you an accurate history of what was in each version. Because sbomify uses linkage rather than copying, multiple products (or versions of a product) can reuse the same component SBOMs without duplication.
## Walkthrough ## Sharing and exporting You can export and share SBOMs at any level of the hierarchy - a single component or the entire product. This is useful when different stakeholders need different levels of detail. For example, an internal team might need just one component's SBOM, while a customer or auditor needs the full product SBOM. Products and their SBOMs can be shared publicly through your [Trust Center](/faq/what-is-a-trust-center/) (available on Business and Enterprise plans). ## Further reading - [SBOM Hierarchy feature page](/features/sbom-hierarchy/) - [Share and Collaborate](/share-and-collaborate/) - [Screenly case study](/case-studies/screenly/) - a real-world example of the hierarchy in production --- # How do I upload compliance documents? URL: https://sbomify.com/faq/how-do-i-upload-compliance-documents/ Description: Step-by-step guide to uploading compliance documents like SOC 2, ISO 27001, and CE certificates in sbomify by creating a Document component. ## Walkthrough ## Uploading compliance documents sbomify treats compliance documents - such as SOC 2 Type II reports, ISO 27001 certificates, CE certificates, and other attestations - as **Document components**. Like SBOM components they hold versioned artifacts, but their content is a PDF instead of an SBOM. Marking the component as **workspace-wide** means a single SOC 2 report can be linked into every product that needs it, without re-uploading. To upload a compliance document: 1. Navigate to **Components** in the workspace sidebar 2. Click **Add Component**, name it (e.g. `SOC 2 Type II Compliance`), set **Type** to **Document**, and tick **Workspace-wide component**, then submit 3. Open the new component and fill in the upload form: **Version** (e.g. `2024`), **Document Type** (e.g. `Compliance`), **Subcategory** (e.g. `SOC 2`), and a short **Description** 4. Choose the file and click **Save Document** The uploaded document appears in the component's documents table and can be linked to any product that uses this component, and shared externally via your [Trust Center](/faq/what-is-a-trust-center/). --- # How do I create a software release in sbomify? URL: https://sbomify.com/faq/how-do-i-create-a-software-release/ Description: Step-by-step guide to creating a product release in sbomify by linking existing component SBOMs to a versioned release. ## Walkthrough ## Creating a product release A product release in sbomify ties together one or more component SBOMs (and other artifacts like compliance documents) under a single version. This is how you represent a shipped version of your software. ### Prerequisites Before creating a release, you need: - A **product** set up in sbomify (see [How do products work?](/faq/how-do-products-work-in-sbomify/)) - One or more **components** with uploaded SBOMs ### The "Latest" release The first time an SBOM is uploaded against a product, sbomify automatically creates a `Latest` release that always points to the most recent SBOM version of each component. You don't need to manage it - it's there as a stable URL for "whatever is current". Named releases (e.g. `v2.1.0`) are immutable snapshots and are what you should share with customers and auditors. ### Steps 1. Navigate to your **Product** and scroll to the **Releases** section 2. Click **Create Release** and fill in the modal: **Name** (e.g. `Middle-Out Rewrite`), **Version** (e.g. `v2.1.0`), and an optional **Description**, then click **Create** 3. Click into the new release 4. Click **Add Artifact**, use **Select All Visible** (or pick individual SBOMs and documents) in the artifact picker, then click **Add to Release** ### How versioning works Component SBOMs and product releases are versioned independently. For example, your product `v2.1.0` might include a backend component at `v1.8.3` and a frontend at `v3.0.1`. The same component SBOM can also be shared across multiple product releases - if two products ship the same library version, there's no need to upload it twice. --- # How do I delete a workspace? URL: https://sbomify.com/faq/how-do-i-delete-a-workspace/ Description: Step-by-step guide to deleting a workspace in sbomify, including what happens to your data. ## Walkthrough ## Deleting a workspace To delete a workspace in sbomify: 1. Navigate to your workspace **Settings** 2. Stay on the **General** tab and scroll to the **Danger Zone** section 3. Expand the Danger Zone and click **Delete Workspace** 4. In the confirmation modal, type `delete` and click **Delete Workspace** This action is **permanent** and cannot be undone. All data associated with the workspace will be deleted, including products, components, SBOMs, and documents. --- # How do I delete my account? URL: https://sbomify.com/faq/how-do-i-delete-my-account/ Description: Step-by-step guide to deleting your account in sbomify, including what happens to your data. ## Walkthrough ## Deleting your account To delete your account in sbomify: 1. Navigate to **Settings** and open the **Account** tab 2. Scroll to the **Danger Zone** and expand it 3. Click **Delete Account** 4. In the confirmation modal, type `delete` and click **Delete My Account** This action is **permanent** and cannot be undone. All data associated with your account will be deleted. --- # How do I achieve NTIA/CISA minimum elements compliance? URL: https://sbomify.com/faq/how-do-i-achieve-ntia-cisa-compliance/ Description: Guide to meeting NTIA and CISA SBOM minimum elements requirements using sbomify-action's augmentation feature and sbomify's central profile management. ## The problem Most SBOM generation tools produce SBOMs that are missing key fields required by the [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/), which replaced the [NTIA 2021 Minimum Elements](/compliance/ntia-minimum-elements/) on 29 July 2026. Specifically, generated SBOMs typically lack: - **Supplier name** - the organization that supplies the component - **Authors** - who created the SBOM data - **Licenses** - per-component license information - **Lifecycle phase** - the SDLC phase where the SBOM was generated (CISA 2025) It is possible to achieve NTIA/CISA compliance using other tools, but it typically requires chaining together multiple tools and manually injecting data into the generated SBOM. sbomify-action is a toolkit that automates this process and provides best-effort quality improvements to your SBOMs in a single step. ## Option 1: Local config file You can provide augmentation metadata via a `sbomify.json` file in your project root. This works without a sbomify account: ```json { "lifecycle_phase": "build", "supplier": { "name": "Your Company", "url": "https://yourcompany.com" }, "authors": [ { "name": "Your Team", "email": "engineering@yourcompany.com" } ], "licenses": ["Apache-2.0"] } ``` Then enable augmentation in your CI pipeline: ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: requirements.txt OUTPUT_FILE: sbom.cdx.json AUGMENT: true ENRICH: true UPLOAD: false ``` This is ideal for individual projects or teams that want to manage metadata per-repository. ## Option 2: Central profile management in sbomify For organizations managing many components, sbomify provides centrally managed **Contact Profiles**. Instead of maintaining `sbomify.json` files in every repository, you configure the supplier, author, and contact metadata once in sbomify and it gets applied automatically during augmentation. ### Creating a profile In **Settings**, open the **Contacts** tab and click **Add Profile**. A profile contains one or more **Entities** (with manufacturer / supplier / author roles, name, email, phone, address, and website) and one or more **Contacts** on each entity (with author / security / technical roles). Toggle **Set as default** if this profile should apply to every component that does not override it. ### Using profiles Once you have a profile, there are two ways to apply it: - **Default profile** - Mark a profile as the workspace default, and it will be used for all components in that workspace during augmentation - **Per-component profile** - Manually select a specific profile on individual components for cases where different components need different metadata Then in your CI pipeline, simply enable augmentation with a sbomify account: ```yaml - uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: your-component-id LOCK_FILE: requirements.txt AUGMENT: true ENRICH: true ``` sbomify-action will fetch the profile metadata from sbomify and apply it to the generated SBOM automatically. ## Score uploaded SBOMs against the NTIA checklist sbomify ships a built-in **NTIA Minimum Elements (2021)** plugin that grades every uploaded SBOM against the seven required fields and surfaces the result on the SBOM detail page. Enable it from the **Plugins** page in your workspace sidebar: ## What gets added Augmentation addresses specific NTIA and CISA minimum element fields: | Field | NTIA 2021 | CISA 2025 | | ------------------- | --------- | -------------- | | Supplier Name | Required | Required | | Author of SBOM Data | Required | Required | | License | - | Required (new) | | Generation Context | - | Required (new) | For the full list of supported augmentation fields, see the [sbomify-action documentation](https://github.com/sbomify/sbomify-action#augmentation-vs-enrichment). ## Further reading - [Compliance overview](/compliance/) - all frameworks and standards sbomify supports - [NTIA Minimum Elements guide](/compliance/ntia-minimum-elements/) - [CISA 2026 Minimum Elements guide](/compliance/cisa-minimum-elements/) - [EU Cyber Resilience Act guide](/compliance/eu-cra/) - [Schema Crosswalk](/compliance/schema-crosswalk/) - how fields map across CycloneDX and SPDX - [sbomify-action augmentation reference](https://github.com/sbomify/sbomify-action#augmentation-config-file) --- # How do I attach signatures and provenance to SBOMs? URL: https://sbomify.com/faq/how-do-i-use-signature-files/ Description: Walk through uploading detached cryptographic signatures (cosign-bundle, PGP, PKCS#7) and SLSA in-toto provenance attestations to your SBOMs in sbomify, where the Signed and Provenance badges appear, and how the SBOM Verification plugin validates both. ## What this article covers The features described here landed in [sbomify/sbomify#880](https://github.com/sbomify/sbomify/pull/880). Each SBOM record in sbomify can now carry two independent cryptographic artefacts: - A **detached signature**: proves the SBOM bytes have not been altered since the issuer signed them. - A **provenance attestation**: proves the SBOM was produced by a specific build, in a specific repository, by a specific workflow. Both are uploaded through dedicated endpoints, stored as opaque blobs in object storage, and validated by the unified SBOM Verification plugin. They are _complementary_ rather than alternatives: a signature without provenance proves the bytes; provenance without a signature proves the build origin; together they prove both. For the producer-side guidance on _generating_ signatures and attestations in CI (GitHub Attestations, Sigstore keyless signing, the in-toto envelope format), see [How do I sign an SBOM?](/faq/how-do-i-sign-an-sbom/), that article is the upstream half of this one. ## Signature formats sbomify accepts The signature endpoint takes raw bytes in the request body plus an `X-Signature-Type` header that names the format. Three formats are recognised today: | `X-Signature-Type` value | Use when | Tooling | | ------------------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `cosign-bundle` | Sigstore / GitHub Attestations / keyless OIDC signing | [`cosign sign-blob --bundle`](https://docs.sigstore.dev/cosign/) or [`actions/attest-build-provenance`](https://github.com/actions/attest-build-provenance) | | `pgp-detached` | Long-lived organisational GPG keys | `gpg --detach-sign --armor sbom.cdx.json` | | `pkcs7` | Enterprise X.509 certificate chains, code-signing certs, hardware tokens | `openssl smime -sign -binary -outform DER` | The format string is the only thing sbomify uses to discriminate, the bytes themselves are stored opaquely. An unknown format value is rejected with `400 Bad Request`. Every SBOM holds at most one signature; uploading a second time without first removing the old one returns `409 Conflict`. ## Provenance formats sbomify accepts The provenance endpoint takes a JSON body. Two shapes are recognised: - **DSSE envelope**: the standard Sigstore-issued wrapper, identified by a top-level `payloadType` + `payload` (base64-encoded in-toto Statement). - **Direct in-toto Statement**: the unwrapped Statement body itself, identified by a top-level `_type` and `subject`. Either way, sbomify decodes down to the in-toto Statement, walks the `subject[].digest.sha256` array, and rejects the upload (`400 Bad Request`) unless one of those digests matches the SBOM's stored SHA-256. The check is intentional: a provenance attestation that does not name the actual SBOM file is meaningless, and silently accepting one would hide that mismatch from downstream consumers. The accepted Statement is stored as-is, sbomify does not re-shape or re-canonicalise it. ## The four endpoints ```text POST /api/v1/sboms/sbom//signature # raw bytes + X-Signature-Type GET /api/v1/sboms/sbom//signature # download stored bytes POST /api/v1/sboms/sbom//provenance # JSON body (DSSE or Statement) GET /api/v1/sboms/sbom//provenance # download stored JSON ``` All four require authentication, uploads need write access to the SBOM's component, downloads honour the SBOM's public/private visibility just like the SBOM body itself. Upload sizes are capped (5 MB for signatures, 10 MB for provenance) and the SBOM row is row-locked during the write so two concurrent uploads cannot both win. ### Uploading a signature ```bash curl -X POST "https://app.sbomify.com/api/v1/sboms/sbom/$SBOM_ID/signature" \ -H "Authorization: Bearer $SBOMIFY_TOKEN" \ -H "X-Signature-Type: cosign-bundle" \ -H "Content-Type: application/octet-stream" \ --data-binary @sbom.cdx.json.sig ``` A successful upload returns `201 Created` with the storage key sbomify assigned and queues the SBOM Verification plugin to validate the bytes asynchronously. ### Uploading provenance ```bash curl -X POST "https://app.sbomify.com/api/v1/sboms/sbom/$SBOM_ID/provenance" \ -H "Authorization: Bearer $SBOMIFY_TOKEN" \ -H "Content-Type: application/json" \ --data-binary @sbom.cdx.json.intoto.jsonl ``` The endpoint accepts the in-toto JSON or the DSSE envelope and returns `201 Created` once the subject digest passes. A `400 Bad Request` with `error_code: bad_request` and a message about the digest mismatch means the attestation does not name your SBOM, most often a sign that the SBOM was rebuilt after the attestation was issued. ## Where the badges show up Once attached, two badges render on the SBOM detail page (Components → component → click the SBOM filename): - **Signed** (green padlock), the SBOM has a stored `signature_blob_key`. - **Provenance** (blue shield), the SBOM has a stored `provenance_blob_key`. The badges are visible to authenticated users in the workspace. The same fields (`signature_blob_key`, `signature_type`, `provenance_blob_key`) are exposed in `SBOMResponseSchema` so external pipelines querying the API can tell at a glance whether either artefact is present. ## How the SBOM Verification plugin uses them The unified `sbom-verification` plugin runs as part of every SBOM assessment cycle and produces five granular findings: | Finding | What it checks | When it passes | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | `digest:integrity` | Re-computes the SBOM SHA-256 and compares it to the stored hash | The recomputed hash matches | | `signature:present` | Looks for a stored `signature_blob_key` | A signature has been uploaded | | `signature:valid` | Validates the stored signature using `sigstore.Verifier.production().verify_artifact` (cosign-bundle), the other formats currently report `unknown` while keeping the upload + presence check active | The signature verifies cleanly | | `provenance:present` | Looks for a stored `provenance_blob_key` | A provenance attestation has been uploaded | | `provenance:digest` | Re-checks the stored attestation's `subject[].digest.sha256` against the SBOM hash | At least one subject digest matches | The plugin also rolls all five up into an aggregated `verification:attestation` summary finding whose status is `pass` when _any_ cryptographic source verified and `fail` when none did, the BSI / FDA / NTIA plugins consume that summary via a `requires_one_of: [{"type": "category", "value": "attestation"}]` clause, so a digest-only "pass" cannot satisfy an attestation requirement on its own. The plugin runs even if neither artefact has been uploaded, the digest check still passes on its own, and the signature/provenance findings come back as `not present` rather than `fail`. Uploading either artefact while the SBOM is sitting in the assessment queue triggers a re-run. ## Auto-discovering GitHub Attestations If your SBOM declares a GitHub VCS URL (the [github-action](https://github.com/sbomify/sbomify-action) does this automatically when the metadata block carries a repository reference), the verification pipeline does not even need an explicit upload. The plugin queries GitHub's public Attestations API for the SBOM's SHA-256, fetches the Sigstore bundle, and runs `cosign verify-blob-attestation` against it on every assessment cycle. Use the explicit `POST /signature` / `POST /provenance` endpoints when: - Your CI does not run on GitHub. - You sign with PGP or PKCS#7 instead of Sigstore. - You want sbomify to retain the bundle even if the upstream GitHub repository is deleted. The two paths are not mutually exclusive, an explicitly uploaded artefact takes precedence over the GitHub-discovered one, so the API can be the primary channel and auto-discovery serves as a backup. ## Rotating a signature or provenance Both endpoints reject a second upload while the first is still attached (`409 Conflict`). The intent is to keep the audit trail clean: replacing in place would silently change the verification result for downstream consumers. To rotate: 1. **Re-build the SBOM.** Any change to the bytes produces a new SHA-256 and creates a fresh SBOM revision under the same component. 2. **Sign / attest the new revision** with the new key or build provenance. 3. **Upload the fresh signature / provenance to the new SBOM.** The previous SBOM and its artefacts stay on file as immutable history. If you genuinely need to drop an artefact in place (test environment, mistaken upload), do that against the SBOM record directly, the API does not expose a delete primitive on either endpoint by design. ## CRA Declaration of Conformity is a different kind of signature If you arrived here looking for the Place / Name / Function signature pad on Step 5 of the CRA Compliance Wizard, that is a separate feature, the _legal_ manufacturer signature required by [Article 28 + Annex V Section 8](/faq/how-do-i-use-cra-compliance/) of the EU Cyber Resilience Act, captured as a drawn PNG. It is conceptually distinct from the cryptographic signatures and provenance attestations described above, which prove what the SBOM bytes say. A complete filing typically carries both, the DoC says _who_ declares conformity, the cryptographic artefacts prove _which exact bytes_ the consumer received. ## Further reading - [How do I sign an SBOM?](/faq/how-do-i-sign-an-sbom/), producer-side workflow: GitHub Attestations end-to-end. - [What is Sigstore?](/2024/08/12/what-is-sigstore/), keyless signing primer. - [What is in-toto?](/2024/08/14/what-is-in-toto/), the attestation envelope format the provenance endpoint consumes. - [What is SLSA?](/2024/08/17/what-is-slsa/), provenance levels that build on signed attestations. - [GitHub Action with attestation](/2024/10/31/github-action-update-and-attestation/), full workflow walkthrough. - [PR sbomify/sbomify#880](https://github.com/sbomify/sbomify/pull/880), the implementation this article describes. --- # Customer Success Stories URL: https://sbomify.com/case-studies/ Description: Discover how leading organizations are using sbomify to streamline their SBOM management, enhance security, and meet compliance requirements. Working towards NTIA compliance Learn how Atsign, a platform for secure and private communication, improved their SBOM quality and visibility while working towards NTIA compliance using sbomify. Read Case Study Simplifying SBOM Management Learn how Screenly, a secure digital signage platform trusted by Fortune 500 companies, automated their SBOM generation and distribution using sbomify. Read Case Study Ready to start your story? Join these organizations in securing your software supply chain. Get Started Free Contact Sales --- # Atsign Case Study: Working towards NTIA compliance URL: https://sbomify.com/case-studies/atsign/ Description: Atsign provides a platform for secure and private communication, and its NoPorts product is used for zero-trust infrastructure access. This is how sbomify helped them improve the quality of their SBOMs. ## About Atsign Atsign’s atProtocol enables mutual verification between any two people, devices, or entities connected to the Internet. Once verified, they can securely and privately exchange data without exposing vulnerabilities. The open-source atPlatform empowers developers to create applications and solutions with security and privacy at their core. ## The Challenge Atsign have been producing SBOMs for some of their key products and components for some time. This has been part of their 'showing how we care about security' using SBOMs, Supply-chain Levels for Software Artifacts (SLSA) and OpenSSF Scorecards. Those SBOMs were created by running dependency lock files through Anchore Syft. Unfortunately, this did not help to describe Atsign's own software or carry any of the metadata needed for NTIA compliance (which describes 'The Minimum Elements For a Software Bill of Materials (SBOM)'). The SBOMs also weren't very visible, buried away as files in GitHub releases (which might sometimes be a completely different place from where the software itself would be found such as Docker Hub). ## Solution with sbomify Partnering with **sbomify** helped Atsign overcome these challenges: - **Augmentation and Enrichment**: Atsign filled out the relevant metadata in sbomify so that it could be added to lock file generated components by the sbomify GitHub Action. The Action is run as part of their CD pipelines so that SBOMs are created for each release. - **sbomify badge**: An sbomify badge in the README.md for each open source repo sits alongside the SLSA and Scorecard badges, making the SBOM a visible part of the trifecta. It also provides an easy link through to the most recent SBOMs for that component. For example the [at_server](https://github.com/atsign-foundation/at_server/) repo, which contains the core software implementation of the atProtocol. ## Our Broader Partnership Whilst working together on SBOM quality and visibility, opportunities have arisen to take on broader issues in the SBOM arena, such as the difficulty in generating SBOMs for C based projects.

"Working with Viktor and the team at sbomify has been a pleasure. Using sbomify has hugely accelerated our work on NTIA compliance. Viktor has also been leading a group that's creating standards for making SBOMs. This gives us confidence that sbomify will become a platform that follows industry practices as they emerge."

– Chris Swan

## The Results - **Complete, compliant SBOMs**: The SBOMs Atsign creates now carry the full set of metadata that a customer would expect to find. - **Enhanced Visibility**: SBOMs are no longer hidden away in releases, and have joined SLSA and Scorecard in showing that Atsign care about security. ## Conclusion By teaming up with sbomify, Atsign have improved the quality and visibility of SBOMs. Privacy and the security needed to guarantee it are at the heart of Atsign's platform, so being able to show customers how they care about security is vital in establishing trust. Especially when Atsign solutions like NoPorts become security-critical infrastructure for their customers. --- # Screenly Case Study: Simplifying SBOM Management with sbomify URL: https://sbomify.com/case-studies/screenly/ Description: Screenly is a secure digital signage platform and this is how sbomify helped secure their SBOM supply chain. ## About Screenly Screenly delivers secure digital signage solutions trusted by Fortune 500 companies and financial institutions. They focus on providing reliable and secure platforms that meet the needs of security-conscious organizations. ## The Challenge Over the past year, Screenly noticed a growing demand from customers for Software Bill of Materials (SBOMs). Clients wanted transparency into the components that make up Screenly's digital signage solutions. Committed to meeting these needs – and as part of their pledge in joining CISA's Secure by Design program – they set out to provide comprehensive SBOMs. However, they quickly encountered a significant hurdle: instead of managing a single SBOM, Screenly had dozens across their product line. Each component – be it backend services, frontend applications, or device firmware – had its own SBOM with its own release schedule. Grouping and managing these multiple SBOMs became a complex and time-consuming task. Their challenges included: - **Automated SBOM Generation**: They needed to automatically generate SBOMs within their CI/CD pipeline for all services and firmware components. - **Effective Distribution**: Sharing SBOMs with external stakeholders in a way that ensured they always had the latest versions was essential. - **Logical Grouping**: Creating a clear structure that represented their entire product suite, accommodating different release cadences, was challenging. - **Meeting Compliance Standards**: Existing tools often produced incomplete SBOMs that didn't meet NTIA's minimum elements, requiring extra steps to enrich them with vendor and licensing data. - **SBOM Attestation**: Screenly wanted to ensure the authenticity and integrity of their SBOMs by attesting them, adding another layer of security and trust. ## Solution with sbomify Partnering with **sbomify** helped Screenly overcome these challenges: - **Adoption of sbomify GitHub Action Module**: Screenly integrated the sbomify GitHub Action module into their CI/CD pipeline. This allowed for automated SBOM generation across all components directly within their existing workflow. - **Streamlined SBOM Management**: sbomify enabled them to group and manage their multiple SBOMs effectively. They created a logical hierarchy that mirrored how their products are built and maintained, simplifying management despite varying release schedules. ![Screenly's SBOM hierarchy in sbomify](/assets/images/d2/screenly-hierarchy.svg) _Partial diagram of Screenly's SBOM hierarchy in sbomify_ - **Automated Generation with GitHub Actions**: By leveraging the sbomify GitHub Action, every build automatically produced an up-to-date SBOM without manual effort. This seamless integration ensured consistency and saved valuable time. - **Efficient Distribution**: sbomify's distribution features allowed Screenly to share SBOMs with stakeholders easily. Stakeholders always had access to the latest versions, aligning with best practices highlighted in CISA's SBOM Sharing Primer. - **Compliance Made Easy**: sbomify helped them augment their SBOMs with necessary vendor and licensing information, ensuring compliance with NTIA's minimum elements without additional busywork. - **SBOM Attestation via GitHub Actions**: They used sbomify's integration with GitHub Actions to automatically attest all their SBOMs. This provided cryptographic proof of authenticity and integrity, enhancing trust with customers and stakeholders. ## The Results - **Enhanced Transparency**: Customers now have clear insights into the software components of Screenly's solutions, building greater trust. - **Improved Security**: Adhering to industry best practices and NTIA guidelines strengthened their security posture. - **Operational Efficiency**: Automation reduced manual efforts in SBOM management, allowing their team to focus on core development. - **Simplified Management**: Managing multiple SBOMs across different components and release schedules became straightforward. - **Verified Authenticity**: SBOM attestation via GitHub Actions ensured the integrity of their SBOMs, giving stakeholders added confidence. - **Better Collaboration**: Efficient distribution and clear structuring of SBOMs improved stakeholder collaboration. ## Conclusion By teaming up with sbomify, Screenly transformed how they handle SBOMs. They overcame the complexities of managing multiple SBOMs, automated their processes using the sbomify GitHub Action module, ensured compliance, and added a layer of security with SBOM attestation – all while enhancing transparency for their customers. Screenly is dedicated to providing secure and reliable digital signage solutions. With sbomify, they have taken a significant step forward in fulfilling that commitment, reinforcing their position as a trusted partner for security-conscious organizations. --- # The sbomify Blog URL: https://sbomify.com/blog/ Date: 0001-01-01 Description: Articles, guides, and product updates on SBOMs, software supply chain security, and compliance from the sbomify team. --- # The CRA Single Reporting Platform Opens Tomorrow: What ENISA Actually Requires URL: https://sbomify.com/2026/09/10/cra-single-reporting-platform-enisa-srp/ Date: 2026-09-10 Description: ENISA's CRA Single Reporting Platform goes live on 11 September 2026 with Article 14 reporting obligations. Registration, Assigned Representative roles, the 24/72-hour clocks, CSIRT selection, and the fields you will be typing. Tomorrow, the [Cyber Resilience Act](/compliance/eu-cra/)'s reporting obligations stop being a date on a slide. From **11 September 2026**, manufacturers of products with digital elements must notify actively exploited vulnerabilities and severe incidents, and the machinery for doing so - ENISA's **Single Reporting Platform (SRP)** - opens at [portal.cra-srp.enisa.europa.eu](https://portal.cra-srp.enisa.europa.eu). ENISA has been publishing steadily through the summer: a [factsheet](https://www.enisa.europa.eu/sites/default/files/2026-07/ENISA_CRA_SRP_Factsheet_v1.0_0.pdf), a [glossary of every reporting field](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2), step-by-step guidance for Assigned Representatives, and a [FAQ that was updated as recently as 9 September](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions). Between them they answer most of the operational questions, and several answers are not what teams assume. Here is what the official material says, and what it means if you are the person who will actually be filling in the form. ## What the SRP Is Article 16(1) of the [CRA](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) requires ENISA to establish a single reporting platform and run its day-to-day operations, so that manufacturers report once instead of notifying each Member State separately. Mechanically, that means: 1. You submit a notification and select the **CSIRT designated as coordinator** (CDaC). 2. The notification is **simultaneously made available to ENISA** - unless particularly exceptional circumstances apply, more on which below. 3. The receiving CDaC disseminates it without delay to the CSIRTs of other Member States where the product is available. 4. National CSIRTs share some of that information with their **market surveillance authorities**, who hold the enforcement powers. Note the direction of travel. You do not report _to ENISA_; ENISA runs the pipe. The authority that receives your notification and decides what happens to it is a national CSIRT, and the authority that can fine you sits downstream of that. **Only one notification is required per event**, even if you have multiple EU branches or subsidiaries and a parent company outside the EU. ENISA is explicit that coordinating internally so exactly one notification goes out is the manufacturer's problem, not the platform's. ## Who Reports, and Who Does Not Yet This is where the launch scope is narrower than the regulation. | Who | Legal basis | Status on 11 September 2026 | | ------------------------------- | ------------- | -------------------------------------------------------------------------------------- | | Manufacturers | Article 14 | **In scope now.** Mandatory reporting through the SRP | | Open-source software stewards | Article 24(3) | Not until **11 December 2027**, per Article 71(2) | | Anyone, voluntary notifications | Article 15 | **Not implemented at launch.** Coming in a later phase | | Non-manufacturers | - | Contact your national CSIRT directly; an SRP submission "might be marked as 'invalid'" | So if you are a steward of an open-source project, you have another fifteen months. If you are a researcher or a downstream user wanting to flag something, the SRP is not your channel yet. ## What Has To Be Reported Two categories, and both have definitions with teeth: - **Actively exploited vulnerabilities (AEV)** - a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Article 3(42)). - **Severe incidents (SI)** - an incident that negatively affects, or is capable of negatively affecting, a product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions (Article 3(44)), where the severity criteria in Article 14(5) are met. For interpretation of what "becoming aware" means in practice, ENISA points at Section 5 of the Commission's [FAQs on the CRA Implementation](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions) and Section 9.1 of its [July 2026 guidance](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation) rather than answering itself. ## The Clocks | Stage | Deadline | | ----------------------------------------------- | ----------------------------------------------------------------------- | | Early warning | Without undue delay, and within **24 hours** of becoming aware | | AEV / severe incident notification | Within **72 hours**, with general information and an initial assessment | | Final report - actively exploited vulnerability | No later than **14 days** after a corrective measure is available | | Final report - severe incident | Within **1 month** of the 72-hour notification | The clock starts when you become aware, not when you finish triaging. **One quirk worth knowing before it bites you.** ENISA documents that in the current release, the 72-hour counter in the platform displays a due date **48 hours after you submit the 24-hour early warning**, not 72 hours after you became aware. If you submit your early warning at hour 20, the platform will show your 72-hour notification as due at hour 68 and may flag it overdue before the legal deadline has passed. ENISA says this will be recalculated from the "date/time when you became aware" field in a future release. Two consequences. First, do not use the platform's counter as your compliance clock - track the real one internally. Second, the counters exist to drive reminder emails, and ENISA is careful to say they "do not replace the responsibility" to meet the Article 14 timelines. For final reports, there is currently **no counter at all for AEVs**, because the deadline depends on when your corrective measure ships - a date the platform cannot know in advance. Severe incidents get a counter set one month after the 72-hour notification. ## Registration: EU Login, and the AR Model You cannot register a company. You register **people**. Assigned Representatives (ARs) sign in with an **EU Login account with multi-factor authentication enabled**. Accounts can be created in advance at [ecas.ec.europa.eu](https://ecas.ec.europa.eu/cas/login). ENISA states there is no additional corporate entity authentication mechanism, and that EU Login accounts are personal - so the people who will submit notifications need their own, not a shared mailbox login. There are two roles: | Role | How you get it | Can do | Can see | | ---------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------ | | **Primary AR** | Registers directly, selects the CDaC, creates the manufacturer association | Submit and update notifications, manage the association, invite and remove Secondary ARs | All notifications for the manufacturer | | **Secondary AR** | Invited by the Primary AR, confirms pre-filled manufacturer information | Submit and update notifications | Only the notifications they submitted themselves | **One Primary AR per manufacturer, up to 20 Secondary ARs.** The Primary must have a _verified_ AR-manufacturer association before it can invite anyone. A Secondary AR may claim the Primary role, but that goes to the designated CSIRT for review and approval. Current role and association status live under **Settings > Association Management**. The association itself is validated by the designated CSIRT, and ENISA is upfront that the procedure and processing time **vary between CSIRTs**. Two mitigations are built in: - Verification happens **in parallel** with reporting - a pending association does not block submission. - An AR whose association is not yet verified may submit **up to 20 notifications** before verification becomes mandatory. ENISA's own advice cuts against the instinct to get registered early: to limit CSIRT validation workload, manufacturers are advised to "register and initiate the validation process only when they need to submit a notification." Registration takes a few minutes if the EU Login account already exists. That is a defensible reading of the platform's design, and we would still argue for splitting the difference: **create the EU Login accounts now, decide who your Primary and Secondary ARs are now, and leave the SRP registration itself until you need it.** The EU Login step is the one with an unknown-length tail (personal accounts, MFA enrolment, people on leave), and it is the one ENISA explicitly says you can do in advance. ## Picking the Right CSIRT Is Your Job The platform does not route for you, and getting it wrong has a cost. ENISA: "If the wrong CDaC is selected, the notification may be invalidated and will need to be resubmitted to the correct CDaC." Inside a 24-hour window, a resubmission is not a formality. Article 14(7) gives a cascade. Work down it in order: | Order | Test | | ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | The Member State of your **main establishment** - where decisions about the cybersecurity of your products with digital elements are predominantly taken | | 2 | If that cannot be determined: the Member State where your EU establishment has the **highest number of employees** | | 3 | No EU establishment: where your **authorised representative** acts for the highest number of your products | | 4 | Failing that: where the **importer** places the highest number of your products on the market | | 5 | Failing that: where the **distributor** makes the highest number of your products available | | 6 | Failing all of the above: the Member State with the **highest number of users** of your products | Note that step 1 is not "where you are headquartered" and not "where engineering sits." It is where cybersecurity decisions are predominantly taken. For a distributed company that is a determination worth making in writing, once, in advance - and recording, because you will need to justify it if it is ever questioned. ENISA publishes the [list of CSIRTs designated as coordinators](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators) so you can map the answer to an actual entry in the dropdown. ## What You Will Be Typing ENISA's [SRP Glossary](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2) documents 43 fields with their meaning, format, and the stage at which each applies. Fields are marked required, optional, mandatory if the information is available, or carried forward from a previous stage. The early warning is deliberately thin. Here is what is **required at the 24-hour mark**: | Field | Notes | | -------------------------------------------- | ------------------------------------------ | | Notification type (vulnerability/incident) | Determines which subsequent fields you see | | Notification level (24h/72h/final) | - | | Title and summary | - | | Manufacturer name | - | | **Product name** | - | | **Product version** | - | | Member States where the product is available | Required if the information is available | | Date/time you became aware | AEV and SI both | | Unlawful or malicious acts suspected | Severe incidents only | Read that list again with an engineering eye. At the 24-hour mark, the regulator is not asking for your root cause analysis. It is asking **which product, which version, and which Member States**. Those are inventory questions, and they are the ones that go badly when the answer lives in three spreadsheets and a release engineer's memory. The 72-hour notification adds general information about the vulnerability or the nature of the incident, an initial assessment, considered sensitivity of the information, and - now required - **corrective or mitigating measures taken, and measures users can take**. The final report is where the detailed severity and impact descriptions, the malicious actor where known, and the date the corrective measure became available all land. Fields that stay optional throughout are worth noting too, because they are where SBOM data would go if you have it: **component name**, CVE ID, EUVD ID, and attack vector. Optional to ENISA. Extremely useful to the CSIRT reading it at 3am, and to you when the same component turns up in the next notification. ## Two Things That Are Not There **No API.** ENISA states plainly that no Application Programming Interface will be provided at the initial release, and that notifications must be submitted through the platform interface. Organisations "may automate their internal reporting workflows and integrate CRA reporting requirements into their own systems and databases" - everything up to submission. API functionality "may be considered in a future phase." The practical effect: your integration work does not shorten the critical path. Your **data quality** does. A human will be reading a field off a screen and typing it into a browser, and the only question that matters is whether that screen already says "these four product versions ship the affected component." **English only.** At launch the platform is available in English only. ENISA will progressively translate the factsheet and supporting materials into all EU languages, and will review platform translation in a later phase. If your incident response runbook assumes a local-language filing, it does not. ## Particularly Exceptional Circumstances Article 16(2) lets the receiving CSIRT delay or withhold dissemination of a notification to other Member States, including at the manufacturer's request. [Commission Delegated Regulation (EU) 2026/881](https://eur-lex.europa.eu/eli/reg_del/2026/881/oj/eng) of 11 December 2025 specifies the terms and conditions. Operationally, ENISA says you should assess **during the 72-hour window** whether PEC applies, and it can only be invoked where at least one of the Article 16(2) conditions is met. When you actively mark PEC in the 72-hour notification, **ENISA receives only partial information** until the receiving CSIRT releases the full notification. That is a genuine decision point with a deadline attached, and it is not one you want to be reading about for the first time at hour 70. Decide in advance who in your organisation is allowed to invoke it and on what basis. ## If the Platform Is Down ENISA's answer is unambiguous and worth internalising: **wait, then submit**. If the SRP is temporarily unavailable, you submit the notification once it is back. If you judge that immediate communication is necessary in the meantime, you may contact your designated CSIRT directly - but the notification must **still** be submitted through the SRP once it is available again. A phone call does not discharge the obligation. ## Your Existing Backlog Three clarifications from ENISA's FAQ, all of which route to the Commission's implementation FAQ for the legal detail: - **Products placed on the market before the CRA.** The Article 14 obligations apply from 11 September 2026 to all products with digital elements within CRA scope, including products placed on the market before 11 December 2027 (Commission FAQ subsection 5.3). - **No retroactive reporting.** You are not required to report an actively exploited vulnerability where you were **already aware of the active exploitation** before 11 September 2026. But if you become aware of the exploitation after that date, the obligation applies - including where the underlying vulnerability was already known to you (subsections 5.1 and 5.3). - **Third-party components.** Where an actively exploited vulnerability in your product originates from a third-party component, ENISA refers you to Section 5.4 of the Commission's FAQ. The July 2026 Commission guidance elaborates: if the vulnerable code cannot be exploited in your product, or has not been exploited in it, it is not an actively exploited vulnerability contained in your product - and mandatory reporting does not bite. That last one is a reachability determination with a legal consequence attached, and it is the shape of a [VEX](/faq/how-do-i-use-vex/) statement. Making it credibly in 24 hours means having both an SBOM you trust and an analysis you can defend afterwards. ## What This Means for SBOM Practice Nothing in the SRP mentions SBOMs. The CRA's SBOM obligation lives in Annex I Part II and does not bind until 11 December 2027. So why does a reporting platform matter to an SBOM programme? Because the reporting obligation lands **fifteen months before** the documentation obligation, and it asks the harder question first. Annex I asks _do you have an SBOM_. Article 14 asks _which of your products and versions contain this component, and can you say so within 24 hours_. The second question is answerable only if you have been treating SBOMs as a queryable archive of every shipped version rather than a file generated at release time and forgotten. From tomorrow, the gap between those two postures has a deadline and a fine attached - up to EUR 15,000,000 or 2.5% of worldwide annual turnover under Article 64(2) for breaches of the Article 14 obligations. Three things follow: 1. **Version-level SBOM coverage of what is in the field**, not just what is on `main`. The 24-hour field is "product version," singular, and you may need several rows. 2. **Continuous matching against vulnerability intelligence**, so "is this being exploited in something we ship?" is a query rather than a project. 3. **A reachability answer per affected product**, because the Commission has made "is the vulnerable code reachable" the difference between a mandatory notification and a voluntary one. ## Before Tomorrow 1. **Create EU Login accounts with MFA** for everyone who might submit. This is the step with the unpredictable tail, and the one ENISA says you can do in advance. 2. **Name your Primary AR and your Secondary ARs.** One Primary, up to 20 Secondaries. Decide the succession now, not while the Primary is on a plane. 3. **Determine and write down your CSIRT designated as coordinator** using the Article 14(7) cascade. Wrong choice, invalidated notification. 4. **Track your own 24/72-hour clocks internally.** The platform's 72-hour counter currently runs from your early-warning submission, not from awareness. 5. **Decide who can invoke PEC**, and on what grounds, before you need to. 6. **Make sure "which versions ship component X" is a query.** Everything else on this list is paperwork you can do in an afternoon. This one is not. ## How sbomify Helps sbomify generates SBOMs automatically in CI/CD with the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action) and keeps one per product version in a queryable archive, which is the shape the 24-hour field wants. Components are continuously matched against vulnerability data, so the "which of our releases contain this?" step is a lookup rather than an investigation, and [VEX statements](/faq/how-do-i-use-vex/) let you record the reachability determination that decides whether a notification is mandatory at all. Our [CRA Compliance Wizard](/faq/how-do-i-use-cra-compliance/) tracks ENISA SRP registration status alongside your CSIRT contact and vulnerability-handling setup, and grades each uploaded SBOM against [BSI TR-03183-2](/compliance/bsi-tr-03183/) so the December 2027 obligation is not a second scramble. On the intake side, every [Trust Center](/faq/what-is-a-trust-center/) can publish an RFC 9116 `security.txt`, because a 24-hour clock that starts late because a researcher could not find your contact address is still a 24-hour clock. ## Official Sources - [ENISA: CRA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp) - [ENISA: CRA SRP Frequently Asked Questions](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions) (updated 9 September 2026) - [ENISA: CRA Single Reporting Platform Factsheet v1.0](https://www.enisa.europa.eu/sites/default/files/2026-07/ENISA_CRA_SRP_Factsheet_v1.0_0.pdf) (PDF) - [ENISA: CRA SRP Glossary](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2) - [ENISA: List of CSIRTs designated as coordinators](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators) - [CRA SRP portal](https://portal.cra-srp.enisa.europa.eu) - live from 11 September 2026 - [Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [Commission Delegated Regulation (EU) 2026/881](https://eur-lex.europa.eu/eli/reg_del/2026/881/oj/eng) - delaying dissemination of notifications - [European Commission: CRA reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) - [European Commission: FAQs on the CRA Implementation](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions) - [European Commission: CRA implementation guidance, C(2026) 5252 (27 July 2026)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation) ENISA runs a helpdesk for questions not covered by the published material, reachable at `cra-srp-helpdesk[@]enisa.europa.eu`. Further reading: our [EU CRA compliance guide](/compliance/eu-cra/), the [BSI TR-03183 four-part update](/2026/08/20/bsi-tr-03183-four-parts-cra-update/), and [what the CRA means for device manufacturers](/2026/01/06/cra-explained-cyber-resilience-act-for-device-manufacturers/). --- # Announcing sbomify-action v26.8.0: The One That Went on a Diet URL: https://sbomify.com/2026/08/25/announcing-sbomify-action-v26-8-0-the-one-that-went-on-a-diet/ Date: 2026-08-25 Description: sbomify-action v26.8.0 cuts the container image from 515MB to 106MB by fetching verified, attested tool bundles on demand, ends silent SBOM quality downgrades, adds git submodule support, and introduces Clearly Cached, a caching proxy that makes ClearlyDefined license data actually usable from CI. The headline number in this release is that the container image went from **515MB to 106MB**. That is the fun part. The part that should actually change your confidence in your SBOMs is what we found while getting there: for several ecosystems, sbomify-action was quietly producing a worse SBOM than it should have, and nothing told you. --- ## 515MB to 106MB, Without Dropping Anything The old image shipped every tool it might ever need, for every language it supports, whether your project used them or not. If you build a Python service, you were still pulling a JDK on every cold CI run. The new image ships one Python runtime, sbomify-action itself, and `cyclonedx-py`. Everything else is fetched at the moment it is needed, as per-ecosystem bundles from [sbomify/sbom-tools](https://github.com/sbomify/sbom-tools), pinned by digest, verified and attested before use, and unpacked into an unprivileged prefix. Every `apt-get` call is gone, so nothing in the image needs root. **No ecosystem was dropped to get there.** An earlier attempt removed cdxgen and the JVM to hit the number, and we reverted it, because a smaller image that generates worse SBOMs is not an improvement. What this buys you beyond faster pulls: the tools are now verified supply-chain artifacts rather than layers baked in months ago, and they can be updated without waiting for a new action release. If you build in an air-gapped environment, `SBOMIFY_FETCH_RUNTIMES=0` opts out. --- ## The Part That Matters: No More Silent Downgrades Fetching tools used to be opt-in outside our own image. The reasoning was that fetching a tool changes which generator wins, and therefore changes the user's SBOM, so we should not do it without permission. That reasoning is backwards. Declining to fetch does not leave you without an opinion. It silently hands you the fallback, which is the worse answer. A Rust project resolved by a generic file scanner instead of `cargo-cyclonedx` is not a neutral outcome, and nothing was telling you it had happened. Two examples from this release, both real: - **Rust was broken for every user.** The CycloneDX Cargo integration was failing outright on a spec-version argument, and nobody noticed, because the fallback scanner quietly produced a worse SBOM in its place. - **Go looked fine and was not.** A `go.sum` returned 154 components through the fallback, which _looks_ like a working result. Routed to the right generator, it returns 158 components with real module metadata. A plausible wrong answer is far more dangerous than an empty one, because nobody investigates it. Inside the image, the chain is now strict: a generator that claims your project and then fails aborts the run instead of falling through to something worse. Two generators were also caught claiming inputs they cannot actually handle, which on a developer laptop looked harmless and in production cost you the SBOM entirely. Related, and in the same spirit: a container image no longer has every file in it described as a component; a Swift package with missing information now tells you what is missing instead of writing an empty SBOM; and a spec version that nothing in the toolchain can generate is rejected at config time rather than after your build has run. --- ## Every Lock File We Support, Fully Supported Twenty-eight lock file and manifest names. Twenty-five real-world repositories. Both CycloneDX and SPDX. Every combination now runs on every commit. That breadth turned into depth. Point sbomify-action at the same project today and it sees a great deal more of it: | Input | Components before | Components now | | ----------------------- | ----------------: | -------------: | | `composer.json` (SPDX) | 1 | 100 | | `pyproject.toml` (SPDX) | 1 | 70 | | `gradle.lockfile` | none | 68 | | `package.json` (SPDX) | 1 | 10 | | `Package.swift` | none | 4 | PHP is the clearest example. A `composer.json` now describes the whole project, all hundred components of it. Gradle lock files generate directly, without running your build. Swift packages resolve properly. And a manifest that lists version ranges reads the lock file sitting next to it, so you get the versions you actually shipped. Discovery got broader in the same pass. Rust crates that carry only a `Cargo.toml`, .NET project files rather than the lock file almost nobody commits, PHP through a proper Composer bundle, and first-class recognition for Haskell, Erlang, and Clojure. If that is your stack, point the action at it and it will find your dependencies. --- ## Git Submodules, Handled Properly If your repository pulls in code through git submodules, that code is part of what you ship, and it was previously invisible. Discovery now detects lock files that live in another repository, whether through `.gitmodules` or a vendored clone, and annotates them clearly. They are left **deselected by default**, with an explanation, because a submodule is better tracked from the repository that owns it. When you do enable one, the action resolves the submodule's pinned commit to a real version, then either attaches the SBOM that already exists for that version or generates and uploads one so it is there next time. So the same dependency, pinned by five different products, produces one SBOM rather than five near-identical ones. One decision worth stating explicitly: submodule SBOMs are **never attested** from the parent repository's workflow. An attestation from your pipeline would carry your Sigstore identity for code your organisation does not own, which is a claim we are not willing to emit on your behalf. The generated workflow marks those rows as deliberately unsigned. --- ## Better Enrichment, Fewer Rate Limits Enrichment is how a bare dependency list becomes an SBOM with suppliers, licenses, and metadata that a downstream consumer can act on. It is also where the action talks to a dozen upstream services, and where rate limiting quietly costs you data. Every enrichment lookup, across all twelve sources, is now cached across runs rather than being thrown away when the process exits. That directly improves SBOM completeness, because the throttled lookups that used to come back empty now come back from cache. The subtle half is what is _not_ cached. A transient failure, a timeout, or a 429 is never persisted, because a single throttled run would otherwise suppress that package's enrichment for the entire cache lifetime, which is exactly the data loss the cache exists to prevent. Negative results expire in a day rather than a month, so a newly published package is picked up instead of remembered as absent. And any cache failure degrades to no cache: a corrupt cache costs you network calls, not your run. Elsewhere in the same vein: the operating system lifecycle data has been re-sourced directly from vendors, with staleness detection so we notice when it drifts rather than serving you dates that quietly went out of date. --- ## Introducing Clearly Cached [ClearlyDefined](https://clearlydefined.io/) is one of the most useful datasets in the open source supply chain: curated license and attribution data for millions of packages, built by the community and free to everyone. It is also a free public API carrying the whole ecosystem, and querying it package by package from CI asks a great deal of it. A coordinate that has not been looked at recently can take the better part of a minute to come back. And by design the API never returns a 404, so a package that simply has not been harvested yet returns an empty definition, which from the client side is indistinguishable from a package with no license. That last point is the one that mattered for your SBOMs. A slow response and an unharvested package both ended up recorded as "no license", sitting alongside real answers with nothing to tell them apart. So we built [**clearly-cached**](https://github.com/sbomify/clearly-cached), a fast, selective caching proxy that sits in front of ClearlyDefined. We run it publicly at `clearly-cached.sbomify.com`, and sbomify-action now goes through it by default. The goal is not to route around ClearlyDefined but to be a better-behaved client of it: ask for less, ask once, and share the answer with everyone else running the action. Measured across 76 real packages spanning all seven supported ecosystems: | | Licenses resolved | Wall clock | | ------------------------ | ----------------: | --------------------- | | Direct to ClearlyDefined | 31 of 76 | 474s | | Through clearly-cached | **76 of 76** | **5s** warm, 92s cold | Forty-five of those packages exceeded our ten-second client timeout when queried directly, cold. All of them now resolve. Three things make the difference. The proxy returns a flat 0.4KB projection of the handful of fields enrichment actually uses, instead of a definition that can run to 190KB. It answers from cache, so the second project to ask about a popular package pays nothing for the answer. And it reports **unharvested** as its own state, distinct from unlicensed, so "ClearlyDefined has not looked at this yet" can never be recorded in your SBOM as "this package has no license". A circuit breaker backs that up: after five consecutive failures the source steps aside for the rest of the run, which saves your CI minutes and stops us adding load to a service that is already busy. It is open source, and `SBOMIFY_CLEARLY_CACHED_URL` points the action at your own instance or a local container if you would rather not depend on ours. Burning it in surfaced two defects that had been quietly costing people data against the old API as well. **Go packages had never enriched at all.** The namespace was interpolated into the URL raw, so `pkg:golang/github.com/gorilla/mux` split across extra path segments and 404'd every single time, silently. Go went from 0 of 6 packages enriched to 6 of 6. And a malformed response could take the parser down mid-SBOM; every field is now type-checked. We also stopped deriving the **supplier** field from ClearlyDefined's copyright parties. That was our misreading rather than bad data: copyright parties are exactly what they say they are, and a copyright holder found somewhere inside a package is simply not the same thing as that package's supplier. Across 68 live packages it showed: numpy's supplier came back as the author of meson, SQLAlchemy's as the author of clipboard.js, certifi's as a certificate authority bundled inside it. Confidently wrong provenance is worse than an empty field, so supplier is now left to the sources that model it directly. --- ## Smaller Things That Remove Friction - **The wizard survives real workspaces.** Hitting a plan limit now offers a route forward instead of a raw `403` and a retry button that fails identically. Tokens scoped to a non-default workspace bind to the right one. A retry after a partial run no longer dies on something it already created. There is a Reload on the components screen, and the action row stays on screen at every terminal size. - **Your component version comes from the release tag.** If your workflow runs on a tag, that is the version, and the action offers to normalise it rather than making you wire it up yourself. - **Prereleases are marked as prereleases** when publishing to sbomify, so a release candidate does not sit in your Trust Center looking like a shipped version. - **Environment variable handling is fixed outside Docker.** If you run the CLI directly rather than as a container action, three resolution defects that only surfaced there are gone. --- ## Getting Started Run it straight from PyPI, with no install step at all: ```bash pipx run sbomify-action # or uvx sbomify-action ``` Or use the GitHub Action: ```yaml - uses: sbomify/sbomify-action@v26.8.0 ``` Or run the wizard against your repository and let it write the workflow for you: ```bash docker run --rm -it \ -v "$(pwd):/github/workspace" \ -w /github/workspace \ -e SBOMIFY_TOKEN=$SBOMIFY_TOKEN \ ghcr.io/sbomify/sbomify-action \ sbomify-action wizard ``` If you are already on an earlier version, the upgrade is worth doing for the quality fixes alone. Regenerate an SBOM for a Rust, Go, PHP, or Swift project and compare the component count against your last one. If the number jumps, that gap is what was missing from your SBOM before. The platform side shipped the same day: [sbomify v26.8.0](/2026/08/25/announcing-sbomify-v26-8-0-the-one-with-security-advisories/) adds security advisory publishing and the measurable half of CRA compliance. For the full technical detail, see the [v26.8.0 release notes on GitHub](https://github.com/sbomify/sbomify-action/releases/tag/v26.8.0). As always, if the action is doing something surprising with your project, we want to hear about it. Several of the fixes above started as somebody's confusing SBOM. --- # Announcing sbomify v26.8.0: The One With Security Advisories URL: https://sbomify.com/2026/08/25/announcing-sbomify-v26-8-0-the-one-with-security-advisories/ Date: 2026-08-25 Description: sbomify v26.8.0 adds full security advisory publishing with per-product gating, a rebuilt Trust Center, patch SLA targets and CRA KPIs, formal risk acceptance, malicious package detection, CSV evidence exports, and a new brand. Most vulnerability tooling stops at the moment of discovery. You get a finding, a severity, maybe a fix version, and then you are on your own for the part that actually matters to your customers: telling them what happened, which of your products it affects, and what they should do about it. v26.8.0 is about that second half. It is also, not coincidentally, the half the [EU Cyber Resilience Act](/compliance/eu-cra/) starts asking about on **11 September 2026**, when Article 14's reporting obligations come into force. That is three weeks after this post goes out. --- ## Security Advisories, Written and Published From One Place The new Security Advisories module lets you author a proper vendor advisory inside sbomify: a summary, a severity with its CVSS vector, the affected and fixed version ranges, the products it touches, and a timeline of what you knew and when. The timeline is the part I would encourage you to look at first. Each entry carries an absolute timestamp, its age, and the gap since the previous update, rendered as "2 weeks later". That gap is the number your customers actually judge you on. A vendor who posted five updates over ten days handled an incident. A vendor whose timeline jumps from "under investigation" to "fixed" four months later did not, and no amount of prose disguises it. Making that visible in your own tooling is a mild form of accountability, and it is deliberate. When the advisory is ready, it publishes to your Trust Center. That is where it gets interesting. ### Gated Advisories That Are Actually Gated Advisories have three visibility states, and the middle one is the one nobody else gets right. - **Private** never leaves your workspace, whatever its publication status. - **Public** is readable by anyone once it is out of draft. - **Gated** requires two things at once: a workspace-level grant, meaning the reader is a member or has an approved access request with an NDA signed, **and** a link to at least one product that reader can already reach. That second condition is what makes gating per-advisory rather than per-workspace. A customer under NDA for your gateway product does not automatically get to read an embargoed advisory about a product they were never shown. And when an advisory touches several products, it only names the ones the reader is entitled to know about; the rest are counted, not named. There is a smaller detail that matters more than it looks: a gated advisory a reader may not see returns a **404, not a 403**. A 403 confirms the advisory exists, and for something under embargo, the fact that it exists is exactly what you are protecting. Gated pages are also `noindex, nofollow`, because a crawler is nobody's NDA holder. --- ## The Trust Center, Rebuilt Around It The Trust Center got a full redesign to carry all of this. The advisory index is modelled on how vendor advisory pages are actually read: a filter sidebar beside a dense table, where each advisory occupies a block whose severity, summary, and date span its per-product version rows. Version ranges render as the comparisons that answer the only question a reader has, "am I on an affected version": `>= 11.2.0, < 11.2.4-h20` against `>= 11.2.4-h20`. A product that is not affected simply reads `None` and `All`. Filtering happens live, facet counts exclude their own filter so ticking a second severity widens the result rather than dead-ending it, and underneath it all is a plain form that works without JavaScript. Everything picks up your workspace branding, with one deliberate exception. The severity scale is **not** brand-driven, because critical must never render green on a green-branded workspace, and the CVSS number is always printed next to its colour so severity never depends on colour alone. Alongside the advisories, the Trust Center now carries persistent navigation on every public page, so a customer arriving from a search result or a link in an email has a route to the rest of your disclosures instead of a dead end. --- ## The CRA Questions Auditors Actually Ask We have been building CRA support since [v26.1.0](/2026/04/02/announcing-sbomify-v26-1-0-the-one-where-we-switch-to-calver/), and [v26.2.0](/2026/05/13/announcing-sbomify-v26-2-0-the-one-that-signs-the-doc/) closed the Declaration of Conformity loop. This release is about the parts that have to be measurable rather than merely documented. - **Patch SLA targets, and the five CRA KPIs.** You can now set how fast a vulnerability of each severity has to be fixed, defaulting to a defensible Critical 7 / High 30 / Medium 90 days so a workspace that never opens the setting still has a published policy. Once there is a target, the five KPIs become computable: mean time to triage, mean time to remediate, open criticals with their KEV split, patch SLA compliance, and VEX publication latency. Two judgement calls are worth knowing about. An open finding already past its SLA counts as a breach **now**, not when someone eventually closes it, because otherwise a workspace could hold a breach open forever and keep a perfect record. And a best-effort severity sits outside the percentage rather than counting as always met, because treating an unbounded target as satisfied flatters the number exactly where your policy is weakest. - **Your EU Authorized Representative, on the DoC.** If you are placing a product on the EU market without an EU establishment, Article 22 makes an Authorized Representative mandatory, and Annex V expects their details on the accompanying documentation. The CRA wizard now captures the establishment determination and, where required, the representative's details and mandate, and the Declaration of Conformity renders them with the Article 25 statement. If a representative is required but missing, the document says so loudly rather than quietly omitting a mandatory section. - **Evidence that survives the ten-year requirement.** Article 13(15) requires the compliance record kept for ten years after market placement, or the support period if that is longer. Export packages now pin that retention floor at creation, so a later change to the product cannot silently shorten the record you already exported. - **End of life, handled as an obligation rather than a date field.** Products have carried end-of-support and end-of-life dates for a while, and nothing happened when they approached. Now you get a readiness check that surfaces every critical and high finding neither patched nor formally risk-accepted, a drafted EOL announcement that goes out through the same advisory channel your customers already watch, and the final release's SBOM and VEX pinned to a real versioned release rather than to a floating `latest` pointer that would keep moving after support ended. The announcement is deliberately left as a draft: an EOL notice is an irreversible public statement, so the system surfaces the obligation and a human publishes it. - **A `security.txt` in the shape BSI TR-03183-3 wants.** Separate CSIRT contact and report-page slots in the correct order, an optional CSAF pointer, and an `Expires` field clamped to at most a year out. It shares one dataset with the CRA wizard, so answering the question in either place fills the other. --- ## Findings That Tell You the Truth A vulnerability dashboard is only useful if you trust it. Several changes in this release exist because parts of it were quietly lying. **Malicious packages are now their own class.** A compromised package is a completely different decision from a vulnerable one: you remove it today, you do not schedule a patch for next sprint. Both arrived through the same scanner and rendered identically, and worse, most malicious-package advisories carry no severity at all, so they fell through to a default of _medium_. A supply chain compromise reading as a considered middling judgement is worse than reading as unknown. They are now detected structurally and surfaced as their own category, applied at read time so every scan you have ever run reclassifies with no rescan. **"Nothing scanned" no longer looks like "nothing found."** An empty result with a green tick is the single most dangerous thing a security tool can show you. A scan that recognised nothing, a scanner that errored out, and a spec version the scanner cannot read are now three distinct states, and none of them renders as a clean bill of health. **Risk acceptance is a real state, with an owner and an expiry.** Previously the only way to say "we know, we are living with this" was to leave a finding marked exploitable forever, which reads as untriaged backlog. The new `risk_accepted` state requires all three of a business justification, a named risk owner, and an expiry date, because an acceptance without an expiry is indistinguishable from neglect. When the date passes, the acceptance resurfaces as drift rather than quietly holding. Notably, this is **not** a VEX suppression. CycloneDX has no "accepted" analysis state, and writing `not_affected` would publish a false claim to everyone downstream: an accepted risk genuinely is exploitable, you are choosing to live with it. So the published document says exactly that, `exploitable` with a `will_not_fix` response, and the finding stays visible and counted in your own numbers. Rounding out the triage work: EPSS scores and CVSS 4.0 are captured from both scanner paths, ENISA's EUVD exploited flag now sits alongside CISA KEV, advisory IDs link to the database that holds them, VEX justifications render in human wording instead of spec enum names, and a vulnerability lifecycle model gives you finding age and MTTR. --- ## Evidence You Can Hand Over Auditors and procurement teams ask for tables. Until now the answer was "script something against the API." There are now four CSV exports covering inventory, licenses, findings, and vulnerabilities, scoped to a workspace, product, release, or component. Two things about them are worth calling out. The counting matches what you see on screen, because the exports read the same latest-per-component data and apply live VEX suppressions, so the export can never disagree with the dashboard beside it. And an artifact that cannot be read surfaces as an explicit row rather than silently shrinking the parts list, because for an auditor a quietly incomplete export is far worse than an error. Alongside those: - **License risk categories** for SPDX identifiers, so a legal review can start from the licenses that need attention rather than from an alphabetical list of everything. - **An OpenChain Telco SBOM Guide v1.1 conformance plugin**, checking the clauses the Guide actually mandates. If you supply into telco, this is the profile your customers will ask about. - **SBOM freshness windows.** Components can now carry a freshness expectation, and an SBOM that has aged past it is flagged as stale. An SBOM from eighteen months ago is not evidence of anything. --- ## A New Look, and Less Clicking This release also carries sbomify's new visual identity: a new logo and emblem, a palette built around the brand navy, Figtree throughout, and animated loaders that replace every ad-hoc spinner in the app. It runs all the way through to the login pages and transactional emails. Underneath the paint, the app moved onto a single component library, which is why so much of the interface shifted at once. Settings is now one page per section with tabs across the top rather than one long scroll. Create flows are proper pages. There is one Danger Zone instead of several. Two things that will save you real time: - **The navbar search is now a navigation spotlight.** Hit it and jump to any product, component, or page, instead of hunting through the sidebar. - **The CI/CD integration dialog is one command.** Copy, paste, run. Click to include a token and it mints one scoped to publishing only, with a **7-day TTL** and a name that tells you where it came from, so you are not pasting a long-lived credential into a terminal to get started. The token is minted on click rather than on open, because reading the command is not a decision to create a credential. Workspace roles were also reworked. Admins are now near-owners, able to do everything an owner can except remove an owner or delete the workspace, rather than being defined by an arbitrary list of things they could not reach. Guest became a purely external Trust Center role, and a new **member** role covers day-to-day work. If you have been granting admin because guest was too little, that gap is now filled. --- ## Getting Started If you are on the **hosted platform**, all of this is already live. The most useful ten minutes you can spend: open Settings and set your patch SLA targets, then look at the five KPIs against them. That number is the one a CRA auditor will eventually ask for, and it is better to see it now. If you have vulnerabilities you are knowingly living with, move them to the new risk-accepted state with a real owner and expiry. It will make your open-critical count honest, and the expiry means the decision comes back for review instead of ageing into permanence. For **self-hosted** deployments, pull `ghcr.io/sbomify/sbomify:v26.8.0` and update. There are additive migrations in this release; take a snapshot first as usual. The [sbomify-action v26.8.0](/2026/08/25/announcing-sbomify-action-v26-8-0-the-one-that-went-on-a-diet/) release went out at the same time, and if you generate SBOMs in CI it is worth reading, because it fixes some quiet quality problems in the SBOMs themselves. For the full technical detail, see the [v26.8.0 release notes on GitHub](https://github.com/sbomify/sbomify/releases/tag/v26.8.0). As always, I would like to hear how this lands, particularly the advisory work. Publishing advisories is a workflow most vendors have built once, badly, in a CMS, and we would rather build the version you actually want. If something is missing for how your team discloses, open a support ticket from inside [the app](https://app.sbomify.com) and it will reach us. --- # BSI TR-03183 Is Now Four Documents, and the CRA Clock Runs Out in Three Weeks URL: https://sbomify.com/2026/08/20/bsi-tr-03183-four-parts-cra-update/ Date: 2026-08-20 Description: BSI published TR-03183-1 in version 1.0.0 on 31 July 2026, completing a four-part CRA guideline family. Here is what changed across TR-03183, the Commission's July 2026 guidance, and the ENISA Single Reporting Platform before 11 September. If you built your [EU Cyber Resilience Act](/compliance/eu-cra/) plan around a single BSI document, it is out of date. Not because the SBOM requirements changed, but because BSI kept publishing. For most of 2024 and 2025, "BSI TR-03183" was shorthand for Part 2, the SBOM specification. It was the only part anyone needed, and it was the most concrete public answer to the question the CRA leaves open: what does a compliant SBOM actually look like? Since then, BSI has filled in the rest of the picture. TR-03183 is now four documents covering the manufacturer's obligations end to end, and the newest of them landed three weeks ago. That matters right now because **11 September 2026 is 22 days away**, and that is when CRA reporting obligations start biting. ## What BSI Published Here is the current state of the family: | Part | Version | Date | Scope | | --------------------------------------------------- | ------- | -------------- | ---------------------------------------------------------------------------------------- | | Part 1 - General requirements | 1.0.0 | 31 July 2026 | Risk-based control selection, with a machine-readable OSCAL control catalogue | | Part 2 - Software Bill of Materials (SBOM) | 2.1.0 | 20 August 2025 | SBOM format, content, data fields, dependency depth, licences | | Part 3 - Vulnerability Reports and Notifications | 1.0.0 | September 2025 | Receiving vulnerability reports: security.txt, CVD policy, CSAF v2.0 advisories | | Part H - Conformity based on full quality assurance | 1.1.0 | 30 May 2026 | Demonstrating conformity through an ISO/IEC 27001 ISMS (Module H) instead of per-product | Two housekeeping notes before the substance. First, **Part 2 has not changed**. Version 2.1.0 from August 2025 is still current, and if you see a file named `BSI-TR-03183-2_v2_2_0.pdf` on BSI's website, do not get excited: it sits in the archive section and contains the outdated version 1.1 document. There is no v2.2.0. Second, everything in this family is **explicitly non-binding**. Part 1 says so in its own words: it does not establish obligations on manufacturers and does not provide a presumption of conformity. BSI also states that TR-03183 will be replaced by harmonised European standards once those exist. Non-binding is not the same as unimportant. Germany is making the BSI its CRA market surveillance authority, so the agency writing this guidance is the agency that will eventually be reviewing your technical file. ### Part 1: risk-based controls, in OSCAL Part 1 reached version 1.0.0 on 31 July 2026, announced on 5 August. Its target audience is stated plainly: manufacturers who do not yet have structured security-by-design and vulnerability-handling processes. It is an on-ramp, aimed at the CRA's default product class. Set expectations correctly, though: this is a **stable release, not a new document**. Part 1 has been a living draft since 2023, most recently as v0.10.0 in October 2025. If you diff the two, less has changed than the version jump suggests. What is actually new in 1.0.0 is the framing BSI now calls **Adaptable Risk-based Controls (ARC)**. Rather than handing you a flat checklist, every control comes attached to one or more risk scenarios, each describing the affected assets and impact plus environment parameters: access restriction, interface restriction, user capabilities. You categorise your product's assets by confidentiality, integrity and availability impact, describe the environment each component operates in, and select controls where both the asset impact and the environment match. The underlying risk-scenario method was already in the October draft; 1.0.0 gives it a name and a workflow. The part that should interest anyone building compliance tooling is not new but is easy to miss: BSI ships the control catalogue in **OSCAL**, NIST's Open Security Controls Assessment Language, at [github.com/tr-03183/tr-03183-1](https://github.com/tr-03183/tr-03183-1) with access details available on request. That repository was already referenced in v0.10.0. Machine-readable controls mean filtering by use case, building custom catalogues, and generating structured assessment evidence rather than another spreadsheet. It is the same instinct that drives machine-readable SBOMs, applied one level up. Part 1 also includes an assessment report template that mirrors CRA Annex VII. Its contents list is worth reading if you have been treating SBOM generation as a build-pipeline concern, because the SBOM appears there as documentation of conformity, sitting next to the risk assessment, the design documentation, and the vulnerability handling description. (A small note for anyone citing the document: its cover page is dated 31.07.2026 while its changelog row reads 2025-07-31, and the copyright line still says 2023-2025. The press release announcing version 1.0.0 is dated 5 August 2026, so the 2026 reading is the right one.) ### Part 3: the other half of vulnerability handling Part 3 covers something the SBOM conversation usually skips: how vulnerability reports reach you in the first place. It is the intake side, not the outbound Article 14 reporting side. The centrepiece is a **`security.txt`** file per [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html), and BSI does not leave it at "publish one." Section 4.2 is unusually prescriptive about the contents: | Field | Requirement | What BSI asks for | | --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------- | | Location | MUST | `/.well-known/security.txt`, over HTTPS, plain ASCII or UTF-8 | | `Canonical` | MUST | The authoritative URI, reachable without redirects | | `Contact` | MUST | Three entries in order: your PSIRT mailbox, your CSIRT mailbox, then the URI of your incoming-report web page | | `Encryption` | MUST | OpenPGP keys for every contact listed above | | `Preferred-Languages` | MUST | At least `en` | | `Policy` | MUST | URI of your CVD policy page | | `Expires` | MUST | RFC 3339, at most one year out, and reviewed at least quarterly | | Digital signature | MUST | OpenPGP-signed per RFC 9580, with key validity capped at five years | | `CSAF` | SHOULD | URI of your `provider-metadata.json`, prefixed with the `CSAF:` tag | | `Acknowledgments` | SHOULD | URI of your researcher acknowledgements page | | Crawler visibility | MUST | Firewall and DDoS rules must not block automated discovery | Beyond the file itself, Part 3 requires a dedicated web page for incoming reports with a web form, and a coordinated vulnerability disclosure policy that names the corresponding national CSIRT, gives assurances to reporters, sets out a code of conduct, guarantees response times, offers an anonymous reporting option, and explains how the process ends. And it requires security advisories published in **OASIS CSAF v2.0**, with BSI pointing at the open-source CSAF Provider tooling to generate them. That last requirement is the same architectural decision as Part 2's rule that SBOMs **must not** contain vulnerability information, viewed from the other end. Static component inventory lives in the SBOM. Dynamic vulnerability state lives in CSAF or [VEX](/2026/02/01/sbom-scanning-vulnerability-detection/). BSI has now specified both halves, and they are designed to be read together: one of Part 2's optional component fields is the component creator's `security.txt` URL. Your SBOM tells a downstream consumer what is inside your product; your `security.txt` tells them where to shout when one of those components turns out to be broken. If you are wondering whether a three-line `security.txt` clears this bar, check yours against the table. Most do not, and the two most commonly missing MUSTs are the `Policy` link and the OpenPGP signature. ### Part H: conformity through your ISMS CRA Article 32 lets manufacturers choose their conformity assessment route, and one option is Module H, full quality assurance. Module H assesses the manufacturer's **processes** rather than each individual product. BSI ran a commenting phase on TR-03183-H from 27 February to 31 March 2026 and published version 1.1.0 on 30 May 2026, mapping Module H onto an ISO/IEC 27001-compliant ISMS. For anyone running an SBOM programme, this is a quietly useful lever. If your SBOM generation, storage, signing and distribution exist as auditable ISMS processes rather than per-release improvisation, Module H lets that work cover an entire portfolio instead of being re-demonstrated product by product. Process maturity becomes the deliverable. ## What Else Moved BSI was not the only one busy this summer. **The Commission approved its first CRA application guidance on 27 July 2026** (C(2026) 5252 final). The annex runs to 84 pages with 67 numbered practical examples, and works through the questions manufacturers actually ask: what counts as a product with digital elements, when free and open-source software falls in scope, what makes a modification substantial, how support periods work, and how reporting obligations apply. It is non-binding, and only the Court of Justice can authoritatively interpret the CRA, but it will shape how market surveillance authorities and notified bodies read the regulation. Worth setting expectations: the words "SBOM" and "software bill of materials" do not appear anywhere in those 84 pages. If you were hoping the Commission would finally pin down SBOM format and content, this is not that document, and Article 13(24) implementing acts still have not arrived. Two paragraphs in it _are_ directly relevant to anyone triaging component vulnerabilities: **Paragraph 218 — third-party components.** If your product contains an actively exploited vulnerability originating from a third-party component, you must report it. But where you know a component carries a vulnerability that either (i) cannot be exploited in your product (the guidance's own example: the vulnerable code is not reachable) or (ii) has not been exploited in your product, it is not an actively exploited vulnerability _contained in your product_, and mandatory reporting does not bite. You can still notify voluntarily under Article 15, you still owe the Annex I Part II vulnerability handling duties, and you still have to report it upstream to the component's maintainer under Article 13(6). Read that again as an engineering requirement: the Commission has made "is the vulnerable code reachable in our product?" a question with a legal consequence. That is a VEX-shaped determination sitting directly on top of your SBOM. **Paragraph 217 — no retroactive reporting.** Vulnerabilities you already knew were being exploited before 11 September 2026 do not need reporting. But if you knew about a vulnerability before that date without knowing it was exploited, and exploitation happens or surfaces afterwards, the clock starts then. Your pre-September backlog is not a safe harbour. **ENISA published step-by-step Single Reporting Platform instructions on 31 July 2026.** Three details deserve attention: 1. **Registration happens through EU Login**, with a nominated Primary and Secondary representative. ENISA says EU Login accounts can be created in advance, and that a representative's validation by the coordinator CSIRT happens after first access, in parallel with reporting. So being unregistered will not formally block you — but a 24-hour early-warning window is not when you want to be discovering the flow. 2. **There is no reporting API at launch.** ENISA's own FAQ states that "no Application Programming Interfaces will be provided at this stage." You can automate your internal workflow right up to submission, but a human types the final form into a browser. That makes the quality of your internal triage data the rate-limiting factor, not your integration work. 3. **The 24-hour early warning is deliberately minimal**: notification type and level, manufacturer or steward name, product, title, and whether malicious acts are suspected. The 72-hour notification adds the nature of the vulnerability, exploitation details and corrective measures. Minimal does not mean easy, because "product" means knowing which of your products and versions are affected. **Harmonised standards are still not there.** The horizontal EN 40000 series (vocabulary, cyber resilience principles, vulnerability handling, technical security controls) and the vertical EN 50770 series for OT products are in development, but **no CRA harmonised standard has been cited in the Official Journal**. Until one is, nobody gets the Article 27 presumption of conformity, and everyone demonstrates conformity by describing the solutions they adopted. A draft Commission amendment in early July 2026 proposes pushing the delivery deadlines back two months — Type A and Type B to 31 October 2026, Type C to 31 December 2026 — but the implementing decision has not been published, so those dates are proposed rather than binding. Reporting from standardisation trackers suggests only the vulnerability handling part, prEN 40000-1-3, is currently expected to be cited at all; drafts are not public, so treat that as directional. **Product classification is settled, though.** [Implementing Regulation (EU) 2025/2392](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392), adopted on 28 November 2025 and in force since 21 December 2025, provides the technical descriptions behind the CRA's "important" and "critical" product categories, and confirms that a product's core functionality drives classification rather than ancillary or embedded features. Classification determines your conformity assessment route, which determines who reads your technical documentation and how closely. ## What This Actually Changes for SBOM Practice The SBOM requirements did not move. TR-03183-2 v2.1.0 still asks for CycloneDX 1.6+ or SPDX 3.0.1+ in JSON or XML, still requires recursion down each dependency path to the first component outside your scope of delivery, still requires SHA-512 hashes and SPDX licence identifiers and a completeness indicator on dependency enumeration, and still forbids vulnerability data inside the document. If you were compliant in 2025, you are compliant now. What changed is the surrounding scaffolding, and it points in one direction: **the SBOM is documentation of conformity, not a build artefact**. Three consequences worth internalising: - **Retention is a decade.** CRA Article 13(13) requires technical documentation to stay at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period, whichever is longer. Article 31(2) requires it to be continuously updated during the support period. Combine that with TR-03183-2's rule of one SBOM per software version, and you are not producing an SBOM, you are running a queryable archive. - **Top-level dependencies are a floor, not a target.** The CRA text asks for "at least the top-level dependencies." BSI asks for considerably more, and the September reporting clock asks for more still. When an exploited CVE lands in a transitive dependency, the legal minimum will not answer the question you are being asked in 24 hours. - **Intake and outbound are separate problems.** Part 3 makes sure researchers can reach you. The SRP makes sure you can reach the CSIRT. The SBOM sits in the middle, converting "there is a bug in library X" into "these seven product versions are affected, and in four of them the code is not reachable." Neither BSI nor ENISA will do that step for you. ## The Three-Week Checklist If you sell products with digital elements into the EU, here is what needs to be true before 11 September: 1. **Get EU Login sorted for the ENISA Single Reporting Platform.** Accounts created, Primary and Secondary representatives named, done now rather than under pressure. There is no API, so make sure the people who will actually submit have working access. 2. **Know what is in your shipped versions.** SBOMs for every version currently in the field, stored somewhere you can query in minutes rather than reconstruct in days. This is the whole ball game for a 24-hour deadline. 3. **Publish a security.txt and a CVD policy.** Per TR-03183-3 and RFC 9116. If reports cannot reach you, your 24-hour clock starts late and you find out from someone else. 4. **Be able to produce CSAF advisories.** Not strictly required by Article 14, but it is where BSI is pointing, and Article 14(8) already expects you to inform users "where appropriate in a structured, machine-readable format that is easily automatically processable." 5. **Check your classification** against Implementing Regulation (EU) 2025/2392 before you assume self-assessment is available to you. Everything else on the CRA list can wait for December 2027. These five cannot. ## How sbomify Helps sbomify generates SBOMs automatically in CI/CD with the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action), keeps one per product version in a queryable archive rather than a folder of attachments, and continuously matches components against vulnerability data so "which of our releases contain this?" is a query instead of a project. Our **BSI TR-03183-2 v2.1.0 plugin** grades each uploaded SBOM against the format, SBOM-level and component-level requirements and shows you the gaps before an authority does. On the Part 3 side, every [Trust Center](/faq/what-is-a-trust-center/) can publish an RFC 9116 `security.txt` at `/.well-known/security.txt`, populated from your workspace security contacts, with `Canonical`, `Encryption`, `Preferred-Languages` and `Expires` filled in for you. Toggle it on in **Settings > Trust Center**; ours is live at [trust.sbomify.com](https://trust.sbomify.com/.well-known/security.txt). Our [CRA Compliance Wizard](/faq/how-do-i-use-cra-compliance/) then reuses those values in its vulnerability-handling step rather than asking you to retype them, and tracks your ENISA SRP registration status alongside them. If you are chasing full TR-03183-3 conformance, the fields you will still need to add yourself are the `Policy` link to your CVD policy, the `CSAF` pointer to your `provider-metadata.json`, the full PSIRT/CSIRT contact ordering, and the OpenPGP signature over the file. The trajectory here is not subtle. Regulators started by asking whether you have an SBOM. They have moved on to asking how fast you can use one. BSI just published three more documents describing the machinery around that question, and in three weeks the first part of it stops being advisory. Further reading: our [EU CRA compliance guide](/compliance/eu-cra/), the [BSI TR-03183-2 summary](/compliance/bsi-tr-03183/), and [the CRA explained for device manufacturers](/2026/01/06/cra-explained-cyber-resilience-act-for-device-manufacturers/). --- # Announcing sbomify v26.7.1: The One That Says "Not Affected" URL: https://sbomify.com/2026/07/30/announcing-sbomify-v26-7-1-the-one-that-says-not-affected/ Date: 2026-07-30 Description: sbomify v26.7.1 ships end-to-end VEX support across CycloneDX, OpenVEX, and CSAF, with in-product triage, Dependency-Track sync, and scheduled drift detection. CBOM ingestion now covers every lineage, the Trust Center exposes VEX and CBOM per release, and vulnerability counts finally reflect your current posture. An SBOM tells you what is in your software. A vulnerability scanner tells you which of those components have known CVEs. Neither answers the question your customers actually ask: **are you affected?** Most of the time, the honest answer is no. The vulnerable function is never called, the affected code path is compiled out, the component ships but is never reachable. That answer has a standard format, VEX, and until now sbomify could store it but not really work with it. v26.7.1 changes that. Here is what matters for you. ## VEX, End to End **VEX** (Vulnerability Exploitability eXchange) is a machine-readable statement about whether a specific vulnerability actually affects a specific product. Instead of shipping an SBOM and leaving your customers to draw their own conclusions from a raw CVE list, you tell them: this one is not affected, and here is why. The reason this matters is asymmetric effort. Without VEX, every customer who scans your artifact independently rediscovers the same forty findings and files the same questions with your security team. With VEX, you make the determination once and it travels with the product. v26.7.1 supports the whole lifecycle: - **Three formats, one workflow.** Author or upload VEX as CycloneDX VEX, [OpenVEX](https://github.com/openvex), or [CSAF](https://oasis-open.github.io/csaf-documentation/). sbomify ingests all three and normalizes them, so your choice of format is a detail rather than a commitment. - **Triage inside the product.** Findings can be triaged where you already look at them, with the status and justification recorded as a proper VEX statement rather than a comment in a spreadsheet. - **Dependency-Track triage sync.** If your team already triages in Dependency-Track, that work no longer has to be redone. Opt in, and triage decisions flow into sbomify and are automatically pinned to the relevant release. - **Scheduled drift detection.** This is the part teams underestimate. VEX statements go stale: a new version changes whether a code path is reachable, or a new High/Critical finding lands with no statement covering it at all. sbomify now checks on a schedule and tells you, rather than letting a six-month-old "not affected" quietly become wrong. That last point is the difference between VEX as a compliance artifact and VEX as something you can actually rely on. --- ## CBOM: Every Lineage Now Ingests [v26.7.0 introduced Cryptography BOM support](/2026/07/07/announcing-sbomify-v26-7-0-the-one-that-gets-quantum-ready/) and post-quantum readiness assessment. The gap in that release was ingestion breadth: depending on which tool produced your CBOM, sbomify might or might not recognize it. That gap is closed. Every CBOM lineage now ingests, with CycloneDX 1.7 crypto-registry normalization so assets from different generators land in the same shape. Alongside that, the crypto asset UX has been reworked, CBOMs are exposed through [TEA](https://github.com/CycloneDX/transparency-exchange-api), and your workspace dashboard now includes crypto posture next to everything else. If you tried CBOM upload last month and your generator was not picked up, try again. --- ## The Trust Center Gets Your Posture Your [Trust Center](/features/trust-center/) is the public face of all this, and it now carries the new artifacts: - **VEX and CBOM downloads per release**, alongside the SBOMs already there. - **Vulnerability posture on the release page**, so a customer can see your position without emailing you for it. - **A simpler posture panel.** The VEX toggle is gone. It was a control that asked visitors to understand an implementation detail before they could read the page, which is precisely backwards for a page aimed at people evaluating your product. --- ## Numbers That Reflect Reality One fix in this release deserves calling out on its own, because if you looked at your vulnerability counts before today, they were probably wrong in a specific and unhelpful way. Counts were aggregated across **every historical SBOM version** rather than your current posture. Upload ten iterations of a component over six months, fix things along the way, and the dashboard still counted findings from all ten. The number went up and never came down. Counts now reflect current posture. Expect your totals to drop, in most cases substantially. Nothing was fixed by the change itself; the number is simply telling the truth now. Alongside that: - **Component pages no longer time out at scale.** Two query fixes for workspaces with large artifact histories, where the page could hit a 504. - **Dependency-Track 4 and 5 both work**, including findings pagination. - **The SBOMs list shows the latest artifact per format**, not just the most recent upload overall, so a CycloneDX SBOM no longer hides behind an SPDX one. - **Skipped assessments read as skipped**, not as warnings. A skipped scan is information, not a problem to investigate. --- ## A Fresh Look The dashboard onboarding flow has been redesigned, and component, product, and vulnerability pages have had a design refresh. Under it, the front end has migrated to Tailwind v4 colours, which mostly means the palette is consistent in places it previously was not. --- ## API and Security - **Workspace-scoped tokens are enforced across the whole workspaces API.** A token bound to one workspace cannot read another, on every endpoint rather than most of them. - **The component SBOMs list endpoint gains version and format filtering**, so you can ask for exactly the artifact you want instead of fetching everything and filtering client-side. - **Dependency updates** covering pillow, pyasn1, and datamodel-code-generator. --- ## Under the Hood A few things that are invisible in the product but change how quickly we can respond when something breaks for you: - Every app's test suite now runs in CI, and CI fails loudly if one goes missing rather than silently skipping it. - Frontend test failures can no longer pass CI silently, and a long-standing flake in the vulnerability trends timeline is fixed. - Our error tracking stopped tagging production events as `development`, which had been quietly hiding production alerts from the people meant to see them. Unglamorous, but it is the difference between hearing about a problem from our monitoring and hearing about it from you. --- ## Getting Started If you are on the **hosted platform**, all of the above is already live. The fastest way to see the VEX work is to open a component with known findings and triage one: pick a status, record a justification, and note that what you get back is a real VEX statement you can publish, not an annotation trapped in our database. If you already triage in Dependency-Track, enable the sync instead and let your existing decisions flow in. For **self-hosted** deployments, pull `ghcr.io/sbomify/sbomify:v26.7.1` and update. Either way, check your vulnerability counts after upgrading. If they drop sharply, that is the posture fix working as intended. For the full technical detail, see the [v26.7.1 release notes on GitHub](https://github.com/sbomify/sbomify/releases/tag/v26.7.1). As always, I would like to hear how this lands, and particularly where the VEX workflow does not fit how your team actually triages. VEX is a young standard and the tooling around it is still finding its shape; if the model we have chosen gets in your way, that is useful for us to know. Open a support ticket from inside [the app](https://app.sbomify.com) and it will reach the team. --- # ENISA's New Healthcare Procurement Guidelines Ask for SBOMs Without Saying the Word URL: https://sbomify.com/2026/07/23/enisa-healthcare-procurement-guidelines/ Date: 2026-07-23 Description: ENISA's July 2026 procurement guidelines for hospitals and healthcare providers require supply chain transparency, component listings, and vulnerability management. Here is how SBOMs satisfy them. In July 2026, the European Union Agency for Cybersecurity (ENISA) published its updated [Procurement guidelines for the cybersecurity of hospitals and healthcare providers](https://www.enisa.europa.eu/sites/default/files/2026-07/Procurement%20guidelines%20for%20the%20cybersecurity%20of%20hospitals%20and%20healthcare%20providers.pdf). The document is a deliverable of the European Commission's January 2025 action plan on healthcare cybersecurity and replaces ENISA's 2020 procurement guidance. Here is the part that caught our eye: across 69 pages of procurement measures, checklists, and worked scenarios, the word "SBOM" never appears. And yet the guidelines repeatedly ask hospitals to demand exactly what a [Software Bill of Materials](/what-is-sbom/) provides. If you build software or connected devices for the European healthcare market, this document tells you what your next tender is going to ask for. Let's walk through it. ## Why Healthcare Procurement, and Why Now The numbers ENISA cites explain the urgency. There are over 500,000 types of medical devices and in vitro diagnostics on the EU market, and the European medical technology market was valued at roughly EUR 160 billion in 2023. Meanwhile, the ENISA Threat Landscape 2024 found that the health sector accounts for 8% of total ransomware incidents, making it one of the most targeted sectors. ENISA attributes this exposure to legacy systems, limited security budgets, and the complexity of healthcare supply chains. Only 27% of healthcare organisations have a dedicated ransomware defence programme. Regulation has been catching up. The [NIS2 Directive](/compliance/eu-nis2/) classifies health entities as essential or important entities and imposes supply chain security obligations that flow directly into how hospitals buy technology. Procurement is where those obligations become real: it is the moment a hospital can demand security evidence from a supplier and write consequences into a contract. The guidelines organize their measures into three procurement phases (plan, source, manage) plus a set of horizontal general measures, and they close with filterable checklists and three worked scenarios: buying radiology equipment in a large hospital, buying cloud services for a private medical centre, and buying an off-the-shelf EHR system as a general practitioner. ## The SBOM-Shaped Hole in the Document Read the supplier-facing measures and a pattern emerges. Several of them describe component transparency, which is precisely the problem SBOMs were created to solve. **SOURCE-06: Supply chain cybersecurity transparency.** This measure requires suppliers "to maintain transparency and accountability regarding third-party software and firmware components used in their IT and operational technology environments," explicitly including AI-related components and dependencies. ENISA calls this transparency "critical to identifying and mitigating supply chain risks effectively." That is a functional description of an SBOM: a structured inventory of the third-party components inside a product. **PLAN-03: Supply chain security policy.** The implementation guidance says suppliers should commit to keeping libraries and dependencies patched, and adds: "If possible, it would be best if bidders can provide a listing of the open-source components in the system and require adherence to relevant EU regulations like the CRA for security and documentation." A listing of the open-source components in the system is an SBOM. The only question is whether it arrives as a spreadsheet someone typed up or as a standard, machine-readable document. **MANAGE-01: Vulnerability disclosure and patch management obligations.** Suppliers must maintain a formal process for receiving vulnerability reports, analysing root causes, and shipping patches without undue delay. Buyers are told to require "evidence of patching and updating activities" and to monitor security advisories for all open source components in the solution. You cannot monitor advisories for components you cannot enumerate. Continuous vulnerability monitoring presupposes a component inventory, and [SBOM scanning](/2026/02/01/sbom-scanning-vulnerability-detection/) is how that works in practice. **MANAGE-02 and GENERAL-04.** Hospitals must maintain an accurate, up-to-date inventory of their entire technology infrastructure and must "identify, assess and remediate known vulnerabilities" in collaboration with suppliers. An asset inventory tells you which systems you own. Component-level transparency from suppliers tells you what is inside those systems. When the next Log4Shell-class vulnerability lands, the second inventory is the one that answers "are we affected?" So while the document never says SBOM, a supplier that maintains SBOMs for its products and a hospital that collects and monitors them will satisfy these measures almost mechanically. A supplier that does not will be answering these tender questions with prose and promises. ## The Regulatory Web Behind It The guidelines are explicit about their legal grounding, and the interplay is worth understanding. - **NIS2** obliges health entities to manage supply chain risk, which is the direct driver for these procurement measures. - **MDR and IVDR** impose lifecycle cybersecurity requirements on medical devices, from pre-market approval to post-market vigilance. - **The [Cyber Resilience Act](/compliance/eu-cra/)** requires SBOMs for products with digital elements, but products covered by the MDR or IVDR are exempt from the CRA. That last point matters. A medical device manufacturer might conclude that the CRA's SBOM mandate does not apply to them. Technically correct. But the procurement route closes the gap: ENISA is telling hospitals to demand CRA-style component transparency contractually, whatever the product's regulatory classification. PLAN-03 even name-checks the CRA as the bar for security and documentation. The regulatory exemption does not survive contact with a well-written tender. Manufacturers selling into the US market will find this familiar. The FDA already [expects SBOMs in premarket submissions](/2026/01/09/fda-medical-device-sbom-requirements/) for cyber devices under Section 524B of the FD&C Act. A device maker that has built SBOM generation into its development lifecycle for FDA purposes is most of the way to answering an ENISA-aligned European tender. ## What This Means If You Sell Into EU Healthcare Expect tenders influenced by these guidelines to ask for: 1. **A component listing for your product.** Provide it as a machine-readable SBOM in [CycloneDX or SPDX](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/), not a PDF appendix. The buyer's security team can actually use a standard format, and it signals maturity. 2. **Evidence of a secure development lifecycle.** SOURCE-05 requires security by design, cryptographically authenticated updates, and verified software authenticity. SBOM generation in CI/CD is part of demonstrating this. 3. **A vulnerability disclosure and patching commitment with teeth.** The guidelines suggest contracts should treat failure to remediate known vulnerabilities within a reasonable time frame as a breach of agreement. You will want your own continuous monitoring so the hospital is not the one telling you about CVEs in your product. 4. **Patch evidence over the product lifetime.** Patch logs, reports, and change records. An SBOM per release gives both sides a precise record of what changed. ## What This Means If You Buy For a Hospital The guidelines hand procurement teams a checklist, and Annex B makes it filterable by procurement type. Our advice on top of it: - **Ask for SBOMs by name and by format.** "A listing of open-source components" invites a Word document. "A CycloneDX or SPDX SBOM meeting the [CISA minimum elements](/compliance/cisa-minimum-elements/)" invites something your tooling can ingest. - **Collect SBOMs somewhere you can query.** An SBOM in a contract annex is compliance theatre. An SBOM in a platform that continuously matches components against vulnerability databases is a security control. GENERAL-04 and MANAGE-01 effectively require the latter. - **Make SBOM delivery a lifecycle obligation, not a one-time deliverable.** Products change with every update. Require a fresh SBOM per release, tied to the patching evidence the guidelines already tell you to demand. ## How sbomify Helps This is the workflow sbomify was built for. Suppliers can generate SBOMs automatically in CI/CD with the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action), organize them by product and release, and share them with customers through a portal instead of email attachments. Healthcare buyers get continuous vulnerability monitoring of every collected SBOM, so the component inventory ENISA asks for stays live instead of going stale in a filing cabinet. The pattern behind these guidelines is bigger than healthcare: regulators and buyers everywhere are converging on the same demand, namely that software suppliers know and disclose what is inside their products. ENISA did not need to write the word SBOM for that to be the answer. --- # Announcing sbomify v26.7.0: The One That Gets Quantum-Ready URL: https://sbomify.com/2026/07/07/announcing-sbomify-v26-7-0-the-one-that-gets-quantum-ready/ Date: 2026-07-07 Description: sbomify v26.7.0 adds Cryptography BOM (CBOM) support with NIST-grounded post-quantum readiness assessment, per-token API rate limiting with audit logging, a rebuilt authorization layer, and a broad security hardening pass. Most of the SBOM world is focused on one question: what software am I shipping? v26.7.0 adds a second question that is about to matter a great deal: what cryptography am I shipping, and will it survive the post-quantum transition? This release brings Cryptography BOM (CBOM) support with built-in post-quantum readiness assessment, a much more manageable API token story, and a deep security and authorization overhaul. Here is what matters for you. ## CBOM Support and Post-Quantum Readiness A **Cryptography BOM (CBOM)** is to your cryptographic assets what an SBOM is to your dependencies: a machine-readable inventory of the algorithms, keys, protocols, and certificates your software actually uses. It is part of the CycloneDX specification, and it exists because "which of our systems still use RSA-2048?" is a question most organizations cannot answer today. That question is becoming urgent. NIST has finalized its first post-quantum cryptography (PQC) standards, and the guidance is clear: the classical public-key algorithms that underpin most of today's software, such as RSA and elliptic-curve cryptography, are expected to be broken by a sufficiently capable quantum computer. Attackers are already harvesting encrypted traffic now to decrypt later. You cannot plan a migration away from vulnerable algorithms until you know where they are. v26.7.0 makes sbomify a place to answer that: - **Upload a CBOM and get a crypto-asset inventory.** sbomify extracts the cryptographic assets from your CBOM into a browsable inventory, with a read API so you can pull it into your own tooling. - **NIST-grounded PQC readiness classification.** Every asset is graded against NIST post-quantum guidance, so you can see at a glance which algorithms are quantum-safe, which are on borrowed time, and which need to go first. - **A PQC posture card on your components.** The new assessment plugin summarizes a component's post-quantum readiness right where you already look at its SBOMs and vulnerabilities. - **Zero-effort ingestion.** CBOMs are auto-detected and tagged on upload. You do not need to tell sbomify what you are sending; if a document contains CBOM content, it is recognized and processed. If you have uploaded CBOMs in the past, they are picked up too. And because we do not ship anything we do not use ourselves, **sbomify now publishes its own CBOM** from CI on every release, alongside its SBOMs. If regulators follow the same path with cryptographic transparency that they took with software transparency, and the early signals suggest they will, getting your crypto inventory in order now puts you ahead of the curve rather than behind a deadline. --- ## API Tokens You Can Actually Manage If you run integrations against the sbomify API, this release gives you the operational visibility that has been missing: - **See which tokens are actually in use.** Every token now tracks when it was last used, surfaced right in the UI. That token from an experiment eight months ago? You can now see it has been idle since, and revoke it with confidence. - **Bulk revocation.** When someone leaves the team or you need to respond to an incident, you can revoke tokens in bulk instead of clicking through them one at a time. - **An audit trail for token authentication.** Token-auth events are now written to a structured audit log, so "who accessed what, with which credential, and when" has an answer. - **Per-token rate limiting.** API requests are now rate limited per token, with standard `429` responses, a `Retry-After` header, and `X-RateLimit-*` headers on responses so well-behaved clients can pace themselves. Upload endpoints get stricter limits. One runaway script can no longer degrade things for everyone else, including your own other integrations. Alongside this, we published two new guides: [API access-token best practices and a legacy-token rotation guide](https://github.com/sbomify/sbomify/pull/1073). If you still have long-lived tokens from before expiry became the default, the rotation guide is written for you. --- ## An Authorization Overhaul A large part of this release happened below the waterline: we rebuilt how sbomify decides who is allowed to do what. Previously, authorization checks lived inline throughout the codebase, each endpoint doing its own thing. Every check has now been migrated onto a single authorization front door, and a CI gate prevents new inline checks from sneaking back in. One consistent enforcement point instead of hundreds of scattered ones. What you actually get from this: - **Token scopes are enforced everywhere.** A read-only token is now read-only on every endpoint, including list, artifact, and component reads, and workspace-scoped tokens cannot reach outside their workspace. The scope you set on a token is the access it has, full stop. - **Destructive actions are owner-only.** Deleting things now requires owner privileges, and guests can be granted upload access without gaining anything else. - **CI bots stay in their lane.** OIDC trusted publishing credentials (introduced in v26.3.0) can publish releases but are confined to the specific component they are bound to. A compromised pipeline cannot publish on behalf of the rest of your workspace. --- ## Security Hardening The usual unglamorous-but-important pass, and this one was thorough: - **Stored-XSS prevention** in inline document serving, so a malicious document uploaded to a workspace cannot execute script in the browser of someone viewing it. - **Content-Security-Policy and `X-Content-Type-Options` headers** across the platform, adding defense in depth against script injection and MIME confusion. - **Client IPs are no longer spoofable.** The `X-Real-IP` header is only trusted when it comes from configured proxies, which keeps audit logs and rate limiting honest. - **Workspace-isolation fixes** in team management, plugin settings, and public aggregates, closing cross-workspace access paths (IDOR) that should never have been reachable. - **Dependency and container-image updates** clearing all High-severity advisories across the stack. None of these require any action from you. They are the kind of fixes you want your SBOM platform, of all things, to take seriously. --- ## Performance, Billing, and the Rest - **Faster aggregate SBOM builds.** Cold builds of aggregated release and product SBOMs now fetch in parallel, so the first load after a change is noticeably quicker. - **SPDX-native cross-document linking.** Aggregated SPDX documents now reference their constituent documents the way the SPDX spec intends, which makes them play better with downstream SPDX tooling. - **Atomic release-artifact replacement.** Replacing an artifact on a release is now all-or-nothing, so consumers never see a half-updated release. - **Billing does the right thing on downgrade.** Downgrading now cancels the actual subscription, and the grace-period logic has been hardened. - **Vulnerability dashboard summary cards are point-in-time snapshots**, so the numbers you see reflect a consistent moment rather than shifting under you. - **Inbound notification emails set Reply-To to the submitter**, so replying to a notification reaches the person who triggered it. One housekeeping note: you may notice the version jumped from v26.3.0 straight to v26.7.0. Under [CalVer](https://calver.org/), the minor version is the month of release. Nothing was skipped; it has simply been a few months of heads-down work. --- ## Getting Started If you are on the **hosted platform**, everything above is already live. To try the CBOM support, generate a CBOM for one of your components (tools like [cdxgen](https://github.com/CycloneDX/cdxgen) can emit them) and upload it the same way you upload an SBOM. sbomify will detect it, build your crypto inventory, and show you the PQC posture card. While you are in the app, take two minutes to look at your API tokens: the new last-used column makes stale credentials easy to spot, and bulk revocation makes them easy to clean up. For **self-hosted** deployments, pull `ghcr.io/sbomify/sbomify:v26.7.0` and update. If you have previously uploaded CBOMs, run the backfill command to tag them and generate PQC assessments for your existing data. For the full technical detail, see the [v26.7.0 release notes on GitHub](https://github.com/sbomify/sbomify/releases/tag/v26.7.0). As always, I would love to hear your feedback, especially on the post-quantum readiness work. This is a new area for most teams, and we want to build the tooling that makes the transition tractable. If something is unclear or you want to see the assessment go deeper, open a support ticket from inside [the app](https://app.sbomify.com) and the team will get back to you. --- # Announcing sbomify v26.3.0: The One That Ditches the Token URL: https://sbomify.com/2026/06/12/announcing-sbomify-v26-3-0-the-one-that-ditches-the-token/ Date: 2026-06-12 Description: sbomify v26.3.0 adds GitHub Actions OIDC trusted publishing so you can push SBOMs with no long-lived API token, expires personal access tokens by default, removes the Project layer, and ships a broad security and access-control hardening pass. The headline of v26.3.0 is about getting rid of something: the long-lived API token sitting in your CI secrets. With GitHub Actions OIDC trusted publishing, your pipeline can now push SBOMs to sbomify without any stored credential at all. Alongside that, this release tightens access control across the board and simplifies the workspace hierarchy. Here is what matters for you. ## OIDC Trusted Publishing for GitHub Actions If you publish SBOMs from GitHub Actions today, you almost certainly have a sbomify API token stored as a repository or organization secret. That token is long-lived, it has to be rotated by hand, and if it ever leaks it can be used from anywhere until you notice and revoke it. v26.3.0 removes the need for it. sbomify now supports **OpenID Connect (OIDC) trusted publishing** for GitHub Actions, the same model [PyPI](https://docs.pypi.org/trusted-publishers/) and other ecosystems have moved to. Here is how it works. Instead of storing a secret, you create a **binding** in sbomify that says "this GitHub repository is allowed to publish to this workspace." When your workflow runs, GitHub mints a short-lived, cryptographically signed token that proves which repository, workflow, and branch the job is running from. sbomify verifies that token against your binding and accepts the upload. The token is valid for minutes, not months, and it never leaves the runner. For you, this means: - **No secret to store or rotate.** There is nothing in your repository settings to leak, and nothing to remember to cycle every quarter. - **Scoped to exactly one repository.** A binding authorizes one specific repo to publish, so a token minted anywhere else is useless. - **Upload-only by design.** OIDC credentials can publish SBOMs and nothing else. They cannot read or manage the rest of your workspace. - **Private repositories supported.** You can create a binding for a private repo using just the org and repo name, with no token and no need to expose anything. The repository ID is pinned automatically the first time it publishes. There is a new authenticated API for managing bindings, so you can wire this into your own provisioning if you run a lot of repositories. We are also [publishing sbomify's own SBOMs](https://github.com/sbomify/sbomify/pull/1013) through OIDC trusted publishing now, as the reference implementation for rolling it out across an organization. If you only take one thing from this release, take this one. Moving your pipeline off a stored API token is one of the highest-leverage supply-chain security improvements you can make, and it is now a few minutes of setup. --- ## Personal Access Tokens Now Expire This is the change most likely to need action from you, so it gets its own section. Until now, personal access tokens (PATs) in sbomify lived forever unless you explicitly revoked them. As of v26.3.0, **new tokens expire by default, with a 90-day lifetime.** Long-lived credentials are the thing attackers love most, and a token that never expires is a token you will eventually forget you issued. Capping the default lifetime keeps your workspace's credential footprint honest. What this means in practice: - **Existing tokens are not retroactively killed**, but any integration that depends on a long-lived PAT should plan to rotate on a schedule rather than set-and-forget. - **For CI pipelines, prefer OIDC trusted publishing** (above) over a PAT wherever you can. It sidesteps the rotation problem entirely. - If you genuinely need a longer-lived token for a specific integration, you can still set the expiry when you create it. --- ## Goodbye, Project Layer We have simplified the workspace hierarchy. The old three-level model of **Product, Project, Component** is now just **Product and Component**. The Project layer is gone. In practice almost nobody was using Projects as a meaningful grouping. They added a click and a concept without adding much value, and they made the data model harder to reason about. Flattening to Product and Component matches how people actually think about their software: a product is the thing you ship, and it is made of components. This release includes a **data migration** that moves your existing components up under their products automatically. On the hosted platform this has already happened and there is nothing for you to do. If you self-host, see the upgrade note at the end. --- ## A Security and Access-Control Hardening Pass A large chunk of this release is unglamorous but important: making sure that every endpoint checks who you are and what you are allowed to see, every time. If you run sbomify in front of real customers, these are the fixes you want. - **Authentication required on list endpoints**, and invalid bearer tokens are now properly rejected instead of being quietly ignored. - **CSRF protection on the API.** Browser-based, cookie or session authenticated requests now require a CSRF token. Bearer-token requests (your PATs and OIDC credentials) are exempt, so existing API integrations are unaffected. - **Access is re-checked at download time.** When someone follows a signed link to download an artifact, sbomify now re-verifies that they still have access at that moment, rather than trusting that they did when the link was created. - **Roles are read from the database, not a stale session cache.** If you revoke someone's access, that change now takes effect immediately rather than lingering until their session refreshes. - **Private product names are redacted** from branding reads for users who are not members of the workspace, and membership is enforced before those reads happen. - **Transport and cookie hardening** ships alongside the CSRF work. None of these require any action from you. They simply close gaps so that the boundary between public and private data holds up under scrutiny. --- ## CRA and Compliance Polish We have kept refining the EU Cyber Resilience Act workflow we have been building over the last two releases: - **CRA documents now render correctly in plain markdown viewers**, not just GitHub-flavored ones, and export cleanly to **PDF** in the production image. - **No more stray template comments** leaking into CRA and Trust Center output. A few pages were emitting tails of HTML comments into the visible text. They are gone. - **The sbomify-action call-to-action is now hidden** when your SBOM already came from sbomify-action, so you are not nagged to do something you already did. - **Broken BSI guidance links** that pointed at 404s have been replaced with the published page. --- ## Billing, Performance, and the Rest A round of reliability and polish work that you will mostly feel as "things just work better": - **Stripe webhooks retry on transient failures** instead of being dropped, so subscription state stays in sync even when Stripe has a hiccup. - **Faster page loads.** Stripe synchronization has been moved off the hot path that ran on every request, and aggregated release and product SBOMs are now cached, so dashboards render quicker. - **Vulnerability-trends dashboards** got repaired dropdowns, a new releases filter, and properly formatted counts. - **Relative timestamps** with a hover tooltip on "Created at" columns, so you can see "3 days ago" at a glance and the exact time when you need it. - **Dark-mode fixes** across public, authenticated, and Trust Center pages: logos, table headers, and code blocks that were previously hard to read. - **API correctness fixes:** field-level validation errors are preserved on 400 responses, out-of-range pagination returns an empty page instead of silently falling back, and a duplicate component name now returns a clear `DUPLICATE_NAME` error. --- ## Getting Started If you are on the **hosted platform**, everything in this release is already live, no action needed. Your components have already been migrated out from under the old Project layer, and OIDC trusted publishing is ready to set up from your workspace settings. If you have long-lived personal access tokens powering integrations, now is a good moment to plan their rotation or move them to OIDC. For **self-hosted** deployments, pull `ghcr.io/sbomify/sbomify:v26.3.0` and update. Take a database snapshot before you upgrade, as the Project-layer removal includes a real data migration. For the full technical detail, including the complete list of bug fixes, dependency upgrades, and infrastructure changes, see the [v26.3.0 release notes on GitHub](https://github.com/sbomify/sbomify/releases/tag/v26.3.0). As always, I would love to hear your feedback. If you are setting up OIDC trusted publishing and something is unclear, open a support ticket from inside [the app](https://app.sbomify.com) and the team will get back to you. Getting your pipeline off a stored token is exactly the kind of thing we want to make painless, so tell us where it is not. --- # SPDX 3.0 in Yocto: What Changed and Why It Matters URL: https://sbomify.com/2026/05/19/yocto-spdx-3-0-overview/ Date: 2026-05-19 Description: Part 3 of the Yocto SBOM series. SPDX 3.0 support arrived in Styhead (Yocto 5.1) with single-document JSON-LD output, first-class Build elements, native VEX support, and richer build provenance features. SPDX 3.0 support was added in the Styhead release (Yocto 5.1) and represents a significant architectural leap. The implementation lives in `create-spdx-3.0.bbclass` with supporting libraries in `meta/lib/oe/spdx30.py` (auto-generated SPDX 3.0 bindings) and `meta/lib/oe/sbom30.py` (SBOM construction utilities). This is part 3 of a 5-part series on how Yocto generates SBOMs. [Part 1](/2026/05/05/yocto-sbom-deep-dive-introduction/) covered the high-level architecture and [Part 2](/2026/05/12/yocto-spdx-2-2-pipeline/) walked through the SPDX 2.2 pipeline. ## What Changed Architecturally The most immediately visible difference is the output format: SPDX 3.0 uses JSON-LD (JSON for Linked Data) instead of plain JSON. This makes the documents RDF-compliant, meaning you can load them into any RDF tooling (like Python's `rdflib`) for sophisticated graph queries. The JSON-LD output also conforms to a strict JSON schema, so you do not necessarily need RDF tooling; simpler JSON parsers work just fine for most use cases. But the deeper changes are structural. **Single-document output.** Unlike SPDX 2.2's tarball of separate documents, the SPDX 3.0 implementation produces a single JSON-LD document that describes the entire image. This is possible because SPDX 3.0 uses global unique IDs for all objects, which makes the merging algorithm much simpler since it never has to worry about name collisions. The class builds up per-recipe SPDX data during the build, then merges everything into one cohesive document at image time. **First-class Build objects.** SPDX 2.2 had no concept of a "build." The `create-spdx-2.2` class shoehorned build information into package descriptions. SPDX 3.0 introduces `Build` as a first-class element, with proper `hasInput` and `hasOutput` relationships. This means you can express that a specific build took in some source files as input and produced some packages as output. **Profile-based architecture.** SPDX 3.0 documents declare which profiles they conform to. The Yocto implementation generates documents conforming to: `core`, `build`, `software`, `simpleLicensing`, and `security`. **Native VEX support.** This is arguably the biggest win for security-conscious teams. SPDX 3.0 natively supports VEX information through its security profile, meaning CVE data and vulnerability assessments live inside the SBOM rather than in a separate file. ## New Variables and Configuration ```bash SPDX_VERSION = "3.0.0" SPDX_PROFILES ?= "core build software simpleLicensing security" # Build provenance SPDX_INCLUDE_BUILD_VARIABLES ??= "0" SPDX_INCLUDE_BITBAKE_PARENT_BUILD ??= "0" SPDX_INCLUDE_TIMESTAMPS ?= "0" # VEX control SPDX_INCLUDE_VEX ??= "current" # Identity and namespacing SPDX_UUID_NAMESPACE ??= "sbom.openembedded.org" SPDX_NAMESPACE_PREFIX ??= "http://spdx.org/spdxdocs" ``` Most of the new variables control build provenance features that are disabled by default because they make the output non-reproducible (build timestamps, variable dumps, and so on). The VEX variable, however, is on by default (set to `current`), which is a deliberate choice to make vulnerability information available out of the box. ## SPDX 3.0 Task Flow **`spdx30_build_started_handler`**: A BitBake event handler (not a task) that fires at the beginning of the build. If `SPDX_INCLUDE_BITBAKE_PARENT_BUILD` is set, it creates a `Build` element representing the overall BitBake invocation and writes it to `bitbake.spdx.json` in the deploy directory. This is the parent build that individual recipe builds can reference. **`do_create_spdx`**: Similar in purpose to its SPDX 2.2 counterpart, but the output format and data model are very different. It creates an `ObjSet` (object set), a `software_Package` element for the recipe, a `Build` element representing the recipe's build, links source files as `hasInput` relationships on the `Build`, links produced packages as `hasOutput` relationships on the `Build`, adds license information using the `simpleLicensing` profile, and processes CVE data to create VEX relationship elements. The per-recipe data is written as individual JSON-LD files to the deploy directory. **`do_create_package_spdx`**: This task replaces `do_create_runtime_spdx` from SPDX 2.2 and creates SPDX data for each individual package, including file-level detail for packaged files with checksums and runtime dependencies. **`do_create_image_spdx` / `do_create_image_sbom`**: The image-level task merges all per-recipe JSON-LD documents into a single output file. The merging algorithm loads the image recipe's own SPDX data, then for each package included in the image loads its SPDX document and its recipe's SPDX document, merges all objects into a single object set deduplicating by SPDX ID, and serializes the merged object set as a single JSON-LD document. The result is a single `IMAGE-MACHINE.spdx.json` file in `tmp/deploy/images/MACHINE/`. ## Build Provenance Features in SPDX 3.0 **Build Variables** (`SPDX_INCLUDE_BUILD_VARIABLES = "1"`), Captures every BitBake variable visible during the SPDX task and attaches it to the `Build` element. This is a lot of data, but it means you can determine exactly how a recipe was configured just from the SBOM. **Nested Builds** (`SPDX_INCLUDE_BITBAKE_PARENT_BUILD = "1"`), Creates a hierarchy of `Build` elements. The top-level `Build` represents the BitBake invocation, and each recipe's `Build` is linked to it via `ancestorOf`. This is particularly useful for tracking shared state (sstate): you can see which recipes were rebuilt in a given BitBake run versus pulled from cache. **Agent Tracking:** ```bash SPDX_INVOKED_BY_name = "GitHub Actions" SPDX_INVOKED_BY_type = "software" SPDX_ON_BEHALF_OF_name = "Jane Developer" SPDX_ON_BEHALF_OF_type = "person" SPDX_ON_BEHALF_OF_id_email = "jane@example.com" ``` This records that your CI system ran the build on behalf of a specific person. The idea here is that GitHub Actions is the software agent that mechanically ran BitBake, but it was triggered by a pull request or tag made by a specific user. **Build Host Linking** (`SPDX_BUILD_HOST`), If you have an SBOM for the host system you are building on, you can link it into the generated documents using the `hasHost` relationship. This gives you a deep supply chain that extends from the build environment itself down through your target image. **Package Supplier:** ```bash SPDX_PACKAGE_SUPPLIER_name = "Acme Corporation" SPDX_PACKAGE_SUPPLIER_type = "organization" ``` All of these provenance features are disabled by default because it is not feasible for the core project to guess the correct values that should be provided. If desired, you should enable the ones relevant to your compliance requirements. ## The Supporting Libraries **`oe/spdx30.py`**: Auto-generated SPDX 3.0 Python bindings, roughly 6,000 lines of code. These are generated by the `shacl2code` tool from the official SPDX 3.0 RDF model. This means the Yocto implementation automatically stays in sync with the SPDX specification, and other tools can use these same bindings to manipulate SPDX 3.0 documents. `shacl2code` can also generate C++ and Go bindings and is available as a standalone project. **`oe/sbom30.py`**: SPDX 3.0 SBOM assembly utilities, including the document merging algorithm and convenience methods for creating VEX relationships. ## The Size Question A compressed SPDX 3.0 document for a standard Styhead distro can be around 250 MB compressed and roughly 2 GB uncompressed. This is partly because the single-document approach includes everything, and partly because the JSON-LD format with its `@context` declarations and full IRIs is more verbose than SPDX 2.2's simpler JSON. It is easy to generate SPDX 3.0 output that is larger than the deliverable it describes, because compilers are very good at compressing source code into smaller binaries. The SBOM that describes a 50 MB root filesystem might be 500 MB of structured data. If you are generating a new SBOM with every release build (as you should be for traceability and compliance), you need a storage strategy for these large files. ## Switching Between Versions ```bash # For SPDX 2.2 (if 3.0 is default) INHERIT:remove = "create-spdx" INHERIT += "create-spdx-2.2" # For SPDX 3.0 (if 2.2 is default) INHERIT:remove = "create-spdx" INHERIT += "create-spdx-3.0" ``` SPDX 2.2 has broader tooling support today, while SPDX 3.0 offers richer data and a more future-proof format. However, due to demand, SPDX 3.0 was backported to the Yocto 5.0 (styhead) LTS release, and thus should be available to more users. Additionally, starting with the Yocto 6.0 (wrynose) LTS release, SPDX 2.2 support has been removed so SPDX 3.0 is the only option. --- **Series: How Yocto Generates SBOMs Behind the Scenes** - Part 1: [How Yocto Generates SBOMs Behind the Scenes](/2026/05/05/yocto-sbom-deep-dive-introduction/) - Part 2: [A Deep Dive into Yocto's SPDX 2.2 Pipeline](/2026/05/12/yocto-spdx-2-2-pipeline/) - Part 3: SPDX 3.0 in Yocto: What Changed and Why It Matters _(this post)_ - Part 4: VEX in the SBOM: How Yocto Embeds Vulnerability Assessments _(coming soon)_ - Part 5: Yocto SBOM in Production: Configuration, Tooling, and What's Still Missing _(coming soon)_ --- # Announcing sbomify v26.2.0: The One That Signs the DoC URL: https://sbomify.com/2026/05/13/announcing-sbomify-v26-2-0-the-one-that-signs-the-doc/ Date: 2026-05-13 Description: sbomify v26.2.0 completes the EU CRA workflow with a signed Declaration of Conformity, adds Component Lifecycle Events, SBOM signatures and provenance, and full CycloneDX 1.7 / SPDX 3.0.1 support. In [v26.1.0](/2026/04/02/announcing-sbomify-v26-1-0-the-one-where-we-switch-to-calver/) we shipped the first half of the EU Cyber Resilience Act workflow: figuring out whether you are in scope, and what you need to fix. v26.2.0 is where we close the loop. You can now generate a signed Declaration of Conformity straight from sbomify, and publish it on your product's public page in front of customers and regulators. ## The Declaration of Conformity, End to End If you are putting a product on the EU market under the CRA, you need a [Declaration of Conformity](/compliance/eu-cra/). It is the document where you, the manufacturer, formally state that your product meets the regulation's requirements. Customers want it. Distributors want it. Regulators absolutely want it. With v26.2.0, you can produce one inside sbomify, end to end. The CRA Compliance Wizard now covers the full workflow: 1. **Scope screening.** Figure out whether your product is in scope. _(shipped in v26.1.0)_ 2. **Fix guidance.** Resolve any SBOM gaps that would block conformity. _(shipped in v26.1.0)_ 3. **EN 18031 opt-in.** If your product is in scope for the harmonised radio equipment standards, layer EN 18031-1/2/3 assessment on top. _(new in v26.2.0)_ 4. **Sign the DoC.** Generate the Declaration of Conformity, capture a manufacturer signature directly in the browser (no DocuSign required), and export it as a PDF. Optionally seal the whole bundle with a sigstore signature for cryptographic provenance. _(new in v26.2.0)_ 5. **Publish.** The resulting DoC is available on your product's public page, ready to share with customers and regulators with a single link. _(new in v26.2.0)_ We have also added a **stale-assessment guard**. If your SBOM has been updated since the last CRA assessment, the wizard surfaces a banner so you do not accidentally publish a DoC against outdated evidence. If you have a hardware product heading into the EU market in 2027, this is the workflow we built for you. --- ## Component Lifecycle Events Knowing when a product or component reaches end of support or end of life is critical for both customers and your own internal planning. In v0.25 we introduced lifecycle dates on products and components. With v26.2.0, we have made those a first-class concept. **Component Lifecycle Events** capture the full history of a product's life: when it was released, when it enters its mainstream support phase, when it goes into extended support, and when it finally reaches end of life. Each transition is recorded as an event, with a date and a context, rather than just a single static date field. For you, this means: - **History instead of state.** You can see how a product's lifecycle has evolved over time, not just where it is right now. - **Automatic publication.** A new public endpoint on your Trust Center exposes these events, so customers and downstream tooling can subscribe to lifecycle changes the same way they already pull SBOMs. - **No manual work.** Your existing release-date and end-of-life fields have been migrated automatically. You do not need to do anything. If you are tracking the lifecycle of a Linux distribution, a runtime, a library, or your own product, you now have a standard way to consume and propagate that signal. --- ## SBOM Signatures and Provenance An SBOM tells you what is in your software. A signed SBOM tells you where it came from and that nobody has tampered with it. v26.2.0 adds first-class support for **SBOM signatures and provenance attestations**. If you generate signed SBOMs from your CI/CD pipeline using [sbomify-action](https://github.com/sbomify/sbomify-action), sbomify will now: - **Verify the signature** automatically on upload, using [Sigstore](https://www.sigstore.dev/), the same infrastructure that powers supply-chain security across the open source ecosystem. - **Display a Signed badge** on the SBOM detail page when a valid signature is present. - **Display a Provenance badge** when an in-toto-style provenance attestation is attached. - **Show both badges in your Trust Center.** Customers looking at your public SBOM listings will see at a glance which artifacts are cryptographically verified. The trust signal is now visible inside your own dashboards and outside in front of customers. --- ## More SBOMs Will Just Work We have always been format-agnostic on uploads, but format support has been quietly broadening. With v26.2.0 we now accept: - **CycloneDX 1.3, 1.4, 1.5, 1.6, and 1.7** - **SPDX 2.2, 2.3, and 3.0.1** We have also relaxed two strict-validation rules that were tripping up real-world SBOMs from upstream tooling: CycloneDX SBOMs without a `metadata.component` field are now accepted, and so are SPDX 3.0.1 SBOMs without a top-level document name. Both are technically permitted by the respective specs, but several SBOM generators omit them in practice. If you have ever had an SBOM rejected by sbomify because of a missing field that you cannot control, this release likely fixes it for you. --- ## A Friendlier First Login A few smaller things that add up: - **Workspace hierarchy in the empty dashboard.** New workspaces now render a clickable hierarchy tree (Workspace → Product → Component → SBOM) so it is immediately obvious how the pieces fit together. Click anywhere on the tree to start creating the first one. - **Onboarding drip emails.** New users now receive a series of targeted tips after sign-up, rather than a single welcome message followed by silence. - **Redesigned emails.** Notification emails have been rebuilt from scratch, with full dark-mode support. Email clients finally caught up. --- ## Getting Started If you are on the **hosted platform**, everything in this release is already live, no action needed. The CRA Compliance Wizard is available from any product page, and your existing lifecycle dates have already been migrated into the new Component Lifecycle Events model. For **self-hosted** deployments, pull `ghcr.io/sbomify/sbomify:v26.2.0` and update. Take a database snapshot before you upgrade, as there is a real data migration in this release. For the full technical detail, including the complete list of bug fixes, dependency upgrades, and the under-the-hood plugin and infrastructure changes, see the [v26.2.0 release notes on GitHub](https://github.com/sbomify/sbomify/releases/tag/v26.2.0). As always, I would love to hear your feedback. If you are working through the CRA Compliance Wizard and something is confusing, or worse, missing, open a support ticket from inside [the app](https://app.sbomify.com) and the team will get back to you. The whole point of building this in the open is so we can fix the rough edges before the regulation actually starts to bite. --- # A Deep Dive into Yocto's SPDX 2.2 Pipeline URL: https://sbomify.com/2026/05/12/yocto-spdx-2-2-pipeline/ Date: 2026-05-12 Description: Part 2 of the Yocto SBOM series. How the create-spdx-2.2.bbclass produces SPDX documents during a Yocto build, the three core BitBake tasks involved, and the document-linking model that ties everything together. The SPDX 2.2 implementation in the Yocto Project has been stable since the Honister release (Yocto 3.4, October 2021). It is the established, widely understood pipeline that most Yocto users have been relying on, and for good reason. It produces standards-compliant SBOMs with rich per-package metadata that you can hand off to most SBOM tooling today. This post is part 2 of a 5-part series on how Yocto generates SBOMs. If you have not read [Part 1: How Yocto Generates SBOMs Behind the Scenes](/2026/05/05/yocto-sbom-deep-dive-introduction/), it covers why build-time SBOM generation matters and the high-level architecture. ## Key Variables and Configuration When `create-spdx-2.2.bbclass` is loaded, it sets up several directories and control variables: ```bash DEPLOY_DIR_SPDX ??= "${DEPLOY_DIR}/spdx/${MACHINE}" SPDXDIR ??= "${WORKDIR}/spdx" SPDXDEPLOY = "${SPDXDIR}/deploy" SPDXWORK = "${SPDXDIR}/work" SPDX_UUID_NAMESPACE ??= "sbom.openembedded.org" SPDX_NAMESPACE_PREFIX ??= "http://spdx.org/spdxdocs" ``` The `SPDXDIR` within each recipe's `WORKDIR` is the scratch space where intermediate SPDX data is assembled. `DEPLOY_DIR_SPDX` is the shared location where finalized SPDX documents are staged before being rolled up into the image-level output. The `SPDX_UUID_NAMESPACE` and `SPDX_NAMESPACE_PREFIX` are used to generate document namespaces, the globally unique URIs that identify each SPDX document. These are constructed by combining the prefix with the recipe name and a UUID generated from a hash of the recipe's content. If you are publishing SPDX documents generated by Yocto, it is recommended that you redefine `SPDX_UUID_NAMESPACE` and `SPDX_NAMESPACE_PREFIX` to a URL owned by your organization to differentiate them from other producers. ## Task 1: `do_create_spdx`, the Per-Recipe Core Task The `do_create_spdx` task is the workhorse. It runs after `do_package` (so all packaging information is available) and produces SPDX documents for the recipe and each package it generates. Here is what happens step by step. ### Step 1: Create the Recipe-Level Document The task creates an SPDX document for the recipe itself. This "recipe document" contains: - A document header with creation information (tool name, organization, timestamp) - A document namespace constructed from the recipe name and a UUID - A top-level `SPDXPackage` object representing the recipe, populated with: - `name` from the recipe name (`PN`) - `versionInfo` from the recipe version (`PV`) - `supplier` set to `Organization: OpenEmbedded` - `licenseDeclared` from the recipe's `LICENSE` variable - `SPDXID` which uniquely identifies the recipe within the document ### Step 2: Add Source Information For each entry in `SRC_URI`, the task records the download location. If `SPDX_INCLUDE_SOURCES` is enabled, it goes further: it walks the unpacked source tree (`${S}`), calculates SHA-1 and SHA-256 checksums for each file, and creates `SPDXFile` objects for them. This is expensive (which is why it is off by default), but it allows you to trace any individual source file back through the SBOM. ### Step 3: Process Each Package A single recipe may produce multiple packages (for example, `bash` produces `bash`, `bash-dbg`, `bash-doc`, and so on). For _each_ package, the task creates a separate SPDX document containing: - A new `SPDXPackage` object representing the runtime package - An `externalDocumentRef` linking back to the recipe-level document - A `GENERATED_FROM` relationship from the package back to the recipe - `SPDXFile` objects for every file installed by the package, including their checksums The checksums are calculated by walking `${PKGDEST}//`, the staging area where BitBake has already laid out each package's files. ### Step 4: Write Output The recipe document is written to `${SPDXDIR}/deploy/` as `recipe-.spdx.json`. Each package document is written as `.spdx.json`. These are then deployed to `${DEPLOY_DIR_SPDX}`. ## Task 2: `do_create_runtime_spdx`, Runtime Dependencies A second task, `do_create_runtime_spdx`, handles the dependency relationships between packages. This task exists separately because runtime dependency information is not available until all recipes have been processed (BitBake needs the full dependency graph). This task reads the `RDEPENDS` for each package and adds `DEPENDS_ON` relationships to the package's SPDX document via external document references. For example, if `bash` depends on `glibc`, the `bash` SPDX document will reference the `glibc` SPDX document and declare a dependency relationship. ## Task 3: `do_create_image_spdx`, Image Aggregation When building an image recipe, the `create-spdx-image` class adds a `do_create_image_spdx` task that aggregates all per-recipe SPDX documents into the final deliverable. Here is what the image task produces: 1. **`IMAGE-MACHINE.spdx.json`**: The top-level SPDX document describing the image. It contains a single `SPDXPackage` for the image itself, `externalDocumentRefs` pointing to every included package, and `CONTAINS` relationships linking the image package to each package. 2. **`IMAGE-MACHINE.spdx.index.json`**: An index file listing all the individual SPDX documents that make up the complete SBOM. 3. **`IMAGE-MACHINE.spdx.tar.zst`**: A compressed archive containing all individual SPDX documents (recipe-level and package-level). ## The Document-Linking Challenge in SPDX 2.2 One of the key architectural decisions in the SPDX 2.2 implementation is the use of separate _documents_ linked by external document references. Rather than producing one monolithic SPDX file, Yocto creates hundreds of individual SPDX documents (one per recipe, one per package) and links them together by SPDX external document references, then places all of the individual documents into a tarball with an index file for the final deliverable. This was a pragmatic choice driven by some limitations in SPDX 2.2. The namespace and document structure of SPDX 2.2 makes it hard to combine documents without risking ID collisions or losing relationship information. The tarball approach side-steps this by simply bundling everything together and relying on the index file for navigation. The downside is that tooling consuming these SBOMs needs to understand the document-linking model. You cannot just load a single JSON file and see everything. You need to extract the archive and follow the external document references. ## The VEX Gap in SPDX 2.2 One significant limitation of SPDX 2.2 is that it has no standard way to include vulnerability information. There is simply no mechanism in the SPDX 2.2 specification to embed VEX data or CVE assessments within the SBOM itself. This means that if you are using SPDX 2.2 and want vulnerability tracking, you need a separate workflow. You can use the `cve-check` class to generate a standalone CVE report (typically as `cve-summary.json`), but that report lives outside of the SBOM and needs to be correlated with it manually or through external tooling. You can also produce a separate VEX document (for example, in OpenVEX or CycloneDX VEX format) and distribute it alongside your SPDX 2.2 SBOM, but the two are not structurally connected. This separation is one of the primary motivations for moving to SPDX 3.0, which addresses the problem head-on. ## What the SPDX 2.2 Output Looks Like A typical package SPDX document (e.g., `bash.spdx.json`) looks something like: ```json { "SPDXID": "SPDXRef-DOCUMENT", "creationInfo": { "comment": "This document was created by analyzing packages created during the build.", "created": "2025-02-18T21:58:47Z", "creators": [ "Tool: OpenEmbedded Core create-spdx.bbclass", "Organization: OpenEmbedded ()", "Person: N/A ()" ], "licenseListVersion": "3.14" }, "dataLicense": "CC0-1.0", "documentNamespace": "http://spdx.org/spdxdocs/bash-0139ef99-a375-59f8-9ada-833f50f987d3", "externalDocumentRefs": [ { "checksum": { "algorithm": "SHA1", "checksumValue": "e9353b8e26447ef425aa740060f57411420c817a" }, "externalDocumentId": "DocumentRef-recipe-bash", "spdxDocument": "http://spdx.org/spdxdocs/recipe-bash-ad5747dc-7b5a-562d-aabf-dfb516e7095d" } ], "packages": [...], "files": [...], "relationships": [...] } ``` Each file within the package gets a detailed entry with checksums: ```json { "SPDXID": "SPDXRef-PackagedFile-bash-1", "checksums": [ { "algorithm": "SHA1", "checksumValue": "14cd85414db85903029caca727345272de829a69" }, { "algorithm": "SHA256", "checksumValue": "..." } ], "fileName": "/usr/bin/bash" } ``` --- **Series: How Yocto Generates SBOMs Behind the Scenes** - Part 1: [How Yocto Generates SBOMs Behind the Scenes](/2026/05/05/yocto-sbom-deep-dive-introduction/) - Part 2: A Deep Dive into Yocto's SPDX 2.2 Pipeline _(this post)_ - Part 3: [SPDX 3.0 in Yocto: What Changed and Why It Matters](/2026/05/19/yocto-spdx-3-0-overview/) - Part 4: VEX in the SBOM: How Yocto Embeds Vulnerability Assessments _(coming soon)_ - Part 5: Yocto SBOM in Production: Configuration, Tooling, and What's Still Missing _(coming soon)_ --- # How Yocto Generates SBOMs Behind the Scenes: A Deep Dive into SPDX 2.2 and SPDX 3.0 URL: https://sbomify.com/2026/05/05/yocto-sbom-deep-dive-introduction/ Date: 2026-05-05 Description: Yocto generates SBOMs during the build itself, not after. Part 1 of a 5-part series on how the Yocto Project builds SPDX 2.2 and SPDX 3.0 SBOMs from BitBake metadata, with first-class VEX support. If you are building embedded Linux products with the Yocto Project, you are sitting on one of the most mature and sophisticated SBOM generation pipelines in the industry, and you might not even know it. While most SBOM tools bolt onto your build system as an afterthought, Yocto's approach is fundamentally different: it generates SBOMs during the build itself, using the same metadata that drives compilation. In this post, we will take a detailed look at exactly what happens when Yocto creates an SBOM, from the moment BitBake parses a recipe to the final JSON document sitting in your deploy directory. We will cover both the established SPDX 2.2 pipeline and the newer SPDX 3.0 implementation introduced in the Styhead release, examining the key BitBake classes, tasks, and data flows that make it all work. We will also dig into how VEX (Vulnerability Exploitability eXchange) data is generated and embedded in the SBOM output, which is one of the most practically useful features of the SPDX 3.0 implementation. ## The Foundation: Why Build-Time SBOM Generation Matters Before we dig into the mechanics, it is worth understanding what differentiates Yocto's approach from more common post-build scanning tools. Most SBOM generators work by analyzing a finished artifact, whether that means scanning a container image or inspecting a filesystem. These tools are essentially doing forensic analysis, trying to reconstruct what went into a build after the fact. While these tools have their advantages, especially in the case where the original build information is no longer present, a downside is that information is inevitably lost when a build system transforms source code into final artifacts. A scanner looking at a root filesystem may have no reliable way to determine exactly which version of a source tarball was fetched, which patches were applied, what configure flags were set, or which build dependencies were present. Yocto's `create-spdx` class takes a fundamentally different approach. Because it runs as a part of the build system, it has access to all of BitBake's metadata: the recipe variables, the fetched source URIs, the applied patches, the license information extracted during `do_populate_lic`, and the exact list of files that were packaged. The SBOM is not reconstructed from artifacts; it is made from observations as a direct byproduct of the build. The core question SBOMs are trying to answer is: can we trace the binary deliverables back to the source code that produced them? When your SBOM generator is embedded in the build system, it can be much easier to answer yes to this question. ## The High-Level Architecture At a conceptual level, the Yocto SBOM pipeline works in two phases: 1. **Per-recipe SPDX generation**: As each recipe is built, additional BitBake tasks run that emit SPDX data describing that recipe: its source origins, license information, packages produced, and files contained. 2. **Image-level aggregation**: When an image recipe (like `core-image-minimal`) is built, all the per-recipe SPDX documents are collected and combined into a final deliverable that describes the complete image. This two-phase approach maps naturally to how BitBake works. Each recipe is already an isolated unit of work with well-defined inputs and outputs. The SPDX tasks simply capture this information in a structured format before the image task merges everything together. ## Enabling SBOM Generation In modern Yocto (Scarthgap and later), SPDX generation is enabled by default through `INHERIT_DISTRO`. The `create-spdx` class is inherited globally, meaning every recipe in your build automatically gets SPDX tasks added to its task graph and SPDX documents will be produced for images. For older releases (pre-Scarthgap), you needed to explicitly opt in: ```bash # In conf/local.conf INHERIT += "create-spdx" ``` To disable it on a modern release: ```bash INHERIT_DISTRO:remove = "create-spdx" ``` The class that actually gets inherited depends on which SPDX version you are targeting. In practice, there are two separate implementations: - `create-spdx-2.2.bbclass` for producing SPDX 2.2 JSON - `create-spdx-3.0.bbclass` for producing SPDX 3.0 JSON-LD Both inherit a shared base class, `spdx-common.bbclass`, which contains logic common to both versions (like source archiving and shared variable definitions). ## Why This Matters Now Regulatory pressure around software supply chain transparency is intensifying. The EU [Cyber Resilience Act](/compliance/eu-cra/) requires SBOM documentation for products placed on the EU market. The U.S. Executive Order on Improving the Nation's Cybersecurity established SBOM requirements for software sold to federal agencies. Industry standards bodies and procurement teams are following suit. In this environment, the quality of your SBOM matters. A post-build scanner that guesses at patch history is a different artifact than a build-integrated pipeline that recorded every source fetch, patch application, and package assembly as it happened. Yocto's approach was designed for exactly this level of fidelity. The next posts in this series will go deeper into how it works: the SPDX 2.2 pipeline, the newer SPDX 3.0 implementation, and how vulnerability assessment data (VEX) gets embedded directly into your SBOM output. --- **Series: How Yocto Generates SBOMs Behind the Scenes** - Part 1: How Yocto Generates SBOMs Behind the Scenes _(this post)_ - Part 2: [A Deep Dive into Yocto's SPDX 2.2 Pipeline](/2026/05/12/yocto-spdx-2-2-pipeline/) - Part 3: [SPDX 3.0 in Yocto: What Changed and Why It Matters](/2026/05/19/yocto-spdx-3-0-overview/) - Part 4: VEX in the SBOM: How Yocto Embeds Vulnerability Assessments _(coming soon)_ - Part 5: Yocto SBOM in Production: Configuration, Tooling, and What's Still Missing _(coming soon)_ --- # Announcing sbomify v26.1.0: The One Where We Switch to CalVer URL: https://sbomify.com/2026/04/02/announcing-sbomify-v26-1-0-the-one-where-we-switch-to-calver/ Date: 2026-04-02 Description: sbomify v26.1.0 introduces the CRA Compliance Wizard, switches to CalVer versioning, adds Trust Center subdomain routing, and brings full TEA v0.4.0 compatibility. If you have been following along, you may have noticed the version number just made a fairly dramatic jump, going from v0.27 straight to v26.1.0. That is not a typo. Starting with this release, sbomify is on [CalVer](https://calver.org/). The short version: a version number should tell you something useful. With CalVer, every release encodes the year it shipped. The `26` is 2026. At a glance, you can tell whether the sbomify version you are running was cut this year, last year, or two years ago. For a security and compliance product, where currency of the software you are running is itself part of the trust signal, that feels like the right thing to optimise for. That is the only "breaking change" in this release, and it only matters if you have automated version pins pointed at our images. Everything else is additive. --- ## The CRA Compliance Wizard The headline feature of v26.1.0 is the new **CRA Compliance Wizard**, a guided workflow for assessing your readiness against the [EU Cyber Resilience Act](/compliance/eu-cra/). The CRA starts biting in 2027, and the most common question we get from device manufacturers is some variation of _"how do I even know if my product is in scope, and what do I need to do about it?"_ The wizard walks you through that, step by step: 1. **Scope screening.** Figure out whether your product is in scope for the CRA at all, and if so, whether it falls under the standard, important, or critical category. 2. **Fix guidance.** When the BSI plugin flags missing or malformed fields in your SBOM, the wizard tells you exactly which fields need attention and where, rather than just handing you a failed assessment. This is the first half of a longer CRA workflow we have been building. The full Declaration of Conformity, with manufacturer signature and PDF export, lands in the very next release. But the scope screening and fix guidance are usable today, and they alone should save device teams a lot of late-night spec reading. You can open the wizard from any product page. --- ## Trust Center on Your Own Subdomain The Trust Center is where your customers go to find your SBOMs, compliance assessments, and security contact information. Until now, you could either keep it at `sbomify.com/` or attach a custom domain. v26.1.0 adds a third option: you can serve it from a **subdomain of your own domain**, like `trust.example.com`. Combined with custom-domain support, the Trust Center now feels like a native part of your own web presence rather than a third-party portal that happens to host your documents. --- ## RFC 9116 `security.txt` [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116) is the standard for telling security researchers where to send a vulnerability disclosure. It lives at a well-known path on your domain, and most coordinated-disclosure tooling looks for it automatically. With v26.1.0, every Trust Center page automatically serves a valid `security.txt` populated from your workspace's security contact details. Researchers who want to responsibly report an issue can now find out how, without having to dig through your website. --- ## Transparency Exchange API (TEA) v0.4.0 We have been contributors to the [Transparency Exchange API](https://github.com/CycloneDX/transparency-exchange-api) since it was a draft, and we shipped the first version of TEA support in v0.27 (["The One with TEA"](/2026/02/24/announcing-sbomify-v0-27-the-one-with-tea/)). The spec has continued to evolve since then, and v26.1.0 brings sbomify up to **TEA spec v0.4.0**. For you, this mostly means three things: - **Better release representation.** Components, releases, and the SBOMs attached to each release are now represented as separate concepts in your TEA endpoint, which matches how downstream consumers expect to find them. - **Build-variant support.** The same release built for different architectures or operating systems can now be represented unambiguously. - **Faster TEA endpoints.** Downstream consumers polling your TEA endpoint will see much lower latencies thanks to caching. If you are publishing SBOMs to customers or partners via TEA, this release should land transparently. If you are consuming someone else's TEA endpoint, you will get richer data without changing anything on your end. --- ## A Broader Definition of "BOM" We started with SBOMs. The industry is now also producing Hardware BOMs, AI-BOMs, ML-BOMs, and operations BOMs, and we expect more BOM types to follow. To stop bolting each one on as a separate feature, we have generalised the data model so all BOM types flow through the same workflows: the same plugins, the same Trust Center, the same TEA endpoints, the same lifecycle tracking. Your existing SBOMs keep working without any change on your part. As we add support for new BOM formats over the next few quarters, they will slot in cleanly alongside what you already have. --- ## A Few Smaller Things - **CycloneDX 1.7** uploads are now accepted, alongside all the older versions you were already using. - **Plugins moved to the sidebar.** They were previously buried under Settings and people kept asking where they were. They are now one click from anywhere. - **PostHog analytics** on the hosted platform, so we can see which features people actually reach for. Self-hosted operators can disable it. - **Hardened production images.** Our production Docker images now use Chainguard's distroless Python base, which means a smaller attack surface for self-hosted deployments. Shoutout to [@nissessenap](https://github.com/nissessenap) for doing the legwork on this migration. - **Better support for tricky network environments.** TLS with custom CA certificates and Redis password authentication are now fully supported for self-hosted deployments behind corporate proxies. --- ## Getting Started If you are on the **hosted platform**, everything is already live, no action needed. The CRA Compliance Wizard is available from any product page. To switch your Trust Center over to a subdomain, head to **Settings → Trust Center**. For **self-hosted** deployments, pull the new image and update. Take a database snapshot before you upgrade, as the BOM-model migration is irreversible. For the full technical detail, including the complete list of bug fixes, dependency upgrades, and self-hosted infrastructure changes, see the [v26.1.0 release notes on GitHub](https://github.com/sbomify/sbomify/releases/tag/v26.1.0). As always, I would love to hear your feedback. If anything about the CalVer change or the CRA Wizard is confusing, open a support ticket from inside [the app](https://app.sbomify.com) and the team will get back to you. --- # Trivy Compromise: How We Are Hardening sbomify-action URL: https://sbomify.com/2026/03/26/trivy-compromise-hardening-sbomify-action/ Date: 2026-03-26 Description: Aqua Security's Trivy was compromised twice in two weeks. Here is how we audited and hardened sbomify-action in response, and why we are moving to short-lived OIDC tokens. The last few weeks have been turbulent in the world of supply chain security. Perhaps the most high-profile compromise has been in Aqua Security's Trivy -- a widely used tool in the SBOM world, and also used in sbomify-action as one of the SBOM generation tools. Trivy has been compromised not once, but twice in the span of two weeks. The initial attack vector was a `pull_request_target` misconfiguration in Trivy's GitHub Actions workflow, which allowed the attackers to steal privileged access tokens. In recent analysis from [socket.dev](https://socket.dev/blog/trivy-docker-images-compromised), it appears to have gone even further. There is evidence that the entire Aqua Security GitHub organization was compromised by a group calling themselves TeamPCP -- a group that has been active since December 2025 and labeled the Trivy attack as "Phase 09" of a broader campaign. As part of this, the attackers were able to push compromised Docker images containing infostealer malware to Docker Hub, and even after removal, cached copies on `mirror.gcr.io` continued to be pulled by CI/CD pipelines. This is rather scary. If a _security_ company like Aqua -- with very talented security engineers -- can get fully compromised like this, we can probably assume that a lot of companies are blissfully unaware that they too have been compromised. Trivy is unlikely to have been an accidental target. It was most likely attacked because Trivy is widely used in CI/CD pipelines, making it a juicy target for a credential-stealing attack. The same group also targeted [Checkmarx KICS](https://www.checkmarx.com/), suggesting a deliberate campaign against security tooling in CI/CD pipelines. The cascading impact became clear with [litellm](https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html). Because litellm used Trivy in its CI pipeline, the compromised Trivy action exfiltrated litellm's PyPI publishing token. The attackers then used that token to publish malicious litellm packages containing a three-stage payload: credential harvesting, encrypted exfiltration, and Kubernetes lateral movement. This is the nightmare scenario of supply chain attacks -- one compromised tool cascading into downstream projects. ## How are we hardening sbomify-action? We have audited sbomify-action, and we have found no evidence of it being impacted. None of the affected versions (0.69.4, 0.69.5, 0.69.6) were ever used in sbomify-action. However, as the story is still evolving, we have decided to fully remove Trivy from sbomify-action as a precautionary measure. As of [sbomify-action 26.1.0](https://github.com/sbomify/sbomify-action/releases/tag/v26.1.0), Trivy has been dropped entirely. When the dust settles, we might bring it back, but right now we would rather err on the side of caution. We also audited our own pipelines and applied some additional hardening both in sbomify and sbomify-action. But what can we learn from the Trivy failure in general? Dan Lorenc of Chainguard shared [his view](https://www.linkedin.com/posts/danlorenc_yesterdays-trivy-supply-chain-attack-wasnt-share-7441213598770593793-DqkT/). He argues that this was not just a Trivy failure but a GitHub platform failure. Version tags in GitHub Actions are mutable -- a single force-push can silently rewrite what a tag points to. In the Trivy case, 75 version tags were rewritten to point at malicious code. This is why pinning to commit hashes rather than tags is so important. It has long been considered best practice, but many users are reluctant to do this due to the added friction. We recommend that users pin to hashed versions when using sbomify-action too. If you have run Trivy in your CI/CD pipelines recently, we also recommend rotating any secrets and tokens that were accessible during those runs as a precaution. Another observation is that many CI/CD pipelines rely on Personal Access Tokens (PAT) or other forms of long-lived API tokens. Here, we are in fact guilty of this ourselves, and we need to do better. In the coming weeks, we are going to explore adopting OpenID Connect (OIDC) in sbomify and sbomify-action to reduce this attack vector. This way, even if a token is stolen or leaked like in the case of Trivy, the damage is very limited as the token will expire soon after it has been issued. --- # SBOM Adoption on PyPI Is at 1.58%. We Can Do Better. URL: https://sbomify.com/2026/03/12/pypi-sbom-analysis/ Date: 2026-03-12 Description: We scanned 15,021 of the most popular Python packages for PEP 770 SBOMs. Only 1.58% include one, and every single SBOM is CycloneDX. Here are the full results. This wasn't a research project. We were building [TEA](/2026/03/01/why-were-bullish-on-tea/) support into [sbomify-action](https://github.com/sbomify/sbomify-action) and wanted a way to pull in real SBOM data from a package ecosystem. We chose PyPI because [PEP 770](/2026/03/05/pep-770-sboms-in-python-packages/) gives it a standardized location for SBOMs, making it the ideal candidate. ## What is PyPI-TEA? The result is [PyPI-TEA](https://github.com/sbomify/pypi-tea), a bridge between PyPI and the [Transparency Exchange API](https://transparency.dev/). You give it a PyPI [PURL](https://github.com/package-url/purl-spec), it fetches the corresponding wheel, checks the `.dist-info/sboms/` directory (per PEP 770), and returns the SBOM link and hash via the TEA API format. In practice, it acts as a caching proxy with data transformation: translating PyPI's package-embedded SBOMs into a format that any TEA-compatible client can consume. You can try it out on the [live instance](https://pypi.sbomify.com). ## How sbomify-action Uses It When [sbomify-action](https://github.com/sbomify/sbomify-action) encounters a PyPI PURL in your dependency list, it queries PyPI-TEA. If a PEP 770 SBOM exists for that package, it's included as an external reference in the generated SBOM. You can follow the implementation in [this pull request](https://github.com/sbomify/sbomify-action/pull/186). The vision is bigger than Python: do this for every binary package ecosystem, so you can traverse from a top-level SBOM all the way down to source-level SBOMs across every dependency. ## The Research When we shared PyPI-TEA with [Seth Larson](https://www.linkedin.com/in/sethmlarson/) (the author of PEP 770), he asked if we had data on adoption. We didn't, but we had all the tooling to get it. We pulled the [top PyPI packages list](https://hugovk.github.io/top-pypi-packages/) and analyzed the latest x86 wheels for the top 15,000 packages. A quick note on terminology: a _package_ is a project on PyPI (e.g. `cryptography`), while a _wheel_ is a specific build artifact for that package, often per platform and Python version. A single package can publish dozens of wheels per release. For each package, PyPI-TEA fetched the wheel, inspected the `.dist-info/sboms/` directory, validated any SBOMs found, and recorded the results. Live stats are available at [pypi.sbomify.com/stats](https://pypi.sbomify.com/stats). ## Results Here's the headline: | Metric | Count | Percentage | | -------------------- | -------------- | ---------- | | Packages with SBOMs | 238 / 15,021 | 1.58% | | Wheels with SBOMs | 5,679 / 67,151 | 8.46% | | SBOM format | CycloneDX JSON | 100% | | SPDX SBOMs found | 0 | 0% | | CycloneDX 1.5 wheels | 1,194 | | | CycloneDX 1.4 wheels | 311 | | | CycloneDX 1.6 wheels | 1 | | | Valid SBOMs | 1,469 | 97.5% | | Invalid SBOMs | 37 | 2.5% | ![PyPI SBOM adoption statistics](/assets/images/d2/pypi-sbom-stats.svg) ## Noteworthy Observations - **Not a single SPDX SBOM was found.** Every SBOM across all 15,021 packages is CycloneDX JSON. Whether this reflects tooling maturity, community preference, or both, it's a striking result. - **Most packages use older CycloneDX versions.** The overwhelming majority ship CycloneDX 1.4 or 1.5 SBOMs. The sole CycloneDX 1.6 SBOM comes from an sbomify package. - **37 invalid SBOMs, all from the same bug.** Every invalid SBOM we found traces back to the same [cargo-cyclonedx bug](https://github.com/CycloneDX/cyclonedx-rust-cargo/issues/803). This is a known issue in the Rust CycloneDX tooling. The SBOMs fail schema validation but the underlying data is otherwise reasonable. - **Wheel-level adoption is higher than package-level.** 8.46% of wheels have SBOMs vs. 1.58% of packages. This makes sense: packages that ship SBOMs tend to produce multiple platform-specific wheels, each containing its own SBOM. ## A Call to Arms for PyPI Package Maintainers 1.58% is not good enough. The Python ecosystem can do better, and the tooling is already there. If you maintain a package on PyPI, adding a PEP 770 SBOM is less than 10 lines of configuration, runs in CI, and takes under 5 minutes. Our [PEP 770 guide](/2026/03/05/pep-770-sboms-in-python-packages/) walks through the entire process. sbomify is here to help. [sbomify-action](https://github.com/sbomify/sbomify-action) generates and uploads SBOMs as part of your CI pipeline, and [sbomify](https://sbomify.com) is **free for open source projects**. Let's change these numbers together. --- # PEP 770: SBOMs Are Now a First-Class Citizen in Python Packages URL: https://sbomify.com/2026/03/05/pep-770-sboms-in-python-packages/ Date: 2026-03-05 Description: Python's PEP 770 standardizes shipping SBOMs inside packages via .dist-info/sboms/. Here's what it means and how we adopted it in two projects with minimal effort. Python now has an official standard for shipping [SBOMs](/what-is-sbom/) inside packages. [PEP 770](https://peps.python.org/pep-0770/), authored by [Seth Larson](https://www.linkedin.com/in/sethmlarson/) (Python Security Developer-in-Residence at the Python Software Foundation) and accepted in April 2025, reserves a dedicated directory inside Python packages for SBOM files. It's a small change with big implications for supply chain transparency in the Python ecosystem. ## What PEP 770 Does The core idea is simple: PEP 770 reserves a `.dist-info/sboms/` directory in Python wheels and installed packages. Any SBOM files placed there travel with the package, so when someone runs `pip install`, they get the SBOM automatically. Here's what a wheel looks like with PEP 770: ``` my_package-1.0.0.dist-info/ METADATA RECORD sboms/ my_package.cdx.json ``` A few things worth highlighting: - **Format-agnostic.** CycloneDX, SPDX, or any future format all work. The spec doesn't prescribe what goes inside the SBOM files. - **No core metadata version change needed.** PEP 770 works with existing Python packaging infrastructure. There's nothing to upgrade on the consumer side. - **Build backend support already exists.** [Hatchling](https://hatch.pypa.io/) (>= 1.28.0) supports it natively via the `sbom-files` configuration option. Other build backends are expected to follow. The [packaging specification](https://packaging.python.org/en/latest/specifications/binary-distribution-format/#the-dist-info-sboms-directory) has the full details. ## The Elephant in the Room: Ecosystem Fragmentation PEP 770 is great news for Python, but it also highlights a broader problem: every ecosystem is solving SBOM distribution independently, and the mechanisms are completely different. | Ecosystem | Discovery Mechanism | How It Works | | -------------------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Docker/OCI** | OCI Referrers API | SBOM stored as a separate OCI artifact linked to an image via the `/v2/.../referrers/` endpoint. Cryptographic verification via Cosign attestations (in-toto + Sigstore). | | **Cosign/Sigstore** | Signed attestations | `cosign attest` wraps the SBOM in an in-toto attestation with a signature. The older `cosign attach sbom` (unsigned) is deprecated. Stored in the OCI registry. | | **Python (PEP 770)** | `.dist-info/sboms/` | SBOM files embedded directly inside the wheel archive. Travels with the package, so consumers get it on `pip install`. | | **Maven/Java** | Artifact classifier | The CycloneDX plugin attaches the SBOM as a sibling artifact with a `-cyclonedx` classifier. Fetched separately from Maven Central. | | **npm/Node.js** | No standard | `npm sbom` generates an SBOM locally from the lockfile. There is no registry-level SBOM attachment. Consumers generate their own. | | **Rust/Cargo** | Fragmented | Multiple competing approaches: `cargo-sbom` (file), `cargo-auditable` (binary metadata), Cargo native `[sbom]` config (experimental). No unified standard. | Each approach makes sense within its own ecosystem's packaging model. But if you're a consumer dealing with Docker images, PyPI packages, and Maven JARs, you need three completely different mechanisms to discover SBOMs. There are also important differences in trust models. Only the Docker/Cosign approach provides cryptographic verification of SBOM authenticity. The rest rely on trust-by-proximity: you trust the SBOM because it came from the same place as the package. And npm and Rust don't even have settled standards yet. This is exactly where protocols like [TEA](/2026/03/01/why-were-bullish-on-tea/) and platforms like sbomify aim to help. They provide a unified discovery and sharing layer regardless of how the SBOM was originally shipped. Ecosystem-specific standards like PEP 770 are still a net win, though. Having a per-ecosystem standard is far better than having no standard at all, and a universal layer can aggregate across them. ## How We Adopted PEP 770 We adopted PEP 770 in two projects, and it was remarkably straightforward. ### The pyproject.toml Change If you're using hatchling as your build backend, the configuration change is minimal: ```toml [tool.hatch.build.targets.wheel] sbom-files = ["my_package.cdx.json"] ``` That's it. That single line tells hatchling to include the specified SBOM file in the `.dist-info/sboms/` directory when building the wheel. ### The Placeholder SBOM Pattern Rather than generating the SBOM at build time from scratch, we use a placeholder pattern. A minimal CycloneDX SBOM is committed to the repository: ```json { "bomFormat": "CycloneDX", "specVersion": "1.6", "version": 1, "metadata": { "component": { "type": "library", "name": "my-package", "version": "0.0.0-placeholder" } }, "components": [] } ``` This placeholder is just a skeleton. It passes validation but doesn't contain real dependency data. ### CI Integration In CI, the flow looks like this: 1. The placeholder SBOM is checked out with the code 2. [sbomify-action](https://github.com/sbomify/sbomify-action) enriches it with actual dependency information 3. The wheel is built (with hatchling picking up the now-enriched SBOM) 4. The wheel is published to PyPI The enrichment step replaces the placeholder version and populates the `components` array with real dependency data. By the time the wheel is built, the SBOM accurately reflects what's inside the package. ## See It in Action Here are the actual pull requests: - [py-libtea PR #8](https://github.com/sbomify/py-libtea/pull/8) - [sbomify-action PR #185](https://github.com/sbomify/sbomify-action/pull/185) Each PR touched just three files. No new dependencies. No complex build system modifications. ## Getting Started If you ship Python packages, here's the quick checklist: 1. **Use hatchling >= 1.28.0** (or check if your build backend supports PEP 770) 2. **Add `sbom-files` to `pyproject.toml`** to include your SBOM in the wheel 3. **Create a placeholder SBOM** (CycloneDX or SPDX) and commit it to your repo 4. **Enrich in CI** before building the wheel, so the SBOM reflects actual dependencies 5. **Verify the wheel** contains `.dist-info/sboms/` (unzip the `.whl` file and check) For a deeper dive into SBOM generation for Python projects, check out our [Python SBOM guide](/guides/python/) and our [blog post on generating SBOMs with pipdeptree and CycloneDX](/2024/07/30/generate-sboms-for-python-packages-with-pipdeptree-and-cyclonedx-py/). ## Wrapping Up PEP 770 is a milestone for Python supply chain transparency. It's the kind of standard that succeeds because it's simple, practical, and works with existing tools. [Seth Larson](https://www.linkedin.com/in/sethmlarson/) and the Python packaging community deserve real credit for getting this right. If you maintain Python packages, there's very little reason not to adopt PEP 770 today. As we showed, it works with existing CI pipelines and requires only trivial changes to your build configuration. The Python ecosystem now has a clear, standardized way to ship SBOMs, and the barrier to adoption is about as low as it gets. --- # Announcing sbomify-action v0.14: The One With Yocto URL: https://sbomify.com/2026/03/02/announcing-sbomify-action-v0-14-the-one-with-yocto/ Date: 2026-03-02 Description: sbomify-action v0.14 adds a dedicated Yocto/OpenEmbedded batch processing command, full SPDX 3.0.1 pipeline support, pipdeptree integration for Python transitive dependencies, caching for faster CI runs, and renames from github-action to sbomify-action. What started as `github-action` has outgrown its name. With v0.14, we are officially renaming the project to `sbomify-action` to reflect what it has become: a standalone CLI and multi-platform tool that happens to also work great as a GitHub Action. This release also brings dedicated Yocto/OpenEmbedded support, full SPDX 3.0.1 pipeline fidelity, and pipdeptree integration for complete Python dependency trees. --- ## From github-action to sbomify-action When we first published the project, it was a GitHub Action and nothing else. The name `github-action` made perfect sense. Then v0.11 brought PyPI distribution and CLI support. v0.13 added the configuration wizard and we presented at FOSDEM. People started running it in GitLab CI, Bitbucket Pipelines, and on their laptops. The name stopped fitting. With v0.14, the name catches up with reality. The project is now `sbomify-action` everywhere: on [PyPI](https://pypi.org/project/sbomify-action/), on GitHub, and in the documentation. The GitHub repository has moved from `sbomify/github-action` to `sbomify/sbomify-action`. If you are using the GitHub Action, your existing `sbomify/github-action@v0.14` references continue to work. GitHub handles repository renames transparently, so there is no breaking change. We recommend updating your workflow files when convenient, but there is no rush. --- ## Yocto/OpenEmbedded CLI Command Yocto and OpenEmbedded are the backbone of embedded Linux development. From industrial controllers to medical devices to automotive systems, Yocto builds the firmware that runs critical infrastructure. With the EU Cyber Resilience Act and FDA cybersecurity guidance now requiring SBOMs for these devices, embedded teams need tooling that can handle Yocto's unique SBOM output. The challenge is scale. A typical Yocto build produces hundreds of individual per-package SBOM files, one for each recipe in the image. Processing them manually, setting visibility, injecting PURLs, and uploading them to a management platform, is impractical at that volume. The new `sbomify-action yocto` command handles all of this in a single invocation: ```bash sbomify-action --token $SBOMIFY_TOKEN \ --augment --enrich \ yocto tmp/deploy/images/qemux86-64/core-image-base.rootfs.spdx.tar.zst \ --release "my-product:1.0.0" ``` It walks the Yocto SPDX output directory, processes every SBOM it finds, injects PURLs where missing, and uploads them in batch. Both SPDX 2.2 and SPDX 3 output formats from Yocto are supported. The `--visibility` flag lets you control whether uploaded SBOMs are public, internal, or private, which is important when dealing with proprietary firmware builds. For a complete walkthrough of integrating sbomify into your Yocto workflow, see our [Yocto guide](/guides/yocto/). --- ## Full SPDX 3.0.1 Pipeline Support SPDX 3.0 is the first major version bump since SPDX 2.3, and organizations preparing for CRA compliance need their tooling to handle it end to end. With v0.14, we now support SPDX 3.0.1 across all four phases of our pipeline: generation, augmentation, enrichment, and upload. If you saw our [FOSDEM talk](/2026/02/04/announcing-sbomify-action-v0-13-the-one-where-we-go-to-fosdem/) on the four-phase SBOM generation model, this is the release where SPDX 3 achieves full parity with CycloneDX across that entire pipeline. A significant part of this work was ensuring roundtrip fidelity. In earlier versions, running an SPDX 3 document through our enrichment phase could lose elements, strip type prefixes, or rename properties in ways that made the output invalid. We have fixed all of these issues. You can now generate an SPDX 3.0.1 document, enrich it with license data and metadata, and get back a valid SPDX 3.0.1 document with all original elements preserved. --- ## Pipdeptree Integration for Python A `requirements.txt` file lists your direct dependencies, but it says nothing about what those dependencies pull in. If `requests` depends on `urllib3` and `certifi`, those transitive dependencies belong in your SBOM too. Without them, your SBOM is incomplete, and any vulnerability scanner consuming it will have blind spots. sbomify-action v0.14 natively integrates [pipdeptree](https://github.com/tox-dev/pipdeptree) to automatically discover and include transitive dependencies in your Python SBOMs. When you point sbomify-action at a `requirements.txt`, it resolves the full dependency tree and ensures every package, direct or transitive, appears in the final SBOM. This completes the Python story we have been building across releases: PyPI enrichment for metadata, hash enrichment from lockfiles, and now pipdeptree for the complete dependency graph. --- ## Other Improvements - **Caching** - License databases, Trivy, and Syft are now cached between runs. (Note: Trivy has since been [removed from sbomify-action](/2026/03/26/trivy-compromise-hardening-sbomify-action/) as of v26.1.0 following its March 2026 compromise.) This significantly reduces execution time for repeat CI runs where the tooling has not changed. - **Standalone mode** - Use `--lock-file none` to run sbomify-action without a lockfile. This is useful when you want to inject additional packages or metadata into an existing SBOM without re-running dependency analysis. - **Gzip compression** - Large SBOM uploads are now automatically compressed with gzip to avoid timeouts on slow or constrained network connections. - **Configurable upload timeout** - You can now set a custom timeout for SBOM uploads, and the tool will stop early if your plan's component limit is reached. - **Updated Trivy** - Bumped from 0.68.2 to 0.69.2 for the latest vulnerability database and scanning improvements. (Note: Trivy has since been [removed from sbomify-action](/2026/03/26/trivy-compromise-hardening-sbomify-action/) as of v26.1.0 following its March 2026 compromise.) - **Updated dependencies** - All project dependencies have been bumped to their latest versions. --- ## Bug Fixes - Fixed SPDX 3 roundtrip issues: elements are now preserved during enrichment, type prefixes are restored correctly, and property names are no longer renamed - Fixed SPDX 3 version override not updating the PURL to match the new version - Fixed unsupported format/version combinations producing an unhandled ValueError instead of a clear error message - Fixed SPDX namespace uniqueness to prevent collisions and added test assertion guards - Fixed various data corruption, sanitization, and error handling edge cases --- ## Getting Started Install from PyPI: ```bash pip install sbomify-action ``` Or use the GitHub Action: ```yaml - uses: sbomify/sbomify-action@v0.14 ``` Existing `sbomify/github-action@v0.14` references continue to work thanks to the GitHub repository redirect. Check out the [full changelog on GitHub](https://github.com/sbomify/sbomify-action/compare/v0.13...v0.14) for complete details. --- # Why We're Bullish on TEA, And Why You Should Be Too URL: https://sbomify.com/2026/03/01/why-were-bullish-on-tea/ Date: 2026-03-01 Description: The Transparency Exchange API (TEA) is the missing standard for automated SBOM discovery and exchange. Here's what it is, why it matters, and why sbomify is all in. Imagine you're standing in an electronics store, holding a product in your hand. Using a TEA app, you could automatically scan the barcode, look up the manufacturer, and find out everything about that product: what's in it, whether it meets safety standards, and if there are any known issues. Simple, transparent, and completely routine. Now imagine you could do the same thing for software. And not just software: hardware, AI/ML models, SaaS services, and more. That's the promise of the **Transparency Exchange API** (TEA), and it's why we've just [added full TEA support](/2026/02/24/announcing-sbomify-v0-27-the-one-with-tea/) to sbomify. ## What Is TEA? TEA is a standard API specification for the automated exchange of supply chain transparency artifacts. It was originally developed under the [CycloneDX](https://github.com/CycloneDX/transparency-exchange-api) umbrella and is now being standardized within [ECMA TC54 Task Group 1](https://tc54.org). While TEA lives under the CycloneDX project, a critical design decision is that the specification is explicitly **format agnostic**. You can use TEA to publish and consume SPDX [SBOMs](/what-is-sbom/) just as well as CycloneDX ones. The same goes for VEX: both CycloneDX VEX and OpenVEX are supported artifact types. The goal is a universal discovery and exchange mechanism, not one tied to a single BOM format. And TEA goes well beyond just SBOMs. The specification supports any type of xBOM (SBOM, HBOM, AI/ML-BOM, SaaSBOM, CBOM), vulnerability information (VDR and VEX), attestations (CDXA), and even product lifecycle events through the Common Lifecycle Enumeration (CLE, now ECMA-428), which tracks things like end-of-life, end-of-support, and mergers and acquisitions. At the heart of TEA is the **Transparency Exchange Identifier (TEI)**, a URN scheme built on DNS. A TEI can wrap existing identifiers like EAN/UPC barcodes, PURLs, CPEs, SWIDs, or even plain UUIDs. The DNS-based design means the domain name portion resolves to a TEA server, while the identifier portion just needs to be unique within that server. This lets vendors leverage whatever product identification scheme they already use. Here's the elegant part: given a TEI, a TEA client can automatically resolve it through DNS, discover the API endpoint via the IETF `.well-known` namespace, and retrieve all transparency artifacts for that product, all without any manual intervention.
For instance, if you know a company's domain and have a software identifier (such as a PURL or CPE), you can automatically discover and retrieve the VEX/VDR file for that specific piece of software. No portal logins. No email requests. No hunting through vendor websites. ## The Problem TEA Solves If you want to understand just how broken SBOM sharing is today, look no further than CISA's own [SBOM Sharing Primer](https://www.cisa.gov/resources-tools/resources/sbom-sharing-primer). The document walks through the methods currently used in the real world, and they paint a grim picture. In one example, a consumer requests an SBOM via email, the vendor's legal and production teams verify the requester is an existing customer, then they exchange encrypted emails containing NDAs, and only after the NDA is signed does the vendor reply with the actual SBOM as an email attachment. In another example, consumers log into a vendor portal, sign an NDA within the portal, and then download the SBOM manually. These aren't strawman scenarios. These are the methods CISA documented as being in active use today. Email chains, NDAs, portal logins, manual downloads. This is the state of the art for software transparency in 2025. Now consider the TEA use case from the spec: Acme LLC buys 3,000 gadgets from a vendor and manages SBOMs for products from 14,385 vendors in their vulnerability management system. How do they get continuous, automated access to current and historical SBOMs, VEX files, and attestations from all those vendors? With today's methods, they don't. With TEA, it's a solved problem. As regulatory requirements tighten, with frameworks like the EU Cyber Resilience Act, CISA's SBOM mandates, and growing customer demands for supply chain transparency, every organization needs a way to exchange this information efficiently and automatically. TEA solves this by creating a standardized discovery and retrieval mechanism. If a vendor publishes their transparency data via a TEA-compatible server, any TEA-compatible client can find and consume it. No proprietary integrations. No bespoke APIs. No NDAs over encrypted email. Just a standard. ## TEA Is a Standard, And That's the Point This is perhaps the most important thing to understand about TEA: **it is a standard, not a product**. sbomify is one of the first platforms to support TEA, and we've been active contributors to the standard for a long time. But our implementation isn't a walled garden. We've also released [py-libtea](https://github.com/sbomify/py-libtea), an open-source Python client library for TEA. You can use it to interact with _any_ TEA-compatible server, not just sbomify. This is a powerful concept. It means that the ecosystem isn't locked into any single vendor. A company publishing their SBOMs through sbomify's TEA server can be consumed by a client built by someone else entirely. A security team using a different platform can still query our TEA endpoint, and vice versa. The standard creates interoperability, and interoperability creates adoption. Think of it like email: it doesn't matter whether you use Gmail and your colleague uses Outlook. The standard ensures the message gets through. TEA aims to do the same for software transparency. ## The Road to an International Standard TEA isn't just a community effort. It's on a clear path to becoming a formal international standard. The work is being carried out within **ECMA TC54 Task Group 1**, the same technical committee that has already standardized CycloneDX as ECMA-424, Package-URL as ECMA-427, and Common Lifecycle Enumeration as ECMA-428. The goal is to standardize TEA through ECMA, and ultimately submit it to **ISO** for international recognition. TEA is currently in **Beta 2**, with the consumer side of the API ready for implementation. The working group is actively encouraging developers to build both client and server implementations and participate in interoperability testing. Work on the publisher API will start after the 1.0 release, along with a feature called "Insights" that will allow consumers to query transparency data using an expression language without having to download and process full artifacts locally. For organizations making investments in their software supply chain transparency infrastructure today, this matters. Building on TEA means building on a foundation that's heading toward the same level of international recognition as the standards that underpin the rest of your compliance stack. ## Why We're All In We've been contributing to the TEA standard because we believe it's the missing piece of the software transparency puzzle. SBOMs are increasingly mandated, but without a standard way to _discover and exchange_ them, they sit in silos. VEX files exist, but finding the right one for the right software version from the right vendor remains a manual ordeal. TEA connects the dots. It turns software transparency from a document management problem into an automated, interoperable system, much like how that barcode in the electronics store connects a physical product to an entire ecosystem of information. We're excited about where this is heading, and we're proud to be one of the first platforms supporting it. If you want to see TEA in action, check out our [v0.27 announcement](/2026/02/24/announcing-sbomify-v0-27-the-one-with-tea/) or try out [py-libtea](https://github.com/sbomify/py-libtea) for yourself. The era of standardized software transparency exchange is here. It's time to get on board. --- # Announcing sbomify v0.27: The One with TEA URL: https://sbomify.com/2026/02/24/announcing-sbomify-v0-27-the-one-with-tea/ Date: 2026-02-24 Description: sbomify v0.27 adds full Transparency Exchange API (TEA) support, SPDX 3.0 compatibility, scoped access tokens, and improved account management. We have been working towards this release for a while. sbomify v0.27 brings full Transparency Exchange API (TEA) support, SPDX 3.0 compatibility, scoped access tokens, and a number of quality-of-life improvements across the platform. ## Transparency Exchange API (TEA) The headline feature of v0.27 is full support for the [Transparency Exchange API](https://github.com/CycloneDX/transparency-exchange-api). TEA is a CycloneDX initiative that creates a standard way for organizations to publish and exchange SBOMs. Think of it as a well-known URL where anyone can automatically discover and retrieve the SBOMs for your products, no manual sharing required. We have been involved as contributors to the TEA specification for over a year now, and we are excited to finally bring it into sbomify as a first-class feature. Here is what this means for you: each Trust Center gets its own **TEA-compatible endpoint**. Your customers and partners can point any TEA-compatible tool at your Trust Center and automatically pull the latest SBOMs for the products you share with them. To get started, enable TEA from **Settings -> Trust Center**. You will need a validated custom domain for your Trust Center, as the `.well-known/tea` discovery endpoint relies on it. As more tools adopt the TEA specification, this becomes even more powerful. You publish once, and anyone who needs your SBOMs can retrieve them on their own terms. --- ## SPDX 3.0 Support If your organization uses the SPDX format, you can now upload **SPDX 3.0** SBOMs and they will be fully recognized and validated. All compliance assessment plugins (NTIA, CISA, BSI, FDA, and GitHub Attestation) work with SPDX 3.0 out of the box. Note that vulnerability scanners (OSV and Dependency Track) do not yet support SPDX 3.0. OSV currently requires SPDX 2.x, and Dependency Track only supports CycloneDX. We have also increased the **upload size limit to 100 MB**, so larger SBOMs from complex applications or monorepos are no longer a problem. --- ## OSV and Dependency Track Plugins The **OSV scanner** and **Dependency Track scanner** have been upgraded to run as plugins. If you were already using OSV, your existing scan results have been **migrated automatically**. For Dependency Track, previous scan results were not carried over. New scans will populate fresh results under the plugin framework. Both plugins now benefit from improved reliability: if one plugin encounters an issue, it no longer affects anything else in your workspace. --- ## Scoped Access Tokens Previously, personal access tokens gave access to every workspace in your account. That is not ideal when you are using different tokens in different CI/CD pipelines. You can now **scope each token to a single workspace**. A token for your production workspace cannot touch your staging workspace. Create separate tokens for each workspace you need to access. This is especially useful if you have multiple teams or environments and want tighter control over what each integration can access. --- ## Account Management and Data Export Deleting your account now comes with a **14-day grace period**. During that window your account is disabled, but if you change your mind, you can contact support to restore it. After the grace period, everything is permanently removed, including your subscription and login credentials. Before deleting, you can **export all your personal data** via the API (`GET /api/v1/user/export`). We have also reorganized the account settings page with a clear **danger zone** section so irreversible actions are easy to find but hard to trigger by accident. --- ## Other Improvements - **Faster API responses**: Large payloads are now compressed automatically, so downloads and API calls feel snappier. - **Smoother notifications**: In-app messages now appear without interrupting what you are doing. - **Clearer navigation**: The sidebar has been reorganized with updated labels to make features easier to find. - **UI polish**: More pages have been updated to the new design language introduced in v0.26. - **Simpler billing**: Managing your subscription now takes fewer clicks. --- ## Bug Fixes - Fixed an issue where large SBOM uploads could time out. - Fixed assessment results not refreshing after re-enabling a plugin. - Fixed the workspace switcher not updating the sidebar immediately. - Fixed token permissions not updating correctly after workspace role changes. - Fixed subscription downgrades not processing correctly mid-billing cycle. --- ## Getting Started If you are on the **hosted platform**, everything is already live. No action needed. For **self-hosted** deployments, update to v0.27.0 by pulling the latest release. Check out the [full changelog on GitHub](https://github.com/sbomify/sbomify/compare/v0.26.0...v0.27.0) for complete details. We would love to hear your feedback. Reach out via [GitHub Issues](https://github.com/sbomify/sbomify/issues) or our community channels. --- # Announcing sbomify v0.26: The One Where Bootstrap Moved Out URL: https://sbomify.com/2026/02/16/announcing-sbomify-v0-26-the-one-where-bootstrap-moved-out/ Date: 2026-02-16 Description: sbomify v0.26 delivers a faster, more accessible UI, real-time dashboard updates, BSI TR-03183-2 compliance, and GDPR self-service account deletion. ## A Faster, More Accessible UI The first thing you will notice is that **sbomify feels faster**. Pages load more quickly, transitions are smoother, and the interface is more consistent throughout the application. Dark mode now works reliably across every page, and accessibility has been improved with better contrast ratios, keyboard navigation, and screen reader support. Under the hood, we rebuilt the entire frontend from scratch. But what matters to you is the result: a cleaner, more polished experience that gets out of your way. We have also redesigned the **onboarding wizard**. New users can now get from sign-up to their first SBOM upload in fewer steps, with clearer guidance at each stage. --- ## Real-Time Dashboard Updates Until now, checking whether an assessment finished or a new SBOM was uploaded meant manually refreshing the page. That changes with v0.26. Your dashboard now updates in **real-time**. When a teammate uploads an SBOM, a compliance assessment completes, or a component status changes, you see it immediately. No more guessing, no more stale data. From your perspective, it just works. --- ## BSI TR-03183-2 Compliance If you operate in Germany or sell into the German market, sbomify now supports automated compliance checking against **BSI TR-03183-2** – the German Federal Office for Information Security's technical guideline for SBOM quality and completeness. Like our other compliance plugins, you can enable it in **Settings -> Plugins**. Once enabled, every SBOM upload is assessed automatically against the BSI requirements. This plugin also introduces a **dependency system** for compliance plugins. Plugins can now build on each other, so related standards share foundational checks rather than duplicating work. This means more consistent results across overlapping compliance frameworks. --- ## GDPR Self-Service Account Deletion Under GDPR, you have the right to delete your account and all associated data. Previously, this required contacting our support team and waiting for manual processing. With v0.26, you can **delete your own account** directly from your profile settings. No tickets, no waiting. Your data is removed in accordance with our data retention policy. --- ## Fine-Grained Access Control You can now control who sees what at a more granular level. Set **component visibility** to restrict which components are visible to which roles, and control **document-level access** to limit who can view specific SBOM documents. This is particularly useful for organizations sharing SBOMs externally through the **Trust Center**. You can make some components public for customers and partners while keeping internal components private – all from the same workspace. --- ## Other Improvements - **Version field on Releases** – You can now track release versions aligned with the Transparency Exchange API (TEA), making it easier to correlate SBOMs with specific product versions. - **Improved error tracking** – We catch and resolve issues faster now, often before you notice them. - **Custom login experience** – The login page now uses a branded sbomify theme with better password validation feedback, so you know exactly what is needed when setting or changing your password. - **Zero-downtime deployments** – Deployments no longer cause brief interruptions. Updates happen seamlessly in the background, so the platform is always available. --- ## Bug Fixes - Fixed an issue where compliance assessments could fail on retry. - Fixed IP address capture in NDA audit trails. - Improved error responses for duplicate SBOM uploads – the API response now includes an error code for easier debugging in CI/CD pipelines. --- ## Infrastructure For self-hosted users, note that sbomify v0.26 now requires **Python 3.13**. We have also updated several key dependencies, including gunicorn 25.x, ruff 0.15.x, and bandit 1.9.3. Check the full changelog for upgrade notes before updating your deployment. --- ## Getting Started If you are on the **hosted platform**, everything is already live – no action needed. For **self-hosted** deployments, update to v0.26.0 by pulling the latest release. Check out the [full changelog on GitHub](https://github.com/sbomify/sbomify/compare/v0.25.1...v0.26.0) for complete details. We would love to hear your feedback – reach out via [GitHub Issues](https://github.com/sbomify/sbomify/issues) or our community channels. --- # The Role of SBOMs in Cybersecurity: From Visibility to Vulnerability Response URL: https://sbomify.com/2026/02/08/sbom-cybersecurity-role/ Date: 2026-02-08 Description: Learn how SBOMs strengthen cybersecurity through component visibility, vulnerability management, incident response, and compliance with EO 14028, EU CRA, and more. A [Software Bill of Materials](/what-is-sbom/) (SBOM) is a foundational cybersecurity tool that provides a complete, machine-readable inventory of every component in a software product. In cybersecurity, SBOMs answer the question that every security team must be able to answer: _what is in our software?_ Without this visibility, vulnerability management, incident response, and compliance are all reactive at best and impossible at worst. ## Why SBOMs Matter for Cybersecurity Modern software is assembled from open source and third-party components. A typical application consists of [70-90% open source code](https://www.linux.com/training-tutorials/estimating-total-number-linux-contributors-approach-using-linus-law/) drawn from package registries. Each component is a potential entry point for attackers – whether through known vulnerabilities, compromised packages, or abandoned libraries. SBOMs make the composition of software visible. This visibility is the prerequisite for every other cybersecurity activity involving third-party code: you cannot patch what you do not know you are running. ## SBOMs and Vulnerability Management Vulnerability management is the cybersecurity function that benefits most directly from SBOMs. The workflow connects component inventories to threat intelligence, creating a continuous monitoring capability. ### The Problem Without SBOMs When a new [CVE](/2025/12/18/cve-vulnerability-explained/) is disclosed, organizations without SBOMs must: 1. Manually determine which components are used across all applications 2. Check each application's dependency files (if accessible) 3. Search container images, build artifacts, and deployment manifests 4. Aggregate findings across teams and environments This manual process can take days or weeks. During that time, the vulnerability may be actively exploited. ### The Solution With SBOMs With SBOMs generated and ingested into a management platform like [sbomify](https://sbomify.com) or [OWASP Dependency-Track](https://dependencytrack.org/): 1. New CVE is published to vulnerability databases 2. Platform automatically matches the CVE to SBOM component inventories 3. Affected products and versions are identified within seconds 4. Alerts are sent to the responsible teams 5. Remediation begins immediately This automated approach reduces the response window from days to minutes. The difference is especially critical for vulnerabilities listed in the [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) – those confirmed to be actively exploited in the wild. ## Incident Response: The Log4Shell Case Study The Log4Shell vulnerability ([CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)) in December 2021 is the defining example of why SBOMs matter for cybersecurity. Apache Log4j was a ubiquitous Java logging library used as both a direct and transitive [dependency](/2026/01/29/what-is-a-dependency-in-software/) in millions of applications. **Organizations with SBOMs** queried their component inventories and identified affected systems within minutes. They knew exactly which applications used Log4j, at which versions, and in which environments. **Organizations without SBOMs** spent weeks manually auditing codebases, scanning containers, and contacting vendors to determine exposure. Some discovered Log4j in applications they did not even know existed in their environment. Log4Shell became the single most cited argument for SBOM adoption. It demonstrated that in a crisis, the ability to answer "which of our systems are affected?" is not optional – it is a core cybersecurity capability. ## SBOMs and the Compliance Landscape Multiple cybersecurity regulations and frameworks now require or strongly recommend SBOMs. This reflects the growing consensus that software transparency is essential for security. ### United States - **[Executive Order 14028](/compliance/eo-14028/)** ("Improving the Nation's Cybersecurity", 2021) directed federal agencies to require SBOMs from software vendors. It established SBOMs as a baseline expectation for government software procurement. - **[CISA Minimum Elements](/compliance/cisa-minimum-elements/)** defines the recommended fields for SBOMs, building on the [NTIA minimum elements](/compliance/ntia-minimum-elements/). - **[NIST SP 800-53](/compliance/nist-800-53/)** includes supply chain risk management controls (SR family) that SBOMs help satisfy, particularly SR-4 (Provenance) and CM-8 (Component Inventory). - **[NIST SP 800-171](/compliance/nist-800-171/)** (Rev 3) added a Supply Chain Risk Management family (03.17) relevant to DoD contractors handling Controlled Unclassified Information. - **[FDA Medical Device Guidance](/compliance/fda-medical-device/)** requires SBOMs for medical device premarket submissions. ### European Union - **[EU Cyber Resilience Act](/compliance/eu-cra/)** (CRA) requires manufacturers of products with digital elements to identify and document components, with SBOMs as the practical mechanism. - **[NIS2 Directive](/compliance/eu-nis2/)** requires supply chain security measures for essential and important entities. ### Industry Standards - **[PCI DSS 4.0](/compliance/pci-dss/)** requires maintaining an inventory of third-party software components for payment card environments. For a complete comparison of compliance frameworks, see our [compliance overview](/compliance/). ## SBOMs Across the Cybersecurity Lifecycle SBOMs support cybersecurity at every stage: ### Prevention - **Dependency auditing.** SBOMs reveal the full dependency tree including [transitive dependencies](/2026/01/29/what-is-a-dependency-in-software/), enabling teams to identify and replace risky components before deployment. - **License compliance.** SBOMs document the license of every component, preventing license conflicts that can create legal exposure. See our [GPL](/2025/12/22/gpl-license-guide/), [MIT](/2026/01/22/mit-license-guide/), and [Apache 2.0](/2026/01/07/apache-license-2-guide/) guides for license-specific details. - **Policy enforcement.** SBOM-based tools can block deployments that include components with known critical vulnerabilities or prohibited licenses. ### Detection - **Continuous vulnerability monitoring.** SBOMs ingested into platforms like OWASP Dependency-Track are continuously matched against the [NVD](https://nvd.nist.gov/), [OSV](https://osv.dev/), and [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). See our [SBOM scanning guide](/2026/02/01/sbom-scanning-vulnerability-detection/) for implementation details. - **[CVSS](/2026/02/05/what-is-cvss-vulnerability-scoring/)-based triage.** SBOMs paired with vulnerability data enable automated severity assessment, prioritizing critical and high-severity issues. ### Response - **Rapid impact assessment.** Query SBOM repositories to immediately identify which products and environments contain an affected component. - **Targeted remediation.** Knowing exactly where a vulnerable component is deployed enables precise patching rather than broad emergency measures. - **VEX communication.** Use Vulnerability Exploitability eXchange (VEX) documents to communicate whether a reported vulnerability actually affects your product. ### Recovery - **Audit trail.** Retained SBOMs provide a historical record of what was deployed at any point in time, supporting post-incident analysis and regulatory reporting. - **Rebuild verification.** SBOMs document the components that should be present, enabling verification that rebuilt or patched software matches the intended composition. ## Getting Started If you are beginning your SBOM journey: 1. **Start generating SBOMs.** Use our [language-specific SBOM guides](/guides/) to generate SBOMs for your projects in [CycloneDX](https://cyclonedx.org/) or [SPDX](https://spdx.dev/) format. See our [SBOM formats comparison](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/) for format guidance. 2. **Automate generation in CI/CD.** Integrate SBOM generation into your build pipeline using the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/), which handles generation, enrichment, and augmentation in one step. Standalone tools like [Syft](https://github.com/anchore/syft) are also available (note: we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) and have removed it from sbomify-action). See our [SBOM generation tools comparison](/2026/01/26/sbom-generation-tools-comparison/). 3. **Set up vulnerability monitoring.** Use [sbomify](https://sbomify.com) for integrated monitoring (built-in OSV and Dependency-Track scanning), or deploy a standalone [OWASP Dependency-Track](https://dependencytrack.org/) instance for continuous monitoring. 4. **Establish a management process.** Define how SBOMs are stored, versioned, and distributed. See our [SBOM management guide](/2026/01/18/sbom-management-best-practices/). 5. **Map to compliance requirements.** Identify which compliance frameworks apply to your organization and ensure your SBOM process meets their requirements. See our [compliance overview](/compliance/). For a comprehensive list of tools across the SBOM lifecycle, see our [resources page](/resources/). ## Frequently Asked Questions ### How do SBOMs improve cybersecurity? SBOMs improve cybersecurity by providing component-level visibility into software. This visibility enables automated vulnerability detection (matching components against CVE databases), rapid incident response (immediately identifying affected systems when a new vulnerability is disclosed), continuous compliance monitoring (tracking regulatory requirements), and informed risk management (understanding the full dependency chain and its associated risks). ### Are SBOMs required for cybersecurity compliance? SBOMs are required or strongly recommended by multiple frameworks: U.S. Executive Order 14028 requires them for federal software procurement, the EU Cyber Resilience Act requires them for products with digital elements, FDA guidance requires them for medical device submissions, and NIST SP 800-53/800-171 include supply chain controls that SBOMs help satisfy. See our [compliance overview](/compliance/) for a framework-by-framework breakdown. ### How did Log4Shell demonstrate the need for SBOMs? When the Log4Shell vulnerability (CVE-2021-44228) was disclosed in December 2021, organizations with SBOMs identified affected systems in minutes by querying their component inventories. Organizations without SBOMs spent weeks manually auditing codebases and scanning infrastructure. This stark contrast made Log4Shell the most commonly cited example of why SBOMs are essential for cybersecurity incident response. ### What is the relationship between SBOMs and vulnerability management? SBOMs provide the component inventory that vulnerability management depends on. Without knowing what components are in your software, you cannot determine which vulnerabilities affect you. SBOMs ingested into monitoring platforms are continuously matched against vulnerability databases, enabling automated detection and alerting. This transforms vulnerability management from a periodic manual exercise into a continuous automated process. ### How do I start using SBOMs for cybersecurity? Start by generating SBOMs for your applications using tools like Syft, ~~Trivy~~ (compromised March 2026), or language-specific generators. Automate generation in your CI/CD pipeline. Ingest SBOMs into a monitoring platform like OWASP Dependency-Track for continuous vulnerability scanning. Define remediation SLAs based on CVSS severity and KEV status. See our [SBOM guides](/guides/) for step-by-step instructions. --- # What Is CVSS? Understanding Vulnerability Severity Scoring URL: https://sbomify.com/2026/02/05/what-is-cvss-vulnerability-scoring/ Date: 2026-02-05 Description: Learn what CVSS is, how vulnerability severity scores are calculated, the differences between CVSS v3.1 and v4.0, and how to use CVSS with KEV and SBOMs for prioritization. The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the severity of software vulnerabilities. Published and maintained by [FIRST.org](https://www.first.org/cvss/) (the Forum of Incident Response and Security Teams), CVSS produces a numerical score from 0.0 to 10.0 that represents the severity of a vulnerability. The score is accompanied by a vector string that describes the specific characteristics used to calculate it. CVSS is the most widely used vulnerability scoring system in the world – the [National Vulnerability Database](https://nvd.nist.gov/) (NVD) publishes CVSS scores for virtually every [CVE](/2025/12/18/cve-vulnerability-explained/) entry. ## How CVSS Scores Work A CVSS score is not a single number derived from one input. It is calculated from a set of metrics organized into metric groups. Each metric describes a specific characteristic of the vulnerability, and the combination produces the final score. ### CVSS v3.1 Metric Groups CVSS v3.1 (the most widely deployed version as of early 2026) defines three metric groups: **Base Score (0.0-10.0)** – Represents the intrinsic qualities of the vulnerability that are constant over time and across environments. This is the score most commonly reported. - **Attack Vector (AV):** How the vulnerability is exploited – Network (remote), Adjacent (local network), Local (requires local access), or Physical (requires physical access) - **Attack Complexity (AC):** Whether specialized conditions must exist for exploitation – Low or High - **Privileges Required (PR):** What level of privilege an attacker needs – None, Low, or High - **User Interaction (UI):** Whether a user must take action for exploitation – None or Required - **Scope (S):** Whether exploitation impacts resources beyond the vulnerable component – Unchanged or Changed - **Confidentiality Impact (C):** Impact on data confidentiality – None, Low, or High - **Integrity Impact (I):** Impact on data integrity – None, Low, or High - **Availability Impact (A):** Impact on system availability – None, Low, or High **Temporal Score** – Adjusts the Base Score based on factors that change over time, such as whether an exploit is available, whether a patch exists, and confidence in the vulnerability report. **Environmental Score** – Adjusts the score based on the specific environment where the vulnerability exists, allowing organizations to reflect their own infrastructure context. ### Severity Ratings CVSS scores map to qualitative severity ratings: | Score Range | Severity | | ----------- | -------- | | 0.0 | None | | 0.1 - 3.9 | Low | | 4.0 - 6.9 | Medium | | 7.0 - 8.9 | High | | 9.0 - 10.0 | Critical | ### Reading a CVSS Vector String The CVSS vector string encodes all the metric values in a compact format. For example: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` – Score: 10.0 (Critical) This describes [Log4Shell (CVE-2021-44228)](https://nvd.nist.gov/vuln/detail/CVE-2021-44228): exploitable over the network (AV:N), with low attack complexity (AC:L), requiring no privileges (PR:N) and no user interaction (UI:N), with changed scope (S:C), and high impact on confidentiality, integrity, and availability. Compare with: `CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N` – Score: 1.8 (Low) This describes a vulnerability requiring local access, high complexity, high privileges, user interaction, and producing only low confidentiality impact – a much less severe threat. ## CVSS v4.0 [CVSS v4.0](https://www.first.org/cvss/v4-0/) was released by FIRST.org in November 2023 and represents a significant evolution of the framework. While CVSS v3.1 remains the most widely used version (the NVD still primarily publishes v3.1 scores), v4.0 adoption is increasing. ### Key Changes in v4.0 **New metric groups.** CVSS v4.0 restructures the scoring into four metric groups: - **Base** – Intrinsic vulnerability characteristics (similar to v3.1) - **Threat** – Replaces the Temporal group; focused on exploit maturity - **Environmental** – Organization-specific adjustments - **Supplemental** – Additional context that does not affect the score (e.g., safety impact, automatable, recovery) **Removed Scope metric.** The Scope (S) metric from v3.1, which was widely considered confusing and inconsistently applied, has been removed. Its effects are captured through refined impact metrics. **Attack Requirements.** A new metric (AT) distinguishes between vulnerabilities that require specific deployment conditions and those that do not, providing more nuance than v3.1's Attack Complexity. **Multiple score types.** CVSS v4.0 defines specific score types: - CVSS-B: Base score only - CVSS-BT: Base + Threat - CVSS-BE: Base + Environmental - CVSS-BTE: Base + Threat + Environmental (most complete) ### v3.1 vs. v4.0 | Aspect | CVSS v3.1 | CVSS v4.0 | | ---------------------- | ----------------------------- | ----------------------------------------- | | **Metric groups** | Base, Temporal, Environmental | Base, Threat, Environmental, Supplemental | | **Scope metric** | Present (Unchanged/Changed) | Removed | | **Attack granularity** | Attack Complexity (Low/High) | Attack Complexity + Attack Requirements | | **Score types** | One composite score | Four named score types (B, BT, BE, BTE) | | **NVD support** | Fully supported | Adoption in progress | | **Adoption status** | Industry standard | Growing adoption | Both versions produce scores on the same 0.0-10.0 scale with the same severity ratings. A score of 9.8 means roughly the same severity in both versions, though the exact metrics contributing to that score may differ. ## CVSS in Vulnerability Prioritization CVSS scores are essential for vulnerability prioritization, but they should not be the only signal. ### CVSS Alone Is Not Enough A CVSS Base Score measures theoretical severity – how bad the vulnerability _could_ be if exploited. It does not tell you: - **Whether it is being exploited.** The [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) answers this question. A CVSS 7.5 vulnerability that is actively exploited (KEV-listed) is more urgent than a CVSS 9.8 vulnerability with no known exploits. - **Whether you are affected.** A critical vulnerability in a component you do not use, or in a code path your application never reaches, represents zero actual risk to you. - **Your deployment context.** A network-exploitable vulnerability in an internet-facing application is far more urgent than the same vulnerability in a completely internal tool. ### A Combined Prioritization Approach Effective vulnerability prioritization uses CVSS together with other signals: | Signal | Source | What It Tells You | | ----------- | --------------------------------------------------------------------------------- | ----------------------------------------------- | | **CVSS** | NVD, vendor advisories | Theoretical severity (how bad it could be) | | **KEV** | [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) | Whether it is actively exploited | | **EPSS** | [FIRST.org EPSS](https://www.first.org/epss/) | Probability of exploitation in the next 30 days | | **SBOM** | Your component inventory | Whether you use the affected component | | **Context** | Your deployment architecture | Whether the vulnerability is reachable | For a practical prioritization framework that combines CVSS with KEV status and deployment context, see our [KEV guide](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/). ## CVSS and SBOMs [SBOMs](/what-is-sbom/) enable CVSS-based vulnerability management at scale. Without an SBOM, you need to manually determine which components are in your software before you can look up their CVSS scores. With an SBOM, this process is automated. ### The Workflow 1. **Generate SBOMs** for your applications using tools from our [SBOM generation guides](/guides/) 2. **Ingest SBOMs** into a monitoring platform like [sbomify](https://sbomify.com) or [OWASP Dependency-Track](https://dependencytrack.org/) 3. **Automatic matching** – the platform matches your components against vulnerability databases and retrieves CVSS scores 4. **Prioritize** using CVSS severity combined with KEV status and your deployment context 5. **Remediate** according to your defined SLAs ### CVSS in SBOM Formats [CycloneDX](https://cyclonedx.org/) includes a `vulnerabilities` array that can carry CVSS scores directly within the SBOM or an associated VEX document. This allows a single document to contain both the component inventory and its known vulnerabilities with scores. [SPDX 3.0](https://spdx.dev/) supports vulnerability information through its Security profile, which can reference CVSS data. For more on SBOM scanning and vulnerability detection, see our [SBOM scanning guide](/2026/02/01/sbom-scanning-vulnerability-detection/). ## Frequently Asked Questions ### What is CVSS? The Common Vulnerability Scoring System (CVSS) is an open framework maintained by FIRST.org for scoring the severity of software vulnerabilities on a scale of 0.0 to 10.0. Scores are calculated from metrics describing the vulnerability's attack vector, complexity, required privileges, and potential impact. CVSS scores are published by the NVD for virtually every CVE and are the most widely used measure of vulnerability severity. ### What is a good CVSS score? Lower CVSS scores indicate less severe vulnerabilities. A score of 0.0 means no impact. Scores of 0.1-3.9 are Low severity, 4.0-6.9 are Medium, 7.0-8.9 are High, and 9.0-10.0 are Critical. However, "good" depends on context – even a Medium vulnerability is urgent if it is being actively exploited (listed in the CISA KEV catalog) or in an internet-facing system. ### What is the difference between CVSS v3.1 and v4.0? CVSS v4.0 introduces refined metric groups (Base, Threat, Environmental, Supplemental), removes the controversial Scope metric, adds an Attack Requirements metric for more granular exploitability assessment, and defines four named score types (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE). Both versions use the same 0.0-10.0 scale and severity ratings. CVSS v3.1 remains more widely deployed; v4.0 adoption is growing. ### How should I prioritize vulnerabilities? Do not rely on CVSS scores alone. Combine CVSS severity with CISA KEV status (is it actively exploited?), EPSS probability (how likely is exploitation?), your SBOM (do you use the affected component?), and deployment context (is the vulnerable component exposed?). A KEV-listed vulnerability at CVSS 7.5 often warrants faster action than a non-exploited vulnerability at CVSS 9.8. ### What is EPSS? The Exploit Prediction Scoring System (EPSS) is a model maintained by FIRST.org that estimates the probability that a CVE will be exploited in the wild in the next 30 days. EPSS scores range from 0 to 1 (0% to 100% probability). Used alongside CVSS and KEV, EPSS provides a forward-looking signal for vulnerability prioritization. --- # Announcing sbomify-action v0.13: The One Where We Go to FOSDEM URL: https://sbomify.com/2026/02/04/announcing-sbomify-action-v0-13-the-one-where-we-go-to-fosdem/ Date: 2026-02-04 Description: sbomify-action v0.13 brings hash enrichment from lockfiles, an interactive configuration wizard, Conan Center integration for C/C++, and improved NTIA compliance with supplier fields and PURL generation from VCS URLs. We timed the sbomify-action v0.13 release for [FOSDEM 2026](https://fosdem.org/2026/schedule/event/UYTGWA-sbom-generation/), where we presented on CRA-ready SBOM generation. ## FOSDEM 2026: CRA-Ready SBOMs This past weekend, we presented at FOSDEM in the Software Bill of Materials devroom. The talk covers a four-phase SBOM generation model addressing the EU's Cyber Resilience Act requirements: authoring, augmenting, enriching, and signing SBOMs to exceed minimal compliance standards. It includes a demo of an open-source workflow using sbomify-action, helping teams avoid compliance gaps as the CRA timeline approaches. If you missed it, you can watch the full talk below. You can also find the talk on the [FOSDEM schedule](https://fosdem.org/2026/schedule/event/UYTGWA-sbom-generation/). --- ## What's New in v0.13 ### Breaking Changes **Python 3.11+ now required** - We have increased the minimum Python version from 3.10 to 3.11 to take advantage of the built-in `tomllib` module for TOML parsing. If you are running sbomify-action locally, ensure you have Python 3.11 or later installed. --- ## New Features ### Hash Enrichment from Lockfiles A common gap in SBOMs is missing cryptographic hashes for components. Many SBOM generation tools do not extract hashes, even when they are available in lockfiles. The new hash enrichment subsystem automatically extracts cryptographic hashes from your lockfiles and adds them to SBOM components. This improves SBOM quality and supports integrity verification workflows. **Supported lockfiles:** - Cargo.lock (Rust) - package-lock.json (npm) - Pipfile.lock (Pipenv) - pnpm-lock.yaml (pnpm) - poetry.lock (Poetry) - pubspec.lock (Dart/Flutter) - uv.lock (uv) - yarn.lock (Yarn) ### Interactive Configuration Wizard Getting started with sbomify-action is now easier than ever. The new `sbomify init` command walks you through an interactive wizard to create your `sbomify.json` configuration file. Answer a few questions about your project, and the wizard generates a working configuration. ```bash sbomify-action init ``` ### Conan Center Enrichment C/C++ projects using Conan now get automatic metadata enrichment from the Conan Center API. For each package, we fetch: - License information - Author details - Homepage URL - Repository URL - Package description This follows our enrichment-first philosophy: even if your SBOM generation tool produces sparse output, sbomify-action fills in the gaps from authoritative sources. ### Component Supplier Field (NTIA Compliance) NTIA's minimum elements for SBOMs include supplier information. Previously, some tools would populate this with package authors, which is not quite right. The supplier should be the distribution platform, not the individual who wrote the code. Components now include a `supplier` field populated with the distribution platform: - PyPI for Python packages - npm for JavaScript packages - crates.io for Rust packages - And so on for other ecosystems This improves compliance with NTIA SBOM requirements. ### PURL Generation from VCS URL For SPDX SBOMs, the main package component now generates a PURL from the VCS (Version Control System) URL when no explicit PURL is available. This ensures better NTIA compliance by providing a unique identifier for your software, even when traditional package manager PURLs are not applicable. ### Organization Data from Contact Profile API The sbomify API integration now extracts organizational data from the contact_profile structure. This means your SBOMs can include accurate manufacturer and supplier organization details from your sbomify account settings. --- ## Improvements ### Lifecycle Property Standardization We have updated lifecycle properties to use the official CycloneDX taxonomy. If you are using lifecycle data in your SBOMs, the property names have changed: | Old Property | New Property | | ----------------- | --------------------------------------------- | | `cle:releaseDate` | `cdx:lifecycle:milestone:generalAvailability` | | `cle:eos` | `cdx:lifecycle:milestone:endOfSupport` | | `cle:eol` | `cdx:lifecycle:milestone:endOfLife` | This aligns with the CycloneDX specification and improves interoperability with other tools. ### Better Error Handling We have made significant improvements to error handling throughout the tool: - **ToolNotAvailableError** - Graceful handling when SBOM generation tools are missing, with clear instructions on what to install - **Improved "component not found" messages** - More context about what failed and why - **Better diagnostic info** - SBOM generation errors now include more details for debugging - **Path expansion errors** - Now include the file name and searched paths - **CLI flag detection** - Helpful error when a file path looks like a CLI flag (a common typo) - **Stdout capture** - Tools that output errors to stdout instead of stderr are now handled correctly --- ## Getting Started Install from PyPI: ```bash pip install sbomify-action ``` Or use the GitHub Action: ```yaml - uses: sbomify/sbomify-action@v0.13 ``` Check out the [full changelog on GitHub](https://github.com/sbomify/sbomify-action/compare/v0.12...v0.13) for complete details. --- # SBOM Scanning: How to Detect Vulnerabilities in Your Software Components URL: https://sbomify.com/2026/02/01/sbom-scanning-vulnerability-detection/ Date: 2026-02-01 Description: Learn how SBOM scanning works, which tools to use, how to set up continuous vulnerability monitoring, and how to act on scan results effectively. SBOM scanning is the process of analyzing a [Software Bill of Materials](/what-is-sbom/) to identify known vulnerabilities, license issues, and other risks in the components listed within it. Rather than re-analyzing source code or container images for each new vulnerability disclosure, SBOM scanning matches the component inventory already documented in your SBOM against vulnerability databases. This makes it possible to continuously monitor your entire software portfolio for newly disclosed threats without rescanning every artifact. ## How SBOM Scanning Works The SBOM scanning workflow has three stages: ### 1. Component Identification The scanner reads the SBOM and extracts component identifiers – primarily [Package URLs (purls)](https://github.com/package-url/purl-spec) and [CPEs](https://nvd.nist.gov/products/cpe) – along with version information. These identifiers are the keys used to look up vulnerability data. A purl like `pkg:npm/lodash@4.17.20` tells the scanner exactly which package (lodash), from which registry (npm), at which version (4.17.20) to check. The more precise your SBOM's identifiers, the more accurate the scan results. ### 2. Database Matching The scanner queries one or more vulnerability databases to find known [CVEs](/2025/12/18/cve-vulnerability-explained/) affecting the identified components. Major databases include: - **[National Vulnerability Database (NVD)](https://nvd.nist.gov/)** – The U.S. government's comprehensive CVE database with [CVSS](/2026/02/05/what-is-cvss-vulnerability-scoring/) severity scores - **[OSV (Open Source Vulnerabilities)](https://osv.dev/)** – Google's database focused on open source package vulnerabilities, with ecosystem-specific advisory data - **[GitHub Advisory Database](https://github.com/advisories)** – Community-curated advisories with package-manager-specific versioning - **[CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)** – The list of vulnerabilities with confirmed [active exploitation](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) ### 3. Result Reporting The scanner produces a report listing each vulnerability found, typically including: - The affected component and version - The CVE identifier - The CVSS severity score - Whether the vulnerability is listed in the CISA KEV catalog - Fix availability (which version resolves the vulnerability) - Advisory details and references ## SBOM Scanning Tools ### Grype [Grype](https://github.com/anchore/grype) is an open source vulnerability scanner from Anchore that accepts SBOMs as direct input. It is designed to work with SBOMs generated by [Syft](https://github.com/anchore/syft) but supports any CycloneDX or SPDX SBOM. ```bash # Scan an SBOM file grype sbom:./my-sbom.cdx.json # Scan an SBOM with specific output format grype sbom:./my-sbom.spdx.json -o table ``` Grype matches against multiple vulnerability databases including the NVD, OSV, and ecosystem-specific advisories. It runs as a CLI tool, making it straightforward to integrate into CI/CD pipelines. ### OWASP Dependency-Track [OWASP Dependency-Track](https://dependencytrack.org/) is a continuous SBOM analysis platform. Unlike CLI scanners that run once, Dependency-Track ingests SBOMs into a persistent database and continuously re-evaluates them as new vulnerabilities are published. Key capabilities: - Ingests SBOMs in CycloneDX and SPDX formats via API or web upload - Monitors against NVD, OSV, GitHub Advisories, and other sources - Provides a dashboard showing risk across your entire portfolio - Sends notifications when new vulnerabilities affect your components - Supports policy management for automated risk evaluation Dependency-Track is particularly valuable for [SBOM management](/2026/01/18/sbom-management-best-practices/) at scale – it maintains a centralized view of all your software components and their vulnerability status. ### OSV-Scanner [OSV-Scanner](https://google.github.io/osv-scanner/) from Google uses the [OSV database](https://osv.dev/) and supports SBOM input. It focuses on open source package vulnerabilities with ecosystem-specific version matching. ```bash # Scan an SBOM osv-scanner scan source -S my-sbom.cdx.json ``` ### Trivy > **Note (March 2026):** Following two successful supply chain attacks on Trivy, we no longer consider it safe for CI/CD use. We have removed Trivy from sbomify-action as of v26.1.0. See [Trivy Compromise: How We Are Hardening sbomify-action](/2026/03/26/trivy-compromise-hardening-sbomify-action/) for details. [Trivy](https://github.com/aquasecurity/trivy) can scan SBOMs for vulnerabilities in addition to its source directory and container image scanning capabilities. ```bash # Scan an SBOM trivy sbom my-sbom.cdx.json ``` ### sbomify [sbomify](https://sbomify.com) integrates vulnerability monitoring directly into its SBOM management platform. When you upload SBOMs to sbomify, they are automatically scanned against [Google OSV](https://osv.dev/) for known vulnerabilities. For organizations needing deeper analysis, sbomify also integrates with [OWASP Dependency-Track](https://dependencytrack.org/). This means generation, storage, scanning, and distribution happen in a single workflow rather than requiring separate tools. For a broader tool comparison, see our [SBOM generation tools guide](/2026/01/26/sbom-generation-tools-comparison/) and [resources page](/resources/). ## Setting Up Continuous Monitoring Point-in-time scanning catches vulnerabilities known at scan time but misses those disclosed afterward. Continuous monitoring solves this by repeatedly matching your SBOMs against updated vulnerability databases. ### The Workflow 1. **Generate SBOMs** in your CI/CD pipeline with every build using tools from our [SBOM generation guides](/guides/) 2. **Ingest SBOMs** into a monitoring platform ([sbomify](https://sbomify.com), OWASP Dependency-Track, or equivalent) 3. **Configure data sources** – connect the platform to NVD, OSV, KEV, and ecosystem-specific advisory feeds 4. **Set up notifications** – alert the appropriate team when new vulnerabilities are found in their components 5. **Define policies** – establish severity thresholds and SLAs for remediation ### Why Continuous Monitoring Matters New CVEs are published daily. A component that was clean when you deployed it may have a critical vulnerability disclosed a week later. Without continuous monitoring, you will not know until the next scheduled scan – which may be too late. The [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) is updated multiple times per week with vulnerabilities that are actively being exploited. Continuous monitoring against KEV ensures you are alerted immediately when a component in your portfolio is under active attack. ## Acting on Scan Results Scanning without action is overhead. An effective vulnerability response process turns scan results into remediation. ### Prioritization Not all vulnerabilities require immediate action. Prioritize based on: 1. **KEV status.** If the vulnerability is in the [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/), it is being actively exploited – treat it as urgent regardless of CVSS score. 2. **CVSS severity.** Critical (9.0-10.0) and High (7.0-8.9) vulnerabilities warrant faster response. See our [CVSS guide](/2026/02/05/what-is-cvss-vulnerability-scoring/) for scoring details. 3. **Exploitability.** Is there a public exploit? Is the vulnerability exploitable remotely without authentication? 4. **Deployment context.** Is the affected component in an internet-facing application or an internal tool? Is the vulnerable code path actually reachable? 5. **Fix availability.** If a patched version exists, updating is straightforward. If no fix is available, you need a workaround or compensating control. ### Remediation The most common remediation is updating the vulnerable component to a fixed version. For transitive dependencies, this may require updating the direct dependency that pulls it in – see our [dependency guide](/2026/01/29/what-is-a-dependency-in-software/) for details on dependency trees. When an update is not immediately possible: - Apply vendor-recommended mitigations or workarounds - Implement compensating controls (WAF rules, network restrictions) - Document the accepted risk with a timeline for permanent remediation ### VEX (Vulnerability Exploitability eXchange) VEX is a standardized way to communicate whether a vulnerability in a component actually affects a specific product. A VEX statement might declare that CVE-2024-XXXX in lodash "does not affect" your application because the vulnerable function is never called. VEX reduces false positives by distinguishing between "this component has a known CVE" and "this CVE actually impacts our product." Both [CycloneDX](https://cyclonedx.org/) and [OpenVEX](https://github.com/openvex) support VEX documents that can be consumed by scanning tools to suppress known non-exploitable findings. ## Best Practices 1. **Scan SBOMs, not just source code.** SBOM scanning catches vulnerabilities in deployed components, including OS-level packages in [containers](/2026/01/03/container-security-best-practices/) that do not appear in your source repository. 2. **Monitor continuously.** Do not rely on scan-at-build-time alone. Use a platform like [sbomify](https://sbomify.com) or OWASP Dependency-Track for ongoing monitoring against updated vulnerability feeds. 3. **Prioritize with KEV.** Use the CISA KEV catalog as a top-priority signal. KEV-listed vulnerabilities are confirmed to be actively exploited and should be remediated first. 4. **Define SLAs.** Establish clear timelines for remediation based on severity and exploitability. Example: KEV-listed critical vulnerabilities within 48 hours; critical non-KEV within 2 weeks; high severity within 30 days. 5. **Use VEX to reduce noise.** When a vulnerability does not affect your product (because the vulnerable code path is not reachable), document this with a VEX statement rather than suppressing the alert entirely. 6. **Automate the pipeline.** Generate SBOMs automatically in CI/CD, ingest them into monitoring automatically, and route alerts to the right teams automatically. Manual steps create gaps. ## Frequently Asked Questions ### What is SBOM scanning? SBOM scanning is the process of analyzing a Software Bill of Materials to identify known vulnerabilities, license issues, and other risks in the components it documents. Scanners match SBOM component identifiers (purls, CPEs) against vulnerability databases like the NVD and OSV to find known CVEs. This enables continuous vulnerability monitoring without repeatedly scanning source code or container images. ### What tools scan SBOMs for vulnerabilities? Leading SBOM scanning tools include [sbomify](https://sbomify.com) (integrated platform with built-in OSV and Dependency-Track scanning), Grype (CLI scanner from Anchore), OWASP Dependency-Track (standalone monitoring platform), OSV-Scanner (Google's open source scanner), and Trivy (comprehensive security scanner from Aqua Security, though we [no longer consider it safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise). Grype is best for CI/CD pipeline integration; sbomify and Dependency-Track are best for ongoing portfolio monitoring. ### How often should I scan my SBOMs? SBOMs should be scanned continuously, not just at build time. New vulnerabilities are disclosed daily, and a component that was clean at build time may have a critical CVE disclosed afterward. Use a continuous monitoring platform that automatically re-evaluates your SBOMs as vulnerability databases are updated. ### What is the difference between SBOM scanning and SCA? [Software Composition Analysis (SCA)](/2026/01/11/software-composition-analysis-sca/) scans source code, dependency files, or binaries to identify components and their vulnerabilities. SBOM scanning takes an already-generated SBOM as input and matches its components against vulnerability databases. SCA produces the inventory; SBOM scanning monitors it over time. They are complementary – SCA for discovery, SBOM scanning for continuous monitoring. ### What is VEX? VEX (Vulnerability Exploitability eXchange) is a standardized format for communicating whether a known vulnerability in a component actually affects a specific product. A VEX statement can declare that a CVE "does not affect," "is under investigation," or "is affected" in your product. VEX reduces false positives from SBOM scanning by distinguishing theoretical vulnerability from actual impact. --- # What Is a Dependency in Software? A Beginner's Guide URL: https://sbomify.com/2026/01/29/what-is-a-dependency-in-software/ Date: 2026-01-29 Description: Learn what software dependencies are, the difference between direct and transitive dependencies, how dependency trees work, and how SBOMs document them. A dependency in software is any external component – a library, framework, module, or package – that your application relies on to function. When you import a package from npm, add a library from PyPI, or include a Maven artifact, you are adding a dependency. Dependencies allow developers to reuse tested, maintained code rather than writing everything from scratch. Modern applications are built overwhelmingly from dependencies: studies consistently show that [70-90% of a typical application consists of open source components](https://www.linux.com/training-tutorials/estimating-total-number-linux-contributors-approach-using-linus-law/). ## Direct vs. Transitive Dependencies The most important distinction in dependency management is between direct and transitive dependencies. **Direct dependencies** are the packages your project explicitly declares. These appear in your dependency manifest – `package.json` for JavaScript, `requirements.txt` or `pyproject.toml` for Python, `pom.xml` for Java, `go.mod` for Go, `Cargo.toml` for Rust, and similar files for other ecosystems. You chose these packages, you decided which versions to use, and you are (presumably) aware of their purpose in your application. **Transitive dependencies** are the dependencies of your dependencies. When you add package A to your project, and package A depends on packages B and C, and package B depends on package D, then B, C, and D are all transitive dependencies of your project. You may never have heard of packages B, C, or D, yet they are running in your application and their vulnerabilities are your vulnerabilities. ### The Scale of Transitive Dependencies The ratio of transitive to direct dependencies is often surprising: | Ecosystem | Typical direct dependencies | Typical total (including transitive) | | ---------- | --------------------------- | ------------------------------------ | | JavaScript | 20-50 | 200-1,500+ | | Python | 10-30 | 50-200 | | Java/Maven | 10-30 | 100-500 | | Go | 10-30 | 50-300 | | Rust/Cargo | 10-30 | 100-400 | A JavaScript project with 30 direct dependencies may pull in over 1,000 transitive packages through the npm dependency tree. Each of those packages is code running in your application, with its own maintenance status, license, and vulnerability history. ## The Dependency Tree A dependency tree (or dependency graph) is the complete set of relationships between a project and all of its dependencies, both direct and transitive. Visualizing this tree reveals the full scope of what your application depends on. ``` my-application ├── express@4.18.2 (direct) │ ├── body-parser@1.20.2 (transitive) │ │ ├── bytes@3.1.2 │ │ └── iconv-lite@0.4.24 │ │ └── safer-buffer@2.1.2 │ ├── cookie@0.5.0 │ └── ... ├── lodash@4.17.21 (direct) └── axios@1.6.2 (direct) └── follow-redirects@1.15.3 (transitive) ``` In this example, `express`, `lodash`, and `axios` are direct dependencies. Everything nested beneath them is transitive. The vulnerability in `safer-buffer` – four levels deep – is just as dangerous as one in `express` itself. ## Why Dependencies Matter for Security Dependencies are the primary attack surface for most applications. Several high-profile incidents illustrate the risks: ### Vulnerable Dependencies The [Log4Shell vulnerability](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) ([CVE-2021-44228](/2025/12/18/cve-vulnerability-explained/)) in the Apache Log4j logging library affected millions of Java applications. Many organizations did not know they used Log4j because it was a transitive dependency – pulled in by frameworks and libraries they did depend on directly. ### Compromised Dependencies The [XZ Utils backdoor](https://nvd.nist.gov/vuln/detail/CVE-2024-3094) demonstrated that attackers can spend years gaining trust in a legitimate open source project before inserting malicious code. When a dependency is compromised, every application that uses it is affected. ### Abandoned Dependencies Dependencies that are no longer maintained represent a growing risk. When a [CVE](/2025/12/18/cve-vulnerability-explained/) is found in an unmaintained package, there may be no one to produce a patch. The component stays vulnerable indefinitely unless consumers fork it or find an alternative. ### Dependency Confusion Dependency confusion attacks exploit the way package managers resolve names. An attacker publishes a malicious package to a public registry with the same name as a private internal package. If the package manager checks the public registry first (or alongside) the private one, it may install the attacker's package instead. For a deeper discussion of supply chain attacks, see our [software supply chain management guide](/2025/12/26/software-supply-chain-management/). ## Lock Files Lock files are a critical tool for dependency management. They record the exact versions of every dependency (direct and transitive) that were resolved during installation, ensuring that subsequent installations produce identical results. | Ecosystem | Lock File | Manifest File | | ---------- | ------------------- | ---------------- | | JavaScript | `package-lock.json` | `package.json` | | Python | `poetry.lock` | `pyproject.toml` | | Rust | `Cargo.lock` | `Cargo.toml` | | Go | `go.sum` | `go.mod` | | Ruby | `Gemfile.lock` | `Gemfile` | | PHP | `composer.lock` | `composer.json` | Without a lock file, the same manifest can resolve to different dependency versions on different machines or at different times. This non-determinism is both a reliability risk (builds may break unpredictably) and a security risk (a newly published malicious version could be pulled in automatically). Lock files should always be committed to version control. They are the source of truth for what is actually installed in your project. ## How SBOMs Document Dependencies A [Software Bill of Materials](/what-is-sbom/) provides a complete, machine-readable inventory of every component in your software, including all transitive dependencies. This is essential for security because: 1. **Full visibility.** An SBOM documents every package in the dependency tree, not just the direct dependencies listed in your manifest file. This is the only reliable way to know everything running in your application. 2. **Vulnerability matching.** Once you have an SBOM, platforms like [sbomify](https://sbomify.com) can continuously monitor every component against vulnerability databases. CLI tools like [Grype](https://github.com/anchore/grype) and [OSV-Scanner](https://google.github.io/osv-scanner/) provide point-in-time scanning, while [OWASP Dependency-Track](https://dependencytrack.org/) offers standalone continuous monitoring. See our [SBOM scanning guide](/2026/02/01/sbom-scanning-vulnerability-detection/) for details and our [resources page](/resources/) for a complete list of tools. 3. **Dependency relationship mapping.** Both [CycloneDX](https://cyclonedx.org/) and [SPDX](https://spdx.dev/) support dependency relationship data, documenting which components depend on which others. This lets you trace the path from a vulnerable transitive dependency back to the direct dependency that brought it in. 4. **License tracking.** Each dependency carries a license. SBOMs document these licenses, enabling automated compliance checking. A single [GPL-licensed](/2025/12/22/gpl-license-guide/) transitive dependency can trigger copyleft obligations for your entire application. SBOM generation tools like the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/), [Syft](https://github.com/anchore/syft), and [Trivy](https://github.com/aquasecurity/trivy) (which we [no longer consider safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/)) analyze lock files and build artifacts to capture the full dependency tree. For language-specific SBOM generation instructions, see our [SBOM guides](/guides/). ## Best Practices 1. **Always use and commit lock files.** Lock files ensure reproducible builds and prevent unexpected dependency changes. Review lock file diffs in pull requests to catch unintended dependency updates. 2. **Audit your dependency tree regularly.** Use `npm audit`, `pip-audit`, `cargo audit`, or equivalent tools to check for known vulnerabilities. Do not limit auditing to direct dependencies – transitive vulnerabilities are equally dangerous. 3. **Minimize your dependency footprint.** Every dependency is a potential risk vector. Before adding a new package, evaluate whether the functionality justifies the added surface area. Prefer well-maintained libraries with active security response processes. 4. **Generate and monitor SBOMs.** Automate SBOM generation in your CI/CD pipeline and monitor SBOMs continuously against vulnerability databases. This catches newly disclosed CVEs in your existing dependencies. See our [SBOM management guide](/2026/01/18/sbom-management-best-practices/). 5. **Keep dependencies up to date.** Apply security updates promptly, especially for dependencies listed in the [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/). Use tools like Dependabot or Renovate to automate update pull requests. 6. **Review dependency changes.** Treat dependency updates in pull requests with the same scrutiny as code changes. A bumped version may introduce new transitive dependencies, change licenses, or include unexpected modifications. ## Frequently Asked Questions ### What is a dependency in software? A dependency is any external component – a library, framework, module, or package – that your application relies on to function. Dependencies are declared in manifest files (like `package.json` or `requirements.txt`) and installed from package registries (like npm or PyPI). They allow developers to reuse existing code rather than building everything from scratch. ### What is a transitive dependency? A transitive dependency is a dependency of your dependency. If your project depends on package A, and package A depends on package B, then B is a transitive dependency of your project. Transitive dependencies are often invisible to developers but can contain vulnerabilities, restrictive licenses, or outdated code. They typically outnumber direct dependencies by a factor of 5-30x depending on the ecosystem. ### What is a dependency tree? A dependency tree (or dependency graph) is the complete hierarchy of all dependencies in a project, showing both direct and transitive relationships. It reveals the full set of code that your application actually uses at runtime. SBOM generation tools analyze dependency trees to produce complete component inventories. ### Why are dependencies a security risk? Dependencies are a security risk because each one introduces code that your team did not write and may not audit. Known vulnerabilities in dependencies (CVEs) are a primary attack vector – incidents like Log4Shell affected millions of applications through a single widely-used library. Dependencies can also be intentionally compromised (as in the XZ Utils backdoor), abandoned by maintainers, or used in dependency confusion attacks. ### What is a lock file? A lock file records the exact resolved versions of all dependencies (direct and transitive) in a project. Examples include `package-lock.json` (npm), `poetry.lock` (Python), and `Cargo.lock` (Rust). Lock files ensure reproducible builds – the same versions are installed every time, on every machine. They should always be committed to version control. --- # SBOM Generation Tools Compared: Syft, Trivy, cdxgen, and More URL: https://sbomify.com/2026/01/26/sbom-generation-tools-comparison/ Date: 2026-01-26 Description: Compare the leading SBOM generation tools – Syft, Trivy, cdxgen, Microsoft SBOM Tool, and CycloneDX CLI – covering format support, ecosystems, and CI/CD integration. SBOM generation tools analyze your software projects and produce machine-readable [Software Bills of Materials](/what-is-sbom/) in standard formats like [CycloneDX](https://cyclonedx.org/) and [SPDX](https://spdx.dev/). These tools scan dependency manifests, lock files, container images, and sometimes compiled binaries to create a complete inventory of every component in your software. Choosing the right tool depends on your programming language ecosystem, deployment model, output format requirements, and CI/CD integration needs. ## Why SBOM Generation Tools Matter SBOM generation is the foundation of the [SBOM lifecycle](/resources/). Without accurate generation, downstream activities – vulnerability monitoring, license compliance, supply chain risk management – have nothing to work with. Manual SBOM creation is not practical. A typical modern application has hundreds of dependencies, many of them [transitive](/2026/01/29/what-is-a-dependency-in-software/). Automated tooling is the only reliable way to produce complete, accurate SBOMs at the pace of modern software development. The SBOM generation tool landscape has matured significantly. Several open source tools now support dozens of package ecosystems, multiple output formats, and integration with CI/CD pipelines and container registries. ## Tool Comparison The following comparison covers the most widely used open source SBOM generation tools as of early 2026. ### Overview | Tool | Maintainer | Output Formats | Input Sources | License | | ----------------------------------------------------------------- | --------------------- | --------------------------- | -------------------------------------------------------------------------------------- | ---------- | | **[sbomify](https://sbomify.com)** | sbomify | CycloneDX, SPDX | Source directories, lock files, container images (via best-fit generator + enrichment) | Apache 2.0 | | **[Syft](https://github.com/anchore/syft)** | Anchore | CycloneDX, SPDX, Syft JSON | Source directories, container images, archives | Apache 2.0 | | **[Trivy](https://github.com/aquasecurity/trivy)** | Aqua Security | CycloneDX, SPDX, Trivy JSON | Source directories, container images, VMs, K8s | Apache 2.0 | | **[cdxgen](https://github.com/CycloneDX/cdxgen)** | CycloneDX / AppThreat | CycloneDX | Source directories, container images | Apache 2.0 | | **[Microsoft SBOM Tool](https://github.com/microsoft/sbom-tool)** | Microsoft | SPDX | Source directories, build outputs | MIT | | **CycloneDX CLI** | CycloneDX | CycloneDX | Varies (ecosystem-specific) | Apache 2.0 | | **SPDX Tools** | Linux Foundation | SPDX | Varies (ecosystem-specific) | Apache 2.0 | ### sbomify [sbomify](https://sbomify.com) is an open source SBOM platform that covers the full SBOM lifecycle: generation, augmentation, enrichment, storage, distribution, and vulnerability monitoring. Importantly, sbomify is not a standalone SBOM generator – the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) automatically selects the best generation tool for your ecosystem (such as Syft, cdxgen, or the CycloneDX ecosystem plugins) and then improves the quality of the generated SBOM through enrichment and augmentation. This means you get the most accurate generation for your stack, combined with metadata improvements that raw generators don't provide – all in one step. **Strengths:** - Uses the best underlying generator for each ecosystem, then enriches and augments the output - Automatic metadata augmentation: adds supplier, manufacturer, and contact information to meet [NTIA minimum elements](/compliance/ntia-minimum-elements/) - Enrichment from 11+ data sources (deps.dev, ClearlyDefined, PyPI, crates.io, LicenseDB, and more) for license, hash, and lifecycle data - Native CI/CD integration via [GitHub Action](https://github.com/sbomify/sbomify-action/), GitLab CI, and Bitbucket Pipelines - Outputs both CycloneDX and SPDX formats - Built-in vulnerability monitoring via Google OSV and OWASP Dependency-Track integration - [Trust Center](/features/trust-center/) for distributing SBOMs and compliance documents to customers - Supports all major ecosystems: Python, JavaScript, Java, Go, Rust, Ruby, PHP, .NET, Swift, Dart, Elixir, Scala, C/C++, Docker, Terraform, Yocto **Considerations:** - Not a standalone generator – it wraps and improves the output of other generation tools - Full platform features (Trust Center, vulnerability monitoring) require the cloud service or self-hosted deployment **Basic usage (GitHub Actions):** ```yaml - uses: sbomify/sbomify-action@master env: LOCK_FILE: package-lock.json OUTPUT_FILE: sbom.cdx.json ENRICH: true UPLOAD: false ``` See our [CI/CD guide](/guides/ci-cd/) for GitHub Actions, GitLab CI, and Bitbucket Pipelines examples. ### Syft [Syft](https://github.com/anchore/syft) is Anchore's open source SBOM generation tool. It supports a broad range of package ecosystems and can scan source directories, container images (both local and from registries), and archive files. **Strengths:** - Wide ecosystem support: APK, DEB, RPM, npm, PyPI, Maven, Go, Rust, Ruby, PHP, and more - Container image scanning with layer-by-layer analysis - Outputs CycloneDX, SPDX 2.3, and its own Syft JSON format - Pairs naturally with [Grype](https://github.com/anchore/grype) for vulnerability scanning - Active development with frequent releases **Considerations:** - Does not resolve dependency trees from source manifests as deeply as some language-specific tools - No native vulnerability scanning (use Grype separately) **Basic usage:** ```bash # Scan a directory syft dir:/path/to/project -o cyclonedx-json # Scan a container image syft registry:nginx:latest -o spdx-json ``` ### Trivy > **March 2026 update:** Trivy was [compromised twice in two weeks](/2026/03/26/trivy-compromise-hardening-sbomify-action/) in a coordinated supply chain attack that cascaded into downstream projects like litellm. We no longer consider Trivy safe for CI/CD pipelines and have removed it from sbomify-action as of v26.1.0. If you currently use Trivy, we strongly recommend evaluating alternatives like Syft or cdxgen. [Trivy](https://github.com/aquasecurity/trivy) is Aqua Security's comprehensive security scanner. While best known for vulnerability scanning, Trivy also generates SBOMs and can scan a wider range of targets than most dedicated SBOM tools. **Strengths:** - Combined SBOM generation and vulnerability scanning in a single tool - Scans source directories, container images, VM images, Kubernetes clusters, and IaC files - Outputs CycloneDX and SPDX - Detects both OS-level packages and language-specific dependencies - Extensive ecosystem: npm, PyPI, Maven, Go, Rust, Ruby, NuGet, and more **Considerations:** - **Supply chain risk (March 2026):** Trivy was [compromised twice in two weeks](/2026/03/26/trivy-compromise-hardening-sbomify-action/) and the attack cascaded into downstream projects. We have removed Trivy from sbomify-action and no longer consider it safe for CI/CD use - SBOM generation is one feature among many; some SBOM-specific features may lag behind dedicated tools - Output verbosity can vary between scan targets **Basic usage:** ```bash # Generate SBOM from a directory trivy fs /path/to/project --format cyclonedx --output sbom.json # Generate SBOM from a container image trivy image nginx:latest --format spdx-json --output sbom.spdx.json ``` ### cdxgen [cdxgen](https://github.com/CycloneDX/cdxgen) (CycloneDX Generator) is the official CycloneDX SBOM generation tool, maintained by the AppThreat team under the CycloneDX project. It focuses on deep analysis of language-specific dependency trees. **Strengths:** - Deep dependency resolution for many ecosystems (Java, JavaScript, Python, Go, Rust, .NET, Ruby, PHP, Swift, and more) - Generates evidence-based SBOMs with call graph analysis for supported languages - Supports SBOM signing and attestation workflows - Active development with rapid feature additions - Can generate SBOMs from container images and binary files **Considerations:** - CycloneDX output only (no native SPDX support) - Requires Node.js runtime - Some advanced features (call graph analysis) require language-specific toolchain setup **Basic usage:** ```bash # Scan a project directory cdxgen -o sbom.json /path/to/project # Scan a container image cdxgen -t docker -o sbom.json nginx:latest ``` ### Microsoft SBOM Tool [Microsoft SBOM Tool](https://github.com/microsoft/sbom-tool) is Microsoft's open source tool for SBOM generation, designed for integration with build systems and CI/CD pipelines. **Strengths:** - Designed for CI/CD integration with structured build output support - Supports npm, NuGet, PyPI, Maven, Go, Rust, and more - Validates generated SBOMs against NTIA minimum element requirements - Integrates with Azure DevOps and GitHub Actions **Considerations:** - SPDX 2.2 output only (no CycloneDX support) - Requires .NET runtime - Ecosystem support is narrower than Syft or Trivy **Basic usage:** ```bash # Generate SBOM from build output sbom-tool generate -b /path/to/build -bc /path/to/source -pn my-app -pv 1.0.0 -ps my-org ``` ### CycloneDX Ecosystem Tools The CycloneDX project maintains a collection of language-specific SBOM generation libraries and CLI tools. These are purpose-built for individual ecosystems and produce highly accurate results for their target languages. | Language | Tool | | ----------- | ------------------------------------------------------------------------------- | | Java/Maven | [cyclonedx-maven-plugin](https://github.com/CycloneDX/cyclonedx-maven-plugin) | | Java/Gradle | [cyclonedx-gradle-plugin](https://github.com/CycloneDX/cyclonedx-gradle-plugin) | | JavaScript | [cyclonedx-node-npm](https://github.com/CycloneDX/cyclonedx-node-npm) | | Python | [cyclonedx-python](https://github.com/CycloneDX/cyclonedx-python) | | .NET | [cyclonedx-dotnet](https://github.com/CycloneDX/cyclonedx-dotnet) | | Go | [cyclonedx-gomod](https://github.com/CycloneDX/cyclonedx-gomod) | | Rust | [cyclonedx-rust-cargo](https://github.com/CycloneDX/cyclonedx-rust-cargo) | | PHP | [cyclonedx-php-composer](https://github.com/CycloneDX/cyclonedx-php-composer) | **Strengths:** - Deepest possible integration with each language's package manager - Most accurate dependency resolution for the target ecosystem - Native CycloneDX output **Considerations:** - Language-specific: you need a different tool for each ecosystem in your stack - CycloneDX format only - Variable feature sets between language implementations For a complete listing of language-specific tools and guides, see our [SBOM generation guides](/guides/) and [resources page](/resources/). ## Choosing a Tool ### Single vs. Multi-Ecosystem If your organization uses a single language ecosystem, a language-specific CycloneDX plugin or SPDX tool will produce the most accurate results. If you work across multiple ecosystems (which most organizations do), a multi-ecosystem tool like [sbomify](https://sbomify.com), Syft, ~~Trivy~~ ([compromised](/2026/03/26/trivy-compromise-hardening-sbomify-action/)), or cdxgen provides consistency and simplifies CI/CD integration. If you also need SBOM management, vulnerability monitoring, and distribution, sbomify provides these in an integrated platform rather than requiring separate tools. ### Format Requirements If you need CycloneDX output, all tools listed here support it except Microsoft SBOM Tool. If you need SPDX output, Syft and Microsoft SBOM Tool support it natively (Trivy also supports SPDX but we [no longer consider it safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/)). If you need both formats, Syft is the most flexible. For format conversion, the [CycloneDX CLI](https://github.com/CycloneDX/cyclonedx-cli) can convert between formats. See our [SBOM formats comparison](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/) for help choosing a format. ### Container Image Support For [container security](/2026/01/03/container-security-best-practices/) workflows, Syft provides strong container image scanning with layer-by-layer analysis (Trivy also supports this but we [no longer consider it safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/)). cdxgen also supports container images. Microsoft SBOM Tool does not scan container images directly. For Docker-specific SBOM generation instructions, see our [Docker SBOM guide](/guides/docker/). ### CI/CD Integration All major SBOM generation tools can be integrated into CI/CD pipelines. The [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) provides a streamlined way to generate and manage SBOMs in GitHub workflows. Syft provides an official GitHub Action and supports integration with most CI/CD platforms. Note: we [no longer consider Trivy safe for CI/CD use](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following two successful supply chain attacks in March 2026. ## Benchmarking SBOM Tools Different tools may produce different results for the same project – varying in the number of components detected, the accuracy of version information, and the completeness of transitive dependency resolution. The [sbom-benchmarks repository](https://github.com/sbomify/sbom-benchmarks) provides a framework for comparing SBOM generation tools against reference projects, along with examples of how to run each tool. Benchmarking against your own projects is the best way to evaluate which tool produces the most accurate and complete results for your specific technology stack. ## Best Practices 1. **Generate SBOMs from resolved dependencies.** Use lock files and build outputs rather than unresolved manifests. Lock files capture exact versions including transitive dependencies; manifests may contain version ranges that resolve differently in different environments. 2. **Automate in CI/CD.** Integrate SBOM generation into your build pipeline so every release automatically produces an SBOM. See our [language-specific guides](/guides/) for setup instructions. 3. **Validate generated SBOMs.** Use validation tools like the [CycloneDX Validator](https://github.com/CycloneDX/cyclonedx-core-java) or [SPDX Online Tools](https://tools.spdx.org/app/validate/) to ensure your SBOMs conform to the specification. Invalid SBOMs may be rejected by consumers or analysis tools. 4. **Combine tools for container SBOMs.** A language-specific tool may miss OS-level packages in your container image. Use both a language-specific tool (for precise application dependency resolution) and a container scanner (for OS packages from the base image) to produce a complete picture. 5. **Benchmark against your stack.** Run multiple tools against your actual projects and compare the results. The best tool for a Python project may not be the best tool for a Java project. 6. **Feed SBOMs into monitoring.** SBOM generation is the starting point, not the end. Ingest generated SBOMs into a management platform like [sbomify](https://sbomify.com) for integrated vulnerability monitoring, or use [OWASP Dependency-Track](https://dependencytrack.org/) for standalone analysis. See our [SBOM management guide](/2026/01/18/sbom-management-best-practices/) for the full lifecycle. ## Frequently Asked Questions ### What are SBOM generation tools? SBOM generation tools are software that analyzes your projects – source code, dependency files, container images, or compiled binaries – and produces a machine-readable Software Bill of Materials in a standard format like CycloneDX or SPDX. Leading standalone generators include Syft (Anchore), ~~Trivy~~ (Aqua Security, [compromised March 2026](/2026/03/26/trivy-compromise-hardening-sbomify-action/)), cdxgen (CycloneDX), Microsoft SBOM Tool, and language-specific CycloneDX plugins. Platforms like [sbomify](https://sbomify.com) wrap the best generator for your ecosystem and then enrich and augment the output for higher quality SBOMs. ### What is the best SBOM generation tool? There is no single best tool – the right choice depends on your ecosystems, format requirements, and workflow. For an integrated platform that selects the best generator for your ecosystem and then enriches, augments, and manages the output, [sbomify](https://sbomify.com) covers the full lifecycle. For multi-ecosystem coverage with both CycloneDX and SPDX support as a standalone CLI tool, Syft is the most versatile option. For deep language-specific analysis, CycloneDX ecosystem plugins and cdxgen provide the most accurate results. For SPDX-only workflows integrated with Azure DevOps, Microsoft SBOM Tool is purpose-built. Note: we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following two successful supply chain attacks in March 2026. ### How do I generate an SBOM? Install an SBOM generation tool (Syft, ~~Trivy~~ ([compromised](/2026/03/26/trivy-compromise-hardening-sbomify-action/)), or cdxgen are common starting points for CLI use), point it at your project directory or container image, and specify your desired output format. For example: `syft dir:. -o cyclonedx-json > sbom.json`. For production use, integrate SBOM generation into your CI/CD pipeline using the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/), which handles generation, enrichment, and augmentation in one step. See our [language-specific SBOM guides](/guides/) for detailed instructions. ### What format should my SBOM be in? Choose CycloneDX for security-focused use cases and SPDX for license compliance focus. For EU CRA compliance via BSI TR-03183-2, you need CycloneDX 1.6+ or SPDX 3.0.1+. Most other compliance frameworks accept both formats. See our [SBOM formats comparison](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/) for detailed guidance. ### How do I validate an SBOM? Use format-specific validation tools: the CycloneDX Validator for CycloneDX SBOMs and SPDX Online Tools for SPDX SBOMs. Validation checks structural correctness, required fields, and specification conformance. Additionally, tools like [sbomqs](https://github.com/interlynk-io/sbomqs) can score SBOM quality beyond basic structural validity. --- # Announcing sbomify v0.25: The One with Attestations URL: https://sbomify.com/2026/01/23/announcing-sbomify-v0-25-the-one-with-attestations/ Date: 2026-01-23 Description: sbomify v0.25 introduces GitHub Attestation verification via Sigstore/cosign, SPDX 2.3 export, product lifecycle tracking, and compliance badges. Software supply chain security is not just about knowing what is in your software. It is about proving that knowledge is authentic and has not been tampered with. With v0.25, sbomify takes a significant step forward by introducing **attestation verification**, allowing you to cryptographically verify the provenance of your SBOMs. ## GitHub Attestation Plugin The headline feature of v0.25 is our new **GitHub Attestation Plugin**. This plugin verifies SBOM attestations using [Sigstore](https://www.sigstore.dev/) and cosign, the same infrastructure that powers supply chain security across the open source ecosystem. When you generate an SBOM using GitHub Actions, you can sign it using GitHub's built-in attestation capability. The sbomify GitHub Attestation Plugin then verifies these signatures automatically when you upload your SBOM. If the attestation is valid, you get cryptographic proof that the SBOM was generated by your CI/CD pipeline and has not been modified since. The plugin includes automatic retry logic to handle transient network issues when communicating with the Sigstore transparency log. This ensures reliable verification even under less-than-ideal network conditions. This is our first attestation plugin, building on the [plugin architecture](https://github.com/sbomify/sbomify/blob/master/docs/ADR/ADR-003.md) we introduced in v0.24. We plan to add support for additional attestation formats including in-toto in future releases. --- ## SPDX 2.3 Export sbomify has supported uploading SBOMs in both CycloneDX and SPDX formats for a while. With v0.25, we are adding the ability to **download aggregated SBOMs in SPDX 2.3 format**. You can now download aggregated SBOMs for releases, projects, and products in either CycloneDX or SPDX format directly from the UI. This gives you flexibility when working with tools and partners that prefer one format over the other. Internally, we continue to use CycloneDX as our canonical format, but the SPDX export ensures you can meet requirements regardless of which standard your ecosystem uses. --- ## Product Lifecycle Management Knowing when your software reaches end-of-support or end-of-life is critical for compliance and vulnerability management. v0.25 introduces **Product Lifecycle** fields aligned with the [CLE (Common Lifecycle Enumeration)](/compliance/cle/) standard that let you track: - **Release Date** - When the product version was released - **End-of-Support Date** - When active support ends - **End-of-Life Date** - When all support, including security updates, ends You can set these dates manually in the UI for both **products** and **components**. This is useful for tracking your own release schedules and support commitments. For common Linux distributions and frameworks, lifecycle data can also be added automatically. The [Lifecycle Database](/2026/01/20/announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi/#know-when-your-software-goes-end-of-life) in sbomify-action embeds CLE data directly into your SBOMs during generation. This covers distributions like Ubuntu, Debian, Alpine, and Fedora, as well as language runtimes and frameworks including Python, Go, Django, Rails, and React. These dates flow through to your Trust Center and can be displayed on public product pages. For organizations subject to regulations like the [EU Cyber Resilience Act](/compliance/eu-cra/), tracking lifecycle information is a requirement. --- ## Contact Role Flags Building on the contact profile improvements from v0.24, this release adds **role flags** to contacts. You can now designate contacts as: - **Author** - The person or team who created the component - **Security Contact** - Who to reach for security issues - **Technical Contact** - Who to reach for technical questions We have also consolidated the previously separate author field into the main contact profile. Instead of managing authors separately, you now simply mark a contact as an author using the role flag. This simplifies contact management while aligning with how CycloneDX represents contact information. --- ## Compliance Badges Compliance status is now more visible than ever. v0.25 introduces **compliance badges** that display assessment results directly on product listings and public Trust Center pages. Badges only appear for assessments you pass, so you are showcasing compliance achievements rather than advertising gaps. We have also added a **Copy Badge** button that generates markdown snippets you can paste into your README files. This makes it easy to showcase your compliance status directly in your repository. --- ## Other Improvements - **CRA Plugin v1.1.0** - The EU Cyber Resilience Act plugin now prioritizes native SBOM fields over `cra:` annotations, making it easier to pass assessments without custom annotations - **Custom Domains** - Added DCV (Domain Control Validation) delegation CNAME instructions for easier SSL certificate provisioning - **Architecture** - Reorganized the codebase with cleaner api/domain/services layer separation - **Billing** - Enhanced billing processing and webhook handling for Stripe events (v0.25.1) - **Django Admin** - Comprehensive theme update to match the webapp design system (v0.25.1) - **Footer** - Simplified by removing version badges and moving build info to HTML comments (v0.25.1) --- ## Bug Fixes - Fixed API error messages leaking team and resource information (security improvement) - Fixed 403 errors when tagging SBOMs via API tokens in CI/CD pipelines - Fixed infinite "checking" state in the plugin UI when no plugins are enabled - Fixed RecursionError in public component page templates - Fixed plugin enable to not queue all historical SBOMs, which was blocking the web server (v0.25.1) - Fixed social card images with proper 1200x630 dimensions and meta tags (v0.25.1) - Fixed missing component context in component item view (v0.25.1) - Fixed SPDX SBOMs not being tagged to releases (v0.25.1) - Fixed social banner URLs for public Trust Center pages (v0.25.1) --- ## Getting Started To enable the GitHub Attestation Plugin, navigate to **Settings → Plugins** and enable the GitHub Attestation assessment. From there, every SBOM upload with a valid attestation will be automatically verified. For SPDX downloads, visit any release, project, or product page and use the format selector to download the aggregated SBOM in your preferred format. Check out the full changelog for [v0.25](https://github.com/sbomify/sbomify/compare/v0.24...v0.25) and [v0.25.1](https://github.com/sbomify/sbomify/compare/v0.25...v0.25.1) on GitHub. As always, I would love to hear your feedback. If you have questions about attestation verification or ideas for additional plugins, drop us a note or open an issue on GitHub. --- # The MIT License: A Complete Guide for Developers URL: https://sbomify.com/2026/01/22/mit-license-guide/ Date: 2026-01-22 Description: Understand the MIT License – what it permits, what it requires, how it compares to BSD and Apache 2.0, and how SBOMs help track MIT license compliance. The MIT License is a permissive open source license that allows virtually unrestricted use, modification, distribution, and sublicensing of software, including use in proprietary and commercial products. Its only substantive requirement is that the license text and copyright notice must be included with any substantial distribution of the software. The MIT License is the most widely used open source license in the world – GitHub's data consistently shows it as the most popular license choice across its platform. ## What Is the MIT License? The MIT License (formally, the "MIT License" as listed in the [SPDX License List](https://spdx.org/licenses/) with identifier `MIT`) is a permissive free software license originating at the Massachusetts Institute of Technology. It is sometimes referred to as the "Expat License" to distinguish it from other licenses historically associated with MIT. The full text of the MIT License is remarkably short – approximately 170 words: > Copyright (c) \ \ > > Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: > > The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. > > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. This brevity is intentional. The MIT License prioritizes simplicity and clarity, making it easy for developers and organizations to understand exactly what is permitted and what is required. ## What the MIT License Permits The MIT License grants the following rights without restriction: - **Use** – Run the software for any purpose, including commercial use - **Copy** – Make copies of the software - **Modify** – Create derivative works based on the software - **Merge** – Combine the software with other software - **Publish** – Make the software publicly available - **Distribute** – Share copies with others - **Sublicense** – Grant these same rights to third parties - **Sell** – Sell copies of the software, including modified versions The phrase "deal in the Software without restriction" is deliberately broad. There are no limitations on field of use, no requirements to share source code, and no requirements to license derivative works under the MIT License. ## What the MIT License Requires The MIT License has exactly one condition: **the copyright notice and permission notice must be included in all copies or substantial portions of the Software.** In practice, this means: - If you distribute MIT-licensed code (in source or binary form), include the MIT license text and the original copyright notice - If you modify the code and redistribute it, the same requirement applies - If you include MIT-licensed code as part of a larger work, the license text must be present somewhere in the distribution (typically in a LICENSE file, NOTICES file, or third-party attribution document) There is no requirement to: - Make your source code available - License your derivative works under MIT - Notify the original author of your use - Display attribution in a user interface ## MIT License vs. Other Permissive Licenses The MIT License is one of several permissive licenses. Understanding the differences matters for license compliance, particularly in projects that combine code from multiple licenses. ### MIT vs. BSD (2-Clause and 3-Clause) The BSD 2-Clause License ("Simplified BSD") is functionally equivalent to the MIT License – both require attribution and disclaim warranties, with no other conditions. The wording differs, but the legal effect is the same. The BSD 3-Clause License adds a "non-endorsement" clause: you may not use the name of the copyright holder or contributors to endorse or promote derived products without permission. The MIT License has no such clause. | Feature | MIT | BSD 2-Clause | BSD 3-Clause | | -------------------------- | ------------- | -------------- | -------------- | | **Attribution required** | Yes | Yes | Yes | | **Non-endorsement clause** | No | No | Yes | | **Patent grant** | No (implicit) | No (implicit) | No (implicit) | | **SPDX identifier** | `MIT` | `BSD-2-Clause` | `BSD-3-Clause` | ### MIT vs. Apache 2.0 The [Apache License 2.0](/2026/01/07/apache-license-2-guide/) is also permissive but includes two significant additions that the MIT License lacks: 1. **Explicit patent grant.** Apache 2.0 Section 3 grants users a patent license covering the contributor's contributions. The MIT License makes no mention of patents. While the broad language of the MIT License ("deal in the Software without restriction") may imply a patent license in some jurisdictions, this is not settled law. 2. **NOTICE file requirement.** Apache 2.0 requires that any redistribution carry forward the contents of a NOTICE file if one exists. The MIT License has no equivalent mechanism. 3. **State changes requirement.** Apache 2.0 requires that modified files carry a prominent notice stating the changes. MIT has no such requirement. For a detailed comparison including GPL, see our [Apache License 2.0 guide](/2026/01/07/apache-license-2-guide/). ### MIT vs. ISC License The ISC License is a simplified rewrite of the MIT License. It removes the explicit enumeration of rights ("use, copy, modify...") in favor of a single clause: "Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted." The legal effect is generally considered identical to MIT. The ISC License is used by OpenBSD and many npm packages. ## MIT License and Copyleft (GPL) The MIT License is compatible with copyleft licenses like the [GPL](/2025/12/22/gpl-license-guide/) – but only in one direction. MIT-licensed code can be included in a GPL-licensed project. The combined work is then licensed under the GPL. However, GPL-licensed code cannot be included in an MIT-licensed project, because the GPL requires that the entire combined work be distributed under the GPL. | Combination | Result | Permitted? | | ---------------------------------- | --------------------------------------- | ---------------------- | | MIT code included in GPLv2 project | Combined work is GPLv2 | Yes | | MIT code included in GPLv3 project | Combined work is GPLv3 | Yes | | GPL code included in MIT project | Would require MIT project to become GPL | No (unless relicensed) | | MIT code included in AGPL project | Combined work is AGPL | Yes | This compatibility makes MIT one of the most versatile licenses for code reuse. MIT-licensed libraries can be used in virtually any project, regardless of the project's own license. ## MIT License in Commercial Software The MIT License is one of the most commercially friendly open source licenses. Organizations commonly use MIT-licensed code in proprietary products because: - **No source disclosure.** You are not required to share your source code, even if you modify the MIT-licensed component. - **No license propagation.** Your proprietary code does not need to be licensed under MIT. - **Minimal compliance burden.** Including the license text in your distribution (typically in a NOTICES or THIRD-PARTY file) satisfies the only condition. - **No patent risk (with caveats).** While the MIT License does not include an explicit patent grant, its broad permission language is generally interpreted as an implied license. For maximum patent protection, consider [Apache 2.0](/2026/01/07/apache-license-2-guide/) instead. The primary compliance risk with MIT is not the license itself but the volume. A typical web application may depend on hundreds of MIT-licensed packages. Each one requires its license text and copyright notice to be included in the distribution. Automated tooling – particularly SBOM-based compliance checking – is essential at this scale. ## How SBOMs Track MIT License Compliance A [Software Bill of Materials](/what-is-sbom/) documents every component in your software along with its license. For MIT-licensed components, SBOMs support compliance in several ways: 1. **Identifying MIT dependencies.** SBOMs include license information for each component, using the SPDX identifier `MIT` for machine-readable identification. This makes it straightforward to enumerate all MIT-licensed components in a project. 2. **Attribution aggregation.** With hundreds of MIT-licensed dependencies, manually collecting license texts is impractical. SBOMs provide the component list from which attribution documents (NOTICES files, THIRD-PARTY files) can be generated automatically. 3. **License compatibility checking.** SBOM-based compliance tools can detect potential issues – for example, flagging if MIT code is being redistributed without the required license text, or identifying MIT/GPL combinations that require the combined work to be GPL-licensed. 4. **Audit evidence.** SBOMs provide the documentation needed for license audits, M&A due diligence, and procurement assessments. Both [CycloneDX](https://cyclonedx.org/) and [SPDX](https://spdx.dev/) support standardized license fields. The [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) automatically enriches SBOMs with license data from multiple sources, making it practical to track MIT attribution requirements across hundreds of dependencies. For language-specific instructions, see our [SBOM generation guides](/guides/). For a broader overview of open source licenses, see our [guide to navigating the landscape of open source licenses](/2024/04/03/navigating-the-landscape-of-open-source-licenses/). ## Frequently Asked Questions ### What is the MIT License? The MIT License is a permissive open source license that allows unrestricted use, modification, distribution, and sublicensing of software, including in proprietary and commercial products. Its only requirement is that the license text and copyright notice be included with any distribution. It is the most widely used open source license, identified in the SPDX License List as `MIT`. ### Can I use MIT-licensed software commercially? Yes. The MIT License explicitly permits commercial use, including selling copies, incorporating MIT-licensed code into proprietary products, and distributing modified versions. The only requirement is that you include the MIT license text and copyright notice with your distribution. ### What is the difference between MIT and Apache 2.0? Both are permissive licenses that allow commercial use without requiring source code disclosure. The key differences are: Apache 2.0 includes an explicit patent grant and patent retaliation clause, while MIT does not address patents explicitly; Apache 2.0 requires carrying forward NOTICE file attributions, while MIT only requires including the license text; and Apache 2.0 requires noting changes to modified files, while MIT does not. For projects where patent protection is important, Apache 2.0 provides stronger guarantees. ### Is the MIT License compatible with the GPL? Yes, but only in one direction. MIT-licensed code can be included in GPL-licensed projects – the combined work is then distributed under the GPL. However, GPL-licensed code cannot be included in an MIT-licensed project without the entire project becoming GPL-licensed. This one-directional compatibility is a feature of the GPL's copyleft requirement, not a restriction in the MIT License. ### Do I need to include the MIT License text when distributing software? Yes. The MIT License requires that "the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." In practice, this means including the license text in a LICENSE file, NOTICES file, or third-party attribution document shipped with your distribution. This applies to both source and binary distributions. ### How do I comply with the MIT License? Include the full MIT license text (including the copyright notice) in your distribution. This is typically done by maintaining a LICENSE or THIRD-PARTY-NOTICES file that aggregates the license texts of all open source dependencies. For applications with many MIT-licensed dependencies, automated tools that generate attribution documents from SBOMs are the most reliable approach. --- # Announcing sbomify-action v0.11: The One Where They Go to PyPI URL: https://sbomify.com/2026/01/20/announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi/ Date: 2026-01-20 Description: sbomify-action v0.11 transforms from a CI-only tool into a fully-fledged CLI available on PyPI. Major additions include audit trails for compliance, SPDX format support, a pre-computed license database covering 28 Linux distro versions, and native Rust SBOM generation. With v0.11, sbomify-action is no longer tied to your CI/CD pipeline. Install it anywhere with `pip install sbomify-action` and generate enriched SBOMs on your laptop, in your build scripts, or wherever you need them. This release also tackles two of the biggest pain points in SBOM generation: missing license data and tracking end-of-life software. ## Highlights - **Use it anywhere** - Install from PyPI and run locally, in CI, or in any workflow - **Fill in missing licenses** - LicenseDB automatically adds license data for 28 Linux distro versions - **Know when software goes EOL** - Lifecycle Database tracks support dates for distros and frameworks - **Choose your format** - SPDX and CycloneDX with feature parity - **Prove what happened** - Audit trail logs every SBOM transformation for compliance - **Rust projects welcome** - Native generation and enrichment for the Rust ecosystem ## Never Miss a License Again One of the most frustrating aspects of generating SBOMs for container images is discovering that half your packages are missing license information. This happens because many Linux distribution packages do not include machine-readable license metadata in their package manifests. **LicenseDB** solves this. We have built a pre-computed database of valid package licenses covering 28 Linux distro versions: - Debian (11, 12, 13) - Ubuntu (20.04, 22.04, 24.04) - Alpine (3.13-3.21) - Fedora (39, 40, 41, 42) - Amazon Linux (2, 2023) - CentOS Stream (8, 9) - AlmaLinux (8, 9) - Rocky Linux (8, 9) - Wolfi/Chainguard (rolling) When you generate an SBOM, LicenseDB automatically fills in license data for packages that would otherwise be missing it. The lookup is architecture-agnostic, so you get consistent results whether you are building for amd64 or arm64. LicenseDB is our primary license source, but not our only one. We integrate with multiple providers for license data, including PyPI, crates.io, and other package registries. LicenseDB is checked first because it is fast (downloaded once from GitHub releases then cached locally) and reliable. When LicenseDB does not have coverage for a package, we fall back to other sources. See our [integrations page](/features/integrations/) for the full list of data sources. We take a conservative approach: LicenseDB only includes licenses we can verify from authoritative sources. This means we do not have full coverage of every package, but we would rather provide a smaller, accurate database than try to guess licenses with heuristics. When it comes to license compliance, accuracy matters more than completeness. ## Know When Your Software Goes End-of-Life Compliance frameworks like FedRAMP and SOC2 increasingly require organizations to demonstrate they are not running end-of-life software. But tracking EOL dates across dozens of components, base images, and frameworks is tedious and error-prone. The new **Lifecycle Database** embeds [CLE (Common Lifecycle Enumeration)](https://sbomify.com/compliance/cle/) data directly into your SBOMs, following the ECMA-428 specification. For every component we recognize, you get: | What You Learn | Why It Matters | | -------------- | ------------------------------------------------- | | Release Date | Know how old a component is | | End of Support | When bugfixes stop (security-only after this) | | End of Life | When all support ends, including security patches | ### Coverage **Linux Distributions**: Alpine, Ubuntu, Debian, Fedora, Rocky Linux, AlmaLinux, Amazon Linux, CentOS Stream, Oracle Linux, openSUSE Leap, Wolfi **Language Runtimes and Frameworks**: - Python (2.7, 3.10-3.14) - PHP (7.4, 8.0-8.5) - Go (1.22-1.25) - Rust (1.90-1.92) - Django (4.2, 5.2, 6.0) - Rails (7.0-8.1) - Laravel (10-13) - React (17, 18, 19) - Vue.js (2, 3) With this data in your SBOMs, you can answer questions like "Which of our containers are running EOL base images?" or "When does Python 3.12 stop receiving security patches?" without leaving your SBOM tooling. Here is what the lifecycle data looks like in a CycloneDX SBOM: ```json { "name": "python3", "version": "3.12.1", "properties": [ { "name": "cle:releaseDate", "value": "2023-10-02" }, { "name": "cle:eos", "value": "2025-04-02" }, { "name": "cle:eol", "value": "2028-10-31" } ] } ``` ## Run It Anywhere Until now, sbomify-action lived exclusively in CI/CD pipelines. That made it hard to test configurations, debug issues, or generate SBOMs during local development. With v0.11, install it from PyPI and run it wherever you need: ```bash pip install sbomify-action ``` ```bash $ sbomify-action __ _ ____ ___ __ _ _____/ /_ ____ ____ ___ (_) __/_ __ / | _____/ /_(_)___ ____ / ___/ __ \/ __ \/ __ `__ \/ / /_/ / / / / /| |/ ___/ __/ / __ \/ __ \ (__ ) /_/ / /_/ / / / / / / / __/ /_/ / / ___ / /__/ /_/ / /_/ / / / / /____/_.___/\____/_/ /_/ /_/_/_/ \__, / /_/ |_\___/\__/_/\____/_/ /_/ /____/ v0.11 - Zero to SBOM hero ``` The CLI supports both command-line flags and environment variables, so your existing CI configurations translate directly. Test locally, commit with confidence. ## Choose CycloneDX or SPDX Your supply chain partners may require SPDX. Your internal tooling may expect CycloneDX. You should not have to choose between them or accept a degraded experience with one format. Our goal is **feature parity between CycloneDX and SPDX**. With v0.11, we have made significant progress: ```bash sbomify-action --lock-file requirements.txt -f spdx -o sbom.spdx.json ``` License sanitization, lifecycle data, and enrichment from all data sources now work identically regardless of output format. Whichever format your organization or supply chain partners require, you get the same high-quality, enriched SBOMs. ## Prove What Happened to Your SBOM When auditors or customers ask how an SBOM was generated, you need to show your work. The new **audit trail** logs every transformation applied during generation and enrichment, with timestamps. ### What Gets Tracked - **Overrides** - Component name, version, and PURL changes from CLI or environment variables - **Augmentation** - Supplier, manufacturer, authors, licenses, VCS info, lifecycle phase additions - **Enrichment** - Per-component metadata additions (description, license, publisher, URLs) - **Sanitization** - PURL normalizations, URL validations, stub components added ### Output Every run produces three outputs: 1. **Summary table** in the console showing counts by category 2. **audit_trail.txt** written alongside your SBOM output with full details 3. **Collapsible group** in GitHub Actions with the complete audit trail Here is what the audit trail looks like: ``` # SBOM Audit Trail # Generated: 2026-01-18T12:34:56Z # Input: requirements.txt # Output: sbom.cdx.json ## Override [2026-01-18T12:34:56Z] OVERRIDE component.version SET "2.0.0" (source: cli/env) [2026-01-18T12:34:56Z] OVERRIDE component.name MODIFIED "old-name" -> "my-app" (source: cli/env) ## Enrichment [2026-01-18T12:34:57Z] ENRICHMENT pkg:pypi/requests@2.31.0 license ADDED (source: pypi) [2026-01-18T12:34:57Z] ENRICHMENT pkg:pypi/requests@2.31.0 description ADDED (source: pypi) ``` All timestamps are in UTC (ISO 8601 format), making it easy to correlate with CI logs and other audit evidence. This is exactly the provenance and integrity evidence that compliance frameworks like FedRAMP and SOC2 require. ## Rust Ecosystem Support Rust projects now get first-class support: - Native SBOM generation via cargo-cyclonedx - Package metadata enrichment from crates.io This follows our [plugin architecture](https://github.com/sbomify/sbomify-action/blob/master/docs/adr/0001-plugin-architecture.md) principle of "native-first with generic fallback." Native sources like crates.io provide the most accurate metadata for their ecosystem, with generic aggregators as fallbacks for broader coverage. ## Other Improvements **Docker Image**: Multi-arch support (amd64/arm64), lazy installation of Java/Maven and Go to reduce image size. **PURL Handling**: Fixed double-encoding issues, consistent version updates, short git hashes for SBOM versions. **Compliance**: NTIA compliance checkers aligned with the NTIA 2021 standard. ## Breaking Changes - The `rpmrepo` and `ubuntu` enrichment sources have been removed, replaced by LicenseDB which provides broader and more consistent coverage. ## Getting Started Install from PyPI: ```bash pip install sbomify-action ``` Or continue using the GitHub Action as before. The CLI and Action share the same codebase and configuration options. Check out the [full changelog on GitHub](https://github.com/sbomify/sbomify-action/compare/v0.10...v0.11) for complete details. --- # SBOM Management: How to Organize, Track, and Act on Your SBOMs URL: https://sbomify.com/2026/01/18/sbom-management-best-practices/ Date: 2026-01-18 Description: Learn how to manage SBOMs across the full lifecycle – from generation and storage to vulnerability monitoring, versioning, and distribution to consumers. SBOM management is the practice of organizing, storing, versioning, distributing, and acting on [Software Bills of Materials](/what-is-sbom/) across an organization's software portfolio. Generating an SBOM is only the first step. Without a management process, SBOMs become stale documents that sit unused. Effective SBOM management turns component inventories into an operational tool for vulnerability response, compliance reporting, and supply chain risk reduction. ![SBOM management lifecycle from generation through storage and monitoring to action](/assets/images/d2/sbom-management-lifecycle.svg) ## Why SBOM Management Matters Most organizations that begin their SBOM journey focus on generation – using tools like [sbomify](https://sbomify.com), [Syft](https://github.com/anchore/syft), [Trivy](https://github.com/aquasecurity/trivy) (which we [no longer consider safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/)), or [cdxgen](https://github.com/CycloneDX/cdxgen) to produce SBOMs from their projects (see our [resources page](/resources/) for a complete list). This is necessary but insufficient. An SBOM that is generated once and never updated or monitored provides little ongoing value. The real benefits of SBOMs – rapid vulnerability response, continuous compliance, supply chain visibility – only materialize when SBOMs are actively managed. Consider the [Log4Shell](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) disclosure in December 2021: organizations with up-to-date, searchable SBOMs identified affected systems in minutes. Organizations without them spent weeks manually auditing codebases. SBOM management addresses three challenges: 1. **Scale.** A mid-sized organization may have hundreds of applications, each with its own SBOM containing hundreds of components. Managing this manually is not feasible. 2. **Currency.** Software changes with every commit. SBOMs must be regenerated and updated to reflect the current state of deployed software. 3. **Actionability.** An SBOM is only useful if it can be queried, monitored, and correlated with new threat intelligence. Storage without analysis is archival, not management. ## The SBOM Lifecycle The SBOM lifecycle mirrors the structure outlined on our [resources page](/resources/): generation, distribution, and analysis. Management spans all three phases. ### Phase 1: Generation SBOM generation should be automated in your CI/CD pipeline so that every build produces a current SBOM. Key considerations: - **Format choice.** Select [CycloneDX](https://cyclonedx.org/) or [SPDX](https://spdx.dev/) based on your compliance requirements and tooling. See our [SBOM formats comparison](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/) for guidance. Many organizations generate in both formats. - **Generation point.** Generate SBOMs at build time from resolved dependency trees (lock files, built artifacts), not from unresolved manifests. Build-time SBOMs capture the exact versions that will be deployed, including transitive dependencies. - **Automation.** Integrate SBOM generation into your CI/CD pipeline using tools like the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/). Every release should produce an SBOM automatically. - **Completeness.** Ensure SBOMs capture all layers. For [containerized applications](/2026/01/03/container-security-best-practices/), this means generating container-level SBOMs that include base image packages in addition to application dependencies. For language-specific generation instructions, see our [SBOM guides](/guides/). ### Phase 2: Storage and Versioning Generated SBOMs need a durable, queryable storage location. Approaches range from simple to sophisticated: **Artifact repository.** Store SBOMs alongside the build artifacts they describe. If you use a container registry, attach SBOMs to container images using OCI artifacts. If you use a package registry, publish SBOMs as companion files. **Dedicated SBOM platform.** Use a purpose-built platform like [sbomify](https://sbomify.com) that ingests, indexes, and monitors SBOMs across your portfolio. sbomify organizes SBOMs in a hierarchy of Products and Components – matching how software is actually built – and provides centralized visibility, search, and policy enforcement. Its [Trust Center](/features/trust-center/) feature also handles distribution to customers and auditors. **Version control.** Each SBOM should be versioned in lockstep with the software it describes. When version 2.1.3 of your application is released, the SBOM for 2.1.3 should be generated and stored. Previous versions should be retained for audit and incident response purposes. **Retention policy.** Define how long SBOMs are retained. At minimum, retain SBOMs for all currently deployed versions. For compliance, retain SBOMs for the duration required by your applicable frameworks – the [EU CRA](/compliance/eu-cra/) requires vulnerability handling for the expected product lifetime or a minimum of five years. ### Phase 3: Monitoring and Analysis This is where SBOMs deliver their highest value. Continuous monitoring matches your SBOM components against vulnerability databases and threat intelligence feeds. **Vulnerability monitoring.** Ingest SBOMs into a management platform like [sbomify](https://sbomify.com) (which integrates Google OSV and [OWASP Dependency-Track](https://dependencytrack.org/)) or a standalone instance of Dependency-Track. These platforms continuously match components against the [NVD](https://nvd.nist.gov/), [OSV](https://osv.dev/), and the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). When a new [CVE](/2025/12/18/cve-vulnerability-explained/) is published, the platform immediately identifies which of your products are affected. **License compliance.** Monitor for license conflicts and policy violations. Automated tools can flag [GPL](/2025/12/22/gpl-license-guide/) dependencies in proprietary products, [Apache 2.0 / GPLv2 incompatibilities](/2026/01/07/apache-license-2-guide/), or components with unknown licenses. **Component lifecycle tracking.** Monitor for end-of-life and end-of-support components. Dependencies that are no longer maintained represent a growing risk as new vulnerabilities go unpatched. **Policy enforcement.** Define organizational policies (e.g., "no components with critical KEV-listed vulnerabilities in production," "no AGPL-licensed components in SaaS products") and monitor compliance across your portfolio. ## SBOM Distribution SBOMs are not just internal documents. Increasingly, they must be shared with customers, regulators, and supply chain partners. ### Who Receives SBOMs - **Customers** requesting SBOMs as part of procurement or vendor assessment - **Regulators** requiring SBOMs under frameworks like [EO 14028](/compliance/eo-14028/) or the [EU CRA](/compliance/eu-cra/) - **Internal teams** consuming software from other teams within the organization - **Auditors** conducting security assessments or due diligence ### Distribution Methods - **Companion file.** Publish the SBOM alongside the software release (e.g., in the GitHub release assets, alongside Docker images in a registry) - **API access.** Provide programmatic access to SBOMs through a dedicated API endpoint - **Dedicated platform.** Use an SBOM management platform like [sbomify's Trust Center](/features/trust-center/) that provides a branded portal with controlled access to SBOMs and compliance documents for authorized consumers ### What to Include Follow the [NTIA minimum elements](/compliance/ntia-minimum-elements/) as a baseline for SBOM content: supplier name, component name, component version, unique identifiers, dependency relationships, SBOM author, and timestamp. The [CISA minimum elements draft](/compliance/cisa-minimum-elements/) adds recommended fields including license information and lifecycle/generation context. ## Organizing SBOMs at Scale As the number of SBOMs grows, organization becomes critical. ### By Product and Version The most natural organization maps SBOMs to the products and versions they describe. Each product-version combination should have exactly one authoritative SBOM. For products composed of multiple services or components, consider a hierarchical approach: a top-level SBOM for the product that references component-level SBOMs for each service. ### By Deployment Environment Different environments (development, staging, production) may run different versions. Track which SBOM corresponds to what is currently deployed in each environment. This is especially important for incident response – when a new vulnerability is disclosed, you need to know what is in production right now, not what was released last quarter. ### By Supply Chain Position If you both consume and produce software, maintain SBOMs in both directions: SBOMs you receive from your suppliers (upstream) and SBOMs you generate for your products (downstream). Correlating upstream SBOMs with downstream products lets you trace how a supplier vulnerability propagates through your software. ## Best Practices 1. **Automate generation in CI/CD.** Never generate SBOMs manually. Integrate SBOM generation into your build pipeline so every release is automatically documented. See our [SBOM generation guides](/guides/) for language-specific instructions. 2. **Monitor continuously.** Set up automated vulnerability monitoring against your SBOMs. New CVEs are published daily; manual cross-referencing does not scale. [sbomify](https://sbomify.com) provides integrated monitoring via Google OSV and OWASP Dependency-Track. 3. **Version SBOMs with releases.** Every software release should produce a corresponding SBOM. Store them together so you always know the component composition of any deployed version. 4. **Define retention and distribution policies.** Decide how long SBOMs are retained, who has access, and how they are shared with external consumers. Align retention with your compliance obligations. 5. **Centralize visibility.** As your SBOM inventory grows, centralize it in a platform that supports search, filtering, and cross-portfolio analysis. Being able to answer "which of our products use Log4j?" in seconds is the goal. 6. **Keep SBOMs current.** A stale SBOM is worse than no SBOM – it provides false confidence. Ensure that deployed software always has a corresponding current SBOM. Flag and investigate any deployed artifacts without an associated SBOM. 7. **Act on findings.** SBOM management is not complete without a remediation process. When monitoring surfaces a vulnerability, define SLAs for response based on severity, [KEV status](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/), and deployment context. ## Frequently Asked Questions ### What is SBOM management? SBOM management is the practice of organizing, storing, versioning, distributing, and continuously monitoring Software Bills of Materials across an organization's software portfolio. It encompasses the entire SBOM lifecycle: automated generation in CI/CD, durable storage with version tracking, continuous vulnerability monitoring against databases like the NVD and CISA KEV, license compliance checking, and distribution to customers and regulators. ### Why is SBOM management important? Generating an SBOM is only the first step. Without management, SBOMs quickly become stale and unused. SBOM management enables rapid vulnerability response (identifying affected products in seconds when a new CVE is disclosed), continuous compliance monitoring, and supply chain visibility at scale. Organizations with hundreds of applications and thousands of dependencies cannot manage software composition manually. ### What tools are used for SBOM management? Key tools include [sbomify](https://sbomify.com) for integrated SBOM management (generation, storage, monitoring, and distribution in one platform), OWASP Dependency-Track for standalone vulnerability monitoring, and Grype for CLI-based scanning. For generation-only tools, Syft, ~~Trivy~~ ([compromised March 2026](/2026/03/26/trivy-compromise-hardening-sbomify-action/)), and cdxgen produce SBOMs in CycloneDX or SPDX format. For a comprehensive listing, see our [SBOM resources page](/resources/). ### How often should SBOMs be updated? SBOMs should be regenerated with every software release and ideally with every build in your CI/CD pipeline. The SBOM for a deployed application should always reflect its current composition. Additionally, SBOMs should be continuously monitored against vulnerability databases, as new CVEs are published daily that may affect previously scanned components. ### What should be included in an SBOM? At minimum, follow the NTIA minimum elements: supplier name, component name, component version, unique identifiers (purl or CPE), dependency relationships, SBOM author, and timestamp. The CISA minimum elements draft adds license information and generation context. For compliance with specific frameworks, check the requirements on our [compliance overview page](/compliance/). --- # SBOM Formats Compared: CycloneDX vs SPDX URL: https://sbomify.com/2026/01/15/sbom-formats-cyclonedx-vs-spdx/ Date: 2026-01-15 Description: A practical comparison of CycloneDX and SPDX SBOM formats covering history, governance, field differences, tooling, compliance preferences, and when to use which. An SBOM format defines the structure, fields, and serialization of a [Software Bill of Materials](/what-is-sbom/). Two formats have emerged as industry standards: [CycloneDX](https://cyclonedx.org/), developed by OWASP, and [SPDX](https://spdx.dev/) (Software Package Data Exchange), developed by the Linux Foundation. Both are actively maintained, widely supported by tooling, and accepted by major compliance frameworks. Understanding their differences helps organizations choose the right format for their use case – or, as is increasingly common, support both. ## A Brief History ### SPDX SPDX originated in 2010 as a Linux Foundation project focused on standardizing how open source license information is communicated. Its roots in license compliance shaped the format's design: SPDX has always included rich fields for license expressions, copyright text, and file-level attribution. SPDX 2.0 was released in 2015. The later SPDX 2.2.1 became an [ISO/IEC standard (5962:2021)](https://www.iso.org/standard/81870.html) in 2021. SPDX 2.3, the current widely-deployed version, added support for additional relationship types and improved package identification. [SPDX 3.0](https://spdx.github.io/spdx-spec/v3.0.1/), released in 2024, is a significant redesign. It introduces a profile-based architecture where the core specification defines common elements and optional profiles (Security, Licensing, Build, AI, Dataset) extend the model for specific use cases. This makes SPDX 3.0 more flexible but also more complex than previous versions. ### CycloneDX CycloneDX was created in 2017 by [OWASP](https://owasp.org/) with a different starting point: application security. The format was designed specifically to support software supply chain security use cases including vulnerability tracking, dependency analysis, and component integrity verification. CycloneDX has evolved rapidly through regular releases. [CycloneDX 1.6](https://cyclonedx.org/docs/1.6/) (2024) added attestation and cryptography bill of materials support. [CycloneDX 1.7](https://cyclonedx.org/docs/1.7/) (2025) added patent and intellectual property metadata, citations for data provenance, enhanced cryptographic transparency capabilities, and expanded formulations scope. CycloneDX is an [Ecma International standard (ECMA-424)](https://ecma-international.org/publications-and-standards/standards/ecma-424/) as of 2024. ## Governance and Community | Aspect | CycloneDX | SPDX | | ------------------- | ---------------------------------------------------------------- | -------------------------------------------------------- | | **Governing body** | [OWASP Foundation](https://owasp.org/) | [Linux Foundation](https://www.linuxfoundation.org/) | | **Standards body** | [Ecma International](https://ecma-international.org/) (ECMA-424) | [ISO/IEC](https://www.iso.org/) (5962:2021) | | **Primary focus** | Application security and supply chain risk | License compliance and software transparency | | **Release cadence** | Frequent (roughly annual major versions) | Less frequent (major versions every 2-3 years) | | **Current version** | 1.7 (2025) | 3.0.1 (2024), with 2.3 still widely deployed | | **Serialization** | JSON, XML, Protocol Buffers | JSON, XML, RDF, Tag-Value (SPDX 2.3); JSON-LD (SPDX 3.0) | Both formats are open standards with active communities, public specification repositories, and contributor-friendly governance. ## Key Structural Differences ### Document Model **CycloneDX** uses a flat, component-centric model. An SBOM is a document containing metadata and a list of components. Dependencies are expressed separately through a `dependencies` array that maps component references to their dependents. This separation keeps the component list clean and the dependency graph explicit. **SPDX 2.3** uses a package-and-relationship model. Packages are listed individually, and `relationships` entries describe how they relate (e.g., `DEPENDS_ON`, `CONTAINS`, `BUILD_TOOL_OF`). SPDX supports a wider set of relationship types than CycloneDX. **SPDX 3.0** moves to an element-based model with a linked-data approach. Elements (packages, files, snippets, etc.) are connected through relationships and can reference external documents. This is more powerful for complex use cases but adds modeling complexity. ### Component Identification Both formats support Package URL ([purl](https://github.com/package-url/purl-spec)) and [CPE](https://nvd.nist.gov/products/cpe) for component identification. Purl is the preferred identifier in both ecosystems as it is more precise for software packages. | Identifier | CycloneDX | SPDX 2.3 | SPDX 3.0 | | ------------ | ---------------------------- | --------------------------- | ------------------------------------ | | **purl** | `components[].purl` | `packages[].externalRefs[]` | External identifier | | **CPE** | `components[].cpe` | `packages[].externalRefs[]` | External identifier | | **Hash** | `components[].hashes[]` | `packages[].checksums[]` | Verification properties | | **Supplier** | `components[].supplier.name` | `packages[].supplier` | Organization agent linked to element | For a complete field-by-field mapping, see our [SBOM Schema Crosswalk](/compliance/schema-crosswalk/). ### License Data SPDX has historically been stronger for license documentation, reflecting its origins. SPDX defines the [SPDX License List](https://spdx.org/licenses/) – the standard set of license identifiers (e.g., `MIT`, `Apache-2.0`, `GPL-3.0-only`) used across the industry, including by CycloneDX. CycloneDX supports license data through `components[].licenses[]`, which can reference SPDX license identifiers or include full license text. Both formats support SPDX license expressions (compound expressions like `MIT OR Apache-2.0`). ### Vulnerability Data **CycloneDX** includes a dedicated `vulnerabilities` array at the document level, allowing SBOMs to carry vulnerability information alongside component data. This is useful for creating Vulnerability Exploitability eXchange (VEX) documents and for attaching vulnerability assessments directly to SBOMs. **SPDX 2.3** does not have a native vulnerability data structure. Vulnerability information must be conveyed through external references or separate documents. **SPDX 3.0** introduces a Security profile that adds vulnerability and VEX support, closing this gap. ### Lifecycle and Build Data **CycloneDX 1.7** includes `metadata.lifecycles[].phase` to indicate when the SBOM was generated (design, pre-build, build, post-build, operations, discovery, decommission). This aligns with the [CISA SBOM types taxonomy](https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom). **SPDX 3.0** supports build information through its Build profile, which can document build system, build commands, and build environment details. ## SBOM Format Examples A minimal SBOM documenting a single component in each format: ### CycloneDX (JSON) ```json { "bomFormat": "CycloneDX", "specVersion": "1.6", "version": 1, "metadata": { "timestamp": "2026-01-15T12:00:00Z", "component": { "type": "application", "name": "my-application", "version": "1.0.0" } }, "components": [ { "type": "library", "name": "lodash", "version": "4.17.21", "purl": "pkg:npm/lodash@4.17.21", "licenses": [{ "license": { "id": "MIT" } }] } ] } ``` ### SPDX 2.3 (JSON) ```json { "spdxVersion": "SPDX-2.3", "dataLicense": "CC0-1.0", "SPDXID": "SPDXRef-DOCUMENT", "name": "my-application", "documentNamespace": "https://example.com/my-application-1.0.0", "creationInfo": { "created": "2026-01-15T12:00:00Z", "creators": ["Tool: example-tool-1.0"] }, "packages": [ { "SPDXID": "SPDXRef-Package-lodash", "name": "lodash", "versionInfo": "4.17.21", "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz", "licenseConcluded": "MIT", "externalRefs": [ { "referenceCategory": "PACKAGE-MANAGER", "referenceType": "purl", "referenceLocator": "pkg:npm/lodash@4.17.21" } ] } ] } ``` Both formats express the same information – a component named `lodash` at version `4.17.21`, licensed under MIT. CycloneDX uses a more compact syntax; SPDX 2.3 requires additional fields like `downloadLocation`, `SPDXID`, and `documentNamespace`. ## Compliance Framework Preferences Different regulatory frameworks have varying levels of format preference. | Framework | Format Preference | | ------------------------------------------------------------------- | ---------------------------------------------------------- | | [Executive Order 14028](/compliance/eo-14028/) (US) | Format-agnostic; both accepted | | [CISA Minimum Elements](/compliance/cisa-minimum-elements/) | Format-agnostic; references both | | [EU Cyber Resilience Act](/compliance/eu-cra/) (via BSI TR-03183-2) | CycloneDX 1.6+ or SPDX 3.0.1+, JSON or XML format required | | [NTIA Minimum Elements](/compliance/ntia-minimum-elements/) | Format-agnostic; both satisfy minimum element requirements | | [FDA Medical Device](/compliance/fda-medical-device/) | SPDX and CycloneDX both referenced in FDA guidance | | [NIST SP 800-53](/compliance/nist-800-53/) | Format-agnostic; focuses on controls, not format | | [NIST SP 800-171](/compliance/nist-800-171/) | Format-agnostic; focuses on CUI protection requirements | The EU CRA's implementing guidance (BSI TR-03183-2) is the most prescriptive, requiring specific minimum versions of each format. Most other frameworks are deliberately format-neutral. ## Tooling Ecosystem Both formats have broad tooling support. Most modern SBOM tools support both formats, either natively or through conversion. ### Generation Tools | Tool | CycloneDX | SPDX | Notes | | ------------------------------------------------------------------- | --------- | ---- | ---------------------------------------------------------------------------------------------------------------------------- | | [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) | Yes | Yes | Generation + enrichment + augmentation, CI/CD integration | | [Syft](https://github.com/anchore/syft) | Yes | Yes | Multi-ecosystem, container support | | [Trivy](https://github.com/aquasecurity/trivy) | Yes | Yes | Vulnerability scanning + SBOM generation (see [March 2026 advisory](/2026/03/26/trivy-compromise-hardening-sbomify-action/)) | | [cdxgen](https://github.com/CycloneDX/cdxgen) | Yes | No | CycloneDX-native, broad language support | | [Microsoft SBOM Tool](https://github.com/microsoft/sbom-tool) | No | Yes | SPDX-native, CI/CD integration | ### Analysis and Management Tools | Tool | CycloneDX | SPDX | Notes | | ------------------------------------------------------ | --------- | ---- | --------------------------------------------------- | | [sbomify](https://sbomify.com) | Yes | Yes | Integrated management, monitoring, and distribution | | [Grype](https://github.com/anchore/grype) | Yes | Yes | CLI vulnerability scanner | | [OWASP Dependency-Track](https://dependencytrack.org/) | Yes | Yes | Standalone monitoring platform | | [OSV-Scanner](https://google.github.io/osv-scanner/) | Yes | Yes | Google's vulnerability scanner | For a comprehensive tool listing organized by lifecycle phase, see our [SBOM resources page](/resources/). For tool comparison and benchmarks, see the [sbom-benchmarks repository](https://github.com/sbomify/sbom-benchmarks). ## When to Use Which Format There is no single "winner" between CycloneDX and SPDX. The right choice depends on your primary use case: **Choose CycloneDX when:** - Your primary concern is application security and vulnerability management - You need to include vulnerability or VEX data directly in the SBOM - You are targeting EU CRA compliance and prefer the more compact format - Your toolchain already uses CycloneDX-native tools like cdxgen - You want a simpler document model with fewer required fields **Choose SPDX when:** - License compliance is your primary driver - You need detailed file-level analysis (SPDX supports file and snippet elements) - You are working in ecosystems that have standardized on SPDX (e.g., some automotive and embedded Linux communities) - You need ISO/IEC standard status (ISO/IEC 5962:2021) - You are working with SPDX 3.0 profiles for specialized use cases (AI, Build, Dataset) **Support both when:** - You distribute software to diverse customers with different format preferences - Your compliance obligations span multiple frameworks with different preferences - You use tools like Syft that generate both formats from a single scan (note: we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise) Many organizations generate SBOMs in both formats or convert between them using tools like the [CycloneDX CLI](https://github.com/CycloneDX/cyclonedx-cli). The formats are converging in capability, and the practical differences are narrowing with each release. ## Frequently Asked Questions ### What are the main SBOM formats? The two industry-standard SBOM formats are CycloneDX (developed by OWASP, standardized as ECMA-424) and SPDX (developed by the Linux Foundation, standardized as ISO/IEC 5962:2021). Both support JSON and XML serialization, are accepted by major compliance frameworks, and have broad tooling support. CycloneDX originated in application security; SPDX originated in license compliance. ### What is the difference between CycloneDX and SPDX? CycloneDX is a security-focused format with a compact, component-centric model and native support for vulnerability and VEX data. SPDX is a compliance-focused format with rich license documentation capabilities and support for file-level and snippet-level analysis. CycloneDX has a simpler document structure; SPDX (especially 3.0) offers a more flexible element-based model with profiles for specialized use cases. Both support purl, CPE, and hash-based component identification. ### Which SBOM format should I use? If your primary concern is application security and vulnerability management, CycloneDX is often the more straightforward choice. If license compliance is your primary driver, SPDX's deeper license support may be more appropriate. For EU CRA compliance via BSI TR-03183-2, you need CycloneDX 1.6+ or SPDX 3.0.1+ in JSON or XML format. Many organizations support both formats, as most modern tools can generate either. ### Can I convert between CycloneDX and SPDX? Yes. Tools like the CycloneDX CLI support conversion between formats. However, conversion may result in some data loss where one format supports fields that the other does not. For critical compliance use cases, it is better to generate natively in the required format rather than converting. ### What is an SBOM example? An SBOM is a machine-readable document listing every component in a software product, including names, versions, package identifiers (purl), licenses, and supplier information. See the CycloneDX and SPDX JSON examples in this article for minimal working examples. For real-world SBOMs with hundreds of components, see the [sbom-benchmarks repository](https://github.com/sbomify/sbom-benchmarks). --- # Announcing sbomify v0.24: The One with All the Plugins URL: https://sbomify.com/2026/01/14/announcing-sbomify-v0-24-the-one-with-all-the-plugins/ Date: 2026-01-14 Description: sbomify v0.24 introduces a powerful plugin-based assessment framework supporting security, license, compliance, and attestation plugins. Ships with NTIA, CISA, CRA, and FDA compliance plugins out of the box. Today marks a pivotal release for sbomify. With v0.24, we are laying the foundation for what will become a fully extensible, plugin-based platform. This release introduces our new **Plugin-Based Assessment Framework**, a unified architecture for running automated assessments on every SBOM upload. This represents a fundamental shift in how we think about sbomify's architecture going forward. ## Plugin-Based Assessment Framework The headline feature of v0.24 is our new assessment plugin system, documented in [ADR-003: Plugin-based Assessments for SBOM Uploads](https://github.com/sbomify/sbomify/blob/master/docs/ADR/ADR-003.md). If you want to understand where sbomify is headed, this architectural decision record is essential reading. ### Four Assessment Categories The plugin framework is designed to support four distinct categories of SBOM assessment: | Category | Description | Examples | | --------------- | ------------------------------------------------------- | --------------------- | | **Security** | Vulnerability scanning via external tools and APIs | OSV, Dependency-Track | | **License** | Policy evaluation against approved/denied license lists | License policy checks | | **Compliance** | Validation against regulatory and industry standards | NTIA, CISA, CRA, FDA | | **Attestation** | Integrity and provenance verification | Sigstore, in-toto | Each category has different characteristics. Security plugins integrate with external vulnerability databases that change continuously, so they support scheduled re-runs. Compliance and license plugins are deterministic for a given ruleset version. Attestation plugins verify cryptographic signatures and provenance data. ### Compliance Plugins Shipping Now This release ships with five compliance plugins ready to use. Each plugin aligns with our [compliance documentation](/compliance/), so you can understand exactly what is being validated: - **[NTIA Minimum Elements](/compliance/ntia-minimum-elements/)** - Validates your SBOMs against the foundational US baseline for SBOM data fields - **[CISA 2025 Minimum Elements](/compliance/cisa-minimum-elements/)** - Checks compliance with the updated US guidance including hash, license, and generation context - **[EU Cyber Resilience Act (CRA)](/compliance/eu-cra/)** - Validates against Regulation 2024/2847 requirements (beta) - **[FDA Medical Device Cybersecurity](/compliance/fda-medical-device/)** - Ensures medical device SBOM requirements are met, including lifecycle properties - **Checksum Verification** - A test plugin that validates SBOM integrity through checksum verification (useful as a reference implementation) Each plugin runs automatically when you upload an SBOM. Simply enable the plugins you need in **Settings → Plugins**, and assessments happen transparently in the background. ### Why This Architecture Matters The design decisions in ADR-003 are intentional and set the stage for everything that follows: - **Assessments tied to uploads, not content hashes** - Each upload is assessed independently, giving you a complete history of checks over time - **Immutable AssessmentRun records** - Every assessment is recorded permanently, enabling full audit trails and historical tracking - **Python SDK with normalized results** - All plugins return results in a consistent `AssessmentResult` schema with `Finding` entries, making it easy to compare and aggregate data across plugin types - **Config hashing for reproducibility** - When assessment results change, you can trace exactly why by comparing configuration hashes - **Per-team plugin enablement** - Teams can enable the plugins relevant to their needs, with feature gating based on billing plans ### The Migration Path This plugin system is the future of sbomify. In upcoming releases, we will be migrating our existing features into this architecture: **Phase 2: Security Plugins** Our current **OSV vulnerability scanning** and **Dependency Track integration** will be refactored into security plugins. This migration will make these features more modular, give you historical tracking of all vulnerability scans, and allow the same plugin architecture to power scheduled re-scans as vulnerability databases are updated. **Phase 3 and Beyond** We have a roadmap of additional plugins including license policy evaluation, attestation verification (Sigstore and in-toto), and VEX (Vulnerability Exploitability eXchange) statement processing. The goal is to make sbomify a platform where you can mix and match the capabilities you need. --- ## Vue.js to Alpine.js Migration Complete We have completed the frontend migration we started in previous releases. This release replaces the remaining **35 Vue.js components** with lightweight Alpine.js implementations backed by Django templates. This migration closes out [ADR-001: Django Monolith](https://github.com/sbomify/sbomify/blob/master/docs/ADR/ADR-001.md). As documented there, our detour into Vue turned out to be a mistake. While we wanted to maintain an API-first approach, leveraging Django Templates with server-side rendering minimizes complexity compared to a separate Vue frontend. Equally important, Vue made end-to-end testing more challenging, and we had several blocks silently failing as a result. The result is a significantly smaller bundle size, faster page loads, a more maintainable codebase, and much better test coverage. If you have been following our journey from Vue.js to Alpine.js + HTMX, this release marks the finish line. --- ## Contact Profiles CycloneDX Alignment Contact profiles have been restructured to align with the CycloneDX specification. The new **3-level hierarchy** (Profile → Entity → Contact) matches how CycloneDX represents organizational and contact information. If you have existing contact profiles, they will be automatically migrated to the new structure. No action required on your part. --- ## Billing System Improvements We have made several improvements to how billing works: - **Dynamic pricing from Stripe** - Pricing is now synced directly from Stripe, ensuring consistency across the platform - **Promotion codes at checkout** - You can now apply promotion codes when subscribing or upgrading - **Billing period visibility** - Your current billing period and next billing date are now displayed in team settings - **Improved subscription management** - New management commands for subscription reconciliation and better webhook handling --- ## Other Improvements - **Trust Center**: Consolidated templates, improved SEO, and better UX across the board - **CycloneDX 1.6+**: Added manufacturer field support with backward compatibility for 1.5 - **CI/CD Templates**: New configuration templates for Azure DevOps and Jenkins - **License Expressions**: Optimized parsing with server-side rendering support - **Mobile Experience**: Improved search bar responsiveness on mobile devices - **Document Upload**: Better drag-and-drop experience - **Workspace Labels**: Now use title case (Product, Compliance Artifact, Project) --- ## Security and Infrastructure On the security front, we addressed findings from Semgrep and Bandit scans, added `noreferrer` to external links, and fixed a user invitation limit bypass vulnerability. Infrastructure updates include upgrading our base image to **Debian Trixie**, updating `python-keycloak` to 7.0.1, and bumping our GitHub Actions dependencies to their latest versions. --- ## Bug Fixes - Fixed duplicate artifacts appearing in release pages when components belong to multiple projects - Fixed barcode rendering on private product identifiers page - Fixed latest badge display and modal issues in release UI - Fixed private component access returning 404 instead of 403 Forbidden - Fixed `$schema` alias handling in CycloneDX SBOM serialization - Fixed domain verification cron job registration --- ## Getting Started If you are self-hosting sbomify, update to v0.24 to take advantage of the new plugin system. For users on our hosted platform, these features are already live. To enable assessment plugins, navigate to **Settings → Plugins** and enable the assessments relevant to your requirements. From there, every SBOM upload will be automatically assessed, with full historical tracking of all results. Check out the [full changelog on GitHub](https://github.com/sbomify/sbomify/compare/v0.23...master) for complete details. As always, I would love to hear your feedback. Drop us a note or open an issue on GitHub if you have questions, suggestions, or ideas for new plugins. The plugin architecture is designed to be extensible, and we are eager to hear what assessments would be most valuable to you! --- # Software Composition Analysis (SCA): What It Is and How SBOMs Fit In URL: https://sbomify.com/2026/01/11/software-composition-analysis-sca/ Date: 2026-01-11 Description: Learn what software composition analysis is, how SCA tools work, how SCA compares to SAST and DAST, and how SBOMs complement SCA for full supply chain visibility. Software Composition Analysis (SCA) is a category of application security tooling that identifies open source and third-party components in a codebase, catalogs their licenses, and detects known vulnerabilities associated with those components. SCA tools work by analyzing dependency manifests, lock files, and sometimes compiled binaries to produce an inventory of components that can be matched against vulnerability databases like the [National Vulnerability Database](https://nvd.nist.gov/) (NVD) and the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). ![SCA workflow from source analysis through component identification to vulnerability matching](/assets/images/d2/sca-workflow.svg) ## What Is Software Composition Analysis? Software Composition Analysis addresses a fundamental reality of modern software development: most applications are not written from scratch. Studies consistently show that [70-90% of a typical application consists of open source components](https://www.linux.com/training-tutorials/estimating-total-number-linux-contributors-approach-using-linus-law/) pulled from package registries like npm, PyPI, Maven Central, and crates.io. Each of these components introduces potential security vulnerabilities, license obligations, and maintenance risks. SCA tools automate the process of identifying these components and their associated risks. Without SCA, development teams would need to manually track every library version across every project – an approach that does not scale given the pace of vulnerability disclosure (the NVD published over 28,000 CVEs in 2023 alone). The core functions of SCA are: 1. **Component identification.** Scanning source code, dependency files, and sometimes binaries to produce a complete inventory of third-party components, including [transitive dependencies](/2026/01/29/what-is-a-dependency-in-software/) – the dependencies of your dependencies. 2. **Vulnerability detection.** Matching identified components against vulnerability databases to flag known [CVEs](/2025/12/18/cve-vulnerability-explained/). 3. **License compliance.** Identifying the license of each component and flagging potential conflicts or compliance obligations, such as [GPL copyleft requirements](/2025/12/22/gpl-license-guide/). 4. **Policy enforcement.** Allowing organizations to define rules (e.g., "block any component with a critical CVE" or "reject AGPL-licensed dependencies") and enforce them in CI/CD pipelines. ## How SCA Tools Work SCA tools typically operate through one or more of these analysis methods: ### Manifest and Lock File Analysis The most common approach. SCA tools parse dependency declaration files – `package.json` and `package-lock.json` (JavaScript), `requirements.txt` and `poetry.lock` (Python), `pom.xml` (Java), `go.sum` (Go), `Cargo.lock` (Rust), and similar files for other ecosystems. This provides a definitive list of declared dependencies and their resolved versions. ### Source Code Scanning Some SCA tools scan source code files to detect component usage that may not be declared in manifests – for example, vendored code (source files copied directly into a repository rather than managed through a package manager), or code snippets pulled from Stack Overflow or other sources. ### Binary Analysis Binary SCA analyzes compiled artifacts (executables, container images, firmware) to identify embedded components. This is essential when source code is not available, such as when evaluating third-party commercial software or auditing firmware. Binary analysis is less precise than manifest analysis but covers a broader set of use cases. ### Dependency Resolution Advanced SCA tools resolve the full dependency tree, including transitive dependencies. A project that declares 10 direct dependencies may actually depend on hundreds of transitive packages. SCA tools that only examine direct dependencies miss the majority of the attack surface. ## SCA vs. SAST vs. DAST SCA is one of several application security testing approaches. Each addresses different risk categories and operates at different points in the [software development life cycle](/2025/12/15/software-development-life-cycle-sdlc-sbom-integration/). | Aspect | SCA | SAST | DAST | | ----------------------- | --------------------------------------------------------- | ------------------------------------------ | ------------------------------------------------ | | **What it analyzes** | Third-party and open source components | Your application's source code | Your running application | | **Risk category** | Known vulnerabilities in dependencies, license compliance | Code-level flaws (injection, logic errors) | Runtime vulnerabilities (XSS, auth bypass) | | **When it runs** | Build time / CI pipeline | Build time / CI pipeline | After deployment / in staging | | **Input** | Dependency files, lock files, binaries | Source code, bytecode | Application URLs and endpoints | | **Output** | Component inventory, CVE matches, license report | Code-level vulnerability findings | Runtime vulnerability findings | | **False positive rate** | Low (matches known CVEs to exact versions) | Moderate to high | Low to moderate | | **Coverage gap** | Does not find flaws in your own code | Does not find dependency vulnerabilities | Does not find issues in code paths not exercised | These tools are complementary. A comprehensive application security program uses all three: - **SCA** catches known vulnerabilities in the 70-90% of your application that you did not write - **SAST** catches coding flaws in the 10-30% that you did write - **DAST** catches runtime issues that only manifest in a deployed environment ## SCA Tools Several tools provide SCA capabilities. The ecosystem spans open source and commercial offerings. ### Open Source SCA Tools - **[Grype](https://github.com/anchore/grype)** – Vulnerability scanner from Anchore that matches SBOMs and container images against vulnerability databases. Works well in combination with Syft for SBOM generation. - **[OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)** – Mature OWASP project that identifies project dependencies and checks for known CVEs. Supports Java, .NET, JavaScript, Ruby, and Python. - **[OWASP Dependency-Track](https://dependencytrack.org/)** – Continuous SBOM analysis platform that ingests SBOMs and monitors components against multiple vulnerability databases. Provides a dashboard for tracking risk across an entire portfolio. - **[OSV-Scanner](https://google.github.io/osv-scanner/)** – Google's open source vulnerability scanner that uses the [OSV database](https://osv.dev/) and supports multiple ecosystems. - **[Trivy](https://github.com/aquasecurity/trivy)** – Comprehensive scanner from Aqua Security that detects vulnerabilities in OS packages, language dependencies, container images, and IaC configurations. (Note: we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following two successful supply chain attacks in March 2026 and have removed it from sbomify-action.) ### Commercial SCA Tools - **Snyk Open Source** – Developer-focused SCA with IDE integrations and automated fix PRs - **Sonatype Lifecycle** – Enterprise SCA with policy engine and supply chain firewall - **Black Duck** (Synopsys) – Enterprise SCA with extensive binary analysis capabilities - **FOSSA** – SCA focused on license compliance and open source management For a comprehensive list of tools in the SBOM ecosystem, see our [resources page](/resources/). ## SCA and SBOMs SCA tools and [SBOMs](/what-is-sbom/) are closely related but serve different purposes. Understanding the relationship helps you build a more effective security program. ### SCA Generates SBOMs Many SCA tools produce SBOMs as an output of their analysis. The [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) generates SBOMs and automatically enriches them with license, hash, and lifecycle metadata from 11+ data sources. Standalone tools like [Syft](https://github.com/anchore/syft) and [Trivy](https://github.com/aquasecurity/trivy) also generate SBOMs in standard formats ([CycloneDX](https://cyclonedx.org/) or [SPDX](https://spdx.dev/)). In this sense, SCA is one of the primary methods for [SBOM generation](/guides/). ### SBOMs Enable Continuous SCA A generated SBOM can be ingested by management platforms like [sbomify](https://sbomify.com) or [OWASP Dependency-Track](https://dependencytrack.org/) for continuous analysis. Instead of re-scanning your entire codebase every time a new CVE is published, the platform matches new vulnerabilities against your existing SBOM inventory. This is particularly valuable for monitoring production deployments where source code may not be readily accessible. ### SBOMs Go Beyond SCA While SCA focuses on vulnerability detection and license compliance, SBOMs serve a broader purpose: - **Regulatory compliance.** Frameworks like [Executive Order 14028](/compliance/eo-14028/), the [EU Cyber Resilience Act](/compliance/eu-cra/), and [FDA medical device guidance](/compliance/fda-medical-device/) require SBOMs as a compliance artifact – not just SCA scan results. - **Supply chain transparency.** SBOMs document the provenance and composition of software for consumers, auditors, and regulators. - **Incident response.** When a vulnerability like [Log4Shell](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) is disclosed, SBOMs allow you to immediately identify affected products without re-running scans. For organizations building a security program, SCA tools are the engine and SBOMs are the artifact. Use SCA to scan and detect; use SBOMs to document, share, and continuously monitor. ## Best Practices 1. **Integrate SCA into CI/CD.** Run SCA scans on every build and pull request. Catching vulnerable dependencies before they reach production is far less costly than remediating them after deployment. 2. **Monitor continuously, not just at build time.** New vulnerabilities are disclosed daily. Use SBOM-based monitoring with platforms like [sbomify](https://sbomify.com) or [OWASP Dependency-Track](https://dependencytrack.org/) to catch newly disclosed CVEs in your already-deployed components. 3. **Resolve the full dependency tree.** Ensure your SCA tool analyzes transitive dependencies, not just direct ones. The majority of vulnerable components in most projects are transitive. 4. **Define and enforce policies.** Establish clear rules for vulnerability severity thresholds, license restrictions, and acceptable risk. Automate enforcement in your pipeline to prevent policy violations from reaching production. 5. **Combine SCA with SAST and DAST.** SCA only finds known vulnerabilities in third-party code. Pair it with SAST for your own code and DAST for runtime testing to cover all three risk categories. 6. **Generate SBOMs from SCA output.** Use your SCA tool's SBOM generation capability to produce machine-readable component inventories in [CycloneDX or SPDX format](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/). These SBOMs serve both security monitoring and compliance purposes. ## Frequently Asked Questions ### What is software composition analysis? Software Composition Analysis (SCA) is a category of security tooling that identifies open source and third-party components in your software, detects known vulnerabilities in those components by matching them against databases like the NVD, and catalogs their licenses for compliance purposes. SCA tools analyze dependency manifests, lock files, and sometimes binaries to produce a complete component inventory. ### What is the difference between SCA and SAST? SCA analyzes third-party and open source components in your application for known vulnerabilities and license issues. SAST (Static Application Security Testing) analyzes your own source code for coding flaws like injection vulnerabilities, authentication bypasses, and logic errors. SCA covers the 70-90% of your application that is third-party code; SAST covers the code you wrote yourself. Both are needed for comprehensive application security. ### How does SCA relate to SBOMs? SCA tools are one of the primary methods for generating SBOMs. When an SCA tool scans your project and identifies all components, that inventory can be exported as an SBOM in standard formats like CycloneDX or SPDX. Conversely, SBOMs enable continuous SCA by providing a persistent component inventory that can be monitored against new vulnerability disclosures without re-scanning source code. ### What are the best open source SCA tools? Leading open source SCA tools include Grype (vulnerability scanner from Anchore), OWASP Dependency-Track (continuous SBOM analysis platform), OWASP Dependency-Check (mature CVE detection tool), OSV-Scanner (Google's vulnerability scanner using the OSV database), and Trivy (comprehensive scanner from Aqua Security, though we [no longer consider it safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise). Choice depends on your ecosystem, integration requirements, and whether you need CLI scanning, CI/CD integration, or continuous monitoring. ### Does SCA find all vulnerabilities? No. SCA finds known vulnerabilities in third-party components – those that have been assigned CVE identifiers and added to vulnerability databases. It does not find zero-day vulnerabilities (those not yet publicly known), vulnerabilities in your own code, or runtime configuration issues. SCA should be combined with SAST, DAST, and penetration testing for comprehensive coverage. --- # FDA Medical Device SBOM Requirements: What the New Cybersecurity Guidance Means for Manufacturers URL: https://sbomify.com/2026/01/09/fda-medical-device-sbom-requirements/ Date: 2026-01-09 Description: Breakdown of the FDA's June 2025 guidance on medical device cybersecurity, explaining SBOM requirements, premarket submission expectations, and compliance strategies. On June 27, 2025, the FDA issued updated guidance on **"Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions."** This document marks a significant step forward in how medical device manufacturers must approach software security and transparency. At the heart of these recommendations lies the [Software Bill of Materials (SBOM)](/what-is-sbom/) – now an essential element of premarket submissions for connected medical devices. If you're a manufacturer preparing a 510(k), PMA, or other premarket submission, here's what you need to know about the FDA's SBOM expectations and how to prepare. ## What the Guidance Says About SBOMs The FDA guidance recommends the inclusion of an SBOM under **Section V.A.4 (Software Bill of Materials)** as part of cybersecurity documentation in premarket submissions. Additionally, **Appendix 4** lists SBOM sections as recommended documentation when cybersecurity risk is relevant. While the guidance language is technically **non-binding** ("contains nonbinding recommendations"), the practical reality is different: - Under **Section 524B of the FD&C Act**, the FDA has authority over "cyber devices" – devices with software that can be vulnerable and are connected - FDA may **refuse to accept premarket submissions** that do not provide adequate SBOM and related cybersecurity information - Insufficient SBOM documentation can lead to **delays in review** or requests for resubmission In practice, the SBOM has moved from "nice-to-have" to **essential cybersecurity documentation** for medical device submissions. This mirrors the broader global trend toward [mandatory SBOM requirements](/features/why-now/) across regulatory frameworks. ## SBOM Content Expectations The FDA guidance does not define SBOM fields directly. Instead, it explicitly references the **[NTIA Minimum Elements for a Software Bill of Materials](https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf)** as the baseline expectation for SBOM content in premarket submissions. This distinction matters: the FDA is effectively saying "provide an SBOM that meets the NTIA minimum elements" – not "provide an SBOM with these FDA-defined fields." This approach mirrors how other regulators (including the EU's Cyber Resilience Act) reference SBOMs indirectly via standards bodies, allowing requirements to evolve without requiring agencies to reissue guidance. ### NTIA Minimum Elements The NTIA baseline defines what every SBOM should contain. For each software component: - **Supplier name** – who supplied the component - **Component name** – the name of the component - **Version** – the version identifier - **Unique identifier** – such as Package URL (purl) or CPE - **Dependency relationship** – how components relate to each other - **Author of SBOM data** – who created the SBOM - **Timestamp** – when the SBOM was created ### Machine-Readable Formats SBOMs should be provided in machine-readable formats that support the NTIA minimum elements: - **SPDX** (Software Package Data Exchange) - **CycloneDX** Both formats are widely accepted and can represent the required NTIA data fields. ### Complete Software Inventory All software included in the device must be identified: - Commercial software - Open-source components - Third-party libraries - Off-the-shelf (OTS) components ### Support and Lifecycle Metadata Beyond the NTIA baseline, FDA expects additional context for medical device submissions: - **Level of support** from the component supplier (active, legacy, or unsupported) - **End-of-support and end-of-life dates** for each component ### Vulnerability Context SBOMs should be supplemented with: - A **known vulnerabilities assessment** for identified components - **Controls or mitigation descriptions** explaining whether vulnerabilities are mitigated by design This means SBOMs are expected to be part of a comprehensive **vulnerability and risk management package**, not just a flat inventory list. ## Lifecycle and Traceability Requirements The FDA guidance ties SBOMs into broader cybersecurity documentation expectations throughout the device lifecycle. Understanding the full [SBOM lifecycle](/features/generate-collaborate-analyze/) – from generation through distribution and analysis – is critical for FDA compliance: ### Secure Product Development and Traceability - SBOMs must be **traceable to security architecture views** and threat models that FDA reviewers evaluate - The documentation should demonstrate how software components affect device security risks ### Ongoing Updates - SBOMs should be **updated to reflect changes** throughout software updates and the device lifecycle - This is not a one-time snapshot – it's a living document - Proper [SBOM versioning practices](/guides/how-to-version-sboms/) are essential for maintaining traceability ### Integration with Other Documentation In premarket submissions, SBOMs typically appear alongside: - **Security Risk Management Reports** – showing how components affect device risks - **Vulnerability Assessments** – outcomes derived from SBOM analysis - **Software Support Information** – lifecycle and maintenance details - **Labeling and Transparency Materials** – cybersecurity information for end users ### Why CI/CD Integration Is Essential Given the FDA's emphasis on traceability and ongoing updates, **manual SBOM generation is not sustainable** for medical device compliance. Every software build should automatically generate an SBOM that: - Captures the exact components at the moment of build - Is cryptographically linked to that specific release - Can be traced back to source code and build artifacts - Is automatically stored and versioned for audit trails Integrating SBOM generation into your CI/CD pipeline ensures that every release – whether it's a major version update or a security patch – has accurate, reproducible documentation. This is particularly important for medical devices where you may need to answer FDA questions about software composition years after the initial submission. ### Distribution and Transparency The FDA expects manufacturers to share cybersecurity information with stakeholders, including healthcare providers and end users. This means having a reliable system for distributing SBOMs to: - FDA reviewers during premarket submissions - Auditors during compliance assessments - Healthcare organizations evaluating your devices - Security researchers conducting vulnerability assessments Email and shared drives don't scale for this – you need a dedicated [SBOM hub and Trust Center](/features/trust-center/) that provides controlled access to current and historical SBOMs. ## Practical Implications for Manufacturers If you're preparing a premarket submission (510(k), PMA, De Novo), here's what the FDA expects in practice: ### SBOM Compliance Checklist 1. **NTIA Minimum Elements** – Ensure your SBOM includes all required fields (supplier, component name, version, unique identifier, dependencies, author, timestamp) 2. **Machine-readable format** – Use SPDX or CycloneDX 3. **Inventory completeness** – Cover all software elements in your device 4. **Support and lifecycle metadata** – Document support status and EOL dates for each component 5. **Known vulnerability assessment** – Tie vulnerabilities back to risk controls 6. **Traceability and architecture linkage** – Connect SBOMs to documentation and risk models 7. **Ongoing maintenance strategy** – Plan for SBOM updates through the device's life ### Consequences of Non-Compliance Noncompliance or insufficient SBOM information can result in: - **Refuse-to-accept decisions** at the submission stage - **Delays in review** requiring resubmission with complete SBOM and analysis The message is clear: get your SBOM documentation right the first time. ## How sbomify Helps with FDA Compliance Medical devices often have long lifecycles – sometimes 10-15 years or more. Managing SBOMs across that timespan, through multiple software updates and component changes, requires purpose-built tooling that automates the entire [SBOM lifecycle](/features/generate-collaborate-analyze/). [sbomify]() provides the infrastructure medical device manufacturers need: ### Automated CI/CD Integration This is the foundation of FDA-compliant SBOM management. sbomify integrates directly into your build pipeline: - **[Generate SBOMs automatically](/features/generate-collaborate-analyze/)** during every build – no manual steps - **Augment and enrich** SBOMs with supplier information, licensing, and metadata required by NTIA minimum elements - **Cryptographic signing and attestation** for verifiable integrity - Upload to sbomify with our [GitHub Action](https://github.com/sbomify/sbomify-action) and [GitLab modules](/2024/11/12/gitlab-support/) - Every release automatically documented and stored for regulatory review By automating generation in CI/CD, you ensure that SBOMs are always accurate, reproducible, and traceable to specific builds – exactly what the FDA expects. ### Trust Center for Regulatory Distribution Email and file shares don't meet FDA expectations for professional cybersecurity documentation. sbomify's [Trust Center](/features/trust-center/) gives you: - A **branded portal** for sharing SBOMs with FDA reviewers, auditors, and healthcare organizations - **Controlled access** – determine who can see which products and versions - **Always current** – stakeholders access live data, not stale email attachments - **Audit trail** – track who accessed what and when - Professional presentation that demonstrates your commitment to transparency ### SBOM Lifecycle Management - Archive and track SBOMs across product versions and releases - Maintain full version history for regulatory audits spanning years - Support long-lived medical devices with complete historical records ### Centralized SBOM Hub - Manage SBOMs for multiple device products in one platform - Standardize generation and storage across engineering teams - Aggregate component-level SBOMs into product-level views with our [SBOM hierarchy](/features/sbom-hierarchy/) feature – essential for complex medical devices with multiple software subsystems ### Continuous Vulnerability Monitoring - Integrate with [Google OSV and Dependency Track](/features/integrations/) for ongoing vulnerability detection - Monitor archived SBOMs for newly discovered CVEs - Track vulnerability status even for devices shipped years ago – critical for the FDA's post-market cybersecurity expectations ## Conclusion The FDA's June 2025 cybersecurity guidance makes it clear: SBOMs are no longer optional for medical device manufacturers. They're a critical component of premarket submissions and ongoing compliance. The guidance sets clear expectations for SBOM content, format, and lifecycle management – and the FDA is prepared to refuse submissions that don't meet these standards. Getting ahead of these requirements isn't just about regulatory compliance – it's about building more secure devices and maintaining trust with healthcare providers and patients. [Get started with sbomify](https://app.sbomify.com) and build FDA-ready SBOM documentation into your medical device development process. ## Resources ### Official Documentation - [FDA Guidance: Cybersecurity in Medical Devices (PDF)](https://www.fda.gov/media/119933/download) - [NTIA Minimum Elements for a Software Bill of Materials (PDF)](https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf) ### Learn More About SBOMs - [What is an SBOM?](/what-is-sbom/) - [The SBOM Lifecycle: Generation, Distribution, and Analysis](/features/generate-collaborate-analyze/) - [How to Version SBOMs](/guides/how-to-version-sboms/) - [The Growing Importance of SBOMs in Cybersecurity Compliance](/features/why-now/) ### Related Compliance Frameworks - [Understanding the EU Cyber Resilience Act](/2024/07/10/understanding-the-eu-cyber-resilience-act-the-role-of-sboms-in-enhancing-cybersecurity/) - [How SBOMs Help with PCI DSS 4.0 Compliance](/2025/01/07/how-sboms-can-help-you-achieve-pci-dss-4-compliance/) - [CRA Explained: What the Cyber Resilience Act Means for Device Manufacturers](/2026/01/06/cra-explained-cyber-resilience-act-for-device-manufacturers/) ### sbomify Features - [SBOM Hierarchy](/features/sbom-hierarchy/) - [Integrations](/features/integrations/) - [Trust Center](/features/trust-center/) --- # Apache License 2.0: What It Is, How It Works, and What It Means for Your Software URL: https://sbomify.com/2026/01/07/apache-license-2-guide/ Date: 2026-01-07 Description: Understand the Apache License 2.0, its patent grant, attribution requirements, NOTICE file, compatibility with GPL, and how SBOMs track compliance. The Apache License 2.0 is a permissive open source license published by the [Apache Software Foundation](https://www.apache.org/) (ASF) that allows users to freely use, modify, distribute, and sublicense software with minimal restrictions. Its defining features are an explicit patent grant that protects users from patent litigation by contributors, and straightforward attribution requirements through the NOTICE file mechanism. The Apache License 2.0 is one of the most popular open source licenses in the world, used by projects including Apache HTTP Server, Kubernetes, Android (AOSP), TensorFlow, and thousands of others. ## What Is the Apache License 2.0? The Apache License 2.0 (formally, the [Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0)) is a permissive free software license written by the Apache Software Foundation and released in January 2004. "Permissive" means that the license imposes minimal restrictions on how the software can be used, modified, and redistributed – including in proprietary, closed-source products. The Apache License 2.0 replaced the earlier Apache License 1.1 and 1.0, which had more restrictive advertising clauses similar to the original BSD license. Version 2.0 was designed to be clear, comprehensive, and compatible with a broad range of other open source licenses. The license is identified in the [SPDX License List](https://spdx.org/licenses/) as `Apache-2.0`. ## Key Provisions ### Permissions Granted The Apache License 2.0 grants the following rights, in both copyright and patent terms: - **Use** – Run the software for any purpose, including commercial use - **Modify** – Create derivative works based on the software - **Distribute** – Distribute copies of the original or modified software - **Sublicense** – Grant these same rights to others - **Patent use** – Use any patents held by contributors that cover their contributions ### Conditions The license requires: 1. **Attribution.** You must include a copy of the Apache License 2.0 in any distribution and retain all copyright, patent, trademark, and attribution notices from the original source. 2. **NOTICE file.** If the original work includes a NOTICE file (a text file containing attribution notices required by the license), you must include a readable copy of the NOTICE file in your distribution. You may add your own attribution notices to the NOTICE file, but you may not remove existing ones. 3. **State changes.** If you modify the software, you must include a prominent notice stating that you changed the files. ### What Is NOT Required Unlike copyleft licenses such as the [GPL](/2025/12/22/gpl-license-guide/), the Apache License 2.0 does **not** require: - Distributing your source code (you can distribute binaries only) - Licensing your derivative works under the Apache License - Making your modifications open source This is what makes it "permissive" – you can incorporate Apache-licensed code into proprietary software without triggering any obligation to open-source your own code. ## The Patent Grant The Apache License 2.0's explicit patent grant is one of its most important features and a key reason organizations choose it over other permissive licenses like MIT or BSD. Section 3 of the license states that each contributor grants "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable ... patent license" covering the contributor's contributions. This means: - If a contributor holds patents that cover their code contribution, they are granting you a license to those patents for the purpose of using, making, and selling the software. - This protection applies to all users and redistributors of the software. - The patent grant is automatically revoked for any user who initiates patent litigation against the project (the "patent retaliation" clause in Section 3). Neither the [MIT license](/2026/01/22/mit-license-guide/) nor the BSD licenses include an explicit patent grant, which creates theoretical patent risk – a contributor could contribute code and later assert patent claims against users. The Apache License 2.0 eliminates this risk. ## The NOTICE File The NOTICE file is a mechanism unique to the Apache License 2.0 for managing attribution requirements. The Apache Software Foundation [requires](https://www.apache.org/legal/src-headers.html) all ASF projects to include a NOTICE file containing: - The project name and a brief description - Copyright notices from all contributors - Any third-party attribution notices required by dependencies When you redistribute Apache-licensed software, you must include the contents of the NOTICE file in at least one of: - A NOTICE file included with your distribution - Documentation provided alongside the distribution - A display generated by your software (if it has a user-facing display) The NOTICE file is a common source of compliance failures. Organizations that use Apache-licensed components must ensure they carry forward all required attributions, especially when bundling multiple Apache-licensed libraries. ## License Compatibility License compatibility determines whether code from different licenses can be combined in a single work. The Apache License 2.0 has broad compatibility with other open source licenses, but there are notable interactions. | License | Compatible with Apache 2.0? | Notes | | ---------------------------- | --------------------------- | ---------------------------------------------------------------------------------- | | **MIT** | Yes | MIT code can be included in Apache-licensed projects and vice versa | | **BSD (2-clause, 3-clause)** | Yes | Similar permissive terms; no conflict | | **GPL v3** | Yes (one direction) | Apache 2.0 code can be included in GPLv3 projects; the combined work is GPLv3 | | **GPL v2** | No | The Apache 2.0 patent clause is considered an "additional restriction" under GPLv2 | | **LGPL v3** | Yes (one direction) | Similar to GPLv3 compatibility | | **MPL 2.0** | Yes | MPL 2.0 was explicitly designed for compatibility | | **AGPL v3** | Yes (one direction) | Apache 2.0 code can be included in AGPLv3 projects | The GPLv2 incompatibility is historically significant. It means you cannot combine Apache 2.0 code with GPLv2-only code (like the Linux kernel) in a single work. This was one of the issues addressed when GPLv3 was designed to be compatible with Apache 2.0. ## Apache License 2.0 vs. MIT vs. GPL These are the three most commonly encountered open source licenses. Understanding their differences is essential for license compliance. | Feature | Apache 2.0 | MIT | GPL v3 | | ---------------------------- | ----------------- | ------------------ | --------------------------- | | **License type** | Permissive | Permissive | Copyleft | | **Patent grant** | Explicit | None | Explicit | | **Source code required** | No | No | Yes (for distributed works) | | **Derivative works license** | Any license | Any license | Must be GPL | | **Attribution required** | Yes (NOTICE file) | Yes (license text) | Yes (license text + source) | | **Commercial use** | Yes | Yes | Yes | | **SPDX identifier** | `Apache-2.0` | `MIT` | `GPL-3.0-only` | For organizations that want permissive licensing with patent protection, Apache 2.0 is the standard choice. For projects that prioritize simplicity and brevity, MIT is often preferred. For projects that want to ensure all derivatives remain open source, GPL is the appropriate choice. For a broader overview of open source licenses, see our [guide to navigating the landscape of open source licenses](/2024/04/03/navigating-the-landscape-of-open-source-licenses/). ## How SBOMs Track Apache License Compliance A [Software Bill of Materials](/what-is-sbom/) documents every component in your software along with its license. For Apache-licensed components, SBOMs support compliance in several ways: 1. **Identifying Apache-licensed dependencies.** SBOMs include license information for each component, making it straightforward to identify all Apache 2.0 dependencies in your project. The SPDX identifier `Apache-2.0` provides machine-readable identification. 2. **NOTICE file tracking.** By identifying which components are Apache-licensed, SBOMs help teams ensure they are carrying forward all required NOTICE file attributions. 3. **Compatibility checking.** Automated license compliance tools can process SBOMs to detect potential compatibility conflicts – for example, flagging if Apache 2.0 and GPLv2-only components coexist in the same project. 4. **Audit trail.** SBOMs provide the evidence that organizations need for license audits and due diligence in M&A transactions, documenting exactly which licenses are present in a software product. Both [CycloneDX](https://cyclonedx.org/) and [SPDX](https://spdx.dev/) support standardized license fields. The [CISA minimum elements draft](/compliance/cisa-minimum-elements/) includes license as a recommended SBOM field, recognizing that license information is increasingly expected in SBOMs. The [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) automatically enriches SBOMs with license data from multiple sources, making it straightforward to identify all Apache-licensed components in your dependency tree. For language-specific instructions, see our [SBOM generation guides](/guides/). ## Frequently Asked Questions ### What is the Apache License 2.0? The Apache License 2.0 is a permissive open source license published by the Apache Software Foundation. It allows free use, modification, distribution, and sublicensing of the software, including in proprietary products. Its key features are an explicit patent grant protecting users from contributor patent claims, and a NOTICE file mechanism for managing attribution requirements. ### Can I use Apache 2.0 licensed software in commercial products? Yes. The Apache License 2.0 explicitly permits commercial use, including incorporating Apache-licensed code into proprietary, closed-source products. The only requirements are that you include the Apache license text, retain attribution notices, include the NOTICE file if one exists, and note any modifications you made to the original files. ### What is the difference between Apache 2.0 and MIT? Both are permissive licenses that allow commercial use without requiring source code disclosure. The key differences are: Apache 2.0 includes an explicit patent grant and patent retaliation clause, while MIT does not address patents; Apache 2.0 requires carrying forward NOTICE file attributions, while MIT only requires including the license text; and Apache 2.0 requires stating changes to modified files, while MIT does not. ### Is Apache 2.0 compatible with the GPL? Apache 2.0 is compatible with GPL v3 but NOT with GPL v2. Apache 2.0 code can be included in a GPLv3 project (the combined work is licensed under GPLv3), but the Apache 2.0 patent termination clause is considered an "additional restriction" under GPLv2, making the two licenses incompatible. This distinction matters for projects like the Linux kernel, which is GPLv2-only. ### What is the NOTICE file in the Apache License? The NOTICE file is a text file that Apache-licensed projects use to collect attribution notices. It contains the project name, copyright notices, and any third-party attributions required by dependencies. When you redistribute Apache-licensed software, you must include the contents of the NOTICE file with your distribution. Failure to carry forward NOTICE attributions is a common compliance oversight. --- # CRA Explained: What the Cyber Resilience Act Means for Device Manufacturers URL: https://sbomify.com/2026/01/06/cra-explained-cyber-resilience-act-for-device-manufacturers/ Date: 2026-01-06 Description: Podcast episode with EU CRA expert Sarah Fluchs explaining SBOM requirements, the 5-year support mandate, and vulnerability management for device manufacturers. The EU Cyber Resilience Act (CRA) is transforming how device manufacturers approach cybersecurity. To break down what this means in practice, Viktor sat down with Sarah Fluchs on the Nerding Out with Viktor podcast. Sarah isn't just any commentator on the CRA - she serves on the **EU Commission's CRA expert group**, giving her first-hand involvement in shaping this landmark regulation. With a PhD in security-by-design and years of experience in OT (Operational Technology) cybersecurity, she brings a rare blend of technical depth and policy insight. ## SBOMs Are Non-Negotiable for CRA Compliance Sarah is emphatic: **SBOMs are critical for CRA compliance**. The regulation requires manufacturers to maintain full visibility into their software supply chain, and SBOMs are the mechanism to achieve this. But generating quality SBOMs is only half the battle. The real challenge lies in managing them over time - tracking versions, maintaining audit trails, and making software components traceable across complex supply chains. For manufacturers of long-lifecycle hardware, this represents a fundamental operational shift. This is exactly where proper tooling becomes essential. A platform like [sbomify]() addresses these challenges by providing: - **Lifecycle management** - Archive and track SBOMs across product versions and releases - **Centralized portal** - Manage all your security artifacts in one place, with full version history - **Trust Center** - Share SBOMs with stakeholders (customers, auditors, regulators) through a branded portal - **CI/CD integration** - Generate SBOMs automatically in your pipeline and upload them to sbomify ## The 5-Year Support Requirement Changes Everything The CRA mandates security updates for the expected product lifetime, with a **minimum of five years**. For OT devices that often operate for 20+ years, this forces companies to fundamentally rethink their approach. This isn't just about patching - it's about maintaining comprehensive records of what software was shipped, when, and to whom. You need to be able to answer: "What components were in version 2.3.1 that we shipped in 2024?" years down the line. This is where SBOM archiving becomes critical. With sbomify, every release is captured and stored, creating an auditable trail that satisfies CRA's documentation requirements without manual tracking. ## Vulnerability Management at Scale Manufacturers must establish robust vulnerability handling processes, including responsible disclosure mechanisms. Sarah notes that the hardest part isn't formal reporting - it's building an efficient system to triage the influx of vulnerability reports. sbomify integrates with vulnerability databases like [Google OSV](/features/integrations/) and [Dependency Track](/features/integrations/), allowing you to continuously monitor your archived SBOMs for newly discovered vulnerabilities - even for products shipped years ago. ## Sarah's Key Message > "CRA compliance isn't about ticking boxes. Done right, it's a path to stronger engineering practices, deeper supply chain accountability, and better product security." Her advice for manufacturers getting started: 1. **Find your showstoppers early** - Run your products through the CRA requirements now to identify major blockers 2. **Start your risk assessment** - This is the linchpin that informs all other decisions 3. **Establish vulnerability handling** - Build the processes to manage the influx of security information ## Listen to the Full Episode - [Full episode with transcript](https://vpetersson.com/podcast/S02E21.html) - [YouTube](https://www.youtube.com/watch?v=e9_bpsJKOL0) - [Spotify](https://open.spotify.com/show/2eoSJgEN0YOgshqYkqnX2B) - [Apple Podcasts](https://podcasts.apple.com/podcast/nerding-out-with-viktor/id1722663668) - [Amazon Music](https://music.amazon.com/podcasts/c2443912-6c23-4ce9-804c-4caa827f63d7/nerding-out-with-viktor) ## Get CRA-Ready with sbomify The CRA deadline is approaching fast. [sbomify]() gives you the infrastructure to generate, manage, and share SBOMs throughout your product lifecycle - whether you're shipping embedded devices, IoT products, or enterprise software. [Get started free →](https://app.sbomify.com) ## Related Resources - [EU Cyber Resilience Act - Official EU page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) - [Why Now? CRA is Coming](/features/why-now/) - [Understanding the EU Cyber Resilience Act: The Role of SBOMs](/2024/07/10/understanding-the-eu-cyber-resilience-act-the-role-of-sboms-in-enhancing-cybersecurity/) --- # Container Security: Best Practices for Securing Docker and Kubernetes URL: https://sbomify.com/2026/01/03/container-security-best-practices/ Date: 2026-01-03 Description: A comprehensive guide to container security covering image scanning, runtime protection, network policies, and how SBOMs provide component visibility. Container security is the practice of protecting containerized applications and their infrastructure throughout the entire lifecycle – from building container images through deployment and runtime operations. Containers package applications with their dependencies into isolated units, but this isolation does not automatically equal security. Every layer of a container image, from the base operating system to application dependencies, represents a potential attack surface that must be managed. ![Container image layers with separate SBOMs feeding into security controls](/assets/images/d2/container-security-layers.svg) ## What Is Container Security? Container security encompasses the tools, practices, and policies used to protect containerized workloads. Unlike traditional application security, container security must address concerns at multiple layers: the container image, the container runtime, the orchestration platform (typically Kubernetes), the host operating system, and the network. Containers have become the standard deployment model for cloud-native applications. According to the [Cloud Native Computing Foundation](https://www.cncf.io/), the majority of organizations now run containerized workloads in production. This widespread adoption makes container security a critical discipline – a compromised container image pulled from a public registry can affect thousands of deployments. The challenge is compounded by the ephemeral nature of containers. Unlike traditional servers that persist for months or years, containers may exist for seconds or minutes. Security practices must be automated and embedded into the build and deployment pipeline rather than applied manually. ## Container Image Security The container image is the foundation of container security. An image that ships with known vulnerabilities, outdated packages, or unnecessary components creates risk before the container even starts. ### Base Image Selection The choice of base image has an outsized impact on security. A full Linux distribution (like Ubuntu or Debian) may include hundreds of packages that your application never uses but that increase the attack surface. Minimal base images reduce this risk. | Base Image Type | Packages | Attack Surface | Use Case | | ------------------------------------------------------------------------------ | ---------------------------------- | -------------- | ------------------------------------------------------- | | **Distroless** (e.g., `gcr.io/distroless`) | Application runtime only | Minimal | Production workloads | | **[Chainguard Images](https://www.chainguard.dev/chainguard-images)** | Minimal, zero/low-CVE packages | Minimal | Production workloads, compliance-sensitive environments | | **[Docker Hardened Images](https://www.docker.com/products/hardened-images/)** | Distroless Debian/Alpine, non-root | Minimal | Production workloads, regulated environments | | **Alpine Linux** | ~15 MB base, musl libc | Small | General purpose, size-sensitive | | **Slim variants** (e.g., `python:3.12-slim`) | Stripped-down distribution | Medium | Language-specific applications | | **Full distribution** (e.g., `ubuntu:24.04`) | Full package set | Large | Development, debugging | For production, prefer hardened, distroless, or slim images. Fewer packages means fewer potential vulnerabilities and a smaller SBOM – making both security management and compliance simpler. Two hardened image providers stand out for security-conscious teams: [Chainguard Images](https://www.chainguard.dev/chainguard-images) are built from the ground up on [Wolfi](https://github.com/wolfi-dev), a Linux distribution designed specifically for containers. They are rebuilt daily, ship with zero or near-zero known CVEs, and include high-quality SBOMs out of the box. Available as drop-in replacements for popular base images like Python, Node.js, and Go. [Docker Hardened Images](https://www.docker.com/products/hardened-images/) (DHI) take a different approach – hardening familiar Debian and Alpine bases by stripping them down to distroless principles (no shell, no package manager, non-root by default). Docker [made the full catalog of 1,000+ images free and open source](https://www.docker.com/blog/docker-hardened-images-for-every-developer/) under Apache 2.0 in late 2025. Every image ships with an SBOM, [SLSA](https://slsa.dev/) Build Level 3 provenance, and [VEX](https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex) metadata. The Enterprise tier adds FIPS-enabled and STIG-hardened variants for regulated environments. ### Image Scanning Container image scanning analyzes the contents of an image for known vulnerabilities by matching installed packages and libraries against vulnerability databases like the [NVD](https://nvd.nist.gov/) and [OSV](https://osv.dev/). Key scanning tools include: - **[Trivy](https://github.com/aquasecurity/trivy)** – Open source scanner from Aqua that detects vulnerabilities in OS packages, language-specific dependencies, and misconfigurations (note: we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following two successful supply chain attacks in March 2026 and have removed it from sbomify-action) - **[Grype](https://github.com/anchore/grype)** – Open source vulnerability scanner from Anchore - **[Snyk Container](https://snyk.io/product/container-vulnerability-management/)** – Commercial scanner with developer workflow integration Scanning should happen at multiple points: during the CI/CD build, before images are pushed to a registry, and continuously against images already in production (since new vulnerabilities are disclosed daily). ### Container SBOMs: Separate Layers, Separate SBOMs A containerized application has two distinct layers with different component profiles: the **base image layer** (OS packages, system libraries) and the **application layer** (your code's dependencies from lock files). Rather than combining everything into a single monolithic SBOM, the best practice is to generate **separate SBOMs for each layer** and organize them hierarchically. This separation matters for several reasons: - **Different update cadences.** Base image packages change when you rebuild with a new base image; application dependencies change when you update your lock file. Separate SBOMs let you track each independently. - **Different vulnerability profiles.** A glibc vulnerability in the base image is a different remediation path than a vulnerability in an npm package. Separate SBOMs make triage clearer. - **Cleaner compliance.** Compliance reviewers can evaluate OS-level and application-level components independently, with the correct tool and context for each. The [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) supports this workflow directly – generate an Application SBOM from your lock file and a Container SBOM from the built image, then organize both under a single product using sbomify's [Product → Component hierarchy](/features/sbom-hierarchy/). For step-by-step instructions, see our [Docker SBOM guide](/guides/docker/). ## Runtime Security Image scanning catches known vulnerabilities before deployment, but runtime security protects against exploitation of unknown flaws, misconfigurations, and malicious behavior during execution. ### Principle of Least Privilege Containers should run with the minimum permissions required: - **Run as non-root.** The default user in many container images is root. Always specify a non-root user in your Dockerfile (`USER nonroot`) or enforce this via Kubernetes security contexts. - **Drop capabilities.** Linux capabilities grant fine-grained privileges. Drop all capabilities and add back only those required (`--cap-drop=ALL --cap-add=NET_BIND_SERVICE`). - **Read-only filesystem.** Mount the container filesystem as read-only where possible (`--read-only`), using tmpfs mounts for directories that require writes. - **No privilege escalation.** Set `allowPrivilegeEscalation: false` in Kubernetes security contexts to prevent processes from gaining additional privileges. ### Secrets Management Never bake secrets (API keys, database credentials, certificates) into container images. Images are stored in registries and can be inspected by anyone with access. Instead: - Use Kubernetes Secrets or a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager) - Mount secrets as files or environment variables at runtime - Rotate secrets regularly and audit access ### Runtime Monitoring Runtime security tools observe container behavior and detect anomalies: - **Unexpected processes** – A web server container suddenly running a shell may indicate compromise - **Unusual network connections** – Outbound connections to unknown IP addresses - **File system modifications** – Changes to binaries or configuration files in a read-only container - **Privilege escalation attempts** – Attempts to gain root access ## Kubernetes Security For organizations running containers at scale, Kubernetes introduces its own security considerations. ### Network Policies By default, Kubernetes allows all pod-to-pod communication within a cluster. Network policies restrict this to only the connections that are necessary: - Isolate namespaces so that development and production workloads cannot communicate - Restrict ingress to only the pods that need to receive traffic - Restrict egress to only the external services that pods need to reach ### Pod Security Standards Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) define three levels of restriction: - **Privileged** – Unrestricted (use only when necessary) - **Baseline** – Prevents known privilege escalations - **Restricted** – Hardened configuration following security best practices Enforce at least the Baseline level for all production workloads. Use the Restricted level where possible. ### Supply Chain Security for Images Ensure that only trusted, scanned images run in your cluster: - Use a private container registry with access controls - Sign images and verify signatures before deployment (using tools like [Sigstore cosign](https://docs.sigstore.dev/cosign/)) - Implement admission controllers that reject unsigned or unscanned images - Pin images to specific digests rather than mutable tags (`:latest` can change without notice) - Consider using hardened base images from [Chainguard](https://www.chainguard.dev/chainguard-images) or [Docker Hardened Images](https://www.docker.com/products/hardened-images/) that ship with built-in SBOMs, provenance attestations, and near-zero CVEs ## Container Security and SBOMs SBOMs play a central role in container security by providing the component visibility needed for effective vulnerability management. ### Why Separate Container SBOMs Matter A typical container image may contain hundreds of packages across multiple layers. Without SBOMs, identifying whether a newly disclosed vulnerability affects your containers requires manual investigation of each image – a process that does not scale. With separate SBOMs for each container layer, organized in a [hierarchical structure](/features/sbom-hierarchy/): - **[Vulnerability scanning](/2026/02/01/sbom-scanning-vulnerability-detection/) becomes targeted.** Match base image SBOMs against OS-level advisories and application SBOMs against language-specific vulnerability databases ([NVD](https://nvd.nist.gov/), [OSV](https://osv.dev/), [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)). - **Incident response accelerates.** When a new critical [CVE](/2025/12/18/cve-vulnerability-explained/) is disclosed, query your SBOM repository to immediately identify affected images – and know whether the vulnerability is in the base image or your application dependencies. - **Compliance requirements are met.** The [EU CRA](/compliance/eu-cra/) and [EO 14028](/compliance/eo-14028/) require component documentation for software products, including containerized applications. - **Base image risk is visible.** Container SBOMs expose the [dependency](/2026/01/29/what-is-a-dependency-in-software/) chain inherited from base images that developers may not be aware of, kept separate from application-level components for clarity. For detailed instructions on generating separate SBOMs from container images, see our [Docker SBOM guide](/guides/docker/). For a broader overview of SBOM tools, see our [resources page](/resources/). ## Best Practices 1. **Scan images at every stage.** Integrate scanning into CI/CD (build-time), the container registry (push-time), and production (runtime). New vulnerabilities are disclosed daily – a clean image today may be vulnerable tomorrow. 2. **Use hardened or minimal base images.** Choose hardened images ([Chainguard](https://www.chainguard.dev/chainguard-images), [Docker Hardened Images](https://www.docker.com/products/hardened-images/)), distroless, or slim variants for production. Fewer packages means fewer vulnerabilities and a smaller attack surface. 3. **Generate separate SBOMs per layer.** Generate an application SBOM from your lock file and a container SBOM from the built image. Organize both under a single product in your [SBOM management platform](/2026/01/18/sbom-management-best-practices/) for continuous vulnerability monitoring. 4. **Run containers as non-root.** Never run production containers as the root user. Configure security contexts to drop unnecessary capabilities and prevent privilege escalation. 5. **Implement network policies.** Do not rely on default allow-all networking. Define explicit network policies that restrict communication to only what is required. 6. **Sign and verify images.** Use image signing to establish provenance and prevent deployment of tampered images. Verify signatures with admission controllers in Kubernetes. 7. **Keep base images up to date.** Regularly rebuild images with updated base layers to pick up security patches. Automate this with scheduled rebuilds in your CI/CD pipeline. 8. **Manage secrets properly.** Never embed secrets in images. Use dedicated secrets management tools and mount secrets at runtime. ## Frequently Asked Questions ### What is container security? Container security is the practice of protecting containerized applications and their infrastructure throughout the lifecycle – from building images through deployment and runtime operations. It encompasses image scanning, vulnerability management, runtime protection, network policies, secrets management, and access control for container orchestration platforms like Kubernetes. ### How do you scan container images for vulnerabilities? Container images are scanned by analyzing their contents (OS packages, language libraries, application dependencies) against vulnerability databases like the NVD and OSV. Tools like ~~Trivy~~ ([compromised March 2026](/2026/03/26/trivy-compromise-hardening-sbomify-action/)), Grype, and Snyk perform this analysis. Scanning should be integrated into CI/CD pipelines, container registries, and production monitoring to catch vulnerabilities at every stage. ### What is a container SBOM? A container SBOM is a Software Bill of Materials generated from a built container image, documenting the OS-level packages and system libraries in the base image. Best practice is to generate this separately from your application SBOM (which covers your code's dependencies from lock files) and organize both under a product hierarchy. This separation keeps vulnerability triage and compliance clear. See our [Docker SBOM guide](/guides/docker/) for detailed instructions on generating separate SBOMs for each layer. ### How does Kubernetes improve container security? Kubernetes provides security mechanisms including Pod Security Standards (restricting container privileges), Network Policies (controlling pod-to-pod communication), RBAC (role-based access control), Secrets management, and admission controllers (enforcing policies on what can be deployed). These features must be actively configured – Kubernetes defaults are permissive. ### Why should containers run as non-root? Running containers as root means that a compromise of the application gives the attacker root privileges inside the container, which in some configurations can lead to host escape. Running as a non-root user limits the blast radius of a compromise. Combined with dropping capabilities and setting `allowPrivilegeEscalation: false`, non-root containers significantly reduce risk. --- # What Is a KEV? Understanding CISA's Known Exploited Vulnerabilities Catalog URL: https://sbomify.com/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/ Date: 2025-12-30 Description: What is a KEV? CISA's Known Exploited Vulnerabilities catalog lists CVEs under active attack. Learn how KEV differs from CVE and CVSS, and how SBOMs automate KEV monitoring. A KEV – Known Exploited Vulnerability – is a vulnerability that attackers are exploiting _right now_. When Apache Log4Shell ([CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)) surfaced in December 2021, it took CISA just days to add it to the [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). That single listing told every organization in the world: this is not theoretical – patch now. The KEV catalog, maintained by the Cybersecurity and Infrastructure Security Agency, is the authoritative registry of CVEs with confirmed active exploitation. While CVE databases catalog all publicly known flaws and CVSS scores estimate theoretical severity, the KEV catalog answers a more urgent question: _is this vulnerability being exploited right now?_ ![Vulnerability prioritization flow from CVE through CVSS and KEV to SBOM-based remediation](/assets/images/d2/vulnerability-prioritization.svg) ## What Is the KEV Catalog? The CISA KEV catalog is a curated list of [CVE](/2025/12/18/cve-vulnerability-explained/) vulnerabilities that have reliable evidence of active exploitation. CISA launched the catalog in November 2021 alongside [Binding Operational Directive (BOD) 22-01](https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities), which requires U.S. federal civilian executive branch (FCEB) agencies to remediate KEV-listed vulnerabilities within specified timeframes. The catalog started with roughly 300 entries at launch, grew past 1,000 by late 2023, and contained approximately 1,500 entries as of early 2026. CISA adds new vulnerabilities multiple times per week as exploitation evidence is confirmed, and each entry includes: - **CVE ID** identifying the vulnerability - **Vendor and product** affected - **Vulnerability name** and description - **Date added** to the catalog - **Due date** for federal agency remediation - **Required action** (typically "Apply updates per vendor instructions") - **Known ransomware campaign use** (yes/no flag) The catalog is freely available as a [JSON feed](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json), a [CSV download](https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv), and through the CISA website. ## KEV vs. CVE vs. CVSS: How They Work Together These three systems are complementary, not competing. Each answers a different question in the vulnerability management process. | System | Question It Answers | Maintained By | Output | | -------- | -------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------- | | **CVE** | What is this vulnerability? | [MITRE Corporation](https://www.cve.org/) | Unique identifier (e.g., CVE-2021-44228) | | **CVSS** | How severe is this vulnerability? | [FIRST.org](https://www.first.org/cvss/) | Severity score (0.0-10.0) | | **KEV** | Is this vulnerability being exploited? | [CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) | Binary yes/no (listed or not) | A CVE tells you a vulnerability exists. CVSS tells you how bad it _could_ be. KEV tells you it _is_ being exploited. Effective vulnerability prioritization uses all three signals together. ### A Worked Example: Log4Shell Consider [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), the Log4Shell vulnerability in Apache Log4j: - **CVE ID:** CVE-2021-44228 – assigned by MITRE, giving the flaw a unique, trackable identifier - **CVSS score:** 10.0 (Critical) – the maximum possible score, reflecting remote code execution with no authentication required - **KEV status:** Added to the KEV catalog on December 10, 2021, just days after public disclosure All three systems describe the same vulnerability, but each contributes different information. The CVE provides a common name. The [CVSS score](/2026/02/05/what-is-cvss-vulnerability-scoring/) quantifies theoretical severity. The KEV listing confirms that attackers were already exploiting it in the wild, making it an immediate priority rather than a theoretical risk. Now consider two vulnerabilities, both with CVSS scores of 9.8 (Critical). One is listed in the KEV catalog; the other is not. The KEV-listed vulnerability should be patched first because there is confirmed evidence of active exploitation, whereas the other – while theoretically severe – may not have working exploits in circulation. Beyond these three systems, [EPSS](https://www.first.org/epss/) (Exploit Prediction Scoring System) offers a forward-looking probability estimate of exploitation. Used alongside KEV, EPSS can help identify vulnerabilities that are _likely_ to be exploited soon, even before CISA confirms active exploitation. For more on how CVSS and EPSS complement each other, see our [CVSS scoring guide](/2026/02/05/what-is-cvss-vulnerability-scoring/). ## Binding Operational Directive 22-01 [BOD 22-01](https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities) ("Reducing the Significant Risk of Known Exploited Vulnerabilities") is the CISA directive that established the KEV catalog's operational role. It covers over 100 federal civilian executive branch agencies and requires them to: 1. **Review** the KEV catalog on an ongoing basis 2. **Remediate** each KEV vulnerability by the due date specified in the catalog 3. **Report** their remediation status to CISA While BOD 22-01 only legally binds federal civilian agencies, CISA strongly recommends that all organizations – including state and local governments, critical infrastructure operators, and private sector companies – use the KEV catalog as a prioritization input for their vulnerability management programs. The remediation timelines in BOD 22-01 are aggressive. Vulnerabilities added to the KEV catalog since early 2022 typically carry a remediation deadline of 14 days from the date of addition, though some early entries in the catalog had longer windows of up to six months. This reflects the urgency: if a vulnerability is being actively exploited, delayed patching means continued exposure. ## How the KEV Catalog Is Maintained CISA adds vulnerabilities to the KEV catalog based on three criteria, all of which must be met: 1. **The vulnerability has an assigned CVE ID.** Only cataloged vulnerabilities with standard identifiers qualify. 2. **There is reliable evidence of active exploitation.** CISA draws this evidence from multiple sources: federal agency incident reports, industry partners, commercial and open-source threat intelligence feeds, and cybersecurity researchers. 3. **A clear remediation action exists.** Typically this means a vendor patch or mitigation is available. CISA does not add vulnerabilities for which there is no known fix, as doing so would disclose exploited flaws without offering a path to resolution. A high CVSS score alone is _not_ enough for KEV inclusion. A vulnerability can be rated Critical (9.0+) and still not appear in the KEV catalog if CISA lacks evidence of active exploitation. Conversely, a Medium-severity vulnerability _can_ be added to the KEV catalog if attackers are exploiting it in the wild. The criterion is exploitation evidence, not theoretical severity. Vulnerabilities are rarely removed from the KEV catalog once added – even after the remediation deadline passes. While CISA has removed entries in rare cases where evidence of exploitation was later found insufficient, the catalog serves primarily as a persistent historical record of exploitation activity. ## Using the KEV Catalog for Patch Prioritization Most organizations face far more vulnerabilities than they can patch simultaneously. The KEV catalog provides a practical prioritization signal that cuts through the noise. With approximately 245 KEVs added in 2025 alone – roughly 20% growth in a single year – the pace of confirmed exploitation is increasing, making principled prioritization more important than ever. ### A Prioritization Framework A common approach combines CVSS severity with KEV status and deployment context: 1. **Critical + KEV-listed + Internet-facing** – Patch immediately (within 24-48 hours) 2. **Critical + KEV-listed + Internal** – Patch within the BOD 22-01 deadline (typically 14 days) 3. **Critical + Not KEV-listed** – Patch within standard SLA (typically 30 days) 4. **High + KEV-listed** – Treat as critical; patch within 14 days 5. **High + Not KEV-listed** – Patch within standard SLA 6. **Medium/Low + Not KEV-listed** – Schedule for regular maintenance windows This framework is a starting point. Organizations should adjust based on their risk tolerance, asset criticality, and compensating controls. Adding [EPSS](https://www.first.org/epss/) as a forward-looking signal can further refine prioritization: a vulnerability with a high EPSS score that is not yet in the KEV catalog may still warrant accelerated patching. ### The Ransomware Flag Since October 2023, CISA has included a "Known Ransomware Campaign Use" flag in KEV entries, as part of its Ransomware Vulnerability Warning Pilot (RVWP). This binary indicator (yes/no) signals whether the vulnerability has been used in ransomware operations. Vulnerabilities flagged for ransomware use warrant heightened urgency due to the potential for data encryption and operational disruption. ## KEV and SBOMs: Automated Monitoring The real power of the KEV catalog emerges when combined with [SBOMs](/what-is-sbom/). An SBOM provides a machine-readable inventory of every component in your software. The KEV catalog provides a machine-readable list of actively exploited vulnerabilities. Connecting the two creates automated, continuous monitoring. The logic is straightforward: you cannot check your components against the KEV catalog if you do not know what components you have. Without an SBOM, responding to a new KEV entry means manually investigating every application to determine whether it uses the affected library or product. With SBOMs, you can answer that question in seconds across your entire portfolio. ### How It Works 1. **Generate SBOMs** for all your applications using tools from our [SBOM generation guides](/guides/) 2. **Ingest SBOMs** into a management platform such as [sbomify](https://sbomify.com) or [OWASP Dependency-Track](https://dependencytrack.org/) 3. **Run vulnerability analysis** – tools like Google OSV and Dependency-Track identify known CVEs in your SBOM components 4. **Cross-reference with KEV** – check which of those CVEs appear in the KEV catalog to identify actively exploited vulnerabilities 5. **Prioritize remediation** using the KEV due date and your deployment context Because CISA adds new KEVs multiple times per week, building this cross-referencing into your workflow is important. The KEV catalog's machine-readable formats make this feasible to automate. For a deeper look at building this pipeline, see our guide on [SBOM scanning for vulnerability detection](/2026/02/01/sbom-scanning-vulnerability-detection/). ### Integration Points Several tools and data sources support KEV-SBOM workflows: - **[sbomify](https://sbomify.com)** – SBOM management platform with vulnerability analysis via Google OSV integration - **[CISA KEV JSON feed](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)** – Machine-readable, updated as new KEVs are added - **[OWASP Dependency-Track](https://dependencytrack.org/)** – Ingests SBOMs and performs vulnerability analysis using multiple data sources - **[Grype](https://github.com/anchore/grype)** – Command-line vulnerability scanner that can match against vulnerability data - **[OSV](https://osv.dev/)** – Google's open source vulnerability database For a comprehensive list of analysis tools, see our [SBOM resources page](/resources/). ## KEV in the Compliance Context The KEV catalog intersects with several compliance frameworks: - **[Executive Order 14028](/compliance/eo-14028/)** directs agencies to improve vulnerability management, and KEV provides the prioritization mechanism. - **[CISA minimum elements](/compliance/cisa-minimum-elements/)** recommend unique identifiers (like purl or CPE) in SBOMs, enabling automated matching against KEV entries. - **[NIST SP 800-53](/compliance/nist-800-53/) SI-5** requires receiving and acting on security alerts and advisories – the KEV catalog is a primary source for this control. - **[EU CRA](/compliance/eu-cra/)** requires vulnerability handling processes, and KEV status is a valuable input for prioritizing which vulnerabilities to address first. ## Notable KEVs and Real-World Impact A few high-profile KEV entries illustrate why the catalog matters and how quickly confirmed exploitation can escalate. **Log4Shell (CVE-2021-44228)** – Added to the KEV catalog in December 2021, Log4Shell was one of the most consequential vulnerabilities in the catalog's early history. A remote code execution flaw in the ubiquitous Apache Log4j logging library, it affected hundreds of thousands of applications worldwide. Mass exploitation began within hours of public disclosure, and the vulnerability remains a common attack vector years later. **MOVEit Transfer (CVE-2023-34362)** – Added in June 2023, this SQL injection vulnerability in Progress Software's MOVEit Transfer file-sharing platform was exploited at scale by the Cl0p ransomware group. The campaign compromised over 2,500 organizations and exposed data belonging to tens of millions of individuals, making it one of the largest mass-exploitation events linked to a single KEV entry. **XZ Utils (CVE-2024-3094)** – Added in April 2024, this was not a conventional exploit but a deliberate supply chain backdoor planted in the XZ compression library by a contributor who spent years building trust in the open-source project. It was discovered just before shipping in major Linux distributions, narrowly averting a widespread compromise. Its KEV listing underscored that the catalog also tracks supply chain threats when exploitation evidence is confirmed. These cases share a common thread: each affected widely used software, each was exploited rapidly after (or even before) public disclosure, and each would have been easier to triage for organizations that maintained current SBOMs of their software components. ## Frequently Asked Questions ### What is a KEV? A KEV (Known Exploited Vulnerability) is a CVE vulnerability that CISA has confirmed is being actively exploited in real-world attacks. The CISA KEV catalog lists these vulnerabilities along with remediation deadlines and required actions. Being listed in the KEV catalog means the vulnerability is not just theoretically dangerous – it is being used by attackers right now. ### What is the KEV catalog? The CISA Known Exploited Vulnerabilities Catalog is a curated, continuously updated list of CVE vulnerabilities with confirmed active exploitation. Established by Binding Operational Directive 22-01, it requires U.S. federal agencies to remediate listed vulnerabilities within specified timeframes. The catalog is freely available as JSON, CSV, and via the CISA website, and is widely used by both government and private sector organizations for patch prioritization. ### How is KEV different from CVE? CVE is a system for assigning unique identifiers to all publicly known vulnerabilities, regardless of whether they are being exploited. The KEV catalog is a curated subset of CVEs that have confirmed evidence of active exploitation. There are over 330,000 CVE entries but only about 1,500 KEV entries. A CVE tells you a vulnerability exists; a KEV listing tells you attackers are actively using it. ### Who must comply with the KEV catalog? BOD 22-01 legally requires U.S. federal civilian executive branch (FCEB) agencies to remediate KEV-listed vulnerabilities by the specified due dates. However, CISA strongly recommends that all organizations use the KEV catalog for prioritization. Many private sector organizations, state and local governments, and critical infrastructure operators have adopted KEV as a standard input to their vulnerability management programs. ### How can I monitor the KEV catalog automatically? Generate SBOMs for your applications, ingest them into a vulnerability management platform like OWASP Dependency-Track, and use vulnerability analysis to identify known CVEs in your components. Then cross-reference those CVEs against the KEV catalog. CISA publishes the KEV catalog as a machine-readable [JSON feed](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) that can be consumed by automated tools. ### How often is the KEV catalog updated? CISA updates the KEV catalog multiple times per week. New vulnerabilities are added as soon as CISA confirms reliable evidence of active exploitation and verifies that a remediation action exists. There is no fixed schedule – additions are driven by threat intelligence, so the catalog may see several updates in a single week or occasional pauses. ### How many vulnerabilities are in the KEV catalog? As of early 2026, the KEV catalog contains approximately 1,500 entries. The catalog launched with about 300 entries in November 2021, passed 1,000 in late 2023, and has been growing at roughly 20% per year. Despite this growth, the KEV catalog remains a small fraction of the 330,000+ CVEs in the broader vulnerability ecosystem – which is precisely what makes it useful for prioritization. --- # Software Supply Chain Management: Risks, Best Practices, and SBOM Integration URL: https://sbomify.com/2025/12/26/software-supply-chain-management/ Date: 2025-12-26 Description: Learn what software supply chain management is, how attacks like Log4Shell and XZ Utils exploit it, and how SBOMs provide visibility and risk reduction. Software supply chain management is the practice of identifying, assessing, and mitigating risks across the entire chain of components, tools, and processes used to develop and deliver software. A software supply chain encompasses everything that contributes to a finished application: open source libraries, third-party services, build tools, package registries, CI/CD pipelines, and the people and processes that connect them. Managing this chain is essential because a vulnerability or compromise at any point can propagate downstream to every consumer of the software. ![Software supply chain from upstream dependencies through build to downstream consumers](/assets/images/d2/supply-chain-risk.svg) ## What Is a Software Supply Chain? A software supply chain is the complete set of components, dependencies, tools, and workflows involved in creating, building, and distributing a piece of software. Just as a physical supply chain traces the path of raw materials through manufacturing to a finished product, a software supply chain traces the path of code from its origins to its deployment. Modern applications are overwhelmingly assembled rather than written from scratch. Studies consistently show that [70-90% of a typical application consists of open source components](https://www.linux.com/training-tutorials/estimating-total-number-linux-contributors-approach-using-linus-law/) drawn from public package registries like npm, PyPI, Maven Central, and crates.io. Each of these components has its own dependencies, creating a deep tree of transitive dependencies that most development teams never manually audit. This reality makes software supply chain risk management (SSCRM) a critical discipline. If a single component in your dependency tree is compromised, vulnerable, or abandoned, the risk flows directly into your application and to your users. ## Chain of Custody in Software Chain of custody is a concept borrowed from forensics and physical supply chains. In the software context, chain of custody refers to the documented trail that records who created, modified, built, and distributed each component in a software product. A robust chain of custody answers questions like: - Where did this component originate? - Who authored and maintained it? - Was it modified between the source repository and the package registry? - Was the build process reproducible and tamper-evident? [Software Bills of Materials](/what-is-sbom/) (SBOMs) provide the component-level inventory that underpins chain of custody. Frameworks like [SLSA](/2024/08/17/what-is-slsa/) (Supply-chain Levels for Software Artifacts) and [in-toto](https://in-toto.io/) add attestation layers that cryptographically verify each step in the build process. ## Major Software Supply Chain Attacks Several high-profile incidents have demonstrated the consequences of supply chain compromise. ### SolarWinds (2020) Attackers compromised the build system of SolarWinds' Orion IT monitoring platform, injecting malicious code into a routine software update. Approximately 18,000 organizations, including U.S. government agencies, installed the compromised update. The attack was attributed to a state-sponsored actor and went undetected for months. It demonstrated that compromising a single widely-used vendor can provide access to thousands of downstream organizations. ### Log4Shell (2021) [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), known as Log4Shell, was a critical remote code execution vulnerability in Apache Log4j, a ubiquitous Java logging library. The vulnerability affected millions of applications worldwide. Organizations without component inventories struggled for weeks to determine whether they were affected. This incident became the single most cited argument for SBOM adoption: organizations with SBOMs could identify affected systems in minutes. ### XZ Utils Backdoor (2024) [CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094) revealed a deliberately planted backdoor in the XZ Utils compression library, a component present in virtually every Linux distribution. A malicious contributor spent years building trust in the project before inserting the backdoor. This attack showed that supply chain risks include not just accidental vulnerabilities but intentional sabotage through social engineering of open source maintainers. ### Common Attack Vectors | Attack Vector | Description | Example | | --------------------------- | ----------------------------------------------------------------------- | --------------------------------------- | | **Build system compromise** | Injecting malicious code during the build/CI process | SolarWinds | | **Dependency confusion** | Publishing malicious packages with names that overlap internal packages | Multiple incidents across npm, PyPI | | **Typosquatting** | Publishing packages with names similar to popular libraries | Thousands of examples across registries | | **Maintainer compromise** | Gaining control of a legitimate package through social engineering | XZ Utils | | **Vulnerable dependency** | Exploiting a known vulnerability in a widely-used component | Log4Shell | ## Software Supply Chain Risk Management Frameworks Several frameworks provide structured approaches to managing software supply chain risk. ### NIST C-SCRM (SP 800-161 Rev 1) [NIST SP 800-161 Rev 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final) ("Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations") provides the most comprehensive federal guidance on supply chain risk. It builds on the [NIST SP 800-53](/compliance/nist-800-53/) control framework, particularly the SR (Supply Chain Risk Management) family, and provides detailed practices for identifying, assessing, and mitigating supply chain risks throughout the system development life cycle. ### Executive Order 14028 [Executive Order 14028](/compliance/eo-14028/) ("Improving the Nation's Cybersecurity", 2021) directed federal agencies to enhance software supply chain security, including requiring SBOMs from software vendors and establishing the [NTIA minimum elements](/compliance/ntia-minimum-elements/) for SBOM content. ### EU Cyber Resilience Act The [EU Cyber Resilience Act](/compliance/eu-cra/) (CRA) requires manufacturers of products with digital elements to identify and document vulnerabilities and components, including providing SBOMs. The CRA makes software supply chain transparency a legal obligation for products sold in the EU market. ### SLSA Framework [SLSA](https://slsa.dev/) (Supply-chain Levels for Software Artifacts) is a framework from the [OpenSSF](https://openssf.org/) that defines three levels of build security maturity in the current [v1.0 specification](https://slsa.dev/spec/v1.0/levels). Each level adds protections: from documenting build provenance (Level 1) through using a hosted build platform (Level 2) to hardened, tamper-resistant builds (Level 3). ## How SBOMs Support Supply Chain Management An [SBOM](/what-is-sbom/) is the foundational tool for software supply chain visibility. Without knowing what components are in your software, you cannot assess supply chain risk. SBOMs support supply chain management in several ways: 1. **Component visibility.** SBOMs provide a complete inventory of every library, framework, and module in your application, including transitive dependencies that developers may not be aware of. 2. **Vulnerability identification.** Once you have an SBOM, platforms like [sbomify](https://sbomify.com) and [OWASP Dependency-Track](https://dependencytrack.org/) can continuously match your components against vulnerability databases like the [NVD](https://nvd.nist.gov/) and [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). 3. **License compliance.** SBOMs document the license of each component, enabling automated detection of copyleft or restrictive licenses that may create legal obligations. See our [GPL license guide](/2025/12/22/gpl-license-guide/) for details on copyleft compliance. 4. **Incident response.** When a new vulnerability is disclosed, SBOMs allow you to immediately determine which of your products are affected, drastically reducing response time. 5. **Regulatory compliance.** Multiple frameworks now require or strongly recommend SBOMs, including [EO 14028](/compliance/eo-14028/), the [EU CRA](/compliance/eu-cra/), and [FDA medical device guidance](/compliance/fda-medical-device/). See our [compliance guide](/compliance/) for a complete comparison. To start generating SBOMs for your projects, see our [language-specific SBOM guides](/guides/) covering Python, JavaScript, Java, Go, Rust, and more. ## Best Practices for Software Supply Chain Security 1. **Generate and maintain SBOMs.** Automate SBOM generation in your CI/CD pipeline using tools like the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/). Keep SBOMs current with every release. 2. **Monitor dependencies continuously.** Do not rely on point-in-time audits. Use SBOM-based monitoring to catch newly disclosed vulnerabilities in your deployed components. 3. **Verify component provenance.** Use signed packages, verify checksums, and adopt frameworks like SLSA to ensure components have not been tampered with between source and deployment. 4. **Minimize your dependency footprint.** Fewer dependencies mean a smaller attack surface. Regularly review and remove unused dependencies. Prefer well-maintained libraries with active security response processes. 5. **Pin and lock dependencies.** Use lock files to ensure reproducible builds and prevent unexpected dependency updates. Review dependency changes before merging. 6. **Establish a vulnerability response process.** Define SLAs for patching based on severity and exploitability. Monitor the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) for actively exploited vulnerabilities in your stack. 7. **Evaluate suppliers.** For critical commercial dependencies, assess the vendor's security practices, including whether they provide SBOMs and maintain vulnerability disclosure processes. ## Frequently Asked Questions ### What is software supply chain management? Software supply chain management is the practice of identifying, assessing, and mitigating risks across the full chain of components, tools, and processes used to build and deliver software. It encompasses open source dependency management, build pipeline security, vendor assessment, and ongoing vulnerability monitoring. The goal is to ensure that every component in your software is known, trusted, and up to date. ### What is a chain of custody in software? Chain of custody in the software context refers to the documented, verifiable record of who created, modified, built, and distributed each component in a software product. It establishes trust by providing evidence that a component has not been tampered with between its source and its deployment. SBOMs, build attestations (like SLSA provenance), and code signing are the primary tools for establishing software chain of custody. ### How do SBOMs help with supply chain security? SBOMs provide the component-level visibility that is the foundation of supply chain security. Without knowing what is in your software, you cannot assess risk, identify vulnerabilities, or respond to incidents. SBOMs enable automated vulnerability scanning, license compliance checking, and rapid incident response when new vulnerabilities like Log4Shell are disclosed. They are required or recommended by most major compliance frameworks. ### What is the NIST risk management framework for supply chains? NIST publishes several frameworks relevant to supply chain risk management. [NIST SP 800-161 Rev 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final) is the primary guidance for cybersecurity supply chain risk management (C-SCRM). [NIST SP 800-53 Rev 5](/compliance/nist-800-53/) includes the SR (Supply Chain Risk Management) control family with specific controls for provenance (SR-4) and supply chain processes (SR-3). These frameworks are increasingly referenced in procurement requirements and compliance obligations. ### What are the biggest software supply chain risks? The most significant risks include: vulnerable open source dependencies (the most common attack surface), compromised build systems (as in SolarWinds), malicious packages in public registries (typosquatting and dependency confusion), and social engineering of open source maintainers (as in XZ Utils). Transitive dependencies, which are pulled in indirectly and often unreviewed, represent a particularly underestimated risk. --- # The GPL License: A Comprehensive Guide to the GNU General Public License URL: https://sbomify.com/2025/12/22/gpl-license-guide/ Date: 2025-12-22 Description: Understand the GPL license, including GPL v2 vs v3, copyleft obligations, LGPL, AGPL, commercial use, and how SBOMs track GPL compliance. The GPL (GNU General Public License) is a free software license that guarantees end users the freedom to run, study, modify, and share software. Created by Richard Stallman and the Free Software Foundation (FSF), the GPL is the most widely used copyleft license in open source software. Its defining characteristic is the copyleft requirement: any derivative work must also be distributed under the GPL, ensuring that the freedoms it grants are preserved downstream. ## What Is the GPL? The GNU General Public License, commonly called the GPL or GNU GPL, is a series of free software licenses published by the [Free Software Foundation](https://www.fsf.org/) (FSF). The GPL was first written by Richard Stallman in 1989 for the GNU Project and has since become the most prominent copyleft license in the world. The core idea behind the GPL is simple: software licensed under the GPL can be freely used, modified, and distributed, but anyone who distributes modified versions must also make their source code available under the same GPL terms. This "share-alike" obligation is what distinguishes copyleft licenses from permissive licenses like [MIT](/2026/01/22/mit-license-guide/) or [Apache 2.0](/2026/01/07/apache-license-2-guide/). The GPL family includes three major versions and two important variants: - **GPL v2** (1991) – The version that popularized copyleft; still used by the Linux kernel - **GPL v3** (2007) – Updated to address patents, tivoization, and international compatibility - **LGPL** (Lesser GPL) – A weaker copyleft for libraries, allowing proprietary linking - **AGPL** (Affero GPL) – Extends copyleft to software accessed over a network ## GPL v2 vs. GPL v3: Key Differences Understanding the differences between GPL version 2 and version 3 matters because they have different implications for commercial use and distribution. | Feature | GPL v2 (1991) | GPL v3 (2007) | | ---------------------------- | ------------------------------------------ | ------------------------------------------------------------------ | | **Patent grant** | Implicit (not explicit) | Explicit patent license from contributors | | **Tivoization protection** | No | Yes – prevents hardware that blocks modified software from running | | **Anti-DRM provisions** | No | Yes – modified GPL software cannot be locked down by DRM | | **License compatibility** | Narrower | Broader – compatible with Apache 2.0, for example | | **Internationalization** | US-centric language | Jurisdiction-neutral terminology | | **Installation information** | Not required | Required for "User Products" (consumer devices) | | **Notable users** | Linux kernel, Git, WordPress (v2 or later) | GCC, GNU Bash, Samba | GPL v2 includes a clause that allows licensees to use "version 2 or any later version," but this is optional – the copyright holder can specify "GPL v2 only." The Linux kernel, for instance, is licensed under "GPL v2 only" because Linus Torvalds chose not to adopt v3. GPL v3 was designed to close perceived loopholes in v2. The anti-tivoization provisions were a direct response to devices (like TiVo) that used GPL software but locked the hardware to prevent users from running modified versions. The explicit patent grant protects users and developers from patent litigation by contributors. ## Understanding Copyleft Copyleft is the legal mechanism that makes the GPL distinctive. While copyright restricts copying and modification by default, copyleft uses copyright law to ensure that freedoms are preserved. Under a copyleft license: 1. You can use, modify, and distribute the software freely 2. If you distribute the software (modified or unmodified), you must provide the source code 3. Your distribution must be under the same license terms 4. You cannot add restrictions beyond what the license specifies This creates a "viral" effect: GPL code that enters a project tends to make the whole project (or at least the derivative portions) subject to the GPL. This is the characteristic that makes commercial adoption of GPL software more complex than permissive-licensed alternatives. ### What Counts as a Derivative Work? This is the most debated question in GPL compliance. The GPL requires that "the work as a whole" be licensed under the GPL if it is based on GPL-licensed code. But what exactly constitutes a derivative work? Generally accepted interpretations: - **Modifying GPL source code and distributing it** – clearly a derivative work - **Statically linking against a GPL library** – generally considered a derivative work - **Dynamically linking against a GPL library** – debated; the FSF considers it a derivative work, others disagree - **Using a GPL command-line tool in your build process** – generally not a derivative work (the tool's output is yours) - **Using a GPL library as a separate process via IPC** – generally not a derivative work The LGPL was created specifically to address the library linking question. ## The LGPL: Lesser GPL for Libraries The GNU Lesser General Public License (LGPL) is a modified version of the GPL designed for software libraries. The LGPL allows proprietary software to link against LGPL-licensed libraries without the copyleft obligation applying to the proprietary code. Under the LGPL: - You can use the library in proprietary software without releasing your source code - If you modify the LGPL library itself, those modifications must be released under the LGPL - You must allow users to replace the LGPL library with modified versions (e.g., via dynamic linking) Common LGPL-licensed projects include the GNU C Library (glibc), Qt (available under both LGPL and commercial licenses), and many Java libraries. The LGPL is a pragmatic compromise: it keeps the library itself free while allowing commercial adoption that would be impractical under the full GPL. ## The AGPL: Closing the Network Loophole The GNU Affero General Public License (AGPL) adds one significant provision to GPL v3: if you run modified AGPL software as a network service (such as a web application), you must make the modified source code available to users who interact with the software over the network. Under the standard GPL, the copyleft obligation is triggered by _distribution_. Running software on a server and letting users access it via a browser is not distribution – the users never receive a copy of the software. The AGPL closes this gap by treating network interaction as equivalent to distribution for the purpose of source code availability. AGPL is commonly used by companies that offer open source software as a service but want to prevent competitors from running modified versions without contributing back. Notable AGPL projects include MongoDB (before its switch to SSPL), Grafana, and Nextcloud. ## GPL and Commercial Use A common misconception is that the GPL prohibits commercial use. It does not. The GPL explicitly allows commercial use, distribution, and even sale of GPL-licensed software. What it restricts is the ability to make the software proprietary. ### Can You Sell GPL Software? Yes. You can sell copies of GPL software, charge for support, or sell services around GPL software. The FSF itself has always supported commercial free software. The key constraint is that buyers must receive the same freedoms: the source code and the right to modify and redistribute. ### Commercial Strategies with GPL Software Organizations commonly take one of these approaches: 1. **Dual licensing** – Offer the software under both the GPL (for open source users) and a commercial license (for proprietary users who want to avoid copyleft obligations). MySQL, Qt, and many others use this model. 2. **Open core** – Release the core product under the GPL and sell proprietary extensions or enterprise features under a commercial license. 3. **Services and support** – Distribute the software under the GPL and monetize through consulting, support contracts, and managed hosting. Red Hat built a multi-billion dollar business on this model. 4. **SaaS delivery** – Run GPL software on your own servers without triggering the distribution clause (though this doesn't apply to AGPL software). ## GPL Compliance in Practice GPL compliance requires careful attention to three areas: distribution, source code availability, and license notices. ### When You Distribute GPL Software If you distribute GPL-licensed software (binary or source), you must: 1. Include a copy of the GPL license text 2. Include copyright notices and any warranty disclaimers 3. Provide the complete corresponding source code (or a written offer to provide it) 4. License the whole work under the GPL (for derivative works) ### Source Code Requirements The source code you provide must be the "complete corresponding source" – everything needed to build the binary, including build scripts, interface definition files, and any shared libraries. For GPL v3, this extends to "Installation Information" for consumer products (the anti-tivoization clause). ### Common Compliance Failures - Distributing binaries without source code or a valid written offer - Failing to include the license text with distributed software - Adding restrictions that the GPL does not permit (e.g., "no commercial use" clauses) - Confusing GPL v2 and GPL v3 obligations in mixed-license codebases ## How SBOMs Track GPL License Compliance A [Software Bill of Materials](/what-is-sbom/) plays a critical role in license compliance by documenting every component in your software along with its license. This is essential for GPL compliance because: 1. **Identifying GPL components.** SBOMs include license information for each component, making it straightforward to determine whether your project includes any GPL-licensed dependencies. The [CISA minimum elements draft](/compliance/cisa-minimum-elements/) now includes license as a recommended SBOM field. 2. **Tracking copyleft obligations.** When an SBOM shows a GPL-licensed component, your legal and engineering teams can assess whether the copyleft obligation applies to your distribution model. This is especially important for complex dependency trees with dozens or hundreds of transitive dependencies. 3. **Automating license audits.** Tools that process SBOMs can automatically flag components with copyleft licenses, allowing organizations to enforce license policies in their CI/CD pipeline. This is far more reliable than manual code review for license compliance. 4. **Supporting dual-license decisions.** When a component is available under both GPL and a commercial license, the SBOM documents which license applies to your specific use. Both [CycloneDX](https://cyclonedx.org/) and [SPDX](https://spdx.dev/) (which originated as a license documentation format) include standardized license fields. SPDX license expressions (e.g., `GPL-2.0-only`, `GPL-3.0-or-later`, `LGPL-2.1-or-later`) provide machine-readable license identifiers that make automated compliance checking possible. The [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) automatically enriches SBOMs with license data from multiple sources (including its LicenseDB covering 28 Linux distro versions), making GPL identification reliable even for system-level packages. For language-specific instructions, see our [SBOM generation guides](/guides/). ## GPL License Comparison Table | License | Copyleft Strength | Commercial Use | Library Linking | Network Use Trigger | Patent Grant | | -------------- | ----------------- | -------------- | --------------------- | ------------------- | ------------ | | **GPL v2** | Strong | Yes | Copyleft applies | No | Implicit | | **GPL v3** | Strong | Yes | Copyleft applies | No | Explicit | | **LGPL v2.1** | Weak (library) | Yes | Allowed (proprietary) | No | Implicit | | **LGPL v3** | Weak (library) | Yes | Allowed (proprietary) | No | Explicit | | **AGPL v3** | Strong + network | Yes | Copyleft applies | Yes | Explicit | | **MIT** | None (permissive) | Yes | No restrictions | No | No | | **Apache 2.0** | None (permissive) | Yes | No restrictions | No | Explicit | For a broader overview of open source licenses, see our [guide to navigating the landscape of open source licenses](/2024/04/03/navigating-the-landscape-of-open-source-licenses/). ## Frequently Asked Questions ### What is the GPL license? The GPL (GNU General Public License) is a copyleft free software license created by the Free Software Foundation. It guarantees that users can run, study, modify, and distribute the software, with the condition that any distributed derivative works must also be licensed under the GPL and include source code. It is the most widely used copyleft license in open source software. ### Can I use GPL software in commercial products? Yes. The GPL explicitly permits commercial use, distribution, and sale. The restriction is not on commerce but on making the software proprietary. If you distribute a product that includes GPL code, you must make the complete source code available under the GPL. Common commercial strategies include dual licensing, open core models, and selling services around GPL software. ### What is the difference between GPL and LGPL? The GPL requires that any derivative work be distributed under the GPL (strong copyleft). The LGPL (Lesser GPL) allows proprietary software to link against LGPL-licensed libraries without the copyleft applying to the proprietary code. If you modify the LGPL library itself, those modifications must be shared, but your application code that uses the library can remain proprietary. ### What is the difference between GPL v2 and GPL v3? GPL v3 (2007) added explicit patent grants, anti-tivoization provisions (preventing hardware lockdown of modified software), anti-DRM clauses, broader international compatibility, and better compatibility with other open source licenses like Apache 2.0. GPL v2 (1991) remains widely used, notably by the Linux kernel, which is licensed under "GPL v2 only." ### How do SBOMs help with GPL compliance? SBOMs document every component in your software along with its license, making it possible to automatically identify GPL-licensed dependencies, track copyleft obligations, and enforce license policies in CI/CD pipelines. Both CycloneDX and SPDX include standardized license fields that support machine-readable GPL license identification using SPDX license expressions like `GPL-2.0-only` or `GPL-3.0-or-later`. --- # Major Updates: sbomify v0.21 and Action Module v0.8 & v0.9 URL: https://sbomify.com/2025/12/19/major-updates-sbomify-v0-21-and-action-modules/ Date: 2025-12-19 Description: Triple release: sbomify v0.21 with vulnerability trends dashboard, plus GitHub Action v0.8 and v0.9 featuring modular generation plugins and 8 enrichment data sources. ![Major Updates](/assets/images/sbomify-v0-21-release.png) We have been busy at sbomify! Today we are announcing a triple release covering significant updates to both the core platform and our GitHub Action module. Here is a breakdown of what's new. ## sbomify v0.21: "The One Where We Almost Ditched Vue" This release brings substantial improvements to the user interface and underlying technology stack. As the release name suggests, we've undertaken a significant refactoring effort to streamline our frontend architecture. ### Key Features - **Vulnerability Trends Dashboard:** A new interactive dashboard to visualize vulnerability trends over time. - **Enhanced Workspace Management:** A new workspace switcher with a modal interface in the sidebar makes managing multiple environments easier than ever. - **Custom Keycloak Login:** We've introduced a custom Keycloak login theme with Tailwind CSS styling for a more seamless authentication experience. - **Improved Navigation:** A new navbar search, improved notifications, and version display in the footer. Under the hood, we migrated the Documents and SBOMs tables from Vue.js to **HTMX and Alpine.js**, resulting in a lighter and more responsive interface. We also cleaned up the codebase by removing deprecated Vue.js components. [Read the full v0.21 release notes](https://github.com/sbomify/sbomify/releases/tag/v0.21) --- ## sbomify-action v0.9: "The One Where Generation Gets Modular" Our GitHub Action module has received a major architectural upgrade focused on modularity and extensibility. ### Modular Generation Version 0.9 introduces a **plugin architecture for SBOM generation**. This system uses priority-based selection with automatic fallback (e.g., trying `cyclonedx-py` first, then `Trivy`, then `Syft`), ensuring you get the best possible SBOM for your project type without manual configuration. (Note: Trivy has since been [removed from sbomify-action](/2026/03/26/trivy-compromise-hardening-sbomify-action/) as of v26.1.0 following its March 2026 compromise.) ### Ubuntu APT Enrichment We've added native metadata source support for `pkg:deb/ubuntu/*` packages, covering LTS versions from 18.04 to 24.04 and 24.10. ### Built-in Validation Generated SBOMs are now automatically validated against the JSON Schema to ensure strict compliance. --- ## sbomify-action v0.8: "The One With Enrichment Plugins" Just prior to v0.9, we released v0.8, which completely rewrote the SBOM enrichment system. ### Plugin-based Enrichment Similar to generation, enrichment is now plugin-based. We prioritize multiple data sources to maximize NTIA compliance. We have implemented 8 data sources including **PyPI, Debian, deps.dev, ecosyste.ms, PURL, ClearlyDefined, Repology, and RPM Repo**. Crucially, **lockfile components are now enriched** rather than removed, preserving the integrity of your dependency graph while adding valuable metadata. ### Expanded Ecosystem Support - **RPM Repository Enrichment:** Native Tier 1 enrichment for RHEL-compatible distros (Rocky, Alma, CentOS Stream, Fedora, Amazon Linux). - **Dart/Flutter:** Added support for Dart packages via pub.dev and `pubspec.lock` enrichment. - **CycloneDX 1.7:** Full support for the latest CycloneDX 1.7 schema. These updates represent a significant step forward in making sbomify the most flexible and compliant SBOM management platform. Check out the updated [sbomify-action repository](https://github.com/sbomify/sbomify-action) to get started with these new features! --- # CVE Vulnerabilities Explained: What They Are and Why They Matter URL: https://sbomify.com/2025/12/18/cve-vulnerability-explained/ Date: 2025-12-18 Description: Learn what CVE vulnerabilities are, how the CVE system works, the role of MITRE and NVD, and how SBOMs enable rapid vulnerability response. A CVE (Common Vulnerabilities and Exposures) is a standardized identifier assigned to a publicly known cybersecurity vulnerability. Each CVE entry provides a unique ID, a description, and references to related advisories, giving security teams a common language for tracking and discussing specific flaws. The CVE system is maintained by the [MITRE Corporation](https://www.cve.org/) and serves as the backbone of modern vulnerability management across the software industry. ![CVE lifecycle from discovery through remediation](/assets/images/d2/cve-lifecycle.svg) ## What Is a CVE? CVE stands for Common Vulnerabilities and Exposures. It is a dictionary of publicly disclosed security flaws, each assigned a unique identifier in the format `CVE-YEAR-NUMBER` (for example, `CVE-2021-44228` for the Log4Shell vulnerability). The CVE system does not rate the severity of vulnerabilities – it simply catalogs them with a standardized reference that anyone in the cybersecurity community can use unambiguously. The program was launched in 1999 by MITRE Corporation with funding from the U.S. Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency ([CISA](https://www.cisa.gov/)). Before CVE existed, different vendors and databases used their own naming schemes for the same vulnerability, leading to confusion and duplicated effort. CVE solved this by providing a single, authoritative numbering system. As of early 2026, the CVE database contains over 330,000 entries and continues to grow rapidly – over 48,000 CVEs were published in 2025 alone. The MITRE CVE program relies on a network of CVE Numbering Authorities (CNAs) – organizations authorized to assign CVE IDs within their scope. Major CNAs include Microsoft, Google, Red Hat, Apache, and hundreds of other vendors and open source projects. ## How the CVE Process Works ### Discovery and Assignment When a vulnerability is discovered – by a security researcher, vendor, or automated tool – it can be reported to the relevant CNA or directly to MITRE. The CNA evaluates the report and, if it meets the criteria (a security flaw in publicly available software that can be independently fixed), assigns a CVE ID. ### Publication Once assigned, the CVE entry is published to the [CVE List](https://www.cve.org/) with a description and references. The entry may initially be marked as "reserved" while the vendor works on a patch, then updated with full details upon coordinated public disclosure. ### Enrichment After publication, the [National Vulnerability Database](https://nvd.nist.gov/) (NVD), maintained by NIST, enriches the CVE with additional data: severity scores (via CVSS), affected product configurations (CPE data), and references to patches and advisories. This enrichment makes CVE data actionable for vulnerability management tools. ## CVE vs. CVSS vs. KEV: Understanding the Differences These three acronyms are related but distinct. Confusing them is common, so here is a clear breakdown. | Term | What It Is | Who Maintains It | Purpose | | -------- | --------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------- | | **CVE** | Unique vulnerability identifier | MITRE Corporation | Catalog and name individual vulnerabilities | | **CVSS** | Severity scoring system (0.0–10.0) | [FIRST.org](https://www.first.org/cvss/) | Rate how severe a vulnerability is | | **KEV** | Known Exploited Vulnerabilities catalog | [CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) | Track vulnerabilities actively exploited in the wild | A CVE tells you _what_ the vulnerability is. A [CVSS](/2026/02/05/what-is-cvss-vulnerability-scoring/) score tells you _how bad_ it is. A [KEV](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) listing tells you _it is being actively exploited right now_. Effective vulnerability management uses all three signals together. ## The National Vulnerability Database (NVD) The [National Vulnerability Database](https://nvd.nist.gov/) is the U.S. government's repository of standards-based vulnerability management data. NVD builds on the CVE list by adding: - **CVSS scores** – severity ratings using the Common Vulnerability Scoring System - **CPE data** – Common Platform Enumeration entries that map vulnerabilities to specific products and versions - **CWE classifications** – Common Weakness Enumeration categories describing the type of flaw (e.g., buffer overflow, SQL injection) - **Fix references** – links to vendor advisories and patches NVD is freely accessible and is the primary data source for most vulnerability scanning tools. When a platform like [sbomify](https://sbomify.com), [Grype](https://github.com/anchore/grype), or [OWASP Dependency-Track](https://dependencytrack.org/) scans your software for known issues, it is typically checking component versions against NVD data. ## CVE Funding and Governance The CVE program has historically been funded through U.S. government contracts administered by CISA and DHS. In 2025, questions about the sustainability of MITRE's CVE funding drew significant attention from the cybersecurity community. The concern was straightforward: the entire global vulnerability tracking ecosystem depends on a single program funded by a single government. In response, the [CVE Foundation](https://www.cve.org/) was established to diversify funding and governance. The CVE Board, an international group of cybersecurity experts, provides strategic oversight. The expansion of the CNA network – now numbering over 400 organizations across 40+ countries – has also distributed the operational workload beyond MITRE alone. Regardless of governance structure, the CVE system remains the de facto global standard for vulnerability identification. ## Vulnerability Management with CVEs Vulnerability management is the continuous process of identifying, evaluating, prioritizing, and remediating security flaws in software. CVEs are the fundamental building blocks of this process. ### The Vulnerability Management Lifecycle 1. **Discover** – Inventory all software components in your environment (this is where SBOMs are critical) 2. **Identify** – Match your components against known CVEs using vulnerability scanners 3. **Evaluate** – Assess severity using CVSS scores, exploit availability (KEV status), and your own risk context 4. **Prioritize** – Not all CVEs require immediate action. Focus on high-severity vulnerabilities in internet-facing or critical systems, especially those listed in the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) 5. **Remediate** – Apply patches, update dependencies, or implement mitigations 6. **Verify** – Confirm the fix was applied and re-scan to ensure the vulnerability is resolved ### Vulnerability Scanners and Scanning Tools Several categories of tools support CVE-based vulnerability management: - **[Software Composition Analysis (SCA)](/2026/01/11/software-composition-analysis-sca/)** tools scan open source dependencies for known CVEs. Examples include [Grype](https://github.com/anchore/grype), [Snyk](https://snyk.io/), and [Trivy](https://github.com/aquasecurity/trivy) (which we [no longer consider safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise). - **Container scanners** analyze Docker and OCI images for vulnerable packages. See our [Docker SBOM guide](/guides/docker/) for details. - **Network vulnerability scanners** probe running systems for known flaws. - **[SBOM-based analysis](/2026/02/01/sbom-scanning-vulnerability-detection/)** platforms like [sbomify](https://sbomify.com) and [OWASP Dependency-Track](https://dependencytrack.org/) ingest SBOMs and continuously monitor components against new CVE disclosures. See our [resources page](/resources/) for a complete list of vulnerability scanning and SBOM analysis tools. The key advantage of SBOM-based scanning is that it decouples vulnerability identification from the build process. Once you have an SBOM, you can re-scan it at any time as new CVEs are published – without needing access to the source code or build system. ## How SBOMs Enable Rapid CVE Response The value of a [Software Bill of Materials](/what-is-sbom/) becomes most obvious during a vulnerability incident. Consider the Log4Shell scenario (CVE-2021-44228, disclosed December 2021): - **Without SBOMs:** Teams had to manually audit every application, check dependency files, search through build systems, and contact vendors to determine if they were using Apache Log4j. This took many organizations days or weeks. - **With SBOMs:** A simple search across your SBOM repository for `org.apache.logging.log4j:log4j-core` returned a complete list of affected applications in minutes. This is why compliance frameworks increasingly mandate SBOMs. The [EU Cyber Resilience Act](/compliance/eu-cra/) requires manufacturers to identify and document components in their products. [Executive Order 14028](/compliance/eo-14028/) requires software vendors to the U.S. government to provide SBOMs. The [CISA minimum elements](/compliance/cisa-minimum-elements/) specify that SBOMs should include unique identifiers (such as [Package URL](https://github.com/package-url/purl-spec)) that can be matched against CVE-affected component data. To start generating SBOMs for your projects, see our [language-specific SBOM guides](/guides/) covering Python, JavaScript, Java, Go, Rust, and more. ## Notable CVEs That Changed the Industry Several high-profile CVEs have shaped how the industry approaches vulnerability management: - **CVE-2014-0160 (Heartbleed)** – A critical flaw in OpenSSL that exposed encrypted communications for millions of servers. Highlighted the risk of widely shared dependencies. - **CVE-2017-5638 (Apache Struts)** – The vulnerability behind the Equifax breach, which exposed personal data of 147 million people. Demonstrated the consequences of slow patching. - **CVE-2021-44228 (Log4Shell)** – A remote code execution flaw in Apache Log4j that affected millions of applications. Became the catalyst for widespread SBOM adoption as organizations struggled to identify affected systems. - **CVE-2024-3094 (XZ Utils)** – A supply chain attack where a malicious contributor inserted a backdoor into the XZ compression library. Showed that vulnerabilities can be deliberately introduced, not just accidentally created. Each of these incidents reinforced the same lesson: you cannot protect what you cannot see. SBOMs provide that visibility. ## Best Practices for CVE Management 1. **Maintain SBOMs for all your software.** An accurate component inventory is the foundation of effective vulnerability management. Use automated tools to [generate SBOMs](/guides/) as part of your CI/CD pipeline. 2. **Automate vulnerability scanning.** Integrate SBOM-based scanning tools into your build and deployment process. Continuous monitoring catches newly disclosed CVEs without manual effort. 3. **Use multiple severity signals.** Do not rely on CVSS scores alone. Factor in KEV status (is it being exploited?), your deployment context (is the component exposed?), and exploit maturity. 4. **Establish a patching SLA.** Define response timeframes based on severity. Critical CVEs in exposed systems should be addressed within days, not months. 5. **Subscribe to advisories.** Monitor the [NVD data feeds](https://nvd.nist.gov/vuln/data-feeds), vendor security bulletins, and the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) for timely notification of new CVEs affecting your stack. 6. **Document your response process.** When the next Log4Shell-scale event happens, you need a practiced runbook – not a scramble. SBOMs, pre-defined escalation paths, and automated alerting make the difference. ## Frequently Asked Questions ### What does CVE stand for? CVE stands for Common Vulnerabilities and Exposures. It is a system for assigning unique identifiers to publicly known cybersecurity vulnerabilities. Each CVE ID (e.g., CVE-2021-44228) serves as a standard reference that security teams, vendors, and tools can use to unambiguously identify a specific flaw. ### What is the difference between a CVE and a vulnerability? A vulnerability is any security weakness in software that could be exploited. A CVE is the standardized identifier assigned to a publicly known vulnerability. Not all vulnerabilities have CVE IDs – only those that are publicly disclosed and meet the CVE program's inclusion criteria receive a CVE number. Think of CVE as the naming system, and vulnerability as the broader concept. ### Who assigns CVE numbers? CVE IDs are assigned by CVE Numbering Authorities (CNAs). MITRE Corporation serves as the primary CNA and coordinates the overall program. Over 400 organizations, including major software vendors like Microsoft, Google, and Red Hat, are authorized to assign CVE IDs within their product scope. Researchers can also request CVE IDs through the [CVE Request form](https://www.cve.org/ResourcesSupport/ReportRequest). ### How are CVEs used in vulnerability management? CVEs are the foundation of vulnerability management. Organizations use vulnerability scanners and Software Composition Analysis tools to match their software components against known CVEs. When a match is found, the CVSS severity score and KEV status help prioritize remediation. SBOMs make this process more efficient by providing a complete component inventory that can be continuously rescanned. ### What is the National Vulnerability Database (NVD)? The NVD is the U.S. government's repository of vulnerability data, maintained by NIST. It enriches CVE entries with severity scores (CVSS), affected product mappings (CPE), weakness classifications (CWE), and references to patches. Most vulnerability scanning tools use NVD as their primary data source. --- # Software Development Life Cycle (SDLC): A Complete Guide URL: https://sbomify.com/2025/12/15/software-development-life-cycle-sdlc-sbom-integration/ Date: 2025-12-15 Description: Learn what the Software Development Life Cycle (SDLC) is, its phases and models, and how SBOMs integrate into each stage for security and compliance. The Software Development Life Cycle (SDLC) is a structured process that defines the stages involved in developing software from initial concept through deployment and maintenance. SDLC provides a systematic framework that development teams use to plan, create, test, and deliver high-quality software. Understanding the SDLC is essential for any organization building software today, particularly as security and compliance requirements become integral to every phase of development. ![SDLC phases with SBOM integration points](/assets/images/d2/sdlc-sbom.svg) ## What Is the Software Development Life Cycle? SDLC, short for Software Development Life Cycle, is a methodology used by software engineering teams to design, develop, and test software in a predictable and efficient manner. Rather than writing code ad hoc, SDLC defined processes ensure that each stage of development has clear objectives, deliverables, and quality checks. The concept of a structured development life cycle emerged in the 1960s as software projects grew in complexity. What began as a simple sequential process has evolved into a family of software development life cycle models, each suited to different project types and organizational needs. At its core, every SDLC framework answers the same questions: What are we building? How will we build it? How do we know it works? And how do we keep it running? ## The Phases of the SDLC While specific terminology varies between models, most SDLC frameworks include six to eight phases. Here are the core stages that appear in virtually every approach. ### 1. Planning and Requirements Analysis The first phase involves gathering business requirements, identifying stakeholders, and defining project scope. Teams assess feasibility, estimate resources, and create a project plan. Security considerations should enter the picture here through threat modeling and risk assessment. ### 2. System Design Architects and senior developers translate requirements into a technical blueprint. This includes system architecture, technology stack selection, data models, and interface specifications. Design decisions made here have long-lasting implications for security and maintainability. ### 3. Implementation (Coding) Developers write the actual source code based on the design specifications. This phase typically involves selecting libraries, frameworks, and third-party components. These [dependency](/2026/01/29/what-is-a-dependency-in-software/) choices directly impact the [software supply chain](/2025/12/26/software-supply-chain-management/) and are the foundation of what an [SBOM](/what-is-sbom/) will eventually document. ### 4. Testing Quality assurance teams verify that the software meets requirements and is free of defects. Testing includes unit tests, integration tests, system tests, and user acceptance testing. Security testing, including vulnerability scanning and penetration testing, is increasingly part of this phase. ### 5. Deployment The tested software is released to production environments. Deployment strategies such as blue-green deployments, canary releases, and rolling updates help reduce risk. This phase is where CI/CD pipelines automate the build, test, and release process. ### 6. Maintenance and Operations After deployment, teams monitor the application, fix bugs, apply security patches, and release updates. This phase often lasts the longest and is where vulnerability management and ongoing compliance activities take place. ## Software Development Life Cycle Models Over the decades, several SDLC models have emerged to address different project needs. Each model organizes the core phases differently. | Model | Approach | Best Suited For | Key Characteristic | | ------------- | ----------------------------------- | ---------------------------------------------- | ----------------------------------------------------- | | **Waterfall** | Sequential, linear | Well-defined projects with stable requirements | Each phase completes before the next begins | | **Agile** | Iterative, incremental | Projects with evolving requirements | Short sprints, continuous feedback | | **Spiral** | Risk-driven, iterative | Large, high-risk projects | Risk analysis at every iteration | | **V-Model** | Verification and validation | Safety-critical and regulated systems | Each development phase has a corresponding test phase | | **DevOps** | Continuous integration and delivery | Fast-moving organizations | Merges development and operations | | **Lean** | Waste elimination | Startups and rapid prototyping | Minimize overhead, maximize value | The Waterfall model was the original SDLC approach, moving linearly from requirements through deployment. Agile methodologies, including Scrum and Kanban, replaced the rigid sequential approach with iterative cycles that deliver working software in short sprints. Most modern teams use some form of Agile combined with DevOps practices. ## Where Security Fits: From SDLC to Secure SDLC Traditional SDLC models treated security as a gate at the end of development – a final check before release. This approach consistently proved inadequate. Vulnerabilities discovered late in the cycle are far more expensive to fix than those caught early. The Secure Software Development Life Cycle (SSDLC or Secure SDLC) integrates security activities into every phase: - **Planning:** Threat modeling, security requirements definition - **Design:** Security architecture review, attack surface analysis - **Implementation:** Secure coding standards, dependency management, SBOM generation - **Testing:** Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), [Software Composition Analysis (SCA)](/2026/01/11/software-composition-analysis-sca/) - **Deployment:** Configuration hardening, secrets management, SBOM distribution - **Maintenance:** Vulnerability monitoring, patch management, SBOM updates This shift-left approach – moving security earlier in the development process – is central to [DevSecOps](https://www.nist.gov/publications/devsecops-nist-special-publication-800-218-secure-software-development-framework-ssdf), where security becomes a shared responsibility across the entire team rather than a bottleneck at the end. ## SDLC and SBOMs: Integration at Every Phase A [Software Bill of Materials](/what-is-sbom/) (SBOM) documents every component, library, and dependency in a piece of software. Rather than treating SBOM generation as a one-time event, modern organizations integrate SBOMs throughout the SDLC. ### During Implementation When developers add dependencies – open source libraries, frameworks, and packages – they shape the software's composition. This is the moment to begin tracking what goes into the build. Tools like the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) can generate SBOMs automatically as part of the build process. See our [SBOM generation guides](/guides/) for language-specific instructions covering Python, JavaScript, Java, Go, Rust, and more. ### During Testing SBOMs enable automated [vulnerability scanning](/2026/02/01/sbom-scanning-vulnerability-detection/). Once you have a complete inventory of components, platforms like [sbomify](https://sbomify.com) can continuously monitor your SBOMs against vulnerability databases. Standalone tools like [Grype](https://github.com/anchore/grype) and [OWASP Dependency-Track](https://dependencytrack.org/) can also cross-reference your SBOM against the [National Vulnerability Database](https://nvd.nist.gov/) (NVD) and [OSV](https://osv.dev/). See our [resources page](/resources/) for a complete list of SBOM generation and analysis tools. ### During Deployment The SBOM becomes a release artifact alongside the software itself. Compliance frameworks including the [EU Cyber Resilience Act](/compliance/eu-cra/) and [Executive Order 14028](/compliance/eo-14028/) require SBOMs to be available to downstream consumers. Signing the SBOM provides tamper-evidence for the supply chain. ### During Maintenance As new vulnerabilities are discovered – often months or years after deployment – SBOMs allow organizations to quickly determine whether they are affected. When the [Log4Shell vulnerability](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) was disclosed in December 2021, organizations with SBOMs could identify affected systems in minutes rather than weeks. ## SDLC Best Practices for Modern Teams 1. **Choose the right model for your context.** Agile works well for most web and cloud applications. V-Model or Spiral may be more appropriate for safety-critical systems in medical devices or automotive software. 2. **Shift security left.** Integrate threat modeling in planning, dependency review in implementation, and automated security testing in CI/CD. Catching vulnerabilities early saves time and reduces risk. 3. **Automate everything repeatable.** Use CI/CD pipelines to automate builds, tests, security scans, SBOM generation, and deployments. Manual processes introduce inconsistency and slow the cycle. 4. **Track your dependencies.** Every third-party library is a potential risk vector. Maintain SBOMs, monitor for vulnerabilities, and have a process for updating or replacing compromised components. 5. **Build compliance into the workflow.** Rather than scrambling for compliance at audit time, embed [SBOM generation](/guides/) and vulnerability scanning into your standard SDLC process. This is especially critical for organizations subject to the [NTIA minimum elements](/compliance/ntia-minimum-elements/) or [CISA guidance](/compliance/cisa-minimum-elements/). 6. **Measure and improve.** Track metrics like lead time, deployment frequency, mean time to recovery, and vulnerability remediation time. Use retrospectives to continuously improve the process. ## NIST and the SDLC The National Institute of Standards and Technology (NIST) has published several frameworks relevant to securing the SDLC: - **[NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final)** (Secure Software Development Framework, SSDF) provides practices for integrating security into the development process, organized into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. - **[NIST SP 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** includes the SA (System and Services Acquisition) and SR (Supply Chain Risk Management) control families that directly address SDLC security controls. - **[NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework)** provides a high-level structure for managing cybersecurity risk that maps to SDLC activities. These frameworks are increasingly referenced in procurement requirements and regulatory compliance, making them essential reading for teams working on government or critical infrastructure projects. ## Frequently Asked Questions ### What is SDLC in software development? SDLC stands for Software Development Life Cycle. It is a structured process that guides software development from initial planning through deployment and ongoing maintenance. The SDLC provides a framework of phases – including requirements analysis, design, implementation, testing, deployment, and maintenance – that help teams deliver reliable software in a systematic way. ### What are the most common SDLC models? The most widely used software development life cycle models are Waterfall, Agile (including Scrum and Kanban), DevOps, V-Model, Spiral, and Lean. Agile and DevOps are the most popular for modern web and cloud applications due to their iterative approach and emphasis on continuous delivery. ### How do SBOMs fit into the SDLC? SBOMs integrate into multiple SDLC phases. During implementation, SBOM generation tools capture component inventories. During testing, SBOMs enable automated vulnerability scanning. During deployment, SBOMs are distributed alongside release artifacts for compliance. During maintenance, SBOMs allow rapid identification of affected systems when new vulnerabilities are disclosed. See our [SBOM generation guides](/guides/) for language-specific integration steps. ### What is the difference between SDLC and DevOps? SDLC is the overall process framework for software development, while DevOps is a specific approach that emphasizes collaboration between development and operations teams with a focus on automation, continuous integration, and continuous delivery. DevOps can be seen as a modern SDLC model rather than an alternative to the SDLC concept itself. ### What is a Secure SDLC? A Secure SDLC (sometimes called SSDLC) integrates security practices into every phase of the software development life cycle, rather than treating security as a final checkpoint. This includes threat modeling during planning, secure coding standards during implementation, SAST/DAST during testing, and vulnerability monitoring during maintenance. NIST SP 800-218 (SSDF) provides a standardized framework for implementing a Secure SDLC. --- # Announcing sbomify v0.20: Custom Domains & Streamlined Onboarding URL: https://sbomify.com/2025/12/12/announcing-sbomify-0-20/ Date: 2025-12-12 Description: sbomify v0.20 release featuring custom domain support for Trust Centers, redesigned onboarding wizard, team invitation improvements, and security hardening. ![sbomify v0.20 Release](/assets/images/release-0-20-cover.png) We're excited to announce the release of **sbomify v0.20**, a significant update focused on empowering organizations to make their Trust Center truly their own. This release introduces custom domain support, a redesigned onboarding experience, and numerous improvements to workspace management and security. ## Custom Domain Support The headline feature of v0.20 is **custom domain support for public Trust Center pages**. Workspaces can now use their own domain (via CNAME) to serve their public Trust Center, making it seamlessly integrate with their existing web presence. With this update, you can: - Configure a custom domain directly from your workspace branding settings - Use clean, slug-based URLs when accessing via your custom domain - Benefit from extended caching with proper invalidation when your content changes This feature is perfect for organizations that want their Trust Center to live at something like `trust.yourcompany.com` rather than a subdomain of sbomify. ## Redesigned Onboarding Wizard We've completely reimagined the onboarding experience for new users. The previous multi-step wizard has been simplified into a **single-step SBOM identity setup** that gets you up and running faster. Key improvements include: - Automatic redirect for first-time users to set up their SBOM identity - Plan-aware getting started flow that adapts to your subscription - Modernized UI with better handling of edge cases ## Workspace Management Enhancements Managing your workspace just got easier with several quality-of-life improvements: - **Workspace name editing**: Change your workspace name directly from settings - **User invitation management**: Manage pending invitations from the settings page - **Improved session management**: Better caching and workspace switching with proper cache invalidation ## Team Invitation System Improvements We've overhauled how team invitations work with a new **token-based invitation system**: - More secure invitation URLs backed by database tokens - Persistent team settings with toast notifications for invitation status - Improved handling and styling throughout the invitation flow ## Public Pages Improvements Your public Trust Center pages now offer an even better experience: - **Breadcrumb navigation** for easier navigation on component pages - **Copy-to-clipboard functionality** for quick sharing - Fixed layout and logo display issues - Consistent "Trust Center" capitalization across all templates ## Security Hardening This release includes important security improvements: - Fixed incomplete URL substring sanitization (addressing CodeQL alerts) - Added admin permission restrictions for removing team owners - Improved workspace member removal and session handling - Added comprehensive tests for edge cases with pending invitations ## Infrastructure Updates Under the hood, we've made several infrastructure improvements: - Improved HTTPS/TLS handling with Caddy - Configurable port exposure in Docker setup - New `bin/deploy.sh` deployment script - Updated deployment documentation ## By the Numbers This release involved significant effort across the codebase: - **125 files changed** - **~9,663 lines added** - **~1,611 lines removed** ## Getting Started If you're self-hosting sbomify, update to v0.20 to take advantage of these new features. For users on our hosted platform, these improvements are already live. Check out the [full changelog on GitHub](https://github.com/sbomify/sbomify/releases/tag/v0.20) for complete details. As always, we welcome your feedback and contributions. Drop us a note or open an issue on GitHub if you have questions or suggestions! --- # Announcing GitHub Action 0.7.0 and sbomify 0.19 URL: https://sbomify.com/2025/12/05/announcing-github-action-0-7-0-and-sbomify-0-19/ Date: 2025-12-05 Description: Major releases: GitHub Action 0.7.0 with ecosyste.ms enrichment and SPDX support, plus sbomify 0.19 with full Django+HTMX migration, custom domains, and CycloneDX 1.7. ![Zero to SBOM Hero](/assets/images/release-0-19-cover.png) We are excited to announce significant updates to both our GitHub Action and the core sbomify platform. This release brings major architectural improvements, enhanced security features, and expanded support for SBOM standards. ## [GitHub Action 0.7.0](https://github.com/sbomify/sbomify-action/releases/tag/v0.7.0) The latest version of our GitHub Action includes major changes to enrichment, format support, and telemetry. ### Major Changes - **Enrichment via ecosyste.ms**: We have switched our package metadata enrichment from Parley to the [ecosyste.ms](https://ecosyste.ms) API. A big thank you to @andrew for this integration! - **SPDX Support**: We now offer full support for SPDX 2.2 and 2.3 formats alongside CycloneDX, powered by the new `spdx-tools` dependency. - **Enhanced Telemetry**: Sentry error tracking now respects repository visibility, ensuring that private repositories do not send CI context. ### Improvements - **API Updates**: The product releases API now uses `sbom_id` instead of `artifact_id`/`artifact_type`. - **Release Tagging**: Improved workflow for release tagging with better ID resolution. - **Vendor Normalization**: Fixed tool vendor normalization to prevent serialization comparison errors. - **Caching**: Better cache management for enrichment API calls. - **Error Filtering**: User errors (validation/configuration) are now filtered from telemetry to reduce noise. ### Testing & Dependencies We've added comprehensive Sentry filtering tests across GitHub Actions, GitLab CI, and Bitbucket Pipelines, along with new tool vendor normalization tests. Dependencies have been updated to include `spdx-tools`, `beartype`, `click`, `isodate`, `ply`, `rdflib`, `semantic-version`, `uritools`, and `xmltodict`. --- ## [sbomify 0.19](https://github.com/sbomify/sbomify/releases/tag/v0.19) This is a massive release for the sbomify platform, involving a complete frontend architecture migration and significant infrastructure enhancements. ### Summary - Major frontend architecture migration - Infrastructure enhancements ### Architecture Changes We have almost completed the full migration from Vue.js to a stack of **Django + HTMX + Alpine.js**. - Removed ~3,700 lines of Vue code. - All frontend is now server-driven with Django templates. - Added [`ADR-001`](https://github.com/sbomify/sbomify/blob/master/docs/ADR/ADR-001.md) (Django Monolith) and [`ADR-002`](https://github.com/sbomify/sbomify/blob/master/docs/ADR/ADR-002.md) (Languages & Frameworks) to our architectural decision records. ### Infrastructure & Security - **Caddy Reverse Proxy**: Now handling automatic Let's Encrypt TLS certificate management and health monitoring. - **Custom Domain Support**: Workspaces can now use custom domains with auto-provisioned TLS and automated validation. - **Security**: - Added Turnstile CAPTCHA on enterprise contact forms. - Enhanced client IP detection with spoofing protection. - Keycloak authentication fixes. ### New Features - **Global Components**: Workspace-level reusable components. - **Contact Profiles**: Reusable supplier information for SBOMs. - **Workspace Visibility Controls**: Toggle between public and private workspaces (paid plans). - **Improved CycloneDX 1.6 & added 1.7 Support**: Support for the latest SBOM specifications. - **Release Date Tracking**: Added an optional `released_at` field. - **Vulnerability Scanning Dashboard**: Centralized management for scans. - **Enhanced Trust Center**: A redesigned public workspace page for better transparency. These updates mark a significant step forward in our mission to simplify SBOM management and security compliance. --- # Using Conan for C SBOMs URL: https://sbomify.com/2025/09/04/conan/ Date: 2025-09-04 Description: How to use the Conan package manager to generate SBOMs for C and C++ projects, addressing the lack of native package management in these languages. Last November I wrote about [The C conundrum](https://sbomify.com/2024/11/18/c-conundrum/) as there's so much C code that needs SBOMs, but there was no straightforward way to generate them. [Conan](https://conan.io/) got a mention, but at the time wasn't working as hoped. Thankfully things have improved since then, which means that Conan provides a viable route to generating SBOMs for C (and C++) projects. The most crucial change is that SBOM generation tools like Aqua's [Trivy](https://trivy.dev/) can now generate reasonable output from Conan lock files. (Note: we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise and have removed it from sbomify-action.) That in turn means that sbomify can use a `conan.lock` file in the same way it would use a lock file for any other package manager. The Conan [documentation](https://docs.conan.io/2/) and [tutorial](https://academy.jfrog.com/conan-2-essentials) have improved dramatically, which makes it much easier to get started. It's relatively straightforward to 'bolt on' a `conanfile.py` to a project and use it to describe dependencies. A `conan.lock` can then be generated and used as the basis of an SBOM. The only problem is that any changes to the project dependencies need to be (manually) updated in the Conan file. A more integrated approach means going all in on Conan, and using it to generate configuration and build descriptions like `CMakeLists.txt`. Conan is very capable and flexible, and an easy win for a green field project. But the 6.5 billion lines of open source C out there are testament to a huge brown field problem. There's been huge investment in the existing config and build systems for those projects, encapsulated in CMake, GNU Autotools, and many other systems. Refactoring those projects into Conan will require deep understanding of the existing tool chain, and how Conan generates builds. We might wish for an AI magic wand to make the transition easy, but it seems to be a task that's beyond the present generation of coding assistants. As regulatory pressure from the EU Cyber Resilience Act ([CRA](https://en.wikipedia.org/wiki/Cyber_Resilience_Act)) and other mandates mounts there's going to be increasing interest in getting SBOMs for C stuff. Conan can be used as a 'bolt on' workaround, and with increased adoption and familiarity may become the de facto way of doing things. At least for everything that lies outside of other package ecosystems like Yocto and Zephyr. This is a guest post from [Chris Swan](https://cpswan.net), an advisor at sbomify and an Engineer at [Atsign](https://atsign.com) who are an early adopter of sbomify. --- # CISA's Minimum Elements now in Draft URL: https://sbomify.com/2025/08/23/cisa-minimum-elements/ Date: 2025-08-23 Description: Analysis of CISA's 2025 draft SBOM Minimum Elements update, adding required hash, license, and tool provenance fields to succeed the 2021 NTIA guidance. > **Update, August 2026:** This post describes the 2025 public comment draft. The final [2026 Minimum Elements for a Software Bill of Materials](/compliance/cisa-minimum-elements/) was published on 29 July 2026 and now updates and replaces the NTIA 2021 guidance. The final version differs from the draft described below. For current guidance, see our [CISA 2026 Minimum Elements](/compliance/cisa-minimum-elements/) reference. [CISA](https://www.cisa.gov/sbom) has published a [public comment draft of updated SBOM Minimum Elements](https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf). This draft is intended as successor guidance to the [NTIA Minimum Elements](https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf) first issued on July 12, 2021. Comments are open until **October 3, 2025** ([Federal Register notice](https://www.federalregister.gov/documents/2025/08/22/2025-18532/notice-of-draft-software-bill-of-materials-sbom-minimum-elements-guidance)). ## What changed at a glance **New required data fields** - Component hash - License - Tool name used to generate the SBOM - Generation context: pre-build, build-time, or post-build **Renamed or clarified fields** - _Supplier Name_ → _Software Producer_ - _Author of SBOM Data_ → _SBOM Author_ - _Other Unique Identifiers_ → _Software Identifiers_ (at least one required; examples include CPE, purl, OmniBOR, SWHID) - _Version of the Component_ → _Component Version_ (file creation date allowed if no version) - _Depth_ → _Coverage_ (requires comprehensive listing, including transitive dependencies and duplicates when metadata differs) - _Accommodation of Mistakes_ → _Accommodation of Updates to SBOM Data_ - _Frequency_ and _Distribution and Delivery_ clarified - Timestamp must follow ISO 8601 - SWID removed from Automation Support examples **Removed** - _Access Control_ as a standalone element (folded into Distribution and Delivery expectations for controlled sharing). ## Practical implications - SBOMs now must include **hashes, licenses, and tool provenance**. This strengthens validation, license compliance, and reproducibility. - **Coverage is stricter**. Transitive dependencies and duplicate instances are explicitly in scope. - **Known Unknowns** must be flagged, with a distinction between unknown and intentionally redacted components, improving clarity during audits and incident response. ## How this relates to the 2021 NTIA Minimum Elements The [NTIA document](https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf) established the original baseline in 2021. CISA was tasked by [OMB M-22-18](https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf) to produce successor guidance that reflects today’s SBOM maturity. This draft builds on and updates that baseline for federal use once finalized. ## Comment window CISA is accepting public comments until **October 3, 2025**. You can review the [draft PDF](https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf) and submit feedback through the [Federal Register notice](https://www.federalregister.gov/documents/2025/08/22/2025-18532/notice-of-draft-software-bill-of-materials-sbom-minimum-elements-guidance). --- # Big Update to sbomify URL: https://sbomify.com/2025/07/04/big-update-to-sbomify/ Date: 2025-07-04 Description: sbomify v0.15 introduces document support alongside SBOMs, improved public pages, and product-level SBOM aggregation – evolving into a complete compliance hub. Happy 4 July to our US friends. Today, we are pleased to announce that we have shipped yet another big update to sbomify, version 0.15. This release has two major focuses: - **Improving the look and feel – and overall experience – of all public pages** - **Introducing support for documents in addition to SBOMs** The latter is especially important because it paves the way toward our ultimate goal: becoming the best open implementation of CycloneDX's Transparency Exchange API (TEA), where documents are first-class citizens. ## Why are these two features such a big deal? Imagine you are a product company. People in the community have told us they want a portal where they can direct users to security artifacts. These artifacts might be SBOMs, but they could also include penetration testing results, FCC or CE certification documents, and many other items. With this new feature, that is now possible. All you need to do is create a new "Component" in sbomify and upload your documents there with versioning. If you create a product (such as "sbomify") and a project (for example, "compliance documents"), you can then add a component called "FCC Certificates" and share those documents by making the relevant components public directly in the user interface. ## A Compliance Hub In short, sbomify is evolving into a compliance hub. SBOMs remain important, but they are now just one part of a broader picture. Speaking of SBOMs, we have also exposed our product- and project-level SBOM aggregation download feature to public pages. This means that if you have a project with ten different components – for example, ten different microservices – you can now download an aggregated SBOM that links all of them together using externalReferences in CycloneDX*. Want a live demo? Check out our [public product page](https://app.sbomify.com/public/product/eP_4dk8ixV/) _* Note: This is currently available only for CycloneDX, and it assumes your SBOM components are marked as public._ --- # Unpacking Raspberry Pi's Built‑In SBOM Magic URL: https://sbomify.com/2025/04/17/unpacking-raspberry-pi-s-built-in-sbom-magic/ Date: 2025-04-17 Description: How Raspberry Pi's rpi-image-gen tool generates SPDX SBOMs out of the box, achieving a 7.8/10 quality score with sbomqs for embedded image builds. When the Raspberry Pi Foundation quietly unveiled [rpi‑image‑gen](https://github.com/raspberrypi/rpi-image-gen), most of the headlines focused on how it streamlines custom image creation. Tucked inside that announcement is something even more exciting for anyone who cares about software supply‑chain transparency: every image it builds comes with a Software Bill of Materials (SBOM) out of the box. If you live and breathe SBOMs, or you just want to understand why this matters, read on. We will walk through how the tool works, where the SBOM lives, and what is inside it. ## A Quick Primer on rpi‑image‑gen Think of rpi‑image‑gen as the flexible cousin of the long‑standing [pi‑gen](https://github.com/RPi-Distro/pi-gen) project that the Raspberry Pi team uses for the official Raspberry Pi OS builds. While pi‑gen is opinionated and optimized for the distro maintainers' workflow, rpi‑image‑gen is designed for developers and device makers who need bespoke images. Building a minimal Debian 12 image for 64‑bit devices takes just a few commands: ```bash git clone https://github.com/raspberrypi/rpi-image-gen.git cd rpi-image-gen sudo ./install_deps.sh ./build.sh ``` Important: run it on a Raspberry Pi OS (f.k.a. Raspbian) machine for the smoothest experience. Running under plain Debian or Ubuntu tends to trip over architecture mismatches. Once the build finishes, you will find everything in `work/deb12-arm64-min/artefacts/`: ```text boot.vfat boot.vfat.sparse config.yaml deb12-arm64-min.img deb12-arm64-min.img.sparse deb12-arm64-min.sbom <-- the star of the show fstab ... ``` `deb12-arm64-min.img` is the file you flash to your SD card. Right beside it sits `deb12-arm64-min.sbom`, a 6.8 MB JSON document that catalogues every component in the image. ## How the SBOM Gets Made Under the hood, rpi‑image‑gen calls a helper script at `sbom/gen.sh`. That script invokes **Syft**, Anchore's open‑source SBOM generator, to crawl the root filesystem and spit out an SPDX 2.3‑compliant file. The default settings live in `sbom/defaults`, so you can swap formats or tweak depth without touching the core builder. Running `jq` on the finished SBOM shows 214 packages detected: ```bash cat deb12-arm64-min.sbom | jq '.packages | length' # 214 ``` ## Measuring Quality with `sbomqs` A big SBOM is not automatically a good SBOM. To gauge quality, we ran **sbomqs** from Interlynk: ``` SBOM Quality Score: 7.8 / 10.0 Components: 214 ``` Here are a few highlights from the report: | Category | Metric | Score | Notes | | --------------------- | --------------- | ----- | ---------------------------------------------- | | NTIA minimum elements | Unique IDs | 10.0 | All components identified | | NTIA minimum elements | Supplier info | 5.8 | 124 of 214 list a supplier | | Quality | Valid licenses | 7.0 | 187 of 214 carry a recognized license | | Semantic | Checksums | 0.0 | Checksums missing, an easy win for improvement | | Structural | Spec compliance | 10.0 | Valid SPDX 2.3 JSON | Even with a few gaps, an out‑of‑the‑box score of 7.8 is impressive. Most importantly, the file is fully parsable and ready for vulnerability scans and license audits. ## Why Built‑In SBOMs Matter - **Zero setup overhead** – You do not need to glue extra scanners into your pipeline; the SBOM arrives with every build. - **Reproducibility** – Anyone flashing your image can inspect exactly what shipped, making security reviews and bug hunts faster. - **Regulatory head‑start** – As governments push for transparency (think EU Cyber Resilience Act or US Executive Order 14028), having machine‑readable SBOMs from day one keeps you ahead of the curve. ## Tips for Taking It Further 1. **Enable checksum generation**: Edit `sbom/defaults` and add `--file-digests` to Syft's args to fill that gap in the quality score. 2. **Switch formats**: Need CycloneDX instead of SPDX? Change `output_format` from `spdx-json` to `cyclonedx-json` in `sbom/defaults`. 3. **Automate uploads**: Pipe the `.sbom` file into your CI artefact store or an SBOM analysis platform such as sbomify. ## Final Thoughts Raspberry Pi has quietly raised the bar for embedded‑image builders by shipping SBOMs as a first‑class citizen. If you already depend on Raspberry Pi boards, rpi‑image‑gen is worth the upgrade for this feature alone. And if you are exploring ways to make your firmware supply chain more transparent, it is one of the simplest on‑ramps you will find. For those using other embedded build systems, check out how [Yocto handles SBOM generation](/2025/02/21/mastering-sbom-generation-with-yocto/). Give it a spin, peek inside the SBOM, and let us know what you discover. --- # Mastering SBOM Generation with Yocto URL: https://sbomify.com/2025/02/21/mastering-sbom-generation-with-yocto/ Date: 2025-02-21 Description: Deep dive into Yocto's built-in SPDX 2.2 SBOM generation, analyzing output quality with sbomqs and integrating with sbomify for SBOM lifecycle management. I recently [spent time with Yocto](https://vpetersson.com/2025/02/21/yocto-rockpi-and-sboms.html) to better understand how it works with SBOMs, and I was very impressed. In short, if you are building your own Linux distribution, Yocto is an excellent choice for many reasons, particularly if you want to provide SBOMs for your product. Since Yocto builds everything from source, it can provide a complete SBOM for all components it compiles. Because Yocto has a catalog of all the packages it can build, including the corresponding licensing, it is able to generate high-quality SBOMs out of the box. Other platforms are also adopting this approach; for example, the Raspberry Pi Foundation recently introduced [built-in SBOM generation with `rpi-image-gen`](/2025/04/17/unpacking-raspberry-pi-s-built-in-sbom-magic/). ## Yocto and SBOMs It is worth noting that Yocto only generates SPDX SBOMs (SPDX 2.2, to be precise). It also creates a unique SBOM for each package, which are then linked together in `index.json` using document linking. When you have run `bitbake` to build your disk image, you can find a file named something like `[...].spdx.tar.zst` inside your deploy folder. Extract this file using `tar --zstd -xvf .spdx.tar.zst`, preferably somewhere outside of the deploy folder, because a large number of SBOMs will be generated (as mentioned above): ```bash $ ls avahi-daemon.spdx.json avahi-locale-en-gb.spdx.json base-files.spdx.json base-passwd.spdx.json bash.spdx.json bridge-utils.spdx.json busybox.spdx.json busybox-syslog.spdx.json busybox-udhcpc.spdx.json ca-certificates.spdx.json [...] ``` As you can see, each package that Yocto builds has its own SBOM. As mentioned, there is a file called `index.json` that links all these SBOMs together: ```bash $ cat index.json | jq { "documents": [ { "documentNamespace": "http://spdx.org/spdxdocs/avahi-daemon-81243a7b-5ae6-57ad-afaf-b9f620b0c46e", "filename": "avahi-daemon.spdx.json", "sha1": "97f1b5af960fe9e6246ec689a3fe04f874ad1bce" }, { "documentNamespace": "http://spdx.org/spdxdocs/avahi-locale-en-gb-35e61a4c-7f43-5d5a-8ee7-c2ba7e00f0ed", "filename": "avahi-locale-en-gb.spdx.json", "sha1": "a37a234836c785beddfd8c3b0a4343c23ae83851" }, { "documentNamespace": "http://spdx.org/spdxdocs/base-files-ee9424e3-1d7e-5739-b9cd-237a1a6f843f", "filename": "base-files.spdx.json", "sha1": "1d89ffb1e9bfb379df3a35fc3196f1e574895131" }, { "documentNamespace": "http://spdx.org/spdxdocs/base-passwd-78e3ab0a-4686-572d-a886-5105dd9b12de", "filename": "base-passwd.spdx.json", [...] ``` If we look into the actual individual SBOMs, they appear as follows: ```bash $ cat bash.spdx.json | jq { "SPDXID": "SPDXRef-DOCUMENT", "creationInfo": { "comment": "This document was created by analyzing packages created during the build.", "created": "2025-02-18T21:58:47Z", "creators": [ "Tool: OpenEmbedded Core create-spdx.bbclass", "Organization: OpenEmbedded ()", "Person: N/A ()" ], "licenseListVersion": "3.14" }, "dataLicense": "CC0-1.0", "documentNamespace": "http://spdx.org/spdxdocs/bash-0139ef99-a375-59f8-9ada-833f50f987d3", "externalDocumentRefs": [ { "checksum": { "algorithm": "SHA1", "checksumValue": "e9353b8e26447ef425aa740060f57411420c817a" }, "externalDocumentId": "DocumentRef-recipe-bash", "spdxDocument": "http://spdx.org/spdxdocs/recipe-bash-ad5747dc-7b5a-562d-aabf-dfb516e7095d" } ], "files": [ { "SPDXID": "SPDXRef-PackagedFile-bash-1", "checksums": [ { "algorithm": "SHA1", "checksumValue": "14cd85414db85903029caca727345272de829a69" }, { "algorithm": "SHA256", "checksumValue": "b1792af9b894206c749b2d03cd58e5544184d7cf49b4db7f3a632961de66231f" } ], "copyrightText": "NOASSERTION", "fileName": "usr/bin/bash.bash", "fileTypes": [ "BINARY" ], "licenseConcluded": "NOASSERTION", "licenseInfoInFiles": [ "NOASSERTION" ] } ], [...] ``` This SBOM is very detailed and complete. Kudos to the Yocto team for providing such a comprehensive solution, as it can save a significant amount of time and effort. By analyzing the Bash SBOM further using `sbomqs`, we can see that the quality is quite good: ```bash $ sbomqs score bash.spdx.json SBOM Quality by Interlynk Score:7.0 components:1 bash.spdx.json +-----------------------+--------------------------------+-----------+--------------------------------+ | CATEGORY | FEATURE | SCORE | DESC | +-----------------------+--------------------------------+-----------+--------------------------------+ | NTIA-minimum-elements | comp_with_name | 10.0/10.0 | 1/1 have names | + +--------------------------------+-----------+--------------------------------+ | | comp_with_supplier | 10.0/10.0 | 1/1 have supplier names | + +--------------------------------+-----------+--------------------------------+ | | comp_with_uniq_ids | 10.0/10.0 | 1/1 have unique IDs | + +--------------------------------+-----------+--------------------------------+ | | comp_with_version | 10.0/10.0 | 1/1 have versions | + +--------------------------------+-----------+--------------------------------+ | | sbom_authors | 10.0/10.0 | doc has 3 authors | + +--------------------------------+-----------+--------------------------------+ | | sbom_creation_timestamp | 10.0/10.0 | doc has creation timestamp | | | | | 2025-02-18T21:58:47Z | + +--------------------------------+-----------+--------------------------------+ | | sbom_dependencies | 0.0/10.0 | doc has 0 dependencies | +-----------------------+--------------------------------+-----------+--------------------------------+ | Quality | comp_valid_licenses | 10.0/10.0 | 1/1 components with valid | | | | | license | + +--------------------------------+-----------+--------------------------------+ | | comp_with_any_vuln_lookup_id | 0.0/10.0 | 0/1 components have any lookup | | | | | id | + +--------------------------------+-----------+--------------------------------+ | | comp_with_deprecated_licenses | 10.0/10.0 | 0/1 components have deprecated | | | | | licenses | + +--------------------------------+-----------+--------------------------------+ | | comp_with_multi_vuln_lookup_id | 0.0/10.0 | 0/1 components have multiple | | | | | lookup id | + +--------------------------------+-----------+--------------------------------+ | | comp_with_primary_purpose | 0.0/10.0 | 0/1 components have primary | | | | | purpose specified | + +--------------------------------+-----------+--------------------------------+ | | comp_with_restrictive_licenses | 10.0/10.0 | 0/1 components have restricted | | | | | licenses | + +--------------------------------+-----------+--------------------------------+ | | sbom_with_creator_and_version | 0.0/10.0 | 0/1 tools have creator and | | | | | version | + +--------------------------------+-----------+--------------------------------+ | | sbom_with_primary_component | 10.0/10.0 | primary component found | +-----------------------+--------------------------------+-----------+--------------------------------+ | Semantic | comp_with_checksums | 0.0/10.0 | 0/1 have checksums | + +--------------------------------+-----------+--------------------------------+ | | comp_with_licenses | 10.0/10.0 | 1/1 have licenses | + +--------------------------------+-----------+--------------------------------+ | | sbom_required_fields | 10.0/10.0 | Doc Fields:true Pkg | | | | | Fields:true | +-----------------------+--------------------------------+-----------+--------------------------------+ | Sharing | sbom_sharable | 0.0/10.0 | doc has a sharable license | | | | | free 0 :: of 1 | +-----------------------+--------------------------------+-----------+--------------------------------+ | Structural | sbom_parsable | 10.0/10.0 | provided sbom is parsable | + +--------------------------------+-----------+--------------------------------+ | | sbom_spec | 10.0/10.0 | provided sbom is in a | | | | | supported sbom format of | | | | | spdx,cyclonedx | + +--------------------------------+-----------+--------------------------------+ | | sbom_spec_file_format | 10.0/10.0 | provided sbom should be in | | | | | supported file format for | | | | | spec: json and version: | | | | | json,yaml,rdf,tag-value | + +--------------------------------+-----------+--------------------------------+ | | sbom_spec_version | 10.0/10.0 | provided sbom should be in | | | | | supported spec version for | | | | | spec:SPDX-2.2 and versions: | | | | | SPDX-2.1,SPDX-2.2,SPDX-2.3 | +-----------------------+--------------------------------+-----------+--------------------------------+ ``` Overall, Yocto's capabilities for generating SPDX SBOMs are robust, making it an excellent solution for managing SBOM-related tasks when building a Linux distribution. ## Yocto, SBOMs and sbomify Once you have your SBOMs, you can use sbomify to distribute your SBOMs to your stakeholders. Since we already have all the SBOMs for each package, we need to create a component in sbomify for each package. We can help you with this, but it's important to note that this is just the beginning of the [SBOM lifecycle](/features/generate-collaborate-analyze/).
We still need to go through the augmentation process, which adds information to the SBOM about you as the vendor. In this particular case, you might not need to go through the Enrichment process, since Yocto already has all the information we need, but you might still want to sign your SBOMs.
Moreover, since sbomify supports [SBOM hierarchy natively](/features/sbom-hierarchy/), there is no need for `index.json`. Moreover, since we've mapped each package to a component, once we release an update to a package, we can track this and have a clear audit trail of the changes. ## Conclusion If you're interested in Yocto, SBOMs and how sbomify can help you with your SBOM management and life cycle, drop us a line at [hello@sbomify.com](mailto:hello@sbomify.com) and we'll be happy to help you. --- # Chris Swan Joins sbomify Advisory Board URL: https://sbomify.com/2025/02/21/chris-swan-joins-sbomify/ Date: 2025-02-21 Description: Chris Swan, Engineer at Atsign and former CTO at UBS, joins sbomify's advisory board bringing DevOps, open source, and cybersecurity expertise. sbomify is excited to announce that Chris Swan has joined its advisory board. Chris brings extensive experience in DevOps, open source, and cybersecurity, making him an invaluable asset as sbomify continues simplifying and securing software supply chains. ![Chris Swan](/assets/images/chris_swan.webp) Chris currently serves as an Engineer at [Atsign](https://atsign.com/), working on the atPlatform, a privacy-focused open-source networking platform. He previously held leadership roles at DXC Technology, UBS, Cohesive Networks, and Credit Suisse, focusing on cloud, security, and infrastructure innovation. Chris is also known for his insightful writing as an [editor at InfoQ](https://www.infoq.com/profile/Chris-Swan/#allActivity) and as co-host of the [_Tech Debt Burndown_](https://techdebtburndown.com/) podcast. Chris's involvement with sbomify began during his work at Atsign, where he successfully integrated sbomify into their CI/CD pipeline to automate SBOM generation. This collaboration, detailed in the [Atsign case study](https://sbomify.com/case-studies/atsign), demonstrates Chris's practical approach to integrating security seamlessly into developer workflows. Chris's perspective aligns perfectly with sbomify’s mission of developer-friendly, frictionless SBOM management. _"I've been interested in SBOMs since Josh Corman first introduced me to them back in 2015. With the US Executive Order 14028 in place, and EU Cyber Resilience Act (CRA) on the way it's becoming a super hot topic, and there's lots of work to be done to make implementation easy and effective. Viktor has an incredible vision for sbomify, and I'm delighted to be able to help make it happen."_ -Chris Swan To experience effortless SBOM management, [try sbomify today](https://sbomify.com). --- # sbomify Goes Open Source: A New Chapter in SBOM Management URL: https://sbomify.com/2025/01/31/announcing-sbomify-open-sourced/ Date: 2025-01-31 Description: sbomify is now open source under Apache 2.0 plus Common Clause. Learn about our hierarchical SBOM approach, CycloneDX support, and Project Koala integration plans. I am thrilled to share that **sbomify** is now officially **open source**! As of today, you can find our project on [GitHub](https://github.com/sbomify/sbomify). This decision is a leap forward in our mission to promote transparency, collaboration, and innovation in Software Bill of Materials (SBOM) management. ## Why Now? The timing of our open-source release couldn't be more fitting. As the founder of sbomify and co-chair of a CISA Working Group on SBOM Reference Implementation, I've gained unique insights into the industry's needs. The working group is entering its final phase, developing a comprehensive white paper that will shape the future of SBOM practices. With the EU's Cyber Resilience Act (CRA) on the horizon, organizations are facing increasing pressure to adopt robust SBOM practices. This regulatory shift makes the need for accessible, enterprise-grade SBOM tooling more urgent than ever. By open-sourcing sbomify in alignment with these emerging recommendations and regulatory requirements, our team hopes to empower organizations and individuals to adopt more robust and transparent SBOM practices, sooner rather than later. ## Hierarchical SBOMs: Product, Project, & Components One of sbomify's standout features is the **hierarchical approach** to structuring SBOMs. This wasn't a theoretical design choice -- it emerged directly from our experience implementing SBOMs in real-world enterprise environments. We learned that instead of a one-size-fits-all model, organizations need a flexible, layered approach to effectively manage their software supply chain. That's why we've designed sbomify to organize SBOM data across three logical levels: - **Product**: The overarching entity -- think a product line or service offering. - **Project**: The specific application or module within that product line. - **Components**: The libraries, frameworks, and resources that power each project. [Learn more about our SBOM hierarchy approach here.](https://sbomify.com/features/sbom-hierarchy/) By embracing this organized structure, you gain clearer insights into which components belong where, making it easier to assess impact, manage updates, and streamline compliance. ## Focusing on Standards: CycloneDX & (Eventually) SPDX Our immediate goal is to be fully compliant with **CycloneDX**, and while we're not yet 100% aligned with **SPDX**, we are actively working towards it. Standardized formats are critical to ensuring consistent, dependable SBOM data. We believe that by supporting both CycloneDX and SPDX, sbomify will better serve the entire community, from open-source maintainers to enterprise security teams. ## Looking Ahead: Project Koala & TEA In addition to existing SBOM standards, we're committed to supporting [Project Koala](https://github.com/CycloneDX/transparency-exchange-api/) and the **Transparency Exchange API (TEA)**. These emerging initiatives aim to standardize how security and compliance data is exchanged. By integrating Koala and TEA capabilities into sbomify, we're helping lay the groundwork for a more unified and transparent ecosystem -- where all parties can confidently share, verify, and build upon each other's work. ## Open Source at Heart Releasing sbomify under an _Apache 2.0 license plus Common Clause_ reflects our desire to foster open collaboration while preventing unauthorized monetization. I want to extend special thanks to **OSS Capital** for their work on the [Common Clause](https://commonsclause.com/) which makes it easier to ensure that sbomify remains free for everyone to run, self-host, and adapt within their organizations. ## Join Us Star sbomify on GitHub Here are some ways you can get involved: 1. **Explore sbomify**: Check out our [GitHub repository](https://github.com/sbomify/sbomify) to install and run sbomify locally. 2. **Contribute**: Whether you have suggestions for improvements, want to report issues, or can offer code contributions, we'd love your help shaping sbomify's roadmap. 3. **Spread the Word**: Share this announcement with your network to help us grow a vibrant community around open SBOM management. Your feedback, ideas, and enthusiasm will help refine sbomify into an indispensable tool for anyone looking to streamline their SBOM processes. Our team can't wait to see what we'll build together as we embrace the principles of open source, transparency, and shared innovation. **Thank you for being a part of this journey -- let's make SBOM management easier, more secure, and more collaborative than ever before!** --- # How SBOMs Can Help You Achieve PCI DSS 4.0 Compliance URL: https://sbomify.com/2025/01/07/how-sboms-can-help-you-achieve-pci-dss-4-compliance/ Date: 2025-01-07 Description: Discover how Software Bill of Materials (SBOMs) help online gambling and e-commerce businesses achieve PCI DSS 4.0 compliance through better vulnerability management and audit trails. ### What Is PCI DSS 4.0? The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that companies that process, store, or transmit credit card information maintain a secure environment. PCI DSS 4.0 is the latest evolution of these standards, released to: - Address emerging threats - Improve security practices - Provide more flexibility in how organizations meet their security requirements Online gambling platforms and e-commerce businesses are especially impacted by PCI DSS 4.0, given their high volume of transactions and the critical nature of protecting cardholder data. CTOs, CISOs, and other security leaders in these industries must ensure their systems and processes comply with PCI DSS to avoid costly breaches and non-compliance penalties. ### What Are SBOMs? A Software Bill of Materials (SBOM) is an inventory list of all the components (libraries, modules, frameworks, etc.) that go into creating a software application or system. Think of an SBOM as a detailed recipe for your software. It helps you understand: - **What open-source or proprietary components** are in your applications - **Which versions** of those components are deployed - **Where** (in which products, projects, or services) these components are used SBOMs provide insight into potential security vulnerabilities and compliance risks arising from the software supply chain. For example, knowing exactly which version of an open-source library is integrated into your payment-processing application can be a game-changer if a critical vulnerability is discovered in that library. ### Why SBOMs Are the Solution for PCI DSS Compliance PCI DSS 4.0 emphasizes **continuous risk assessments, vulnerability management, and secure software development practices**. These objectives hinge on being able to: 1. **Identify Vulnerabilities Quickly**: You can't protect what you don't know exists. SBOMs offer a transparent, human-readable list of all your software components, making it easier to detect known vulnerabilities. 2. **Maintain Detailed Audit Trails**: PCI DSS requires organizations to maintain accurate records that prove you're following security best practices. SBOMs serve as a living documentation of your software's composition, making audits less cumbersome. 3. **Establish Accountability**: With an SBOM, teams can be held accountable for the components they choose and the updates or patches they apply (or don't apply). That traceability is crucial for demonstrating compliance. In industries like online gambling and e-commerce, where applications change rapidly due to continuous feature deployment, having an SBOM means you can react fast. Instead of scrambling to figure out where a newly discovered vulnerability might exist, you already have a reliable, up-to-date inventory of your software components. ### How sbomify Simplifies SBOM Management At [sbomify](https://sbomify.com), we understand that creating SBOMs is just the first step. Managing them, especially for a portfolio of applications, can quickly become **time-consuming** and **error-prone**. That's why we developed features to help you **organize**, **review**, and **aggregate** your SBOM data effectively. #### SBOM Hierarchy: Products and Components Our platform offers a **hierarchical approach** to managing SBOMs: - **Component-Level**: Each SBOM represents the building blocks (think individual libraries, services, or modules) - **Product-Level**: Products aggregate multiple components. For instance, if your e-commerce platform consists of a front-end, back-end, and payment gateway, each part has its own component SBOM, but you can view them collectively under the same product **Why does this matter?** Because PCI DSS isn't limited to just one application, it concerns your entire environment handling payment data. By grouping and reviewing SBOMs at both levels, you can quickly identify shared vulnerabilities or outdated components **across** your organization. [Learn more about SBOM hierarchy](https://sbomify.com/features/sbom-hierarchy/) ### Managing Complex Environments With a Central SBOM Hub In a modern DevOps or Continuous Integration/Continuous Deployment (CI/CD) environment, multiple teams and sometimes multiple CI/CD tools (GitHub Actions, Jenkins, Azure DevOps, etc.) generate SBOMs. This can create a scattered ecosystem where no single dashboard gives you a unified view of your software's entire composition. **Why a Central SBOM Hub Is Essential** - **Consolidated Visibility**: Bring together SBOMs from various build pipelines so you don't miss any critical updates or vulnerabilities - **Streamlined Processes**: Standardize how you generate, store, and review SBOMs. This makes audits simpler and reduces manual overhead - **Compliance at Scale**: As your organization grows, so does your software environment. A central hub ensures you can scale your compliance program without chaos Having a one-stop shop for all your SBOMs is particularly crucial in online gambling and e-commerce, where you might have multiple services (like account management, game or product catalogs, payment gateways, and marketing analytics) each built by different teams. PCI DSS 4.0 compliance depends on your ability to keep track of all these moving parts and prove that every software component meets security requirements. ### A Look Ahead: Compliance Beyond PCI DSS While this post focuses on PCI DSS 4.0, it's important to note that **other compliance frameworks** are increasingly looking at software supply chain security and requiring a robust accounting of your software components. Notable examples include: 1. **EU Cyber Resilience Act**: This upcoming regulation in the European Union will likely mandate stricter controls around software supply chains and could require SBOMs 2. **ISO/IEC 27001**: This widely recognized standard for information security management also emphasizes risk management of software assets 3. **Industry-Specific Regulations**: Sectors like healthcare (HIPAA) and finance (FFIEC) are adopting similar stances, pushing for greater transparency and vulnerability management in software Being proactive now by implementing SBOMs and centralizing their management will prepare your organization to meet these evolving demands head-on. ### Conclusion PCI DSS 4.0 sets the bar high for payment security, requiring organizations to be vigilant, transparent, and accountable in how they handle cardholder data. **SBOMs are a powerful tool** in meeting these requirements because they give security teams the visibility and traceability they need to manage vulnerabilities and prove compliance. [sbomify](https://sbomify.com) goes a step further by making **SBOM management simpler**, offering product- and component-level views and a central hub for consolidating all your SBOMs. If you operate in online gambling or e-commerce, where the risks and compliance stakes are especially high, adopting a single, centralized platform to manage your SBOMs is no longer optional, it's essential. Ready to take control of your software supply chain and secure your path to PCI DSS 4.0 compliance? [Get started with sbomify](https://sbomify.com/) --- # The C conundrum - generating SBOMs when there's no lockfile URL: https://sbomify.com/2024/11/18/c-conundrum/ Date: 2024-11-18 Description: Exploring the challenge of generating SBOMs for C/C++ projects without native package managers, reviewing cmake-sbom, Conan, cve-bin-tool, and CISA working group efforts. Generating an SBOM for something created in a modern language like Dart, Go, Python or Rust is pretty easy. Dependencies are declared using the language's package manager, the package manager creates a .lock file, and then an SBOM can be generated from the .lock file. Under the hood sbomify uses [Trivy](https://trivy.dev/) to do that, and other tools like [Syft](https://github.com/anchore/syft) do the same. (Note: we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise and have removed it from sbomify-action.) There's no package manager for C though, at least not a universally used one. That's a huge problem, because apps developed using modern languages where it's easy to create SBOMs are the very tip of an iceberg where stuff developed in C is both the rest of the visible iceberg and everything beneath the surface - the apps we know are written in C, and the numerous libraries etc. that they're built on top of. How are people going to comply with Executive Order 14028 (in the US) and the forthcoming Cyber Resilience Act (CRA) in the EU if they're dealing with that iceberg of C? Where there are package managers we can reasonably expect their maintainers to start churning out SBOMs. [The Yocto Project](https://www.yoctoproject.org/), which builds embedded Linux distributions, has taken an early lead with their machinery for [Creating a Software Bill of Materials](https://docs.yoctoproject.org/dev/dev-manual/sbom.html). It's also reasonable to expect that major distributions like Debian and Red Hat will follow suit. They do after all have all the metadata that's needed, and they've already spent years on careful curation. But what about all the apps that aren't in major distro package managers? There are a few pieces to the puzzle out there, but not yet a complete solution. - [cmake-sbom](https://github.com/DEMCON/cmake-sbom) can add the SBOM creation process to CMake (a popular tool for building C projects), but a lot of the data entry (and subsequent maintenance) is manual. This perhaps provides the boilerplate for NTIA compliance, but doesn't really help with upstream dependencies. - [Zephyr](https://www.zephyrproject.org/) has the ability to generate SPDX for the embedded systems it creates, based on earlier work in [cmake-spdx](https://github.com/swinslow/cmake-spdx). But that hasn't yet been cycled back into a generic tool that could be used by other CMake based projects. - [Conan](https://conan.io/) is a package manager for C/C++, with many popular dependencies already present there. That opens the door to generating SBOMs from `conan.lock` files, but right now the resulting files (at least those generated by Syft) are of very poor quality, with incomplete CFEs. - [cve-bin-tool](https://github.com/intel/cve-bin-tool) can generate an SBOM from the libraries it finds in a binary, but: - Only a limited subset of libraries are discoverable to the tool. - When generating SBOMs from test binaries they were of poor quality. - cve-bin-tool flags binaries and the libraries they contain as being vulnerable even when they've been patched to fix the relevant CVE, implying a naive matching mechanism. - [it-depends](https://github.com/trailofbits/it-depends) finds nothing (and it seems it's a [known issue](https://github.com/trailofbits/it-depends/issues/66) despite the README saying it supports CMake projects). Thankfully efforts are underway to resolve these problems. C (and C++) is lined up for [Phase 3](https://github.com/CISA-SBOM-Community/SBOM-Generation?tab=readme-ov-file#phase-3) of the SBOM Generation Reference Implementations within the CISA SBOM Community; and the working group had a call in the past week to look at what's already working and where effort can most effectively be applied to provide tools for a broader range of projects. This is a guest post from [Chris Swan](https://cpswan.net), an Engineer at [Atsign](https://atsign.com) who are an early adopter of sbomify. --- # sbomify GitHub Action v0.3.0: Now Faster and Compatible with GitLab! URL: https://sbomify.com/2024/11/12/gitlab-support/ Date: 2024-11-12 Description: sbomify GitHub Action v0.3.0 release adds GitLab CI/CD support, 50% faster build times, and bug fixes for Docker image SBOM generation. We’re excited to announce the release of version [0.3.0](https://github.com/sbomify/sbomify-action/releases/tag/v0.3.0) of our [GitHub Actions module](https://github.com/sbomify/sbomify-action)! This update brings some valuable enhancements, including: - **GitLab support:** Responding to popular demand, you can now use our sbomify toolkit with GitLab, making it easier than ever to integrate SBOM generation into your GitLab CI/CD workflows. Check out the details [here](https://github.com/sbomify/sbomify-action#using-in-gitlab). - **Improved speed:** We’ve optimized the toolchain to reduce build times by **50%** or more, even on high-performance servers. - **Bug fixes:** This release includes fixes for issues encountered when building SBOMs from Docker images, ensuring a smoother experience. --- # GitHub Action module with Attestation URL: https://sbomify.com/2024/10/31/github-action-update-and-attestation/ Date: 2024-10-31 Description: New features in sbomify's GitHub Action including Dart lockfile support, Docker image SBOMs, NTIA enrichment, and SLSA build provenance attestation. Over the last few weeks, we've made some significant updates to our [GitHub Actions module](https://github.com/sbomify/sbomify-action). Since our last update, we've added a few new features. ## Changelog - Support for Dart lockfiles - Support for Docker images (system packages only) - Full support for [Enrichment and Augmentation](https://sbomify.com/features/generate-collaborate-analyze/), meaning we can automatically complete your SBOMs to make them NTIA Minimum Elements compatible - Documentation on how to use attestation with the GitHub Actions module (more on that below) - Bumped versions of various sub-components - Various bug fixes ## Using Attestation Thanks to recent improvements by GitHub, generating an attestation is now very straightforward. Behind the scenes, the GitHub Actions module [attest-build-provenance](https://github.com/actions/attest-build-provenance) will automatically generate a [SLSA build provenance](https://slsa.dev/spec/v1.0/provenance) predicate using the [in-toto](https://github.com/in-toto/attestation/tree/main/spec/v1) format. All you need to do is instruct our GitHub Actions module to write the SBOM to disk, and then point the attestation tool to this file – voila! You now have a cryptographically signed attestation of your SBOM. At sbomify, we are big fans of dogfooding our own product, so we've adopted this exact flow in the SBOM we generate for our GitHub Actions module itself, as you can see in [the sbomify-action workflow file](https://github.com/sbomify/sbomify-action/blob/master/.github/workflows/sbomify.yaml). The job looks something like this: ```yaml [...] - name: Upload SBOM uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: 'Gu9wem8mkX' LOCK_FILE: 'poetry.lock' COMPONENT_NAME: 'sbomify-github-action' COMPONENT_VERSION: ${{ github.ref_name }} AUGMENT: true ENRICH: true UPLOAD: true OUTPUT_FILE: github-action.cdx.json - name: Attest uses: actions/attest-build-provenance@v1 with: subject-path: '${{ github.workspace }}/github-action.cdx.json' ``` For more details on using the GitHub Action and other CI/CD integrations, see our [integrations page](/features/integrations/). What’s great about this is that it removes the need to trust sbomify directly. You can verify the SBOM independently as follows: - Download the latest SBOM from the GitHub Action [sbomify public page](https://app.sbomify.com/component/Gu9wem8mkX) - Install the GitHub CLI if you don't already have it With this done, you can verify the file against GitHub: ```bash $ gh attestation verify path/to/downloaded-sbom.json --owner sbomify Loaded digest sha256:aeee57eeb5b34e0f70ace59bfc2328e3332062523796837eb37883eb805cd8f9 for file:///path/to/downloaded-sbom.json Loaded 1 attestation from GitHub API ✓ Verification succeeded! sha256:aeee57eeb5b34e0f70ace59bfc2328e3332062523796837eb37883eb805cd8f9 was attested by: REPO PREDICATE_TYPE WORKFLOW sbomify/sbomify-action https://slsa.dev/provenance/v1 .github/workflows/sbomify.yaml@refs/tags/v0.1.1 ``` And just like that! We can independently verify that sbomify (or any other intermediary) did not tamper with the SBOM in transit. --- # Big update to our GitHub Action URL: https://sbomify.com/2024/10/04/github-action-update/ Date: 2024-10-04 Description: Major overhaul of sbomify GitHub Action transforming it from a simple upload tool to a complete SBOM Swiss Army knife with generation, augmentation, and enrichment. In the last few weeks, we've worked hard on overhauling the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) based on customer feedback. The initial purpose of the GitHub Action module was merely to upload SBOMs to the sbomify platform. We've now broadened the scope to make it more powerful, with the goal of creating NTIA Minimum Elements compliant SBOMs directly in your CI/CD pipeline with minimal fuss. As a refresher, the SBOM lifecycle looks like this:
Notice that there are three required steps in the Authoring phase: - Generation - Augmentation - Enrichment Thus, we've gone from being a simple upload tool to a complete SBOM Swiss Army knife, where we combine the best open-source tools in the industry to generate a complete SBOM. All you need to do is provide either an SBOM or a (supported) lockfile, and we take care of the rest. This is what it looks like in your Actions YAML file: ```yaml - name: Upload SBOM uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: 'my-component-id' SBOM_FILE: 'sbom-file.json' COMPONENT_NAME: 'my-app' COMPONENT_VERSION: ${{ github.ref_name }} AUGMENT: true ENRICH: true ``` We didn't stop there. You can also now use the action in stand-alone mode without sbomify to generate SBOMs: ```yaml - name: Generate SBOM uses: sbomify/sbomify-action@master env: LOCK_FILE: 'requirements.txt' COMPONENT_NAME: 'my-python-app' COMPONENT_VERSION: ${{ github.ref_name }} ENRICH: true UPLOAD: false OUTPUT_FILE: 'my_sbom.cdx.json' ``` This will take the file `requirements.txt`, build an SBOM, then enrich the SBOM (using Ecosyste.ms), and finally write the file `my_sbom.cdx.json` to disk. For more details on using the GitHub Action and other CI/CD integrations, see our [integrations page](/features/integrations/). --- # Introducing sbomify: Revolutionizing SBOM Management URL: https://sbomify.com/2024/08/29/launching-sbomify/ Date: 2024-08-29 Description: Announcing the launch of sbomify, a platform for automated SBOM management and sharing that integrates with CI/CD pipelines to ensure stakeholders always have the latest SBOMs. We’re excited to announce the launch of sbomify, a platform designed to transform how businesses manage and share Software Bill of Materials (SBOMs). Our journey to create sbomify began with a clear observation – many companies, particularly those in regulated industries, are struggling to keep up with the increasing demand for SBOMs. This need has only intensified with mandates like the US Executive Order 14028, the upcoming EU Cyber Resilience Act, and the CISA's [Secure by Design](https://www.cisa.gov/securebydesign) initiative, which calls for radical transparency in software development. As the founder of [Screenly](https://www.screenly.io), I observed firsthand the growing challenges software vendors face when it comes to managing and sharing SBOMs. It became glaringly obvious that manually sending SBOMs to customers via email or storing them on internal file servers was completely unrealistic. The process was not only time-consuming but also prone to errors and delays, making it an inefficient way to ensure that customers had access to the most up-to-date information. This challenge is further emphasized in CISA’s [Sharing Primer on SBOMs](https://www.cisa.gov/sites/default/files/publications/Sharing-SBOMs-Primer-CISA-508.pdf), which highlights the importance of efficient and secure SBOM sharing practices. Over the past year, I’ve also had numerous conversations with CTOs and CISOs across various industries about how they currently manage SBOMs. It became clear that most companies are still relying on manual processes to handle these critical documents. Whether it's through email, internal file shares, or other outdated methods, the consensus was that there had to be a better way – one that aligns with the dynamic nature of SBOMs in modern CI/CD environments. This is where sbomify comes in. sbomify automates the entire SBOM management process by integrating directly with your CI/CD pipeline. With each new release, the latest SBOM is automatically uploaded to sbomify, providing stakeholders with instant, real-time access. No more cumbersome email chains or dealing with outdated files – sbomify ensures your SBOMs are always up-to-date and easily accessible. To understand how sbomify fits into the SBOM ecosystem, it’s essential to recognize the three key parts of the SBOM life cycle: [**generation, collaboration, and analysis**](/features/generate-collaborate-analyze/). sbomify focuses purely on the collaboration aspect, ensuring that once SBOMs are generated, they can be easily shared and accessed in real-time by all relevant stakeholders. We believe that efficient collaboration is the backbone of effective SBOM management, which is why we’ve built sbomify to excel in this area. ![SBOM hub](/assets/images/site/marketplace.webp) However, we also recognize the importance of the other two components - generation and analysis. That’s why sbomify will be partnering and integrating with leading third-party providers who specialize in these areas. Our goal is to create a seamless experience where SBOMs can be generated, collaborated on, and analyzed, all through interconnected tools that work together to ensure comprehensive SBOM management. We’re excited about the possibilities sbomify offers and would love to hear your thoughts or discuss how it can benefit your organization. You can request early access up using [this form](https://docs.google.com/forms/d/e/1FAIpQLSe1-SCbmyPnhHxP1RHIYi4iKP2CLy6SXcqFOP1i7B8VHZJYkw/viewform?usp=sf_link). --- # Exploring the Future of Software Security: Join Us at BSides Bristol URL: https://sbomify.com/2024/08/26/bsides-bristol/ Date: 2024-08-26 Description: sbomify presents 'Navigating the SBOM Landscape: Formats, Relevance, and Tooling in 2024' at BSides Bristol, covering SPDX, CycloneDX, and current SBOM tooling. This weekend marks an exciting event for the cybersecurity community – [BSides Bristol](https://www.bsidesbristol.org.uk/) is officially kicking off! We’re thrilled to be a part of this dynamic conference, where we’ll be presenting a talk on a topic that’s rapidly gaining significance: [Navigating the SBOM Landscape: Formats, Relevance, and Tooling in 2024](https://pretalx.com/bsides-bristol-2024/talk/EX8YC8/). ## What’s Our Talk About? In recent years, the concept of a Software Bill of Materials (SBOM) has emerged as a cornerstone of modern cybersecurity practices. With growing global attention – highlighted by the US executive order aimed at enhancing national cybersecurity and the UK’s Code of Practice for Software Vendors - SBOMs are increasingly recognized as essential tools for ensuring software transparency and mitigating risks. Our talk is designed to dive deep into the world of SBOMs, exploring why they are becoming indispensable in today’s cybersecurity framework. We’ll discuss the key SBOM formats – SPDX and CycloneDX – offering a detailed look at their features, benefits, and how they contribute to a more secure software ecosystem. But understanding the formats is just the beginning. We’ll also provide an overview of the current SBOM tooling landscape, highlighting the technologies that are making it easier for organizations to manage and utilize SBOMs effectively. Whether you’re a developer, a security professional, or a decision-maker, this session will equip you with the knowledge to navigate the SBOM landscape confidently. ## Why Should You Attend? This talk is more than just an introduction to SBOMs. It’s a comprehensive guide to understanding their significance in today’s cybersecurity efforts. You’ll leave with a clear grasp of the different SBOM formats, the state-of-the-art tools available, and practical insights into how these can be applied to enhance software security and ensure regulatory compliance. If you’re committed to advancing your organization’s software security practices, this session is one you won’t want to miss. We look forward to seeing you at BSides Bristol and engaging in this important conversation about the future of software security. ## Update The slides from the talk can be found [here](https://speakerdeck.com/vpetersson/navigating-the-sbom-landscape-formats-relevance-and-tooling-in-2024-at-bsides-bristol-24). --- # Announcing sbomify's GitHub Actions Module: Seamlessly Share SBOMs in Your CI/CD Pipeline URL: https://sbomify.com/2024/08/21/introducing-github-action-module/ Date: 2024-08-21 Description: Introducing sbomify's GitHub Actions module for automated SBOM generation in your CI/CD pipeline. Available on GitHub Marketplace for seamless integration. We are thrilled to announce the launch of **sbomify's GitHub Actions Module** – now available in the [GitHub Marketplace](https://github.com/marketplace/actions/sbomify)! This powerful tool simplifies the process of generating Software Bill of Materials (SBOMs) right within your CI/CD pipeline, ensuring that your software components are transparently documented and compliant with industry standards. ## Why sbomify? As software development evolves, transparency and security have become paramount. A Software Bill of Materials (SBOM) is a detailed list of components used in building a piece of software, allowing teams to manage vulnerabilities, license compliance, and supply chain risks effectively. With sbomify, you can automatically generate SBOMs as part of your development workflow, making it easier to maintain a secure and compliant software development lifecycle. ## Introducing sbomify’s GitHub Actions Module The sbomify GitHub Action is designed to integrate seamlessly with your existing CI/CD pipelines, offering: - **Automated SBOM Generation**: Automatically create SBOMs for your software projects as part of your CI/CD process, ensuring consistent documentation across all builds. - **Compliance and Security**: Maintain compliance with industry standards and improve your software’s security posture by documenting all dependencies and components. - **Easy Integration**: Simply add the sbomify Action to your workflow file, and it takes care of the rest. No complex configurations are required. ## How to Get Started Getting started with sbomify is easy! Here's how you can integrate it into your project: 1. **Visit the Marketplace**: Head over to the [GitHub Marketplace](https://github.com/marketplace/actions/sbomify) to find the sbomify Action. 2. **Add sbomify to Your Workflow**: Add the sbomify Action to your GitHub Actions workflow by modifying your `.yml` file(s). You can find detailed setup instructions in the [sbomify GitHub repository](https://github.com/sbomify/sbomify-action). 3. **Run Your Workflow**: Once integrated, every time your workflow runs, sbomify will automatically upload the generated SBOM for your project, which in turn can be shared with your stakeholders. No more manual sharing of SBOMs over emails, your stakeholders can automatically pull down the latest SBOM directly from sbomify when they need it, ensuring they always have the latest version. Here's a quick example of how to include sbomify in your workflow: ```yaml name: Build and Generate SBOM on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # Build your SBOM... - name: Upload SBOM uses: sbomify/sbomify-action@master env: TOKEN: ${{ secrets.SBOMIFY_TOKEN }} COMPONENT_ID: 'my-component-id' SBOM_FILE: 'sbom-file.json' COMPONENT_NAME: 'my-app' COMPONENT_VERSION: ${{ github.ref_name }} AUGMENT: true ENRICH: true ``` For more details on using the GitHub Action and other CI/CD integrations, see our [integrations page](/features/integrations/). ## Not using GitHub Actions? No problem! Our tool can easily be integrated in any other CI/CD pipeline. Just get in touch and we'll help you. ## Join Us in Building More Secure Software As software supply chains become increasingly complex, tools like sbomify are essential for maintaining transparency and security. By integrating sbomify into your workflows, you're taking a proactive step towards better software management and compliance. We’re excited to see how sbomify will help you build more secure and transparent software. Try it out today by visiting the [GitHub Marketplace](https://github.com/marketplace/actions/sbomify) and start sharing your SBOMs with ease! --- # Comparing SBOM Formats: Focus on Component Types in CycloneDX vs. SPDX URL: https://sbomify.com/2024/08/20/sbom-component-types/ Date: 2024-08-20 Description: A detailed comparison of CycloneDX and SPDX SBOM formats, analyzing their support for applications, libraries, containers, operating systems, and SaaS components. CycloneDX and SPDX are two leading SBOM (Software Bill of Materials) standards, each with distinct strengths and support for various component types. CycloneDX is well-suited for modern, agile environments due to its broad support for containers, SaaS, and hardware-related components, making it ideal for organizations requiring a flexible, lightweight SBOM format. In contrast, SPDX excels in compliance-focused documentation, particularly for open-source software, offering extensive support for license information and provenance tracking. This makes SPDX the preferred choice in industries where legal and regulatory compliance is critical. ## Comparing SBOM Formats: Focus on Component Types in CycloneDX vs. SPDX When choosing between CycloneDX and SPDX for creating Software Bill of Materials (SBOMs), it's essential to understand the different component types these standards support and how they align with various use cases. Both formats have their strengths, but their support for different component types varies, making them suitable for different environments and requirements. Let's dive into the component types supported by each and what they are used for. ### 1. **Applications** **CycloneDX**: - **Component Type**: Application - **Usage**: CycloneDX supports detailed SBOMs for entire applications, capturing all dependencies and modules involved. This is particularly useful for organizations needing a comprehensive view of their software products, including all embedded third-party software, to assess vulnerabilities and manage updates efficiently. CycloneDX's flexibility makes it a preferred choice for agile environments where software components evolve rapidly. **SPDX**: - **Component Type**: Package - **Usage**: In SPDX, applications are typically represented as packages. SPDX excels in documenting the licensing and provenance of each component within the application, making it suitable for industries with strict compliance requirements, such as automotive or healthcare sectors. SPDX’s detailed package-level information helps ensure that all components meet the necessary legal and regulatory standards [1]. ### 2. **Libraries** **CycloneDX**: - **Component Type**: Library - **Usage**: CycloneDX supports library SBOMs with a focus on ease of integration and automation. It’s designed to help developers and security teams quickly identify vulnerable libraries and ensure that open-source components are up-to-date. The format is lightweight, making it easy to integrate into CI/CD pipelines for continuous monitoring. **SPDX**: - **Component Type**: Package, File, Snippet - **Usage**: SPDX offers more granularity with its support for packages, files, and snippets. This allows organizations to track and document every piece of a library, down to individual files and code snippets, along with their licensing information. This level of detail is particularly beneficial for managing open-source license compliance across large and complex codebases [2]. ### 3. **Containers** **CycloneDX**: - **Component Type**: Container - **Usage**: CycloneDX is well-suited for container environments, providing detailed information about each layer within a container image. This includes everything from the base image to individual libraries and configurations used within the container. CycloneDX’s container SBOMs are valuable for DevOps teams looking to maintain consistency and security across development, testing, and production environments. **SPDX**: - **Component Type**: Package (representing containers) - **Usage**: While SPDX can document containers by treating them as packages, its primary strength lies in its detailed documentation of each component within the container. This includes extensive metadata on licensing and provenance, making SPDX useful in environments where understanding the legal and security implications of every component within a container is critical [3]. ### 4. **Operating Systems and Devices** **CycloneDX**: - **Component Type**: Operating System, Device - **Usage**: CycloneDX extends beyond traditional software components to include operating systems and devices. This makes it ideal for scenarios where the interaction between software and hardware is a primary concern. **SPDX**: - **Component Type**: No direct equivalent - **Usage**: SPDX does not natively support the documentation of operating systems or devices. It is more focused on traditional software components like files, packages, and licenses [4]. ### 5. **SaaS and Services** **CycloneDX**: - **Component Type**: Service - **Usage**: CycloneDX shines in environments that rely on cloud-native architectures, supporting the documentation of Software as a Service (SaaS) and other services. This includes external APIs, authentication mechanisms, and other service-related components. **SPDX**: - **Component Type**: No direct equivalent - **Usage**: SPDX does not natively support the documentation of SaaS or service components [5]. ## References - [1] Sonatype. (n.d.). SPDX vs CycloneDX: Choosing the Right SBOM Format for Your Organization. Retrieved from - [2] Security Boulevard. (2020). CycloneDX vs SPDX: Which is Best for Your Use Case? Retrieved from - [3] Security Boulevard. (2020). Container Security with CycloneDX and SPDX. Retrieved from - [4] Sonatype. (n.d.). Operating System and Device Documentation with CycloneDX. Retrieved from - [5] Security Boulevard. (2020). SaaS and Service Documentation with CycloneDX. Retrieved from --- # What Is SLSA? Understanding Supply Chain Levels for Software Artifacts URL: https://sbomify.com/2024/08/17/what-is-slsa/ Date: 2024-08-17 Description: What is SLSA? The OpenSSF framework for software supply chain security defines three build levels for provenance and integrity. Learn how SLSA works, how it builds on in-toto, and how to adopt it with GitHub Actions. In 2020, attackers compromised SolarWinds' build system and injected malicious code into Orion software updates that were distributed to roughly 18,000 organizations, including multiple U.S. government agencies. The attack succeeded because there was no verifiable record of what the build system was _supposed_ to produce – so no one noticed when it started producing something different. **[SLSA](https://slsa.dev/)** (Supply chain Levels for Software Artifacts, pronounced "salsa") is a framework designed to prevent exactly this kind of attack. It defines a set of progressively stronger requirements for how software is built, producing a signed, tamper-evident record – called **provenance** – that documents exactly how, where, and by whom an artifact was created. Maintained by the [Open Source Security Foundation (OpenSSF)](https://openssf.org/), SLSA provides a common language for describing build security maturity, from basic documentation to hardened, tamper-resistant build platforms. ## The SLSA Build Levels SLSA v1.0 defines three build levels, each adding stronger guarantees against different classes of supply chain threats. ### Build L1: Provenance Exists At Level 1, the build process produces provenance – a document that records what was built, from what source, using which build system. The provenance format is an [in-toto attestation](/2024/08/14/what-is-in-toto/) with an SLSA Provenance predicate. **Requirements:** - Provenance is generated and available to consumers - The provenance document follows the SLSA provenance format - The build process is documented **What it prevents:** Build L1 does not prevent attacks, but it creates a baseline of transparency. If a compromised artifact is later discovered, provenance helps trace where the failure occurred. It also enables consumers to make informed decisions about which artifacts to trust. ### Build L2: Hosted Build Platform At Level 2, provenance must be generated by a _hosted build service_ – not the developer's local machine. The build service signs the provenance, attesting that it accurately reflects the build it performed. **Requirements:** - All Build L1 requirements - Builds run on a hosted build platform (e.g., GitHub Actions, Google Cloud Build, GitLab CI) - The build platform generates and signs the provenance (the developer cannot forge it) - Provenance includes the builder identity, source reference, and build configuration **What it prevents:** Build L2 prevents developers from fabricating provenance. Because the build platform generates the provenance, a compromised developer account cannot create forged provenance claiming an artifact was built from clean source code when it was not. ### Build L3: Hardened Builds At Level 3, the build platform itself must be hardened against tampering. Builds run in isolated environments where even the build platform's own administrators cannot manipulate individual builds. **Requirements:** - All Build L2 requirements - Builds run in isolated, ephemeral environments - The build platform prevents cross-build contamination (one build cannot influence another) - Secrets and signing keys are isolated from build workloads - The build platform has a verifiable record of its own integrity **What it prevents:** Build L3 prevents insider threats at the build platform level. Even if an attacker compromises the CI/CD infrastructure, the isolation guarantees mean they cannot inject code into a specific build without detection. This is the level required to defend against SolarWinds-class attacks. ## How SLSA Provenance Works SLSA provenance is a machine-readable document that answers three questions about a software artifact: 1. **What was built?** – The artifact's digest (cryptographic hash) 2. **How was it built?** – The source repository, commit, build configuration, and builder identity 3. **Who built it?** – The build platform and its identity credentials Provenance is expressed as an [in-toto attestation](/2024/08/14/what-is-in-toto/) – a signed envelope containing a typed predicate. The SLSA Provenance predicate type includes fields for the builder, build configuration, source materials, and metadata. The attestation is signed using [Sigstore](/2024/08/12/what-is-sigstore/) (keyless signing) or traditional key-based signing, and the signature is recorded in a transparency log. A simplified example of what provenance captures: ``` Subject: my-app:v1.2.3 (sha256:abc123...) Builder: GitHub Actions (github.com/actions/runner) Source: github.com/my-org/my-app @ commit def456 Build: .github/workflows/release.yml Timestamp: 2026-02-20T14:30:00Z ``` Consumers verify provenance by checking the signature, confirming the builder identity, and validating that the source and build configuration match their expectations. Tools like `cosign verify-attestation` and `slsa-verifier` automate this process. ## The Supply Chain Threats SLSA Addresses SLSA's levels map to specific threat categories in the software supply chain. The framework's [threat model](https://slsa.dev/spec/v1.0/threats-overview) identifies attacks at each stage of the development process. | Threat | Example | SLSA Level | | -------------------------- | ---------------------------------------------------- | ----------------------- | | No provenance | Consumers cannot verify how an artifact was built | Build L1 | | Forged provenance | Developer fabricates provenance for a modified build | Build L2 | | Compromised build platform | Attacker injects code via CI/CD infrastructure | Build L3 | | Compromised source | Unauthorized commit pushed to repo | Source track (separate) | | Compromised dependencies | Malicious transitive dependency | Not yet covered by SLSA | Note that SLSA v1.0 focuses on the _build_ track. Source integrity (protecting the source repository from unauthorized changes) is being developed as a separate track. Dependency management is out of scope for SLSA but is addressed by complementary tools like [SBOMs](/what-is-sbom/) and [vulnerability scanning](/2026/02/01/sbom-scanning-vulnerability-detection/). ## Real-World Adoption ### GitHub Actions GitHub's [artifact attestation](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds) feature generates SLSA Build L1 provenance for any artifact built with GitHub Actions. The provenance is an [in-toto attestation](/2024/08/14/what-is-in-toto/) signed via [Sigstore](/2024/08/12/what-is-sigstore/) and stored alongside the artifact. Verification is available via the GitHub CLI: ```bash gh attestation verify my-artifact.tar.gz --owner my-org ``` For Build L2/L3, the [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) uses GitHub's reusable workflows to generate provenance in an isolated build context, preventing the calling workflow from tampering with the provenance. ### Google Cloud Build Google Cloud Build natively generates SLSA Build L3 provenance for container images. Provenance is automatically signed and can be verified using Binary Authorization for admission control in GKE clusters. ### npm and PyPI The npm registry includes SLSA provenance for packages built via GitHub Actions, and PyPI supports provenance through its Trusted Publishers feature. Both use [Sigstore](/2024/08/12/what-is-sigstore/) for signing, allowing consumers to verify that a package was built from the stated source. ### Kubernetes All Kubernetes release artifacts include SLSA Build L3 provenance, allowing cluster operators to verify that the binaries they deploy were produced by the Kubernetes project's official build infrastructure. ## SLSA and SBOMs SLSA and [SBOMs](/what-is-sbom/) address different parts of the software supply chain security problem, and they are most effective when used together. - **SLSA provenance** answers: _How was this artifact built, and can I trust the build process?_ - **SBOMs** answer: _What components are inside this artifact, and do any have known vulnerabilities?_ An organization that generates SLSA provenance for its builds _and_ produces SBOMs for its artifacts covers both integrity (the build was not tampered with) and visibility (the contents are known and monitorable). Provenance without an SBOM means you trust the build but do not know what is inside. An SBOM without provenance means you know what is inside but cannot verify the build was legitimate. Both SLSA provenance and SBOMs can be expressed as [in-toto attestations](/2024/08/14/what-is-in-toto/), signed with [Sigstore](/2024/08/12/what-is-sigstore/), and managed alongside artifacts. For organizations using [sbomify](https://sbomify.com) for SBOM management, pairing SBOMs with SLSA provenance provides a comprehensive picture: verified build integrity and a complete component inventory. ## Getting Started with SLSA ### Step 1: Achieve Build L1 Generate provenance for your builds. If you use GitHub Actions, enable artifact attestations: ```yaml permissions: id-token: write contents: read attestations: write steps: - uses: actions/checkout@v4 - run: make build - uses: actions/attest-build-provenance@v2 with: subject-path: dist/my-app ``` This produces an SLSA Build L1 provenance attestation signed via Sigstore. ### Step 2: Move to Build L2/L3 Use the [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) for isolated provenance generation that the calling workflow cannot tamper with: ```yaml jobs: build: # ... your build steps ... provenance: needs: build uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0 with: base64-subjects: ${{ needs.build.outputs.digest }} ``` ### Step 3: Verify Provenance Consumers can verify provenance using the SLSA verifier: ```bash slsa-verifier verify-artifact my-app \ --provenance-path my-app.intoto.jsonl \ --source-uri github.com/my-org/my-app ``` ## SLSA in the Compliance Context SLSA aligns with emerging supply chain security regulations: - **[Executive Order 14028](/compliance/eo-14028/)** requires software producers to attest to secure development practices, including build integrity. SLSA provenance provides the mechanism for this attestation. - **[NIST SSDF (SP 800-218)](https://csrc.nist.gov/publications/detail/sp/800-218/final)** recommends protecting all forms of code from unauthorized access and tampering. SLSA's build levels directly address this by progressively hardening the build process. - **[EU CRA](/compliance/eu-cra/)** requires demonstrating supply chain security processes. SLSA provenance provides auditable evidence of build integrity. - **[CISA minimum elements](/compliance/cisa-minimum-elements/)** recommend that SBOMs include build information. SLSA provenance complements SBOMs by providing detailed, verified build records. ## Frequently Asked Questions ### What is SLSA? SLSA (Supply chain Levels for Software Artifacts, pronounced "salsa") is a security framework that defines three build levels of increasing rigor for producing software artifacts with verifiable provenance. It provides a common language for describing build security maturity, from basic provenance documentation (Build L1) to hardened, tamper-resistant build platforms (Build L3). SLSA is maintained by the [Open Source Security Foundation (OpenSSF)](https://openssf.org/). ### What are the SLSA build levels? SLSA v1.0 defines three build levels. Build L1 requires that provenance exists and documents the build process. Build L2 requires that provenance is generated by a hosted build platform (not the developer's machine), making it harder to forge. Build L3 requires a hardened build platform with isolated, tamper-resistant build environments, preventing even the build platform's own administrators from manipulating individual builds. ### How is SLSA related to in-toto? SLSA uses the [in-toto attestation format](/2024/08/14/what-is-in-toto/) for all its provenance documents. An SLSA provenance attestation is an in-toto attestation with a specific predicate type that records build parameters, source information, and builder identity. in-toto provides the format; SLSA provides the security requirements. ### How do I get started with SLSA? The fastest path is to use a CI/CD platform that already supports SLSA provenance generation. GitHub Actions provides SLSA Build L1 provenance through its [artifact attestation feature](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds). The [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) can produce Build L2/L3 provenance. Google Cloud Build also supports SLSA provenance natively. ### Is SLSA required by any regulations? SLSA is not mandated by name in any regulation, but its requirements align with [Executive Order 14028](/compliance/eo-14028/) (which requires attestation of secure development practices), the [NIST SSDF](https://csrc.nist.gov/publications/detail/sp/800-218/final) (which requires protecting build integrity), and the [EU Cyber Resilience Act](/compliance/eu-cra/) (which requires supply chain security processes). Adopting SLSA helps demonstrate compliance with these frameworks. --- # What Is in-toto? Securing the Software Supply Chain End to End URL: https://sbomify.com/2024/08/14/what-is-in-toto/ Date: 2024-08-14 Description: What is in-toto? The CNCF-graduated framework uses layouts, signed link metadata, and end-to-end verification to cryptographically prove every build step happened as intended. Learn how it underpins SLSA, GitHub attestations, and SBOM integrity. When the [XZ Utils backdoor](/2024/04/13/what-really-happened-to-xz/) was discovered in March 2024, it revealed how a malicious contributor could spend years infiltrating an open-source project to inject a supply chain compromise. The attack succeeded because there was no cryptographic verification that the build steps producing the XZ binary matched the intended, authorized process. This is precisely the problem that **[in-toto](https://in-toto.io/)** was designed to solve. in-toto is a framework for securing the _entire_ software supply chain – from source commit to deployed artifact – by cryptographically recording and verifying every step along the way. Originally developed at New York University's [Secure Systems Lab](https://ssl.engineering.nyu.edu/) by Professor Justin Cappos and Santiago Torres-Arias, in-toto has grown from an academic research project into a [CNCF graduated project](https://www.cncf.io/projects/in-toto/) and the foundation of the modern software supply chain security ecosystem. The name comes from the Latin phrase meaning "in total" or "completely," reflecting its end-to-end approach. ## How in-toto Works in-toto establishes a cryptographic chain of trust across every step in a software supply chain. It does this through three core concepts: layouts, link metadata, and verification. ### Layouts: The Blueprint A layout is a signed document that defines the _intended_ supply chain. It specifies: - **The steps** involved in producing the software (e.g., clone source, run tests, compile, package) - **Who is authorized** to perform each step (identified by cryptographic keys) - **What materials and products** each step should consume and produce (e.g., the compile step takes source files as input and produces a binary as output) - **Inspection rules** that must hold true across steps (e.g., the files that leave one step must be the same files that enter the next) The layout is signed by the project owner – the authority who defines what the supply chain _should_ look like. Think of it as a security policy for your build pipeline, expressed in a machine-verifiable format. ### Link Metadata: The Evidence As each step in the layout is executed, the entity performing it generates _link metadata_ – a signed record containing: - The **command** that was run - The **materials** (input files and their cryptographic hashes) consumed by the step - The **products** (output files and their cryptographic hashes) produced by the step - The **cryptographic signature** of the authorized functionary who performed the step Each link is signed by the functionary's private key, creating tamper-evident proof that the step was performed by an authorized party and that the inputs and outputs are exactly what was recorded. ### Verification: The Guarantee Once all steps are complete, in-toto verification checks the entire chain: 1. The layout signature is valid and from a trusted project owner 2. Every step defined in the layout has corresponding signed link metadata 3. Each link was signed by an authorized functionary for that step 4. The material/product relationships between steps are consistent – the products of one step match the materials of the next 5. All inspection rules pass If any check fails – a step was skipped, an unauthorized party performed a step, or files were modified between steps – verification fails and the artifact is rejected. This is what makes in-toto an _end-to-end_ verification system: it does not just check individual steps in isolation, but verifies the integrity of the entire pipeline. ## The in-toto Attestation Framework Beyond the original layout/link model, the in-toto project developed the **[in-toto attestation framework](https://github.com/in-toto/attestation)** – a more general-purpose format for making signed, verifiable claims about software artifacts. This framework has become the de facto standard for supply chain metadata across the industry. An in-toto attestation consists of: - **An envelope** – a signed wrapper (using [DSSE](https://github.com/secure-systems-lab/dsse), the Dead Simple Signing Envelope) that provides authentication - **A subject** – the artifact(s) the attestation refers to, identified by cryptographic digest - **A predicate** – a typed payload containing the actual claim The predicate type system is what makes the framework so versatile. Different predicate types include: - **[SLSA Provenance](/2024/08/17/what-is-slsa/)** – records how an artifact was built, including source, builder, and build parameters - **SBOM** – wraps a CycloneDX or SPDX [SBOM](/what-is-sbom/) in a signed attestation, providing provenance and integrity - **Vulnerability scan results** – attests to the findings of a security scan - **Code review** – records that a human reviewed the code before it was built This predicate-based architecture means the in-toto attestation format can carry _any_ type of supply chain metadata in a standardized, signable envelope. ## Why in-toto Matters ### Preventing Supply Chain Attacks The core value of in-toto is that it makes supply chain tampering detectable. Consider how common supply chain attacks work: - **A build system is compromised** and injects malicious code during compilation. in-toto verification detects that the products of the build step do not match the expected transformation of the source materials. - **An unauthorized actor pushes a release.** in-toto verification fails because the release step was not signed by an authorized functionary. - **A dependency is swapped** between the resolve and build steps. in-toto's material/product matching across steps detects the inconsistency. Without in-toto, these attacks can go undetected because each individual step _appears_ to have succeeded. in-toto's end-to-end verification catches tampering that step-level checks miss. ### The XZ Utils Lesson The [XZ Utils backdoor (CVE-2024-3094)](/2024/04/13/what-really-happened-to-xz/) is a textbook case for why in-toto matters. The attacker modified the build process to inject a backdoor that only appeared in the distributed tarballs, not in the git source. A supply chain secured with in-toto would have required the build step to be performed by an authorized functionary using the exact source materials from the repository, and verification would have caught the discrepancy between the source and the tarball. ## Real-World Adoption in-toto and its attestation format have been widely adopted across the software supply chain ecosystem. **CNCF Graduated Project** – in-toto [graduated from the CNCF](https://www.cncf.io/projects/in-toto/) in 2023, joining a small set of projects that have achieved this level of maturity and adoption. It is part of the CNCF's supply chain security ecosystem alongside [sigstore](/2024/08/12/what-is-sigstore/) and [The Update Framework (TUF)](https://theupdateframework.io/). **SLSA Framework** – [SLSA (Supply chain Levels for Software Artifacts)](/2024/08/17/what-is-slsa/) uses the in-toto attestation format for all its provenance attestations. When a SLSA-compliant build system generates provenance, it produces an in-toto attestation. **GitHub Artifact Attestations** – GitHub's [artifact attestation](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds) feature uses in-toto attestations signed via [sigstore](/2024/08/12/what-is-sigstore/) to establish provenance for artifacts built with GitHub Actions. Every time you see SLSA provenance on a GitHub release, it is an in-toto attestation under the hood. **Kubernetes** – The Kubernetes project generates SLSA Level 3 provenance for its releases using in-toto attestations, allowing users to verify that official Kubernetes binaries were built from the expected source by authorized infrastructure. **Datadog** – Datadog integrated in-toto into its CI/CD pipelines to provide end-to-end verification of its Agent software, ensuring that the binaries delivered to customers match the intended build process. ## in-toto and SBOMs in-toto and [SBOMs](/what-is-sbom/) are complementary. An SBOM tells you _what_ is in your software. in-toto tells you _how_ it got there and _who_ was responsible for each step. The intersection is practical: - **SBOMs as attestation predicates** – An in-toto attestation can wrap an SBOM as its predicate, producing a signed, verifiable SBOM. This proves not only what components are in the software, but also who generated the SBOM and from what source materials. - **Build provenance for SBOM accuracy** – in-toto provenance attestations record the exact build inputs and process, which is precisely the information needed to generate an accurate SBOM. Build-time SBOMs generated alongside in-toto link metadata can be trusted to reflect the actual build. - **Continuous verification** – When [monitoring SBOMs for vulnerabilities](/2026/02/01/sbom-scanning-vulnerability-detection/), in-toto attestations provide assurance that the SBOM was not tampered with after generation. For organizations managing SBOMs with a platform like [sbomify](https://sbomify.com), in-toto attestations add a layer of integrity: you can verify that the SBOM was generated by an authorized CI/CD pipeline from the correct source, not fabricated or modified after the fact. ## Getting Started with in-toto The in-toto project provides implementations in multiple languages: - **[in-toto-python](https://github.com/in-toto/in-toto)** – The reference implementation, installable via `pip install in-toto` - **[in-toto-golang](https://github.com/in-toto/in-toto-golang)** – Go implementation, used by many cloud-native tools - **[in-toto-java](https://github.com/in-toto/in-toto-java)** – Java implementation for JVM-based build systems - **[in-toto-rs](https://github.com/in-toto/in-toto-rs)** – Rust implementation For most organizations, the fastest path to adopting in-toto is through tools that already use it: 1. **Enable SLSA provenance** in your CI/CD system. GitHub Actions, Google Cloud Build, and other platforms support SLSA provenance generation, which produces in-toto attestations automatically. 2. **Verify attestations** on artifacts you consume. Tools like `cosign verify-attestation` ([sigstore](/2024/08/12/what-is-sigstore/)) and `gh attestation verify` (GitHub CLI) check in-toto attestations. 3. **Generate signed SBOMs** by wrapping your SBOM output in an in-toto attestation using your CI/CD signing infrastructure. For deeper control – such as defining custom layouts with specific functionary keys and step-level verification – the in-toto Python or Go libraries provide the full layout/link/verify workflow. The [in-toto documentation](https://in-toto.readthedocs.io/) includes step-by-step tutorials. ## in-toto in the Compliance Context in-toto aligns with emerging supply chain security requirements: - **[Executive Order 14028](/compliance/eo-14028/)** directs federal agencies to enhance software supply chain security, including provenance and integrity verification – core capabilities of in-toto. - **[NIST SSDF (SP 800-218)](https://csrc.nist.gov/publications/detail/sp/800-218/final)** recommends protecting all forms of code from unauthorized access and tampering. in-toto's cryptographic verification of build steps directly addresses this requirement. - **[SLSA requirements](/2024/08/17/what-is-slsa/)** – Organizations pursuing SLSA compliance are inherently using in-toto attestation formats for provenance. - **[EU CRA](/compliance/eu-cra/)** requires vulnerability handling and supply chain security processes. in-toto provides the verification mechanism to demonstrate that software was built through an authorized, untampered pipeline. ## Frequently Asked Questions ### What is in-toto? in-toto is an open-source framework for securing the software supply chain. It provides a system of layouts, signed link metadata, and end-to-end verification to ensure that every step in building and delivering software happened exactly as intended, with no unauthorized modifications. It is a CNCF graduated project. ### What is the in-toto attestation framework? The in-toto attestation framework defines a standard envelope format for supply chain metadata. It wraps a typed predicate (such as SLSA provenance, vulnerability scan results, or SBOM data) inside a signed envelope, providing a universal format for making and verifying claims about software artifacts. ### How is in-toto related to SLSA? [SLSA](/2024/08/17/what-is-slsa/) (Supply chain Levels for Software Artifacts) builds directly on in-toto. SLSA provenance attestations use the in-toto attestation format, and SLSA's verification model is an extension of in-toto's end-to-end verification concept. in-toto provides the technical foundation; SLSA provides a maturity framework on top of it. ### Is in-toto a CNCF project? Yes. in-toto joined the Cloud Native Computing Foundation (CNCF) as a sandbox project in 2019 and graduated in 2023. It is one of only a few supply chain security projects to reach CNCF graduated status, alongside [sigstore](/2024/08/12/what-is-sigstore/) and The Update Framework (TUF). ### How does in-toto relate to SBOMs? in-toto attestations can carry SBOM data as a predicate type, providing a signed, verifiable wrapper around [SBOM](/what-is-sbom/) content. This means you can not only generate an SBOM but also cryptographically prove who generated it, when, and from which source materials – adding integrity and provenance to your SBOM. --- # What Is Sigstore? Keyless Signing for the Software Supply Chain URL: https://sbomify.com/2024/08/12/what-is-sigstore/ Date: 2024-08-12 Description: What is Sigstore? The CNCF-graduated project makes cryptographic signing effortless with keyless signing via Fulcio, transparency logging via Rekor, and container signing via Cosign. Learn how Sigstore secures artifacts, SBOMs, and supply chains. Before [Sigstore](https://www.sigstore.dev/), signing a software artifact meant generating a GPG or PEM key pair, storing the private key securely, distributing the public key, rotating keys on a schedule, and revoking compromised keys. Most projects never bothered. The result: the vast majority of open-source software shipped unsigned, and consumers had no way to verify that a package came from who it claimed to come from. Sigstore changed this by removing the hardest part of the problem – key management – entirely. Using short-lived certificates, identity-based signing, and a public transparency log, Sigstore makes it possible to sign and verify software artifacts without managing a single long-lived key. Launched in 2021 as a collaboration between Google, Red Hat, Purdue University, and Chainguard, Sigstore [graduated from the CNCF](https://www.cncf.io/projects/sigstore/) in 2022 and now underpins signing infrastructure for npm, PyPI, Kubernetes, and GitHub artifact attestations. ## How Sigstore Works: Keyless Signing Sigstore's central innovation is **keyless signing** – a model where developers never see or manage cryptographic keys. Instead, signing is tied to an _identity_ (like a GitHub or Google account) through short-lived certificates. Here is the flow: 1. **Authenticate.** The developer proves their identity via OpenID Connect (OIDC), using an existing identity provider like GitHub, Google, or Microsoft. 2. **Get a certificate.** Sigstore's certificate authority, **Fulcio**, issues a short-lived X.509 certificate (valid for roughly 10 minutes) that binds the developer's verified identity to an ephemeral key pair. 3. **Sign the artifact.** The developer uses **Cosign** (or another signing client) to sign the artifact with the ephemeral private key. 4. **Log the event.** The signature, certificate, and artifact digest are recorded in **Rekor**, Sigstore's transparency log – a tamper-evident, append-only public ledger. 5. **Key expires.** The ephemeral private key is discarded. Because the signing event is permanently recorded in Rekor with a timestamp, anyone can later verify that the signature was valid at the time it was created, even though the certificate has long since expired. This is what makes keyless signing possible: the transparency log replaces long-lived keys as the source of trust. Instead of trusting that a key has not been compromised over months or years, verifiers trust that the signing event was recorded in Rekor at a specific time, with a valid certificate, for a verified identity. ## Core Components ### Cosign [Cosign](https://docs.sigstore.dev/cosign/signing/overview/) is the primary signing and verification tool. It supports: - **Container images** – signs OCI images and stores signatures in OCI registries alongside the image - **Blobs** – signs arbitrary files (binaries, archives, SBOMs) - **[in-toto attestations](/2024/08/14/what-is-in-toto/)** – signs and verifies in-toto attestations, including SLSA provenance Cosign integrates with CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins) and can verify signatures as part of admission control in Kubernetes clusters. ### Fulcio [Fulcio](https://docs.sigstore.dev/fulcio/overview/) is Sigstore's certificate authority. It issues short-lived certificates (typically 10 minutes) after verifying the requester's identity via OIDC. Because certificates are short-lived, there is no need for certificate revocation lists or OCSP – the certificate simply expires before it can be meaningfully abused. Fulcio supports identity providers including GitHub Actions (for workload identity in CI/CD), Google, Microsoft, and any OIDC-compliant provider. In CI/CD environments, the build system's workload identity is used automatically, requiring no human interaction. ### Rekor [Rekor](https://docs.sigstore.dev/rekor/overview/) is the transparency log – an immutable, append-only ledger that records every signing event. Each entry includes the artifact digest, the signature, and the signing certificate. Rekor provides: - **Tamper evidence** – any modification to the log is detectable through cryptographic proofs (Merkle tree inclusion proofs) - **Timestamping** – each entry has a trusted timestamp, proving when the signature was created - **Public auditability** – anyone can query Rekor to verify that a signature exists and when it was made Rekor is what enables keyless signing to work: because the signing event is permanently recorded with a timestamp, the short-lived certificate does not need to remain valid for verification to succeed. ### Gitsign [Gitsign](https://docs.sigstore.dev/gitsign/overview/) applies Sigstore's keyless signing to Git commits and tags. Instead of configuring GPG keys, developers authenticate via OIDC and sign commits with a short-lived certificate, with the signing event recorded in Rekor. ## Why Sigstore Matters ### The Key Management Problem Traditional code signing requires generating a key pair, protecting the private key (often in an HSM or vault), distributing the public key (via a keyserver or out-of-band), rotating keys periodically, and revoking them when compromised. Each of these steps is a potential point of failure, and the operational burden means most projects skip signing entirely. Sigstore eliminates every one of these steps. There are no long-lived keys to generate, store, rotate, or revoke. The developer's existing identity _is_ the credential, and the transparency log _is_ the distribution mechanism. ### Real-World Supply Chain Attacks The attacks that Sigstore helps prevent are not theoretical: - **[SolarWinds (2020)](https://en.wikipedia.org/wiki/2020_United_States_federal_government_data_breach)** – Attackers compromised the build system and injected malicious code into signed updates. If the build system had used identity-bound, transparency-logged signing, the anomalous signing identity would have been visible in the public log. - **[codecov (2021)](https://about.codecov.io/security-update/)** – A modified bash uploader script was distributed for months. Transparency-logged signatures would have made the unauthorized modification detectable. - **[XZ Utils (2024)](/2024/04/13/what-really-happened-to-xz/)** – A malicious contributor backdoored the build process. Sigstore's identity-based signing would tie every signed artifact to a specific verified identity, making it harder for a pseudonymous attacker to sign releases undetected. ### Adoption at Scale Sigstore's impact is measured by who uses it: - **npm** – All packages published to the npm registry include Sigstore-based provenance attestations, allowing users to verify that a package was built from a specific repository and commit. - **PyPI** – Python package attestations use Sigstore to sign and verify distributions uploaded from trusted CI/CD publishers. - **Maven Central** – The Sigstore Java client enables signing for JVM-based artifacts. - **Kubernetes** – All Kubernetes release artifacts are signed with Sigstore, providing verifiable provenance for the most widely deployed container orchestrator. - **GitHub artifact attestations** – GitHub's [attestation feature](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds) uses Sigstore for signing [in-toto attestations](/2024/08/14/what-is-in-toto/), including [SLSA](/2024/08/17/what-is-slsa/) provenance. - **Distroless images** – Google's Distroless container images are signed with Cosign, allowing Kubernetes admission controllers to enforce signature verification. ## Sigstore and SBOMs Sigstore provides the signing layer that gives [SBOMs](/what-is-sbom/) integrity and provenance. An unsigned SBOM is a claim – a signed SBOM is evidence. - **Signing SBOMs** – Cosign can sign SBOM files (CycloneDX, SPDX) or attach signed SBOMs to container images. This proves who generated the SBOM and when. - **SBOM attestations** – An SBOM can be wrapped in an [in-toto attestation](/2024/08/14/what-is-in-toto/) and signed via Sigstore, producing a verifiable, transparency-logged SBOM that consumers can independently validate. - **Verification in pipelines** – Organizations consuming SBOMs can use `cosign verify-attestation` to confirm that the SBOM was generated by a trusted CI/CD identity before [scanning it for vulnerabilities](/2026/02/01/sbom-scanning-vulnerability-detection/). For organizations using [sbomify](https://sbomify.com) for SBOM management, Sigstore-signed SBOMs provide assurance that the inventory data was generated by an authorized pipeline, not fabricated or modified after the fact. ## Getting Started with Sigstore ### Signing a Container Image ```bash # Install cosign go install github.com/sigstore/cosign/v2/cmd/cosign@latest # Sign an image (keyless – opens browser for OIDC auth) cosign sign my-registry.io/my-image:latest # Verify the image cosign verify my-registry.io/my-image:latest \ --certificate-identity=user@example.com \ --certificate-oidc-issuer=https://accounts.google.com ``` ### Signing in CI/CD (GitHub Actions) In GitHub Actions, Cosign uses the workflow's OIDC identity automatically – no browser interaction required: ```yaml - uses: sigstore/cosign-installer@v3 - run: cosign sign my-registry.io/my-image:${{ github.sha }} ``` ### Verifying Attestations ```bash # Verify a SLSA provenance attestation cosign verify-attestation my-registry.io/my-image:latest \ --type slsaprovenance \ --certificate-identity-regexp="https://github.com/my-org/*" \ --certificate-oidc-issuer=https://token.actions.githubusercontent.com ``` For more on attestation formats, see our guide on [in-toto](/2024/08/14/what-is-in-toto/). ## Sigstore in the Compliance Context Sigstore supports compliance with emerging software supply chain regulations: - **[Executive Order 14028](/compliance/eo-14028/)** requires software producers to attest to secure development practices and provide SBOMs. Sigstore provides the cryptographic signing infrastructure to make those attestations verifiable. - **[SLSA requirements](/2024/08/17/what-is-slsa/)** – Sigstore is the default signing mechanism for SLSA provenance at all build levels. Achieving SLSA compliance typically involves Sigstore. - **[EU CRA](/compliance/eu-cra/)** requires demonstrating supply chain security and vulnerability handling. Sigstore-signed artifacts and SBOMs provide auditable proof of integrity. - **[NIST SP 800-53](/compliance/nist-800-53/) SI-7** (Software, Firmware, and Information Integrity) requires integrity verification mechanisms. Sigstore's signing and verification model directly addresses this control. ## Frequently Asked Questions ### What is Sigstore? Sigstore is an open-source project that provides free, easy-to-use tools for cryptographically signing, verifying, and protecting software artifacts. Its keyless signing model eliminates the need for developers to manage long-lived cryptographic keys, making signing accessible to every project. Sigstore is a CNCF graduated project. ### What is keyless signing? Keyless signing is Sigstore's approach to cryptographic signing that replaces long-lived keys with short-lived certificates tied to an identity (like a GitHub or Google account) via OpenID Connect. The certificate lives only long enough to create the signature, then expires. A transparency log (Rekor) records the signing event, providing permanent proof that the signature was valid at the time it was created. ### What are the main components of Sigstore? Sigstore consists of three core services: [Cosign](https://docs.sigstore.dev/cosign/signing/overview/) (signs and verifies container images and other artifacts), [Fulcio](https://docs.sigstore.dev/fulcio/overview/) (a certificate authority that issues short-lived certificates based on OIDC identity), and [Rekor](https://docs.sigstore.dev/rekor/overview/) (a transparency log that records all signing events in a tamper-evident ledger). [Gitsign](https://docs.sigstore.dev/gitsign/overview/) extends this to Git commit signing. ### How is Sigstore related to SLSA and in-toto? Sigstore provides the signing infrastructure that [SLSA](/2024/08/17/what-is-slsa/) and [in-toto](/2024/08/14/what-is-in-toto/) rely on. SLSA provenance attestations (which use the in-toto attestation format) are typically signed using Sigstore's keyless signing. GitHub artifact attestations, for example, use in-toto format signed via Sigstore's Fulcio and recorded in Rekor. ### Who uses Sigstore? Sigstore is used by major package registries (npm, PyPI, Maven Central), container platforms (Kubernetes, Distroless), CI/CD systems (GitHub Actions, GitLab), and Linux distributions. GitHub's artifact attestation feature uses Sigstore under the hood. --- # How to Generate SBOMs for Python Packages with `pipdeptree` and `cyclonedx-py` URL: https://sbomify.com/2024/07/30/generate-sboms-for-python-packages-with-pipdeptree-and-cyclonedx-py/ Date: 2024-07-30 Description: Tutorial on generating CycloneDX SBOMs for Python projects using pipdeptree and cyclonedx-py, including transitive dependencies and best practices for pinning with hashes. Software Bill of Materials (SBOMs) are essential for ensuring transparency and security in software supply chains. This guide will show you how to use `pipdeptree` and `cyclonedx-py` to generate SBOMs for Python projects, including all transient dependencies. We'll also reference a comprehensive guide on generating SBOMs for Python packages using Docker and Django CMS. ## Why SBOMs Matter SBOMs provide a detailed inventory of all components in a software project, helping with: - **Security**: Identifying and fixing vulnerabilities. - **Compliance**: Meeting legal and regulatory standards. - **Maintenance**: Ensuring software stability. See our article [What is an SBOM](/what-is-sbom/) for more details. ## Step-by-Step Guide to Generating SBOMs ### Using `pipdeptree` for Dependency Analysis `pipdeptree` visualizes the dependency tree of installed Python packages, making it ideal for SBOM generation. #### Installation Install `pipdeptree` with pip: ```bash pip install pipdeptree ``` #### Generate the Dependency Tree Run this command to see the dependency tree and save it to a `requirements.txt` file: ```bash pipdeptree --freeze > requirements.txt ``` This output includes all installed packages and their dependencies, providing the necessary data for a comprehensive SBOM. ### Exploding the SBOM To fully capture all dependencies, including transient ones, it's essential to "explode" the SBOM. `pipdeptree` does this effectively by mapping out the entire dependency tree. ### Converting `pipdeptree` Output to CycloneDX Format Once you have the dependency tree from `pipdeptree`, you can convert it to a CycloneDX SBOM using the CycloneDX-Python tool. #### Installation Install CycloneDX-Python with pip: ```bash pip install cyclonedx-bom ``` #### Conversion Process First, generate the dependency tree and save it to a file using the previous `pipdeptree` command. Then, convert this `requirements.txt` file to a CycloneDX SBOM: ```bash $ cyclonedx-py \ --requirements requirements.txt \ --output sbom.json ``` This process ensures all dependencies, including transient ones, are captured in the SBOM. ### Best Practices for Managing Dependencies Pinning all dependencies, ideally with hashes, enhances security and compliance, aligning with standards like the OpenSSF Scorecards. #### Pinning Dependencies with Hashes Specify versions and hashes in your `requirements.txt`: ``` package==version --hash=sha256:hash ``` This ensures you're using verified dependency versions, reducing the risk of vulnerabilities. ### Wrapping up For a thorough walkthrough on generating SBOMs, check out our [comprehensive guide](/2024/05/27/comprehensive-guide-to-generating-and-understanding-sboms-with-docker-and-django-cms/). This resource covers generating SBOMs using Docker and Django CMS, with applicable insights for any Python project. Generating SBOMs for Python packages, including all dependencies, is vital for security and compliance. Tools like `pipdeptree` and CycloneDX-Python make this process straightforward. By following best practices such as pinning dependencies with hashes, you can further secure your project. --- # What Is Lock File Drift? A Hidden Risk in Dependency Management URL: https://sbomify.com/2024/07/30/what-is-lock-file-drift/ Date: 2024-07-30 Description: What is lock file drift? When your dependency manifest and lock file fall out of sync, builds become unreproducible and SBOMs become inaccurate. Learn how to detect, prevent, and fix lock file drift across npm, Python, Go, Rust, and more. A developer adds a new dependency to `package.json`, runs the application locally, confirms it works, and pushes the change. But they forget to run `npm install` to update `package-lock.json`. CI passes because it uses `npm install` (which silently regenerates the lock file) instead of `npm ci` (which would fail on the mismatch). The application deploys with a different set of dependency versions than anyone tested against. This is **lock file drift** – and it is one of the most common, least visible risks in modern dependency management. ## What Is a Lock File? Every modern package manager uses two files to manage dependencies: 1. **A manifest** – the file where developers declare what they need (`package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `Gemfile`, `composer.json`). Manifests typically specify version _ranges_ (e.g., `^1.2.0`), giving the package manager flexibility to resolve compatible versions. 2. **A lock file** – the file generated by the package manager that records the _exact_ versions resolved for every direct and transitive dependency (`package-lock.json`, `poetry.lock`, `Cargo.lock`, `go.sum`, `Gemfile.lock`, `composer.lock`, `pnpm-lock.yaml`). Lock files ensure that every environment installs identical versions. The manifest says _what you want_. The lock file says _what you got_. When these two diverge, you have lock file drift. ## How Drift Happens Lock file drift is usually accidental. The most common causes: **Manual manifest edits without reinstalling.** A developer adds or bumps a dependency version in the manifest but does not run the package manager to regenerate the lock file. The manifest now declares constraints that the lock file does not satisfy. **Merge conflicts resolved incorrectly.** Two branches modify dependencies independently. When merged, the manifest may reflect both changes, but the lock file – which is often large, machine-generated, and difficult to review – may be resolved incorrectly or left in an inconsistent state. **Automated tools that update one file but not the other.** CI scripts, Dockerfiles, or custom tooling may modify the manifest (e.g., bumping a version) without running the corresponding install command to propagate the change to the lock file. **Different package manager versions.** Different developers or CI environments running different versions of the same package manager can produce structurally different lock files from the same manifest, even when the resolved versions are identical. ## Why Lock File Drift Is Dangerous ### Non-Reproducible Builds The entire purpose of a lock file is build reproducibility. When drift occurs, the lock file no longer accurately describes what gets installed. Different environments may resolve different versions depending on when they run, what's available in the registry, and which resolution strategy the package manager uses. The result: "works on my machine" failures, intermittent test breakage, and production behavior that nobody tested. ### Silent Security Regressions Lock file drift can prevent security patches from being applied _or_ introduce vulnerable versions without anyone noticing. Consider a scenario where the manifest is updated to require `library >= 2.1.0` (which patches a [CVE](/2025/12/18/cve-vulnerability-explained/)), but the lock file still pins `library@2.0.3` (the vulnerable version). If CI uses a lenient install command, it may honor the lock file and install the vulnerable version. The developer believes the patch is applied; it is not. The reverse is also dangerous: the lock file may resolve to a newer version that introduces breaking changes or new vulnerabilities that the manifest's range technically allows but that no one has tested. ### Inaccurate SBOMs This is where lock file drift intersects directly with [software supply chain security](/2025/12/26/software-supply-chain-management/). When you generate an [SBOM](/what-is-sbom/) from your project, most SBOM generation tools read the lock file to determine the exact versions of your dependencies. If the lock file is drifted, the SBOM is wrong – it lists versions that do not match what is actually installed in the built artifact. An inaccurate SBOM undermines every downstream process that depends on it: [vulnerability scanning](/2026/02/01/sbom-scanning-vulnerability-detection/) misses real exposures or flags false positives, [KEV monitoring](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) operates on stale data, and compliance attestations become unreliable. For organizations using [sbomify](https://sbomify.com) or similar platforms to manage and monitor SBOMs, lock file drift is a data quality problem at the source. ## Detecting Drift by Ecosystem Each package manager has mechanisms to detect lock file drift. The key principle: **use strict install commands in CI that fail when the lock file doesn't match the manifest.** ### Node.js (npm / Yarn / pnpm) ```bash # npm: fails if package-lock.json is out of sync with package.json npm ci # Yarn: fails if yarn.lock needs updating yarn install --frozen-lockfile # pnpm: fails if pnpm-lock.yaml needs updating pnpm install --frozen-lockfile ``` `npm ci` is the single most important command for preventing Node.js lock file drift. Unlike `npm install`, it does not modify the lock file – it installs exactly what the lock file specifies, and fails if the lock file is inconsistent with the manifest. ### Python (pip / Poetry / Pipenv) ```bash # Poetry: fails if poetry.lock is out of date poetry check --lock # Pipenv: verify lock file integrity pipenv verify # pip with hashes: fails if installed packages don't match pinned hashes pip install --require-hashes -r requirements.txt ``` ### Rust (Cargo) ```bash # Check if Cargo.lock is up to date (in CI) cargo check --locked ``` The `--locked` flag tells Cargo to refuse to update the lock file. If `Cargo.toml` and `Cargo.lock` are out of sync, the command fails. ### Go ```bash # Tidy modules and check for changes go mod tidy git diff --exit-code go.sum ``` Go does not have a single "strict mode" flag, but running `go mod tidy` followed by checking whether `go.sum` changed is the standard CI pattern. ### Ruby (Bundler) ```bash # Fails if Gemfile.lock needs updating bundle install --frozen ``` ## Preventing Drift ### CI Pipeline Checks The most effective prevention is a CI step that runs the strict install command and fails the build on drift. This should be the _first_ step in your pipeline – before tests, before linting, before anything that depends on installed packages. ```yaml # Example: GitHub Actions step for Node.js - name: Check for lock file drift run: npm ci ``` ### Pre-Commit Hooks Add a pre-commit hook that regenerates the lock file and checks for changes: ```bash #!/bin/sh # Regenerate lock file and fail if it changed npm install --package-lock-only git diff --exit-code package-lock.json || { echo "Lock file drift detected. Run 'npm install' and commit the updated lock file." exit 1 } ``` ### Automated Dependency Updates Tools like [Dependabot](https://docs.github.com/en/code-security/dependabot) and [Renovate](https://docs.renovatebot.com/) update both the manifest and lock file together in a single pull request, eliminating the most common source of drift. ### Pull Request Review Discipline Require that any PR modifying a dependency manifest also includes the corresponding lock file update. Code review tools can flag PRs that change `package.json` without changing `package-lock.json`. ## Lock File Drift and SBOM Accuracy For organizations subject to [software supply chain regulations](/compliance/eo-14028/) or generating SBOMs for compliance with the [EU Cyber Resilience Act](/compliance/eu-cra/), lock file drift is not just a developer inconvenience – it is a compliance risk. An SBOM generated from a drifted lock file is effectively a false attestation: it claims the software contains specific component versions when it may actually contain different ones. This matters for: - **[Vulnerability monitoring](/2026/02/01/sbom-scanning-vulnerability-detection/)** – Scanners checking your SBOM against [CVE](/2025/12/18/cve-vulnerability-explained/) and [KEV](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) databases will produce incorrect results if the SBOM doesn't match the deployed artifact. - **Audit trails** – Compliance frameworks expect SBOMs to accurately represent what is shipped. A drifted SBOM fails this requirement. - **Incident response** – When a new vulnerability is disclosed, you need to know _exactly_ what versions are in your software. A drifted lock file makes this impossible. The fix is straightforward: ensure that CI enforces lock file consistency _before_ the SBOM generation step. If the lock file is accurate, the SBOM will be accurate. ## Frequently Asked Questions ### What is lock file drift? Lock file drift is the condition where a project's dependency lock file (such as `package-lock.json`, `poetry.lock`, or `Cargo.lock`) is out of sync with its primary dependency manifest (such as `package.json`, `pyproject.toml`, or `Cargo.toml`). This means the versions recorded in the lock file do not match the constraints in the manifest, leading to unreproducible builds and potential security issues. ### Why does lock file drift matter for security? Lock file drift can silently downgrade dependencies to versions with known vulnerabilities, or allow untested versions to enter production. It also makes [SBOMs](/what-is-sbom/) inaccurate – if your SBOM is generated from a drifted lock file, it does not reflect what is actually installed in your application, undermining vulnerability monitoring and compliance. ### How do I detect lock file drift? Most package managers offer strict install commands that fail when drift is detected: `npm ci` for Node.js, `poetry check --lock` for Python, `cargo check --locked` for Rust, and `go mod tidy` followed by checking for changes in Go. Run these in CI to catch drift automatically. ### How do I prevent lock file drift? Use strict install commands in CI (`npm ci` instead of `npm install`), add pre-commit hooks that regenerate the lock file and fail if it changes, require lock file updates in pull request review checklists, and use automated dependency update tools like Dependabot or Renovate that update both files together. --- # Embracing Cybersecurity with CISA's 'Secure by Design' Initiative URL: https://sbomify.com/2024/07/24/embracing-cybersecurity-with-cisas-secure-by-design-initiative/ Date: 2024-07-24 Description: Overview of CISA's Secure by Design guide, its three core principles for software manufacturers, and practical steps for implementing security from the start. In the ever-evolving landscape of cyber threats, the importance of integrating robust security measures into the earliest stages of software development cannot be overstated. Recognizing this need, the Cybersecurity and Infrastructure Security Agency (CISA), alongside various international partners, has released an updated guide titled "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software" ([CISA](https://www.cisa.gov/resources-tools/resources/secure-by-design)). This comprehensive document emphasizes the urgency for software manufacturers to prioritize security from the outset, fundamentally shifting the cybersecurity burden away from consumers and towards developers. #### Key Principles of Secure by Design The guide outlines three core principles that software manufacturers are encouraged to adopt: 1. **Take Ownership of Customer Security Outcomes**: Manufacturers are urged to take full responsibility for the security of their products, ensuring that security features are enabled by default and that customers are protected without needing to take additional steps ([CISA](https://www.cisa.gov/news-events/news/cisa-us-and-international-partners-announce-updated-secure-design-principles-joint-guide)). 2. **Embrace Radical Transparency and Accountability**: This principle advocates for openness about vulnerabilities and security practices. By ensuring complete and accurate vulnerability advisories, manufacturers can build trust and enhance their products' security ([CISA](https://www.cisa.gov/news-events/news/us-and-international-partners-publish-secure-design-and-default-principles-and-approaches)). 3. **Lead from the Top**: Executive leadership must prioritize security as a critical element of product development. This cultural shift within organizations is crucial for embedding security into every stage of the software lifecycle ([CISA](https://www.cisa.gov/news-events/news/next-chapter-secure-design)). #### International Collaboration The updated guidance has garnered support from cybersecurity authorities worldwide, including agencies from Australia, Canada, Germany, the UK, and several other nations. This international coalition underscores the global consensus on the necessity of secure by design principles ([CISA](https://www.cisa.gov/news-events/news/us-and-international-partners-publish-secure-design-and-default-principles-and-approaches)). CISA Director Jen Easterly highlighted the collaborative effort, stating, "Ensuring that software manufacturers integrate security into the earliest phases of design for their products is critical to building a secure and resilient technology ecosystem" ([CISA](https://www.cisa.gov/news-events/news/cisa-us-and-international-partners-announce-updated-secure-design-principles-joint-guide)). #### Practical Steps for Implementation To assist manufacturers in adopting these principles, the guide provides practical steps and examples of artifacts that can demonstrate a commitment to secure by design. These artifacts, ranging from secure coding practices to comprehensive vulnerability management processes, serve as evidence of a manufacturer's dedication to security ([CISA](https://www.cisa.gov/news-events/news/next-chapter-secure-design)). Moreover, the guide encourages manufacturers to engage in continuous learning and adaptation. This includes participating in secure by design summits, collaborating with educational institutions, and adhering to secure coding practices advocated by the broader cybersecurity community ([CISA](https://www.cisa.gov/news-events/news/next-chapter-secure-design)). #### The Road Ahead CISA's updated guidance is more than a set of recommendations; it is a call to action for the entire software industry. By adopting secure by design principles, manufacturers can significantly reduce the prevalence of vulnerabilities and enhance the overall security of technology products used globally. As the digital landscape continues to expand, the need for secure software becomes ever more critical. CISA's initiative represents a significant step towards a more secure digital future, where security is an integral part of the development process, rather than an afterthought ([CISA](https://www.cisa.gov/resources-tools/resources/secure-by-design)) ([CISA](https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf#:~:text=URL%3A%20https%3A%2F%2Fwww.cisa.gov%2Fsites%2Fdefault%2Ffiles%2F2023)). For more detailed information and to access the full guide, visit the [CISA Secure by Design page](https://www.cisa.gov/resources-tools/resources/secure-by-design). --- # What's New in SPDX 3: Enhanced Referencing Capabilities URL: https://sbomify.com/2024/07/22/whats-new-in-spdx-3-enhanced-referencing-capabilities/ Date: 2024-07-22 Description: SPDX 3 draft introduces nested references, cross-document references, and improved relationship types to match CycloneDX capabilities for complex SBOM management. At sbomify, we pride ourselves on providing the latest insights and updates in the realm of Software Bill of Materials (SBOM). One of the most anticipated developments is the draft release of SPDX 3, which brings a host of new features and improvements. Notably, SPDX 3 now includes enhanced referencing capabilities, a critical feature that has long been available in CycloneDX. Let’s delve into what this means for SBOM practitioners and how it positions SPDX 3 as a robust standard for software component documentation. #### Enhanced Referencing Capabilities One of the standout features in SPDX 3 is its improved referencing capabilities. This feature, already supported in CycloneDX, allows for more efficient and accurate representation of complex software dependencies and relationships. The inclusion of this capability in SPDX 3 signifies a major leap forward for the standard, aligning it more closely with industry needs. **Key Aspects of Enhanced Referencing:** - **Nested References:** SPDX 3 supports nested references, enabling users to document multi-level dependencies with precision. This is particularly useful for large software projects where components are often built on top of multiple layers of dependencies. - **Cross-Document References:** Users can now reference elements across different SPDX documents, facilitating better modularization and management of SBOMs. This is essential for organizations that need to maintain separate SBOMs for different projects or components but want to maintain a cohesive overview. - **Improved Relationship Types:** The new version introduces more granular relationship types, such as “includes,” “requires,” and “optional,” providing a clearer picture of how components interact within the software ecosystem. #### The Importance of Referencing Accurate referencing is crucial for several reasons: 1. **Dependency Management:** With software becoming increasingly complex, managing dependencies accurately is critical. Enhanced referencing allows for a more detailed and accurate representation of dependencies, reducing the risk of missing or incorrectly documenting a component. 2. **Mitigating Flattening of SBOMs:** Referencing mitigates the need to "flatten" multiple SBOMs into a single large SBOM. Flattening can lead to a loss of crucial structural information and make it harder to track where a specific library or component is used. By allowing references to multiple SBOMs, SPDX 3 helps maintain the integrity and structure of each SBOM, making it easier to understand the usage and dependencies of specific libraries and components. 3. **Security and Compliance:** Knowing the exact relationships between components helps in assessing the impact of vulnerabilities and ensuring compliance with licensing terms. Enhanced referencing makes it easier to trace and manage these aspects. 4. **Automation and Efficiency:** Improved referencing capabilities streamline the automation of SBOM generation and validation processes. This leads to more efficient workflows and reduces the likelihood of human error. #### Comparing SPDX 3 and CycloneDX For those familiar with CycloneDX, the inclusion of enhanced referencing in SPDX 3 brings the two standards closer in terms of functionality. CycloneDX has been a popular choice for its detailed referencing capabilities, and with SPDX 3 catching up, users can now choose the standard that best fits their needs without compromising on this critical feature. **CycloneDX vs. SPDX 3: Key Points** - **Existing Strengths of CycloneDX:** CycloneDX has been favored for its strong support for detailed and nested references, making it a go-to for many organizations. - **SPDX 3 Advancements:** With the introduction of similar capabilities in SPDX 3, users now have the flexibility to choose SPDX while still benefiting from comprehensive referencing features. #### Still in Draft: What It Means It’s important to note that SPDX 3 is still in draft form. This means the specification is open for feedback and further refinement before its final release. The draft status provides an opportunity for the community to contribute insights and suggest improvements, ensuring that the final version meets the diverse needs of the industry. **Implications of the Draft Status:** - **Community Involvement:** Stakeholders can participate in the review process, providing feedback to shape the final version of SPDX 3. - **Ongoing Refinement:** The draft status indicates that while the core features are in place, there may be adjustments and enhancements based on community input. ### Conclusion The draft release of SPDX 3, with its enhanced referencing capabilities, marks a significant advancement for SBOM standards. At SBOMify.com, we are excited about these developments and the potential they hold for improving software transparency and security. By aligning more closely with the features offered by CycloneDX, SPDX 3 provides a robust and flexible option for documenting software components and their relationships. We encourage you to explore the draft version of SPDX 3, provide feedback, and prepare for the transition to this enhanced standard. Stay tuned to sbomify for the latest updates and in-depth analyses as SPDX 3 moves towards its final release. For more detailed information and to participate in the feedback process, visit the [SPDX 3 draft specification](https://spdx.org/spdx-specification-draft). --- # Understanding the EU Cyber Resilience Act: SBOM Requirements and Compliance URL: https://sbomify.com/2024/07/10/understanding-the-eu-cyber-resilience-act-the-role-of-sboms-in-enhancing-cybersecurity/ Date: 2024-07-10 Description: What does the EU Cyber Resilience Act require? The CRA mandates SBOMs, vulnerability handling, and security updates for all products with digital elements sold in the EU. Learn the timeline, product categories, and how to prepare. In October 2024, the European Union adopted the **Cyber Resilience Act (CRA)** – the most ambitious cybersecurity product regulation ever enacted. For the first time, a major market is requiring that _all_ products with digital elements meet mandatory cybersecurity requirements, including the maintenance of Software Bills of Materials, vulnerability handling processes, and long-term security update commitments. The CRA affects every company that places software or connected hardware on the EU market, from consumer IoT device makers to enterprise software vendors. For organizations already invested in [SBOM practices](/what-is-sbom/), the CRA validates what they have been building. For those that have not started, the compliance clock is now ticking. For a practitioner perspective on CRA compliance, see our [interview with EU CRA expert Sarah Fluchs](/2026/01/06/cra-explained-cyber-resilience-act-for-device-manufacturers/). ## Timeline The CRA's obligations phase in over a three-year transition period: | Date | Milestone | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | **October 2024** | CRA adopted by European Parliament and Council | | **December 2024** | CRA entered into force (published in Official Journal) | | **September 2026** | Vulnerability reporting obligations apply – manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours | | **September 2027** | Full essential requirements apply, including SBOM obligations, security by design, conformity assessment, and security update commitments | Organizations should not wait until 2027. Building SBOM infrastructure, establishing vulnerability handling processes, and ensuring products meet security-by-design requirements takes time. Starting now provides a buffer for the organizational and technical changes required. ## What the CRA Covers ### Scope: Products with Digital Elements The CRA applies to **all products with digital elements** placed on the EU market. This includes: - **Software** – standalone applications, operating systems, firmware, mobile apps - **Connected hardware** – IoT devices, routers, smart home devices, industrial controllers - **Components** – software libraries and hardware components intended for integration into other products The CRA uses three product categories based on risk: **Default category** – The majority of products. Manufacturers can self-assess compliance (no third-party audit required). Examples: photo editing software, smart speakers, hard drives. **Important products (Class I)** – Products with a higher cybersecurity risk. Compliance requires either a harmonized standard or third-party assessment. Examples: password managers, VPNs, routers, operating systems. **Important products (Class II)** – Higher-risk products requiring mandatory third-party conformity assessment. Examples: hypervisors, firewalls, tamper-resistant microcontrollers, industrial IoT gateways. **Critical products** – The highest risk category. Requires European cybersecurity certification. Examples: hardware security modules, smart meter gateways, smartcard devices. ### Exemptions The CRA does _not_ apply to: - Products already covered by sector-specific EU regulations (medical devices, automotive, aviation) - Non-commercial open-source software developed outside a commercial context - Cloud services and SaaS (covered by NIS2 instead) ## Essential Cybersecurity Requirements The CRA mandates a set of essential requirements that products must meet. The most consequential for software producers: ### Security by Design Products must be designed and developed with security in mind from the outset: - No known exploitable vulnerabilities at time of release - Secure default configuration (no default passwords, minimum necessary privileges) - Protection of data confidentiality and integrity - Availability and resilience, including protection against denial of service ### SBOM Requirements The CRA explicitly requires manufacturers to **identify and document components and dependencies**, including by drawing up a Software Bill of Materials. Key aspects: - The SBOM must cover at minimum the top-level dependencies of the product - Machine-readable format is recommended (e.g., [CycloneDX or SPDX](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/)) - The SBOM must be maintained and updated throughout the product's support period - The SBOM is part of the technical documentation that must be available to market surveillance authorities For organizations already generating SBOMs in CI/CD pipelines and managing them through platforms like [sbomify](https://sbomify.com), CRA SBOM compliance is largely a matter of formalizing existing practices. For those starting from scratch, see our [guide to demystifying SBOMs](/2024/04/03/demystifying-sboms-the-backbone-of-modern-software-security/) and [SBOM generation guides](/guides/). ### Vulnerability Handling Manufacturers must establish and maintain vulnerability handling processes throughout the product's support period: - **Coordinated vulnerability disclosure (CVD)** – A documented process for receiving and handling vulnerability reports from external researchers - **Security updates** – Free security patches delivered without undue delay for the entire support period (minimum five years from market placement) - **Vulnerability monitoring** – Active monitoring for vulnerabilities in product components, including third-party and open-source dependencies This is where SBOMs and [vulnerability scanning](/2026/02/01/sbom-scanning-vulnerability-detection/) become essential. Monitoring for newly disclosed [CVEs](/2025/12/18/cve-vulnerability-explained/) – especially those in the [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) – requires knowing exactly what components are in your product. An SBOM provides that inventory; vulnerability scanning tools provide the monitoring. ### Vulnerability Reporting Starting September 2026, manufacturers must report: - **Actively exploited vulnerabilities** – to ENISA (the EU Agency for Cybersecurity) within **24 hours** of becoming aware, with a full report within 72 hours - **Severe incidents** – to ENISA and affected users without undue delay This reporting obligation applies even to vulnerabilities in third-party components used in the product. Maintaining current SBOMs is the practical prerequisite for meeting this requirement – you cannot report a vulnerability in a component you do not know you use. ## Open Source and the CRA The CRA's treatment of open source has been one of the most debated aspects of the legislation. **Non-commercial open source is exempt.** Open-source software developed and distributed without commercial intent falls outside the CRA's scope. Individual developers contributing to open-source projects on a voluntary basis are not manufacturers under the CRA. **Open-source software stewards** – organizations like the Apache Software Foundation, the Eclipse Foundation, or the Linux Foundation that systematically support open-source products used in commercial contexts – have lighter obligations. They must establish a cybersecurity policy, cooperate with market surveillance authorities, and document vulnerabilities, but they do not bear the full conformity assessment obligations of manufacturers. **Manufacturers remain responsible** for the open-source components they integrate into their commercial products. If a manufacturer ships a product containing an open-source library with a known vulnerability, the manufacturer – not the open-source project – bears the CRA compliance obligation. ## Implementing CRA Compliance ### Step 1: Inventory Your Products Identify all products with digital elements that you place on the EU market. Classify each into the appropriate risk category (default, important, critical). ### Step 2: Establish SBOM Practices Generate SBOMs for all covered products. Integrate SBOM generation into your CI/CD pipeline using tools like the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/), Syft, or ~~Trivy~~ ([compromised March 2026](/2026/03/26/trivy-compromise-hardening-sbomify-action/)) so SBOMs are produced at every build and kept current. Use [sbomify](https://sbomify.com) to manage, monitor, and share SBOMs across your product portfolio. ### Step 3: Build Vulnerability Handling Processes Establish a coordinated vulnerability disclosure process. Set up [continuous vulnerability monitoring](/2026/02/01/sbom-scanning-vulnerability-detection/) against your SBOMs. Prepare the internal workflow for the 24-hour reporting obligation starting September 2026. ### Step 4: Ensure Security by Design Review products against the CRA's essential requirements. Address default passwords, unnecessary network exposure, and other common security anti-patterns. Document your secure development lifecycle. ### Step 5: Prepare Technical Documentation The CRA requires technical documentation including risk assessments, SBOM, design and development documentation, conformity assessment records, and EU declaration of conformity. Begin compiling this documentation now. ## CRA and Other Frameworks The CRA intersects with several existing compliance frameworks: - **[Executive Order 14028](/compliance/eo-14028/)** – U.S. federal SBOM requirements are complementary; organizations meeting EO 14028 requirements are well-positioned for CRA compliance - **[CISA minimum elements](/compliance/cisa-minimum-elements/)** – The CISA SBOM minimum elements align with CRA SBOM expectations - **NIS2 Directive** – Covers operators of essential and important services (overlaps with CRA for some product categories) - **[SLSA](/2024/08/17/what-is-slsa/)** and [in-toto](/2024/08/14/what-is-in-toto/) – Build provenance and supply chain integrity frameworks that support CRA's security-by-design requirements - **CE marking** – Products meeting CRA requirements will carry the CE marking for cybersecurity ## Frequently Asked Questions ### What is the EU Cyber Resilience Act? The EU Cyber Resilience Act (CRA) is EU legislation that establishes mandatory cybersecurity requirements for all products with digital elements placed on the EU market. Adopted in October 2024, it requires manufacturers to implement security by design, maintain [SBOMs](/what-is-sbom/), handle vulnerabilities throughout the product lifecycle, and provide security updates for at least five years. ### When does the CRA take effect? The CRA entered into force in December 2024. Vulnerability reporting obligations apply from September 2026. The full set of essential requirements, including SBOM obligations, becomes enforceable in September 2027. Manufacturers selling products in the EU should be preparing now. ### Does the CRA require SBOMs? Yes. The CRA requires manufacturers to identify and document the components and dependencies of their products, including by drawing up a Software Bill of Materials. The SBOM must cover at minimum the top-level dependencies. Machine-readable formats ([CycloneDX, SPDX](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/)) are recommended. ### Does the CRA apply to open source software? Non-commercial open-source development is exempt. However, open-source software stewards have lighter obligations, including establishing a cybersecurity policy and cooperating with market surveillance authorities. Open-source software integrated into commercial products is covered through the manufacturer's obligations. ### What are the penalties for non-compliance? The CRA provides for fines of up to 15 million euros or 2.5% of worldwide annual turnover (whichever is higher) for non-compliance with essential cybersecurity requirements. Non-compliance with other obligations can result in fines of up to 10 million euros or 2% of turnover. --- # The Role of SBOMs in an OBOM: Ensuring Compliance and Security in Smart Thermometer Development URL: https://sbomify.com/2024/07/09/the-role-of-sboms-in-an-obom-ensuring-compliance-and-security-in-smart-thermometer-development/ Date: 2024-07-09 Description: How to integrate SBOMs into Operations Bill of Materials (OBOM) for IoT devices, using a smart thermometer example with Python backend, Docker, and Rust firmware. In today's software landscape, compliance with security and transparency mandates is more critical than ever. Executive orders, such as the one issued by the U.S. government in May 2021, emphasize the importance of Software Bill of Materials (SBOMs) for ensuring software security and integrity. While SBOMs provide detailed inventories of software components, integrating them into an Operations Bill of Materials (OBOM) offers an enhanced framework that encompasses both software and runtime operational dependencies. This article explores the central role of SBOMs in OBOMs, using the development of a smart thermometer as an example, and discusses how this integration ensures compliance and bolsters security. ## Understanding SBOMs ### What is an SBOM? A Software Bill of Materials (SBOM) is a formal record that lists all components, libraries, and modules included in a software product. It provides a transparent view of the software’s codebase, aiding in dependency tracking, license management, and vulnerability identification. According to recent executive orders, SBOMs are essential for maintaining software security and transparency. ## Example: Smart Thermometer Development ### Components of the Smart Thermometer 1. **Python Backend**: The backend server written in Python, which handles data processing and user interactions. 2. **Docker Files**: Containerization files used to ensure consistent deployment environments. 3. **Device Software**: Firmware written in Rust, running on the thermometer device, which includes dependencies specific to the embedded system. ## Central Role of SBOMs in OBOMs ### Aggregated SBOM for Compliance In the context of a smart thermometer, an aggregated SBOM provides a comprehensive inventory of all software components involved: - **Backend SBOM**: Listing Python libraries and dependencies. - **Container SBOM**: Including Docker configurations and base images. - **Device SBOM**: Documenting Rust dependencies and embedded libraries. ### Integrating SBOMs into OBOMs An OBOM incorporates these SBOMs and extends them by adding runtime operational information: - **Runtime Dependencies**: Specific libraries and services required for the backend and device software to function during runtime. - **Configuration Settings**: Environment variables, configuration files, and system settings necessary for deployment and operation. - **Infrastructure Components**: Details about cloud servers, network configurations, and other infrastructure elements. - **Operational Tools**: Monitoring, logging, and backup tools essential for maintaining the operational integrity of the system. ### Benefits of SBOM Integration #### Enhanced Security and Compliance **Example: Comprehensive Vulnerability Management** Integrating SBOMs within an OBOM allows for detailed tracking of both software and operational components, ensuring compliance with security standards outlined in executive orders. For the smart thermometer, this means that any vulnerabilities identified in the Python libraries, Docker images, or Rust dependencies can be promptly addressed, ensuring the overall security of the product. #### Operational Transparency **Example: Detailed Auditing and Compliance** An aggregated SBOM within an OBOM provides a transparent view of all software and runtime components used in the smart thermometer, facilitating easier audits and ensuring compliance with regulatory standards. This transparency is crucial for meeting the requirements set by executive orders, which mandate visibility into software supply chains. ## OBOM as a Value-Added Extension ### Runtime Information While the SBOM is central to compliance, incorporating it into an OBOM adds valuable runtime information: - **Runtime Dependencies**: Ensuring that all necessary libraries and services are available and correctly configured during the operation of the smart thermometer. - **Configuration Management**: Detailed documentation of environment variables, configuration files, and system settings for consistent deployments across different environments. ### Enhancing Security and Efficiency with OBOM #### Streamlined Deployment By integrating SBOMs into an OBOM, the smart thermometer’s development team can ensure consistent deployment processes. This minimizes the risk of deployment failures and enhances operational efficiency. #### Disaster Recovery Incorporating SBOMs into an OBOM aids in disaster recovery by providing detailed information about the operational setup. This ensures that in case of a system failure, the exact configurations and dependencies can be quickly restored. #### Improved Collaboration An OBOM that includes SBOMs fosters better collaboration between development and operations teams, ensuring that deployment and maintenance processes are well-aligned. ## End-to-End Example: Smart Thermometer OBOM To illustrate a valid end-to-end example that complies with the CycloneDX standard, here is a simplified version of an OBOM for a smart thermometer: ### Example JSON Structure ```json { "bomFormat": "CycloneDX", "specVersion": "1.3", "version": 1, "components": [ { "type": "application", "name": "Smart Thermometer Backend", "version": "2.0.0", "bom-ref": "backend-1", "components": [ { "type": "library", "name": "Flask", "version": "1.1.2", "bom-ref": "flask-1", "licenses": [ { "license": { "id": "BSD-3-Clause" } } ] }, { "type": "library", "name": "Requests", "version": "2.23.0", "bom-ref": "requests-1", "licenses": [ { "license": { "id": "Apache-2.0" } } ] } ] }, { "type": "container", "name": "Smart Thermometer Container", "version": "1.0.0", "bom-ref": "container-1", "components": [ { "type": "operating-system", "name": "Ubuntu", "version": "20.04", "bom-ref": "ubuntu-1" }, { "type": "library", "name": "Docker", "version": "19.03", "bom-ref": "docker-1" } ] }, { "type": "firmware", "name": "Smart Thermometer Device Firmware", "version": "3.2.1", "bom-ref": "firmware-1", "components": [ { "type": "library", "name": "Rust Standard Library", "version": "1.49.0", "bom-ref": "rust-stdlib-1" }, { "type": "library", "name": "Embedded HAL", "version": "0.2.4", "bom-ref": "embedded-hal-1" } ] } ], "dependencies": [ { "ref": "backend-1", "dependsOn": [ "flask-1", "requests-1" ] }, { "ref": "container-1", "dependsOn": [ "ubuntu-1", "docker-1" ] }, { "ref": "firmware-1", "dependsOn": [ "rust-stdlib-1", "embedded-hal-1" ] } ], "metadata": { "timestamp": "2023-07-09T14:28:00Z", "tools": [ { "vendor": "CycloneDX", "name": "CycloneDX Maven Plugin", "version": "1.4.0" } ], "component": { "type": "application", "name": "Smart Thermometer", "version": "3.0.0", "bom-ref": "smart-thermometer-1" } } } ``` ### Explanation - **Components**: This section lists all components of the smart thermometer, including backend libraries, Docker container elements, and device firmware libraries. - **Dependencies**: Specifies the relationships between components, indicating which components depend on others. - **Metadata**: Contains additional information about the BOM, such as the timestamp, tools used to generate the BOM, and details about the top-level component (the smart thermometer). ## Conclusion While the inclusion of Software Bills of Materials (SBOMs) is mandated by executive orders for ensuring software security and transparency, integrating SBOMs into an Operations Bill of Materials (OBOM) provides additional operational benefits. For the development of a smart thermometer, this integration enhances security, compliance, and operational efficiency. By adopting SBOMs as a foundational element and viewing OBOM as a value-added extension, organizations can build a more secure, transparent, and resilient software ecosystem. --- **References:** 1. Executive Order on Improving the Nation's Cybersecurity. (2021). The White House. Retrieved from [White House](https://www.whitehouse.gov/briefing-room/statements-releases/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) 2. CycloneDX. (n.d.). _CycloneDX Specification_. Retrieved from [CycloneDX](https://cyclonedx.org/specification/overview/) 3. National Institute of Standards and Technology (NIST). (2021). _Security and Privacy Controls for Information Systems and Organizations_. Retrieved from [NIST](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) By focusing on the critical role of SBOMs within OBOMs, organizations can ensure compliance with executive mandates while leveraging the additional benefits of a comprehensive operational framework. --- # Enhancing Dependency Management with GitHub's Dependency Graph: An Analysis URL: https://sbomify.com/2024/06/24/enhancing-dependency-management-with-githubs-dependency-graph-an-analysis/ Date: 2024-06-24 Description: Research analysis revealing inaccuracies in GitHub's dependency graph for Java and Python projects, with implications for Dependabot and SBOM generators. **Introduction** In the evolving landscape of software development, dependency management is a critical component. GitHub’s dependency graph is a feature designed to provide insights into the dependencies and dependents of software projects. Leveraged by tools like Dependabot and SBOM (Software Bill of Materials) generators, this feature holds significant promise for improving software maintenance and security. However, a recent study by Daniele Bifolco and colleagues reveals some notable inaccuracies in GitHub’s dependency graph, raising concerns about its reliability for both researchers and practitioners. **The Study** [The study](https://dl.acm.org/doi/pdf/10.1145/3661167.3661175), conducted by researchers from the University of Sannio and the University of Salerno, aimed to assess the accuracy of GitHub’s dependency graph in Java and Python open-source projects. They randomly sampled 297 Java and 338 Python projects hosted on GitHub, analyzing their dependency graphs through three distinct methodologies: backward analysis, forward analysis, and manifest/lock file analysis. 1. **Backward Analysis**: This involved checking if the dependencies listed in a target repository’s dependency graph were reciprocally listed as dependents in the source repository’s dependency graph. 2. **Forward Analysis**: This focused on verifying if the dependents listed in a target repository’s dependency graph were accurately listed as dependencies in the source repository. 3. **Manifest/Lock File Analysis**: This assessed the consistency between dependencies listed in the dependency graph and those specified in the project’s manifest or lock files. **Findings** The results highlighted several inaccuracies in GitHub’s dependency graph: - **Backward Analysis**: 75.17% of dependencies for Java projects and 84.48% for Python projects were correctly detected. The main issues included missing occurrences, incorrect package links, non-existent source repositories, and missing links to source repositories. - **Forward Analysis**: 96.62% of dependents for Java projects and 70.94% for Python projects were correctly identified. Issues here mirrored those in the backward analysis, with a significant proportion of missing occurrences. - **Manifest/Lock File Analysis**: For Java projects, only 77.19% of dependencies matched those in the manifest/lock files, while Python projects had a higher match rate of 95.71%. Discrepancies were often due to inconsistencies in version tags and missing dependencies in the dependency graph. **Implications** The inaccuracies found in GitHub’s dependency graph have several implications: - **For Researchers**: Studies relying on GitHub’s dependency graph should validate the data independently to avoid skewed results. Researchers may need to develop more accurate dependency analyzers to complement GitHub’s data. - **For Practitioners**: Tools like Dependabot and SBOM generators, which rely on GitHub’s dependency graph, may provide incomplete or inaccurate information, leading to potential security vulnerabilities or licensing issues. Developers should be aware of these limitations and consider supplementary tools or manual checks. - **For GitHub Developers**: The insights from this study can guide improvements in the accuracy and reliability of the dependency graph feature. Enhancing this tool can significantly benefit the broader software development community. **Conclusion** While GitHub’s dependency graph is a valuable tool, this study underscores the need for caution and supplementary validation when using it for critical tasks. By addressing the highlighted inaccuracies, GitHub can enhance its utility, making dependency management more reliable and secure for developers worldwide. **Future Work** The researchers plan to extend their study to other programming languages and investigate the impact of dependency graph inaccuracies on past studies. Continuous monitoring and analysis will be essential to track improvements in GitHub’s dependency graph accuracy over time. By recognizing and addressing these challenges, we can improve dependency management practices, ensuring more robust and secure software development processes. --- # Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) URL: https://sbomify.com/2024/06/11/framing-software-component-transparency-establishing-a-common-software-bill-of-materials-sbom/ Date: 2024-06-11 Description: Summary of NTIA's SBOM Framing document 2nd edition highlighting transparency, interoperability standards, and what to expect in the upcoming 3rd edition. As the digital world grows ever more complex, the tools we use to ensure software security and transparency must evolve. The 2nd edition of [Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)](https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf) has been pivotal in laying down the standards necessary for identifying and managing software components. This edition emphasized transparency, interoperability, and security, enabling organizations to manage vulnerabilities more effectively and enhance trust across software supply chains. #### Key Highlights from the 2nd Edition 1. **Enhanced Transparency**: Improved clarity and accessibility of software component information, critical for managing vulnerabilities and ensuring system integrity. 2. **Interoperability Standards**: Establishing a common framework that facilitates better communication and compatibility across different systems and organizations. 3. **Security and Risk Management**: Providing detailed insights into software components, empowering organizations to manage risks proactively. 4. **Community and Collaboration**: Encouraging a collaborative environment among developers, suppliers, and users to maintain software reliability. #### Looking Ahead to the 3rd Edition The forthcoming 3rd edition of _Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)_ is set to build on the robust foundation laid by its predecessor. Here’s what we can anticipate: - **Advanced Security Measures**: Introducing more robust protocols to counter sophisticated cyber threats. - **Greater Automation**: Incorporating advanced automation tools to streamline SBOM creation and management, reducing manual efforts and errors. - **Expanded Scope**: Covering a broader range of software types and use cases to reflect the dynamic nature of modern technology. - **Global Standards Alignment**: Ensuring SBOM practices align with international standards to promote global interoperability and security. #### Notable Additions in the 3rd Edition Draft 1. **Updated Language and Clarifications**: To enhance understanding and implementation of SBOM attributes. 2. **New Baseline Attributes**: Inclusion of license and copyright holder information. 3. **Data Maturity Levels**: Introducing minimum expected, recommended practice, and aspirational goal maturity levels for SBOM attributes. 4. **Handling Undeclared Data**: Providing guidelines for managing unknown or redacted components and dependencies. As we eagerly await the release of the 3rd edition, it's crucial to reflect on the progress made and prepare for the future advancements in software security and transparency that the new edition promises. The continuous evolution of the SBOM framework is a testament to the collaborative efforts of the software community, aiming to create a more secure and transparent digital ecosystem. Stay tuned for more updates and insights as the 3rd edition of the SBOM Framing becomes available, setting the stage for the next chapter in software security and management. --- # Get the latest SBOMs from the top 15 most popular images on Docker Hub URL: https://sbomify.com/2024/06/04/get-the-latest-sboms-from-the-top-15-most-popular-images-on-docker-hub/ Date: 2024-06-04 Description: Automated nightly SBOM generation for Docker Hub's top 15 images including nginx, postgres, redis, and node using Syft in GitHub Actions CI/CD pipeline. Most companies that use Docker also use Docker Hub in some capacity. Have you ever wondered how secure these images are? In our article [Comprehensive Guide to Generating and Understanding SBOMs with Docker and Django-CMS](https://sbomify.com/2024/05/27/comprehensive-guide-to-generating-and-understanding-sboms-with-docker-and-django-cms/), we talked about how to generate SBOMs from a Docker image. In this article, we are taking this one step further and automating the process in our CI/CD pipeline (in this case [GitHub Actions](https://docs.github.com/en/actions)). We've created a GitHub repository called [docker-hub-sbom](https://github.com/sbomify/docker-hub-sbom) that automatically builds SBOMs for the top 15 Docker Hub images every night. The top 15 most popular (official) Docker images are as follows: - alpine - busybox - docker - hello-world - httpd - memcached - mongo - mysql - nginx - node - postgres - python - rabbitmq - redis - ubuntu To keep things simple, we will only generate the SBOM for the 'latest' tag of each disk image. Unlike in our previous guide, we will not use the `docker sbom` feature available in Docker Desktop. Instead, we will use the tool that Docker Desktop uses behind the scenes, namely [syft](https://github.com/anchore/syft). The full CI/CD pipeline is defined in [build-sboms.yml](https://github.com/sbomify/docker-hub-sbom/blob/master/.github/workflows/build-sboms.yml), but in simple terms, all it does is iterate over the list of images and then use `syft` to build an SBOM both in CycloneDX and SPDX format. After each run has been successful, it publishes the SBOMs as artifacts. You can see an example of this in [this run](https://github.com/sbomify/docker-hub-sbom/actions/runs/9359480735). For instance, you can download the SBOM for nginx ([CycloneDX](https://github.com/sbomify/docker-hub-sbom/actions/runs/9359480735/artifacts/1564889381) and [SPDX](https://github.com/sbomify/docker-hub-sbom/actions/runs/9359480735/artifacts/1564889383)). There are a few important things to point out here: - First, this way of generating SBOMs is completely CI/CD agnostic. You could easily take this workflow and implement it on other tools like [Travis](https://www.travis-ci.com/), [Jenkins](https://www.jenkins.io/), [TeamCity](https://www.jetbrains.com/teamcity/) or almost any other CI/CD platform. - Second, while we are using upstream Docker Hub images in this example, you could just swap this out for your own internal Docker images for your application and get the same result. --- # Comprehensive Guide to Generating and Understanding SBOMs with Docker and Django-CMS URL: https://sbomify.com/2024/05/27/comprehensive-guide-to-generating-and-understanding-sboms-with-docker-and-django-cms/ Date: 2024-05-27 Description: Practical walkthrough of generating SBOMs from Docker containers and Python projects using Django-CMS as an example, covering cyclonedx-python, docker sbom, and transitive dependencies. It's fair to say that SBOMs (Software Bill of Materials) is a rapidly emerging field. Many vendors, like Docker and GitHub, now offer tools to automatically generate SBOMs for you. That's great, but maybe we should first start by asking ourselves what should really go into an SBOM. The simplest answer to this question is that it should include everything that makes up your software. Thus, things like dependencies (such as open source libraries used) should go into the SBOM. This is where it gets a bit murkier. What about dependencies that you're only using for testing, such as a unit test library? This is never used in the production environment, so it's more like a soft dependency. But what about your runtime environment? If you're using a dockerized runtime environment, it's relatively easy to determine what's part of your application stack, but less so if you're running on bare metal or in a Virtual Machine (VM). You could argue that you need to generate an SBOM from your Infrastructure-as-Code (IaC), such as Terraform/OpenTofu or Ansible, which holds the truths about your runtime environment. That is, assuming you even pin the releases of all of this. It's also important to point out that an SBOM is not an absolute truth for a product. It's just true at the time of generation and might change the next time you fire off a build in your CI/CD pipeline. This largely depends on how strictly you pin your dependencies (and how strictly your dependencies pin their dependencies). It is, however, important to stress that SBOM generation needs to be part of your CI/CD pipeline to be relevant. Your mileage may vary, but to keep things simple, for the sake of this article, let's focus on the 'hard dependencies,' meaning things that are required for your software to work. Let's also assume that your application is running in Docker to keep things simple and that everything that goes inside your Dockerfile is a hard requirement. A project can, of course, span multiple services (e.g., microservices), but let's again keep things simple and focus on a single monolith application that lives inside a single Docker container. ### An Example Project: Django-CMS To make things more realistic, let's use the open-source project [Django CMS](https://github.com/django-cms/django-cms/) and their [Django CMS Quickstart](https://github.com/django-cms/django-cms-quickstart) as the basis for our exploration. Taking a closer look at this example, we will find a `requirements.txt` file as expected for a Python project. There are several tools we can use to generate an SBOM for this file, including [cyclonedx-python](https://github.com/CycloneDX/cyclonedx-python), which will generate an SBOM in CycloneDX format: ```bash $ cyclonedx-py requirements \ requirements.txt \ -o sbom.json ``` There are other tools, like [spdx-sbom-generator](https://github.com/opensbom-generator/spdx-sbom-generator), that can generate SBOMs in SPDX format (rather than CycloneDX as we used above). Now that we have our SBOM for the application layer, we can move on to the `Dockerfile` to build an SBOM for our Docker environment. We can do this as follows: ```bash $ docker build . -t django-cms [...] $ docker sbom \ --format cyclonedx-json \ -o docker-sbom.json \ django-cms ``` Now we have two files: - `sbom.json` - `docker-sbom.json` Let's take a look at them: ```bash $ wc -l sbom.json 1053 sbom.json $ wc -l docker-sbom.json 48162 docker-sbom.json ``` Whoa! The first SBOM is just over 1,000 lines, whereas the one from Docker is ~48 times that size. Why is that? As it turns out, Docker will actually do more than just give you information about the runtime. In fact, it gives you an SBOM for the runtime and your application stack. Under the hood, `docker sbom` uses [syft](https://github.com/anchore/syft), which is capable of generating SBOMs for Python too. Thus, we can disregard our first SBOM. The elegant thing about extracting our SBOM from a Docker container over a `requirements.txt` file is that assuming we are building our Docker containers correctly and not bundling our test dependencies in there, we have solved for this in the process. ### But wait, what about sub-dependencies? Fantastic question! If we go back to django-cms, we notice that there is a dependency outside of Python by the presence of [`package.json`](https://github.com/django-cms/django-cms/blob/develop-4/package.json) (and `package-lock.json`). If we randomly pick a dependency in there (such as babel-runtime), we can indeed prove that this is missing: ```bash $ grep babel-runtime docker-sbom.json [...] ``` This is where it gets tricky. If there is a vulnerability in this package, a surface-level exploration of the SBOM with a tool like [osv-scanner](https://osv.dev/) would not pick up on this. This is generally known as transitive dependencies. To address this, we need to "explode" the SBOM, but that's outside the scope of this article. --- # Call for Views on the Code of Practice for Software Vendors: Ensuring Security and Resilience URL: https://sbomify.com/2024/05/26/call-for-views-on-the-code-of-practice-for-software-vendors-ensuring-security-and-resilience/ Date: 2024-05-26 Description: UK government launches consultation on voluntary Code of Practice for Software Vendors to enhance security and resilience of digital products sold to businesses. The UK government has launched a call for views on a new voluntary Code of Practice for Software Vendors. This initiative aims to enhance the security and resilience of software sold to businesses and organizations. The Code, co-designed with industry and academic experts, outlines fundamental principles for secure design, development, deployment, and customer communication. It seeks feedback on its suitability and the supporting materials provided. This effort is part of broader measures to strengthen cybersecurity across the UK’s digital supply chains and improve organizational resilience. For more details, visit the [official call for views](https://www.gov.uk/government/calls-for-evidence/call-for-views-on-the-code-of-practice-for-software-vendors/call-for-views-on-the-code-of-practice-for-software-vendors). --- # Enhancing SBOM Sharing: A Look at Current Practices and the Role of sbomify URL: https://sbomify.com/2024/05/13/enhancing-sbom-sharing-a-look-at-current-practices-and-the-role-of-sbomify/ Date: 2024-05-13 Description: Analysis of CISA's SBOM Sharing Primer examining current SBOM sharing methods from email to automated tooling, and how sbomify simplifies the distribution process. Software Bill of Materials (SBOM) sharing is becoming increasingly vital in our interconnected digital ecosystem, where security and transparency play crucial roles. The "[SBOM Sharing Primer](https://www.cisa.gov/resources-tools/resources/sbom-sharing-primer)," published this week by the Cybersecurity and Infrastructure Security Agency (CISA), provides a comprehensive look into the practices surrounding SBOM sharing across various sectors and their implications for enhancing software transparency. ## What is an SBOM? An SBOM is essentially an ingredient list for software. It details the components, libraries, and modules that make up software applications. Understanding what is in your software is crucial for security, compliance, and management, making SBOMs invaluable. ## Current State of SBOM Sharing The primer outlines different methods of SBOM sharing employed by various actors in the software supply chain, such as SBOM Authors, Consumers, and Distributors. Each method is examined through the phases of Discovery, Access, and Transport - key elements that influence the sophistication and effectiveness of sharing practices. ### Examples of SBOM Sharing Practices 1. **Email-Based Sharing**: Simple but not scalable, used primarily by proprietary software vendors. 2. **Vendor Portals**: More controlled but requires manual intervention, providing a medium sophistication level for both discovery and access. 3. **Automated Tooling for OSS**: Open Source Software (OSS) projects benefit from automated tools that aid in the discovery and distribution of SBOMs, enhancing scalability and efficiency. Each method carries its trade-offs, balancing control against scalability and automation. The choice of method often depends on the industry's regulatory landscape, the nature of the software, and the organization's specific needs. ## The Role of sbomify in Simplifying SBOM Sharing Enter sbomify, a tool designed to streamline the sharing and management of SBOMs. Here’s how sbomify can simplify the SBOM sharing process: ### Automation and Standardization sbomify serves as a [dynamic hub](https://sbomify.com/share-and-collaborate/), enabling both buyers and software manufacturers to come together in a single unified platform for security artifacts (like SBOMs). This centralized approach allows buyers to streamline their interactions with all vendors in one place, greatly simplifying their oversight and management processes. Similarly, software manufacturers benefit from using sbomify to ensure that all stakeholders always have access to the latest SBOMs, enhancing transparency and ensuring that everyone is consistently informed. ### Integration with Existing Systems sbomify integrates seamlessly with existing software development and distribution workflows. This integration enables automatic SBOM generation during software build processes and easy distribution alongside software releases. ### Enhancing Security and Compliance With sbomify, organizations can enforce security policies and compliance requirements more effectively. It ensures that all SBOMs adhere to industry standards and regulations, providing a reliable audit trail for software components. ### Facilitating Broader Adoption By lowering the barriers to entry for creating and sharing SBOMs, sbomify encourages wider adoption of SBOM practices. This broader adoption is crucial for achieving the transparency needed to secure software supply chains globally. The "SBOM Sharing Primer" serves as a valuable resource, offering insights and practical examples that can help guide organizations in choosing the right SBOM sharing method. As SBOM practices mature, continued innovation and collaboration will be key to enhancing the effectiveness and efficiency of these critical transparency tools. For further details and a deeper understanding of SBOM sharing methods, consult the full document published by CISA [here](https://www.cisa.gov/sbom). --- # Understanding ISO 42001 and the Integration of SBOMs for Enhanced Operational Resilience URL: https://sbomify.com/2024/05/02/understanding-iso-42001-and-the-integration-of-sboms-for-enhanced-operational-resilience/ Date: 2024-05-02 Description: How to integrate SBOMs with ISO 42001 operational resilience management systems for better risk assessment, incident response, and compliance. ## Introduction to ISO 42001 In an era marked by rapid technological advances and complex interdependencies, businesses increasingly prioritize operational resilience to navigate challenges and disruptions. ISO 42001, an emerging standard, provides a framework for establishing, implementing, and maintaining an effective operational resilience management system (ORMS). This standard helps organizations anticipate, respond to, and recover from disruptions, ensuring continued service delivery and stakeholder confidence. ## What is ISO 42001? ISO 42001 sets guidelines for an ORMS that allows companies to assess their operational vulnerabilities and implement strategic processes to enhance resilience. This standard addresses various aspects of resilience planning, from business continuity and crisis management to cybersecurity and information integrity. By adhering to ISO 42001, organizations can proactively manage potential disruptions, minimizing impact and maintaining critical operations under adverse conditions. ## The Role of SBOMs in Supporting ISO 42001 A Software Bill of Materials (SBOM) is an integral component that can significantly enhance the implementation of ISO 42001. By detailing every piece of software within a system, an SBOM provides a clear picture of the software environment, which is critical for managing risks related to operational disruptions, particularly those caused by software vulnerabilities. ### Strengthening Risk Assessment and Management One of the core elements of ISO 42001 is a thorough risk assessment process. SBOMs contribute to this by offering detailed visibility into the software components used across an organization. This visibility is crucial for identifying potential security vulnerabilities that could compromise operational resilience. By integrating SBOMs into their ORMS, organizations can more effectively identify, evaluate, and prioritize risks associated with software components, ensuring robust mitigation strategies are in place. ### Enhancing Incident Response and Recovery In the context of ISO 42001, effective incident response and recovery are vital for maintaining operational resilience. SBOMs aid in these processes by providing essential information that can accelerate the identification of the affected components during a security breach or failure. This timely identification enables quicker remediation, reducing downtime and mitigating the impact on business operations. ### Facilitating Compliance and Auditing For organizations seeking to comply with ISO 42001, SBOMs serve as a valuable tool for auditing and compliance verification. They offer a transparent account of the software inventory, which auditors can use to assess the adequacy of the organization's resilience measures. Furthermore, SBOMs ensure that all software dependencies are known and managed according to the resilience requirements set forth in ISO 42001, thereby supporting comprehensive compliance efforts. ## Implementing ISO 42001 with SBOMs Integrating SBOMs into an ORMS as per ISO 42001 can be strategically advantageous for organizations. Here's how to effectively incorporate SBOMs: 1. **Scope Definition**: Define the scope of the ORMS to include all critical software assets. Use SBOMs to gain a comprehensive understanding of these assets. 2. **Risk Management**: Implement a systematic process to analyze the risks associated with each software component listed in the SBOMs. Develop strategies to mitigate these risks in alignment with the resilience objectives of ISO 42001. 3. **Incident Management**: Utilize SBOMs to enhance incident management protocols. Ensure that response plans account for potential vulnerabilities identified through SBOMs, facilitating rapid recovery actions. 4. **Continuous Improvement**: Regularly update SBOMs and review them as part of the ORMS evaluation process to adapt to new threats and vulnerabilities, maintaining alignment with ISO 42001 standards. 5. **Training and Awareness**: Educate staff about the importance of SBOMs in operational resilience and ensure they understand how to leverage this information in their roles. ## Conclusion ISO 42001 and SBOMs together provide a robust framework for enhancing operational resilience by offering a proactive approach to managing disruptions related to software vulnerabilities. By integrating SBOMs into their resilience strategies, organizations can achieve greater transparency, improve risk management, and expedite recovery processes, ensuring they are better equipped to handle disruptions and maintain continuity in today’s volatile business environment. Embracing this combined approach allows businesses to not only safeguard their operations but also enhance their overall resilience and reliability. --- # Harnessing ISO 27001 and SBOMs for Enhanced Information Security Management URL: https://sbomify.com/2024/04/29/harnessing-iso-27001-and-sboms-for-enhanced-information-security-management/ Date: 2024-04-29 Description: How to integrate SBOMs into ISO 27001 information security management systems for better risk assessment, compliance auditing, and vendor management. ## Introduction to ISO 27001 As businesses navigate the complex landscape of cyber threats, ISO 27001 emerges as a vital standard for establishing robust information security management systems (ISMS). This international standard, developed by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), provides a comprehensive framework for protecting sensitive information across all formats, fostering secure and resilient operations. ## What is ISO 27001? ISO 27001 sets forth the criteria for an ISMS that includes policies, procedures, and controls aimed at managing an organization's information risks. By adopting ISO 27001, companies not only enhance their ability to protect critical information assets but also demonstrate a commitment to security best practices, which can significantly boost client and partner confidence. ## The Role of SBOMs in Strengthening ISO 27001 Implementation A Software Bill of Materials (SBOM) is an essential tool that complements the ISO 27001 framework. An SBOM provides a detailed inventory of all software components in a product, from libraries to modules, revealing their origin, composition, and security attributes. This transparency is invaluable for thorough risk management and security compliance, key components of an effective ISMS under ISO 27001. ### Enhancing Risk Assessment and Treatment ISO 27001 mandates organizations to systematically evaluate information security risks by considering threats, vulnerabilities, and impacts. SBOMs significantly bolster this process by offering clear visibility into software components, making it easier to identify vulnerabilities and assess the associated risks. This detailed insight aids organizations in prioritizing and implementing appropriate controls as outlined in Annex A of ISO 27001. ### Supporting Compliance and Audit Processes Adopting SBOMs aids in meeting ISO 27001's stringent compliance requirements. They provide auditable evidence of due diligence in software security and component management, facilitating smoother internal and external audits. This documentation is crucial for proving that the ISMS is not only well-designed but also effectively managed and maintained according to the standard's guidelines. ### Streamlining Vendor Management For organizations relying on third-party software within their ISMS scope, SBOMs are particularly beneficial. They enable better scrutiny of third-party components, ensuring that external software complies with ISO 27001's security requirements. This is crucial for comprehensive ISMS coverage, ensuring that all parts of the information ecosystem, regardless of origin, meet the necessary security standards. ## Implementing ISO 27001 with the Aid of SBOMs Incorporating SBOMs into the ISO 27001 implementation process enhances the overall security posture of an organization. Here are steps to effectively integrate SBOMs into your ISMS: 1. **Scope Definition**: Clearly define the scope of the ISMS to include all software products used within the organization. 2. **Risk Management**: Utilize SBOMs to conduct thorough risk assessments of all software components. Identify and evaluate risks associated with each component and apply ISO 27001 controls to mitigate them. 3. **Control Implementation**: Refer to SBOMs when designing and implementing technical and organizational controls, ensuring all software vulnerabilities are addressed. 4. **Continuous Improvement**: Regularly update SBOMs as part of the ISMS review process to maintain an up-to-date understanding of software components and associated risks. 5. **Training and Awareness**: Educate stakeholders on the importance of SBOMs in maintaining ISO 27001 compliance and enhancing the security of software assets. ## Conclusion ISO 27001 provides a strategic blueprint for comprehensive information security management. When supplemented with SBOMs, organizations can achieve a deeper understanding of their software vulnerabilities, enhance compliance efforts, and streamline audit processes. This integration not only fortifies the security framework but also supports dynamic risk management, ensuring businesses can protect their critical information assets against emerging threats. By embracing both ISO 27001 and the detailed insights offered by SBOMs, companies can elevate their information security to meet the challenges of the digital age. --- # Exploring the New SPDX 3.0: A Game Changer for SBOMs URL: https://sbomify.com/2024/04/28/exploring-the-new-spdx-3-0-a-game-changer-for-sboms/ Date: 2024-04-28 Description: Overview of SPDX 3.0 improvements including enhanced compatibility, improved accuracy, streamlined automation, and broader software package support for SBOM generation. **TL;DR:** SPDX 3.0 is the latest update to the Software Package Data Exchange standard, significantly enhancing the way Software Bill of Materials (SBOMs) are created, maintained, and utilized across the software industry. This new version offers improved compatibility, detail, and process automation, making it an indispensable tool for managing software supply chain security, ensuring compliance, and improving quality assurance in an increasingly complex digital world. ## What is an SBOM? A Software Bill of Materials (SBOM) is essentially a comprehensive inventory of all components, libraries, and modules contained in a piece of software. Think of it as a detailed list of ingredients that tells you exactly what’s in the software you use or develop. SBOMs are crucial for tracking the origins of software components, managing licenses, and most importantly, identifying potential security vulnerabilities. ## Introducing SPDX 3.0 The Software Package Data Exchange (SPDX) format is one of the most widely recognized standards for communicating SBOM information. Developed by the SPDX Workgroup under the Linux Foundation, it provides a common format for software tools to share data about software packages. With the introduction of SPDX 3.0, several advancements have been made to further enhance the utility and adoption of SBOMs across industries. ### Enhanced Compatibility and Flexibility One of the standout features of SPDX 3.0 is its increased compatibility and flexibility. This new version supports a broader range of software packages and environments, making it applicable to more complex software systems than ever before. Whether you are dealing with traditional applications, microservices, or even IoT devices, SPDX 3.0 offers a robust framework for documenting software components. ### Improved Accuracy and Detail SPDX 3.0 has significantly improved the level of detail and accuracy in documenting software components. This new version allows for more precise descriptions of each component, including its origin, version, and any known vulnerabilities. This enhancement not only aids developers and security professionals in identifying risks but also helps in compliance with various regulatory requirements. ### Streamlined Processes The introduction of automated tooling compatibility in SPDX 3.0 streamlines the process of generating and maintaining SBOMs. Tools that support SPDX 3.0 can automatically generate accurate and up-to-date SBOMs as part of the software development process. This automation reduces human error and ensures that SBOMs are always reflective of the current state of the software, thereby enhancing overall software supply chain security. ## Why SPDX 3.0 Matters In today’s software development environment, where third-party and open-source components are ubiquitous, having a clear understanding of what’s inside your software is more critical than ever. Here’s why SPDX 3.0 is a game changer: - **Security**: With detailed component tracking, organizations can quickly respond to new vulnerabilities as they are discovered. SPDX 3.0 enables faster and more accurate vulnerability management. - **Compliance**: Many industries are subject to regulations that require detailed software component documentation. SPDX 3.0 facilitates compliance with these regulations, reducing the risk of non-compliance penalties. - **Quality Assurance**: By providing a clear picture of all software ingredients, SPDX 3.0 helps quality assurance teams identify potential compatibility issues, outdated libraries, or unsupported licenses. ## Looking Ahead As the adoption of SPDX 3.0 grows, we can expect a more standardized approach to SBOM management across the tech industry. This will likely lead to improved software security practices, more efficient compliance processes, and a greater overall trust in technology ecosystems. For developers, security professionals, and compliance officers, embracing SPDX 3.0 offers an opportunity to stay ahead in managing software risks effectively. It’s not just about complying with the current standards but setting a foundation for a more secure future in software development. SPDX 3.0 is not just a new format; it's a strategic tool in the ongoing battle to secure software supply chains against the threats of today and tomorrow. As we move forward, leveraging this standard will be key to maintaining the integrity and security of our digital infrastructure. --- # What Is OpenSSF? Scorecards, SLSA, and the Open Source Security Ecosystem URL: https://sbomify.com/2024/04/25/openssf-and-openssf-scorecards-bolstering-open-source-security/ Date: 2024-04-25 Description: What is OpenSSF? The Open Source Security Foundation coordinates industry-wide efforts to secure open source software. Learn about OpenSSF Scorecards, how to run them, what they measure, and how they connect to SBOMs, SLSA, and supply chain security. After the [Log4Shell vulnerability](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) exposed how a single widely-used open source library could affect hundreds of thousands of organizations, the technology industry confronted an uncomfortable question: who is responsible for securing the open source software that underpins the modern internet? The answer, increasingly, is everyone – and the **[Open Source Security Foundation (OpenSSF)](https://openssf.org/)** is the organization coordinating that effort. OpenSSF is a cross-industry initiative under the Linux Foundation that brings together developers, security professionals, and organizations to improve the security of open source software. Formed in 2020 by merging the Core Infrastructure Initiative (CII) and the Open Source Security Coalition, OpenSSF includes members like Google, Microsoft, Amazon, Intel, IBM, and dozens of other companies that depend on open source and have a shared interest in securing it. ## The OpenSSF Ecosystem OpenSSF is not a single tool – it is an umbrella for a portfolio of projects that together address different layers of the software supply chain security problem. | Project | What It Does | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | **[Scorecards](https://securityscorecards.dev/)** | Automated security health assessment for open source projects | | **[SLSA](/2024/08/17/what-is-slsa/)** | Build integrity and provenance framework (Supply chain Levels for Software Artifacts) | | **[Sigstore](/2024/08/12/what-is-sigstore/)** | Keyless signing and verification infrastructure | | **[GUAC](https://guac.sh/)** | Graph for Understanding Artifact Composition – aggregates supply chain metadata | | **[Alpha-Omega](https://openssf.org/community/alpha-omega/)** | Funds security improvements for critical open source projects | | **[Best Practices Badge](https://www.bestpractices.dev/)** | Self-assessment program for open source project security maturity | | **[Package Analysis](https://github.com/ossf/package-analysis)** | Detects malicious packages in open source registries | | **[Allstar](https://github.com/ossf/allstar)** | Enforces security policies on GitHub organizations | This guide focuses on **Scorecards** – the most widely used and immediately actionable tool in the OpenSSF portfolio. ## OpenSSF Scorecards: How They Work [OpenSSF Scorecards](https://securityscorecards.dev/) is an automated tool that evaluates the security practices of open source projects on GitHub. It examines a project's repository configuration, CI/CD setup, dependency management, and contribution practices, and produces a score from 0 to 10 for each check. ### What Scorecards Measure Scorecards currently run 18+ checks. The most important ones: **Branch Protection** – Is the default branch protected? Are force pushes blocked? Are status checks required before merging? Branch protection prevents unauthorized code from entering the main branch. **Code Review** – Are pull requests reviewed before merging? Code review is one of the most effective defenses against malicious or accidental introduction of vulnerabilities. **CI Tests** – Does the project run tests in CI? Automated testing catches regressions that manual review might miss. **Dependency Update Tool** – Does the project use Dependabot, Renovate, or a similar tool to keep dependencies current? Outdated dependencies are a common source of vulnerabilities. **Pinned Dependencies** – Are CI/CD workflow dependencies pinned to specific versions (by hash, not tag)? Unpinned dependencies in GitHub Actions workflows are a supply chain attack vector – an attacker who compromises a dependency can inject code into every workflow that references it by tag. **Vulnerabilities** – Does the project have unaddressed vulnerabilities in the OSV database? This checks whether known security issues are being resolved. **Security Policy** – Does the project have a `SECURITY.md` file describing how to report vulnerabilities? A clear disclosure process encourages responsible reporting. **Signed Releases** – Are releases cryptographically signed? Signed releases let consumers verify artifact integrity. This is where [Sigstore](/2024/08/12/what-is-sigstore/) and Scorecards intersect. **Fuzzing** – Does the project participate in OSS-Fuzz or use other fuzzing infrastructure? Fuzzing finds bugs that unit tests typically miss. **SAST** – Does the project run static analysis security testing tools? SAST catches common vulnerability patterns in code. **Token Permissions** – Are GitHub Actions workflow tokens scoped to minimum necessary permissions? Overly broad tokens increase the blast radius of a compromised workflow. **Dangerous Workflow** – Does the project have CI workflows that run untrusted code in a privileged context (e.g., `pull_request_target` with checkout)? This is a known attack vector for GitHub Actions. ### Running Scorecards **CLI:** ```bash # Install go install github.com/ossf/scorecard/v5/cmd/scorecard@latest # Run against any public GitHub repo scorecard --repo=github.com/apache/log4j ``` **GitHub Action (for your own repos):** ```yaml - uses: ossf/scorecard-action@v2 with: results_file: results.sarif publish_results: true ``` The GitHub Action posts results to the repository's Security tab and can be configured to run on every push or PR. **Website:** Pre-computed scores for popular projects are available at [securityscorecards.dev](https://securityscorecards.dev/). ### Interpreting Results Scorecard results are most useful when viewed at the individual check level, not just as an aggregate score. A project might score 9/10 overall but have a 0 on Branch-Protection – which is a critical gap regardless of the overall score. When evaluating a dependency, focus on the checks that matter most for your threat model: - **If you're concerned about supply chain attacks:** Prioritize Branch-Protection, Code-Review, Pinned-Dependencies, Signed-Releases, and Dangerous-Workflow. - **If you're concerned about vulnerability management:** Prioritize Vulnerabilities, Dependency-Update-Tool, and Maintained. - **If you're concerned about build integrity:** Prioritize CI-Tests, SAST, and Fuzzing. ## Scorecards and SBOMs Scorecards and [SBOMs](/what-is-sbom/) address different dimensions of dependency risk, and they are most powerful when used together. An SBOM tells you _what_ dependencies you have and [whether they contain known vulnerabilities](/2026/02/01/sbom-scanning-vulnerability-detection/). Scorecards tell you _how well those dependencies are maintained_ – which is a leading indicator of future vulnerability risk. A dependency with no known CVEs but a Scorecard score of 2/10 (no code review, no CI tests, no branch protection) is a risk that an SBOM alone would not flag. **Practical workflow:** 1. Generate an [SBOM](/what-is-sbom/) for your project to identify all dependencies 2. Run Scorecards against your critical dependencies (or check pre-computed scores on securityscorecards.dev) 3. Use Scorecard results to inform dependency selection: prefer well-maintained dependencies with strong security practices 4. Monitor both SBOMs (for vulnerabilities) and Scorecards (for security practice degradation) over time For organizations using [sbomify](https://sbomify.com) for SBOM management, Scorecard data provides a complementary signal: while sbomify tracks known vulnerabilities in your components, Scorecards assess the development practices that determine how quickly those dependencies will respond to future vulnerabilities. ## Scorecards and SLSA Scorecards and [SLSA](/2024/08/17/what-is-slsa/) are both OpenSSF projects, and they reinforce each other: - Scorecards evaluate whether a project _follows_ good security practices (code review, CI testing, dependency management) - SLSA verifies that a specific artifact _was built_ through a secure, untampered process A project can have a perfect Scorecard but ship a compromised artifact if the build system is attacked. SLSA provenance catches that. Conversely, a project can have SLSA Build L3 provenance but still ship vulnerable code if it lacks code review or CI testing. Scorecards catch that. Together, they provide layered defense: Scorecards for development practices, SLSA for build integrity, and [SBOMs](/what-is-sbom/) for component visibility. ## Frequently Asked Questions ### What is OpenSSF? The Open Source Security Foundation (OpenSSF) is a cross-industry initiative under the Linux Foundation that brings together developers, security professionals, and organizations to improve the security of open source software. It coordinates projects including Scorecards, [SLSA](/2024/08/17/what-is-slsa/), [Sigstore](/2024/08/12/what-is-sigstore/), GUAC, Alpha-Omega, and the Best Practices Badge program. ### What are OpenSSF Scorecards? [OpenSSF Scorecards](https://securityscorecards.dev/) is an automated tool that evaluates the security practices of open source projects on GitHub. It runs 18+ checks covering areas like branch protection, code review, dependency management, CI/CD security, fuzzing, and vulnerability disclosure. Each check produces a score from 0 to 10. ### How do I run OpenSSF Scorecards? You can run Scorecards via the CLI (`scorecard --repo=github.com/org/repo`), as a [GitHub Action](https://github.com/ossf/scorecard-action) on your own repository, or look up pre-computed scores at [securityscorecards.dev](https://securityscorecards.dev/). ### How do Scorecards relate to SBOMs? Scorecards help evaluate the security quality of your dependencies, which is complementary to [SBOM](/what-is-sbom/)-based vulnerability monitoring. An SBOM tells you what dependencies you have; Scorecards tell you how well-maintained and secure those dependencies' development practices are. Combining both gives a more complete picture of supply chain risk. ### Is OpenSSF the same as the Linux Foundation? OpenSSF is a project _within_ the Linux Foundation, not a separate organization. It was formed in 2020 by merging the Core Infrastructure Initiative (CII) and the Open Source Security Coalition. Its members include Google, Microsoft, Amazon, Intel, IBM, and many other organizations invested in open source security. --- # How SBOMs Streamline SOC 2 Compliance: Insights for the Agile Enterprise URL: https://sbomify.com/2024/04/23/how-sboms-streamline-soc-2-compliance-insights-for-the-agile-enterprise/ Date: 2024-04-23 Description: Guide on using SBOMs to simplify SOC 2 Type I and Type II compliance through improved transparency, proactive risk management, and streamlined audits. ## Decoding SOC 2 Compliance for Agile Enterprises For agile enterprises aiming to assure clients that their data is in safe hands, SOC 2 compliance is crucial. This framework, shaped by the American Institute of CPAs (AICPA), scrutinizes an organization's approach to managing data across five key principles: security, availability, processing integrity, confidentiality, and privacy. But achieving SOC 2 compliance isn’t just about ticking boxes – it’s about integrating robust data management practices into your everyday workflows. ### The Two Types of SOC 2 Reports There are two types of SOC 2 reports: Type I and Type II. **Type I** is essentially a snapshot, assessing the design of your controls at a specific moment in time. It’s like taking a still photo of your security measures to ensure they're set up correctly. **Type II**, on the other hand, is more like a video, capturing the operational effectiveness of these controls over a minimum of six months. This ongoing evaluation provides deeper insights into how well your practices really hold up under everyday business pressures. ## The Strategic Advantage of SBOMs in SOC 2 Compliance A Software Bill of Materials (SBOM) provides a comprehensive inventory of every component that makes up your software. For agile enterprises looking to enhance their SOC 2 compliance, leveraging SBOMs can be a game-changer. ### Elevating Transparency and Traceability With SBOMs, every single software component is mapped out, making it easier to track origins and functions. This high level of detail is a boon for transparency, crucial for meeting the security and availability aspects of SOC 2. Knowing precisely what's in your software helps identify potential vulnerabilities and ensures that all elements meet security standards, thereby simplifying compliance processes. ### Simplifying Risk Management For SOC 2 Type II compliance, where the focus is on the effectiveness of controls over time, SBOMs are invaluable. They allow businesses to quickly react to new vulnerabilities by pinpointing which applications are impacted based on their detailed component lists. This capability not only enhances your security posture but also keeps you one step ahead in compliance by enabling proactive risk management. ### Streamlining Audits and Reporting When audit time rolls around, having an SBOM makes the process much smoother. Auditors can easily verify the security controls in place and track their effectiveness throughout the reporting period. This clarity and easy access to detailed information can make SOC 2 Type II audits more straightforward and less stressful. ## Implementing SBOMs for Optimal SOC 2 Compliance Here's how you can integrate SBOMs into your SOC 2 compliance strategy effectively: 1. **Develop a Tailored SBOM Strategy**: Define the scope and granularity of your SBOMs based on the complexity of your software and your specific compliance needs. 2. **Automate SBOM Generation and Maintenance**: Employ tools that automatically generate and update SBOMs whenever your software evolves. 3. **Incorporate SBOMs into Your Risk Management Framework**: Regularly analyze your SBOMs as part of your security assessments and vulnerability management processes. 4. **Educate Your Team**: Make sure everyone from developers to the C-suite understands the value and use of SBOMs in maintaining SOC 2 compliance. ## Conclusion Incorporating SBOMs into your SOC 2 compliance strategy isn't just about improving security – it’s about fostering a culture of transparency and proactive risk management. As technology and threats evolve, utilizing SBOMs will not only help meet rigorous compliance standards but also enhance your enterprise’s overall security and trustworthiness. Agile enterprises that embrace this approach will find themselves well-equipped to navigate the complexities of modern data management and protection. --- # What really happened to XZ? URL: https://sbomify.com/2024/04/13/what-really-happened-to-xz/ Date: 2024-04-13 Description: Analysis of the XZ backdoor discovery in Linux distributions, exploring how this supply chain attack worked and the implications for open-source security. The article "XZ Backdoor Story Part 1" from Securelist delves into the discovery and analysis of a backdoor found in XZ, which is commonly used in various Linux distributions and OpenSSH server processes. This piece provides an initial technical overview of how the backdoor operates, its implications for security, and the broader context of its use in cyber-attacks. Kaspersky's researchers detail the technical characteristics of the backdoor, discussing its potential origins and the techniques it employs to compromise systems. They also explore the broader trend of increasing sophistication in malware design and the ongoing challenges of securing open-source software components from such stealthy infiltrations. The discussion also touches on the importance of robust cybersecurity measures and the need for continuous monitoring and updating of systems to defend against these evolving threats. The analysis serves as a cautionary tale about the vulnerabilities that can be exploited in widely used software and the necessity for the cybersecurity community to remain vigilant against such hidden threats. For further details on this analysis, you can read the full article on [Securelist's website](https://securelist.com/xz-backdoor-story-part-1/112354/). --- # Elevate Your Cybersecurity with Our Leading SBOM Management Solution URL: https://sbomify.com/2024/04/12/elevate-your-cybersecurity-with-our-leading-sbom-management-solution/ Date: 2024-04-12 Description: How sbomify's SBOM management platform helps organizations comply with Executive Order 14028 through comprehensive visibility, vulnerability management, and streamlined reporting. In an era where digital security is paramount, the recent Executive Order 14028 on Improving the Nation’s Cybersecurity has set a new precedent for software supply chain security, emphasizing the critical role of Software Bill of Materials (SBOM) in enhancing transparency and trustworthiness in software products. As a provider of SBOM management software, we are at the forefront of supporting organizations to navigate and comply with these new mandates, ensuring that your software supply chain is secure, compliant, and resilient against cyber threats. #### The SBOM Mandate: A Game-Changer in Cybersecurity The Executive Order marks a pivotal moment in cybersecurity policy, directing the National Institute of Standards and Technology (NIST) to develop guidelines for improving software supply chain security. One of the cornerstone achievements of this initiative is the formalization of the SBOM – a comprehensive record of the components that make up software products. This development is not just a regulatory milestone; it's a transformative step towards ensuring that organizations can identify, manage, and mitigate vulnerabilities effectively. #### How Our SBOM Management Solution Can Help **Comprehensive Visibility and Compliance:** Our SBOM management software provides an exhaustive view of your software components, ensuring you meet the Executive Order's requirements. With our tool, you can generate, maintain, and audit SBOMs efficiently, giving you and your stakeholders confidence in the security and compliance of your software products. **Proactive Vulnerability Management:** By leveraging our SBOM management solution, you're not just complying with regulations – you're proactively enhancing your cybersecurity posture. Our platform enables you to quickly identify vulnerabilities within your software components, facilitating rapid response and remediation to protect against potential threats. **Streamlined Collaboration and Reporting:** Compliance with the new SBOM mandates requires seamless collaboration across teams and with external stakeholders. Our platform simplifies this process, providing intuitive tools for generating and sharing SBOMs and compliance reports, ensuring you can communicate your cybersecurity measures effectively. **Adapt and Thrive in a New Cybersecurity Landscape:** The Executive Order and NIST’s subsequent guidelines represent a significant shift towards prioritizing software supply chain security. With our SBOM management software, your organization will not only adapt but thrive in this new landscape, leveraging cutting-edge tools to safeguard your products and reputation. #### Embrace the Future of Cybersecurity with Confidence The call to action by the Executive Order on cybersecurity is clear, and the mandate for utilizing SBOMs underscores the importance of transparency and accountability in the software supply chain. Our SBOM management solution is designed to help you navigate these changes with ease, providing a robust platform for compliance, security, and collaboration. In a world where cybersecurity is more critical than ever, let us be your partner in embracing these new mandates and transforming your security practices. Contact us today to learn how our SBOM management software can elevate your cybersecurity and compliance to meet and exceed the standards set by the Executive Order 14028. --- # NIST Cybersecurity Framework (CSF) 2.0: What It Means for Software Supply Chain Security URL: https://sbomify.com/2024/04/11/introducing-the-nist-cybersecurity-framework-csf-2-0/ Date: 2024-04-11 Description: A practical guide to NIST CSF 2.0, its six core functions including the new GOVERN function, and how SBOMs support CSF 2.0 implementation for supply chain risk management and vulnerability monitoring. In February 2024, the National Institute of Standards and Technology (NIST) released version 2.0 of the Cybersecurity Framework – the most significant update since the framework's original publication in 2014. CSF 2.0 reflects a decade of lessons learned from real-world cybersecurity incidents, supply chain attacks, and the growing recognition that cybersecurity governance is as important as technical controls. For organizations building or consuming software, CSF 2.0 is particularly relevant because of its expanded treatment of supply chain risk management – and [SBOMs](/what-is-sbom/) are a foundational capability for meeting many of its outcomes. ## The Six Core Functions CSF 2.0 organizes cybersecurity outcomes into six core functions. The most significant structural change from CSF 1.1 is the addition of GOVERN as a new top-level function. ### GOVERN (New in CSF 2.0) The GOVERN function establishes and monitors the organization's cybersecurity risk management strategy, expectations, and policy. It elevates cybersecurity governance from a background concern to an explicit, measurable function – recognizing that cybersecurity decisions are fundamentally business decisions. Key outcomes include: - **Organizational context** – Understanding the organization's mission, stakeholder expectations, and legal/regulatory requirements - **Risk management strategy** – Establishing risk tolerance, priorities, and resource allocation - **Supply chain risk management** – Policies and processes for managing cybersecurity risk in the supply chain - **Roles and responsibilities** – Clear accountability for cybersecurity outcomes The explicit inclusion of supply chain risk management in GOVERN signals that NIST considers it a governance-level concern, not just a technical one. ### IDENTIFY The IDENTIFY function focuses on understanding the organization's assets, business environment, and risk exposure. For software supply chain security, this means knowing what software you use, what components it contains, and what risks those components introduce. Key categories: - **Asset Management (ID.AM)** – Inventorying hardware, software, data, and services - **Risk Assessment (ID.RA)** – Understanding threats, vulnerabilities, and their potential impact - **Improvement (ID.IM)** – Continuous assessment and refinement of cybersecurity practices ### PROTECT The PROTECT function implements safeguards to ensure delivery of services. In the supply chain context, this includes ensuring software integrity, managing access controls, and maintaining secure configurations. ### DETECT The DETECT function defines activities to identify cybersecurity events in a timely manner. For software supply chains, this means continuous monitoring of components for newly disclosed vulnerabilities. ### RESPOND The RESPOND function covers activities to take action on detected cybersecurity incidents – including communication, analysis, mitigation, and improvements based on lessons learned. ### RECOVER The RECOVER function focuses on restoring capabilities impaired by a cybersecurity incident – including recovery planning, improvements, and communications. ## CSF 2.0 Components Beyond the six functions, CSF 2.0 provides structural tools for implementation: ### Organizational Profiles Profiles help organizations articulate their current cybersecurity posture ("Current Profile") and their target state ("Target Profile"). The gap between the two drives prioritized improvements. This is particularly useful for organizations beginning their supply chain security journey – the Current Profile honestly assesses what's in place, while the Target Profile defines what "good" looks like. ### Tiers CSF 2.0 defines four tiers of cybersecurity risk management maturity: 1. **Partial** – Ad hoc, reactive practices with limited awareness of supply chain risk 2. **Risk Informed** – Risk management processes are in place but may not be organization-wide 3. **Repeatable** – Formal policies and procedures consistently applied, including supply chain risk management 4. **Adaptive** – Continuous improvement based on lessons learned and predictive indicators Organizations should use tiers honestly – most organizations starting their SBOM journey are at Tier 1 or 2, and that's a legitimate starting point. ### Community Profiles and Quick Start Guides NIST provides supplementary resources including Community Profiles (pre-built profiles for specific sectors or use cases) and Quick Start Guides for organizations new to the framework. These resources are available on the [NIST CSF website](https://www.nist.gov/cyberframework). ## How SBOMs Support CSF 2.0 Implementation SBOMs are not mentioned as a standalone requirement in CSF 2.0, but they directly support outcomes across multiple functions. Organizations implementing CSF 2.0 should consider SBOM adoption as a foundational capability. ### GOVERN: Supply Chain Risk Management Policy The GOVERN function expects organizations to have policies and processes for managing supply chain risk. Implementing SBOM requirements – for both internally developed software and vendor-provided software – is a concrete, auditable way to demonstrate supply chain governance. Specific actions: - Establish a policy requiring SBOM generation for all internally developed software - Include SBOM requirements in vendor procurement contracts - Define acceptable license policies and vulnerability response SLAs - Use a management platform like [sbomify](https://sbomify.com) to enforce these policies consistently ### IDENTIFY: Software Asset Management The IDENTIFY function's Asset Management category (ID.AM) requires organizations to inventory their assets, including software. SBOMs provide the most granular and accurate form of software asset inventory available – down to the individual library version and its transitive dependencies. Without SBOMs, software asset management typically stops at the application level ("we use Product X version Y"). With SBOMs, asset management extends to "Product X version Y contains 847 open source components, including Log4j 2.17.1 and OpenSSL 3.0.8." This granularity is exactly what vulnerability response requires. sbomify's [SBOM hierarchy](/features/sbom-hierarchy/) maps this to organizational structure: products contain projects, projects contain components. This aligns naturally with CSF 2.0's emphasis on understanding organizational context. ### PROTECT: Supply Chain Integrity The PROTECT function includes safeguards for data security and platform integrity. In the supply chain context, this means verifying that software components are authentic and haven't been tampered with. SBOM attestation provides cryptographic verification of integrity and provenance. On GitHub Actions, the `attest-build-provenance` action creates SLSA build provenance attestations for SBOMs generated by the sbomify action, allowing recipients to verify that the SBOM was produced by a legitimate CI/CD pipeline – not manually assembled or modified after the fact. ### DETECT: Continuous Vulnerability Monitoring The DETECT function's Continuous Monitoring category is where SBOMs deliver perhaps their most tangible value. By ingesting SBOMs into a management platform and continuously cross-referencing components against vulnerability databases, organizations implement automated detection of newly disclosed vulnerabilities. With sbomify, this works as follows: 1. SBOMs are generated in CI/CD and ingested into the platform 2. Every component is continuously checked against Google OSV and other vulnerability databases 3. When a new vulnerability is disclosed that affects a component in your inventory, you're alerted automatically 4. The SBOM hierarchy tells you exactly which products and services are affected This transforms vulnerability response from "search every application to see if we're affected" to "check the alert to see which products contain the affected component." For more on this workflow, see our guide on [SBOM scanning for vulnerability detection](/2026/02/01/sbom-scanning-vulnerability-detection/). ### RESPOND and RECOVER: Incident Context During incident response, SBOMs provide the context needed for rapid triage. When a zero-day vulnerability is disclosed, the first question is always "are we affected?" With SBOMs managed in sbomify, the answer is immediate – and the SBOM hierarchy tells you exactly which services need attention. This aligns with CSF 2.0's emphasis on rapid, informed response and the ability to recover quickly from cybersecurity events. ## CSF 2.0 and Other Regulatory Frameworks CSF 2.0 is designed to be complementary to other frameworks and regulations: - **[Executive Order 14028](/compliance/eo-14028/)** – Directly references NIST guidelines and SBOM requirements - **[EU Cyber Resilience Act](/compliance/eu-cra/)** – Aligns with CSF 2.0's supply chain risk management outcomes - **[PCI DSS 4.0](/compliance/pci-dss/)** – Maps to CSF 2.0 categories for organizations in the payment card industry - **CMMC** – The Cybersecurity Maturity Model Certification builds on NIST 800-171, which aligns with CSF categories - **ISO 27001** – CSF 2.0 Organizational Profiles can be aligned with ISO 27001 controls For organizations subject to multiple frameworks, CSF 2.0 serves as a unifying structure – implement once, map to many. For a broader view of the [compliance landscape](/compliance/), see our compliance hub. ## Getting Started with CSF 2.0 and SBOMs For organizations adopting CSF 2.0 and integrating SBOMs: 1. **Assess your current state** – Create a CSF 2.0 Current Profile. Be honest about where your supply chain risk management practices stand today. 2. **Define your target** – Determine what tier and profile you're targeting, and which outcomes are highest priority. 3. **Start with IDENTIFY** – You can't protect, detect, or govern what you don't know about. Add SBOM generation to your CI/CD pipelines using the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) and build your software asset inventory. 4. **Enable DETECT** – Ingest SBOMs into [sbomify](https://sbomify.com) and enable continuous vulnerability monitoring. 5. **Formalize GOVERN** – Establish SBOM policies, procurement requirements, and vulnerability response SLAs. 6. **Iterate** – CSF 2.0 is explicitly designed for continuous improvement. Start where you are and build capability over time. For more on the role of SBOMs in cybersecurity programs, see our guide on [the role of SBOMs in cybersecurity](/2026/02/08/sbom-cybersecurity-role/). For the full CSF 2.0 documentation and supplementary resources, visit [NIST's official website](https://www.nist.gov/cyberframework). --- # What Is a CBOM? The Cryptography Bill of Materials Explained URL: https://sbomify.com/2024/04/10/future-proofing-cybersecurity-with-the-cryptography-bill-of-materials-cbom/ Date: 2024-04-10 Description: What is a CBOM? The Cryptography Bill of Materials inventories every cryptographic asset in your software – algorithms, keys, certificates, and protocols. Learn how CBOMs prepare organizations for the post-quantum transition. Organizations know what software libraries they depend on – or at least they _should_, if they maintain [SBOMs](/what-is-sbom/). But ask most organizations what cryptographic algorithms they use, what key lengths protect their data, or which certificates expire next month, and the answer is usually silence. This blind spot is about to become critical: NIST finalized its first [post-quantum cryptography standards](https://csrc.nist.gov/projects/post-quantum-cryptography) in August 2024, starting a migration that will touch every system that uses public-key cryptography. You cannot migrate what you cannot see. A **CBOM (Cryptography Bill of Materials)** is the answer. Defined as a capability of the [CycloneDX](https://cyclonedx.org/capabilities/cbom/) standard, a CBOM is a structured inventory of every cryptographic asset in your software: algorithms, key lengths, certificates, protocols, and their usage contexts. Just as an SBOM makes your software composition visible, a CBOM makes your cryptographic posture visible – and visibility is the prerequisite for action. ## What Is Inside a CBOM? A CBOM catalogs cryptographic assets across several categories: ### Algorithms and Parameters - **Algorithm name** – The specific cryptographic algorithm (e.g., AES-256-GCM, RSA-2048, SHA-384, ECDSA P-256) - **Key length** – The size of cryptographic keys in use - **Mode of operation** – How the algorithm is applied (e.g., CBC, GCM, CTR for block ciphers) - **Usage context** – What the algorithm protects (data at rest, data in transit, authentication, digital signatures) ### Certificates - **Certificate authority** – Who issued the certificate - **Subject and issuer** – What entity the certificate identifies - **Validity period** – Expiration dates for proactive renewal - **Signature algorithm** – The algorithm used to sign the certificate (critical for quantum readiness) ### Protocols - **Protocol version** – TLS 1.2, TLS 1.3, SSH, IPsec, etc. - **Cipher suites** – The specific combination of algorithms negotiated for each connection - **Deprecated configurations** – Protocols or cipher suites that are no longer considered secure (e.g., TLS 1.0, RC4, 3DES) ### Key Management - **Key storage locations** – HSMs, key vaults, file-based stores - **Key rotation policies** – How often keys are rotated and by what mechanism - **Key lifecycle state** – Active, expired, revoked, or compromised ## Why CBOMs Matter Now ### The Post-Quantum Transition In August 2024, NIST published three finalized post-quantum cryptography standards: - **[FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final)** – Module-Lattice-Based Key-Encapsulation Mechanism, replacing key exchange mechanisms like ECDH - **[FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final)** – Module-Lattice-Based Digital Signature Algorithm, replacing signature schemes like RSA and ECDSA - **[FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final)** – Stateless Hash-Based Digital Signature Algorithm, providing an alternative signature scheme based on different mathematical assumptions These standards mark the beginning of the largest cryptographic migration in computing history. Every system that uses RSA, ECDSA, ECDH, or other public-key algorithms vulnerable to quantum attack will need to transition to post-quantum alternatives. NIST's guidance calls for beginning migration immediately, with a target of deprecating vulnerable algorithms by 2035. The scale of this migration is staggering. It affects TLS configurations, code signing, certificate authorities, VPNs, database encryption, API authentication, and every other system that relies on public-key cryptography. Without a CBOM, organizations have no systematic way to identify what needs to change. ### Harvest-Now, Decrypt-Later The most urgent reason to act now – even before quantum computers can break current encryption – is the **harvest-now, decrypt-later (HNDL)** threat. Nation-state adversaries and sophisticated attackers are already capturing encrypted network traffic and storing it, with the expectation that future quantum computers will be able to decrypt it. Data with long-term confidentiality requirements is particularly at risk: - Government classified information - Medical records (HIPAA mandates decades of retention) - Financial transactions and trade secrets - Intellectual property and research data For this data, the threat window is not "when quantum computers arrive" – it is _now_. A CBOM helps identify which systems handle long-lived sensitive data and which cryptographic algorithms protect it, enabling prioritized migration to quantum-resistant alternatives. ### Cryptographic Agility Even outside the quantum context, organizations regularly need to retire compromised or deprecated algorithms. SHA-1, MD5, RC4, DES, and TLS 1.0/1.1 have all been deprecated over the past decade, and each deprecation required organizations to find and update every system using the affected algorithm. Without a CBOM, this is an ad-hoc, error-prone process. **Cryptographic agility** – the ability to quickly swap out cryptographic algorithms across your infrastructure – depends on knowing exactly what is deployed where. A CBOM provides this foundation. ## CBOMs and SBOMs CBOMs and [SBOMs](/what-is-sbom/) are complementary inventories that address different dimensions of software transparency. | | SBOM | CBOM | | -------------------- | -------------------------------------------------------------- | ----------------------------------------------------- | | **Inventories** | Software components (libraries, packages) | Cryptographic assets (algorithms, keys, certificates) | | **Primary use case** | Vulnerability management, license compliance | Cryptographic risk assessment, quantum migration | | **Format** | [SPDX, CycloneDX](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/) | CycloneDX | | **Answers** | "What's in my software?" | "What crypto does my software use?" | CycloneDX supports both in the same document. An organization generating CycloneDX SBOMs can extend them to include cryptographic asset data, producing a unified inventory that covers both component composition and cryptographic posture. For organizations managing SBOMs with [sbomify](https://sbomify.com), adding CBOM data to the same CycloneDX documents means cryptographic assets become part of the same management, monitoring, and sharing workflow already in place for software components. ## Generating a CBOM ### Automated Discovery Several tools support automated cryptographic asset discovery: - **[CycloneDX CBOM tools](https://cyclonedx.org/capabilities/cbom/)** – Generate CycloneDX-formatted CBOMs by analyzing dependencies and configurations - **IBM Quantum Safe tools** – Scan codebases and running systems for cryptographic usage patterns - **Certificate inventory tools** – Tools like `certbot`, `openssl`, and cloud provider APIs can enumerate certificates across infrastructure ### Manual Inventory For many organizations, the first CBOM begins as a manual inventory: 1. **TLS configurations** – Audit web servers, load balancers, and API gateways for supported protocol versions and cipher suites 2. **Certificate stores** – Enumerate all certificates, their issuers, expiration dates, and signature algorithms 3. **Key management systems** – Inventory HSMs, cloud KMS services (AWS KMS, Azure Key Vault, GCP Cloud KMS), and application-level key stores 4. **Cryptographic library dependencies** – Check your SBOM for libraries like OpenSSL, BoringSSL, libsodium, Bouncy Castle, and their configured algorithms 5. **Data-at-rest encryption** – Document database encryption, disk encryption, and backup encryption configurations ### Ongoing Maintenance Like SBOMs, CBOMs should be treated as living documents. Certificate expirations, algorithm deprecations, and new deployments all require CBOM updates. Integrate CBOM generation into your CI/CD pipeline alongside SBOM generation for continuous visibility. ## The Regulatory Landscape Cryptographic transparency is gaining regulatory attention: - **NSA CNSA 2.0** – The Commercial National Security Algorithm Suite 2.0 sets timelines for U.S. national security systems to transition to quantum-resistant algorithms, starting in 2025 - **[Executive Order 14028](/compliance/eo-14028/)** and subsequent White House memoranda on quantum computing direct federal agencies to inventory cryptographic systems and develop migration plans - **[EU Cyber Resilience Act](/compliance/eu-cra/)** requires products with digital elements to implement "appropriate" cryptographic protection – documenting that cryptography via CBOMs supports compliance - **PCI DSS 4.0** requires inventories of cryptographic algorithms and key management practices for payment card environments Organizations that proactively build CBOMs will be ahead of the compliance curve as these requirements mature. ## Frequently Asked Questions ### What is a CBOM? A CBOM (Cryptography Bill of Materials) is a structured inventory of all cryptographic assets used in a piece of software, including algorithms, key lengths, certificates, protocols, and their usage contexts. It is defined as a capability of the [CycloneDX](https://cyclonedx.org/capabilities/cbom/) SBOM standard and enables organizations to identify cryptographic risks, plan quantum-resistant migrations, and maintain cryptographic agility. ### How is a CBOM different from an SBOM? An [SBOM](/what-is-sbom/) inventories software components (libraries, packages, dependencies). A CBOM inventories cryptographic assets (algorithms, keys, certificates, protocols). They are complementary: an SBOM tells you what software you have, a CBOM tells you what cryptography that software uses. CycloneDX supports both in the same format. ### Why do I need a CBOM now? Quantum computers capable of breaking RSA and elliptic curve cryptography are expected within the next decade. NIST finalized its first post-quantum cryptography standards (ML-KEM, ML-DSA, SLH-DSA) in August 2024. The migration will take years, and the first step is knowing what cryptography you use today. CBOMs provide that inventory. ### What is the harvest-now-decrypt-later threat? Harvest-now-decrypt-later (HNDL) is a strategy where adversaries capture encrypted data today with the intention of decrypting it once quantum computers become available. Data with long-term confidentiality requirements (state secrets, medical records, financial data) is particularly at risk. CBOMs help identify which systems use vulnerable algorithms so migration can be prioritized. ### How do I generate a CBOM? [CycloneDX tools](https://cyclonedx.org/capabilities/cbom/) can generate CBOMs by analyzing codebases for cryptographic library usage, certificate stores, and protocol configurations. IBM's Quantum Safe toolkit provides automated scanning. For many organizations, the first CBOM is compiled manually by inventorying TLS configurations, key management systems, and cryptographic library dependencies. --- # How to create an SBOM URL: https://sbomify.com/2024/04/07/how-to-create-an-sbom/ Date: 2024-04-07 Description: Step-by-step guide to generating SBOMs using Docker CLI and GitHub tools including the command line interface, Dependency Graph, and REST API.

📘 Updated Guides Available

This article provides a general overview, but we now have more comprehensive and up-to-date guides available. Check out our SBOM Generation Guides for language-specific instructions covering Python, JavaScript, Go, Rust, Java, Docker, and many more.

In the evolving landscape of software development and cybersecurity, the importance of creating a Software Bill of Materials (SBOM) has never been more critical. As organizations and developers seek to enhance transparency and security in their software supply chain, understanding how to generate an SBOM efficiently becomes a foundational step. This article serves as a comprehensive guide on how to create, generate, and build an SBOM, ensuring that you're equipped with the knowledge to improve your software's integrity and trustworthiness. By detailing the process of generating an SBOM, we aim to empower developers and organizations alike to take proactive steps in securing their software ecosystems against vulnerabilities and threats. ### Using Docker If you are using a recent version of Docker Engine, you can generate an SBOM directly from the `docker` command. While this feature is still [flagged as experimental](https://docs.docker.com/engine/sbom/), it is indeed supported out of the box. To do this, simply run: ```bash $ docker sbom \ –-format spdx-json \ nginx:latest > docker-sbom.json ``` This will generate a file called `docker-sbom.json`, which is an SBOM for the `nginx:latest` docker image in your current directory. In this example, we're using the [SPDX](https://spdx.dev) SBOM format, but other formats are supported, including: - syft-json - cyclonedx-xml - cyclonedx-json - github-0-json - spdx-tag-value - pdx-json - table - text The default value is table. ### Using GitHub GitHub also supports generating SBOM in a few ways: - Using the GitHub Command Line Interface - Using the Export feature in Dependency Graph - Using the RESTful API Note that GitHub currently only allows you to export SBOMs in the SPDX format. #### Using the Command Line Interface To enable the SBOM feature in the GitHub CLI, you need to first install the SBOM extension: ```bash gh ext install advanced-security/gh-sbom ``` With the extension installed, you can generate an SBOM directly from your terminal using the `gh sbom` command. To use this, simply jump into the GitHub repository you want to generate an SBOM for, and then run: ```bash gh sbom > my-sbom.json ``` This will generate a file called `my-sbom.json` in your current working directory. There's also a GitHub Actions workflow [available](https://github.com/marketplace/actions/sbom-generator-action) that allows you to build the SBOM during your CI/CD run. #### Using Dependency Graph Navigate to your GitHub repository in your browser. Then go to: - Insights - Dependency Graph - Export SBOM #### Using the RESTful API GitHub exposes the same functionality using this [RESTful API](https://docs.github.com/en/rest/dependency-graph/sboms?apiVersion=2022-11-28). ``` ``` --- # Elevating M&A Due Diligence with SBOMs: A Guide for Corporate Strategists URL: https://sbomify.com/2024/04/07/elevating-ma-due-diligence-with-sboms-a-guide-for-corporate-strategists/ Date: 2024-04-07 Description: How SBOMs accelerate M&A due diligence compared to traditional source code analysis with Black Duck, offering faster evaluation, IP protection, and streamlined compliance. In the competitive arena of mergers and acquisitions (M&A), the due diligence phase is a pivotal moment that determines the success or failure of potential deals. Traditionally, evaluating a target company's software assets has relied heavily on tools like Black Duck for in-depth source code analysis. However, the emergence of Software Bill of Materials (SBOMs) is transforming this critical step, offering advantages that legacy tools cannot match. As professionals navigating the complexities of corporate M&A, understanding the strategic value of SBOMs can significantly enhance your due diligence process. ### Accelerated Due Diligence: Seizing Opportunities Faster One of the standout benefits of SBOMs for corporate M&A teams is the dramatic increase in efficiency. While traditional source code review processes are thorough, they are also time-intensive, potentially delaying deal progression. SBOMs, by contrast, provide immediate insights into a software's composition, vulnerabilities, and dependencies, enabling a faster evaluation period. This speed is not just about convenience; it's a strategic advantage, allowing your company to move quickly on acquisition opportunities before competitors. ### Safeguarding Intellectual Property: Minimizing Risks For corporations, protecting intellectual property (IP) during the M&A process is paramount. Traditional due diligence methods, which require access to the target's source code, pose inherent risks of IP exposure or theft. SBOMs offer a solution by relying solely on metadata for their analysis. This approach ensures that your team can assess the software assets of a target company without the need to expose sensitive code, reducing the risk of compromising IP and fostering a trust-based environment for negotiations. ### Enhanced Visibility for Strategic Decision-Making SBOMs provide a level of visibility into software assets that surpasses what traditional tools offer. By detailing every component of a software's ecosystem, including third-party and open-source elements, SBOMs enable a deeper understanding of potential security risks, compliance issues, and operational dependencies. This comprehensive insight is crucial for making strategic decisions, ensuring that your company fully understands the assets it is acquiring and any associated risks or opportunities. ### Streamlining Compliance and Mitigating Risks In the current regulatory landscape, ensuring compliance with software licenses and security standards is essential. SBOMs are instrumental in this regard, helping corporate M&A teams to quickly verify that acquired software meets all legal and regulatory requirements. Additionally, the early identification of vulnerabilities and dependencies facilitated by SBOMs allows for proactive risk management, safeguarding the investment and facilitating a smoother integration post-acquisition. ### Conclusion The role of SBOMs in modernizing the M&A due diligence process cannot be overstated. For corporate strategists and M&A professionals, they represent a powerful tool that not only accelerates due diligence but also enhances the protection of intellectual property, improves strategic decision-making, and streamlines compliance and risk management. As the digital landscape evolves, the integration of SBOMs into your M&A toolkit is not merely an upgrade – it's a strategic necessity. Embracing SBOMs positions your company to capitalize on acquisition opportunities with greater speed, security, and confidence. In the competitive world of corporate M&A, staying ahead means adopting the most advanced and efficient tools available – SBOMs are your gateway to that edge. --- # Elevating M&A Due Diligence with sbomify's SBOM Management URL: https://sbomify.com/2024/04/03/elevating-ma-due-diligence-with-sbomifys-sbom-management/ Date: 2024-04-03 Description: How sbomify streamlines M&A due diligence by providing comprehensive software asset evaluation, vulnerability assessment, and license compliance checking. In the world of mergers and acquisitions (M&A), the stakes are high, and the margin for error is low. A critical aspect of the M&A due diligence process is the comprehensive evaluation of a target company's software assets. This is where potential vulnerabilities and compliance issues can lurk, potentially derailing deals or inviting future liabilities. Enter sbomify, a transformative SBOM management solution designed to elevate the due diligence process by offering an unparalleled level of insight into a company's software dependencies. ### Streamlining Software Asset Evaluation sbomify offers acquirers a robust platform for the thorough auditing of software components within a target company. This tool is essential for identifying vulnerabilities that could pose security risks or uncovering software that might not comply with critical licensing requirements. With sbomify, companies engaged in M&A activities can conduct detailed and efficient evaluations, ensuring no stone is left unturned. ### Facilitating Informed Decision-Making The strength of sbomify lies in its ability to provide a clear and comprehensive view of the software ecosystem of a potential acquisition. By leveraging sbomify, acquirers gain access to a detailed inventory of all software components, complete with vulnerability assessments and license compliance checks. This level of detail supports informed decision-making, allowing companies to assess risks and compliance with a degree of accuracy previously unattainable. ### Reducing Risks and Ensuring Compatibility M&A transactions often involve integrating diverse technological platforms and software products. sbomify aids in identifying potential compatibility issues or licensing constraints that could complicate these integrations. By offering insights into the software licenses and dependencies, sbomify helps acquirers navigate the complex landscape of software compliance, reducing the risk of future legal or operational challenges. ### A New Paradigm in M&A Due Diligence sbomify is not just a tool; it's a paradigm shift in how due diligence is conducted in the context of M&A. The platform's ability to provide deep insights into a company's software assets transforms due diligence from a checkbox activity into a strategic advantage. With sbomify, companies can proceed with their M&A activities with a higher level of confidence, knowing that they are making decisions based on comprehensive and accurate information about their software assets. In the dynamic and often uncertain world of M&A, sbomify stands out as a beacon of clarity and reliability. It empowers acquirers to perform due diligence with an unprecedented level of thoroughness, ensuring that software vulnerabilities and compliance issues are identified and addressed before they can become problems. With sbomify, companies can look forward to smoother integrations, secure in the knowledge that their new acquisitions are technologically sound and compliant. --- # Streamlining Open Source License Compliance in M&A: Unveiling the sbomify Advantage URL: https://sbomify.com/2024/04/03/streamlining-open-source-license-compliance-in-ma-unveiling-the-sbomify-advantage/ Date: 2024-04-03 Description: Learn how sbomify simplifies open source license compliance during M&A due diligence by automating SBOM analysis to identify GPLv3 and other non-permissive licenses. In the intricate arena of mergers and acquisitions (M&A) within the tech industry, the due diligence process is paramount, especially when evaluating the acquisition of software companies. One of the significant challenges encountered is navigating the complexities of open source licenses, which, if not thoroughly understood and managed, can introduce unforeseen complications. Licenses such as the GNU General Public License version 3 (GPLv3) along with other non-permissive licenses pose specific challenges due to their requirements, which might restrict the proprietary use of software. This is where sbomify emerges as a crucial tool, offering an innovative solution to effortlessly identify and manage these licenses. ### The Challenge at Hand The integration of open source software (OSS) into commercial products is a common practice due to its benefits such as reduced development costs and accelerated innovation. However, the diversity of open source licenses, from permissive to non-permissive, necessitates meticulous management to ensure compliance. Non-permissive licenses, including GPLv3, AGPL, and LGPL, require that modifications to the open source code be made publicly available under the same license, potentially affecting proprietary software integration. In the context of M&A, identifying such licenses early in the due diligence process is critical to avoid legal and operational risks. ### The Comprehensive Solution Offered by sbomify sbomify leverages the power of Software Bill of Materials (SBOMs) to provide a clear overview of all software components in a product, including their associated licenses. This automated approach delivers several key benefits for M&A due diligence: - **Automated License Detection:** sbomify scans and identifies all types of open source licenses within SBOMs, including permissive and non-permissive ones, ensuring a thorough compliance check. - **Insight into Compliance Risks:** The platform highlights potential compliance issues, aiding acquirers in understanding the implications of integrating the target's software assets into their portfolio. - **Efficiency in the Due Diligence Process:** By automating the detection and reporting process, sbomify significantly accelerates the due diligence, enabling faster and more informed decision-making. - **Detailed Reporting for Compliance:** sbomify generates comprehensive reports that detail compliance status and risks, valuable for negotiations, internal audits, and ongoing compliance monitoring. ### Why Choose sbomify? sbomify distinguishes itself through its user-friendly design, scalability, and commitment to continuous monitoring, making it an indispensable tool for companies undergoing M&A activities. It is equipped to manage the complexities of modern software portfolios, ensuring companies can navigate the landscape of open source licensing with confidence. ### Conclusion For businesses in the tech sector considering M&A activities, understanding and managing the complexities of open source licensing is crucial. sbomify offers a streamlined, automated solution to tackle the challenges of compliance with both permissive and non-permissive open source licenses. By integrating sbomify into their due diligence strategy, businesses can ensure a smooth acquisition process, safeguarding their investments and embracing the benefits of open source software while mitigating legal and operational risks. --- # The Time is Now: Embracing SBOMs in an Era of Enhanced Cybersecurity Standards URL: https://sbomify.com/2024/04/03/the-time-is-now-embracing-sboms-in-an-era-of-enhanced-cybersecurity-standards/ Date: 2024-04-03 Description: Why 2024-2026 is the critical window for SBOM adoption. From EO 14028 and the EU Cyber Resilience Act to PCI DSS 4.0 and FDA guidance, regulatory requirements are converging – and the tooling is ready. When the concept of Software Bills of Materials first entered mainstream cybersecurity discourse, it was largely aspirational – a good practice that forward-thinking organizations might adopt. That era is over. SBOMs have moved from recommendation to requirement, driven by a convergence of regulatory mandates, industry standards, and a tooling ecosystem that has matured enough to make adoption practical for organizations of any size. The question is no longer _whether_ to adopt SBOMs, but how quickly you can integrate them into your existing workflows. ## The Regulatory Landscape Has Changed ### Executive Order 14028: The U.S. Federal Mandate The U.S. [Executive Order 14028](/compliance/eo-14028/) on Improving the Nation's Cybersecurity marked a turning point for SBOM adoption. It requires software vendors selling to the federal government to provide SBOMs, and directs NIST and CISA to define minimum elements and guidelines for SBOM production and consumption. The implementing guidance has evolved since 2021. EO 14144 (January 2025) initially strengthened attestation requirements, but EO 14306 (June 2025) rescinded key portions, and OMB Memorandum M-26-05 (January 2026) shifted from a centralized attestation mandate to an agency-led, risk-based approach. The core outcome: EO 14028's SBOM and supply chain security principles remain in effect, but each agency now tailors its assurance requirements to its specific risk profile. M-26-05 specifically encourages SBOM requirements for cloud service providers. The impact extends far beyond federal contractors. EO 14028 established the expectation that software transparency is a baseline requirement, not a differentiator. Private-sector procurement teams increasingly include SBOM requirements in their contracts, following the federal government's lead. ### EU Cyber Resilience Act: A Global Standard The [EU Cyber Resilience Act (CRA)](/compliance/eu-cra/) (Regulation EU 2024/2847) goes further than any previous regulation. It is binding EU law that requires manufacturers placing products with digital elements on the EU market to identify and document components and dependencies, including by drawing up a software bill of materials. Unlike U.S. guidance documents, the CRA is enforceable legislation – organizations selling software in European markets need SBOM capabilities in place now. The CRA is significant because of its broad scope: it applies to manufacturers, importers, and distributors of products with digital elements – encompassing commercial software, IoT devices, and embedded systems. The CRA requires SBOMs covering at least top-level dependencies in a commonly used, machine-readable format. It also mandates vulnerability handling processes, meaning SBOMs must be actively monitored, not just generated and filed. Market surveillance authorities can request SBOMs as part of conformity assessment. ### PCI DSS 4.0: Payment Industry Requirements [PCI DSS v4.0.1](/compliance/pci-dss/) Requirement 6.3.2 requires maintaining an inventory of bespoke and custom software, including third-party software components incorporated into that software, to facilitate vulnerability and patch management. This requirement became mandatory after March 31, 2025. While PCI DSS doesn't mandate SBOMs by name, Requirement 6.3.2 is effectively an SBOM requirement for custom software in cardholder data environments. ### FDA Medical Device Guidance The FDA now requires SBOMs as part of pre-market submissions for medical device software. This requirement recognizes that medical devices increasingly depend on open source components, and that patient safety depends on knowing exactly what software is running on those devices. ### UK Code of Practice for Software Vendors The UK's Software Security Code of Practice adds another jurisdiction to the growing list of governments that expect software transparency. While currently voluntary, it signals the direction of UK regulation and aligns with the broader global trend. ## The Tooling Ecosystem Is Ready Two years ago, generating and managing SBOMs required significant manual effort. Today, the tooling ecosystem is mature, integrated into the platforms developers already use, and largely free. ### Native Platform Support **GitHub** provides SBOM generation through its Dependency Graph, producing SPDX-format SBOMs directly from repository dependency data. This gives millions of developers a zero-configuration starting point for SBOM generation. **Docker Scout** analyzes container images and generates SBOMs, providing vulnerability analysis alongside image builds. For containerized applications, this means SBOM generation is built into the deployment pipeline. ### Open Source Generators The open source ecosystem offers mature SBOM generation tools for every major language and package ecosystem: - **[sbomify GitHub Action](https://github.com/sbomify/sbomify-action/)** – Automatically selects the best generator for your stack and enriches the output with metadata from 11 data sources - **[Syft](https://github.com/anchore/syft)** – Generates SBOMs from container images, file systems, and archives - **[Trivy](https://trivy.dev/)** – Aqua Security's multi-purpose scanner with SBOM generation (we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/)) - **[CycloneDX plugins](https://cyclonedx.org/tool-center/)** – Language-specific generators for npm, Maven, pip, Go, and more ### Management and Monitoring Generating an SBOM is only the first step. The real value comes from continuous monitoring – automatically checking your components against vulnerability databases as new CVEs are disclosed. Management platforms like [sbomify](https://sbomify.com) provide: - Centralized SBOM storage with [SBOM hierarchy](/features/sbom-hierarchy/) for complex products - Continuous vulnerability monitoring via Google OSV - License compliance checking - A [Trust Center](/features/trust-center/) for sharing SBOMs and compliance documents with customers - Enrichment from 11 data sources to fill gaps in generated SBOMs ## Why the Timing Is Critical ### Regulations Are Converging For the first time, multiple major regulatory frameworks are requiring SBOMs simultaneously. Organizations that sell software across jurisdictions – the U.S., EU, and UK – face overlapping requirements that all point to the same capability: transparent, machine-readable documentation of software components. Building this capability once satisfies multiple requirements. ### Cyber Threats Demand Visibility Supply chain attacks continue to grow in sophistication and frequency. The lesson of Log4Shell – that you need to know what's in your software _before_ a vulnerability is disclosed – has been reinforced repeatedly. SBOMs provide the visibility needed for rapid vulnerability response, turning days of investigation into seconds of database queries. For more on this topic, see our guide on [the role of SBOMs in cybersecurity](/2026/02/08/sbom-cybersecurity-role/). ### Market Differentiation Organizations that can provide SBOMs on demand – through a self-service portal like sbomify's [Trust Center](/features/trust-center/) – demonstrate a maturity that procurement teams increasingly expect. This is especially true in regulated industries (healthcare, finance, defense) where software transparency is becoming a selection criterion. ### The Cost of Waiting Implementing SBOM processes under regulatory deadline pressure is significantly more expensive and disruptive than doing it proactively. Organizations that adopt SBOMs now can iterate on their processes, train their teams, and resolve integration challenges at their own pace – rather than scrambling to meet a compliance deadline. ## Getting Started The path from zero to continuous SBOM monitoring is shorter than most organizations expect: 1. **Add SBOM generation to CI/CD** – The [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) can be added to an existing workflow in minutes. It automatically detects your technology stack and generates a compliance-ready SBOM. 2. **Ingest into a management platform** – Upload generated SBOMs to [sbomify](https://sbomify.com) for centralized storage, vulnerability monitoring, and compliance tracking. 3. **Enable continuous monitoring** – sbomify automatically cross-references your components against vulnerability databases, alerting you to new risks as they're disclosed. 4. **Share with stakeholders** – Use sbomify's Trust Center to provide customers, auditors, and partners with on-demand access to your SBOMs and compliance documents. For a complete walkthrough, see the [sbomify zero-to-hero guide](/zero-to-hero/). For details on how SBOMs support vulnerability detection workflows, see our guide on [SBOM scanning for vulnerability detection](/2026/02/01/sbom-scanning-vulnerability-detection/). ## Conclusion The convergence of regulatory mandates, mature tooling, and escalating supply chain threats has made SBOM adoption an immediate priority – not a future consideration. The infrastructure exists, the standards are defined, and the regulatory clock is ticking. Organizations that act now position themselves for compliance, security, and competitive advantage. Those that wait risk scrambling under deadline pressure. The time to embrace SBOMs is unequivocally now. --- # SBOM Management for Software Vendors: A Complete Guide to sbomify URL: https://sbomify.com/2024/04/03/sbomify-a-paradigm-shift-for-software-vendors-in-sbom-management/ Date: 2024-04-03 Description: How software vendors use sbomify to generate compliance-ready SBOMs in CI/CD, enrich them with 11 data sources, attest with GitHub Actions, and share via Trust Center – all from an open source GitHub Action. Software vendors face growing pressure to provide Software Bills of Materials to their customers. Regulatory frameworks like [Executive Order 14028](/compliance/eo-14028/) and the [EU Cyber Resilience Act](/compliance/eu-cra/) require it. Enterprise procurement contracts demand it. And security-conscious customers expect it as a baseline indicator of software transparency. The challenge is not whether to produce SBOMs – it's how to do it without creating a manual process that slows down releases, produces incomplete data, and falls out of date the moment a dependency changes. sbomify solves this by making SBOM generation, enrichment, attestation, and sharing a fully automated part of the CI/CD pipeline. ## The Open Source sbomify GitHub Action The foundation of sbomify's vendor workflow is the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) – an open source action that integrates directly into GitHub Actions workflows. It handles the full SBOM generation process: 1. **Automatic ecosystem detection** – The action analyzes your repository and identifies the technology stack (Node.js, Python, Go, Java, Rust, .NET, Ruby, and more) 2. **Best-tool selection** – Rather than requiring you to choose and configure an SBOM generator, the action selects the most accurate generator for your ecosystem 3. **Format support** – Generates SBOMs in CycloneDX or SPDX format, covering both dominant standards 4. **CI/CD native** – Runs as part of your existing build pipeline, generating an SBOM with every build or release For teams using GitHub Actions, adding SBOM generation is typically a matter of adding a few lines to an existing workflow file. For GitLab CI, Bitbucket Pipelines, or any other CI/CD system, sbomify provides a Docker image (`sbomifyhub/sbomify-action`) that runs anywhere. For a complete walkthrough, see the [sbomify zero-to-hero guide](/zero-to-hero/). ## Enrichment from 11 Data Sources A common problem with SBOM generators is that they produce incomplete SBOMs. A package manager knows the component name and version, but often lacks supplier information, license details, or package descriptions – fields that regulations like NTIA minimum elements require. sbomify addresses this with automatic enrichment. When an SBOM is ingested, sbomify cross-references every component against 11 data sources to fill in missing information: - **License resolution** – Identifies the license for components where the generator couldn't determine it, resolving ambiguous or multi-licensed packages - **Supplier identification** – Maps components to their maintainers and publishing organizations - **Package metadata** – Adds descriptions, homepage URLs, and repository links - **Vulnerability cross-referencing** – Checks every component against Google OSV and other vulnerability databases The result is a compliance-ready SBOM that meets NTIA minimum elements out of the box, without manual curation. ## SBOM Attestation Trust in an SBOM depends on knowing that it hasn't been tampered with and that it genuinely came from the claimed source. When using GitHub Actions, the sbomify action pairs naturally with GitHub's [`attest-build-provenance`](https://github.com/actions/attest-build-provenance) action to create a [SLSA build provenance](https://slsa.dev/spec/v1.0/provenance) predicate in [in-toto](https://github.com/in-toto/attestation/tree/main/spec/v1) format. This provides: - **Integrity** – Cryptographic proof that the SBOM hasn't been modified since it was generated - **Provenance** – Verification that the SBOM was produced by a specific CI/CD workflow, not manually assembled - **Independent verification** – Anyone can verify the attestation using `gh attestation verify`, removing the need to trust sbomify or any other intermediary The workflow is straightforward: the sbomify action generates the SBOM and writes it to disk, then the `attest-build-provenance` action signs it. For details and a working example, see the [attestation guide](/2024/10/31/github-action-update-and-attestation/). For regulated industries and high-assurance customers, attested SBOMs are becoming a baseline expectation. ## SBOM Hierarchy for Complex Products Real-world software products are rarely a single application with a single dependency tree. A typical SaaS product might include: - A frontend application (React/TypeScript) - Multiple backend services (Go, Python, Java) - A data pipeline (Python/Spark) - Infrastructure definitions (Terraform, Helm charts) - Shared libraries used across services sbomify's [SBOM hierarchy](/features/sbom-hierarchy/) organizes this complexity with a two-level structure: - **Product** – The top-level entity that customers purchase or use (e.g., "Acme Platform v3.2") - **Components** – The individual services, deployable units, or dependencies that make up the product This structure means that both vendors and customers can navigate the SBOM at the right level of detail – product-level for procurement decisions and component-level for service-specific risk assessment and vulnerability investigation. ## Trust Center: Professional SBOM Distribution Sharing SBOMs through email attachments or file shares doesn't scale. Customers need self-service access to current SBOMs, and vendors need to control who sees what. The [sbomify Trust Center](/features/trust-center/) solves this with a branded portal that vendors host on their own domain: - **Self-service access** – Customers browse and download current SBOMs without submitting requests - **Automatic updates** – SBOMs refresh with every CI/CD build, so the Trust Center always reflects the latest release - **Compliance documents** – Publish SOC 2 reports, ISO 27001 certificates, pentest summaries, and other compliance artifacts alongside SBOMs - **Branded experience** – The portal uses the vendor's branding and can be hosted on their domain (e.g., `trust.yourcompany.com`) - **Access control** – Control which customers and partners can access which documents For vendors, the Trust Center eliminates the operational overhead of responding to individual SBOM requests while demonstrating security maturity to prospective customers. ## Compliance-Ready by Default sbomify is designed so that vendors don't need to understand every regulatory requirement in detail. The platform's defaults produce SBOMs that meet: - **NTIA minimum elements** – Supplier, component name, version, dependency relationships, author, timestamp - **[EO 14028](/compliance/eo-14028/) requirements** – Machine-readable format, complete dependency inventory, automated generation - **[EU CRA](/compliance/eu-cra/) obligations** – Component documentation, vulnerability handling, update mechanisms - **[PCI DSS 4.0](/compliance/pci-dss/) inventory requirements** – Software component inventory with version tracking By automating compliance into the generation and enrichment process, sbomify lets vendors focus on building software rather than interpreting regulatory text. ## Self-Hostable Deployment For organizations with strict data residency requirements or air-gapped environments, sbomify supports self-hosted deployment. This means SBOM data never leaves your infrastructure – the same generation, enrichment, and management capabilities are available on-premises. The sbomify GitHub Action remains open source regardless of deployment model, ensuring that the core generation workflow is transparent and auditable. ## Getting Started as a Vendor The path from no SBOMs to fully automated SBOM management is straightforward: 1. **Add the sbomify GitHub Action** to your CI/CD workflow. It detects your stack and generates SBOMs automatically. 2. **Connect to sbomify** for enrichment, vulnerability monitoring, and centralized management. 3. **Organize with SBOM hierarchy** – Map your product's services and dependencies into the product → component structure. 4. **Set up your Trust Center** – Give customers self-service access to your SBOMs and compliance documents. 5. **Enable attestation** – Pair with GitHub's `attest-build-provenance` action for cryptographic SBOM verification. For a step-by-step walkthrough, see the [zero-to-hero guide](/zero-to-hero/). For integration details across different ecosystems, see the [integrations page](/features/integrations/). Most teams go from zero to continuous SBOM generation in less than a day. The combination of open source tooling, automated enrichment, and a managed platform means that SBOM management no longer requires dedicated headcount or specialized expertise. --- # Navigating the Landscape of Open Source Licenses URL: https://sbomify.com/2024/04/03/navigating-the-landscape-of-open-source-licenses/ Date: 2024-04-03 Description: Comprehensive guide to open source licenses including MIT, Apache 2.0, GPL, BSD, MPL, and more. Learn the differences between permissive and copyleft licenses and how SBOMs help with license compliance. Open source software forms the backbone of modern applications, from the smallest utilities to the infrastructure running the largest data centers. Studies consistently show that 70-90% of a typical application consists of open source components. The licenses under which this software is released determine how it can be used, integrated, and distributed – and getting license compliance wrong can have serious legal and business consequences. This guide covers the most important open source licenses, organized by category, with practical guidance on commercial compatibility. If you're building software that incorporates open source dependencies – and you almost certainly are – understanding these licenses is essential. ## Why Licenses Matter for Software Supply Chain Security License compliance is a supply chain concern. When your application depends on hundreds of open source packages, each with its own license, manually tracking obligations becomes impossible. A single copyleft dependency buried three levels deep in your dependency tree can create unexpected obligations for your entire application. This is where [Software Bills of Materials](/what-is-sbom/) become critical. An SBOM lists every component in your software along with its license, making automated compliance checking possible. Tools like [sbomify](https://sbomify.com) enrich SBOMs with license data from multiple sources, automatically flagging conflicts and compliance risks before they become legal problems. ## Permissive Licenses Permissive licenses impose minimal restrictions on how software can be used, modified, and redistributed. They are the most commercially friendly category and are widely used in both open source and proprietary software. ### MIT License One of the most popular open source licenses. It allows almost unrestricted freedom to use, modify, and distribute the licensed software, provided that the original license and copyright notice are included with any substantial portions of the software. **Commercial compatibility:** Highly compatible. Its permissiveness makes it favorable for commercial use without imposing significant legal constraints. For a deep dive, see our [MIT License guide](/2026/01/22/mit-license-guide/). ### Apache License 2.0 Similar to the MIT License in its permissiveness, the Apache License also provides an express grant of patent rights from contributors to users. It allows for commercial use, modification, and distribution of the licensed software. **Commercial compatibility:** Generally considered commercially friendly. It requires explicit attribution and provides an explicit grant of patent rights, reducing legal risks for commercial applications. See our [Apache License 2.0 guide](/2026/01/07/apache-license-2-guide/) for details. ### BSD Licenses (2-Clause and 3-Clause) The BSD licenses are permissive, similar to the MIT License. The 2-clause license is very straightforward, allowing for almost unrestricted use, while the 3-clause license adds a non-endorsement clause, preventing the use of the licensor's name to promote derived products without permission. **Commercial compatibility:** Both are considered commercially friendly due to their permissiveness and minimal requirements. ### Zlib/libpng License A very permissive license for software libraries that allows modification, distribution, and use in proprietary applications, provided that credit is given to the author. **Commercial compatibility:** Highly compatible with commercial projects due to its minimal restrictions. ## Strong Copyleft Licenses Copyleft licenses require that derivative works be distributed under the same license terms. This ensures that modifications and extensions remain open source, but creates challenges for proprietary software that incorporates copyleft-licensed code. ### GNU General Public License (GPL) Versions 2 and 3 The GPL is the most widely known copyleft license. Any derivative work must be distributed under the same license terms. GPLv3 introduced terms intended to protect against patent aggression and to prevent tivoization (the practice of designing hardware to prevent modifications to the software it runs). **Commercial compatibility:** GPLv3 is often considered commercially challenging because it requires that derivative works be open-sourced under the same license, potentially exposing proprietary code. GPLv2 is seen as slightly more lenient, though still restrictive for proprietary use. For a comprehensive analysis, see our [GPL License guide](/2025/12/22/gpl-license-guide/). ### GNU Affero General Public License (AGPLv3) Similar to GPLv3, but with an additional requirement: if you run a modified program on a server and let other users communicate with it, you must release the modified source code to those users. This closes the "application service provider" loophole in GPLv3 – a critical consideration for SaaS applications. **Commercial compatibility:** The most restrictive of the major open source licenses for commercial use, especially for software offered as a service. ## Weak Copyleft Licenses Weak copyleft licenses strike a middle ground: modifications to the licensed code itself must be shared, but the licensed code can be combined with proprietary software without triggering copyleft obligations on the larger work. ### GNU Lesser General Public License (LGPL) A compromise between the strong copyleft of the GPL and permissive licenses. It allows linking to LGPL libraries in proprietary software without requiring that the proprietary software's source code be released – as long as the LGPL library itself is not modified. **Commercial compatibility:** More commercially friendly than GPL, especially for proprietary software that uses open source libraries without modifying them. ### Mozilla Public License 2.0 (MPL 2.0) A file-level copyleft license that requires modifications to MPL-licensed files to be open-sourced, but allows those files to be combined with proprietary code into a larger work without open-sourcing the proprietary components. **Commercial compatibility:** Commercially friendly for projects that want to ensure improvements to open source code are shared while allowing commercial application development. ### Eclipse Public License (EPL) Similar to the MPL, the EPL requires that modifications to EPL-licensed code be made available under the EPL, but allows proprietary applications to link to EPL-licensed libraries without open-sourcing the proprietary code. **Commercial compatibility:** Generally considered commercially friendly, especially for developers using open source libraries within proprietary applications. ## Special-Purpose and Dual Licenses ### Creative Commons Licenses Creative Commons licenses are not typically used for software but for creative works such as documentation, images, and videos. They range from the most permissive (CC0, essentially public domain) to restrictive forms (CC BY-NC-ND, which prohibits commercial use and derivative works). **Commercial compatibility:** Varies widely. CC0 is fully compatible with commercial use. Restrictive variants like CC BY-NC-ND are unsuitable for commercial projects. ### European Union Public License (EUPL) A strong copyleft license approved by the European Commission. It is compatible with several other licenses including the GPL, allowing integration of EUPL-licensed code with code under those licenses. **Commercial compatibility:** The copyleft nature makes it less commercially friendly for proprietary software, similar to the GPL. However, its cross-license compatibility offers flexibility for open source projects. ### Artistic License 2.0 Originally designed for the Perl programming language, this license allows modified versions of the software to be distributed under a different license or as closed source, provided that certain conditions are met. **Commercial compatibility:** Generally considered commercially friendly, offering flexibility to distribute proprietary versions alongside open source ones. ### Dual Licensing (Redis, MySQL) Some projects use dual licensing: an open source license for community use and a commercial license for proprietary use. Redis uses the BSD license for its core but the Redis Source Available License (RSAL) for certain modules. MySQL is available under the GPL for open source use or a commercial license from Oracle for proprietary use. **Commercial compatibility:** The open source license applies the usual restrictions (BSD for Redis core, GPL for MySQL), while the commercial license removes those restrictions for a fee. ## License Compliance in Practice Tracking license obligations manually is impractical for modern software with hundreds or thousands of dependencies. Automated tools and processes are essential: 1. **Generate SBOMs in CI/CD** – Use the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/) or similar tools to produce an SBOM at every build. The SBOM captures every component and its license. 2. **Enrich with license data** – sbomify enriches SBOMs with license information from multiple sources, resolving ambiguous or missing license declarations. 3. **Automate policy checks** – Define your organization's license policy (e.g., "no AGPL in production services") and automatically flag violations. 4. **Monitor continuously** – License declarations can change between package versions. Continuous monitoring ensures you catch changes when dependencies are updated. For teams getting started with SBOM-based compliance, the [sbomify zero-to-hero guide](/zero-to-hero/) walks through the complete setup. ## Conclusion The landscape of open source licenses is broad and varied, but understanding the three main categories – permissive, strong copyleft, and weak copyleft – covers the vast majority of what you'll encounter. The key is not just understanding individual licenses but having automated systems to track compliance across your entire dependency tree. SBOMs provide that foundation, and tools like sbomify make the process manageable at scale. **This is not legal advice. Please consult a legal professional before making commercial decisions around licensing.** --- # Enhancing SBOM Management for Software Buyers with sbomify URL: https://sbomify.com/2024/04/03/enhancing-sbom-management-for-buyers-with-sbomify/ Date: 2024-04-03 Description: How sbomify helps CTOs and CISOs manage SBOMs from software vendors – with Trust Center access, vulnerability monitoring, license compliance, and SBOM hierarchy for complex supply chains. CTOs and CISOs responsible for software procurement face a growing challenge: ensuring that the software their organizations depend on is secure, compliant, and transparent about its composition. Traditional approaches to vendor security assessment – questionnaires, annual audits, and PDF reports – don't scale when your organization uses dozens or hundreds of software products, each with thousands of open source dependencies that change with every release. Software Bills of Materials solve this problem by providing machine-readable, continuously updated inventories of everything inside a software product. But having an SBOM is only useful if you can access it, understand it, and act on it. That's where [sbomify](https://sbomify.com) comes in. ## The Buyer's SBOM Challenge Software buyers face several obstacles when trying to use SBOMs for vendor risk management: - **Access:** Getting SBOMs from vendors often means email requests, NDAs, and weeks of back-and-forth. By the time the SBOM arrives, the software has already been updated. - **Complexity:** A single product might contain thousands of components across multiple services and languages. A flat list of dependencies is overwhelming without structure. - **Staleness:** Point-in-time SBOMs become outdated quickly. Vulnerability databases add new entries daily, and vendor releases change the dependency landscape. - **Actionability:** Raw SBOMs don't tell you what to worry about. You need vulnerability correlation, license analysis, and compliance mapping to make informed decisions. sbomify addresses each of these challenges. ## Trust Center: Self-Service SBOM Access The [sbomify Trust Center](/features/trust-center/) is a branded portal that vendors host on their own domain, giving customers self-service access to current SBOMs and compliance documentation. For buyers, this eliminates the procurement bottleneck: - **Always current** – SBOMs are updated automatically with every vendor release, because they're generated in CI/CD and published to the Trust Center as part of the deployment pipeline - **No email required** – Authorized customers access the portal directly, without submitting requests or waiting for vendor responses - **Compliance documents alongside SBOMs** – Vendors can publish SOC 2 reports, ISO 27001 certificates, pentest summaries, and other compliance artifacts in the same portal, creating a single source of truth for vendor security assessment - **Branded and professional** – The Trust Center reflects the vendor's brand and can be hosted on their domain, signaling security maturity to procurement teams For buyers evaluating potential vendors, the existence of a Trust Center is itself a positive signal – it indicates that the vendor has automated SBOM processes and is proactive about transparency. ## SBOM Hierarchy: Understanding Complex Products Modern software products are rarely monolithic. A typical SaaS product might consist of a frontend application, multiple backend services, a data pipeline, and shared libraries – each with its own technology stack and dependency tree. sbomify's [SBOM hierarchy](/features/sbom-hierarchy/) maps this complexity with a clear structure: - **Product** – The top-level entity (e.g., "Acme Platform v3.2") - **Components** – The individual services, deployable units, or dependencies within the product (e.g., "API Service," "Web Frontend," "Auth Service") This hierarchy gives buyers a structured view of software composition rather than a single flat list of thousands of entries. It answers questions like "which service uses this vulnerable library?" and "how many different components in this product use Log4j?" – questions that are critical during incident response. ## Vulnerability Monitoring Generating an SBOM is a snapshot. The real value comes from continuously monitoring those components against vulnerability databases as new CVEs are disclosed. sbomify provides this through integration with [Google OSV](https://osv.dev/) and other vulnerability data sources. For buyers, this means: - **Proactive alerting** – When a new vulnerability is disclosed that affects a component in a vendor's SBOM, you know about it – even before the vendor communicates it - **Risk prioritization** – Not all vulnerabilities are equal. sbomify helps you focus on the ones that matter based on severity, exploitability, and whether the affected component is in a critical path - **Vendor accountability** – With continuous monitoring, you can track how quickly vendors respond to disclosed vulnerabilities in their dependencies For a deeper look at SBOM-based vulnerability workflows, see our guide on [SBOM scanning for vulnerability detection](/2026/02/01/sbom-scanning-vulnerability-detection/). ## License Compliance For many buyers, license compliance is as important as security. Open source licenses impose obligations that can conflict with your organization's policies – a copyleft dependency in a product you embed in your own offering, for example, could create unexpected legal exposure. sbomify enriches SBOMs with license data and flags potential compliance issues: - Identification of all licenses across the dependency tree, including transitive dependencies - Detection of copyleft licenses (GPL, AGPL) that may conflict with proprietary use - Flagging of components with missing or ambiguous license declarations - Policy enforcement against your organization's approved license list ## Sharing and Collaboration SBOM management isn't a solo activity. Security teams, procurement, legal, and engineering all need access to vendor SBOM data, often with different perspectives. sbomify's [sharing and collaboration features](/share-and-collaborate/) support this by allowing teams to share SBOM views, annotate findings, and coordinate vendor communications within a single platform. Vendors can also annotate vulnerabilities directly – for example, marking a flagged CVE as "not applicable" because the affected code path is not used in their product. This kind of contextual information is invaluable for buyers making risk decisions, and it happens within the platform rather than through disconnected email threads. ## What to Look for in Vendor SBOM Practices When evaluating software vendors, consider these indicators of SBOM maturity: 1. **Automated generation** – SBOMs should be generated automatically in CI/CD, not manually assembled. Manual SBOMs are inherently unreliable. 2. **NTIA minimum elements** – The SBOM should include supplier names, component names and versions, dependency relationships, timestamps, and author identification. 3. **Regular updates** – SBOMs should be regenerated with every release. A six-month-old SBOM for actively developed software is effectively useless. 4. **Vulnerability monitoring** – The vendor should be monitoring their own SBOMs for newly disclosed vulnerabilities, not just generating static documents. 5. **Self-service access** – A Trust Center or equivalent portal for on-demand SBOM access signals mature practices and confidence in transparency. ## Getting Started as a Buyer If your organization is starting to incorporate SBOMs into vendor risk management: 1. **Add SBOM requirements to procurement contracts** – Specify that vendors must provide machine-readable SBOMs in SPDX or CycloneDX format, updated with each release. 2. **Use a management platform** – Ingest vendor SBOMs into [sbomify](https://sbomify.com) for centralized visibility, vulnerability monitoring, and compliance checking. 3. **Enable continuous monitoring** – Set up alerts for new vulnerabilities affecting your vendor's components. 4. **Communicate expectations** – Share the [sbomify zero-to-hero guide](/zero-to-hero/) with vendors who need help getting started with SBOM generation. The shift from reactive vendor assessment to continuous, SBOM-driven supply chain monitoring is the most significant improvement available to software procurement teams today. The tools exist, the standards are defined, and the regulatory environment demands it. --- # Demystifying SBOMs: The Backbone of Modern Software Security URL: https://sbomify.com/2024/04/03/demystifying-sboms-the-backbone-of-modern-software-security/ Date: 2024-04-03 Description: What is an SBOM? A Software Bill of Materials is a machine-readable inventory of every component in your software. Learn about SBOM formats (SPDX, CycloneDX), generation tools, vulnerability management, and compliance requirements. When the Log4Shell vulnerability ([CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)) was disclosed in December 2021, organizations around the world scrambled to answer a simple question: _does our software use Log4j?_ For most, the answer took days or weeks of manual investigation across thousands of applications. For the few that maintained [Software Bills of Materials](/what-is-sbom/), the answer took seconds. An **SBOM (Software Bill of Materials)** is a machine-readable inventory of every component in a piece of software – every library, framework, and transitive dependency, along with version numbers, suppliers, and relationships. Think of it as a nutritional label for software: it tells you exactly what is inside. And just as food labels transformed public health by making ingredients transparent, SBOMs are transforming software security by making the software supply chain visible. ## What Is Inside an SBOM? A well-formed SBOM contains structured information about each component in your software: - **Component name and version** – The specific library or package and its exact version (e.g., `log4j-core 2.14.1`) - **Supplier** – Who authored or published the component - **Package URL (purl)** – A universal identifier for the component (e.g., `pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1`) - **Dependency relationships** – How components relate to each other (direct dependency, transitive dependency, dev dependency) - **Licenses** – The license terms governing each component - **Hashes** – Cryptographic digests for integrity verification This information enables automated tooling to match components against vulnerability databases, verify license compliance, and detect supply chain anomalies. ## SBOM Formats Three formats dominate the SBOM landscape. For a detailed comparison, see our [SBOM formats guide](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/). ### SPDX (Software Package Data Exchange) [SPDX](https://spdx.dev/) is maintained by the Linux Foundation and is an ISO/IEC 5962 international standard. Originally designed for license compliance, SPDX has evolved to support security use cases with SPDX 3.0's security profile. It supports JSON, XML, RDF, tag-value, and YAML serialization formats. ### CycloneDX [CycloneDX](https://cyclonedx.org/) is maintained by OWASP and was designed from the start for security and supply chain use cases. It supports JSON and XML, and has specialized capabilities including vulnerability disclosure (VEX), [cryptographic BOMs (CBOM)](/2024/04/10/future-proofing-cybersecurity-with-the-cryptography-bill-of-materials-cbom/), and service dependency mapping. CycloneDX is an ECMA standard (ECMA-424). ### SWID Tags [SWID (Software Identification) Tags](https://csrc.nist.gov/projects/Software-Identification-SWID) are an ISO/IEC 19770-2 standard primarily used for identifying installed software in enterprise asset management. SWID tags are less common in the development-focused SBOM ecosystem but are referenced in some government procurement requirements. For most organizations, the choice is between SPDX and CycloneDX. Both are mature, well-tooled, and accepted by regulatory frameworks. Many organizations generate both. ## How SBOMs Are Generated SBOMs can be generated at different points in the software lifecycle, with trade-offs in accuracy and completeness. ### Build-Time Generation The most accurate SBOMs are generated during the build process, when the full dependency tree has been resolved and lock files are available. Build-time tools include: - **[sbomify GitHub Action](https://github.com/sbomify/sbomify-action/)** – A multi-ecosystem SBOM generator that automatically selects the best generation tool for your stack, enriches the output with package metadata, and optionally augments it with business information - **[Syft](https://github.com/anchore/syft)** – Generates SBOMs from container images, file systems, and archives in both SPDX and CycloneDX formats - **[Trivy](https://trivy.dev/)** – Aqua Security's scanner that generates SBOMs alongside vulnerability reports (we [no longer consider Trivy safe](/2026/03/26/trivy-compromise-hardening-sbomify-action/)) - **[CycloneDX CLI tools](https://cyclonedx.org/tool-center/)** – Language-specific plugins for npm, Maven, Gradle, pip, Go, and more ### Analysis-Time Generation Post-hoc tools analyze compiled binaries or container images to infer components. These are useful when source code or build systems are not available but may miss components that are statically linked or vendored without metadata. ### The Accuracy Problem An SBOM is only as useful as it is accurate. [Lock file drift](/2024/07/30/what-is-lock-file-drift/) – where the dependency manifest and lock file fall out of sync – is one of the most common causes of inaccurate SBOMs. If your lock file doesn't reflect what's actually installed, neither will your SBOM. ## Why SBOMs Matter ### Rapid Vulnerability Response The primary security value of an SBOM is speed. When a new [CVE](/2025/12/18/cve-vulnerability-explained/) is disclosed – especially one confirmed as actively exploited in the [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) – you need to know immediately whether your software is affected. Without an SBOM, this means manually investigating each application's dependencies. With an SBOM, you query a database and get the answer in seconds. This is not a hypothetical benefit. During Log4Shell, organizations with SBOMs identified affected applications within hours. Those without SBOMs spent weeks. ### Continuous Monitoring SBOMs enable _continuous_ vulnerability monitoring, not just point-in-time audits. By ingesting SBOMs into a management platform like [sbomify](https://sbomify.com) or [OWASP Dependency-Track](https://dependencytrack.org/), you can automatically cross-reference your components against vulnerability databases (like [Google OSV](https://osv.dev/)) as new vulnerabilities are disclosed. For details on building this pipeline, see our guide on [SBOM scanning for vulnerability detection](/2026/02/01/sbom-scanning-vulnerability-detection/). ### Supply Chain Visibility Modern software is overwhelmingly composed of third-party code. Studies consistently show that 70-90% of a typical application consists of open-source components. An SBOM makes this composition visible, enabling informed decisions about which dependencies to adopt, which to replace, and which pose unacceptable risk. For more on [the role of SBOMs in cybersecurity](/2026/02/08/sbom-cybersecurity-role/), see our dedicated guide. ### Compliance SBOMs are increasingly required – not just recommended – by regulators and procurement frameworks: - **[Executive Order 14028](/compliance/eo-14028/)** requires SBOMs for software sold to the U.S. federal government - **[EU Cyber Resilience Act](/compliance/eu-cra/)** requires manufacturers of products with digital elements to document components and dependencies - **FDA** requires SBOMs for pre-market submissions of medical device software - **[CISA minimum elements](/compliance/cisa-minimum-elements/)** define what an SBOM must contain to be useful for cross-organizational sharing - **NIST SP 800-161** recommends SBOMs as part of supply chain risk management ## SBOMs in Practice: The Lifecycle Generating an SBOM is not a one-time event. SBOMs are most valuable when treated as living documents managed throughout the software lifecycle. 1. **Generate** – Produce SBOMs as part of your CI/CD pipeline, at every build 2. **Sign** – Wrap SBOMs in [in-toto attestations](/2024/08/14/what-is-in-toto/) signed via [Sigstore](/2024/08/12/what-is-sigstore/) for integrity and provenance 3. **Store** – Ingest SBOMs into a management platform ([sbomify](https://sbomify.com)) for centralized visibility 4. **Monitor** – Continuously scan SBOMs against vulnerability databases as new CVEs are published 5. **Share** – Provide SBOMs to customers, regulators, and partners as required by contracts or regulations 6. **Update** – Regenerate SBOMs whenever dependencies change, and retire SBOMs for decommissioned software ## Getting Started The fastest path to SBOM adoption: 1. **Pick a format.** CycloneDX is the simplest starting point for security-focused use cases. SPDX is a good choice if license compliance is a primary driver. See our [format comparison](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/). 2. **Add SBOM generation to CI.** Use the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/), Syft, Trivy, or a CycloneDX plugin for your language. Generate the SBOM alongside your build artifacts. 3. **Ingest into a management platform.** [sbomify](https://sbomify.com) provides centralized SBOM storage, vulnerability analysis via Google OSV, and sharing capabilities. 4. **Monitor continuously.** Set up alerts for new vulnerabilities affecting your components. For step-by-step generation guides across different ecosystems, see our [SBOM generation guides](/guides/). ## Frequently Asked Questions ### What is an SBOM? An SBOM (Software Bill of Materials) is a machine-readable inventory that lists every component in a piece of software, including direct dependencies, transitive dependencies, their versions, suppliers, and licenses. It is often compared to a nutritional label for food – it tells you exactly what is inside. See [What is an SBOM?](/what-is-sbom/) for a deeper overview. ### What are the main SBOM formats? The two dominant SBOM formats are [SPDX](https://spdx.dev/) (Software Package Data Exchange), maintained by the Linux Foundation, and [CycloneDX](https://cyclonedx.org/), maintained by OWASP. Both support JSON and XML serialization. SPDX has deeper roots in license compliance, while CycloneDX was designed for security and supply chain use cases. For a detailed comparison, see our [format guide](/2026/01/15/sbom-formats-cyclonedx-vs-spdx/). ### Why are SBOMs important for security? SBOMs enable rapid vulnerability response. When a new [CVE](/2025/12/18/cve-vulnerability-explained/) is disclosed, an SBOM lets you determine in seconds whether your software contains the affected component – without manually auditing source code or build systems. This is critical for monitoring against databases like the [CISA KEV catalog](/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/) and for meeting regulatory compliance requirements. ### How do I generate an SBOM? SBOMs can be generated using tools like the [sbomify GitHub Action](https://github.com/sbomify/sbomify-action/), [Syft](https://github.com/anchore/syft), [Trivy](https://trivy.dev/), or [CycloneDX CLI plugins](https://cyclonedx.org/tool-center/). The most accurate SBOMs are generated at build time, when the full dependency tree is resolved. ### Are SBOMs required by law? Increasingly, yes. U.S. [Executive Order 14028](/compliance/eo-14028/) requires SBOMs for software sold to the federal government. The [EU Cyber Resilience Act](/compliance/eu-cra/) requires manufacturers of products with digital elements to identify and document components. The FDA requires SBOMs for medical device software. Many procurement contracts now include SBOM requirements as well.