Policies & Gates

You will finish this page able to write a policy that decides whether a build passes, preview it against a real scan before it can break anything, and tune the scoring that ranks your backlog.

Gate policies

A gate policy is a set of declarative rules evaluated against a project's active findings. Each rule either fails or warns.

• One fail violation is enough to stop a build.
• warn violations never break a build. They are advisory.
• Resolved, fixed, accepted-risk and false-positive findings never reach your rules.

Find them at Settings → Gate policies (also reachable at /policies).

The page walks the model in three steps: 1 you write rules · 2 Argus checks every finding · 3 your pipeline passes or fails.

Built-in policies

Four starters ship ready to run.

Duplicate one, edit it, and save it as your own, saving never modifies the built-in.

Policy shape

A policy is JSON. Each rule is:

{
  "id": "crit-reach-exposed",
  "name": "Critical, reachable, internet-facing",
  "effect": "fail",
  "match": { "all": [
    { "field": "severity",       "op": "eq",  "value": "CRITICAL" },
    { "field": "reachable",      "op": "neq", "value": false },
    { "field": "internetFacing", "op": "true" }
  ]}
}

A match is either a leaf, { field, op, value }, or a combinator: { "all": [...] }, { "any": [...] }, { "not": ... }. Nest them freely.

Operators

Fields you can match on

Previewing before you enforce

This is the important step. Pick a project and click Run gate preview: the policy is evaluated against that project's latest real scan.

You get one of two headlines:

• This build would pass: no fail rule matched.
• This build would be blocked: with the count of failing violations.

Below it: N fail · N warn · N active findings checked, then a Why list naming each violation, the rule that matched, the finding, its severity and CVE.

Preview never saves and never blocks anything. Iterate until the count is what you expect, then click Save policy.

Argus warns you when the editor content does not match anything saved, an unsaved policy cannot be enforced yet, and an edited copy of a saved policy will run the last saved rules until you save again.

Drafting a policy with AI

Type what you want in plain English and click Draft policy (2 credits). Examples that work well:

• Fail the build on critical reachable KEV findings
• Warn on any hardcoded secret, fail if it is reachable
• Fail when EPSS is above 50% on an internet-facing asset
• Fail on critical or high SCA findings that have a CVE

Argus generates the rules, explains them in English, and drops them into the editor. Always preview before saving.

Evaluating from the API

Run a saved or built-in policy against a project:

curl -sS -X POST "$ARGUS_URL/api/graphql" \
  -H "Authorization: Bearer argus_live_xxx" \
  -H "content-type: application/json" \
  -d '{
    "query": "query Gate($p: ID!, $pol: String!) { EvaluatePolicy(projectId: $p, policyId: $pol) { policyName pass failCount warnCount evaluated violations { ruleName findingId severity cveId } } }",
    "variables": { "p": "<project-id>", "pol": "block-kev-reachable" }
  }'

Gate your pipeline on pass:

PASS=$(curl -sS ... | jq -r '.data.EvaluatePolicy.pass')
[ "$PASS" = "true" ] || { echo "Argus gate: blocked"; exit 1; }

Try an unsaved policy with PreviewPolicy(projectId:, policy: <JSON>). List what is available with ListGatePolicies.

To gate on the diff of a pull request rather than a whole project, use the CI script in Integrations.

Priority weights, SLA and retention

Settings → Priority weights controls how Argus scores and ages findings.

Risk score weights

How much each severity contributes to a project's risk score, 1-100 each.

SLA targets

Maximum hours to remediate at each severity. A finding older than its target is an SLA breach on the dashboard.

Range 1-8760 hours.

Data retention

How long scan results and finding history are kept. Default 180 days, minimum 30, maximum 3650. Records past the window are permanently deleted. There is no separate archive to restore from.

Settings → Archive shows the current window, the cutoff date, and how many completed scan jobs are pending deletion.

Reset restores the defaults above locally; click Save Changes to apply them.

Scan rules

Argus derives your rule catalogue from the rules that have actually produced findings in your projects, so the list reflects your code rather than a generic registry dump.

SAST rules

Settings → Rules → SAST Rules. Grouped by namespace (the first segment of the rule id, such as python), with a per-namespace search and counts.

Columns: Rule · Findings · Info · On. Filter by severity, or search by rule id.

Toggle a rule off and it stops reporting new findings from the next scan onward. Findings it already reported stay open, Argus never silently closes your backlog for you. Rules default to on; turning one off is recorded as an override you can revert at any time.

Open a rule for its id, title, severity, finding count, and where it came from. Per-rule parameter tuning is not supported by the scan engine yet, the on/off switch is the only setting that affects a scan today.

Secret rules

Settings → Rules → Secret Rules. The same model for credential detection rules, including Argus's entropy and semantic passes.

Columns: Rule · Rule ID · Severity · Findings · On. Same override behaviour, same messages.

Rule edits require Admin.

Agent approval gate

For regulated environments, require a human to approve any autonomous fix before it runs.

Turn on Fixes require approval. Agent work then queues as a request that an Admin must approve or reject on the Agent Requests page.

Separation of duties is enforced: a Developer can request an agent action; only an Admin can approve one. Approvals and rejections are written to the audit log.

Scan policies, inventory, not enforcement

Settings → Scan policies is a separate feature and it is worth being precise about what it is.

A record on that page is an inventory entry for a security control you operate: a name, a type label (Block, Alert, Warn, Audit) and the effectiveness scores you model. Nothing in the scan pipeline reads it. It cannot fail a scan or block a merge. Build gating lives on Gate policies, above.

Its useful part is the Risk Reduction Calculator: score a control on Effectiveness, Coverage and Reliability (0-100 each) and Argus combines them defence-in-depth style:

combined = 1 − (1 − Effectiveness) × (1 − Coverage) × (1 − Reliability)

The banner then reports combined risk reduction across all your active control records. Use it to model your control stack for a risk committee, not to gate a build.

Next

• Team and access, who is allowed to change these
• API reference, evaluate policies from a pipeline