Built-in Scanners

Chainloop’s built-in workflow templates scan your code for you: Chainloop clones the repository connected to your project into a sandbox it manages, runs one open-source tool there, and records the output as a signed attestation. Nothing runs in your CI. In the product you pick a scan by name — SAST Scan, Secret Scan, Vulnerability Scan — without seeing what’s behind it. This page names the tool each scan runs, what it looks for, the evidence it produces, and how to enable it. Throughout, scan means the built-in template you turn on and tool means the binary it runs.

​

Scanners at a Glance

Each evidence entry is a material type and a material name, so you can find the report inside the attestation and write policies against it.

​

Turning Scans On

Every scan has an On/Off toggle and, when it’s on, up to two independent run modes: Run periodically and Run in PRs. You set these per scan, either in the Create Project wizard or later from the project’s workflow settings.

​

Run Modes

The two modes are independent: enable both for scheduled baseline coverage plus per-change feedback, or enable just one. Where a scan supports only a single mode, that mode stays selected — the table above lists what each one supports. Turning a scan on without selecting either run mode falls back to manual delivery, for the scans that allow it: Chainloop sets up the workflow and its contract, and you instrument your CI with the Chainloop CLI to send attestations yourself. Server-side runs — periodic or in PRs — need a repository connected through a provider that supports them, currently GitHub or GitLab. If no repository is linked to the project, or its provider doesn’t support them, the run modes are disabled and you can use manual delivery instead where the scan allows it.

​

Configuring a Scan

Each scan has a Configure panel where you set its options before adding it to the project.

• Triggers — the run modes to enable. Only the modes the scan supports are offered, so the SCM Configuration Check above shows just Run periodically.
• Name — optional; if you leave it blank, Chainloop generates one automatically.
• Template inputs — the fields the scan accepts, each with a description of the format it expects. The inputs for every built-in scan are listed under each scan below.

Some scans allow multiple configurations. Adding more than one configuration for the same scan creates a separate workflow for each, which is how you cover several components of a monorepo.

​

Built-in and Custom Templates

Workflow templates come from two sources:

• Built-in templates — the scans on this page. Provided by Chainloop, available on Chainloop Cloud, and pre-selected by default.
• Custom templates — defined by your organization, and only available in on-prem installations. See Managing Custom Templates for the chainloop apply workflow.

​

How Scans Run

​

Where Scans Run

Chainloop clones the repository linked to your project into a sandbox it manages and runs the tool there. None of your runners are involved. A scan is skipped when the project has no linked repository. The one exception is the SCM Configuration Check, which needs no sandbox and no clone — it only calls your provider’s API. Every scan that reads source takes a path input, relative to the repository root, which defaults to the whole repository. Point it at a subdirectory to scan one component of a monorepo.

​

How Often Periodic Scans Run

At least once a day. Chainloop re-scans any workflow whose most recent run is more than 24 hours old, so there is no schedule to configure. A workflow that has never run is treated the same way, so a scan you just enabled is picked up shortly after.

​

Where the Results Go

Every run is stored as evidence: the scan reports — and, for PR runs, the pull request metadata — are captured as a signed attestation, evaluated by the same policies as the rest of your evidence, and retained for audit. Policy verdicts are recorded, not enforced: a violation never fails the run or rejects the attestation, so you always get the report. To make a violation stop something, use control gates. Findings from the vulnerability scans feed vulnerability management, where periodic runs power AI auto-remediation — Chainloop assesses each finding with AI and, when a fix is available, proposes it as a pull or merge request. See assessment and auto-remediation for that flow.

​

Scanning in Pull Requests

Turn on Run in PRs for as many scans as you like: they share one sandbox run per pull or merge request, so a pull request gets one clone, one attestation, one Chainloop PR Validation check, and one consolidated comment instead of a separate set per scan. There is no PR validation workflow to create. Chainloop provisions one for the project on its first pull request, named pr-validation, deriving its contract from the scans you opted into.

​

How the Diff Is Scoped

Each tool narrows to the change in its own way, which is worth knowing when a finding looks unrelated to the pull request:

​

SAST Scan

Runs opengrep — an open-source fork of Semgrep — over your source code with the bundled Community ruleset. Semgrep’s proprietary Pro rules are not included.

