Reading your worklist¶
Open a container from My applications. The page is deliberately sparse on first load. Rather than listing every finding at once, it tells you whether the build can be submitted, what is standing in the way, and which change to make first.
The situation line¶
The first line on the page says one of four things.
| Line | Meaning |
|---|---|
| This build cannot be submitted for security review yet. | A hard gate failed. The sentence names each failure, and each one has a fix listed below. |
| Every gate passes, but findings remain open. | Nothing is blocking, but the open findings will go to the reviewer as they are. |
| Submitted. | A review merge request is open and a reviewer will pick it up. |
| Clear. | Nothing is open. Tag a release and run the scans to open a review. |
This line describes whether the build can be submitted. It does not predict what the reviewer will decide.
Under the line, chips count findings by severity, and a short note says what changed since the previous scan: how many findings were resolved, how many are new, or that nothing changed.
Where this build is¶
A strip of five steps shows where the build is in the process: built, scanned, findings, review MR, authorize. The current step is highlighted. If the review MR step reads Not open, that is because a review only opens when every scan passes on a tagged run.
Bands¶
Findings are grouped into bands, worst first. Each band has its rule at the top so you know what is expected before you open anything.
| Band | Rule |
|---|---|
| Critical CVEs | Fix only. A Critical is never justified, and the pipeline closes any review that carries one. |
| High CVEs | Fix if a fix exists. A High with an available fix will be refused by the reviewer. Only a High with no fixed release can be justified, and the reviewer will look closely at the reason. |
| Medium and Low CVEs | Fix where a fix exists. Where none does, write a justification. |
| Code findings | Fix the code, or exclude the rule by id with a reason. |
| Credential patterns | Confirm whether the match is real, then fix or exclude with a reason. |
| Blocking checks | Fix. These are hard stops with one specific fix each, and none of them can be justified. |
Groups¶
Within a band, findings are grouped by the change that clears them, so the list is as short as the work is.
- A package appears once, in the band of its worst CVE, and the number beside it is how many CVEs one update closes. The row names the version that closes them. If some CVEs in the group have no fix yet, the row says so rather than implying the update clears everything.
- A static analysis rule with sixty instances is one row, and the row says how many files it touches.
- Credential pattern matches that did not verify are grouped by file.
- Blocking checks appear on their own.
Each row ends with the action to take, such as UPDATE, FIX, JUSTIFY, or FIX OR EXCLUDE.
The finding page¶
Open any row to get the finding page. It says what the finding is, where it is (file and line, package, detector, or commit), why it matters, and what closes it. If a justification is allowed for this kind of finding, the page shows the exact lines to add to cdso_config.yml and which section they belong in. The Explainable AI narration on the page is built from the scan evidence and cites it.
The Next control at the bottom takes you to the next finding that needs a different change, rather than another instance of the same rule.
After you make a change¶
Commit and push. The build runs, but the scans do not start on their own; press play on the scans job in the review stage of the pipeline. The Then line at the bottom of the worklist names the job. When every scan passes on a tagged run, the pipeline opens the review merge request.
