Guardrails Library
100+ Guardrails Out of the Box
Get instant value from day one. Pre-built guardrails for reliability, quality, operational readiness, and security — no need to build from scratch.
Write once, enforce everywhere. Each guardrail runs on every PR and in AI coding workflows, turning standards into automated enforcement in minutes, not quarters.
Policies
11Guardrails
61codeowners.exists
Repository And Ownership
Requires a CODEOWNERS file to be present in the repository. Checks standard locations: root, .github/, or docs/.
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).
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.
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.
codeowners.team-owners
Repository And Ownership
Requires at least one team-based owner (@org/team) in the CODEOWNERS file for better ownership continuity.
codeowners.no-individuals-only
Repository And Ownership
Ensures each CODEOWNERS rule includes at least one team owner, not just individual users. Stricter than team-owners which only checks that teams exist somewhere in the file.
codeowners.no-empty-rules
Repository And Ownership
Flags CODEOWNERS rules that have no owners assigned, which effectively un-assigns ownership for matching files.
codeowners.max-owners
Repository And Ownership
Flags CODEOWNERS rules with too many owners. Excessive owners often means diffused responsibility where nobody truly owns the code. Configurable via the max_owners_per_rule input.
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 Dockerfiles include required OCI labels for traceability. Common labels: org.opencontainers.image.source, version, maintainer.
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.
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.
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.
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.
readme.readme-exists
Repository And Ownership
Verifies that a `README.md` or `README` file exists in the repository root. Every repository should have basic documentation for discoverability.
readme.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.
readme.readme-required-sections
Repository And Ownership
Ensures the README contains required section headings (e.g., Installation, Usage). Configurable via the required_sections input parameter.
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.
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.
How Integrations Power Guardrails
Integrations Gather Data
Collectors and catalogers automatically extract metadata from your codebase, CI/CD pipelines, and external systems
Guardrails Enforce Standards
Guardrails evaluate the collected data and provide real-time feedback in PRs and AI workflows
Need a Custom Guardrail?
Build your own collectors and policies with simple Bash and Python scripts. Enforce any engineering standard specific to your organization.
Ready to Automate Your Standards?
See how Lunar can turn your engineering wiki, compliance docs, or postmortem action items into automated guardrails with our 100+ built-in guardrails.
Infrastructure conventions
Post-mortem action items
Security & compliance policies
Testing & quality requirements