Compliance¶

The Compliance tab on a completed run shows how well your environment meets each selected compliance framework.

Supported frameworks¶

owasp_llm and nist_ai_rmf are populated from AI-SPM findings. Enable AI-SPM scanning on a cloud account to get coverage against these two frameworks. Coverage is honestly partial: only the OWASP LLM risks and NIST AI RMF functions a static configuration scanner can actually observe are rule-mapped (for OWASP LLM, that's LLM01/02/03/06/10; for NIST AI RMF, the MAP and MANAGE functions). Everything else in either framework requires organizational or runtime evidence this scanner doesn't collect, and is not claimed as covered.

The built-in framework library (PCI-DSS 4.0, HIPAA, ISO 27001:2022, NIST CSF 2.0, GDPR) is served via GET /compliance-frameworks and is available in the Compliance tab.

Custom frameworks¶

You can define organisation-specific compliance frameworks under Settings → Custom Frameworks. A custom framework has a name, version, and a list of controls (JSON). Custom frameworks appear alongside built-in frameworks in the Compliance tab.

Custom checks¶

Custom checks let you register your own check definitions - title, description, severity, provider and resource type - under Settings → Custom Checks, and map them to a specific framework and control ID. They can be parameterized via Settings → Compliance Params.

The rule logic for a custom check is written in Rego, under Custom Policies. Rego is the single custom-policy language: use a Custom Policy to decide when a finding is raised, and a Custom Check to give that finding its compliance-control mapping so it counts toward a framework's score.

Evidence artifacts¶

When an inspection run collects compliance evidence (log exports, configuration snapshots), artifacts are stored per-control. Browse evidence under the Evidence section of a run, or download a ZIP bundle via GET /runs/{run_id}/evidence/bundle.zip.

Score breakdown¶

Each framework shows:

The score is green at 80% and above, amber from 60%, and red below that.

Controls that are not assessed¶

A control is not assessed when the run cannot say whether it is met. It is neither passed nor failed, and it is left out of the score. There are several reasons, and each has its own heading - the same words in the Compliance tab and in the compliance report.

What the framework card says¶

• N of M controls assessed, with · K not assessed when some are not - every control that is not assessed is a coverage gap, or the score states no reason.
• Scored on N of M controls, followed by a count per reason - at least one control is not assessed for a reason other than incomplete coverage. The percentage is of the N controls, not of the whole framework. The counts read, for example, 89 have no automated check, 4 not assessed for incomplete coverage, 3 not assessed (scanner not in scope).
• Qualified pass, in amber - the score is 80% or above, and a failing finding exists for controls that are not counted in it (the first reason in the table below). It is never shown in the green of a plain pass. Hover the badge to see how many controls: Qualified: a failing finding exists for 2 controls not counted in this score. The executive summary report prints Qualified pass for the same score.

Click a card to list its controls. The controls that are not assessed are grouped by reason; each group shows its heading with the number of controls, and a sentence saying what the reason means.

The reasons¶

A reason the console has no words for is still shown: its heading is made from the reason's own name, and the sentence under it says the console has no description of it. It is never dropped and never called a coverage gap.

Which scan is missing¶

Under Not assessed — scanner not in scope, where the score records which scan is missing, the controls are listed by the scan that would assess them - for example Needs an AWS account scan in the run. The scans named are an AWS account scan, an Azure subscription scan, a GCP project scan, a Kubernetes cluster scan and a codebase scan. Where any one of several scans would do, they are joined with "or". A control with no such line is one the score names no scan for.

Runs with more than one target¶

A run can scan several targets of one kind: two cloud accounts, several repository groups, two clusters, several images. When the scan of one target does not complete and another target of the same kind did complete, the other targets are still assessed, and the framework is scored over them (the conditions are listed below).

For each control, across the targets of a run:

• the control is failed when it failed on any target;
• it is passed when it passed on every target that was assessed;
• it is not assessed only when no target could be assessed for it.

The score is computed from those control results. The targets whose scan did not complete are named under the framework card and in the report, in one sentence: <targets> were not scanned completely; their controls are not assessed. Click the card to see, for each control, the targets it failed on or could not be assessed on. A target that passed is not listed.

The earlier, run-wide behaviour (the framework has no score and the card says the coverage is incomplete) is kept when:

• an incomplete scan cannot be placed on a target the run can name;
• no other target of that kind was scanned in the run;
• no other target ran the same sub-scanner (for a codebase or image scan);
• for cloud accounts, another account does not cover every provider the findings show;
• the run's record of what was scanned is not available (for example a resume or rescore that does not carry it).

In particular a run with a single repository group or a single cloud account is scored as before.

Passes and policy failures that name their findings¶

Where a control passed because a finding positively shows it, the control list (in the report, and in the console from the release that carries the console change) names those findings. A control that failed because of a custom policy lists the findings the policy matched, per policy.

When a framework has no score for a reason about your policies¶

If the organisation's custom policies cannot be read when a run is scored, the platform does not call a control passed that a policy may fail. The framework shows Not available — the organisation's custom policies could not be read when this run was scored. Its counts and failed controls are shown as on any run; they are not a score. The run does not fail. Rescore the run once the policies can be read. A deployment with no database configured has no custom policies to read and is not affected.

Compliance trend¶

On the Schedule Detail page, the Compliance Trend chart shows how your score for a framework has changed across the last 30 days of scheduled runs. Regressions show immediately as dips.

How scanner findings count toward SOC 2 and vulnerability-management controls¶

• Web application (DAST) scans. For SOC 2, a DAST finding fails the controls its check states, and only for the 17 checks the platform lists. A DAST check outside that list no longer fails CC6.6 by default; it is mapped by the finding's words like any other finding with no stated control. Findings stored by earlier scans keep the CC6.6 they were tagged with; a re-scan does not.
• Vulnerability advisories (image, dependency and SBOM findings) fail the framework's vulnerability-management controls. PCI DSS 11.3.1 (internal vulnerability scans, high-risk and critical findings resolved) is failed only by an advisory of high or critical severity; a medium advisory still fails 6.3.1 and 6.3.3. NIST CSF ID.RA-01 and CSA CCM TVM-07 ("vulnerabilities are identified") are no longer failed by an open advisory: the advisory is the identification.

Improving your score¶

1. Go to Findings, filter by the framework you want to improve.
2. Sort by severity - address critical and high first.
3. Use the Remediation Steps on each finding detail page.
4. Re-run the inspection to verify the fix.