De audit is waar je erachter komt. De pull request is waar het gebeurde. Ergens tussen die twee momenten, vaak maanden uit elkaar, stopte een controle die een auditor zal steekproefsgewijs controleren met werken, en niemand merkte het op, omdat de wijziging die het doorbrak niet op een compliance-wijziging leek. Het leek op een opschoning.
Dit is de vorm ervan. De controle is ISO 27001:2022 A.8.15, logging. De wijziging is één verwijderde regel.
De wijziging
Een pull request ruimt een functie op die de rol van een gebruiker bijwerkt. Er zit een log-oproep in het midden die de auteur als ruis ziet, deze wordt bij elke rolwijziging geactiveerd en vervuilt de uitvoer, dus deze wordt verwijderd. De functie werkt nog steeds. De tests slagen nog steeds. Het diff is één regel korter en, als er al iets is, schoner.
async function updateRole(actor, target, role) { await db.roles.set(target, role)- await audit.log("role.update", { actor, target, role }) return ok()}Die regel was het auditlogboek voor een wijziging in toegangrechten. A.8.15 (logging) verwacht dat beveiligingsrelevante gebeurtenissen, inclusief wijzigingen in privileges, worden geregistreerd en bewaard, en A.8.16 (monitoring) is afhankelijk van het bestaan van dat logboek. Door het te verwijderen, verdwijnt het enige bewijs dat een rol ooit is gewijzigd.
Waarom niemand het opmerkte
Een reviewer die naar dit diff kijkt, ziet een verwijderde logregel. Om het probleem op te merken, zou deze moeten weten dat deze specifieke log het bewijs is voor een controle, dat de controle A.8.15 is, en dat A.8.15 binnen de scope valt van hun certificering. Dat zijn drie stukken frameworkkennis die een code reviewer niet in zijn hoofd heeft tijdens het goedkeuren van een routine refactor.
Dit is de leemte. De controlepost staat op de juiste plek, code review bekijkt al elke wijziging, met opzet, voordat deze wordt geïmplementeerd. Wat ontbreekt, is het frameworkbewustzijn om te herkennen dat een ogenschijnlijk gewone regel draagkrachtig is voor een audit.
Wat het later kost
Hier opgemerkt, is dit een éénregelige terugdraaiing en een gesprek van dertig seconden. De auteur heeft de hele wijziging nog in zijn hoofd. In de audit opgemerkt, is het een uitzondering: de controle functioneerde niet gedurende de periode, en nu moet iemand achterhalen wanneer de logging stopte, wat ervan afhing en hoe deze veilig kan worden hersteld, onder tijdsdruk, mogelijk nadat de auteur is vertrokken.
De kosten van een compliance-leemte worden bepaald door één ding: hoe lang deze onopgemerkt bleef. De pull request is de goedkoopste plek om het op te merken.
De kern
Compliance faalt in een pull request van vijf regels, niet in de audit. De audit is een achterlopende indicator van een beslissing die iemand weken eerder in een diff heeft genomen. heygrc is gebouwd om dat diff te lezen tegenover de frameworks die je moet halen en de controle te benoemen die een wijziging raakt, A.8.15, in de pull request, terwijl de oplossing nog goedkoop is.