Form rules

Form rules cover the common cases without writing Rego. For a ready-made policy built from these rules, see Policy templates.

Rule categoriesCopy Anchor Link

The Add rule menu lists the categories; open one (click, tap, or the right arrow key) to pick a rule. Only rules that fit the policy's Used for choice are shown, and a category with no rule that fits is hidden. A category with one rule is that rule, with no submenu.

• Approvals: Prodgator approvers, GitHub reviews, Code owners, Allowed actors, Release risk
• Provenance: Verified change, Followed the declared promotion path, Tested in an environment unchanged, Coverage along the promotion path, Findings along the promotion path
• Attestations: Attestations, Code coverage, Test results, SBOM, Build provenance
• Security: Security findings
• Pull request: Pull request details, Labels, Change size, Protected paths, Required checks, Required reusable workflow, GitHub facts, AI-assisted changes
• Custom: Custom Rego

Rule namesCopy Anchor Link

Every form rule can have a name. In the policy editor, fill in Display name next to the rule; the placeholder shows the default. A name is 1 to 80 characters, trimmed, and cannot contain control, line-break, zero-width or bidirectional characters. With no name, results (check output, the pull request page, the playground) show the rule id. The type label, such as "Verified change", appears only in the editor placeholder and heading.

The name appears in evaluations, on the deployment card, in the provenance tree, and in GitHub check run and approval comment output (escaped). It is only a label. Rule ids, Rego and policy keys do not change. Changing a name saves a new policy version. Names are left out of signed provenance statements, and AI features treat them as untrusted text.

Verified changeCopy Anchor Link

Releases only, Business and above. verifiedChange passes when the change that produced the release is verified and no bypass was recorded for it. A bypass is anything that skipped the checks, such as a direct push. The reason names the pull request (or the commit, for a direct push) and the bypass kinds in plain words:

A change pushed without a pull request reads "the change in commit 4f2c1e0 is verified".

No unverified changes contained (requireNoUnverifiedContained, off by default) also fails the rule while the release contains open unverified changes that are not expected or acknowledged, for example "3 unverified changes are contained in this release and not expected or acknowledged; acknowledge or mark them expected in Provenance". Only open unverified changes count; a change marked expected or acknowledged does not. If a contained change is still waiting for its verdict or has an unknown verdict, or the release's ancestry could not be checked, the result is error with "the changes contained in this release could not be checked". To clear the failure, acknowledge each change or mark it expected in Provenance, then evaluate again.

Accept expected or acknowledged bypasses (acceptExpectedBypasses, off by default) lets a change with a bypass pass when the bypass is marked expected, or acknowledged as reviewed or expected, in Provenance, for example "pull request #42 passes because its bypass was expected (direct push)". An acknowledgement as reverted does not count: Prodgator adds one when a later change reverts the bypass, and releasing the bypassed commit again would bring the change back, so the rule fails with "pull request #42 is unverified (bypass: direct push); it was acknowledged as reverted, which does not count". An acknowledgement with no reason that counts fails with "...; its acknowledgement has no reason that counts". This applies to a verified or unverified change only: a change still waiting for its verdict, or with an unknown verdict, never passes, and a bypass that is neither expected nor acknowledged still fails. An unverified change with no bypass still fails. If the expected or acknowledged state cannot be read, the result is error with "whether the bypass of pull request #42 was expected or acknowledged could not be read". No unverified changes contained still applies.

When the result is not pass, the deployment card and the policy playground show a View open unverified changes in Provenance link. It opens the Provenance list filtered to the repository's open unverified changes. The list shows every open unverified change in the repository, not only the ones in this release.

The rule never passes on missing data. These cases are error, and the reason says which one:

• "release provenance is not part of your plan": your plan does not include release provenance.
• "no change record for commit 4f2c1e0": the commit has no landed change record yet.
• "the change or lineage record for this commit could not be read": there is no change record because reading the change or lineage record for the release failed. Evaluate again later.

See Promotion rule statuses for how Enforce treats these.

Release riskCopy Anchor Link

