The developer

This track is for the people who build and ship containers. You do not need to know anything about security policy to use Attest. When a check fails, the console tells you which rule failed, what evidence it failed on, and what change makes it pass. You make the change and move on.

What you are responsible for

There are four things, and they all live in your own repository or your own pipeline.

1. The Dockerfile and the dependencies it pulls in.
2. cdso_config.yml at the root of your repository. It holds the scan configuration and any justifications you write.
3. Starting the scans job on a build you want reviewed. Scans do not run on their own.
4. Tagging the release you want reviewed. Only a tagged run opens a review.

What you do not have to do

You will not have to read raw scanner output to understand a finding. You will not have to decide whether a risk is acceptable; that is the reviewer's job. And you will never be asked to approve, sign, or accept anything.

The process from your side

	Step	What happens
01	Build	You push. The pipeline builds the image from your Dockerfile.
02	Scans	You press play on the scans job in the review stage of the pipeline.
03	Findings	If anything failed, no review opens. Your worklist shows what to fix, one change at a time.
04	Review MR	On a tagged run where every scan passes, the pipeline opens a review merge request and a reviewer picks it up.
05	Authorize	The reviewer approves the merge request. Once it is merged, your pipeline continues and publishes the image.

Getting started

Sign in at attest.ulapcybo.app. If you have the engineer role you land on My applications, which lists the containers you hold. If you land somewhere else or see a message about having no role, see Sign in and roles.

My applications lists the containers you hold, with the one that most needs attention at the top.

Open a container. The first line on the page tells you whether the build can be submitted and, if not, what is in the way. Below that, findings are grouped by the change that clears them, worst first. Open the first one, read what it says to do, make the change, push, and press play on the scans job. That is the whole loop.

Pages in this track

1. Connecting your pipeline covers the CI include and the config file.
2. Running the scans explains the manual scans job and why tagging matters.
3. Reading your worklist walks through the container page.
4. Fixing what blocks goes through each hard gate and what closes it.
5. Writing a justification shows where a justification goes and what a reviewer looks for in it.
6. Choosing a base image covers the approved registry.
7. Submitting for review explains what opens the merge request and what happens after.