Guardrails

✓

ai.code-reviewer Devex Build And Ci

Verifies that at least one AI code reviewer is active on the component. Checks ai.code_reviewers[] for any entry with detected: true. Tool-agnostic — doesn't care which reviewer is active, just that something is reviewing code. Skips if no code reviewer data exists (no tool-specific collectors configured).

✓

ai.instruction-file-exists Devex Build And Ci

Verifies that an agent instruction file exists at the repository root. Checks ai.instructions.all[] which is populated by the ai collector (AGENTS.md) and tool-specific collectors via array append (CLAUDE.md, CODEX.md, GEMINI.md). Passes if any entry exists.

✓

ai.canonical-naming Devex Build And Ci

Verifies the root instruction file uses the canonical vendor-neutral name (AGENTS.md by default). Repos with only CLAUDE.md pass the existence check but fail this naming check.

✓

ai.instruction-file-length Devex Build And Ci

Validates that the root instruction file is within reasonable length bounds. Too short means insufficient context; too long wastes context window budget and can reduce AI task success rates.

✓

ai.instruction-file-sections Devex Build And Ci

Ensures the root instruction file contains required section headings. Validates that essential information like project overview and build commands is documented for AI agents.

✓

ai.plans-dir-exists Devex Build And Ci

Verifies that a dedicated plans directory exists for AI agent task planning. A dedicated directory keeps AI-generated plans organized and reviewable.

✓

ai.ai-authorship-annotated Devex Build And Ci

Verifies that commits include AI authorship annotations. Supports the Git AI standard (usegitai.com) for automated line-level tracking and git trailers as a lightweight manual alternative.

✓

api-docs.spec-exists Repository And Ownership

Verifies that at least one API specification file exists in the repository by checking if `.api.spec_files[]` is non-empty. Protocol-agnostic — works for REST (OpenAPI/Swagger), gRPC (protobuf), or any future API format. Skips if neither the openapi nor swagger collector has run.

✓

api-docs.spec-valid Repository And Ownership

Checks that all detected API spec files parse without errors by verifying `.api.spec_files[].valid` is true for every entry. Skips if no spec files were detected.

✓

api-docs.has-docs Repository And Ownership

Checks that all API spec files include human-readable documentation (descriptions, examples) by verifying `.api.spec_files[].has_docs` is true for every entry. A bare definition without descriptions doesn't count. Skips if no spec files were detected.

✓

backstage.catalog-info-exists Repository And Ownership

Verifies that a catalog-info.yaml file exists in the repository. Every Backstage-managed service must have a catalog definition file. Fails if the `backstage` collector reports no catalog file found.

✓

backstage.catalog-info-valid Repository And Ownership

Verifies that the catalog-info.yaml file is syntactically valid and passes Backstage descriptor schema checks (no lint errors reported by the collector). Fails if the file is missing or has lint errors.

✓

backstage.owner-set Repository And Ownership

Validates that the owner field (spec.owner) is populated in the catalog-info.yaml. Ownership is required for incident routing and accountability. Fails if no catalog file is present.

✓

backstage.lifecycle-set Repository And Ownership

Validates that the lifecycle stage (spec.lifecycle) is defined in the catalog-info.yaml. Lifecycle stages (production, experimental, deprecated) inform operational expectations and SLO requirements. Fails if no catalog file is present.

✓

backstage.system-set Repository And Ownership

Validates that the system grouping (spec.system) is defined in the catalog-info.yaml. System assignment enables dependency mapping and architectural visibility. Fails if no catalog file is present.

✓

ci.lint-clean Devex Build And Ci

Ensures no lint errors across CI configuration files. Reads from the normalized .ci.lint path — works with any CI vendor's lint tool (actionlint for GHA, gitlab-ci-lint for GitLab, etc.).

✓

ci.dependencies-pinned Devex Build And Ci

Verifies all third-party CI dependencies use SHA or tag pins, not branch refs. Reads from the normalized .ci.dependencies path — works with GHA actions, GitLab templates, CircleCI orbs, etc.

✓

ci.no-mutable-refs Devex Build And Ci

Ensures no third-party CI dependencies reference mutable refs like @main, @master, or @latest. Reads from normalized .ci.dependencies.

✓

claude.cli-safe-flags Devex Build And Ci

Ensures Claude CLI invocations in CI do not use dangerous permission-bypassing flags. Flags like --dangerously-skip-permissions remove safety guardrails that prevent the AI from executing arbitrary code without human approval.

✓

claude.cli-structured-output Devex Build And Ci

