Cyberbeveiligingswet: wat Goooy als leverancier doet

How Goooy supports a customer under the Dutch Cyberbeveiligingswet (NIS2): incident notification, vulnerability handling and a supply-chain statement. In Dutch, because it goes into the gemeente’s contract and incident procedure.

Wat de Cbw van een gemeente vraagt

Sinds 15 augustus 2026 is de Cyberbeveiligingswet van kracht en zijn gemeenten essentiële entiteiten. Dat betekent:

• Registratieplicht: registreren in het entiteitenregister van het NCSC.
• Zorgplicht: passende maatregelen voor de netwerk- en informatiesystemen. Voor de overheid is dat de BIO2, inclusief de beveiliging van de toeleveringsketen (zie bio.md).
• Meldplicht: een significant incident zo snel mogelijk en uiterlijk binnen 24 uur na kennisname melden bij het CSIRT (via het NCSC) en de toezichthouder. Volgens NIS2 art. 23 volgen een incidentmelding binnen 72 uur en een eindverslag uiterlijk een maand na de melding.

Een incident bij een leverancier is vaak een incident bij de gemeente. De gemeente kan haar termijnen alleen halen als de leverancier haar sneller informeert. Daarom vraagt de BIO2 (5.20.05, 5.21.04) dat leveranciers transparant zijn over incidenten en kwetsbaarheden.

Wie is hier de leverancier

Of de leverancier zelf onder de Cbw valt, hangt af van wat hij doet en hoe groot hij is: aanbieders van clouddiensten en beheerde ICT-diensten kunnen eronder vallen, een softwaremaker als zodanig niet. Laat dat per leverancier toetsen.

Incidenten

Voor de dienst die Goooy of een partner levert. Een hostingpartij neemt dit over in zijn eigen verwerkersovereenkomst.

Wat telt. Elk beveiligingsincident dat de dienst aan de gemeente raakt: onbevoegde toegang, verlies of lekken van gegevens, verstoring van de beschikbaarheid, een misbruikte kwetsbaarheid, of een incident bij een subverwerker. Of het voor de gemeente significant is, beoordeelt de gemeente; de leverancier meldt ook bij twijfel.

Termijnen, gerekend vanaf het moment dat de leverancier het incident vaststelt:

Buiten kantooruren telt de klok ook. De eerste melding gaat per telefoon en per e-mail naar het incidentcontact van de gemeente (Bijlage 1.6 van de verwerkersovereenkomst).

Inhoud van een melding

Wat de software aanlevert voor het onderzoek

• Het beveiligingslogboek: aanmeldingen (ook mislukte, per protocol), beheer, delen, delegaties, inzage door anderen, exports, geweigerde uitgaande verbindingen, als CSV of JSON-lines en via syslog in de SIEM (audit.md).
• Metrics en alarmregels voor API, mail en achtergrondtaken (operations.md).
• Sessies, app-wachtwoorden en OAuth-tokens van een account in te trekken, MFA te resetten, apparaten op afstand te wissen.

Incidentinformatie wordt minimaal drie jaar bewaard (BIO2 5.28.01).

Kwetsbaarheden

Het beleid voor melders staat in SECURITY.md (coordinated vulnerability disclosure volgens de NCSC-leidraad, BIO2 5.24.08). Samengevat: melden bij security@goooy.nl, reactie binnen 3 werkdagen, beoordeling binnen 10 werkdagen.

Voor klanten en beheerders

Een beveiligingsadvies gaat vóór publicatie naar het beveiligingscontact van elke klant en beheerder, met de getroffen versies, de update, een tijdelijke maatregel als die er is, en of er aanwijzingen van misbruik zijn. Kwetsbaarheden in afhankelijkheden (een nieuwe CVE in een bibliotheek) toetsen we tegen de SBOM; is Goooy geraakt, dan volgt hetzelfde proces.

Elke installatie publiceert zijn eigen /.well-known/security.txt met het contact van de beheerder (SECURITY_CONTACT, SECURITY_POLICY_URL), zodat melders de juiste partij vinden.

