Engineers die voor het eerst ISO 27001 tegenkomen, stellen zich vaak een grote code-audit voor, of een certificaat dat je behaalt zoals een testsuite. Het is geen van beide. ISO/IEC 27001:2022 is een standaard voor beheersystemen. Je bouwt een informatiebeveiligingsmanagementsysteem (beleid, risicobeheer, rollen, leveranciers, incidenten, en het rest). Een geaccrediteerd certificeringsorgaan audit dat systeem en, als het voldoet, geeft het een certificaat. De GitHub-repository is niet het ding dat gecertificeerd wordt.
Deze pagina gaat over het kleine deel dat wel in de repo zit: de technologische controles van bijlage A die een pull request stilzwijgend kunnen verzwakken. Het is de ISO 27001 broer van de SOC 2 en HIPAA "wat het eigenlijk controleert" gidsen. Het is niet de catalogus van controles (dat is de framework hub), en het is niet de "is er een GitHub App" vraag (dat heeft zijn eigen antwoord).
Het certificaat is geen repo-scan
Een SOC 2 Type II-rapport is een onafhankelijk advies van een accountantsfirma over of uw controles, zoals u die beschrijft, passend waren ontworpen en effectief hebben gefunctioneerd over een bepaalde periode. Een Type I-rapport gaat alleen over de ontwerp van een bepaald moment. Een geaccrediteerd ISO 27001-certificaat is anders: een geaccrediteerd certificeringsorgaan bevestigt dat uw beheersysteem voldoet aan de norm. Geen van beide is een statische scan van de broncode. Geen van beide wordt uitgegeven door een GitHub App. Als een leverancier suggereert dat het installeren van een reviewer "u ISO 27001 geeft", beschrijven ze een ander product dan de norm.
Bijlage A van ISO/IEC 27001:2022 bevat 93 controles verdeeld over vier thema's (organisatorisch, mensen, fysiek, technologisch). U implementeert niet alle 93 als een codechecklist. De Verklaring van Toepasselijkheid registreert de controles die u nodig achtte, waarom ze zijn opgenomen, of ze zijn geïmplementeerd en waarom een bepaalde Bijlage A-controle is uitgesloten. Bijlage A is een referentie set waar u die beslissingen tegen kunt controleren, geen menu van 93 items om als code te implementeren. De meeste van de 93 verschijnen nooit in een diff: leverancierscontracten, fysieke kantoren, HR-screening, risicobehandeling documentatie. Het behandelen van de 93 als een repo-audit is de verkeerde graad.
De bijlage A slice die in code leeft
Het technologische thema (A.8) heeft 34 controles. Zelfs daar, alleen een handvol verschijnen regelmatig in een pull request: logboeken (A.8.15), monitoring (A.8.16), cryptografie en sleutelbeheer (A.8.24), toegang beperken (A.8.3), authenticatieversterking (A.8.5), configuratie die overeenkomt met een baseline (A.8.9), veilige codering (A.8.28), wisselbeheer (A.8.32), en informatie back-up (A.8.13). Als je kunt redeneren over wie wat kan bereiken, hoe ze zich identificeren, wat wordt gelogd, hoe geheimen worden bewaard, en of een verandering nog steeds door het proces is gegaan dat je hebt beschreven, redener je over de meeste codegerichte oppervlakte.
De rest van A.8 (netwerken, capaciteit, malware, klokken, enzo) is echt, maar het wordt meestal beslist in architectuur en beheer, niet in een twee-regel applicatie PR. De framework hub lijst de triggers. Deze pagina is het mentale model: ISO 27001 in een repo zijn die A.8 vormen, niet het certificaat en niet de hele bijlage A lijst.
Een bevoorrechte route die stilzwijgend een tweede factor laat vallen
Een supportteam kan geen API-token maken tijdens een incident omdat de adminroute MFA vereist en het on-call-telefoon in een kluis zit. Een pull request verwijdert de tweede-factorcheck en laat de sessiecookie als enige poort staan. Tests blijven groen. De code is korter. Review-opmerkingen gaan over het vrijmaken van het incident. Na de merge kan iedereen die een geldige sessie kan krijgen een bevoorrecht token maken zonder de extra factor die de route vroeger eiste.
ISO 27001:2022 A.8.5 gaat over authenticatieversterking. Een bevoorrechte actie die vroeger een tweede factor vereiste en nu alleen een sessie vereist, is zwakker na de merge. Of dat acceptabel is (een gedocumenteerde, tijdgebonden incidentexceptie versus een permanent gat) is een risicobeslissing voor het team. De taak van de review is om de controle te noemen zodat de beslissing opzettelijk wordt genomen. A.8.3 (toegang beperken) kan ernaast zitten als het token hoe toegang wordt verleend.
De omgekeerde verandering, het terugzetten van requireMfa op de route, of het leiden van incident token-minting via een break-glass pad dat wordt gelogd en vervalt, is goedkoop in de PR. Het achterlaten van de zwakkere route is de duurdere versie: zes maanden later kan een monteur van een certificeringsorgaan vragen hoe bevoorrechte acties worden geauthenticeerd, en de context is verdwenen.
Waar heygrc past, en de eerlijkheidsgrens
heygrc is een GitHub App die elke pull request controleert op basis van de frameworks die je hebt gekozen en de bijlage A controle vermeldt die een verandering raakt, bijvoorbeeld A.8.5 op de MFA-skip hierboven, of A.8.15 wanneer een bevoorrechte actie stopt met gelogd worden. Het certificeert je niet. Het voert je ISMS niet uit. Het schrijft de Verklaring van Toepasbaarheid niet, kiest het certificeringsorgaan niet, of geeft een certificaat. Geen van beide, heygrc of ISMS Copilot, heeft een ISO 27001-certificering. Gebruik het als een reviewer van de verandering, niet als het beheersysteem.
Als de vraag die je eigenlijk hebt getypt was "is er een GitHub App voor ISO 27001", is het korte antwoord ja, en het leeft op zijn eigen pagina. Deze gids is het andere deel: wat die App zou controleren, en waarom de meeste van ISO 27001 nooit in de diff zal verschijnen.