Ensures Claude CLI invocations in CI headless mode use structured JSON output (--output-format json) instead of plain text. JSON output makes AI automation deterministic and parseable.

✓

claude.symlinked-aliases Devex Build And Ci

Verifies that CLAUDE.md exists as a symlink to AGENTS.md. Claude Code does not support the AGENTS.md filename natively, so a symlink is required for compatibility. Reads from ai.native.claude.instruction_file to check symlink status.

✓

coderabbit.config-exists Devex Build And Ci

Ensures a CodeRabbit configuration file (.coderabbit.yaml or .coderabbit.yml) exists at the repository root. A config file allows teams to customize review behavior, set path filters, and configure review instructions.

✓

codex.cli-safe-flags Devex Build And Ci

Ensures Codex CLI invocations in CI do not use dangerous permission-bypassing flags. Flags like --full-auto remove safety guardrails that prevent the AI from executing arbitrary code without human approval.

✓

codex.cli-structured-output Devex Build And Ci

Ensures Codex CLI invocations in CI use structured JSON output instead of plain text. JSON output makes AI automation deterministic and parseable.

✓

compliance-docs.dr-plan-exists Operational Readiness

Verifies that a disaster recovery plan exists in the repository. Every production service should have documented recovery procedures to ensure teams can respond effectively during outages.

✓

compliance-docs.dr-plan-rto-rpo-defined Operational Readiness

Requires that Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are defined in the DR plan. These targets establish clear expectations for acceptable downtime and data loss during disasters.

✓

compliance-docs.dr-plan-required-sections Operational Readiness

Ensures the DR plan contains required section headings covering key recovery topics. Configurable via the plan_required_sections input.

✓

compliance-docs.dr-exercise-recent Operational Readiness

Ensures a DR exercise (tabletop, failover, or full) was conducted within the configured threshold (default: 365 days). Checks the most recent exercise record in the exercises directory.

✓

compliance-docs.dr-exercise-required-sections Operational Readiness

Ensures the most recent DR exercise record contains required section headings documenting what was tested and the outcomes. Configurable via the exercise_required_sections input.

✓

container.no-latest Devex Build And Ci

Prevents use of the :latest tag (explicit or implicit) in base images. Using :latest creates non-reproducible builds and makes debugging difficult.

✓

container.stable-tags Devex Build And Ci

Requires base images to use stable tags: digests (sha256:...) or full semver (1.2.3). Partial versions like "node:20" can change unexpectedly and break builds.

✓

container.allowed-registries Devex Build And Ci

Restricts base images to approved container registries only. Prevents supply chain attacks from untrusted image sources.

✓

container.required-labels Devex Build And Ci

Ensures containers have required labels, checking both Dockerfile LABEL instructions and docker build --label flags. A label present in either source satisfies the requirement.

✓

container.healthcheck Devex Build And Ci

Requires a HEALTHCHECK instruction in the final stage of multi-stage builds. Enables container orchestrators to detect and restart unhealthy containers.

✓

container.user Devex Build And Ci

Requires a USER instruction to run the container as a non-root user. Running as root inside containers is a security risk and violates least privilege.

✓

container.build-tagged Devex Build And Ci

Requires container builds to use an explicit image tag via -t/--tag. Untagged builds produce anonymous images that cannot be tracked or deployed.

✓

container.dockerfile-lint-clean Devex Build And Ci

Requires Dockerfiles to pass hadolint linting with no issues at or above the configured severity threshold. Enforces Dockerfile best practices including pinned versions, proper instruction usage, and security hygiene.

✓

container-scan.executed Security And Compliance

Verifies that container scanning was executed on the component. Fails if no scanner has written to .container_scan.

✓

container-scan.max-severity Security And Compliance

Ensures no findings at or above the configured severity threshold. Configure min_severity to set the threshold (critical, high, medium, low).

✓

container-scan.max-total Security And Compliance

Ensures total container vulnerabilities are under a configurable threshold.

✓

cpp.build-system-exists Devex Build And Ci

Ensures at least one build system (CMake, Make, Meson, Autotools, Bazel) is detected. Unlike Go or Rust where the toolchain is the build system, C/C++ projects require an explicit build system to be compilable.

✓

cpp.min-cpp-standard Devex Build And Ci

Ensures the project uses at least the minimum required C++ standard. Modern standards (C++17+) provide safer constructs, better type safety, and deprecate dangerous legacy features.

✓

cpp.cppcheck-clean Devex Build And Ci

