[PetrefiedThunder]

Summary

Generate Software Bill of Materials (SBOM) in SPDX and CycloneDX formats using Syft v1.19.0 for each Python SDK release. The SBOM covers Python packages (gateway and SDK) and npm lockfiles.

Related issues

Addresses the SBOM gap identified in security evidence Nov 9, 2026 (attached to this work).

Area and license

• I identified the repository area changed by this PR.
• I understand that spec/, verifier/, sdk/python/, sdk/typescript/, integrations/, and examples/ are Apache-2.0.
• I understand that gateway/ contributions are under FSL-1.1-ALv2 (Fair Source).
• This PR does not include proprietary hosted-service code or secrets.

Spec changes

• This PR does not change normative spec behavior.

Validation

Local testing

Tested SBOM generation locally with Syft 1.19.0:

$ syft scan dir:. --output spdx-json=sbom-spdx.json --output cyclonedx-json=sbom-cyclonedx.json --exclude './.*' --exclude '**/node_modules' --exclude '**/__pycache__'
[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
[0001]  WARN unable to parse requirements.txt line: "-r requirements.txt" path=/gateway/requirements-dev.txt

$ ls -lh sbom-*.json
-rw-r--r-- 1 ubuntu ubuntu 9.4K sbom-cyclonedx.json
-rw-r--r-- 1 ubuntu ubuntu  18K sbom-spdx.json

$ jq '.packages | length' sbom-spdx.json
28

The SBOM successfully captures Python packages from requirements.txt and pyproject.toml files, npm packages from package-lock.json files, and GitHub Actions used in workflows.

CI checks

Waiting for CI to run:

• CI result
• License result
• gitleaks

Design decisions

SBOM tool selection

Used Anchore Syft 1.19.0 because:

• Industry standard tool for SBOM generation
• Supports both SPDX and CycloneDX formats
• Can scan source trees without requiring installation
• Fast and reliable
• Version pinned for reproducibility

Trigger strategy

1. On release (python-v* tags): Generate and publish SBOM as release assets
2. On PR (when dependency manifests change): Dry-run to validate workflow and catch issues early
3. Manual: workflow_dispatch for testing

Publishing approach

SBOM files are published as GitHub release assets alongside the Python SDK wheel and sdist. This keeps them close to the release artifacts they describe and makes them easy to discover.

The workflow checks if a release already exists (in case the release was created by another process) and either:

• Uploads SBOM assets to the existing release
• Creates a new release with SBOM assets

Least-privilege permissions

• generate-sbom job: contents: read only
• publish-sbom job: contents: write (required for release asset upload)
• Follows the principle of least privilege per repository convention

Integration with existing release flow

This workflow complements the existing release-python.yml workflow:

• Both trigger on the same python-v* tags
• SBOM workflow is independent and non-blocking
• Does not modify PyPI publishing logic (as requested)
• Uses the same action pinning convention (full commit SHA)

Risk and compatibility

• Low risk: This is an additive change that does not modify existing release or publishing logic
• No breaking changes: SBOM generation runs independently
• Failure handling: If SBOM generation fails, it does not block the SDK release
• Artifact retention: SBOM artifacts are retained for 90 days in CI, forever in releases

Documentation

Added SBOM section to SECURITY.md explaining:

• What SBOM formats are provided
• Where to find them (release assets)
• What they cover (Python packages and npm lockfiles)
• Reference to the workflow file for generation details

Limitations and future improvements

Current approach: Source tree SBOM

• Scans requirements.txt, pyproject.toml, and package-lock.json files
• Captures direct dependencies with pinned versions
• Does not include transitive dependencies without pins

Future enhancements (not in this PR):

• Generate SBOM from built wheels for complete dependency graph
• Sign SBOM files with Sigstore
• Add SBOM validation step
• Generate separate SBOMs for gateway vs SDK

Contributor checklist

• I added or updated tests for behavior changes, or explained why tests are not applicable.
  • This is a CI workflow change. The workflow itself is tested by running it, and local validation confirms SBOM generation works.
• I updated relevant documentation and examples.
  • Added SBOM section to SECURITY.md
• Every commit in this PR is signed off under the Developer Certificate of Origin.
• I agree to submit this contribution under the license applicable to the files I changed.
  • .github/workflows/ and SECURITY.md changes

  

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
agent-middleware-web	Ready	Preview	Nov 10, 2026 6:02am UTC

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn