Every system SuiteWright ships goes through the same pipeline: checkout, build the container, scan it for known vulnerabilities, deploy only if the container reports healthy. The scan step fails the build on a critical finding. No override flag.
That sounds like process theatre until you watch it work.
What the scanner actually catches
The interesting finding is almost never in code that was just written. It is in a base image that was fine six months ago and has since accumulated CVEs, or a transitive dependency four levels down that nobody chose deliberately. That is the class of problem humans are worst at noticing: nothing changed locally, so nothing feels risky.
A scanner does not get bored, and it does not assume that because last week’s build passed, this week’s will.
The honest cost
Two things make this annoying, and pretending otherwise would be dishonest.
Some findings cannot be fixed. A CVE with no upstream patch will fail your build forever
if you gate on it naively. Rebuilding does not help — there is nothing to rebuild to. The
fix is to scan with --ignore-unfixed so fix-less findings are skipped automatically, rather
than maintaining a hand-written ignore list that goes stale and eventually gets rubber-stamped.
A gate you routinely bypass is worse than no gate, because it buys the feeling of safety without the safety. If a critical finding can be waved through under deadline pressure, the scan is decoration. Gate on critical only, make it genuinely rare, and it stays meaningful.
Why it is worth it anyway
The alternative is discovering the same vulnerability when someone else finds it first.
Running this on a one-engineer shop is a deliberate trade: builds occasionally fail for reasons that are not my fault and not my code. That is the point. The scanner is the part of the process that does not get tired at 2am, does not have a deadline, and does not talk itself into shipping anyway.