Er is een faalmodus die geautomatiseerde reviewers vernietigt, en dat is niet het missen van een echt probleem. Het is het markeren van een vals probleem. De eerste keer dat een tool een engineer vertelt dat hun wijziging niet-compliant is en dat onjuist blijkt, verliest de engineer een paar minuten. De tweede keer begint hij de tool te wantrouwen. Bij de vijfde keer negeert hij de opmerkingen zonder ze te lezen, inclusief die ene die wel klopte.
Voor een compliance-reviewer is dit het hele spel. Een bot die genegeerd wordt, ziet niets, dus de enige metriek die uiteindelijk telt, is hoe zelden hij onjuist is.
Één valse melding is duurder dan zijn omvang doet vermoeden
Een valse positief kost je niet één genegeerde opmerking. Het kost je de geloofwaardigheid van elke opmerking die erop volgt. Vertrouwen in een geautomatiseerde reviewer is geen optelsom, het is een reputatie, en een reputatie wordt sneller vernietigd dan opgebouwd. Een reviewer die zelfs maar een klein deel van de tijd onjuist is, is niet 'best wel goed'; het is een constante stroom van opmerkingen die je team leert om te negeren.
Daarom kan een compliance-tool recall niet als hoofdgetal behandelen. Meer vangen is waardeloos als het vangen zo luidruchtig is dat mensen het uitschakelen.
Compliance is moeilijker goed te krijgen dan bugs
Een bugmelding is controleerbaar: de reviewer kan vaak zien of de code fout is. Een compliance-melding vraagt de reviewer om iets te vertrouwen wat hij niet direct kan zien: de koppeling tussen deze wijziging en een controlemaatregel in een framework. 'Dit ziet er niet-compliant uit' is niet verifieerbaar en daarom waardeloos; het is het soort vage uitvoer dat mensen leert om de tool te negeren.
De enige manier om een compliance-melding verifieerbaar te maken, is door de exacte controlemaatregel te noemen, op het juiste detailniveau, zodat de engineer de claim kan controleren. Een bevinding die 'ISO 27001:2022 A.8.15' zegt, kan worden opgezocht en bevestigd. Een bevinding die 'verbeterd je compliance-houding' zegt, kan dat niet, en zou nooit moeten worden geleverd.
Hoe wij erover denken
Twee toezeggingen volgen hieruit. Ten eerste: elke bevinding die heygrc aanstipt, noemt de specifieke controleclausule, zodat deze controleerbaar is in plaats van een gevoel. Ten tweede: we hanteren de lat bij precisie, hoe zelden een bevinding onjuist is, in plaats van een ijdele recall-cijfer na te jagen, omdat een compliance-reviewer die vertrouwen opbouwt meer waard is dan een die alles markeert. We geven liever minder aan en hebben gelijk dan meer markeren en genegeerd worden.
Een luidruchtige compliance-reviewer is erger dan geen, omdat geen tenminste je team niet leert om de volgende waarschuwing te negeren. heygrc is gebouwd om stil, specifiek en juist te zijn, en we houden het aan die standaard.