Policies

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.

ai-agent-present

Checks for AI agent presence via configuration materials in the attestation or known bot reviewers on the PR

Categories: ai
Supported material types: ATTESTATION CHAINLOOP_PR_INFO

ai-config-ai-agents-allowed

Verifies that the AI agent in the configuration is in the allowed list

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG CHAINLOOP_AI_CODING_SESSION

Inputs

Name	Description	Required	Default
`allowed_agents`	Comma-separated list of allowed AI agent names	Yes	-

ai-config-mcp-servers-allowed

Verifies that all MCP servers configured in an AI agent configuration or invoked during an AI coding session are in the allowed list

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG CHAINLOOP_AI_CODING_SESSION

Inputs

Name	Description	Required	Default
`allowed_servers`	Comma-separated list of allowed MCP server names	Yes	-

ai-config-no-dangerous-commands

Detects dangerous or destructive shell commands in AI coding session transcripts (assistant Bash tool calls) and AI agent configuration files (instructions, skills, subagents, MCP config)

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG CHAINLOOP_AI_CODING_SESSION

Inputs

Name	Description	Required	Default
`forbidden_patterns`	Comma-separated list of regular expressions flagged as dangerous. Commas are not allowed inside a pattern. A sensible default covering destructive ops, curl	sh bypasses, and escalation attempts is used when omitted.	No	-

ai-config-no-secrets

Verifies that AI agent configuration files (instructions, skills, MCP config) and AI coding session transcripts do not contain hardcoded secrets such as API keys, tokens, passwords, or credentials

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG CHAINLOOP_AI_CODING_SESSION

ai-instructions-architecture-with-paths

Verifies that AI agent instruction files describe the project architecture by referencing at least one directory path and naming an architectural pattern

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate architecture description in instruction files	No	-

ai-instructions-code-style-specificity

Verifies that AI agent instruction files contain at least one concrete, project-specific code style rule referencing a specific linter, formatter, or language pattern

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate code style specificity in instruction files	No	-

ai-instructions-commands-documented

Verifies that AI agent instruction files specify exact, executable commands for each required action rather than vague instructions

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`actions`	Comma-separated list of actions that must have exact commands documented	No	-

ai-instructions-doc-guidance

Verifies that AI agent instruction files reference documentation practices — where docs live, what format to use, and how to keep READMEs and inline comments relevant

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate documentation guidance in instruction files	No	-

ai-instructions-explicit-boundaries

Verifies that AI agent instruction files define explicit behavioral boundaries — concrete paths or actions the agent must not access or perform

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate behavioral boundary definitions in instruction files	No	-

ai-instructions-git-workflow-documented

Verifies that AI agent instruction files document at least two git workflow conventions — branch naming, commit message format, or PR requirements

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate git workflow convention documentation in instruction files	No	-

ai-instructions-gotchas

Verifies that AI agent instruction files document at least two project-specific gotchas — non-obvious behaviors, edge cases, or pitfalls the agent would get wrong without explicit guidance

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate gotcha documentation in instruction files	No	-

ai-instructions-size-bounds

Checks that each instruction/skill file in an AI agent configuration has a line count within configurable bounds (instructions default max 200, skills default max 500)

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG
Auto-match: Yes

Inputs

Name	Description	Required	Default
`min_lines`	Minimum number of lines required (default 10, applies to all kinds)	No	-
`max_lines`	Maximum number of lines allowed, overrides kind-specific defaults (instruction=200, skill=500)	No	-

ai-instructions-verification-criteria

Verifies that AI agent instruction files include verification mechanisms such as unit tests, executable test commands, or expected input/output examples

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt for verifying instruction files contain verification criteria	No	-

ai-skills-descriptions-actionable

Verifies that each AI agent skill describes what it does, when to use it, and what problems it solves

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate skill descriptions	No	-

ai-subagents-descriptions-actionable

Verifies that each AI agent subagent has a description specifying trigger, scope, and purpose, and that system prompts are substantive

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

Inputs

Name	Description	Required	Default
`prompt`	Custom prompt to evaluate subagent descriptions	No	-

ai-subagents-permissions-scope

Verifies that no subagent sets permissionMode to bypassPermissions or declares MCP servers absent from parent configuration

