Announcing sbomify v0.25: The One with Attestations

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 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 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) 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 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, 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 and 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.