Policies

Reference documentation for all available policies and policy groups

This feature is only available on Chainloop’s platform paid plans.

Chainloop provides a set of built-in policies and policy groups that can be used to enforce compliance and security requirements in your software supply chain.

Policies

artifact-signed

Checks that the provided piece of evidence has a signature

• Categories: security signing
• Supported material types: CONTAINER_IMAGE HELM_CHART

artifact-tag-not-latest

Checks that the provided OCI artifact hasn’t been tagged with the latest tag.

• Categories: security
• Supported material types: CONTAINER_IMAGE

binary-scan

Checks binary scan reports for security and correctness errors. Supports BinSkim SARIF format.

• Categories: security binaries
• Supported material types: SARIF

Inputs

Name	Description	Required	Default
rules	List of specific rules to check. Supports two formats: - RuleId - checks all severity levels of that rule (e.g., BA2009) - RuleId;Level - checks only the specific rule+level combination (e.g., BA2009;error) If not specified, all rules meeting the severity threshold will be checked.	No	-
severity	The severity level to filter the scan results. If not specified, error results will be included. Possible values are none, note, warning, error.	No	error

branch-deletion-blocked

Ensures that branch deletion is blocked to protect important branches from accidental deletion. Supports both GitHub and GitLab.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

branch-force-push-blocked

Ensures that force pushes are blocked on branches to prevent bypassing code review and history integrity. Supports both GitHub and GitLab.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

branch-linear-history-required

Ensures that branches require linear history to prevent merge commits and maintain a clean commit history.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

check-compliance-requirement

Checks that the project passes the compliance requirement

• Categories: compliance
• Supported material types: ATTESTATION

Inputs

Name	Description	Required	Default
requirement_name	Requirement name or comma-separated list of requirement names to check. If not provided, all requirements will be checked.	No	-

ci-user-strongly-authenticated

Ensures that CI users have strong authentication enabled, including two-factor authentication and verified accounts. Only applies to GitHub provider.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

code-coverage

Checks a code coverage report against a given percentage threshold. It uses JaCoCo counters as in JaCoCo Documentation

• Categories: coverage SAST
• Supported material types: JACOCO_XML
• Auto-match: Yes

Inputs

Name	Description	Required	Default
counter	Coverage counter. By default, INSTRUCTION will be used. Other values are LINE, BRANCH, COMPLEXITY and METHOD	No	INSTRUCTION
threshold	Required coverage percentage	No	80

commits-signed-required

Ensures that all commits are signed to verify their authenticity and integrity.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

containers-with-sbom

Ensures all OCI container images have an associated SBOM material. Only the CycloneDX SBOM format is supported. SBOMs generated by Syft using the ‘latest’ tag are not recognized and will result in a policy violation.

• Categories: sbom container
• Supported material types: ATTESTATION

Inputs

Name	Description	Required	Default
bidirectional	Reverse validation of SBOM-to-container associations. Prevents orphaned SBOMs.	No	-

cves-in-kev

Checks a CVE report against CISA’s Known Exploited Vulnerabilities KEV Catalog. Supports Trivy’s SARIF, Blackduck and GHAS Dependency Scans outputs.

• Categories: security CVE
• Supported material types: BLACKDUCK_SCA_JSON GHAS_DEPENDENCY_SCAN SARIF

cwe-top25

Checks for CWEs in the 2024 CWE Top 25 Most Dangerous Software Weaknesses list.

See the CWE Top 25 for the complete list.

Supported Tools:

• SARIF: KICS, SpotBugs, ZAP, StackHawk, Polaris, Semgrep and Opengrep
• GitLab Security Reports: Native GitLab, SonarQube
• Other: CSAF Security Advisory, BlackDuck SCA, GitHub Advanced Security Dependency Scan

• Categories: security CWE
• Supported material types: BLACKDUCK_SCA_JSON CSAF_SECURITY_ADVISORY GHAS_DEPENDENCY_SCAN GITLAB_SECURITY_REPORT SARIF

cwe-top26-40-cusp

