The reviewer¶
This track is for the Security Control Assessor, or whoever holds that responsibility on your team. Attest brings each submission to you with the gate results, the evidence, and the developer's justifications already in place, and explains each finding in plain language. You read, decide, and sign. The explanation is drafted for you; the decision is not.
What you are responsible for¶
- The queue of open submissions, and claiming the ones you are working on so nobody else picks them up.
- A decision on every finding: accept the risk with a written reason, or reject and send the build back.
- The authorization itself, which is approving the review merge request in GitLab under your own account.
- A written reason whenever you reject.
What you do not have to do¶
You will not have to read raw scanner output to work out what a finding means. The console explains each one from the evidence, and the raw file is one click away if you want to check it. You will not receive submissions that are incomplete; the pipeline only opens a review when every scan has passed and every justification is written. And nothing in Attest will ever approve on your behalf or let you approve on someone else's.
The process from your side¶
| Step | What happens | |
|---|---|---|
| 01 | Open a finding | The findings that need you are listed on the package page. Open one to see the full picture. |
| 02 | Read the explanation | What the finding is, why it matters, how confident the scanner is, and where the evidence came from. |
| 03 | Decide with a basis | Accept the risk with a written reason, or reject and send it back to engineering. |
| 04 | Record authorization | Once every finding is decided, record your authorization. Approving the merge request in GitLab is the final step. |
Getting started¶
Sign in. With the reviewer role you land on Review, which is your queue, oldest first. Open the container at the top. The header tells you the version, the deployment level, who submitted it, and which merge request it came in on.
The first time you claim a container or record a decision, the console asks you to connect your GitLab account. This is a one time step and it is what allows your decisions to be recorded under your own name. See Authorizing for how it works.
From there, step through the findings. Each one asks for a written basis before it lets you move to the next.
Pages in this track¶
- Your queue covers what is in it, how it is ordered, and how claims work.
- Reading a package walks through the header, the gates, the evidence, and the Explainable AI narration.
- Deciding each finding covers passed checks, hard gates, and soft findings, and what each asks of you.
- Authorizing explains the GitLab connection and what approve and reject each do.
- Reviewing an unchanged container again explains how the delta shortens a second review.