Secure by design is het principe waarbij informatiebeveiliging niet achteraf als laag over software wordt gelegd, maar structureel wordt ingebouwd tijdens het ontwerp en de architectuur van een systeem. Voor Europese organisaties in gereguleerde sectoren, zoals overheid, juridische dienstverlening en financiën, is dit principe onlosmakelijk verbonden met een tweede vereiste: aantoonbare auditbaarheid van de broncode. Alleen wie de code kan inspecteren, kan het beveiligingsniveau onafhankelijk verifiëren.
Wat secure by design werkelijk inhoudt
Secure by design gaat verder dan het gebruik van sterke encryptie of het tijdig installeren van patches. Het betekent dat kwetsbaarheidklassen worden geëlimineerd op architectuurniveau, dat de standaardinstellingen van een product direct veilig zijn voor gebruik, en dat de ontwikkelaar aantoonbaar verantwoordelijkheid neemt voor de beveiligingsresultaten bij eindgebruikers.
De CISA, samen met de FBI, NSA en internationale partners waaronder het Nederlandse NCSC, publiceerde in 2023 gezamenlijke richtlijnen die dit principe scherp formuleren:
“Software manufacturers should take ownership of the security outcomes for their customers by building products that are secure by default, eliminating entire classes of vulnerability, and being transparent about their security practices.”
CISA, FBI, NSA en internationale partners, CISA Secure by Design Guidance (2023)
De CISA Secure by Design-richtlijnen maken expliciet onderscheid tussen drie kernverplichtingen voor softwareleveranciers: technische hardening, transparantie over kwetsbaarheden, en verantwoordelijkheid voor de gehele levenscyclus van het product. Voor IT-beslissers is dit relevant omdat het de bewijslast verschuift: niet de afnemer, maar de leverancier moet aantonen dat een product veilig is.
Open-source versus proprietaire werkpleksoftware: een ander beveiligingsprofiel
Open-source platforms als Nextcloud en OnlyOffice hebben een fundamenteel ander beveiligingsprofiel dan proprietaire suites zoals Microsoft 365, niet per definitie beter of slechter, maar anders verifieerbaar.
Bij Microsoft 365 is de broncode gesloten. Beveiligingsbeoordelingen zijn afhankelijk van het vertrouwen in de leverancier, externe pentestrapportages en het Microsoft Security Response Center. Een Europese compliance-officer kan niet zelfstandig nagaan of een specifieke module voldoet aan de eisen van artikel 32 van de AVG (passende technische maatregelen). Bij Nextcloud is de volledige broncode publiek beschikbaar op GitHub. Onafhankelijke partijen, van universiteiten tot beveiligingsbedrijven, hebben de code geauditeerd en hun bevindingen openbaar gemaakt.
Dit heeft praktische implicaties. Wanneer een kritieke kwetsbaarheid wordt ontdekt in een open-source component, is de CVE direct koppelbaar aan de specifieke module, versie en mitigatiemaatregel. Bij proprietaire software is men afhankelijk van de communicatie van de leverancier over timing en omvang van het probleem.
| Criterium | Nextcloud / OnlyOffice (open-source) | Microsoft 365 (proprietair) |
|---|---|---|
| Broncode-inspectie | Volledig publiek en auditeerbaar | Niet beschikbaar voor afnemers |
| SBOM beschikbaarheid | Leverbaar via open-source tooling (bijv. Syft, CycloneDX) | Beperkt, via Microsoft Defender-ecosysteem |
| Jurisdictierisico | Afhankelijk van hostingkeuze (on-premise of Zwitserse cloud) | Blootstelling aan CLOUD Act en Patriot Act |
| Patch-controle | Organisatie bepaalt timing en scope | Microsoft bepaalt uitroltijdstip |
| Audittrail voor toezichthouders | Volledig inzichtelijk | Beperkt tot wat Microsoft beschikbaar stelt |
Een statistisch relevant gegeven: volgens het Synopsys Open Source Security and Risk Analysis Report 2023 bevat 84% van de onderzochte codebases minstens één kwetsbaarheid in directe open-source afhankelijkheden. Dit is geen argument tegen open-source, maar een argument voor structurele SBOM-monitoring, ook bij open-source platforms.
De Cyber Resilience Act: van principe naar wettelijke verplichting
De Cyber Resilience Act (CRA), aangenomen door het Europees Parlement in maart 2024 en gepubliceerd in het Publicatieblad van de EU, vertaalt secure by design van principe naar juridische verplichting voor fabrikanten van producten met digitale elementen.
Voormalig Eurocommissaris Thierry Breton formuleerde bij de presentatie van de CRA de kern van de verplichting:
“Fabrikanten zijn verplicht om veiligheidsupdates te leveren en kwetsbaarheden actief te melden; de tijd van ‘security as an afterthought’ is voorbij.”
Thierry Breton, Europese Commissie
De CRA stelt de volgende verplichtingen centraal voor softwareleveranciers:
- Het product moet voldoen aan essentiële cybersecurityvereisten bij het in de handel brengen.
- Actief uitgebuite kwetsbaarheden moeten binnen 24 uur worden gemeld aan ENISA.
- Er moet een Software Bill of Materials (SBOM) beschikbaar zijn.
- Beveiligingsupdates moeten worden geleverd gedurende de verwachte levensduur, minimaal vijf jaar.
- De standaardconfiguratie van het product moet veilig zijn zonder extra handelingen van de gebruiker.
De Europese Commissie schatte in haar impact assessment (SWD(2022) 282) dat de CRA van toepassing zal zijn op circa 90.000 productcategorieën in de EU. Voor leveranciers als Nextcloud, die een commercieel ecosysteem bouwen rondom open-source software, gelden deze verplichtingen onverkort wanneer zij als fabrikant optreden.
Een code-auditprocedure inrichten voor gereguleerde sectoren
Organisaties in sectoren die vallen onder NIS-2 (Richtlijn (EU) 2022/2555) of de AVG zijn verplicht passende technische maatregelen te treffen. Een gestructureerde code-auditprocedure is een concrete invulling van die verplichting voor kritieke softwarecomponenten.
Een werkbare procedure kent vier fasen. Ten eerste: scopebepaling. Niet alle software hoeft even diep geauditeerd te worden. Kritische systemen, zoals de samenwerkingsomgeving, documentopslag en authenticatielaag, krijgen prioriteit op basis van risicoklasse.
Ten tweede: leveranciersverificatie. Vraag de leverancier om het audithistoricum, de CVE-afhandelingsprocedure en de SBOM. Voor open-source software is dit grotendeels publiek beschikbaar. Controleer via het National Vulnerability Database (NVD) of bekende kwetsbaarheden tijdig zijn gepatcht.
Ten derde: onafhankelijke technische review. Laat minimaal eens per twee jaar een externe partij, gecertificeerd conform ISO 27001 of met aantoonbare expertise in penetratietesten, een gerichte beoordeling uitvoeren van de configuratie en kritieke modules.
Ten vierde: continu SBOM-monitoring. Koppel de SBOM aan een kwetsbaarhedenscanner zoals Dependency-Track of Grype, zodat nieuwe CVE’s automatisch worden gesignaleerd zonder te wachten op de volgende periodieke audit.
De rol van SBOM in soevereine werkplekbeslissingen
Een Software Bill of Materials is een machineleesbare inventaris van alle softwarecomponenten in een product, inclusief versienummers, licenties en herkomst. Formats als CycloneDX en SPDX zijn hiervoor gestandaardiseerd en worden ondersteund door tooling in het open-source ecosysteem.
Voor compliance-officers heeft een SBOM directe waarde bij drie vraagstukken. Ten eerste maakt het een risicoanalyse mogelijk: welke componenten hebben een niet-EU-herkomst en vallen daardoor mogelijk onder exportcontrole of buitenlandse rechtsmacht? Ten tweede maakt het responsplanning mogelijk: bij een zero-day in een veelgebruikte bibliotheek zoals OpenSSL kan de organisatie binnen uren bepalen of en waar zij geraakt wordt. Ten derde ondersteunt het aanbestedingsprocedures: leveranciers die geen SBOM kunnen aanleveren, voldoen straks niet aan de verplichtingen van de Cyber Resilience Act en zijn daarmee een juridisch risico voor de afnemer.
ENISA beveelt in haar richtsnoeren voor supply chain security aan dat overheidsorganisaties SBOM-levering als contractuele eis opnemen bij softwareinkoop. Dit sluit aan op de NIS-2-verplichting voor essentiële entiteiten om risico’s in de toeleveringsketen te beheersen (artikel 21, lid 2, sub d).
Volgens het ENISA Threat Landscape 2023 is meer dan 60% van alle cyberaanvallen waarbij een aanvaller toegang verkreeg, terug te voeren op software met bekende maar ongepatchte kwetsbaarheden. SBOM-monitoring is de meest directe technische maatregel om die kwetsbaarheidsklasse structureel te verkleinen.
Secure by design in aanbestedingscriteria en EUCS-certificering
Voor overheidsorganisaties en gereguleerde sectoren die kantoorapplicaties aanbesteden, is secure by design inmiddels een weegbaar criterium geworden, niet alleen een wens. Het EU Cybersecurity Certification Scheme for Cloud Services (EUCS), ontwikkeld door ENISA op basis van artikel 54 van de EU Cybersecurity Act (Verordening (EU) 2019/881), kent drie assuranceniveaus: Basic, Substantial en High.
Niveau High stelt de zwaarste eisen, waaronder aantoonbare onafhankelijkheid van niet-EU-rechtsmacht, verificatie van beveiligingscontroles door geaccrediteerde conformiteitsbeoordelingsinstanties, en eisen aan de operationele locatie van de cloudinfrastructuur. Voor de verwerking van bijzondere persoonsgegevens of informatie die onder de Besluit Voorschrift Informatiebeveiliging Rijksdienst (BIR) valt, is niveau High doorgaans het minimumvereiste.
In aanbestedingsdocumentatie kan secure by design worden geoperationaliseerd via een set van toetsbare gunningscriteria. Denk aan: beschikbaarheid van een actuele SBOM, aantoonbaar gestructureerde kwetsbaarheidsopenbaarmaking (coordinated vulnerability disclosure conform ISO 29147), de aanwezigheid van een externe penetratietestrapportage van minder dan twaalf maanden oud, en naleving van de CRA-vereisten of een gelijkwaardig certificeringsschema.
Nextcloud heeft als open-source platform een auditeerbare basis die deze criteria ondersteunt. Organisaties die overwegen te migreren van Microsoft 365 naar een soevereine werkplek, kunnen de EUCS-vereisten als leidraad gebruiken voor de selectie van zowel het softwareplatform als de hostingpartner. Een Zwitserse of Europese hostingpartner die buiten de reikwijdte van de US CLOUD Act opereert, gecombineerd met open-source software waarvan de broncode aantoonbaar geauditeerd is, vormt daarmee een verdedigbaar en toetsbaar kader voor toezichthouders.
FAQ
Wat is het verschil tussen secure by design en security by default?
Secure by design betekent dat beveiliging al tijdens de architectuur- en ontwerpfase structureel is ingebakken in de software. Security by default houdt in dat een product uit de doos de veiligste configuratie heeft ingeschakeld, zonder dat gebruikers handmatig instellingen hoeven te wijzigen. Beide concepten vullen elkaar aan en zijn verankerd in de CISA-richtlijnen en de Cyber Resilience Act.
Waarom is auditbaarheid van broncode essentieel voor soevereine organisaties?
Zonder toegang tot de broncode kan een organisatie niet zelfstandig verifiëren of een product doet wat de leverancier belooft, of er achterdeurtjes zijn, of onveilige bibliotheken worden gebruikt. Bij proprietaire software moet men vertrouwen op de leverancier. Open-source software stelt organisaties en onafhankelijke partijen in staat de code te inspecteren, te auditen en te valideren.
Wat verplicht de Cyber Resilience Act concreet voor een leverancier als Nextcloud?
De Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen tot het leveren van beveiligingsupdates gedurende de verwachte levensduur, het opstellen en beschikbaar stellen van een SBOM, het melden van actief uitgebuite kwetsbaarheden bij ENISA binnen 24 uur, en het aantonen dat het product voldoet aan essentiële cybersecurityvereisten. Voor open-source projecten met commerciële stewards gelden deze verplichtingen onverkort.
Hoe verhoudt een SBOM zich tot een klassieke leveranciersaudit?
Een SBOM is een machineleesbare inventaris van alle softwarecomponenten en hun versies in een product, vergelijkbaar met een ingrediëntenlijst. Een klassieke leveranciersaudit beoordeelt processen en organisatie. Een SBOM vult die audit aan door automatisch en continu inzicht te geven in kwetsbare componenten, zodat organisaties snel kunnen reageren op nieuw gepubliceerde CVE’s zonder te wachten op een periodieke audit.
Welk EUCS-niveau is vereist voor gevoelige overheidsdata in de cloud?
Het EU Cybersecurity Certification Scheme for Cloud Services kent drie niveaus: Basic, Substantial en High. Voor verwerking van geclassificeerde of gevoelige overheidsdata wordt doorgaans niveau High vereist, waarbij eisen worden gesteld aan operationele locatie, jurisdictie van de aanbieder en immuniteit voor niet-EU-rechtsmacht. Het schema was bij publicatie van dit artikel nog in finalisatiefase bij ENISA.
