CWL 2 SBOM

Generate local CycloneDX SBOMs for the containers declared by a CWL workflow using Trivy. Bootstrapped from the Transpiler-Mate plugin project template.

Install

Python 3.10+ and an installed Trivy executable are required. From this checkout:

pip install transpiler-mate-runtime .

Generate

transpiler-mate cwl2sbom --platform linux/amd64 --output sbom \
  workflow.cwl#main

For the workspace example:

transpiler-mate cwl2sbom --platform linux/amd64 \
  --output tmp/build/burned-area-severity/sbom \
  tmp/burned-area-severity.cwl#burned-area-severity

An explicit CWL entrypoint and platform are required. Trivy downloads and inspects images directly from their registries; no Docker daemon or container execution is involved. Registry authentication uses Trivy's normal configuration. Install Trivy separately; the plugin does not download executables.

Image filenames hash the original reference and platform, avoiding registry aliases and unsafe filename characters. Repeated references are inspected once per invocation. Different aliases may be inspected separately, even if they ultimately resolve to the same image. Trivy's cache handles reuse of downloaded/analyzed content.

Options

The plugin follows nested workflows and effective Docker requirements/hints. It reports missing containers, nonliteral references, and build-only Docker requirements. ExpressionTools are marked not applicable because they run in the CWL engine. No image builds are performed. Failure removes the newly created bundle; existing outputs are preserved.

Publish and scan separately

Publish or attach the generated files using your existing ORAS pipeline. This plugin does not push, retrieve OCI referrers, sign artifacts, or attach SBOMs. The lock file connects each image SBOM to its container identity even when the bundle is attached to a workflow artifact.

See the offline Trivy scanning guide for database preparation and transfer, per-image vulnerability reports, separate license assessment, and CI exit-code handling. Scanning and policy enforcement run downstream of this plugin.

Scope and reproducibility

A tag is resolved by Trivy during inspection. The lock records the repository digest(s) and image configuration ID reported by that inspection, together with the requested platform. It does not pre-resolve tags or rewrite CWL. A reported repository digest can identify a multi-platform index: it must not be mistaken for a selected child manifest digest. For subsequent reproducible invocations, use digest-pinned references and the same platform. The lock file is an audit output, not an input replay mechanism.

A successful bundle covers declared container references; it is not a complete inventory of software that might execute. Runtime downloads, host tools, CWL engine dependencies, and packages Trivy cannot detect are outside its scope. Docker hints describe possible execution environments, not proof of an actual run. The workflow inventory therefore explicitly declares its composition incomplete. Image SBOMs are retained without merging away package or distribution metadata needed by Trivy.

Development

pip install -e '.[test]'
pytest
hatch run dev:typecheck
hatch run dev:ruff check src tests
hatch run dev:ruff format --check src tests
hatch run dev:security
pip install -r requirements-docs.txt
mkdocs build --strict

Verified with Trivy 0.74.0 against alpine:3.21 on linux/amd64.

Tests use controlled scanner responses and require no registry access. Real Trivy scanning is a separate integration check. See architecture.