The seven steps¶
Every container goes through the same seven steps. Each step leaves evidence behind, and every explanation the console gives cites that evidence.
| Step | Name | Who | What happens |
|---|---|---|---|
| 01 | Scan | Pipeline | Every scanner runs against the built image. Evidence lands in immutable, hash verified directories in your own security repository. |
| 02 | Explain | Attest | Every verdict expands to policy version, rule, threshold, and evidence hash, plus what would make a failure pass. |
| 03 | Justify | Developer | What cannot be fixed yet is assessed for reachability, upgrade path, and compensating controls. Drafted from evidence, every sentence cited. Engineers own the words. |
| 04 | Submit | Pipeline | A complete package opens the review merge request and joins the queue. Nothing incomplete reaches a reviewer. |
| 05 | Review | Reviewer | One decision at a time, in reviewer language, with claims that split the queue across a team. |
| 06 | Authorize | Reviewer | Approve under your own verified identity, enforced by the platform. Never a bot, never on someone's behalf. |
| 07 | On record | Everyone | Attributed, timestamped, anchored to an evidence hash, and exportable the day an auditor, a regulator, or a customer asks. |
Automation ends after step 05
Steps 01 through 05 run without a person. Step 06 is always a named person acting under their own identity. Explainable AI drafts, ranks, and explains, but it does not accept risk and it does not sign.
01 Scan¶
The developer pushes, and the pipeline builds the image. The scans are then started as a manual job in the review stage of the pipeline; they do not start on their own. Each scanner writes its result to the security repository under a directory named for the container, the deployment level, and the pipeline run. Directories are never rewritten; a new run gets a new directory.
02 Explain¶
Attest reads what the scanners wrote and evaluates the gate policy. The policy is deterministic code. There is no model in the decision path. A hard gate failure produces a verdict of DENY; a soft gate failure produces CONDITIONAL; all gates passing produces AUTHORIZE. Each gate carries its label, its tier, whether it passed, a one line detail, and the evidence it was evaluated against. See Gates and verdicts.
Explainable AI then narrates each gate in plain language: what the finding is, why it matters, and what closes it, grounded only in the pipeline's evidence.
03 Justify¶
Findings that cannot be fixed yet are recorded in cdso_config.yml in the application's own repository, keyed by CVE id, scanner rule, or file. The pipeline carries those entries into the scan record the reviewer reads. The developer writes them; Attest shows where they go and what a reviewer will want to see in them. See Writing a justification.
04 Submit¶
When every scan passes on a tagged run, the pipeline opens a review merge request in the security repository. That merge request is the submission. Nothing incomplete reaches a reviewer: a build with a failed hard gate never opens one.
05 Review¶
The reviewer's queue lists every open submission, oldest first. A reviewer claims a container so two people never review the same one, opens each finding in turn, reads the explanation and the evidence, and decides with a written basis.
06 Authorize¶
When every finding is decided and none is rejected, the Authorize control unlocks. Approving the merge request in GitLab, as the reviewer, is the authorization. Attest performs it on the reviewer's own GitLab session, never on a shared or system credential. A rejection closes the merge request with the reason posted, and engineering resubmits.
07 On record¶
The decision, the basis, the person, the time, the evidence hash, and the policy version stay together. The merge request in GitLab is the durable record; Attest's decision log points to it. Either can be exported the day someone asks.