Policies

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

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

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

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

Inputs

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

commits-signed-required

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

Categories: security
Supported material types: CHAINLOOP_RUNNER_CONTEXT

Inputs

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

containers-with-sbom

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

Categories: sbom container
Supported material types: ATTESTATION

Inputs

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

cves-in-kev

Checks a CVE report against CISA’s Known Exploited Vulnerabilities KEV Catalog. Supports Trivy’s SARIF, Blackduck, 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 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 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. 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. 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. 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. 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 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 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 evidence.

Categories: security SAST
Supported material types: ATTESTATION

sbom-banned-components

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

Categories: sbom security
Supported material types: SBOM_CYCLONEDX_JSON

Inputs

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

sbom-banned-licenses

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

Categories: sbom
Supported material types: SBOM_CYCLONEDX_JSON

Inputs

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

sbom-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. 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.

Categories: security

Inputs

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

Material Policies

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

code-review

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

Categories: security

Inputs

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

Material Policies

Material Name	Material Type	Policies
`runner-context`	`CHAINLOOP_RUNNER_CONTEXT`	pr-review-required pr-stale-reviews-dismissed pr-code-owner-review-required pr-conversation-resolution-required

cwes

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

Categories: security CWE

Material Policies

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

pr-quality

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

Categories: quality

Inputs

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

Material Policies

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

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.

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* ai-agent-present

Material Policies

Material Name	Material Type	Policies
`pr-info`	`CHAINLOOP_PR_INFO`	pr-bot-author-allowed pr-description-required pr-user-story-linked
-	Any	ai-config-ai-agents-allowed ai-config-mcp-servers-allowed ai-config-no-secrets ai-subagents-permissions-scope 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

Material Policies

Material Name	Material Type	Policies
-	Any	sast

sbom-quality

This policy group applies a number of SBOM-related policies

Categories: SBOM

Inputs

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

Attestation Policies

sbom-present

Material Policies

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

slsa-checks

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

Categories: SLSA

Inputs

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

Attestation Policies

runner-automated* runner-authenticated* signature-present

tag-protection

This policy group enforces tag protection rules to prevent tag manipulation attacks such as the Trivy supply chain attack. It includes policies that prevent tag deletion, force pushes on tags, and restrict who can bypass tag protection rules. Supports both GitHub and GitLab. Read more about how to generate the needed material in the documentation.

Categories: security

Inputs

Name	Description	Required	Default
`tags`	Comma-separated list of tag patterns to check. If not specified, all tags are checked. Uses glob matching where * does not cross dot (.) boundaries. For version tags like v1.45.0, use v** (double star) instead of v* to match across dots.	No	-
`authorized_bypass`	Comma-separated list of actors authorized to bypass tag protection rules. If not specified, no bypass actors are allowed. Use format “role:RoleName”, “team:teamname”, or “user:username” (e.g., role:Repository Admin,team:release-team)	No	-

Material Policies

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

vulnerability-management

This policy group applies vulnerability management related policies.

Categories: security CVE

Inputs

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

Attestation Policies

vulnerability-scan-present

Material Policies

Material Name	Material Type	Policies
-	Any	vulnerabilities

SCM Protection Policies Builtin functions for Rego policies

​Policies

​activex-controls-fuzzed

​ai-agent-present

​ai-config-ai-agents-allowed

Inputs

​ai-config-mcp-servers-allowed

Inputs

​ai-config-no-dangerous-commands

Inputs

​ai-config-no-secrets

Inputs

​ai-instructions-architecture-with-paths

Inputs

​ai-instructions-code-style-specificity

Inputs

​ai-instructions-commands-documented

Inputs

​ai-instructions-doc-guidance

Inputs

​ai-instructions-explicit-boundaries

Inputs

​ai-instructions-git-workflow-documented

Inputs

​ai-instructions-gotchas

Inputs

​ai-instructions-size-bounds

Inputs

​ai-instructions-verification-criteria

Inputs

​ai-skills-descriptions-actionable

Inputs

​ai-subagents-descriptions-actionable

Inputs

​ai-subagents-permissions-scope

​api-security

Inputs

​api-security-scan-present

​artifact-signed

​artifact-tag-not-latest

​binary-compiler-hardening

Inputs

​binary-scan

Inputs

​binary-symbols-stripped

Inputs

​branch-deletion-blocked

Inputs

​branch-force-push-blocked

Inputs

​branch-linear-history-required

Inputs

​check-compliance-requirement

Inputs

​ci-pipeline-security

Inputs

​ci-user-strongly-authenticated

​code-coverage

Inputs

​commits-signed-required

Inputs

​containers-with-sbom

Inputs

​cves-in-kev

​cwe-top25

​cwe-top26-40-cusp

​evidence-prompt

Inputs

​iac-misconfiguration

Inputs

​iac-scan-present

​immutable-releases-enabled

​material-present

Inputs

​owasp-api-top10-2019

​owasp-api-top10-2023

​owasp-top10-2021

​owasp-top10-2025

​patch-policy-present

​pr-bot-author-allowed

Inputs

Policies

activex-controls-fuzzed

ai-agent-present

ai-config-ai-agents-allowed

ai-config-mcp-servers-allowed

ai-config-no-dangerous-commands

ai-config-no-secrets

ai-instructions-architecture-with-paths

ai-instructions-code-style-specificity

ai-instructions-commands-documented

ai-instructions-doc-guidance

ai-instructions-explicit-boundaries

ai-instructions-git-workflow-documented

ai-instructions-gotchas

ai-instructions-size-bounds

ai-instructions-verification-criteria

ai-skills-descriptions-actionable

ai-subagents-descriptions-actionable

ai-subagents-permissions-scope

api-security

api-security-scan-present

artifact-signed

artifact-tag-not-latest

binary-compiler-hardening

binary-scan

binary-symbols-stripped

branch-deletion-blocked

branch-force-push-blocked

branch-linear-history-required

check-compliance-requirement

ci-pipeline-security

ci-user-strongly-authenticated

code-coverage

commits-signed-required

containers-with-sbom

cves-in-kev

cwe-top25

cwe-top26-40-cusp

evidence-prompt

iac-misconfiguration

iac-scan-present

immutable-releases-enabled

material-present

owasp-api-top10-2019

owasp-api-top10-2023

owasp-top10-2021

owasp-top10-2025

patch-policy-present

pr-bot-author-allowed

pr-code-owner-review-required

pr-conversation-resolution-required

pr-description-required

pr-review-required

pr-stale-reviews-dismissed

pr-user-story-linked

radamsa-min-iterations

radamsa-no-crashes

repository-rules-change-restricted

runner-authenticated

runner-automated

sast

sast-scan-present

sbom-banned-components

sbom-banned-licenses

sbom-bsi-component-fields

sbom-bsi-creator

sbom-bsi-dependencies

sbom-bsi-format

sbom-bsi-licenses

sbom-bsi-no-vulns

sbom-bsi-properties

sbom-bsi-sbom-uri

sbom-freshness

sbom-ntia

sbom-present

sbom-version

sbom-with-licenses

sca-scan-present

secrets-detection

signature-present