Fixing what blocks

A hard gate cannot be risk accepted. When one fails, the build cannot be submitted until it is fixed. This page goes through each hard gate, what it is checking for, and what closes it.

Gate	The problem it found	What closes it
G1	A scan stage did not finish.	Rerun or fix the failed scan job. The pipeline reports per job.
G2	Packages in the image have vulnerabilities with no mitigation on record.	Update the package, or record a mitigation keyed by the CVE id.
G3	A file in the image matched a malware signature.	Remove the flagged file and rebuild. A malware hit is never justified.
G4	A live credential is in the image.	Revoke and rotate the credential, remove it from the source and the image history, rebuild.
G5	The base image is not from the approved registry, or the container runs as root.	Change FROM to an approved base, add a USER instruction, rebuild.
G6	Static analysis found code patterns that are still open.	Fix the code, or add an exclusion keyed by the rule id with a written reason.
G7	The Dockerfile has lint errors.	Fix the Dockerfile lines named in the finding. hadolint.ignores carries any deliberate deviation.

Vulnerabilities (G2)

The scanner inventories every package in the image and matches it against the public CVE list. You did not write these packages; they came in through your base image or your dependency list, and the fix for almost all of them is the same: use a version that has the flaw patched.

The worklist groups CVEs by package and names the version that closes the most. Where the fix is only in a prerelease, the row says so; a prerelease is not a release you ship on. Where no fixed version exists, the finding page shows the mitigation entry. See Writing a justification.

A Critical CVE always has to be fixed; the pipeline will not accept a justification for one.

Live credentials (G4)

The scanner looks for strings shaped like credentials. A verified match was checked against the provider and works. An unverified match is a pattern and nothing more; test fixtures, example keys, and hashes match too. Only verified matches fail this gate.

For a verified match, do things in this order: revoke and rotate the credential first, then remove it from the source and from the image history, then rebuild. Deleting the string from the current commit is not enough on its own, because it is still in the history.

Unverified matches do not block, but a reviewer sees every one. Open the file, decide, then fix or exclude with a reason.

Base image and user (G5)

Two checks in one gate. The FROM line must point at the approved registry, and the container must run as a named non root user. See Choosing a base image for the registry and the tag to pin.

Root is not an unconditional stop. At deployment_level: DEVELOPMENT it passes. At PRODUCTION it fails, and can be justified only with a reason a reviewer can check: what needs it, what limits it, and what would remove the need. The finding page shows the container_spec.root_user entry.

Static analysis (G6)

The scanner reads your source and flags patterns it considers risky. It is usually right and occasionally wrong. Treat each rule as one decision: fix the pattern where it is a real problem, or exclude the rule with a written reason where it is not. Use the map form in cdso_config.yml, not a plain list, so the reason travels into the scan record the reviewer reads.

Dockerfile errors (G7)

The finding names the line and the rule. Fix the line. An ignore in hadolint.ignores silences the rule for the whole Dockerfile, not one line, so say why the line is deliberate.

After the fix

Push, press play on the scans job, and the next scan record shows the gate passing. The worklist's "what moved" line confirms the finding as resolved.