Releases only. releaseRisk reads the AI release risk rating of the deployment and can only make a release stricter. Only the level (low, medium or high) is read, never the written summary. The highest rating a deployment received counts, so regenerating the summary cannot lower it.

Any plan with release policies can add the rule, but only an organization whose plan includes Release risk summaries, with AI features on and the Release risk summaries switch on, gets ratings. Without them the rule always sees a missing rating (see below).

Below the threshold the rule adds no requirement. Until someone approves, it passes with the reason "no extra requirement" and neither approves nor blocks: a policy with only this rule leaves the decision to the other policies on the gate, or waits when there are none. A person's approval answers it: once someone other than the person who deployed approves (a current approval from a role that approves), the rule passes for real, so a policy with only this rule approves just as it would at or above the threshold with approval.

A current rejection from someone other than the person who deployed fails the rule whenever there is a rating.

While the rating is being written the rule is pending, whichever whenMissing you chose. With no rating and none on the way, the rule is pending or fail as you chose, and never pass. A rating is missing when the plan has no Release risk summaries, AI is off for the organization, there are no AI credits, the rating failed, or it was written for a different deployment or an older baseline. Turn on Generate release risk automatically in Organization > AI so the rating is ready when the deployment starts waiting; otherwise it exists only after someone opens the approval dialog.

Declared promotion pathCopy Anchor Link

Releases only, Business and above. declaredPath checks that required promotion steps succeeded in order. Define a path in the rule, or use the repository path with the organization path as fallback. A policy path has 1 to 6 steps: branch, environment or gate, or a branch plus an environment or gate. A one-step policy path must name a branch. Environment and gate cannot share a step. An environment can use * wildcards, as in gate patterns (see Promotion path). The release must match the last step.

One policy can apply to repositories with the same SDLC through a gate or direct binding. With no path in the rule, repository or organization, the result is error and an enforced blocking rule holds the gate. There is no option to pass without a path. When a path is found, the reason and evidence.pathSource name its source. See Promotion path.

Accept verified hotfixes (allowVerifiedChanges, off by default) accepts changes merged straight into the release branch without going through the earlier steps, such as a hotfix pull request, when each one came in through a reviewed pull request with no bypass. Off, those changes fail the rule and the release needs an override. On, an unverified change still fails, and so does an out-of-order promotion. On the "Tested in an environment, unchanged" rule, the same option accepts differences made only of verified direct changes.

Code promoted unchangedCopy Anchor Link

Releases only. lineageUnchanged needs a deployment in each selected environment, with unchanged content from there to the release. Require passing tests also needs passing trusted test evidence on that content. Accept verified hotfixes accepts only verified changes made straight on the target branch. Without that option, different code fails even if the change was verified. The reason names a missing environment, changed paths or missing passing tests.

Coverage along the promotion pathCopy Anchor Link

Releases only. chainCoverage uses trusted coverage along the whole path. Set Minimum line coverage (minLines, 0 to 100) and optional report names (names). It checks the lowest reported line percentage among matching reports. No matching coverage fails.

Every environment (everyEnvironment) also requires matching trusted coverage for each upstream deployment hop. Evidence lists any missing environments. This checks evidence per hop as well as the path's minimum; it does not let one report for different code satisfy every hop.

Findings along the promotion pathCopy Anchor Link

Releases only. chainFindings fails when any finding along the whole path is at or above Severity (atOrAbove: critical, high, medium or low). Require a scan (requireScan) waits for a trusted scan during the first 120 seconds after the release was created, then fails if none arrives. Missing or invalid findings counts return error.

Promotion rule statusesCopy Anchor Link

All four rules need release provenance (Business and above). They return pending while lineage is being collected, error when the path could not be read or the plan lacks release provenance, and fail for incomplete or truncated lineage. That failure's reason names where the walk stopped or says the path was too long to read in full. They cannot pass an unknown path or evidence. A complete lineage lets each rule check its own requirements.

The declared-path rule fails when the release is off the path, including when it does not match the last step of a policy-defined path. A failed, skipped or unreadable step is reported before a pending step.

