NIS 2 (Richtlijn (EU) 2022/2555) noemt tien cybersecurityrisicobeheermaatregelen in Art. 21(2), en de meeste compliance-beschrijvingen behandelen deze als beleid en proces: een informatiebeveiligingsbeleid, een incidentafhandelingprocedure, een bedrijfscontinuïteitsplan. Dit is accuraat voor het grootste deel van de lijst. Het is onvolledig voor de ene maatregel die wordt bepaald door wat een team daadwerkelijk levert: Art. 21(2)(e), veiligheid bij de aanschaf, ontwikkeling en onderhoud van netwerk- en informatiesystemen, inclusief kwetsbaarheidsbeheer en -openbaarmaking.
Deze handleiding is voor ontwikkelaars wier organisatie onder NIS 2 valt, een essentiële of belangrijke entiteit onder de richtlijn, of een leverancier die aan zo’n entiteit levert, en die willen weten welk deel van die maatregel een pull request-review daadwerkelijk kan detecteren, los van de supply-chain- en cyberhygiëne-maatregelen die de framework-hub al dekt.
Voor wie dit is bedoeld, en de omvangregel
NIS 2 is van toepassing op middelgrote en grote entiteiten volgens de omvangregel (ruwweg 50 of meer medewerkers, of een jaaromzet en een jaarbalanstotaal die beide boven de EUR 10 miljoen liggen) die actief zijn in de sectoren die in Bijlage I en Bijlage II van de richtlijn zijn opgenomen: energie, transport, bankwezen, gezondheidszorg en digitale infrastructuur onder andere in Bijlage I; postdiensten, chemie, voedsel en productie onder andere in Bijlage II. De sector alleen bepaalt niet of een entiteit essentieel of belangrijk is: binnen Bijlage I wordt een grote entiteit die voldoet aan de omvangregel over het algemeen geclassificeerd als 'essentieel' en een middelgrote entiteit over het algemeen als 'belangrijk'; een entiteit uit Bijlage II die voldoet aan de omvangregel wordt over het algemeen geclassificeerd als 'belangrijk', ongeacht of deze middelgroot of groot is, de omvang splitst deze niet verder zoals bij Bijlage I; en een kleinere groep entiteiten (bepaalde aanbieders van digitale infrastructuur, openbaar bestuur en een paar andere speciale categorieën) worden binnen de scope gebracht, en soms als essentieel geclassificeerd, ongeacht de omvang, op naam in plaats van op basis van de omvangregel. Of jouw organisatie, of de klant voor wie je software ontwikkelt, essentieel, belangrijk of buiten de scope valt, is een juridische classificatievraag voor je compliance- of juridische team, niet iets wat een code-review beslist. Als dat gesprek nog niet heeft plaatsgevonden, voer het dan uit voordat je deze handleiding als compliance-programma gebruikt.
Deze handleiding gaat ervan uit dat de classificatievraag al is beantwoord en dat de organisatie binnen de scope valt. Het is geen vervanging voor het risicobeheerraamwerk dat de richtlijn vereist, de incidentafhandeling die Art. 21(2)(b) en de incidentrapportage die Art. 23 vereisen, of de verantwoordelijkheid van het bestuur die Art. 20 toewijst. Het gaat over de ene maatregel uit Art. 21(2) die in een diff kan afbrokkelen.
De maatregel die daadwerkelijk in een diff verschijnt: Art. 21(2)(e)
Twee van de tien maatregelen uit Art. 21(2) hebben al hun eigen 'control-in-code'-pagina’s op deze site: supply chain security (Art. 21(2)(d), een niet-gepinde of niet-geverifieerde afhankelijkheid) en basis cyberhygiëne (Art. 21(2)(g), een bekende kwetsbaarheid die niet is gepatcht). Punt (e), veiligheid bij de aanschaf, ontwikkeling en onderhoud van netwerk- en informatiesystemen, is een ander aspect: het gaat over hoe software wordt gebouwd en hoe kwetsbaarheden daarin worden gevonden en openbaar gemaakt, niet over welke afhankelijkheden je gebruikt of welke patches je achteraf toepast.
In de praktijk komt dit neer op twee engineeringgewoonten. Ten eerste, de beveiligingstests die een ontwikkelproces uitvoert voordat een wijziging wordt geleverd: een statische-analysepoort, een vereiste beveiligingsreviewstap, een afhankelijkheids- of fuzz-check die moet slagen. Ten tweede, een werkend kwetsbaarheidsopenbaarmakingstraject voor de software zodra deze draait: een beveiligingscontact, een gepubliceerde intakemogelijkheid voor een externe melding, een route voor iemand die een lek vindt om dit aan je te melden. Beide kunnen in één pull request afbrokkelen: een poort wordt uitgeschakeld om een release te ontblokkeren, of een nieuwe extern bereikbare interface wordt geleverd zonder een openbaarmakingstraject.
Uitgewerkt voorbeeld: de poort die is uitgeschakeld om een deadline te halen
Een team staat onder deadlinedruk om een nieuw publiek API-eindpunt te leveren, het eerste klantgerichte oppervlak van het bedrijf dat bereikbaar is vanaf het open internet. De pull request die het eindpunt toevoegt, bevat ook een niet-gerelateerde wijziging van één regel: de vereiste statische-analysebeveiligingspoort van de repository, die normaal gesproken moet slagen voordat er wordt gemerged, wordt gemarkeerd als niet-blokkerend met een opmerking die verwijst naar een opvolgtaak. Het eindpunt zelf is goed gebouwd, met inputvalidatie en authenticatiecontroles die een menselijke review doorstaan. De opvolgtaak waarnaar in de opmerking wordt verwezen, bestaat niet, en niets in de PR herstelt de poort naar blokkerend zodra de release is geleverd. Afzonderlijk heeft het bedrijf geen beveiligingscontact, `security.txt` of gepubliceerde intakemogelijkheid voor kwetsbaarheidsmeldingen: interne tools waren tot nu toe de enige blootgestelde zaken, dus had niemand er een nodig.
Als deze PR alleen als functie wordt beoordeeld, is deze prima: het eindpunt werkt, de tests slagen, de deadline wordt gehaald. Als deze wordt beoordeeld tegen Art. 21(2)(e), is het twee dingen tegelijk. Het verzwakt de beveiligingstests die het ontwikkelproces zou moeten uitvoeren voordat code wordt geleverd, zonder een gescope uitzondering of herstelpad, wat precies het aanschaf- en ontwikkeldeel van de maatregel is. En het is het moment waarop het ontbrekende kwetsbaarheidsopenbaarmakingstraject van het bedrijf ophoudt een papieren gat te zijn en een echt gat wordt: er is nu een live, extern bereikbaar oppervlak en geen route voor iemand die een lek vindt om dit aan het bedrijf te melden, wat het openbaarmakingsdeel is. Geen van beide problemen gaat over de vraag of de code van het eindpunt correct is. Beide gaan over de vraag of het proces en de organisatie nog voldoen aan de maatregel die ervan uitging dat de poort aan bleef en ergens een openbaarmakingstraject bestond.
Een bevinding die Art. 21(2)(e) citeert, beslist niet of de poort om een goede reden had moeten worden uitgeschakeld, het openbaarmakingsbeleid opstelt of de beveiligingstest zelf uitvoert. Het maakt de wijziging zichtbaar terwijl de PR nog open is, zodat de auteur of een reviewer de poort kan herstellen met een echte, bijgehouden uitzondering, en kan aangeven dat de organisatie een meldingskanaal nodig heeft voordat dit eindpunt de voordeur wordt voor een melding die nergens terechtkan. Als er al een openbaarmakingstraject bestond op organisatieniveau, zou dit tweede deel niet van toepassing zijn: het gat is alleen echt als er geen bestaat.
Waar je op moet letten bij een review zonder NIS 2-jurist te worden
Wanneer een pull request de CI-configuratie aanpast, vraag dan of deze een vereiste beveiligingsteststap uitschakelt, verzwakt of omzeilt, en zo ja, of dezelfde PR (of een gekoppelde) documenteren waarom en wanneer deze terugkeert. Een poort die is uitgeschakeld zonder herstelpad is de Art. 21(2)(e)-indicator. Wanneer een pull request een nieuw extern bereikbaar eindpunt, service of integratie toevoegt, vraag dan of er al een kwetsbaarheidsopenbaarmakingstraject voor bestaat op organisatieniveau; als dit het geval is, erft het nieuwe oppervlak dit en is niets verder nodig, als dit niet het geval is, is dat een gat dat het waard is om te melden, ook al is het een eenmalige organisatorische oplossing in plaats van een per-PR-oplossing.
Dit is een smallere vraag dan de volledige maatregel. Het dekt niet of je ontwikkellevenscyclusdocumentatie compleet is of of je kwetsbaarheidsafhandelingsproces voldoet aan elk element dat de richtlijn beschrijft; dat zijn procesvragen voor degene die verantwoordelijk is voor je NIS 2-programma. Het dekt de twee plekken waar een pull request stilletjes werk kan ongedaan maken dat dat programma al had gedaan.
Waar heygrc past, en de eerlijkheidsgrens
heygrc is gebouwd om elke pull request te beoordelen aan de hand van de frameworks die je hebt geselecteerd, inclusief NIS 2 als deze is ingeschakeld, en om het punt te benoemen waar een wijziging schijnbaar raakt, bijvoorbeeld Art. 21(2)(e) bij een uitgeschakelde beveiligingspoort of een nieuw eindpunt zonder zichtbaar openbaarmakingstraject, Art. 21(2)(d) bij een niet-gepinde afhankelijkheid, Art. 21(2)(g) bij een achtergehouden patch. De bevinding is een reviewopmerking met de clausule eraan gekoppeld, zodat de auteur en reviewer met volledige informatie kunnen beslissen. Het certificeert geen NIS 2-compliance, schrijft geen kwetsbaarheidsopenbaarmakingsbeleid, voert geen beveiligingstests uit, classificeert geen entiteit of diend de incidentrapporten in die Art. 23 vereist. Die blijven menselijke en organisatorische verplichtingen.
Als je team al een SAST- of codekwaliteitstool op dezelfde pull request uitvoert, houd deze dan aan. Dat gereedschap vraagt of de code zelf correct en veilig is. Art. 21(2)(e) vraagt of het proces rond de code, de poort die had moeten draaien en het pad dat iemand gebruikt om een lek te melden, nog standhoudt. Het hierboven genoemde eindpunt kan alle kwaliteitscontroles doorstaan en toch de maatregel dunner maken dan deze was. Voer beide lagen uit; geen van beide vervangt de andere.