Reading a package

Open a container from your queue. Everything on the page came from the security repository in GitLab and links back to it.

The header

Container name and version. The deployment level it will run at. The merge request it was submitted on, with a link into GitLab and the author. The verdict the gate policy produced for this run.

The package header. The verdict card on the right says what is being asked of you: how many decisions remain and how many checks already cleared.

Verdicts

Verdict	Meaning
AUTHORIZE	Every gate passed.
CONDITIONAL	No hard gate failed, but soft findings wait on your decision.
DENY	A hard gate failed. This cannot be authorized; it goes back to engineering.

The verdict is the pipeline's read. Your authorization is your decision, and it is recorded separately.

The gates

Each gate is one security check the pipeline ran. It shows its label, its tier, whether it passed, and a one line detail with the numbers behind it. See Gates and verdicts for all thirteen.

The review order is hard gates first, then soft. A stepper along the top shows every gate and marks the ones still waiting on you.

The pipeline the container ran through, stage by stage. Each card lists the checks that ran there and how each came out. Anything that needs you is marked.

Explainable AI

Each gate expands to a plain language narration: what the finding is, why it matters, what would make a failure pass, and where the evidence came from. The narration is grounded only in the pipeline's evidence and cites it. It is drafted for you, and it never decides.

Evidence

The evidence panel shows, per scanner, the verdict and the counts that matter: unmitigated, mitigated, pending, and suppressed vulnerabilities; infected and scanned files; live and documented false positive credential matches; error, warning, and info Dockerfile findings; open and excluded static analysis findings; the running user and approved base.

Beneath the counts, findings are listed worst first. For vulnerabilities, each row carries the CVE, severity, the artifact it was found in, its state, and the developer's mitigation text verbatim.

Every scanner's raw output, the pipeline run with every stage and job, and the scans job log all open in a viewer from the same panel. The raw material is always there; it just is not the first thing on the screen.

The evidence panel for one gate: what the gate recorded, the scanner counts behind it, and the raw file one click away.

Justifications

The developer's justifications from cdso_config.yml appear beside the findings they cover, verbatim. A justification that reads "Mitigation pending" or is empty means the submission is not ready, and the pipeline will not have opened a merge request for it.

Controls

Every finding is mapped to the CCIs it evidences. Click a CCI to open the reference, which describes the control and the NIST 800-53 family it belongs to. See Glossary.

Traceability for one finding: source commit, pipeline, scanner, gate, and the controls it satisfies.

The delta

If this container has a previous scan, the page says what changed: findings resolved, findings new, or nothing. An unchanged container says so, and the second review cites the delta rather than starting over. See Reviewing an unchanged container again.