Verklaring toeleveringsketen

Voor de risicoanalyse van de gemeente (BIO2 5.21.02 – 5.21.05).

Wat er in Goooy zit

• Afhankelijkheden: npm-pakketten, vastgelegd in package-lock.json. Een SBOM (CycloneDX 1.5, alleen de runtime-onderdelen) per release: npm run sbom. Nieuwe afhankelijkheden worden beoordeeld op onderhoud, licentie en omvang.
• Container-images: gebouwd uit de broncode in deze repository op node:26-alpine (API), nginx:1.30-alpine (web), debian:13-slim (Postfix 3.10), en de officiële images van Dovecot en Rspamd. Images krijgen de commit als tag.
• Desktop-apps: Qt, en voor Writer, Sheets en Slides een aangepaste LibreOffice (MPL-2.0).

Controles

• npm audit op de runtime-afhankelijkheden hoort bij elke release; wat er open staat en waarom, staat in security.md.
• Regressietests over echte protocollen, gedraaid bij elke opgeleverde wijziging (development.md).
• Een bewaking dat de interne SMTP-poort nooit naar buiten openstaat (Helm-controle).

Diensten van derden tijdens gebruik: standaard geen. Wat de beheerder aanzet (AI, push, foutrapportage, een externe TURN-server) staat in Beheer → Compliance → Dataresidentie en Beheer → Privacy (AVG) → Ontvangers; met DATA_RESIDENCY=eu-strict kan niets anders (data-sovereignty.md).

Leveranciers van Goooy zelf: de broncode staat op GitLab.com. Voor de dienst die Goooy levert: de hosting- en back-upaanbieders in Bijlage 1 van de verwerkersovereenkomst. Een wijziging daarin melden we vooraf (BIO2 5.21.04).

Bekende zwakke plekken:

• De images die Goooy zelf bouwt (waaronder Dovecot 2.4.5 en Rspamd 4.2.0) staan op een versie én digest vast. Een deel van de images uit de Helm-chart nog niet: ClamAV (1.4), Postgres en Redis volgen hun major-tag, en de optionele browser- en computercomponenten gebruiken latest (security.md).
• De pipeline ondertekent de images met cosign en voegt de SBOM toe als attestatie, maar alleen als de CI-variabelen COSIGN_PRIVATE_KEY en COSIGN_PASSWORD zijn gezet; zonder sleutel worden de images ongetekend gepusht. Controleer vóór het uitrollen met cosign verify of de ondertekening er is. Er is geen SLSA-herkomst.
• De GitLab-pipeline (.gitlab-ci.yml) draait typecheck, unittests, de build, de chart, npm audit, de SBOM, de smoke-suites en Playwright. Wat niet in de pipeline zit, is een verplichte goedkeuring door een tweede persoon (zie hieronder).
• Eén hoofdontwikkelaar, zonder tweede reviewer (standard-for-public-code.md). De broncode is open, dus een ander kan het werk overnemen; de gemeente hoeft niet op één persoon te vertrouwen om de software te blijven gebruiken.
• Geen onafhankelijke certificering of pentest van de dienst (zie bio.md).

Checklist voor de gemeente

1. Registreer in het entiteitenregister van het NCSC.
2. Neem de termijnen en de inhoud van de incidentmelding hierboven op in de verwerkersovereenkomst of de SLA met wie Goooy voor u host.
3. Zet het incidentcontact en het beveiligingscontact in Bijlage 1.6 van de verwerkersovereenkomst; houd ze actueel.
4. Stuur het beveiligingslogboek naar uw SIEM (AUDIT_SYSLOG_URL) en leg daar de detectieregels vast (5.17.01: ongebruikelijke plekken, pieken in mislukte aanmeldingen).
5. Neem de SBOM en deze verklaring mee in de jaarlijkse leveranciersbeoordeling (BIO2 5.22.01).
6. Verwijs in uw eigen incidentprocedure naar deze pagina (BIO2 5.24.07).