Compliance policies
Check your organization against compliance policies, run an evaluation, and override a decision with a reason.
Availability
Who can use this: see Roles.
- Manage compliance policies: Compliance and Org admin.
- Run compliance evaluations: Release manager, Compliance and Org admin.
The Compliance page checks your organization against a set of policies and, on the Enterprise plan, can block GitHub deployments that fail them.
Default policies
The first time anyone opens the page, Prodgator creates five policies:
| Policy | Check | Passes when |
|---|---|---|
| Require CI pass before deploy | The success rate of recent runs is at or above the threshold (100%) | |
| No critical vulnerabilities | There are no open Critical security alerts | |
| Deploy frequency SLA | At least 1 successful deployment to a protected environment in the last 7 days. Otherwise a warning, also while no gate protects an environment | |
| MTTR SLA | No recent run failed, or at least one recent run succeeded | |
| No high-severity secrets exposed | There are no open secret scanning alerts |
and read the organization's 100 newest runs from connected providers. Runs from other CI systems are self-reported and never count toward them.
Each policy shows its rules, the check each rule uses, and its recent results. People who manage compliance policies (Compliance and Org admins) can turn a policy on or off with its switch. Other members see the policy's state as On or Off instead. Disabled policies are skipped.
Running an evaluation
Click Run Evaluation (Release managers, Compliance and Org admins) to check every enabled policy against your organization's current runs, deployments and alerts. Each policy then shows passing, warning or failing, with the evidence for each rule (for example "Success rate is 92.0%, threshold is 100%").
The cards at the top show the pass rate and the number of policies passing and failing.
Security evidence
Checks like "no critical vulnerabilities" count open security findings and the scan results behind them. Their evidence names both counts, for example "2 open critical findings (5 scan results from 3 sources)", and keeps the scan results behind them (up to 500 per check; the security findings export has all).
Known exploited vulnerabilities
The check passes when no open security issue is a vulnerability on the CISA Known Exploited Vulnerabilities (KEV) list. It is not one of the default policies. To use it, a member with adds the rule to a policy through the app's policy API (, or for an existing policy). There is no rule picker on the Compliance page yet, and the public API does not create or change policies. The policy then lists the rule as No known exploited vulnerabilities (CISA KEV).
The check names up to five of the vulnerabilities it found, for example "2 open known exploited vulnerabilities: CVE-2021-44228, CVE-2023-4966". A withdrawn advisory never counts. If Prodgator cannot read its vulnerability data, the check does not pass: it fails, or warns when the policy is set to fail open.
Overriding a decision by hand
A deployment that a Block policy governs can also be answered by hand from the Gates or Pipelines page while it is still pending. That overrides Prodgator's decision, so:
- Compliance and Org admins can answer it (the compliance override permission). Release managers cannot, and neither can other members. If an enforce release policy is also bound to the environment, the answer counts as a release approval and also needs the permission to approve deployments (Org admins hold both; Compliance alone uses break-glass).
- Whoever answers must give a reason of 10 to 500 characters.
- The reason is written to the audit log and starts the comment Prodgator posts on GitHub.
With no Block policy on the environment, or on a plan without blocking enforcement, Prodgator does not answer the rule and a member who can approve deployments can answer it without a reason. API keys with always have to give a reason. To override a Block policy, a key also needs the scope; see API keys.
From the API
API keys with can read results at . See the Public REST API.