Checks a vulnerability report for CWEs in the 2024 CWE On the Cusp list (CWEs ranked 26-40).

See the CWE On the Cusp for the complete list.

Supported Tools:

• SARIF: KICS, SpotBugs, ZAP, StackHawk, Polaris, Semgrep and Opengrep
• GitLab Security Reports: Native GitLab, SonarQube
• Other: BlackDuck SCA, GitHub Advanced Security Dependency Scan

• Categories: security CWE
• Supported material types: BLACKDUCK_SCA_JSON GHAS_DEPENDENCY_SCAN GITLAB_SECURITY_REPORT SARIF

evidence-prompt

Analyzes evidence using an AI-powered prompt. Leverages any OpenAI or Anthropic API integration you have set up in your organization to perform prompt-based analysis of materials (e.g., SBOMs).

• Categories: security compliance
• Supported material types: ATTESTATION BLACKDUCK_SCA_JSON CHAINLOOP_PR_INFO CHAINLOOP_RUNNER_CONTEXT CONTAINER_IMAGE CSAF_SECURITY_ADVISORY EVIDENCE GHAS_DEPENDENCY_SCAN GHAS_SECRET_SCAN GITLAB_SECURITY_REPORT GITLEAKS_JSON HELM_CHART JACOCO_XML SARIF SBOM_CYCLONEDX_JSON SBOM_SPDX_JSON TWISTCLI_SCAN_JSON

Inputs

Name	Description	Required	Default
prompt	A text prompt describing what to analyze in the evidence material	Yes	-

iac-misconfiguration

Checks for misconfigurations in IAC (infrastructure as code) sources. Supports SARIF from Checkov

• Categories: security IAC
• Supported material types: SARIF

material-present

Checks that a required material is present in the attestation

• Categories: compliance
• Supported material types: ATTESTATION

Inputs

Name	Description	Required	Default
material_name	Optional name of the material	No	-
material_type	Optional type of the material (it must be a Chainloop type)	No	-
number	Number of times that at least this material should appear in the attestation (only works with material_type)	No	1

owasp-top10-2021

Checks for CWEs included in the OWASP Top10:2021 list. It works with Gitlab SAST Reports generated with SonarQube

• Categories: security CWE
• Supported material types: GITLAB_SECURITY_REPORT

owasp-top10-2025

Checks for CWEs included in the OWASP Top10:2025 list. It works with Gitlab SAST Reports generated with SonarQube

• Categories: security CWE
• Supported material types: GITLAB_SECURITY_REPORT

pr-code-owner-review-required

Ensures that code owner reviews are required for pull requests. Supports both GitHub and GitLab.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

pr-conversation-resolution-required

Ensures that all conversations in pull requests must be resolved before merging.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

pr-description-required

Ensures PRs/MRs have meaningful descriptions for better code review quality and documentation

• Categories: Code Review
• Supported material types: CHAINLOOP_PR_INFO

Inputs

Name	Description	Required	Default
min_length	Minimum description length in characters	No	50
allow_empty	Allow empty descriptions	No	false
required_sections	List of required sections in description (comma-separated, case-insensitive)	No	-

pr-review-required

Ensures that pull requests require a minimum number of reviewers before merging. Supports both GitHub and GitLab.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
min_reviewers	Minimum number of reviewers required.	Yes	-
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

pr-stale-reviews-dismissed

Ensures that stale pull request reviews are automatically dismissed when new commits are pushed.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

pr-user-story-linked

Ensures all Pull Requests and Merge Requests reference a user story or issue for traceability

• Categories: Code Review
• Supported material types: CHAINLOOP_PR_INFO

Inputs

Name	Description	Required	Default
patterns	List of regex patterns to match issue references (comma-separated)	No	[A-Z]+-[0-9]+,#[0-9]+,[A-Z]{2,}-[0-9]+,gh-[0-9]+,\[[A-Z]+-[0-9]+\]

repository-rules-change-restricted

Validates that only authorized users and teams can modify repository protection rules.

