Scan policies

A scan policy is the rulebook every scan of a tenant is judged against. It turns the findings of a scan into one verdict, pass or fail, with the reasons. That verdict is what a pipeline's exit code, a pull request check and the console's pass/fail badge show.

Each tenant has one active policy. Choose it under Settings, Scan policy. It applies to every scan that tenant starts afterwards: from the console, from the CLI, from a pipeline, and scheduled rescans.

#What a policy checks

A scan fails when any of these is exceeded:

The Scan policy page shows these as plain numbers for every profile, and, when you select another profile, exactly which rows would change and whether each becomes stricter or looser.

#Built-in profiles

There are 35 built-in profiles. The names that refer to a framework or regulation mean the limits follow the intent of that framework's vulnerability-management expectations. They help you meet a standard; they do not certify anything.

#General (8)

#Compliance (7)

#Industry (11)

#Workflow (7)

#Licences (2)

#Choosing one

Move towards stricter profiles in steps. Going from a permissive profile straight to Strict will fail almost every project on day one.

#Custom policies

When no profile fits, build your own. Owners and admins can:

• New custom policy (top right of the page): starts from the profile you choose;
• Customise this profile: copies the profile you are looking at.

A custom policy has a name, an optional description, a profile it starts from, and any of these limits changed:

While you edit, the editor shows how strict the result is and lists every difference from the profile it started from. Only the differences are stored, so everything you did not change is inherited.

Rules for custom policies:

• Names are unique within a tenant. A tenant can have up to 50.
• Edits apply to scans started after you save.
• A policy that is active cannot be deleted: switch to another first.
• A custom policy belongs to its tenant and is invisible to others.
• If an active policy is ever removed, scans fall back to Standard rather than failing.

#Through the API

All of this needs the admin role.

# List built-in and custom policies, each with its limits
curl -H "Authorization: Bearer $TOKEN" https://api.dpndncy.example.com/api/admin/policies

# Create
curl -X POST https://api.dpndncy.example.com/api/admin/policies   -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json"   -d '{"name":"Payments service","baseId":"release-gate","limits":{"maxHigh":0,"maxCvss":7}}'

# Change one (PUT /api/admin/policies/<id>), delete one (DELETE ...), or make one active:
curl -X POST https://api.dpndncy.example.com/api/admin/policy   -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json"   -d '{"policyId":"policy_1793969812737"}'

baseId is the id of a built-in profile from the tables above. Invalid limits are refused with the reason, for example maxHigh must be a whole number from 0 to 999.

#How a pipeline sees it

The CLI in --ci mode exits 0 when the policy verdict is pass and 1 when it is fail, and prints the violations. Changing the tenant's policy changes what pipelines do from the next run, with no change to the pipeline. See The dpndncy command line.