Er zijn twee manieren om een probleem in een pull request aan te geven. De eerste is: 'dit ziet eruit alsof het misschien niet compliant is.' De tweede is: 'dit verwijdert het auditlogboek voor een bevoorrechte actie, wat ISO 27001 A.8.15 van je verwacht om te behouden.' De eerste is ruis. De tweede is iets waar een engineer op kan reageren of tegenin kan gaan. Het verschil is de clausule.
Het exacte clausule citeren is de kern van hoe heygrc een bevinding rapporteert, en het is ook een beperking die we accepteren: als we de clausule niet kunnen noemen, zeggen we liever niets. Hier is waarom.
De vage bevinding is erger dan niets
Een bevinding zonder clausule geeft de lezer het werk dat het zelf had moeten doen. Is dit echt? Welke regel? Waar moet ik dit zelfs controleren? De eerste keer zoeken ze het op. Na een paar bevindingen die niets blijken te zijn, stoppen ze met het lezen van de bevindingen, inclusief de juiste. Een compliance-reviewer die 'wolf' roept, krijgt geen tweede kans, maar wordt genegeerd.
De schaarse bron is niet de dekking. Het is vertrouwen, en een vage bevinding besteedt het.
Een citatie is een falsifieerbare bewering
Het noemen van de exacte clausule verandert een gevoel in een bewering die je kunt controleren. Het vertelt de lezer welke controle, op een niveau dat ze kunnen verifiëren, en nodigt hen uit om het oneens te zijn. Dat is de functie, geen bijwerking: een bevinding die je kunt weerleggen is een bevinding die je kunt vertrouwen als deze standhoudt.
async function runExport(userId, rows) {- await audit.log("data.export", { userId, count: rows.length }) return write(rows)}Niet 'dit ziet er niet-compliant uit'. De specifieke bewering: dit verwijdert de registratie van een bulkdata-export, het soort gebeurtenis dat A.8.15 van je verwacht om te loggen. Je kunt A.8.15 openen, naar de diff kijken en zelf beslissen of de bewering klopt. Dat is het doel.
Het juiste detailniveau is het moeilijkste deel
De clausule moet op het juiste detailniveau staan. 'Dit raakt ISO 27001' is bijna net zo nutteloos als stilte; 'dit verwijdert de logging die A.8.15 vraagt' is actiegericht. Om daar te komen, moet je de daadwerkelijke wijziging, het gedrag dat in de diff is veranderd, koppelen aan de specifieke controle die het reguleert. Niet het kader, niet de controlegroep, de clausule.
Het grootste deel van de moeilijkheid bij het bouwen van een compliance-reviewer zit hier. Opmerken dat er iets is veranderd is het makkelijke deel. Het exact benoemen van welke controle het heeft veranderd, correct, is het werk.
Als we niet kunnen citeren, blijven we stil
Dit is de afweging die we maken, vooral in het begin: precisie boven herinnering. Als we een wijziging niet kunnen koppelen aan een specifieke clausule waar we zeker van zijn, geven we geen zachtere, vagere waarschuwing af om veilig te zijn. Een onjuiste of niet-verifieerbare bevinding kost meer vertrouwen dan een gemiste, en vertrouwen is wat ervoor zorgt dat de juiste bevindingen überhaupt worden geaccepteerd.
Stilte is een functie als het alternatief ruis is. Een reviewer verdient het recht om geloofd te worden door stil te blijven als het niet zeker is.
Het is nog belangrijker als de lezer een agent is
Als een codeeragent de bevinding leest, is een niet-controleerbare 'dit ziet er niet-compliant uit' nog erger: de agent kan er niet over nadenken of erop reageren, dus negeert het of gokt. Een bevinding die de controle en de clausule noemt, is iets wat zowel een mens als een agent kunnen gebruiken: de controle opzoeken, zien wat deze verwacht, beslissen. De citatie is de interface.
De lat is eenvoudig te formuleren en moeilijk vol te houden: elke bevinding noemt de clausule, of er is geen bevinding. De eerlijke maatstaf of we dit volhouden is de detailnauwkeurigheid van onze citaties op echte diffs, iets wat we zullen rapporteren uit onze eigen evals als we die hebben uitgevoerd, met cijfers of helemaal niet.