Categories: ai
Supported material types: CHAINLOOP_AI_AGENT_CONFIG

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
`framework_name`	Framework name or comma-separated list of framework names to check compliance for (case-insensitive). If not provided, all frameworks will be checked.	No	-
`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 2025 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, Opengrep, SonarQube and CodeQL
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 2025 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, Opengrep, SonarQube and CodeQL
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 and WizCLI. Both tools map their native severity to the standard SARIF result.level field:

error: Checkov errors, WizCLI high/critical findings
warning: Checkov warnings, WizCLI medium findings
note: Checkov notes, WizCLI low/informational findings

Categories: security IAC
Supported material types: SARIF

Inputs

Name	Description	Required	Default
`severity`	The severity level to filter the scan results. Results at or above this level are reported as violations. Possible values are `note`, `warning`, `error`.	No	`warning`

iac-scan-present

Checks that an IaC scan material is present in the attestation. Supports WizCLI and Checkov SARIF reports.

Categories: security IAC
Supported material types: ATTESTATION

immutable-releases-enabled

Verifies that GitHub Immutable Releases is enabled for the repository. When enabled, published release artifacts and their associated tags cannot be modified or deleted, protecting the integrity of the software supply chain. This is a GitHub-specific feature; the policy skips on GitLab repositories.

Categories: security
Supported material types: CHAINLOOP_RUNNER_CONTEXT

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. Supported Tools:

SARIF: KICS, SpotBugs, ZAP, StackHawk, Polaris, Semgrep, Opengrep, SonarQube and CodeQL
GitLab Security Reports: SonarQube

Categories: security CWE
Supported material types: GITLAB_SECURITY_REPORT SARIF

patch-policy-present

Verifies that automated patch management tooling is configured and actively monitoring third-party dependencies for known vulnerabilities. On GitHub, checks that Dependabot security updates are enabled via the repository’s security_and_analysis settings. On GitLab, checks for the presence of a Renovate configuration file (renovate.json, renovate.json5, .renovaterc, or .renovaterc.json).

Categories: security patch-management
Supported material types: CHAINLOOP_RUNNER_CONTEXT

pr-bot-author-allowed

Verifies that a PR/MR was authored by one of the allowed bot accounts. Useful for gating workflows to only accept PRs from automated tools such as Dependabot or Renovate. On GitHub, checks the user type field; on GitLab, reads the author.bot field from the Merge Request API. Defaults to dependabot[bot] and renovate[bot] if no allowed_bots input is provided. These defaults use GitHub-style names; GitLab users should specify their bot usernames explicitly or use GitLab service accounts. See the bot PR guide for platform-specific setup.

Categories: security automation
Supported material types: CHAINLOOP_PR_INFO

Inputs

Name	Description	Required	Default
`allowed_bots`	Comma-separated list of allowed bot author names. If not specified, defaults to dependabot[bot] and renovate[bot]. Note that these defaults use GitHub-style names with the [bot] suffix; GitLab usernames typically do not include this suffix.	No	-

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 (SARIF, 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: [email protected], 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	-
`check_author_verified`	Check that the commit author has been verified by the platform (GitHub, GitLab)	No	-
`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	-

tag-deletion-blocked

Ensures that tag deletion is blocked to protect release tags from being removed or replaced. Supports both GitHub and GitLab.

Categories: security
Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
`tags`	Comma-separated list of tag patterns to check. If not specified, all tags are checked. Uses glob matching where * does not cross dot (.) boundaries. For version tags like v1.45.0, use v** (double star) instead of v* to match across dots.	No	-

tag-force-push-blocked

Ensures that force pushes are blocked on tags to prevent tag manipulation attacks (such as the Trivy supply chain attack). Supports both GitHub and GitLab.

Categories: security
Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
`tags`	Comma-separated list of tag patterns to check. If not specified, all tags are checked. Uses glob matching where * does not cross dot (.) boundaries. For version tags like v1.45.0, use v** (double star) instead of v* to match across dots.	No	-

tag-rules-change-restricted

Validates that only authorized actors can bypass tag protection rules. Checks bypass_configuration on tag rulesets to ensure only approved roles, teams, or users can bypass protections. Supports GitHub only (GitLab tag protection uses access levels checked via create_access_levels).

Categories: security
Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

Name	Description	Required	Default
`allowlist`	Comma-separated list of allowed actors who can bypass tag protection rules. If not specified, no bypass actors are allowed. Use format “role:RoleName”, “team:teamname”, or “user:username” (e.g., role:Repository Admin,team:release-team)	No	-
`tags`	Comma-separated list of tag patterns to check. If not specified, all tags are checked. Uses glob matching where * does not cross dot (.) boundaries. For version tags like v1.45.0, use v** (double star) instead of v* to match across dots.	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-code-owner-review-required pr-conversation-resolution-required

cwes

This policy group applies CWE-related policies: CWE Top 25 Most Dangerous Software Weaknesses and CWE On the Cusp (ranked 26–40). Use it to enforce that source or dependency scans are free from these common weaknesses.

Categories: security CWE

Material Policies