In Observe, results are recorded. In Enforce, a blocking failure rejects the release; pending or error holds it. Use an override when it must proceed. Overrides record the unmet rules and do not change their status to pass.

Prodgator approversCopy Anchor Link

Requires a number of approvals given in Prodgator.

A rejection from any eligible approver fails the rule.

When an approval does not countCopy Anchor Link

Prodgator records every approval, but the rule counts only approvals that meet its settings. The deployment card says which approvals did not count and why, for example "Does not count: Nate Ferrell triggered this deployment, and this rule does not allow self-approval." An approval does not count when:

• the approver started the deployment (their linked GitHub account is the workflow run's actor) and self-approval is off in the rule or in the approval settings,
• the approver is not one of the rule's users, not in one of its groups, and the rule does not count anyone who can approve,
• on a pull request, the approval was given on an earlier commit and the rule asks again after a new commit.

Approving more than once changes nothing: the rule reads each person's latest answer, and the card shows it once with a count.

Clicking Approve can still submit your required-reviewer review on GitHub (reviewer forwarding) when your approval does not count toward the policy. The two gates are separate: the GitHub review answers the environment's required reviewers, and the Prodgator protection rule waits for the policy.

If the deployment is stuck because everyone who could approve it started it, you can:

• ask another member of the approver group, or another listed user, to approve it,
• add a second person to the approver group, then have them approve,
• allow self-approval in the rule (a new policy version) and turn self-approval on in the approval settings, then click Re-evaluate,
• switch the policy to observe or remove its binding (both need the Edit release policies permission and are written to the audit log), and switch it back afterwards.

A break-glass override does not help here: it only covers compliance policies.

GitHub factsCopy Anchor Link

Checks facts about the deployment on GitHub.

If Prodgator cannot read the facts from GitHub, the rule returns error and Prodgator tries again later.

AttestationsCopy Anchor Link

Requires attestations sent by the Prodgator report action for the deployment's commit, each with status pass. Attestations from any workflow run on that commit count, so a CI workflow can provide the evidence a separate deploy workflow is gated on.

For each requirement, the newest matching attestation decides. pass satisfies it; fail, warn and info do not. With no matching attestation yet, the rule is pending. A rerun that sends a passing attestation replaces an earlier failure.

The rule fails when any requirement has a newest attestation that does not pass, waits while one is missing, and returns error when Prodgator cannot read attestations. A report from any run on the same commit re-evaluates every deployment waiting for approval on that commit at once (up to 50 per report, newest first; the rest are picked up by the scheduled re-checks).

Evidence from earlier stepsCopy Anchor Link

For Attestations and Security findings rules on release policies, Use evidence from earlier steps in the provenance chain allows the nearest earlier evidence when the evaluated commit has none of its own. This switch needs the provenance feature on Business or Enterprise. It is on for new rules and templates. Existing stored rules without this setting keep it off, including when you edit and save them. Pull request only policies do not show the switch.

Maximum evidence age (days) accepts an integer from 1 to 90 and defaults to 30. Evidence must be for the same code, within that age, and verified through every intervening hop. Trusted-source filters still apply. A changed, unverified, bypassed, stepped-over, back-merged, unknown or unreadable hop, or lineage that is not ready, prevents that evidence from counting. Missing or unreadable evidence never passes the rule: when the earlier evidence could not be read, the result is an error that says so, not a wait. Prodgator picks the nearest earlier step that has evidence before applying the age limit: when that evidence is too old, the result waits and says so, and a fresher record farther back never stands in for it. Security findings rules add up the findings of every trusted scan at that step (the newest per scanner name and job), so a clean scan from one tool cannot hide another tool's findings, and one scan there that is too old makes the whole step unusable. An existing scan requirement in an Attestations rule likewise reads every scan at that step and fails when any of them is not passing. When the evaluated commit has its own trusted scan attestations but no uploaded findings, their counts are added up the same way and checked against the limits, and earlier evidence is not used. If those counts cannot be read, the result is an error. When your plan lacks the provenance feature, the editor says so and the result reads "chain evidence is not part of your plan". Evidence already reported on the evaluated commit takes priority, including a failure.

Results name the source environment or branch, the run and the number of verified hops. Links open the run and the release's promotion path when their IDs are available.

Deprecated scan requirementsCopy Anchor Link

Existing scan rows show Scan (deprecated). Use Convert to a Security findings rule to remove every scan requirement and add one Security findings rule. Other requirements stay. A rule with only scans is removed. The new rule requires a scan, allows no introduced critical or high findings, has no open-finding limit, keeps the old blocking setting, and has chain evidence off. Scan name and workflow filters are dropped and listed in the confirmation toast.

If the policy already has a Security findings rule, conversion asks you to confirm that you checked its settings before removing the scan requirements. Its settings are kept and no second Security rule is added. Conversion needs the Security reports plan feature; the button explains this and is disabled when your plan lacks it.

Coverage, Test results, SBOM and Build provenanceCopy Anchor Link

Four rules check one kind of attestation each, with options the generic Attestations rule does not have. They work for releases and pull requests. Each takes the newest matching report for the commit, only from trusted sources unless that is turned off, and each has the Use evidence from earlier steps in the provenance chain switch and Maximum evidence age (days) described in Evidence from earlier steps. With no matching report the rule is pending; when attestations cannot be read it returns error.

Code coverageCopy Anchor Link

The rule compares the reported percentages with your minimums and ignores the status the report carries. A report without a line percentage fails.

Test resultsCopy Anchor Link

Set at least one limit. A report with invalid counts fails, and so does a report where no test ran.

SBOMCopy Anchor Link

Format is Any, CycloneDX or SPDX. Any accepts either supported format. A report in another format, or with no format, fails.

Build provenanceCopy Anchor Link

What satisfies the rule: a build provenance attestation sent by the Prodgator report action from the output of GitHub's actions/attest-build-provenance (the report action reads the bundle you point it at). Prodgator reads the in-toto statement in the bundle and sets the status itself. The attestation passes only when the predicate type is SLSA provenance, every subject has a sha256 digest, the source commit is the commit of the report and the source repository is the repository of the run. Otherwise it fails and the reason names the mismatch.

Prodgator verifies the Sigstore signature of the bundle: the signature, the certificate chain to the GitHub or public Sigstore trust root, the signing time (a Rekor entry or GitHub's timestamp), the GitHub Actions issuer, and that the certificate names the repository of the run and the commit of the report. A failed check never changes the pass or fail of the attestation itself. It is a separate result, and Require a verified signature decides whether it matters. The reasons a signature does not verify, the trust roots and the limits (a 64 KiB bundle, a 96 KiB attestation) are listed under Signature checks. GitHub Enterprise Cloud with data residency is not supported yet. Attestations saved before Prodgator read the statement itself (no SLSA predicate type or no subjects) fail.

A passing result reads "provenance requirements pass (signature verified, signed by .github/workflows/release.yml)" for a verified attestation and "provenance requirements pass (signature not verified)" otherwise.

The signer workflow option (signerWorkflows, available in policy files, not in the editor) matches the workflow named by the signing certificate when the signature is verified, and the workflow named by the run's sign-in token when it is not, never a workflow path a client claims. When the job runs a reusable workflow, that reusable workflow's file is the signer: write .github/workflows/release.yml for a file in the same repository, or owner/repo/.github/workflows/build.yml for one in another repository.

What is matched: the certificate's workflow (for an unverified attestation, the token's job workflow ref, or its workflow ref when the job calls no reusable workflow), for example acme/api/.github/workflows/release.yml@refs/heads/main. Prodgator drops the @ and everything after it, so the branch, tag or commit is not part of the match and a pattern cannot pin one. When the rest starts with the repository being checked (acme/api/, letter case ignored), that prefix is removed. The remaining path is compared with each pattern case-sensitively, so .github/workflows/Release.yml does not match .github/workflows/release.yml. In a pattern, * stays within one folder and ** crosses folders. The builder option (builders) matches the builder id of the signed statement with the same glob rules, so end a pattern with @** to accept any ref. The workflow writes that id, so a pattern matches only the signer workflow URL or a GitHub runner id that is the certificate's runner type; any other id is not trusted (see Signature checks). A builders pattern that matches the signer workflow URL does not check the runner type: to require GitHub-hosted runners, use custom Rego on verification.runnerEnvironment. Custom Rego can read the certificate's runner type as verification.runnerEnvironment and verification.sameRun, which is true when the certificate was issued to the run that sent the report. An unverified attestation fails a rule that sets builders, with the reason "provenance builder cannot be checked: signature not verified".

Evidence from earlier steps on these rulesCopy Anchor Link

The same rules apply as for Attestations: the evidence must be for the same code, no older than the maximum age (30 days by default, 1 to 90), and verified through every earlier hop. The rule fails closed: a changed, unverified, bypassed or unknown hop, or lineage that is not ready, means that evidence does not count. Evidence on the evaluated commit takes priority. The age you set is kept when you turn the switch off and on again.

If your plan lacks the provenance feature, the switch is disabled in the editor and the result says "chain evidence is not part of your plan". The rule then uses only the evidence of the commit itself.

Self-reported resultsCopy Anchor Link

Results sent from CircleCI, Buildkite, Jenkins or another CI system through Any CI are self-reported: the pipeline's own word, which Prodgator cannot verify. They are stored apart from trusted attestations, so a rule ignores them by default.

The Attestations, Code coverage, Test results and SBOM rules each have the option Count self-reported results from other CI (not verified). It is off by default (allowSelfReported in a policy file). When it is on:

• The rule can also use a self-reported result for the commit. It uses one only when the commit has no matching result from your connected provider, whatever that result's trust. Provider results always come first.
• The result names the self-reported results it used, so you can tell it from verified evidence.
• Only the policy whose own rule has the option on sees self-reported results. Turning it on in one policy changes no other.
• "Only count trusted sources" does not hide them, because the option is the explicit opt-in.

The Build provenance rule has no such option. Other CI systems cannot send build provenance or ownership reports, and a self-reported result never satisfies a provenance check. Seeded and template policies leave the option off.

A new report wakes the pending gates of its own run, and of the same repository and commit. A result filed for a repository that is linked to a provider repository counts at that repository's next evaluation. In Rego, self-reported results are in input.self_reported_attestations, not input.attestations (see the input document).

Required checksCopy Anchor Link

Requires GitHub check runs and commit statuses on the commit (the pull request's head, or the release's commit). Works for releases and pull requests.

The rule fails when a required check fails, and waits while one is still running. If some checks ran on the commit but none matches a required name, the rule keeps waiting: that required check is missing.

Checks GitHub requires that have not startedCopy Anchor Link

On a pull request, Prodgator also reads the status checks that GitHub requires on the base branch: required status checks in repository and organization rulesets, and in classic branch protection. It leaves out Prodgator Policies itself. A required check that has not reported on the commit yet counts as a check that is coming, so the rule waits for it with the reason "waiting on required checks that have not started", followed by the check names. This covers a pull request from a fork whose workflows wait for a maintainer to approve them, and one whose workflows cannot run because of merge conflicts. GitHub lists those checks as "Expected" on the pull request.

• A required name, * included, matches these checks by name, so * waits for every required check, reported or not.
• Require every check to be green waits for them too, unless they match an ignored name.
• A workflow run on the commit that is queued, waiting, or waiting for approval also counts as a check that exists and has not finished.

Prodgator reads the base branch's rules with the GitHub App's Administration: Read and Metadata: Read permissions, and reuses what it read for up to 5 minutes per repository and branch. Workflow runs are read with Actions: Read. When a run is created or finishes, and when a check suite finishes, Prodgator evaluates the pull request again.

When no other checks runCopy Anchor Link

Some commits get no checks at all, for example a change to files no workflow runs on. The only check on them is Prodgator Policies itself, the base branch requires no other check, and no workflow run is pending. With Pass, the rule waits for checks to start and then passes with the reason "no other checks ran on this commit". It waits for the number of seconds you set, counted from when Prodgator first saw the commit: the first evaluation of the pull request's head commit (or merge group commit), or the deployment's creation for a release. That gives CI time to register its checks. Until then the rule is pending with the reason "waiting for checks to start", and Prodgator evaluates the pull request or release again when the time is up, even if GitHub sends nothing else. If a check starts during that time, the rule works as usual.

If Prodgator cannot read the base branch's required checks (for example, the installation has not accepted Administration: Read), it does not pass a pull request with nothing reported. The rule stays pending with the reason "could not read the branch's required checks", and Prodgator tries again a few times.

With Keep waiting, the rule waits until every required check reports, so a commit without checks stays pending until someone pushes a commit that runs them or overrides the gate.

Rules saved before this setting existed behave as Pass with 120 seconds. Policies saved before Prodgator read the base branch's required checks wait for them too, without being saved again.

Change sizeCopy Anchor Link

Pull requests only. Limits how big a pull request may be, to keep changes small enough to review.

A new rule starts with 30 files, 800 lines and these paths: **/package-lock.json, **/yarn.lock, **/pnpm-lock.yaml, **/go.sum, **/Cargo.lock, **/poetry.lock, **/*.snap and **/dist/**.

The rule passes within the limits and fails above either one, with a reason that names the counts and the limits, for example "too large: 41 files changed, limit 30". It returns error when Prodgator could not read the pull request's files from GitHub.

The totals come from GitHub and cover the whole pull request, but Prodgator lists at most 300 files. When a pull request has more, excluded paths are taken off only for the files in the list: files past it always count, so the rule can count too many but never too few. The reason says so when this happens.

Pull request detailsCopy Anchor Link

Pull requests only. Checks where a pull request comes from and what state it is in.

Turn on at least one check: allowed branches, a size limit, or forks or drafts off.

The rule fails for a branch that is not allowed, a fork when forks are off, or a size above a limit, naming each problem, for example "101 files changed, the limit is 100". With a size limit set, it returns error when Prodgator could not read the pull request's files from GitHub. Unlike Change size, the counts cover every file; use Change size to leave out lock files and other generated paths.

Protected pathsCopy Anchor Link

Pull requests only, on the Business plan. Guards folders and files that need extra care, such as infrastructure or database migrations. The rule has 1 to 10 entries, each with:

A changed file counts for an entry when its path matches, and for a renamed file also when its old path matches, so moving a file out of a protected folder still counts.

An approval counts when it is a GitHub review that approves and is not stale, or a Prodgator approval given on the pull request's latest commit, from a listed user or a member of a listed group. The author's approval never counts, and someone who approves on GitHub and in Prodgator counts once.

The rule:

• fails when a Block entry matches, naming up to 10 of the paths, for example "changes to protected paths: infra/prod.tf",
• waits while a Require approvals entry has fewer approvals than it needs, for example "needs 2 approvals from octocat or the rule's approver groups for infra/**",
• passes when no protected path changed, or every matching entry has its approvals,
• returns error when Prodgator could not read the pull request's files, and when more than 300 files changed: Prodgator lists at most 300 files, and a file past the list could be protected. Split the pull request or ask someone who can override release policies to override the gate.

Code ownersCopy Anchor Link

Pull requests only, on the Business plan. Every changed file that has code owners needs an approval from one of its owners. Owners come from your CODEOWNERS file, which the Prodgator report action sends for the base branch. Prodgator uses the report for the base commit of the pull request, or else the latest report for the base branch.

Ownership follows GitHub's rules: the last matching line wins, a pattern starting with / matches from the repository root, a pattern ending in / matches everything in that folder, and a pattern without a / matches at any depth. * does not cross /, ** does: docs/* matches docs/a.md but not docs/guides/a.md. A line without owners leaves its files unowned.

A file is satisfied by an approving GitHub review that is not stale, or a Prodgator approval given on the pull request's latest commit, never the author's. A user owner (@ann) matches the reviewer's GitHub login, or the GitHub account linked to the Prodgator approver. A team owner (@acme/platform) matches a Prodgator approval from a member of the mapped approver group.

The rule:

• waits while an owned file has no approval from its owners, naming up to 10 files and their owners, for example "needs approval from: @acme/platform (infra/main.tf), @ann (docs/a.md)",
• passes when every owned file has an approval, or when no changed file has owners,
• follows When the base branch has no ownership report when there is no report, with the reason "no ownership report for the base branch; add the ownership input to the Prodgator report action",
• returns error when Prodgator could not read the pull request's files or the ownership report ("the ownership report could not be read right now"), and when more than 300 files changed.

GitHub's own code owner reviews still work through Require GitHub approval on a GitHub reviews rule, which reads GitHub's review decision. You can use both rules in one policy.

Security findingsCopy Anchor Link

Works for releases and pull requests. On the Business plan for pull requests, and it needs security findings in your plan. Limits how many security findings a change brings in and, if you like, how many the repository may have open.

Set at least one limit, or turn on the scan setting.

What counts as new. Prodgator collects the findings reported for the commit: security reports and run reports uploaded for it and, for a pull request, GitHub's open code scanning alerts on the pull request's merge commit, the vulnerable packages the pull request adds (GitHub dependency review) and secret scanning alerts first found in one of its commits. The same finding reported twice counts once. A finding is new when it is not open on the baseline:

• When the pull request targets the repository's tracked branch (the branch the Security page follows): the repository's open findings from every source.
• When a pull request targets another branch: the open findings uploaded for that branch.
• For a release: the repository's open findings from every source, without the findings first seen in this commit's own reports. A release commit on the tracked branch opens findings on the Security page as soon as its reports are processed, so those findings still count as new for the release.

The rule:

• fails when a severity is over its limit, for example "introduces 1 critical and 2 high findings (limit 0 critical, 0 high)",
• waits with "no security scan reported for this commit yet" when the scan setting is on and nothing reported,
• returns error when a limit is set and a source it needs could not be read, for example "code scanning alerts could not be read; try Re-evaluate", and when security findings are not part of your plan.

A GitHub source that is not set up for the repository (no code scanning, or no dependency graph) is skipped, not counted as an error. When GitHub refuses a read because of a rate limit, the source counts as not read and a rule with a limit returns error for that evaluation. Re-evaluate to read it again. Security, GitHub's sources included, is read only for policies with this rule, custom rules or Rego.

These intelligence settings are optional and default to off. KEV and EPSS do not change a finding's severity. See Vulnerability intelligence for the data sources and custom Rego facts.

Required reusable workflowCopy Anchor Link

Requires that the GitHub Actions runs behind a change called one or more reusable workflows, for example your platform team's build or scan workflow. Works for releases and pull requests:

• A release reads the calls of the deployment's workflow run.
• A pull request reads the calls of every workflow run on its head commit (or merge group commit), together.

The rule:

• passes once the listed workflows were called at an allowed ref, all of them or one of them depending on Which workflows,
• waits with the reason "waiting for workflow runs to report" until a run has reported its calls,
• on a pull request, waits while a workflow run on the commit has not finished, naming the workflows it still waits for,
• with Require an attestation from the workflow, waits while a called workflow has not sent its attestation yet,
• fails once the runs finished without the calls ("not called: ...") or called them at a ref the rule does not allow,
• returns error when Prodgator could not read the workflow runs (or the attestations, when it needs them), and for releases from GitLab, Bitbucket or Azure DevOps, which do not report reusable workflow calls.

Prodgator records the calls from GitHub's workflow_run events. Runs recorded before the rule existed have no calls on record, so a release of such a run waits until its run sends another event, for example on a rerun.

Allowed actorsCopy Anchor Link

Limits who may start a release or author a pull request, by GitHub login, approver group or bot, and can require an approval from someone else. See Allowed actors.

AI-assisted changesCopy Anchor Link

Asks more of an AI-assisted pull request or release: extra approvals, an approval from an approver group, or a label. Other changes pass. Business and Enterprise plans. See AI-assisted changes.

For any rule, choose whether it is blocking when you add it.