> ## 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
### activex-controls-fuzzed
Verify that Windows ActiveX/COM controls were fuzz-tested with the CERT/CC
Dranzer tool and that no control failed, hung, or crashed during the run.
Any failed or hung object, or any crash finding (access violation, Win32
exception, or error), is a candidate for `!Exploitable` triage and must be
remediated prior to Product release.
* **Categories:** `security` `compliance`
* **Supported material types:** `CERTCC_DRANZER`
### 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`
##### Inputs
| Name | Description | Required | Default |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `ignored_paths` | Comma-separated list of regular expressions. Findings whose source file path matches are skipped. Commas are NOT allowed inside a pattern. For coding sessions this matches against the file path of the preceding Read/Write/Edit/MultiEdit tool\_use; chunks without an associated file path (user prompts, assistant text, Bash output, etc.) are never excluded. | No | - |
### 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-compiler-hardening
Checks BinSkim compiler-hardening results (ASLR, secure tools, critical warnings, ...) for every analyzed binary.
A binary BinSkim could not evaluate because its PDB (debug symbols) could not be loaded (`E_PDB_NOT_FOUND`) always fails: its hardening configuration cannot be verified without symbols. For binaries that were analyzed, the policy raises a violation for each hardening rule finding that matches the configured `rules` and meets the `severity` threshold.
Supports BinSkim SARIF format.
* **Categories:** `security` `binaries`
* **Supported material types:** `SARIF`
##### Inputs
| Name | Description | Required | Default |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `rules` | List of specific hardening rules to check. Supports two formats:
- `RuleId` - checks all severity levels of that rule (e.g., `BA2001`)
- `RuleId;Level` - checks only the specific rule+level combination (e.g., `BA2001;error`)
If not specified, all rule findings meeting the severity threshold are checked.
| No | - |
| `severity` | The minimum severity level to report for rule findings. Possible values are `none`, `note`, `warning`, `error`. Does not affect the `E_PDB_NOT_FOUND` gate, which always fails.
| No | `error` |
| `paths` | Comma-separated list of path globs the policy applies to. Matching is case-insensitive and treats both `\` and `/` as path separators. Defaults to all files (`**`).
| No | - |
| `ignored_paths` | Comma-separated list of path globs to exclude from the check, evaluated after `paths`.
| No | - |
### binary-scan
Checks binary scan reports for security and correctness errors, including BinSkim tool notifications (e.g. PDB-load failures that prevent a binary from being analyzed). 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` |
### binary-symbols-stripped
Verifies that release binaries in a BinSkim SARIF report are stripped of debug symbols.
BinSkim reports a binary it could not analyze because its PDB (debug symbols) could not be loaded as an `ERR997.ExceptionLoadingPdb` / `E_PDB_NOT_FOUND` tool notification. This policy treats that as the desired state: a stripped release binary. Conversely, any binary BinSkim was able to analyze (its PDB loaded, so debug symbols are present) raises a violation.
Each scanned binary is evaluated individually. The set of scanned binaries is taken from the report's `artifacts` list when present, falling back to the binaries referenced by analysis results.
* **Categories:** `security` `binaries`
* **Supported material types:** `SARIF`
##### Inputs
| Name | Description | Required | Default |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `paths` | Comma-separated list of path globs the policy applies to. Matching is case-insensitive and treats both `\` and `/` as path separators. Defaults to all files (`**`).
| No | - |
| `ignored_paths` | Comma-separated list of path globs to exclude from the check, evaluated after `paths`.
| No | - |
### 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-pipeline-security
Checks CI/CD pipeline configuration security scan results for findings.
Supported Tools:
* **zizmor** (SARIF) — GitHub Actions workflow security auditor
- **Categories:** `security` `CI/CD`
- **Supported material types:** `SARIF`
##### Inputs
| Name | Description | Required | Default |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------- |
| `severity` | The minimum severity to report as a violation. Findings at or above this level are reported. Possible values (zizmor's native severity scale) are `informational`, `low`, `medium`, `high`.
| No | `medium` |
### 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, GHAS Dependency Scans and CycloneDX SBOM outputs.
* **Categories:** `security` `CVE`
* **Supported material types:** `BLACKDUCK_SCA_JSON` `GHAS_DEPENDENCY_SCAN` `SARIF` `SBOM_CYCLONEDX_JSON`
### 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-2019
Checks for CWEs included in the [OWASP API Security Top 10 (2019) list](https://owasp.org/API-Security/editions/2019/en/0x11-t10/).
**Supported Tools:**
* **SARIF**: Salt Security
- **Categories:** `security` `API` `OWASP`
- **Supported material types:** `SARIF`
### owasp-api-top10-2023
Checks for CWEs included in the [OWASP API Security Top 10 (2023) list](https://owasp.org/API-Security/editions/2023/en/0x11-t10/).
**Supported Tools:**
* **SARIF**: Salt Security
- **Categories:** `security` `API` `OWASP`
- **Supported material types:** `SARIF`
### owasp-top10-2021
Checks for CWEs included in the [OWASP Top10:2021 list](https://owasp.org/Top10).
**Supported Tools:**
* **SARIF**: ZAP
* **GitLab Security Reports**: SonarQube
- **Categories:** `security` `CWE`
- **Supported material types:** `GITLAB_SECURITY_REPORT` `SARIF`
### 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]+\]` |
### radamsa-min-iterations
Verify that a radamsa fuzzing run generated at least a minimum number of
iterations. Evaluates radamsa's `-M` metadata log (RADAMSA\_REPORT), where
every generated test case is one record, and fails the gate when the run
produced fewer iterations than required. Use it to prove a target was
fuzzed with meaningful coverage rather than for a token handful of cases.
* **Categories:** `security` `compliance`
* **Supported material types:** `RADAMSA_REPORT`
##### Inputs
| Name | Description | Required | Default |
| ---------------- | ---------------------------------------------------------------- | -------- | -------- |
| `min_iterations` | Minimum number of fuzzing iterations the radamsa run must record | No | `100000` |
### radamsa-no-crashes
Verify that a radamsa fuzzing run produced no crashing inputs. Chainloop only
attaches a RADAMSA\_CRASHES material when radamsa actually found crashes — a
clean run has nothing to attest — so the mere presence of that material in the
attestation is the failure signal.
* **Categories:** `security` `compliance`
* **Supported material types:** `ATTESTATION`
### 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-bsi-component-fields
BSI TR-03183-2 §5.2.2/§5.2.4/§5.2.5 — Validates per-component data fields. By default only Required fields (§5.2.2) gate: component creator, name, version, filename, distribution licences, SHA-512 deployable hash. Set the 'enforce' input to also gate Additional (§5.2.4 — source/deployable URIs, unique identifiers, declared licences) and/or Optional (§5.2.5 — effective licence, source hash, security.txt URL) categories.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
##### Inputs
| Name | Description | Required | Default |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | ------- |
| `enforce` | Comma-separated list of additional BSI categories to gate on, beyond the always-enforced Required (§5.2.2). Accepted values: "additional" (§5.2.4), "optional" (§5.2.5). Leave empty to gate only Required fields. | No | - |
### sbom-bsi-creator
BSI TR-03183-2 §5.2.1 — SBOM MUST identify its creator by email address or URL. Checks 'metadata.manufacturer' and 'metadata.authors\[]' on the CycloneDX SBOM and 'metadata.timestamp'.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
### sbom-bsi-dependencies
BSI TR-03183-2 §5.1 — Every component MUST enumerate its direct dependencies and the SBOM MUST declare dependency-graph completeness via 'compositions\[].aggregate'.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
### sbom-bsi-format
BSI TR-03183-2 §4 — A newly generated or updated SBOM shall be a valid CycloneDX document in JSON format, version 1.6 or higher. Fires a violation for CycloneDX below 1.6.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
### sbom-bsi-licenses
BSI TR-03183-2 §6.1 — Licence identifiers MUST use SPDX expressions. Validates that every component licence uses a valid SPDX ID, a 'LicenseRef-' / 'LicenseRef-scancode-' reference, or an SPDX expression using only AND/OR/WITH operators.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
### sbom-bsi-no-vulns
BSI TR-03183-2 §3.1 — SBOMs MUST NOT contain vulnerability information. Vulnerabilities belong in a separate VEX document.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
### sbom-bsi-properties
BSI TR-03183-2 §5.2.2 — Components MUST declare BSI taxonomy properties classifying them as executable/non-executable, archive/no archive, and structured/unstructured.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
### sbom-bsi-sbom-uri
BSI TR-03183-2 §5.2.3 Additional — Each SBOM SHOULD carry a unique identifier (SBOM-URI). For CycloneDX this is the 'serialNumber' field in BOM-Link format (urn:uuid:...). The SBOM-URI is an Additional data field; this policy is silent by default. Set 'enforce' to 'additional' to surface violations and gate on absence.
* **Categories:** `sbom` `compliance` `bsi`
* **Supported material types:** `SBOM_CYCLONEDX_JSON`
##### Inputs
| Name | Description | Required | Default |
| --------- | ------------------------------------------------------------------------------------------------ | -------- | ------- |
| `enforce` | Set to "additional" to gate on SBOM-URI absence (§5.2.3). Leave empty to keep the policy silent. | 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 | - |
### sca-scan-present
Checks that a Software Composition Analysis (SCA) material is present in the attestation. Compatible with SPDX, CycloneDX and BlackDuck SCA formats
* **Categories:** `security` `compliance`
* **Supported material types:** `ATTESTATION`
### secrets-detection
Checks secrets scanning reports for leaked secrets. Supports GitLab, GHAS, Gitleaks, and detect-secrets reports
* **Categories:** `security` `secrets`
* **Supported material types:** `GHAS_SECRET_SCAN` `GITLAB_SECURITY_REPORT` `GITLEAKS_JSON` `YELP_DETECT_SECRETS_BASELINE`
### 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 | - |
### trusted-binaries-authenticode-signed
DEPRECATED: use `trusted-binaries-signed` instead. As of `trusted-binaries-signed` v2 the extension filter is optional, so that policy now covers this exact check — omit `extensions` to check every in-scope file (this policy's behavior), or supply `extensions` to restrict to specific file types. This policy is retained only for backward compatibility and will be removed in a future release.
Verifies that binaries listed in a Sysinternals sigcheck manifest are digitally signed and that the signature belongs to an expected publisher.
For every in-scope file the policy raises a violation when the file is not signed, or when it is signed by a publisher other than the expected one. The expected publisher is matched (case-insensitive substring) against both the sigcheck `Publisher` (the Authenticode signer) and `Company` columns, since the two often carry slightly different forms of the same organization name.
Use `paths` / `ignored_paths` to scope the check to the binaries that must be signed (for example, excluding operating-system files). The signature attributes are the only thing derivable from the manifest; complementary controls such as malware scanning or chain-of-custody are evidenced by the manifest itself, not enforced here.
* **Categories:** `security` `binaries` `compliance`
* **Supported material types:** `SYSINTERNALS_SIGCHECK`
##### Inputs
| Name | Description | Required | Default |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `publisher` | Comma-separated list of expected Authenticode publisher names. A file passes when its `Publisher` or `Company` column contains any of these values (case-insensitive substring). Example: publisher="Contoso, Contoso Inc".
| Yes | - |
| `paths` | Comma-separated list of path globs the policy applies to. Matching is case-insensitive and treats both `\` and `/` as path separators. Defaults to all files (`**`). Example: paths="c:/program files/contoso/\*\*".
| No | - |
| `ignored_paths` | Comma-separated list of path globs to exclude from the check, evaluated after `paths`. Example: ignored\_paths="c:/windows/\*\*".
| No | - |
### trusted-binaries-signed
Verifies that the binaries built for a product are digitally signed.
By default the check applies to every in-scope file. Supply `extensions` to restrict it to a specific set of file types (for example, the Authenticode-supported `exe,dll,ocx,ctl,cat,cab,msi,xpi`). Every in-scope file that is not signed raises a violation. When `publisher` is set, in-scope files must additionally be signed by one of the expected publishers, matched (case-insensitive substring) against both the sigcheck `Publisher` and `Company` columns.
Use `paths` / `ignored_paths` to restrict the check to the files produced by the build (for example, the installation directory), and `extensions` to limit it to specific file types.
Changelog:
* v2 (behavior change): the `extensions` filter is now optional. Omitting it no longer applies the built-in Authenticode extension set — instead all in-scope files are checked. Supply `extensions` explicitly to restrict the check to specific file types.
- **Categories:** `security` `binaries` `compliance`
- **Supported material types:** `SYSINTERNALS_SIGCHECK`
##### Inputs
| Name | Description | Required | Default |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `extensions` | Comma-separated extensions to restrict the check to. Omitted → no extension filter (all in-scope files are checked).
| No | - |
| `publisher` | Comma-separated list of expected publisher names. When set, in-scope signed files must match one of these (case-insensitive substring against the `Publisher` or `Company` column). When omitted, any valid signature is accepted. Example: publisher="Contoso, Contoso Inc".
| No | - |
| `paths` | Comma-separated list of path globs the policy applies to. Matching is case-insensitive and treats both `\` and `/` as path separators. Defaults to all files (`**`). Example: paths="c:/program files/contoso/\*\*".
| No | - |
| `ignored_paths` | Comma-separated list of path globs to exclude from the check, evaluated after `paths`. Example: ignored\_paths="c:/windows/\*\*".
| No | - |
### trusted-binaries-timestamp
Verifies that signed binaries in a Sysinternals sigcheck manifest carry a signature timestamp.
For every in-scope file that is signed, the policy raises a violation when the sigcheck `Date` column (the signing timestamp) is empty or `n/a`. Unsigned files are ignored, since there is no signature to timestamp.
The manifest must include the `Date` column for the check to be meaningful: if no record carries a `Date` column the policy is skipped rather than reporting false positives, so run sigcheck with its default columns (the `Date` column is included by default).
* **Categories:** `security` `binaries` `compliance`
* **Supported material types:** `SYSINTERNALS_SIGCHECK`
##### Inputs
| Name | Description | Required | Default |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `paths` | Comma-separated list of path globs the policy applies to. Matching is case-insensitive and treats both `\` and `/` as path separators. Defaults to all files (`**`). Example: paths="c:/program files/contoso/\*\*".
| No | - |
| `ignored_paths` | Comma-separated list of path globs to exclude from the check, evaluated after `paths`. Example: ignored\_paths="c:/windows/\*\*".
| No | - |
### trusted-binaries-vendor-keys
Verifies that third-party / redistributed binaries are not signed with the organization's own signing key.
Third-party components must be redistributed with the signature (or lack thereof) established by the party that built them; they must never be re-signed with the organization's key. The policy flags any file under `third_party_paths` that is signed and whose `Publisher` or `Company` column matches the organization identity given in `publisher`.
Matching is case-insensitive substring against both columns, so slightly different forms of the same organization name (for example `Contoso Inc` vs `Contoso, Inc.`) are both detected.
* **Categories:** `security` `binaries` `compliance`
* **Supported material types:** `SYSINTERNALS_SIGCHECK`
##### Inputs
| Name | Description | Required | Default |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `publisher` | Comma-separated list of the organization's own publisher names. Any third-party file signed with one of these (matched case-insensitive substring against the `Publisher` or `Company` column) is a violation. Example: publisher="Contoso, Contoso Inc".
| Yes | - |
| `third_party_paths` | Comma-separated list of path globs identifying third-party / redistributed binaries. Matching is case-insensitive and treats both `\` and `/` as path separators. Example: third\_party\_paths="**/vendor/**,**/redist/**".
| Yes | - |
| `ignored_paths` | Comma-separated list of path globs to exclude from the check, evaluated after `third_party_paths`.
| 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 | - |
| `suppress_assessed` | Skip the gate for violations whose effective assessment status is NOT\_AFFECTED. | No | `true` |
### vulnerability-scan-present
Checks that a supported SCA scan material is present in the attestation.
Compatible with SARIF (Trivy, Grype, Stackhawk, TwistCLI, Snyk and WizCLI), BlackDuck, GHAS Dependency Scan and CycloneDX with vulnerabilities formats
* **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`
### webserver-response-headers
Gates an OWASP ZAP (DAST) SARIF report on the presence of one or more specific
ZAP **rule IDs**. Configure the rule ID(s) via the `zap_rule_ids` input
(comma-separated); the presence of any configured rule ID in the report is a violation.
This is a generic, fine-grained gate: point it at the exact ZAP rule ID(s) you care
about instead of a broad CWE bucket. One common use is gating individual webserver
response-header checks (X-Content-Type-Options, HSTS, CSP, Permissions-Policy, HttpOnly,
SameSite, fingerprinting) independently, since each maps to a distinct ZAP rule ID.
Reads rule IDs directly, so it works across ZAP 2.15 – 2.17+ regardless of the
version-dependent CWE taxonomy. ZAP's "-N" alert-variant suffix is stripped before
matching (so "10038-1" matches a configured "10038").
**Supported Tools:**
* **SARIF**: OWASP ZAP (2.15 – 2.17+)
- **Categories:** `security` `DAST`
- **Supported material types:** `SARIF`
##### Inputs
| Name | Description | Required | Default |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `zap_rule_ids` | Comma-separated ZAP rule ID(s) whose presence in the report counts as a violation
(e.g. "10038,10055"). ZAP's "-N" alert-variant suffix is stripped before matching.
| Yes | - |
## 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) |
### pr-validation
Unified PR validation policy group covering both bot-authored and human-authored PRs.
Policies self-select based on author type: bot-specific policies skip for human authors
and vice versa. 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` `security` `automation`
##### 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]. | No | - |
| `min_length` | Minimum description length in characters. | No | `50` |
| `allow_empty` | Allow empty descriptions. | No | `false` |
| `required_sections` | 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]+\]` |
| `allowed_agents` | Comma-separated list of allowed AI agent names. | Yes | `__CHANGE_ME__` |
| `allowed_servers` | Comma-separated list of allowed MCP server names. | Yes | `__CHANGE_ME__` |
| `ignored_paths` | Comma-separated list of regular expressions for paths to ignore in AI secret scanning. | No | - |
| `min_lines` | Minimum number of lines required for AI instruction/skill files (default 10). | No | - |
| `max_lines` | Maximum number of lines allowed for AI instruction/skill files, overrides kind-specific defaults. | No | - |
##### Attestation Policies
* [source-commit](#source-commit)\* [ai-agent-present](#ai-agent-present)
##### Material Policies
| Material Name | Material Type | Policies |
| ------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pr-info` | `CHAINLOOP_PR_INFO` | [pr-bot-author-allowed](#pr-bot-author-allowed) [pr-description-required](#pr-description-required) [pr-user-story-linked](#pr-user-story-linked) |
| - | Any | [ai-config-ai-agents-allowed](#ai-config-ai-agents-allowed) [ai-config-mcp-servers-allowed](#ai-config-mcp-servers-allowed) [ai-config-no-secrets](#ai-config-no-secrets) [ai-subagents-permissions-scope](#ai-subagents-permissions-scope) [ai-instructions-size-bounds](#ai-instructions-size-bounds) |
### 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) |