> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chainloop.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Generate and Continuously Scan SBOMs

> Produce CycloneDX SBOMs from a connected repository — or bring your own — and keep them checked against newly disclosed CVEs.

<Note>
  This feature is only available on Chainloop's platform [paid plans](https://chainloop.dev/pricing).
</Note>

An SBOM is only worth having if it exists and stays current. Chainloop covers both halves: it can build the SBOM for you from a connected repository, and it can keep re-checking any SBOM in the project against newly disclosed CVEs. Both run server-side, so neither needs a change to your CI.

## Which Path You Need

| What you want                                         | Turn on                                                      |
| ----------------------------------------------------- | ------------------------------------------------------------ |
| An SBOM of a repository you've connected              | **SBOM Generation**                                          |
| Vulnerability findings from source, SBOM included     | **Vulnerability Scan**, with `source` set to **Source code** |
| Vulnerability findings from SBOMs your own CI attests | **Vulnerability Scan**, with `source` set to **SBOMs**       |
| A published SBOM *and* daily CVE checks               | Both                                                         |

Both are [built-in scans](/reference/scanners) you enable per project.

## Prerequisites

* A GitHub or GitLab repository connected to your organization and linked to the project — see [Connect GitHub & GitLab](/guides/connect-repository). 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](/get-started/projects/create-project), or later from the project's workflow settings. Its only run mode is **Run periodically** — there is no schedule to configure.

Its one input is `path`, 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](/concepts/attestations) carrying a CycloneDX SBOM named `sbom`, built by [syft](https://github.com/anchore/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.

<Note>
  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](#generate-sboms-in-your-own-ci-instead).
</Note>

### SBOM Quality Checks

Each run is evaluated against the [`sbom-quality`](/reference/policies#sbom-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](/concepts/contracts) you control with `with:` parameters, the same way [Set up Vulnerability Management](/guides/vulnerability-management#add-the-policy-group-to-your-contract) 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](https://github.com/anchore/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

Set `source` 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](/reference/scanners#vulnerability-scan) 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](/concepts/vulnerability-management) 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](/concepts/attestations#ci-integration) has working syft examples for GitHub Actions, GitLab CI, and other systems.
* Declare the material in your workflow [contract](/concepts/contracts):

```yaml theme={"dark"}
apiVersion: chainloop.dev/v1
kind: Contract
metadata:
  name: skynet-contract
spec:
  materials:
    # SBOMs will be uploaded to the CAS Backend of your choice, such as an OCI registry and referenced in the attestation
    - type: SBOM_CYCLONEDX_JSON
      name: skynet-sbom
```

* [Set up Vulnerability Management](/guides/vulnerability-management) covers the rest of the CI wiring, including the vulnerability report itself.

An SBOM attested this way is ordinary evidence, so **Vulnerability Scan** in SBOM mode picks it up and keeps scanning it — you can hand generation to your CI and still get continuous checks from Chainloop.

## 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](/guides/dependency-track). Approved risk assessments also publish as a live VEX feed you can share with customers, covered in [Vulnerability Management](/concepts/vulnerability-management).

## Troubleshooting

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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](/concepts/control-gates) if a violation should block a release — policy verdicts on managed runs are recorded, not enforced.
  </Accordion>
</AccordionGroup>

## Next Steps

* [Built-in Scanners](/reference/scanners) — every built-in scan, the tool it runs, and the evidence it produces.
* [Vulnerability Management and Risk Assessment](/concepts/vulnerability-management) — what happens to findings after a scan.
* [Cyber Resilience Act](/reference/cyber-resilience-act) — how SBOMs and vulnerability handling map onto CRA obligations.