Ensures cppcheck reports no errors and fewer warnings than the configured threshold. cppcheck catches undefined behavior, memory leaks, and other common C/C++ mistakes.

✓

cpp.min-compiler-version-cicd Devex Build And Ci

Ensures the C/C++ compiler version (gcc or clang) used in CI/CD meets the minimum required version. Newer compilers provide better diagnostics, optimization, and standard compliance.

✓

cpp.min-cmake-version-cicd Devex Build And Ci

Ensures the CMake version used in CI/CD meets the minimum required version. Modern CMake features (targets, presets, dependency management) require recent versions.

✓

dep-automation.dep-update-tool-configured Security And Compliance

Requires at least one dependency update tool (Dependabot or Renovate) to be configured in the repository. Fails if neither tool's config file is found.

✓

dep-automation.all-ecosystems-covered Security And Compliance

Checks that all detected package ecosystems in the component have corresponding update rules in the dependency automation config. For example, if the component uses npm and Docker, both should have update entries in Dependabot or be covered by Renovate's enabled managers. Skips if no dependency automation tool is configured.

✓

dependencies.min-versions Security And Compliance

Ensures dependencies meet minimum safe version requirements. Validates that project dependencies are at or above specified versions to enforce security patches and compatibility standards.

✓

dotnet.project-file-exists Devex Build And Ci

Ensures the project has at least one .NET project file (.csproj, .fsproj, .vbproj). Required for all .NET projects to be buildable.

✓

dotnet.target-framework-set Devex Build And Ci

Ensures all project files have a target framework specified. Required for proper compilation and runtime behavior.

✓

dotnet.dependencies-locked Devex Build And Ci

Ensures the project has packages.lock.json files for dependency locking. Required for reproducible builds and supply chain security.

✓

dotnet.test-project-exists Devex Build And Ci

Ensures the project has at least one test project. Encourages proper testing practices and quality assurance.

✓

dotnet.min-sdk-version Devex Build And Ci

Ensures the .NET SDK version meets minimum requirements. Prevents using outdated SDK versions that may have security vulnerabilities or missing features.

✓

dotnet.min-sdk-version-cicd Devex Build And Ci

Ensures the .NET SDK version used in CI/CD meets minimum requirements. Prevents CI/CD pipelines from using outdated SDK versions.

✓

feature-flags.feature-flags-age Testing And Quality

Detects feature flags that have existed longer than a configurable threshold. Feature flags should be temporary and removed once a feature is fully rolled out. Stale flags add complexity and technical debt to the codebase.

✓

gemini.cli-safe-flags Devex Build And Ci

Ensures Gemini CLI invocations in CI do not use dangerous permission-bypassing flags. Flags like --yolo and -y remove safety guardrails that prevent the AI from executing arbitrary code without human approval.

✓

gemini.cli-structured-output Devex Build And Ci

Ensures Gemini CLI invocations in CI use structured JSON output instead of plain text. JSON output makes AI automation deterministic and parseable.

✓

github-actions.no-script-injection Security And Compliance

Flags attacker-controlled ${{ }} expressions used directly in run: blocks and actions/github-script script: fields. These get substituted before the shell executes, enabling arbitrary code injection via PR titles, branch names, commit messages, and other user-controlled inputs.

✓

github-actions.no-dangerous-trigger-checkout Security And Compliance

Flags pull_request_target workflows that check out PR head code. This runs attacker-supplied code with base-branch secrets and write permissions — the pattern behind the tj-actions/changed-files breach (CVE-2025-30066).

✓

github-actions.permissions-declared Security And Compliance

Flags workflows with no permissions: key at workflow or job level. Without explicit permissions, workflows inherit org/repo defaults which may be write-all on repos created before GitHub's Feb 2023 default change.

✓

github-actions.no-write-all-permissions Security And Compliance

Flags explicit permissions: write-all at workflow or job level. Workflows should declare only the specific scopes they need to follow the principle of least privilege.

✓

github-actions.checkout-no-persist-credentials Security And Compliance

Flags actions/checkout steps that don't set persist-credentials: false. The default (true) stores GITHUB_TOKEN in .git/config, which leaks if the checkout directory is uploaded as an artifact (ArtiPACKED attacks, 2024).

✓

github-actions.no-secrets-inherit Security And Compliance

Flags secrets: inherit in reusable workflow calls. This passes ALL repository and org secrets to the called workflow, violating least-privilege. Workflows should explicitly pass only needed secrets.

✓

golang.go-mod-exists Devex Build And Ci

Ensures the project has a go.mod file for module management. Required for all Go projects using modules.

