Overview

Supply Chain Security scans can report multiple Aqua Check IDs for the same source file and line, each with a different severity (for example, one High and one Critical finding on the same secret pattern). Image and repository Assurance Policies evaluate each finding independently against all applicable policies.

This article explains how overlapping severities affect Fail PR and Fail Build outcomes when multiple policies target different severity thresholds.

How Assurance Policies Evaluate Findings

Independent finding evaluation

• Each Check ID / finding is evaluated on its own merits.
• Two different Check IDs on the same file and line are two separate findings, not a single merged result.

Cumulative severity controls

Severity selectors in assurance policies are cumulative:

A High-threshold policy still matches Critical findings because Critical is above High.

Example Configuration

Scan contains on one file

• Check ID passwords-in-plain-text — High
• Check ID stripe-secret-token — Critical

Build scan result

1. Policy A matches the Critical finding → build fails (exit code 13 when enforcement applies).
2. Policy B matches both High and Critical findings, but Fail Builds is disabled → warning only for build failure purposes.

Outcome: the build fails because of Policy A and the Critical finding, even though Policy B does not fail builds.

The High-severity policy does not override or downgrade enforcement from the Critical policy.

PR scan result

Both policies have Fail PRs enabled. A matching violation fails the Aqua PR scan. To block merges in Azure DevOps (or similar), configure the Aqua pipeline as a required build validation on the target branch.

Best Practices

1. Align severity policies with intent — Use Critical-only build blocking when only critical secrets should stop releases; use High for PR gates with softer build rules.
2. Avoid duplicate Check ID overlap — Custom rules may increase overlapping detections; tune rules if noise is high.
3. Test in lab — Run a repository scan with known multi-severity fixtures before changing production policies.
4. Review exit codes — Build scanners return non-zero exit codes when any enforced policy fails; document expected codes in CI templates.

Verification

1. Run a build scan on a test repository containing High + Critical findings on the same line.
2. Confirm Policy A fails the build and scanner exit code reflects enforcement.
3. Confirm Policy B logs warnings without failing the build (when configured).
4. Run PR scan and confirm both policies can fail PR status when violations match.

Platform Coverage

Related Resources

• Supply Chain Security — Assurance Policies
• Image and artifact assurance