Material Name	Material Type	Policies
-	Any	cwe-top25 cwe-top26-40-cusp

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

tag-protection

This policy group enforces tag protection rules to prevent tag manipulation attacks such as the Trivy supply chain attack. It includes policies that prevent tag deletion, force pushes on tags, and restrict who can bypass tag 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
`tags`	Comma-separated list of tag patterns to check. If not specified, all tags are checked. Uses glob matching where * does not cross dot (.) boundaries. For version tags like v1.45.0, use v** (double star) instead of v* to match across dots.	No	-
`authorized_bypass`	Comma-separated list of actors authorized to bypass tag protection rules. If not specified, no bypass actors are allowed. Use format “role:RoleName”, “team:teamname”, or “user:username” (e.g., role:Repository Admin,team:release-team)	No	-

Material Policies

Material Name	Material Type	Policies
`runner-context`	`CHAINLOOP_RUNNER_CONTEXT`	tag-deletion-blocked tag-force-push-blocked tag-rules-change-restricted

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

Getting Started

Concepts

Guides

References

Misc

Documentation Index

​Policies

​ai-agent-present

​ai-config-ai-agents-allowed

Inputs

​ai-config-mcp-servers-allowed

Inputs

​ai-config-no-dangerous-commands

Inputs

​ai-config-no-secrets

​ai-instructions-architecture-with-paths

Inputs

​ai-instructions-code-style-specificity

Inputs

​ai-instructions-commands-documented

Inputs

​ai-instructions-doc-guidance

Inputs

​ai-instructions-explicit-boundaries

Inputs

​ai-instructions-git-workflow-documented

Inputs

​ai-instructions-gotchas

Inputs

​ai-instructions-size-bounds

Inputs

​ai-instructions-verification-criteria

Inputs

​ai-skills-descriptions-actionable

Inputs

​ai-subagents-descriptions-actionable

Inputs

​ai-subagents-permissions-scope

​artifact-signed

​artifact-tag-not-latest

​binary-scan

Inputs

​branch-deletion-blocked

Inputs

​branch-force-push-blocked

Inputs

​branch-linear-history-required

Inputs

​check-compliance-requirement

Inputs

​ci-user-strongly-authenticated

​code-coverage

Inputs

​commits-signed-required

Inputs

​containers-with-sbom

Inputs

​cves-in-kev

​cwe-top25

​cwe-top26-40-cusp

​evidence-prompt

Inputs

​iac-misconfiguration

Inputs

​iac-scan-present

​immutable-releases-enabled

​material-present

Inputs

​owasp-top10-2021

​owasp-top10-2025

​patch-policy-present

​pr-bot-author-allowed

Inputs

​pr-code-owner-review-required

Inputs

​pr-conversation-resolution-required

Inputs

​pr-description-required

Inputs

​pr-review-required

Policies

ai-agent-present

ai-config-ai-agents-allowed

ai-config-mcp-servers-allowed

ai-config-no-dangerous-commands

ai-config-no-secrets

ai-instructions-architecture-with-paths

ai-instructions-code-style-specificity

ai-instructions-commands-documented

ai-instructions-doc-guidance

ai-instructions-explicit-boundaries

ai-instructions-git-workflow-documented

ai-instructions-gotchas

ai-instructions-size-bounds

ai-instructions-verification-criteria

ai-skills-descriptions-actionable

ai-subagents-descriptions-actionable

ai-subagents-permissions-scope

artifact-signed

artifact-tag-not-latest

binary-scan

branch-deletion-blocked

branch-force-push-blocked

branch-linear-history-required

check-compliance-requirement

ci-user-strongly-authenticated

code-coverage

commits-signed-required

containers-with-sbom

cves-in-kev

cwe-top25

cwe-top26-40-cusp

evidence-prompt

iac-misconfiguration

iac-scan-present

immutable-releases-enabled

material-present

owasp-top10-2021

owasp-top10-2025

patch-policy-present

pr-bot-author-allowed

pr-code-owner-review-required

pr-conversation-resolution-required

pr-description-required

pr-review-required

pr-stale-reviews-dismissed

pr-user-story-linked

repository-rules-change-restricted

runner-authenticated

runner-automated

sast

sast-scan-present

sbom-banned-components

sbom-banned-licenses

sbom-freshness

sbom-ntia

sbom-present

sbom-version

sbom-with-licenses

secrets-detection

signature-present

source-commit

tag-deletion-blocked

tag-force-push-blocked

tag-rules-change-restricted

vulnerabilities

vulnerability-scan-present

Policy Groups

branch-protection

code-review

cwes

pr-quality

sast

sbom-quality

slsa-checks

tag-protection

vulnerability-management