✓

golang.go-sum-exists Devex Build And Ci

Ensures the project has a go.sum file for dependency verification. Required for reproducible builds.

✓

golang.min-go-version Devex Build And Ci

Ensures the project uses at least the minimum required Go version. Helps maintain security and compatibility standards.

✓

golang.min-go-version-cicd Devex Build And Ci

Ensures the Go version used in CI/CD commands meets the minimum required version. Helps maintain security and compatibility standards for build environments.

✓

golang.tests-recursive Devex Build And Ci

Ensures tests run recursively (./...) to cover all packages. Prevents accidentally missing tests in subpackages.

✓

golang.vendoring Devex Build And Ci

Enforces vendoring policy - can require vendor directory exists or forbid it, depending on team standards.

✓

helm.lint-passed Deployment And Infrastructure

Validates that all Helm charts pass helm lint. Charts that fail linting may have template errors, missing required values, or invalid YAML that will cause deployment failures.

✓

helm.version-semver Deployment And Infrastructure

Ensures Helm chart versions follow semantic versioning (semver). Consistent versioning enables reliable dependency resolution and rollback strategies.

✓

helm.values-schema Deployment And Infrastructure

Requires Helm charts to include a values.schema.json file. A values schema validates user-provided values at install time, preventing misconfiguration.

✓

helm.dependencies-pinned Deployment And Infrastructure

Ensures all Helm chart dependencies specify version constraints. Unpinned dependencies (using * or empty version) can pull breaking changes unexpectedly.

✓

html.htmlhint-clean Devex Build And Ci

Ensures HTMLHint reports no errors and fewer warnings than the configured threshold. HTMLHint catches unclosed tags, missing attributes, and accessibility issues in HTML files.

✓

html.stylelint-clean Devex Build And Ci

Ensures Stylelint reports no errors and fewer warnings than the configured threshold. Stylelint catches invalid properties, formatting issues, and common CSS/SCSS/LESS mistakes.

✓

iac.valid Deployment And Infrastructure

Validates that all IaC configuration files are syntactically correct. Invalid configurations will fail deployment.

✓

iac.waf-protection Deployment And Infrastructure

Requires WAF protection for internet-facing services. Checks each IaC module for public resources and verifies WAF is configured.

✓

iac.datastore-destroy-protection Deployment And Infrastructure

Ensures stateful resources (databases, storage buckets, caches) have lifecycle { prevent_destroy = true } to prevent accidental data loss.

✓

iac.resource-destroy-protection Deployment And Infrastructure

Ensures stateless infrastructure resources (EC2 instances, load balancers, networking) have lifecycle { prevent_destroy = true } to prevent accidental destruction of critical infrastructure.

✓

iac-scan.executed Security And Compliance

Verifies that IaC scanning was executed on the component. Fails if no scanner has written to .iac_scan.

✓

iac-scan.max-severity Security And Compliance

Ensures no findings at or above the configured severity threshold. Configure min_severity to set the threshold (critical, high, medium, low).

✓

iac-scan.max-total Security And Compliance

Ensures total IaC findings are under a configurable threshold.

✓

java.build-tool-wrapper-exists Devex Build And Ci

Ensures a build tool wrapper exists (mvnw for Maven projects, gradlew for Gradle projects). Wrappers ensure reproducible builds without requiring a pre-installed build tool.

✓

java.min-java-version Devex Build And Ci

Ensures the Java version configured in the build file meets the minimum requirement. Checks pom.xml or build.gradle for the target Java version.

✓

java.min-maven-version Devex Build And Ci

Ensures the Maven version used in CI/CD commands meets the minimum requirement. Helps maintain build tool security and compatibility.

✓

java.min-gradle-version Devex Build And Ci

Ensures the Gradle version used in CI/CD commands meets the minimum requirement. Helps maintain build tool security and compatibility.

✓

java.tests-all-modules Devex Build And Ci

Ensures tests run across all modules rather than a subset. Prevents accidentally skipping tests in multi-module projects.

✓

k8s.valid Deployment And Infrastructure

Validates that all Kubernetes manifests in the repository are syntactically correct and conform to K8s schema. Invalid manifests will fail deployment.

✓

k8s.requests-and-limits Deployment And Infrastructure

Ensures all containers have CPU and memory requests and limits defined. Missing resource specs can cause scheduling failures and noisy neighbor issues.

✓

k8s.probes Deployment And Infrastructure

Requires liveness and readiness probes on all containers. Probes enable Kubernetes to detect unhealthy pods and route traffic correctly.

