Developer guide · CI/CD SBOM

Generate and maintain an SBOM in CI/CD.

Generate a machine-readable inventory from the release build, keep it with the artifact, and attach it to the exact product version. Vellaci then parses the SBOM, tracks its components and matches vulnerability intelligence.

What is an SBOM in CI/CD? It is a software bill of materials generated as part of a build or release pipeline. Generating one for each shipped version ties component inventory to the artifact that customers receive and gives vulnerability review a stable starting point.

These examples use Syft to write CycloneDX JSON and Vellaci's existing multipart upload API. They assume Syft is installed at an approved, pinned version in the runner. The upload endpoint accepts CycloneDX JSON/XML and SPDX JSON/tag-value, requires a product and version, and is idempotent for the same file and version.

Replace the product slug with one already in your Vellaci workspace. Store the API token as a protected CI secret. Do not print it or place it in the repository.

GitHub Actions

Run on release tags, archive the generated SBOM beside the release output, then upload it with the source revision.

.github/workflows/release-sbom.yml
name: release-sbom
on:
  push:
    tags: ["v*"]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Install Syft at a pinned version using your approved tool-install method.
      - name: Generate CycloneDX SBOM
        run: syft dir:. -o cyclonedx-json=sbom.cdx.json
      - name: Archive SBOM with the release
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.ref_name }}
          path: sbom.cdx.json
          if-no-files-found: error
      - name: Upload SBOM to Vellaci
        env:
          VELLACI_TOKEN: ${{ secrets.VELLACI_TOKEN }}
          VELLACI_URL: https://www.vellaci.ch
          VELLACI_PRODUCT: edge-gateway
        run: |
          curl --fail --silent --show-error \
            -X POST "$VELLACI_URL/api/v1/sboms/upload" \
            -H "Authorization: Bearer $VELLACI_TOKEN" \
            -F "file=@sbom.cdx.json" \
            -F "product=$VELLACI_PRODUCT" \
            -F "version=${GITHUB_REF_NAME}" \
            -F "commit_sha=${GITHUB_SHA}" \
            -F "tool=syft"

GitLab CI

Add VELLACI_URL, VELLACI_TOKEN and VELLACI_PRODUCT as protected CI/CD variables. Use a runner image containing a pinned Syft version.

.gitlab-ci.yml
sbom:
  stage: build
  image: your-pinned-syft-image
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - syft dir:. -o cyclonedx-json=sbom.cdx.json
    - test -s sbom.cdx.json
    - >-
      curl --fail --silent --show-error
      -X POST "$VELLACI_URL/api/v1/sboms/upload"
      -H "Authorization: Bearer $VELLACI_TOKEN"
      -F "file=@sbom.cdx.json"
      -F "product=$VELLACI_PRODUCT"
      -F "version=$CI_COMMIT_TAG"
      -F "commit_sha=$CI_COMMIT_SHA"
      -F "branch=$CI_COMMIT_BRANCH"
      -F "tool=syft"

Keep the SBOM useful

  • Generate from the release source tree or built image that you actually ship.
  • Keep the original SBOM as a release artifact and retain its checksum.
  • Use the same product identity and immutable release version in every pipeline run.
  • Include the commit SHA so reviewers can trace the inventory to source.
  • Review Vellaci's parse and match status; HTTP 202 means processing was queued.

Format, signing and attestations

CycloneDX and SPDX are established exchange formats. SBOM generation does not by itself prove that an SBOM corresponds to a particular binary. Keep it with the release and use your existing artifact-signing or provenance-attestation process when you need cryptographic binding. Avoid treating a generated inventory as a legal conformity conclusion.

Vellaci accepts SBOMs via the API, GitHub, GitLab or the product UI. Its authenticated ingestion stores the original privately, links it to a version, and processes it for component and vulnerability views.

Sources and verification

Implementation facts

Last verified 29 September 2026. API behavior below is based on Vellaci's current upload route and OpenAPI specification; Syft output syntax is linked to the project documentation.

Move from pipeline output to product context.

Attach a release SBOM to its product version, then follow components into advisories, exploitability review and VEX decisions.