This feature is only available on Chainloop’s platform paid plans.
Which Path You Need
Both are built-in scans you enable per project.
Prerequisites
- A GitHub or GitLab repository connected to your organization and linked to the project — see Connect GitHub & GitLab. SBOM Generation and source-code scanning both need one.
- For Vulnerability Scan in SBOM mode, at least one CycloneDX or SPDX SBOM already attested on the project version. That mode never touches your repository, so it needs nothing else.
Generate an SBOM
Turn On SBOM Generation
Enable SBOM Generation from the Workflows step of the Create Project wizard, or later from the project’s workflow settings. Its only run mode is Run periodically — there is no schedule to configure. Its one input ispath, relative to the repository root, which defaults to the whole repository. For a monorepo, add one configuration per component: each becomes its own workflow with its own SBOM.
What You Get
Every run produces a signed attestation carrying a CycloneDX SBOM namedsbom, built by syft from the repository’s source and its declared dependencies. Chainloop re-runs the scan at least once a day, so the SBOM follows the default branch rather than aging out.
The SBOM describes your repository, not a build output — it is not an SBOM of your container image. If that’s what you need, see Generate SBOMs in Your Own CI Instead.
SBOM Quality Checks
Each run is evaluated against thesbom-quality policy group, which checks the SBOM for banned licenses and components, NTIA minimum elements, license coverage, and freshness. The verdicts are stored with the evidence and never fail the run.
The built-in template exposes only path, so the policy group’s own inputs — the banned-license and banned-component lists, and the freshness window — keep their defaults. To choose your own values, attach the policy group to a contract you control with with: parameters, the same way Set up Vulnerability Management does it.
Continuously Scan Your SBOMs
Continuous here means a fresh scan at least once a day against an updated vulnerability database: a package that was clean last week gets flagged today without anyone touching the code. Turn on Vulnerability Scan and choose where its dependency list comes from.Scan From Source Code
The default,source set to Source code. syft builds an SBOM from the repository and grype scans it for known CVEs; both the SBOM and the report are attested. This mode supports Run periodically, Run in PRs, and manual delivery. The severity input sets the lowest severity that counts as a violation, and defaults to HIGH.
Running this alongside SBOM Generation gives you two source-derived SBOMs a day from separate workflows. That’s harmless, but if all you want is findings, this mode covers generation and scanning on its own.
Scan SBOMs You Already Attested
Setsource to SBOMs when your pipeline builds the SBOM — from a container image, say, which is more faithful than a source-derived one — or when Chainloop shouldn’t clone your code at all. Chainloop collects the CycloneDX and SPDX SBOMs already attested on the project version and runs grype over each one, re-attesting the results alongside the SBOM they came from. Built-in Scanners has the material names it produces.
Two constraints come with it. The scan is skipped until the project has at least one SBOM to scan, and there is no PR mode — there’s no pull request to react to.
Where the Findings Land
Findings from either mode flow into the project’s Security tab: deduplicated across runs and scanners, flagged when a CVE appears in the CISA KEV catalog, and eligible for AI risk assessment and auto-remediation. Vulnerability Management and Risk Assessment covers the triage loop, the VEX feed, and the reports.Generate SBOMs in Your Own CI Instead
Managed generation needs a connected repository and gives you a source-derived SBOM. When neither fits — no repository connection, or you need an SBOM of a built image — produce the SBOM in your pipeline and attest it:- Attestations has working syft examples for GitHub Actions, GitLab CI, and other systems.
- Declare the material in your workflow contract:
- Set up Vulnerability Management covers the rest of the CI wiring, including the vulnerability report itself.
Send SBOMs Onward
Any CycloneDX SBOM that reaches Chainloop, generated or attested from your CI, can be forwarded automatically to a Dependency-Track instance for component analysis — see Send SBOMs to Dependency-Track. Approved risk assessments also publish as a live VEX feed you can share with customers, covered in Vulnerability Management.Troubleshooting
The SBOM Generation workflow has no runs
The SBOM Generation workflow has no runs
Check that the project has a repository linked and that its provider is GitHub or GitLab — managed scans are skipped when there is no linked source repository. Periodic runs are also dispatched by a sweep rather than the moment you save, so a workflow you just enabled can take a while to show its first run.
Vulnerability Scan in SBOM mode is skipped
Vulnerability Scan in SBOM mode is skipped
That mode scans SBOMs already attested on the project version, so it has nothing to do until one arrives. Either turn on SBOM Generation or attest an SBOM from your CI, and the next run will pick it up.
The SBOM is missing dependencies I expected
The SBOM is missing dependencies I expected
Two usual causes. The SBOM is source-derived, so anything introduced at build time — base image packages, vendored binaries — won’t appear; attest an artifact SBOM from your pipeline instead. Or
path points at a subdirectory that doesn’t contain the manifest or lockfile declaring those dependencies.I want banned licenses enforced on the generated SBOM
I want banned licenses enforced on the generated SBOM
The built-in template exposes only
path, so sbom-quality runs with its default lists. Attach the policy group to a contract of your own with with: parameters to set them, and add a control gate if a violation should block a release — policy verdicts on managed runs are recorded, not enforced.Next Steps
- Built-in Scanners — every built-in scan, the tool it runs, and the evidence it produces.
- Vulnerability Management and Risk Assessment — what happens to findings after a scan.
- Cyber Resilience Act — how SBOMs and vulnerability handling map onto CRA obligations.