✓

k8s.min-replicas Deployment And Infrastructure

Enforces minimum replica counts on HorizontalPodAutoscalers. Ensures services maintain capacity during scaling events and failures.

✓

k8s.pdb Deployment And Infrastructure

Requires PodDisruptionBudgets for Deployments and StatefulSets. PDBs protect availability during voluntary disruptions like node drains.

✓

k8s.non-root Deployment And Infrastructure

Requires containers to run as non-root users via securityContext. Running as root inside containers violates least privilege principles.

✓

k8s.min-kubectl-version Deployment And Infrastructure

Ensures the kubectl version used in CI meets the minimum required version. Old kubectl clients may miss security fixes or lack support for current cluster APIs.

✓

linter.ran Testing And Quality

Ensures linting was executed for the specified language. Fails if no lint data is found, indicating the linter was not configured or did not run.

✓

linter.max-warnings Testing And Quality

Ensures lint warnings are at or below the maximum allowed threshold. Validates that the codebase maintains acceptable lint warning counts.

✓

nodejs.lockfile-exists Devex Build And Ci

Ensures a package lockfile exists (package-lock.json, yarn.lock, or pnpm-lock.yaml). Lockfiles are essential for reproducible builds and dependency integrity.

✓

nodejs.typescript-configured Devex Build And Ci

Ensures TypeScript is configured via tsconfig.json. TypeScript provides type safety and improved developer experience.

✓

nodejs.engines-pinned Devex Build And Ci

Ensures the engines.node field is set in package.json. Pinning the Node.js engine version prevents compatibility issues across environments.

✓

nodejs.min-node-version Devex Build And Ci

Ensures the Node.js version detected in the project meets the minimum required version. Helps maintain security and compatibility standards.

✓

nodejs.min-node-version-cicd Devex Build And Ci

Ensures the Node.js version used in CI/CD commands meets the minimum required version. Helps maintain security and compatibility standards for build environments.

✓

observability.dashboard-exists Operational Readiness

Verifies that the service has a linked monitoring dashboard by checking .observability.dashboard.exists is true. Fails if observability data is present but .observability.dashboard.exists is false (the UID is registered but the dashboard is gone in Grafana). Skips cleanly when no observability source has written data for this component.

✓

observability.alerts-configured Operational Readiness

Verifies that at least one alert rule is configured for the service by checking .observability.alerts.configured is true. Fails if alerting data is present but no rules are configured. Skips cleanly when no observability source has written data for this component.

✓

oncall.schedule-configured Operational Readiness

Verifies that the service has an active on-call schedule by checking .oncall.schedule.exists is true. Fails if no on-call schedule data is present.

✓

oncall.escalation-defined Operational Readiness

Verifies that an escalation policy is configured for the service by checking .oncall.escalation.exists is true. Fails if no escalation data is present.

✓

oncall.min-participants Operational Readiness

Ensures the on-call rotation has at least a minimum number of participants to avoid single-person burnout. Checks .oncall.schedule.participants against the configurable min_participants threshold (default: 2).

✓

openapi.spec-version Devex Build And Ci

Ensures all REST API specs meet a minimum OpenAPI version. Compares the major version from `.api.spec_files[].version` against `min_version` (default: 3). Flags any spec below the threshold. Only checks entries with `protocol: "rest"`. Skips if no REST spec files were detected.

✓

php.composer-json-exists Devex Build And Ci

Ensures the project has a composer.json file for dependency management. Reads from .lang.php.composer.json_exists.

✓

php.composer-lock-exists Devex Build And Ci

Ensures the project has a composer.lock file for reproducible builds. Reads from .lang.php.composer.lock_exists.

✓

php.phpunit-configured Devex Build And Ci

Ensures a test framework (PHPUnit) is configured for the project. Testing is essential for maintaining code quality.

✓

php.static-analysis-configured Devex Build And Ci

Ensures a static analysis tool (PHPStan or Psalm) is configured. Static analysis catches bugs and type errors before runtime.

✓

php.code-style-configured Devex Build And Ci

Ensures a code style tool (PHP-CS-Fixer or PHP_CodeSniffer) is configured. Consistent code style reduces cognitive load and merge conflicts.

✓

php.min-version Devex Build And Ci

Ensures the project requires at least the minimum PHP version. Helps maintain security and compatibility standards.

✓

php.min-version-cicd Devex Build And Ci

Ensures the PHP runtime version observed in CI meets the minimum required version. Reads from .lang.php.cicd.cmds version entries.

✓