• Evidence — a SARIF report named sast-report.
• Policies — source-commit and owasp-top10-2025, plus the sast and cwes policy groups, which check findings against the OWASP Top 10 (2025) and the CWE Top 25 together with the 26–40 “on the cusp” list.
• Configuration — reads .semgrep.yml, a .semgrep/ directory, and .semgrepignore from your repository.

​

Secret Scan

Runs betterleaks, a drop-in successor to gitleaks maintained by gitleaks’ original authors. Reports keep the gitleaks format, which is why the material type is still called GITLEAKS_JSON.

• Evidence — a GITLEAKS_JSON report named secret-report.
• Policies — source-commit and secrets-detection.
• Configuration — reads .gitleaks.toml or .betterleaks.toml from your repository.

​

Vulnerability Scan

Reports known CVEs affecting your dependencies. The source input decides where the dependency list comes from.

​

Source code mode

The default. syft builds a CycloneDX SBOM from your repository, then grype scans that SBOM for known vulnerabilities. Both the SBOM and the vulnerability report are attested, so you get an inventory and its findings from one run.

​

SBOM mode

Set source to SBOMs when your pipeline already produces SBOMs, or when Chainloop shouldn’t touch your source. Chainloop collects the SBOMs already attested on the project version, runs grype over each one, and re-attests them as indexed pairs — sbom-1 and vulnerability-report-1, sbom-2 and vulnerability-report-2, and so on. Because the SBOMs can arrive in several formats and there can be more than one per run, the fixed material names below don’t apply. This mode needs no access to your repository, and it is skipped when the project has no SBOM evidence to scan. It has no pull request mode — there is no pull request to react to. See Generate and Continuously Scan SBOMs for the setup.

• Evidence — a SARIF report named vulnerability-report and an SBOM_CYCLONEDX_JSON named sbom. Both are optional, since SBOM mode produces indexed names instead.
• Policies — source-commit, cves-in-kev, and the vulnerability-management policy group. A finding at or above the configured severity fails the run, as does any CVE listed in the CISA KEV catalog.
• Inputs — severity sets the lowest severity that counts as a violation, and defaults to HIGH.

​

IaC Scan

Runs checkov over your infrastructure as code — Terraform, Dockerfiles, Kubernetes manifests, and YAML or JSON configuration — looking for misconfigurations such as public storage buckets, missing encryption, and over-broad permissions.

• Evidence — a SARIF report named iac-report.
• Policies — source-commit, iac-scan-present, and iac-misconfiguration.
• Configuration — reads .checkov.yaml or .checkov.yml from your repository.

​

GitHub Actions Scan

Runs zizmor over the workflow and action definitions in your repository, looking for the ways a CI pipeline gets compromised: actions pinned to a mutable tag instead of a digest, workflows granted more permissions than they need, and untrusted input interpolated into a run block. This scan is offered for GitHub repositories only.

• Evidence — a SARIF report named actions-report.
• Policies — ci-pipeline-security.

​

SBOM Generation

Runs syft over your repository and attests the result as a CycloneDX SBOM, giving every project a dependency inventory that refreshes on its own. Runs periodically only.

• Evidence — an SBOM_CYCLONEDX_JSON named sbom.
• Policies — source-commit and the sbom-quality policy group, which checks the SBOM for banned licenses and components, NTIA minimum elements, license coverage, and freshness.

​

SCM Configuration Check

The exception on this page: it runs no scanning tool and never clones your code. Chainloop reads your repository’s configuration from your provider’s API — branch and tag protection, code review requirements, automated patch management, and signed commits — records what it read as evidence, and evaluates that evidence with policies. It runs periodically on GitHub and GitLab, and a repository can have only one.

• Evidence — a CHAINLOOP_RUNNER_CONTEXT material named runner-context, holding the repository configuration Chainloop read. It uses the same format the Enterprise Edition CLI collects in your pipeline, so the same policies apply to both.
• Policies — patch-policy-present and commits-signed-required, plus the branch-protection, code-review, and tag-protection policy groups.
• Inputs — branches and tags select the refs to check, and authorized_bypass lists the accounts allowed to bypass protection.

When a permission stops Chainloop from reading part of the configuration, the gap is recorded in the evidence rather than silently dropped, so policies can tell “not configured” apart from “not visible to us”. For what each check expects, see SCM Protection Policies.

​

Related