Teams hebben al gates. Ze verstoppen ze onder groene vinkjes en goede hoop. Een PR zegt “ziet er goed uit”, iemand drukt op approve, en productie krijgt wat de haast heeft overleefd. Dat is geen gate. Dat is een beleefde schouderophaal.

Een bruikbare gate vraagt om bonnetjes. Draaiden de tests op deze commit? Welke scanner gaf deze uitslag? Welke dependency-set ging de build in? Welke mens keek naar het risicovolle stuk? Als je die vragen niet vanuit de PR zelf kunt beantwoorden, draait de review nog steeds op geheugen en vibes.

PR review evidence hoort naast de wijziging te staan. Ik wil testresultaten zien, lint-output, security findings, een korte risico-notitie als de wijziging auth of datastromen raakt, en links naar gegenereerde artifacts. Voor supply-chainwerk wil ik ook provenance en een SBOM. SLSA geeft een helder frame voor artifact provenance. OWASP ASVS geeft taal voor appchecks in plaats van hoopvolle reviewnotities.

Gesanitiseerd Gate-scherm met demo-PR, evidence artifacts, policy checks en een geblokkeerde release.
Gate met synthetische data: checks, evidence-artifacts, deploy readiness en een geblokkeerde release wanneer bewijs ontbreekt.

Deploy readiness stelt een andere vraag. Een schone PR bewijst niet dat de release zonder gedoe naar buiten kan. De gate moet weten welk artifact je promoot, welke omgevingsregels gelden, wie mag goedkeuren, welke branch mag deployen, welke config wijzigde en hoe je terugrolt als de release op het meubilair begint te kauwen. GitHub environments ondersteunt die vorm al: protected environments, required reviewers, branch restrictions en custom protection rules.

Fail-closed gedrag weegt zwaarder dan de UI eromheen. Als de scan niet draaide, moet de gate blokkeren. Als de SBOM ontbreekt, blokkeren. Als de reviewer de code goedkeurde maar het deploy-artifact uit een andere commit komt, blokkeren. Als de evidence-store plat ligt, blokkeren en zeggen waarom. Mensen mopperen daarover tot de eerste foute vrijdagdeploy. Daarna wordt het mopperbudget kleiner.

NIST SSDF wijst dezelfde kant op: security-eisen vastleggen, het buildpad beschermen en provenance-data verzamelen. Daar heb je geen governance-kostuum voor nodig. Je hebt bewijs nodig dat bij het werk blijft.

De beste gate voelt streng op de juiste plek en stil op de rest. Reviewers verspillen minder tijd. Releasebesluiten worden korter. Auditvragen veranderen niet meer in archeologie. Je doet het werk, hangt het bewijs eraan, en de gate gaat open of niet.