php.min-composer-version Devex Build And Ci

Ensures CI pipelines use at least the minimum Composer version. Older Composer versions may lack security fixes and modern dependency resolution features.

✓

python.lockfile-exists Devex Build And Ci

Ensures the project has a dependency lockfile (poetry.lock, Pipfile.lock, or pinned requirements.txt) for reproducible builds.

✓

python.linter-configured Devex Build And Ci

Ensures a Python linter is configured (ruff, flake8, or pylint). Linters catch bugs and enforce consistent code style.

✓

python.min-python-version Devex Build And Ci

Ensures the project uses at least the minimum required Python version. Helps maintain security and compatibility standards.

✓

python.min-python-version-cicd Devex Build And Ci

Ensures the Python version used in CI/CD commands meets the minimum required version for build environments.

✓

repo-boilerplate.readme-exists Repository And Ownership

Verifies that a README file exists in the repository root. Every repository should have basic documentation for discoverability.

✓

repo-boilerplate.readme-min-line-count Repository And Ownership

Requires the README to have a minimum number of lines (default 25). Prevents placeholder READMEs that lack useful information.

✓

repo-boilerplate.readme-required-sections Repository And Ownership

Ensures the README contains required section headings (e.g., Installation, Usage). Configurable via the required_sections input. Skips if no sections configured.

✓

repo-boilerplate.codeowners-exists Repository And Ownership

Requires a CODEOWNERS file to be present in the repository. Checks standard locations: root, .github/, or docs/.

✓

repo-boilerplate.codeowners-valid Repository And Ownership

Validates that the CODEOWNERS file has correct syntax. Checks that all owner references use valid formats (@user, @org/team, or email).

✓

repo-boilerplate.codeowners-catchall Repository And Ownership

Requires a default catch-all rule (*) in CODEOWNERS so that every file in the repository has at least one owner.

✓

repo-boilerplate.codeowners-min-owners Repository And Ownership

Ensures each CODEOWNERS rule has a minimum number of owners for redundancy. Configurable via the min_owners_per_rule input.

✓

repo-boilerplate.codeowners-team-owners Repository And Ownership

Requires at least one team-based owner (@org/team) in the CODEOWNERS file for better ownership continuity.

✓

repo-boilerplate.codeowners-no-individuals-only Repository And Ownership

Ensures each CODEOWNERS rule includes at least one team owner, not just individual users. Stricter than codeowners-team-owners which only checks that teams exist somewhere in the file.

✓

repo-boilerplate.codeowners-no-empty-rules Repository And Ownership

Flags CODEOWNERS rules that have no owners assigned, which effectively un-assigns ownership for matching files.

✓

repo-boilerplate.codeowners-max-owners Repository And Ownership

Flags CODEOWNERS rules with too many owners. Excessive owners often means diffused responsibility. Configurable via the max_owners_per_rule input.

✓

repo-boilerplate.gitignore-exists Repository And Ownership

Verifies that a .gitignore file exists in the repository root. Prevents accidental commits of build artifacts, dependencies, and IDE files. Reads from `.repo.gitignore`.

✓

repo-boilerplate.license-exists Repository And Ownership

Verifies that a LICENSE file exists in the repository root. Checks common variants: LICENSE, LICENSE.md, LICENSE.txt, LICENCE. Reads from `.repo.license`.

✓

repo-boilerplate.security-exists Repository And Ownership

Verifies that a SECURITY.md file exists in the repository root or .github/ directory. Provides a channel for responsible vulnerability disclosure. Reads from `.repo.security`.

✓

repo-boilerplate.contributing-exists Repository And Ownership

Verifies that a CONTRIBUTING.md file exists in the repository root or .github/ directory. Helps external and internal contributors understand the process. Reads from `.repo.contributing`.

✓

repo-boilerplate.editorconfig-exists Repository And Ownership

Verifies that an .editorconfig file exists in the repository root. Ensures consistent coding style across editors. Use exclude/include in lunar-config to control whether this check runs. Reads from `.repo.editorconfig`.

✓

ruby.gemfile-exists Devex Build And Ci

Ensures the project has a Gemfile for dependency management. Required for all Ruby projects using Bundler.

✓

ruby.lockfile-exists Devex Build And Ci

Ensures the project has a Gemfile.lock for reproducible dependency resolution. Pinned dependencies prevent unexpected version drift across environments.

✓

ruby.ruby-version-set Devex Build And Ci

Ensures the Ruby version is explicitly specified via a .ruby-version file or a ruby directive in the Gemfile. Pinning the Ruby version prevents environment inconsistencies between development, CI, and production.

