> ## 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.
# Policies
> Reference documentation for all available policies and policy groups
This feature is only available on Chainloop's platform [paid plans](https://chainloop.dev/pricing).
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
### 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`
### api-security
Check **API security** posture findings for weaknesses above a severity threshold.
Supported Tools:
* **Salt Security** (SARIF, API posture gaps)
- **Categories:** `security` `API`
- **Supported material types:** `SARIF`
##### Inputs
| Name | Description | Required | Default |
| ---------- | ----------- | -------- | -------- |
| `severity` | | No | `MEDIUM` |
| `score` | | No | - |
### api-security-scan-present
Checks that an API security scan material is present in the attestation. Supports Salt Security SARIF reports.
* **Categories:** `security` `API`
* **Supported material types:** `ATTESTATION`
### 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](https://www.jacoco.org/jacoco/trunk/doc/counters.html)
* **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](https://www.cisa.gov/known-exploited-vulnerabilities-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](https://cwe.mitre.org/top25/index.html) for the complete list.
**Supported Tools:**
* **SARIF**: KICS, SpotBugs, ZAP, StackHawk, Polaris, Semgrep, Opengrep, SonarQube, CodeQL and Salt Security
* **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 **2026 CWE On the Cusp** list (CWEs ranked 26-40).
See the [CWE On the Cusp](https://cwe.mitre.org/top25/archive/2025/2025_onthecusp_list.html) for the complete list.
**Supported Tools:**
* **SARIF**: KICS, SpotBugs, ZAP, StackHawk, Polaris, Semgrep, Opengrep, SonarQube, CodeQL and Salt Security
* **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-api-top10
Maps CWEs from API security posture findings to [OWASP API Security Top 10 (2023)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) categories.
Reports a violation when the number of covered categories is below the `min_coverage` threshold.
**Supported Tools:**
* **SARIF**: Salt Security
- **Categories:** `security` `API` `OWASP`
- **Supported material types:** `SARIF`
##### Inputs
| Name | Description | Required | Default |
| -------------- | ------------------------------------------------------------------------------------------- | -------- | ------- |
| `min_coverage` | Minimum number of OWASP API Top 10 categories that must have active posture coverage (1-10) | No | `8` |
### owasp-top10-2021
Checks for CWEs included in the [OWASP Top10:2021 list](https://owasp.org/Top10). It works with Gitlab SAST Reports generated with [SonarQube](https://next.sonarqube.com/sonarqube/web_api/api/issues/gitlab_sast_export)
* **Categories:** `security` `CWE`
* **Supported material types:** `GITLAB_SECURITY_REPORT`
### owasp-top10-2025
Checks for CWEs included in the [OWASP Top10:2025 list](https://owasp.org/Top10/2025/).
**Supported Tools:**
* **SARIF**: KICS, SpotBugs, ZAP, StackHawk, Polaris, Semgrep, Opengrep, SonarQube, CodeQL and Salt Security
* **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](https://docs.app.chainloop.dev/guides/pr-policies-control-gate#gating-bot-authored-prs)
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](https://docs.chainloop.dev/concepts/material-types#example-importing-issues-from-the-sonarqube-api) via EVIDENCE)
* **Spectral / AsyncAPI CLI / graphql-eslint** (SARIF, web API spec validation)
- **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](https://docs.chainloop.dev/concepts/material-types#example-importing-issues-from-the-sonarqube-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](https://spdx.org/licenses/index.html) 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](https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf). 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`
### webapi-validation-clean
Evaluates SARIF 2.1.0 web API validation reports and checks for results at or above a severity threshold.
Default threshold is `error`. Can be set to `warning` or `note` to catch lower-severity issues.
Extracts the tool name from `runs[0].tool.driver.name` for reporting.
* **Categories:** `security` `API`
* **Supported material types:** `SARIF`
##### Inputs
| Name | Description | Required | Default |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `severity` | The severity level to filter the validation results. Results at or above this level are reported as violations. Possible values are `note`, `warning`, `error`.
| No | `error` |
### webapi-validation-present
Checks that a web API specification material is present in the attestation. Supports OpenAPI, AsyncAPI, and GraphQL specifications.
* **Categories:** `security` `API`
* **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](https://docs.chainloop.dev/reference/runner-context#gathering-runner-context).
* **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-deletion-blocked) [branch-force-push-blocked](#branch-force-push-blocked) [branch-linear-history-required](#branch-linear-history-required) [repository-rules-change-restricted](#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](https://docs.chainloop.dev/reference/runner-context#gathering-runner-context).
* **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-review-required) [pr-stale-reviews-dismissed](#pr-stale-reviews-dismissed) [pr-code-owner-review-required](#pr-code-owner-review-required) [pr-conversation-resolution-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-top25) [cwe-top26-40-cusp](#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](https://docs.chainloop.dev/guides/pr-policies-control-gate).
* **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-description-required) [pr-user-story-linked](#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](#sast-scan-present)
##### Material Policies
| Material Name | Material Type | Policies |
| ------------- | ------------- | ------------- |
| - | Any | [sast](#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](#sbom-present)
##### Material Policies
| Material Name | Material Type | Policies |
| ------------------------ | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `{{ inputs.sbom_name }}` | `SBOM_CYCLONEDX_JSON` | [sbom-banned-licenses](#sbom-banned-licenses) [sbom-banned-components](#sbom-banned-components) [sbom-freshness](#sbom-freshness) [sbom-ntia](#sbom-ntia) [sbom-with-licenses](#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-automated)\* [runner-authenticated](#runner-authenticated)\* [signature-present](#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](https://docs.chainloop.dev/reference/runner-context#gathering-runner-context).
* **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-deletion-blocked) [tag-force-push-blocked](#tag-force-push-blocked) [tag-rules-change-restricted](#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](#vulnerability-scan-present)
##### Material Policies
| Material Name | Material Type | Policies |
| ------------- | ------------- | ----------------------------------- |
| - | Any | [vulnerabilities](#vulnerabilities) |