• Categories: security
• Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
allowlist	Comma-separated list of allowed users/teams who can modify protection rules. If not specified, secure defaults apply (GitHub allows “admin”, GitLab allows “Maintainers”). - GitHub: Use format “user:username” or “team:teamname” (e.g., user:alice,team:security-team) - GitLab: Use user display names (e.g., Alice Smith,Bob Jones)	No	-
branches	Comma-separated list of branch patterns to check (supports glob patterns like main,feature/*). If not specified, all branches are checked. GitLab only.	No	-

runner-authenticated

Checks that runner is authenticated by using the OIDC token from the provider.

• Categories: security SLSA
• Supported material types: ATTESTATION
• Auto-match: Yes

Inputs

Name	Description	Required	Default
environment	Expected runner environment, i.e. github-hosted, managed.	No	-
runner_required	Set to true if the runner environment should be forced.	No	false

runner-automated

Checks that the CI runner is the expected one supporting Chainloop attestation.

• Categories: security SLSA
• Supported material types: ATTESTATION

Inputs

Name	Description	Required	Default
runner	Expected runner type, i.e. GITHUB_ACTION, GITLAB_PIPELINE	No	-

sast

Check Static Application Security Test (SAST) results for weaknesses. Supported Tools:

• BlackDuck Polaris (SARIF)
• Synopsys Coverity (SARIF)
• CodeQL (SARIF)
• OpenGrep OSS / Semgrep OSS (SARIF)
• SonarQube (GitLab Security Report format and Search API via EVIDENCE)

• Categories: security SAST
• Supported material types: EVIDENCE GITLAB_SECURITY_REPORT SARIF
• Auto-match: Yes

Inputs

Name	Description	Required	Default
severity		No	MEDIUM
score		No	-
issue_types	Comma-separated list of issue types to check (BUG, CODE_SMELL, VULNERABILITY)	No	-

sast-scan-present

Checks that a SAST scan material is present in the attestation. Supports Polaris, Coverity, SonarQube, and CodeQL SARIF reports, SonarQube GitLab Security Reports, and SonarQube Search API evidence.

• Categories: security SAST
• Supported material types: ATTESTATION

sbom-banned-components

Checks that the SBOM doesn’t have any banned components. It accepts a list of comma-separated list of components. If a version is specified, it will fail for versions equal or lower. with: components: log4j@2.14.1, banned-component-name”

• Categories: sbom security
• Supported material types: SBOM_CYCLONEDX_JSON

Inputs

Name	Description	Required	Default
components	Comma separated list of components to ban	No	-

sbom-banned-licenses

Checks SBOM components for banned SPDX licenses and custom/proprietary licenses. This policy validates software components against license compliance requirements by detecting specified banned SPDX license identifiers, flagging custom/proprietary licenses by default, and supporting exceptions. Supports CycloneDX 1.5+.

• Categories: sbom
• Supported material types: SBOM_CYCLONEDX_JSON

Inputs

Name	Description	Required	Default
licenses	Comma separated list of SPDX license identifiers to ban. Example: license=“AGPL-3.0-or-later,GPL” throws violation for components with license.id or expressions with: - AGPL-3.0-or-later since no other SPDX identrifier matches AGPL-3.0-or-later* - Any of the GPL variants that matches GPL*: GPL-1.0-only. GPL-1.0-or-later, GPL-2.0-only, GPL-2.0-or-later, GPL-3.0-only and GPL-3.0-or-later	No	-
allowed_custom_licenses	Comma separated list of custom license names that are allowed. Custom/proprietary licenses are banned by default unless explicitly allowed. Uses exact string matching (case-insensitive). Example: allowed_custom_licenses=“Commercial License, Proprietary ACME License”.	No	-
exceptions	Comma separated list of exception rules to allow specific components with banned licenses. Format: type::identifier::license_exception Example: “purl_type::pkg:deb::GPL,name::github.com/prometheus/procfs::sha*NOTICE(Apache-2.0)“	No	-

sbom-freshness

Checks that the SBOM is not older than a specified threshold. Supports CycloneDX. It accepts a limit argument denoting the number of days. If not provided, it will deactivate the policy: with: limit: 20

• Categories: sbom
• Supported material types: SBOM_CYCLONEDX_JSON
• Auto-match: Yes

Inputs

Name	Description	Required	Default
limit	Max SBOM age in days	No	-

sbom-ntia

Checks SBOM reports for NTIA SBOM Minimum Elements Report. Supports SPDX 2.3 and CycloneDX 1.4+. The policy ignores local files that do not originate from a package manager, such as a local script injected into the build process.

• Categories: security sbom
• Supported material types: SBOM_CYCLONEDX_JSON SBOM_SPDX_JSON

sbom-present

Checks that either a SPDX or CycloneDX SBOM material is present in the attestation

• Categories: sbom
• Supported material types: ATTESTATION

sbom-version

Verifies that the given SBOM report complies with a particular version or higher. It requires a version argument (default value for CycloneDX: 1.4)

• Categories: sbom
• Supported material types: SBOM_CYCLONEDX_JSON

Inputs

Name	Description	Required	Default
min_version	The minimum version of the SBOM to check	No	1.4

sbom-with-licenses

Checks for components with unknown licenses in the CycloneDX report

• Categories: sbom
• Supported material types: SBOM_CYCLONEDX_JSON

Inputs

Name	Description	Required	Default
skipped_types	Comma separated list of CycloneDX components type to skip validation (eg. files)	No	-

secrets-detection

Checks secrets scanning reports for leaked secrets. Supports GitLab, GHAS, and Gitleaks secrets reports

• Categories: security secrets
• Supported material types: GHAS_SECRET_SCAN GITLAB_SECURITY_REPORT GITLEAKS_JSON

signature-present

Checks that SLSA provenance signature is possibly present by verifying the CA and TSA presence.

• Categories: security SLSA
• Supported material types: ATTESTATION

Inputs

Name	Description	Required	Default
require_tsa	Whether TSA is required	No	false

source-commit

Verifies that the attestation explicitly references a specific Git commit

• Supported material types: ATTESTATION

Inputs

Name	Description	Required	Default
check_signature	Check that the commit has a valid digital signature	No	false
check_author_verified	Check that the commit author has been verified by the platform (GitHub, GitLab)	No	false
required_signature_algorithm	Require specific signature algorithm(s). Valid values are PGP, SSH, or X509. Accepts a single algorithm or comma-separated list (e.g., “PGP,SSH”). If set, the commit must include a signature.algorithm annotation matching one of the allowed values	No	-

vulnerabilities

Checks that the vulnerability severity or score, found in a vulnerabilities report, are above an input threshold. It supports a CVSS “score” input for numeric threshold, or “severity” for text-based severity. Compatible with SARIF (Trivy, Grype, Stackhawk, Prisma Cloud, WizCLI and Snyk), BlackDuck and TwistCLI formats

• Categories: security CVE
• Supported material types: BLACKDUCK_SCA_JSON GHAS_DEPENDENCY_SCAN SARIF SBOM_CYCLONEDX_JSON TWISTCLI_SCAN_JSON
• Auto-match: Yes

Inputs

Name	Description	Required	Default
severity		No	MEDIUM
score		No	-

vulnerability-scan-present

Checks that a supported SCA scan material is present in the attestation

• Categories: security CVE
• Supported material types: ATTESTATION

Policy Groups

branch-protection

This policy group enforces branch protection rules to ensure repository integrity. It includes policies that prevent branch deletion, force pushes, enforce linear history, and restrict who can modify protection rules. Supports both GitHub and GitLab. Read more about how to generate the needed material in the documentation.

• Categories: security

Inputs

Name	Description	Required	Default
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-
authorized_admins	Comma-separated list of authorized users/teams who can modify branch protection rules. If not specified, secure defaults apply (GitHub allows “admin”, GitLab allows “Maintainers”). - GitHub: Use format “user:username”, “collaborator:username”, or “team:teamname” (e.g., user:alice,team:security-team,collaborator:bob) - GitLab: Use user display names (e.g., Alice Smith,Bob Jones)	No	-

Material Policies

Material Name	Material Type	Policies
runner-context	CHAINLOOP_RUNNER_CONTEXT	branch-deletion-blocked branch-force-push-blocked branch-linear-history-required repository-rules-change-restricted

code-review

This policy group enforces code review requirements to ensure code quality. It includes policies that require pull request reviews and dismissal of stale reviews. Supports both GitHub and GitLab. Read more about how to generate the needed material in the documentation.

• Categories: security

Inputs

Name	Description	Required	Default
min_reviewers	Minimum number of reviewers required for pull requests.	No	1
branches	Comma-separated list of branch patterns to check (supports wildcards like main,dev*,release/*). If not specified, all branches are checked.	No	-

Material Policies

Material Name	Material Type	Policies
runner-context	CHAINLOOP_RUNNER_CONTEXT	pr-review-required pr-stale-reviews-dismissed

pr-quality

This policy group enforces pull request quality standards to ensure proper documentation and traceability. It includes policies that require meaningful PR descriptions and links to user stories or issues. Supports both GitHub and GitLab. Read more about how to capture PR information in the documentation.

• Categories: quality

Inputs

Name	Description	Required	Default
min_length	Minimum description length in characters.	No	50
allow_empty	Allow empty descriptions.	No	false
required_sections	List of required sections in description (comma-separated, case-insensitive).	No	-
patterns	List of regex patterns to match issue references (comma-separated).	No	[A-Z]+-[0-9]+,#[0-9]+,[A-Z]{2,}-[0-9]+,gh-[0-9]+,\[[A-Z]+-[0-9]+\]

Material Policies

Material Name	Material Type	Policies
pr-info	CHAINLOOP_PR_INFO	pr-description-required pr-user-story-linked

sast

This policy group applies Static Application Security Testing (SAST) related policies.

• Categories: security SAST

Inputs

Name	Description	Required	Default
severity	Minimum severity level for SAST findings (LOW, MEDIUM, HIGH, CRITICAL)	No	MEDIUM
score	Minimum CVSS score for SAST findings (0.0-10.0)	No	-

Attestation Policies

• sast-scan-present

Material Policies

Material Name	Material Type	Policies
-	Any	sast

sbom-quality

This policy group applies a number of SBOM-related policies

• Categories: SBOM

Inputs

Name	Description	Required	Default
bannedComponents	Comma separated list of components to ban	No	-
bannedLicenses	Comma separated list of licenses to ban	No	-
allowedCustomLicenses	Comma separated list of allowed custom licenses names	No	-
licenseExceptions	Comma separated list of exception rules to allow specific components with banned licenses. Format: type::identifier::license_exception	No	-
sbomFreshness	Max age in days	No	30
sbom_name	If provided, a CycloneDX material with the provided name will be required. Otherwise, any SBOM will be affected by this policy	No	-
skippedTypes	If provided, validation for empty licenses will be skipped for the specified CycloneDX SBOM component types (comma-separated, e.g. “file,framework”)	No	-

Attestation Policies

• sbom-present

Material Policies

Material Name	Material Type	Policies
{{ inputs.sbom_name }}	SBOM_CYCLONEDX_JSON	sbom-banned-licenses sbom-banned-components sbom-freshness sbom-ntia sbom-with-licenses

slsa-checks

This policy group applies a number of SLSA-related policies.

• Categories: SLSA

Inputs

Name	Description	Required	Default
runner	Check that the attestation was generated in a specific runner type.	No	-
environment	Specifies the expected runner environment, i.e. github-hosted, managed.	No	-
require_tsa	Specifies whether the TSA signature is required.	No	-

Attestation Policies

• runner-automated* runner-authenticated* signature-present

vulnerability-management

This policy group applies vulnerability management related policies.

• Categories: security CVE

Inputs

Name	Description	Required	Default
severity	Fixes for “critical” vulnerabilities are expected within a defined SLA defined in the requirements.	No	HIGH

Attestation Policies

• vulnerability-scan-present

Material Policies

Material Name	Material Type	Policies
-	Any	vulnerabilities