✓

ruby.bundler-audit-clean Devex Build And Ci

Ensures bundler-audit reports no known vulnerabilities in the project's gem dependencies. Skips gracefully if bundler-audit has not been run. Requires the bundler-audit-cicd collector to capture audit results from CI.

✓

ruby.min-ruby-version Devex Build And Ci

Ensures the project uses at least the minimum required Ruby version. Helps maintain security and compatibility standards.

✓

ruby.min-ruby-version-cicd Devex Build And Ci

Ensures the Ruby version used in CI/CD commands meets the minimum required version for build environments.

✓

ruby.min-bundler-version-cicd Devex Build And Ci

Ensures the Bundler version used in CI/CD commands meets the minimum required version. Outdated Bundler versions may have security issues or lack features needed for reliable dependency resolution.

✓

ruby.min-rake-version-cicd Devex Build And Ci

Ensures the Rake version used in CI/CD commands meets the minimum required version for build automation.

✓

rust.cargo-toml-exists Devex Build And Ci

Ensures the project has a Cargo.toml file for crate configuration. Required for all Rust projects.

✓

rust.cargo-lock-exists Devex Build And Ci

Ensures the project has a Cargo.lock file for dependency pinning. By default required for applications, skipped for libraries (following Cargo conventions). Configurable via lock_mode.

✓

rust.min-rust-edition Devex Build And Ci

Ensures the project uses at least the minimum required Rust edition. Editions enable new language features while preserving backward compatibility.

✓

rust.min-rust-version-cicd Devex Build And Ci

Ensures the Rust toolchain version used in CI/CD commands meets the minimum required version. Helps maintain security and compatibility standards for build environments.

✓

rust.clippy-clean Devex Build And Ci

Ensures clippy reports no warnings (or fewer than the configured threshold). Clippy catches common mistakes and enforces idiomatic Rust patterns.

✓

rust.max-unsafe-blocks Devex Build And Ci

Limits the number of unsafe blocks in the codebase. Unsafe code bypasses Rust's safety guarantees and should be minimized and carefully reviewed.

✓

sast.executed Security And Compliance

Verifies that SAST scanning was executed on the component. Fails if no scanner has written to .sast.

✓

sast.max-severity Security And Compliance

Ensures no findings at or above the configured severity threshold. Configure min_severity to set the threshold (critical, high, medium, low).

✓

sast.max-total Security And Compliance

Ensures total code findings are under a configurable threshold.

✓

sbom.sbom-exists Security And Compliance

Ensures an SBOM was generated, either automatically or detected in CI.

✓

sbom.has-licenses Security And Compliance

Verifies that SBOM components have license information populated. Fails if license coverage is below the configured threshold.

✓

sbom.disallowed-licenses Security And Compliance

Checks for disallowed licenses in SBOM components. Matches component licenses against configurable regex patterns.

✓

sbom.min-components Security And Compliance

Verifies the SBOM contains a minimum number of components. Catches trivially empty SBOMs that may indicate detection failures.

✓

sbom.standard-format Security And Compliance

Validates the SBOM uses an approved format (CycloneDX, SPDX). Auto-passes if no format restriction is configured.

✓

sbom.blocked-origins Security And Compliance

Checks for dependencies with license origin mentions from blocked countries. Supports blocklist or allowlist mode. Requires the license-origins collector.

✓

sbom.disallowed-packages Security And Compliance

Checks for disallowed packages by matching PURL, name, or group against configurable regex patterns (e.g. "ru\\.yandex\\..*", "com\\.alibaba\\..*").

✓

sca.executed Security And Compliance

Verifies that SCA scanning was executed on the component. Fails if no scanner has written to .sca.

✓

sca.max-severity Security And Compliance

Ensures no findings at or above the configured severity threshold. Configure min_severity to set the threshold (critical, high, medium, low).

✓

sca.max-total Security And Compliance

Ensures total vulnerabilities are under a configurable threshold.

✓

secrets.executed Security And Compliance

Verifies that secret scanning was executed on the component. Fails if no scanner has written to .secrets.

✓

secrets.no-hardcoded-secrets Security And Compliance

Ensures no hardcoded secrets are detected in the codebase. Fails if .secrets.issues is non-empty.

✓

secrets.max-issues Security And Compliance

Ensures the number of secret findings is under a configurable threshold. Use this for gradual remediation of existing codebases.

✓

shell.shellcheck-clean Testing And Quality

