Running the scans

There are two things about scanning that catch most people out the first time: the scans do not start on their own, and a review merge request only opens on a tagged run. This page covers both.

Starting the scans

After the build stage finishes, the review stage contains one manual job. Its name depends on the deployment level and the container name, exactly as the container is named:

deployment_level	Job name
PRODUCTION	application-container-scans-<container_name>
anything else	container-scans-<container_name>

Open the pipeline in GitLab and press play on that job. If you are not sure which one it is, the container page in Attest names it for you.

The job itself is a waiter. It triggers the cDSO pipeline, which runs every scanner against the built image and publishes the results to the security repository, and it polls until that pipeline finishes. If you need the scanner logs, they are in the triggered cDSO pipeline, not in the waiter job. Attest picks the results up on its next refresh; the header of the console shows when the GitLab data was last read.

Tagged runs open a review

A scan on a branch or an untagged commit produces a worklist for you and nothing else. A review merge request opens only when every scan passes on a tagged run. Tag the commit you intend to ship, push the tag, and press play on the scans job in the tag's pipeline.

What a run produces

Each run writes to its own directory in the security repository, named for the container, the deployment level, and the pipeline id. Directories are never rewritten. The scan record includes the raw output of each scanner, the pipeline run with every stage and job outcome, and the scans job log. Attest links to each of these from the container page under Evidence.

Scan output on the container page: one file per scanner with its pass or fail, the pipeline run, and the scans job log.

When a scan does not finish

Gate G1 requires every scan stage to report. A scan job that fails or does not run leaves the evidence for the other gates incomplete, and the build cannot be submitted. Rerun the job. The pipeline reports per job, so the log names the one that stopped.

Rerunning after a fix

Push the fix, wait for the build, press play again. The new run gets a new directory and Attest compares it to the previous one, so your worklist shows what was resolved and what is new since the last scan.