From 6e4da9e044198d4a8ef63a7c473a34d780b95ab7 Mon Sep 17 00:00:00 2001 From: Viktor Petersson Date: Tue, 20 Jan 2026 06:44:47 +0000 Subject: [PATCH 1/2] Adds blogpost about v0.11 --- ...ion-v0-11-the-one-where-they-go-to-pypi.md | 192 ++++++++++++++++++ assets/css/styles.css | 8 +- features/integrations.md | 176 +++++++++++++--- 3 files changed, 349 insertions(+), 27 deletions(-) create mode 100644 _posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md diff --git a/_posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md b/_posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md new file mode 100644 index 0000000..446f739 --- /dev/null +++ b/_posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md @@ -0,0 +1,192 @@ +--- +layout: post +title: "Announcing sbomify-action v0.11: The One Where They Go to PyPI" +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." +author: + display_name: Viktor Petersson +category: announcement +tags: [sbom, release, github-actions, pypi, cli] +--- + +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 (no API calls, all data is bundled) and reliable. When LicenseDB does not have coverage for a package, we fall back to other sources. See our [integrations page]({{ site.url }}/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/github-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/github-action/compare/v0.10...v0.11) for complete details. diff --git a/assets/css/styles.css b/assets/css/styles.css index e1d3727..131b7ab 100644 --- a/assets/css/styles.css +++ b/assets/css/styles.css @@ -831,10 +831,6 @@ video { display: none; } -.h-10 { - height: 2.5rem; -} - .h-12 { height: 3rem; } @@ -2330,6 +2326,10 @@ video { grid-template-columns: repeat(3, minmax(0, 1fr)); } + .lg\:grid-cols-4 { + grid-template-columns: repeat(4, minmax(0, 1fr)); + } + .lg\:grid-cols-5 { grid-template-columns: repeat(5, minmax(0, 1fr)); } diff --git a/features/integrations.md b/features/integrations.md index bde7020..d966e12 100644 --- a/features/integrations.md +++ b/features/integrations.md @@ -58,15 +58,15 @@ description: "Seamlessly integrate SBOM generation, analysis, and enrichment int variables: TOKEN: $SBOMIFY_TOKEN COMPONENT_ID: 'Your Component ID' - UPLOAD: true - AUGMENT: true - ENRICH: true + UPLOAD: "true" + AUGMENT: "true" + ENRICH: "true" COMPONENT_NAME: 'my-python-app' COMPONENT_VERSION: $CI_COMMIT_SHA LOCK_FILE: 'poetry.lock' - OUTPUT_FILE: test-sbom.cdx.json" + OUTPUT_FILE: 'sbom.cdx.json' script: - - /sbomify.sh + - sbomify-action @@ -116,7 +116,9 @@ description: "Seamlessly integrate SBOM generation, analysis, and enrichment int -e TOKEN=<my token> \ -e COMPONENT_ID=<my component id> \ -e LOCK_FILE=/code/requirements.txt \ + -e OUTPUT_FILE=/code/sbom.cdx.json \ -e COMPONENT_NAME=my-app \ + -e ENRICH=true \ sbomifyhub/sbomify-action @@ -165,29 +167,157 @@ description: "Seamlessly integrate SBOM generation, analysis, and enrichment int
-

Enrichment

-

Add context to your artifacts automatically.

+

Enrichment Data Sources

+

We integrate with 11 data sources to add metadata to your SBOM components: descriptions, licenses, supplier information, and more.

-
-
-
- Ecosyste.ms -
-
-

Ecosyste.ms

-

- We partner with Ecosyste.ms to enrich your SBOMs with metadata, licensing information, and project health metrics. -

-
-

- How it works: - Enrichment happens automatically when using our GitHub Action module. -

- ENRICH: true + +
+

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/* +
+
+
+ + +
+

Package Aggregators

+

Multi-ecosystem services providing broad coverage.

+
+
+
+

deps.dev

+ Google +
+

Open source dependency insights from Google. Covers most major ecosystems.

+
+
+
+ Ecosyste.ms
+

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
From 7390eb45419cabe265c11437ebdc0a2d1084f5fe Mon Sep 17 00:00:00 2001 From: Viktor Petersson Date: Tue, 20 Jan 2026 06:47:27 +0000 Subject: [PATCH 2/2] Fixes inaccurate statement --- ...uncing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md b/_posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md index 446f739..59fe84c 100644 --- a/_posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md +++ b/_posts/2026-01-20-announcing-sbomify-action-v0-11-the-one-where-they-go-to-pypi.md @@ -37,7 +37,7 @@ One of the most frustrating aspects of generating SBOMs for container images is 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 (no API calls, all data is bundled) and reliable. When LicenseDB does not have coverage for a package, we fall back to other sources. See our [integrations page]({{ site.url }}/features/integrations/) for the full list of data sources. +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]({{ site.url }}/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.