Ensures ShellCheck finds no issues at or above the configured severity level (default: error). Skips if no shell scripts are detected. Severity filtering and warning threshold are both configurable.

✓

terraform.provider-versions-pinned Deployment And Infrastructure

Requires Terraform providers to specify version constraints in required_providers. Unpinned providers can introduce breaking changes unexpectedly.

✓

terraform.module-versions-pinned Deployment And Infrastructure

Requires Terraform modules to use pinned versions or commit SHAs. Unpinned modules make infrastructure deployments non-reproducible.

✓

terraform.remote-backend Deployment And Infrastructure

Requires Terraform to use a remote backend for state management. Local state files are fragile and cannot be shared across teams.

✓

terraform.min-provider-versions Deployment And Infrastructure

Enforces minimum version requirements for Terraform providers. Ensures providers meet security and compatibility baselines.

✓

testing.executed Testing And Quality

Ensures tests were executed in CI. Fails if no test execution data is found.

✓

testing.passing Testing And Quality

Ensures all tests pass. Fails if test pass/fail data is not available.

✓

testing.coverage-collected Testing And Quality

Ensures coverage data is being collected in CI. Fails if no coverage data is found.

✓

testing.coverage-reported Testing And Quality

Ensures coverage percentage is being reported. Fails if coverage runs but percentage is not captured.

✓

testing.min-coverage Testing And Quality

Enforces a minimum code coverage threshold (default 80%). Fails if coverage data is not available.

✓

ticket.ticket-present Devex Build And Ci

Ensures PRs reference an issue tracker ticket in the title.

✓

ticket.ticket-valid Devex Build And Ci

Ensures the referenced ticket exists and is valid in the issue tracker.

✓

ticket.ticket-source Devex Build And Ci

Ensures the ticket comes from an approved issue tracker.

✓

ticket.ticket-status Devex Build And Ci

Ensures the ticket is in an acceptable workflow status.

✓

ticket.ticket-type Devex Build And Ci

Ensures the ticket is an acceptable issue type.

✓

ticket.ticket-reuse Devex Build And Ci

Prevents teams from recycling the same ticket across too many PRs.

✓

vcs.branch-protection-enabled Repository And Ownership

Requires branch protection rules to be enabled on the default branch. Branch protection is the foundation for all other VCS security controls.

✓

vcs.require-pull-request Repository And Ownership

Requires all changes to go through pull requests before merging. Prevents direct pushes to protected branches without review.

✓

vcs.minimum-approvals Repository And Ownership

Enforces a minimum number of approving reviews before merge (default 1). Configurable via the min_approvals input for stricter requirements.

✓

vcs.require-codeowner-review Repository And Ownership

Requires approval from designated code owners defined in CODEOWNERS file. Ensures domain experts review changes to critical paths.

✓

vcs.dismiss-stale-reviews Repository And Ownership

Automatically dismisses approvals when new commits are pushed to a PR. Prevents merging outdated approvals after significant changes.

✓

vcs.require-status-checks Repository And Ownership

Requires CI status checks to pass before merging pull requests. Prevents merging code that fails tests or linting.

✓

vcs.require-branches-up-to-date Repository And Ownership

Requires PR branches to be up-to-date with the base branch before merging. Prevents merging stale branches that may have integration issues.

✓

vcs.disallow-force-push Repository And Ownership

Prohibits force pushes to protected branches to preserve commit history. Force pushes can destroy audit trails and cause data loss.

✓

vcs.disallow-branch-deletion Repository And Ownership

Prevents deletion of protected branches (typically main/master). Protects against accidental or malicious branch removal.

✓

vcs.require-linear-history Repository And Ownership

Enforces linear commit history by requiring squash or rebase merges. Makes git history cleaner and easier to bisect for debugging.

✓

vcs.require-signed-commits Repository And Ownership

Requires all commits to be GPG or SSH signed for authenticity verification. Proves commits were made by the claimed author.

✓

vcs.require-private Repository And Ownership

Ensures repository visibility is set to private, not public. Prevents accidental exposure of proprietary code.

✓

vcs.require-default-branch Repository And Ownership

Validates the default branch name matches the required name (default "main"). Helps standardize branch naming across repositories.

✓

vcs.allowed-merge-strategies Repository And Ownership

Restricts merge strategies to an allowed list (merge, squash, rebase). Enforces consistent merge practices across the organization.

100+ Guardrails Out of the Box

Policies

How Integrations Power Guardrails

Integrations Gather Data

Guardrails Enforce Standards

Need a Custom Guardrail?

Ready to Automate Your Standards?