Veelgestelde vragen

Antwoorden op veelgestelde vragen over soevereiniteit, open source, Stichting LibreKAT, MIAUW, OpenKAT en OciDeck.

Stichting LibreKAT 13 vragen

Stichting LibreKAT werkt aan open, controleerbare en verifieerbare informatiebeveiliging. De stichting ondersteunt projecten, kennisdeling en samenwerking rond digitale veiligheid.

Het gaat daarbij niet alleen om software. LibreKAT wil ook bijdragen aan betere werkwijzen, meer transparantie en een gemeenschap waarin mensen samen digitale veiligheid kunnen verbeteren.

Lees meer op Over Stichting LibreKAT.

Digitale veiligheid is te belangrijk om volledig afhankelijk te zijn van gesloten systemen, oncontroleerbare processen of losse beloftes. Organisaties moeten kunnen begrijpen, controleren en verbeteren hoe hun beveiliging werkt.

LibreKAT bestaat om dat te bevorderen. De stichting stimuleert open technologie, kennisdeling en samenwerking tussen mensen die digitale weerbaarheid willen vergroten.

Lees ook Wat zijn de doelen van Stichting LibreKAT? en Over Stichting LibreKAT.

Nee. LibreKAT is een stichting en heeft geen winstdoel. De stichting kan wel samenwerken met bedrijven, overheden, onderzoekers, vrijwilligers en maatschappelijke organisaties.

Bij samenwerking staat de doelstelling voorop: bijdragen aan open, duurzame en controleerbare digitale veiligheid.

Lees meer op Over Stichting LibreKAT.

Libre verwijst naar vrijheid. Niet alleen gratis gebruik, maar vooral de vrijheid om technologie te bestuderen, te controleren, aan te passen en te delen.

Voor informatiebeveiliging is dat belangrijk. Als je wilt vertrouwen op een systeem of methode, moet je kunnen zien hoe die werkt en hoe beslissingen tot stand komen.

Dat sluit aan bij de kernwaarden van Stichting LibreKAT.

Stichting LibreKAT wil digitale veiligheid verbeteren door open, controleerbare en verifieerbare informatiebeveiliging te stimuleren.

Concreet gaat het onder meer om:

  • ontwikkeling en gebruik van open source-software en -hardware voor veilige digitale infrastructuren;
  • transparantie en reproduceerbaarheid in beveiligingsprocessen;
  • onderzoek, trainingen en activiteiten rond digitale weerbaarheid;
  • verbinding tussen burgers, bedrijven, overheid en maatschappelijke organisaties.

Lees meer op Over Stichting LibreKAT en op de homepage van Stichting LibreKAT.

LibreKAT is de stichting. OpenKAT is een open source-product voor kwetsbaarhedenanalyse.

De namen lijken op elkaar, maar betekenen niet hetzelfde. De stichting kan OpenKAT ondersteunen en past OpenKAT bij de missie van LibreKAT, maar OpenKAT is niet de stichting zelf.

Lees meer over Stichting LibreKAT en OpenKAT.

Open source maakt controle mogelijk. Mensen kunnen zien hoe software werkt, fouten vinden, verbeteringen voorstellen en afhankelijkheid van één leverancier verminderen.

Open source is geen automatische garantie op veiligheid. Het is wel een belangrijke voorwaarde voor transparantie, samenwerking en herstelbaarheid.

Lees meer over de uitgangspunten op Over Stichting LibreKAT.

Belangrijke projecten op deze site zijn OpenKAT, MIAUW en OciDeck.

OpenKAT helpt bij het zichtbaar maken van kwetsbaarheden en digitale risico’s. MIAUW helpt om informatiebeveiligingsonderzoek controleerbaar en auditwaardig te maken. OciDeck helpt bij gestructureerde presentaties, rapportages en veilig delen van informatie.

Lees meer over OpenKAT, MIAUW en OciDeck.

LibreKAT is er voor iedereen die digitale veiligheid open, controleerbaar en beter uitlegbaar wil maken.

Denk aan security-professionals, ontwikkelaars, bestuurders, auditors, onderzoekers, overheden, bedrijven, onderwijsinstellingen, maatschappelijke organisaties en betrokken burgers.

Lees meer op Over Stichting LibreKAT.

Ja. Meedoen kan op meerdere manieren: code bijdragen, documentatie verbeteren, testen, vertalen, vragen stellen, ervaringen delen of helpen bij bijeenkomsten en community-activiteiten.

Je hoeft niet alles technisch te weten om waardevol bij te dragen. Goede vragen, praktijkervaring en heldere uitleg zijn ook belangrijk.

Neem contact op via Contact.

Dat kan, als de samenwerking past bij de doelstelling van de stichting. LibreKAT zoekt samenwerking die bijdraagt aan open, duurzame en controleerbare digitale veiligheid.

Voorbeelden zijn kennisdeling, onderzoek, open source-ontwikkeling, documentatie, trainingen of praktijktoepassingen van de projecten.

Zie ook Partners en Contact.

Belangrijke waarden zijn veiligheid, vrijheid, openheid, soevereiniteit, integriteit, kennisdeling, samenwerking, menselijkheid en continuïteit.

In gewone taal: LibreKAT wil dat digitale veiligheid controleerbaar, eerlijk, duurzaam en bruikbaar is voor de mensen en organisaties die ervan afhankelijk zijn.

Lees ook het artikel Over onze kernwaarden.

Gebruik de contactpagina als je een vraag hebt, wilt bijdragen of samenwerking wilt bespreken.

Probeer kort te beschrijven waar je vraag over gaat: stichting, MIAUW, OpenKAT, OciDeck, samenwerking, pers of een technische bijdrage. Dan is sneller duidelijk wie kan reageren.

Soevereiniteit 29 vragen

Nee. Soevereiniteit is geen autarkie en vereist geen volledige onafhankelijkheid. Organisaties en staten zijn altijd afhankelijk van kennis, leveranciers, grondstoffen en samenwerking.

Het doel is dat afhankelijkheden zichtbaar, beheersbaar en waar nodig vervangbaar zijn. Je kunt werk uitbesteden en toch regie houden, zolang verantwoordelijkheden, rechten, toegang, continuïteit en exitmogelijkheden goed zijn geregeld.

Nee. Geen enkel product kan digitale soevereiniteit op zichzelf garanderen. Soevereiniteit ontstaat uit de combinatie van bestuur, contracten, rechtsmacht, architectuur, openheid, kennis, beheer en uitvoerbare alternatieven.

OpenKAT en OciDeck kunnen wel concrete bouwstenen leveren: meer inzicht, controleerbaarheid, open formaten, zelfbeheer en minder onnodige afhankelijkheid. De organisatie moet die mogelijkheden bewust inrichten en blijven toetsen.

Leg per kritisch systeem een nulmeting en een gewenst niveau vast. Meet daarna concrete eigenschappen, zoals het aandeel bekende ketenpartijen, geteste data-export, klantbeheerde sleutels, herstel zonder leverancier, open interfaces en de tijd die nodig is om over te stappen.

Rapporteer ook resterende afhankelijkheden en geaccepteerde risico’s. Vooruitgang betekent niet dat alle afhankelijkheid verdwijnt, maar dat de organisatie meer inzicht, keuzevrijheid en aantoonbare handelingsruimte krijgt.

Stel eisen vóór het contract wordt gesloten. Vraag naar rechtsmacht, eigendom, gegevenslocaties, onderaannemers, beheer op afstand, sleutelbeheer, open standaarden, exportformaten, auditrechten, continuïteit en beëindiging.

Leg ook vast hoe bewijs wordt geleverd en hoe wijzigingen worden gemeld. Een keurmerk of algemene marketingclaim vervangt geen toetsbare afspraak. Gebruik waar passend de doelen en SEAL-niveaus van het ECSF als gemeenschappelijke taal.

Nee. Europese dataopslag is relevant, maar zegt niet alles over rechtsmacht, eigendom, beheer, sleuteltoegang, onderaannemers en technische afhankelijkheid.

Beoordeel daarom de hele structuur: welke entiteiten leveren de dienst, welk recht kan worden ingeroepen, wie kan beheerhandelingen uitvoeren, wie beheert encryptiesleutels en welke exitmogelijkheden bestaan er?

Ja. Afhankelijkheid kan de beschikbaarheid, integriteit en vertrouwelijkheid van informatie raken. Denk aan uitval of beëindiging van een dienst, ongewenste toegang onder een ander rechtsstelsel of wijzigingen die de organisatie niet zelf kan controleren.

Daarom hoort soevereiniteit thuis in regulering, organisatie en techniek: de drie samenhangende onderdelen die in het boek als ROT worden beschreven. Het is geen los politiek thema naast informatiebeveiliging.

Niet wanneer eisen gericht zijn op beheersbare risico’s en voor alle aanbieders gelijk en toetsbaar gelden. Protectionisme beschermt primair de eigen industrie; soevereiniteitsbeleid beschermt regie, continuïteit, integriteit en vertrouwelijkheid.

Nationaliteit alleen is daarom een zwak criterium. Jurisdictie, afdwingbare afspraken, technische isolatie, openheid en exitmogelijkheden zijn inhoudelijker.

Nee. Een Europese naam of vestigingsplaats is geen volledige garantie. Ook een Europese leverancier kan worden overgenomen, failliet gaan, sterk leunen op niet-Europese technologie of slechte contractuele waarborgen bieden.

Kijk naar controleerbare structuurkenmerken: eigendom en zeggenschap, toepasselijk recht, beheer en sleuteltoegang, ketenafhankelijkheden, open standaarden en een uitvoerbaar exitplan.

Nee. Open source geeft belangrijke rechten om software te bestuderen, aan te passen en door anderen te laten onderhouden. Daarmee kan het transparantie, vervangbaarheid en kennisopbouw ondersteunen.

Maar die rechten hebben pas praktische waarde als er documentatie, mensen, beheer, financiering, veilige updates en toegang tot de eigen data zijn. Ook open source kan afhankelijk zijn van één maintainer, een gesloten clouddienst of moeilijk vervangbare infrastructuur.

Nee. Soevereiniteit is contextafhankelijk. Het gewenste niveau volgt uit de kritikaliteit van het proces, de gevoeligheid van gegevens, wettelijke eisen, risicobereidheid en beschikbare alternatieven.

Het hoogste niveau voor alle systemen kan onnodig duur of onhaalbaar zijn. Een gemotiveerde keuze per systeem is sterker dan één algemeen doel zonder prioriteiten.

Niet noodzakelijk. Eisen aan interoperabiliteit, transparantie, veiligheid en vervangbaarheid kunnen innovatie juist stimuleren doordat nieuwe aanbieders makkelijker kunnen aansluiten en afnemers minder opgesloten raken.

Er bestaan wel echte afwegingen rond kosten, snelheid en functionaliteit. Die moeten expliciet worden gemaakt. De tegenstelling ‘innovatie of soevereiniteit’ is te eenvoudig; het gaat om verantwoord innoveren binnen een gekozen risicoprofiel.

Begin met inzicht. Maak een overzicht van kritieke processen, gegevens, systemen, leveranciers, onderaannemers, beheertoegang, toepasselijke rechtsmacht en bestaande exitmogelijkheden.

Koppel daarna de belangrijkste afhankelijkheden aan beschikbaarheid, integriteit en vertrouwelijkheid. Pas als duidelijk is wat kritiek is en waarvan het afhankelijk is, kun je een passend doel en maatregelen kiezen.

Het boek Soevereiniteit! Hoe dan? behandelt de historische ontwikkeling, de relatie met informatiebeveiliging, het ECSF, de argumenten uit het debat en een praktisch groeipad voor organisaties.

De kernboodschap is nuchter: soevereiniteit is geen alles-of-nietsbegrip en geen eenmalig project. Het is het blijvend organiseren van inzicht, regie en handelingsruimte.

Het begrip kreeg vorm in het Europa van de late middeleeuwen en de vroegmoderne tijd. Jean Bodin beschreef in de zestiende eeuw een hoogste, permanente staatsmacht. De Vrede van Westfalen van 1648 verbond soevereiniteit vervolgens sterk aan territoriale staten en het beginsel van niet-inmenging.

Later verschoof de legitimiteit van vorsten naar het volk en gingen staten bevoegdheden gezamenlijk uitoefenen, bijvoorbeeld binnen de Europese Unie. De geschiedenis laat zien dat soevereiniteit steeds draait om dezelfde kernvraag: wie heeft uiteindelijk het laatste woord?

Omdat soevereiniteit niet alleen over waarschijnlijkheid gaat, maar ook over impact en handelingsvermogen. Een gebeurtenis kan weinig waarschijnlijk zijn en toch onaanvaardbare gevolgen hebben voor een kritisch proces.

Bovendien kan afhankelijkheid al invloed hebben zonder dat toegang daadwerkelijk wordt geblokkeerd. De mogelijkheid van sancties, juridische bevelen of beëindiging kan besluitvorming en onderhandelingsruimte veranderen.

Overheden, bedrijven en maatschappelijke organisaties zijn sterk afhankelijk geworden van een klein aantal leveranciers voor cloud, kantoorsoftware, communicatie en AI. Tegelijk kunnen eigendom, wetgeving, sancties, overnames en geopolitieke verhoudingen veranderen.

Daardoor kan formele zeggenschap botsen met feitelijke afhankelijkheid. De urgente vraag is niet alleen of een leverancier vandaag betrouwbaar is, maar of de organisatie morgen nog kan handelen als regels, toegang of belangen veranderen.

Maak onderscheid tussen werkelijk onmisbare functies en afhankelijkheden die door gewenning, ontbrekende kennis of oude keuzes zijn ontstaan. Breng koppelingen, dataformaten, licenties, processen en vaardigheden concreet in kaart.

Oefen vervolgens met export, herstel en alternatieven voordat er een crisis is. Een exitplan dat nooit is getest, biedt weinig zekerheid. Soms is volledige migratie niet direct haalbaar, maar kunnen open formaten, modulaire architectuur en een tweede uitvoeringsroute de positie al verbeteren.

Dan is een gefaseerde aanpak verstandig. Bepaal eerst voor welke processen de afhankelijkheid het grootste risico vormt en welke functies echt nodig zijn. Verbeter daarna contracten, architectuur en portabiliteit, en migreer waar een passend alternatief beschikbaar is.

Dat een alternatief vandaag minder volwassen is, is een argument over tempo en uitvoering, niet automatisch een reden om het risico te negeren. Het boek bespreekt daarom een groeipad in plaats van één grote overstap.

Digitale soevereiniteit is de mate waarin een overheid of organisatie daadwerkelijk regie houdt over haar digitale functies, gegevens en afhankelijkheden. Daarbij tellen formele rechten én feitelijke handelingsmogelijkheden.

Concrete vragen zijn: waar staan de gegevens, wie kan erbij, welk recht geldt, wie beheert de sleutels, kan de dienstverlening doorgaan bij een conflict en is overstappen reëel mogelijk?

Het ECSF is een Europees beoordelingskader voor cloudsoevereiniteit. Het helpt publieke organisaties om soevereiniteitsrisico’s te beschrijven, eisen te stellen bij inkoop en de huidige en gewenste situatie te vergelijken.

Het raamwerk verschuift het gesprek van algemene claims, zoals ‘Europees’ of ‘soeverein’, naar toetsbare eigenschappen. Het kijkt onder meer naar rechtsmacht, data, operatie, ketens, technologie, beveiliging en duurzaamheid.

Soevereiniteit gaat over gezag en regie: wie heeft het laatste woord en draagt verantwoordelijkheid? Autonomie gaat over het praktische vermogen om zelfstandig te handelen en alternatieven te gebruiken.

Een organisatie kan formeel bevoegd zijn, maar weinig autonomie hebben als zij technisch niet kan overstappen of alleen een leverancier het systeem kan beheren. Soevereiniteit zonder voldoende handelingsruimte blijft dan grotendeels op papier bestaan.

Soevereiniteit is het gezag om bindende besluiten te nemen en daarvoor verantwoordelijkheid te dragen. In digitale omgevingen gaat het vooral om de vraag wie uiteindelijk beslist over data, infrastructuur, technologie en toegang.

Het betekent niet dat een organisatie alles zelf moet bouwen of beheren. Wel moet zij bewuste keuzes kunnen maken, afspraken kunnen afdwingen en kunnen handelen wanneer omstandigheden veranderen. Het boek Soevereiniteit! Hoe dan? werkt dit uit als een praktisch bestuurlijk vraagstuk.

SEAL-niveaus beschrijven oplopende niveaus van cloudsoevereiniteit. Niveau 0 is een standaard publieke cloud zonder aanvullende soevereiniteitsmaatregelen; niveau 4 staat voor een vergaand soeverein ingerichte omgeving met aantoonbare autonomie.

De niveaus zijn geen rapportcijfer voor een leverancier. Ze helpen een organisatie om per toepassing een passend huidig niveau (IST) en gewenst niveau (SOLL) vast te leggen. Een kritisch systeem kan dus een hoger doel krijgen dan een openbare of gemakkelijk vervangbare dienst.

Open source kan helpen doordat een organisatie software mag bestuderen, laten controleren, aanpassen en door een andere partij laten onderhouden. Open rechten ondersteunen daarmee transparantie, vervangbaarheid en de opbouw van eigen kennis.

Open source is geen automatische garantie op soevereiniteit. De praktische waarde hangt ook af van documentatie, mensen, beheer, financiering, veilige updates, open dataformaten en de infrastructuur waarop de software draait.

Het ECSF onderscheidt acht samenhangende doelen: strategische soevereiniteit; juridische en rechtsmachtsoevereiniteit; data- en AI-soevereiniteit; operationele soevereiniteit; ketensoevereiniteit; technologische soevereiniteit; beveiligings- en compliancesoevereiniteit; en duurzaamheidssoevereiniteit.

Die indeling voorkomt dat één eigenschap, zoals de locatie van een datacentrum, ten onrechte als bewijs voor volledige soevereiniteit wordt gebruikt. Een dienst kan op het ene doel sterk en op een ander doel zwak scoren.

OciDeck ondersteunt informatie- en technologische soevereiniteit doordat presentatie-inhoud in leesbare Markdown kan blijven staan. Open formaten maken inhoud beter controleerbaar, herbruikbaar en verplaatsbaar dan wanneer zij uitsluitend in een gesloten applicatieformaat zit.

Lokale verwerking, offline HTML-export en gerichte deel- en privacyfuncties kunnen de afhankelijkheid van externe presentatiediensten en onbedoelde verspreiding verminderen. De uiteindelijke soevereiniteit hangt ook af van opslag, beheer en de keuzes van de gebruiker. Lees meer op OciDeck.

OpenKAT helpt vooral bij operationele, technologische en beveiligingssoevereiniteit. Het brengt digitale objecten, relaties, waarnemingen en bevindingen samen, zodat een organisatie haar eigen omgeving en risico’s beter kan begrijpen en volgen.

Omdat OpenKAT open source is en zelf kan worden gedraaid, kan een organisatie de werking laten controleren en kiezen wie het systeem beheert. OpenKAT levert geen volledige soevereiniteit op: zorgvuldig beheer, scope, gegevensbescherming, kennis en opvolging blijven nodig. Lees meer op OpenKAT.

Een bruikbare aanpak is: 1. inventariseer processen, data en afhankelijkheden; 2. bepaal per systeem het gewenste soevereiniteitsniveau; 3. verbeter inkoop, contracten, architectuur, kennis en alternatieven; 4. toets periodiek of de maatregelen nog werken en stuur bij.

Behandel dit als een cyclus. Leveranciers, eigendom, wetgeving en techniek veranderen. Een eenmalige beoordeling veroudert daarom snel.

Het bestuur is eindverantwoordelijk voor richting, risicobereidheid en aanvaarding van restrisico. Inkoop, juridische zaken, informatiebeveiliging, architectuur, privacy, beheer en de proceseigenaar leveren ieder een noodzakelijk deel van het beeld.

Omdat keuzes vaak langdurige gevolgen hebben, noemt het boek soevereiniteit ‘chefsache’. Het onderwerp kan niet uitsluitend bij techniek of contractbeheer worden neergelegd.

Open source 100 vragen

Open source is een licentievorm. De maker of rechthebbende geeft anderen vooraf toestemming om het werk te gebruiken, te bestuderen, te kopiëren, te verspreiden en aan te passen.

Het recht om aanpassingen te maken is essentieel. Als aanpassen niet is toegestaan, is het geen open source.

De kern is juridisch. Open source gaat over de manier waarop auteursrecht wordt uitgeoefend: via een licentie die ruime gebruiksrechten geeft.

Er kunnen technische en maatschappelijke ideeën achter zitten, maar zonder passende licentie is iets niet open source.

Het betekent dat de rechthebbende via een open source licentie toestemming geeft om de broncode te gebruiken, te bestuderen, te kopiëren, te verspreiden en aan te passen.

De software blijft auteursrechtelijk beschermd. De licentie bepaalt welke rechten en voorwaarden gelden.

Open source en free software gaan over rechten: gebruiken, bestuderen, delen en aanpassen. Freeware betekent meestal alleen dat iets gratis te gebruiken is.

Public domain betekent dat er geen auteursrechtelijke beperking meer geldt, of dat de rechthebbende afstand heeft gedaan voor zover dat juridisch kan. Dat is iets anders dan open source.

Nee. Open source geeft veel rechten, maar altijd binnen de voorwaarden van de licentie.

Die voorwaarden kunnen bijvoorbeeld gaan over naamsvermelding, het behouden van licentieteksten of het delen van wijzigingen onder dezelfde licentie.

De maker of rechthebbende blijft eigenaar van het auteursrecht, tenzij dat recht is overgedragen.

Open source betekent dus niet dat er geen eigenaar is. Het betekent dat de eigenaar via een licentie ruime rechten geeft aan anderen.

Ja. Open source sluit commercieel gebruik niet uit. Een bedrijf mag open source gebruiken, diensten rond open source verkopen of zelf open source software aanbieden.

De prijs en het verdienmodel staan los van de open source rechten.

Open source gaat over rechten op een werk, meestal software. Open standaarden gaan over afspraken, specificaties of protocollen die door meerdere partijen gebruikt kunnen worden.

Ze kunnen elkaar versterken, maar het zijn verschillende dingen.

Een open source licentie is vooraf gegeven toestemming van de rechthebbende. Daarin staat wat anderen met het werk mogen doen en welke voorwaarden daarbij horen.

Zonder zo’n licentie blijft het normale auteursrecht gelden en mag hergebruik meestal niet zomaar.

Omdat auteursrecht automatisch ontstaat. Wie een tekst, ontwerp of software maakt, heeft daar in beginsel rechten op.

Een licentie maakt duidelijk welke toestemming anderen krijgen. Bij open source is die toestemming ruim en vooraf geregeld.

Dan is de code wel zichtbaar, maar niet automatisch vrij te gebruiken. Zichtbaarheid is geen toestemming.

Zonder licentie mag een ander de code meestal niet kopiëren, verspreiden of aanpassen, behalve in beperkte wettelijke uitzonderingen.

Permissieve licenties geven veel vrijheid en stellen meestal beperkte voorwaarden, zoals naamsvermelding en behoud van de licentietekst.

Copyleft-licenties geven ook ruime rechten, maar kunnen eisen dat afgeleide werken onder dezelfde of een vergelijkbare licentie worden verspreid.

Copyleft is een licentieprincipe waarbij vrijheid moet worden doorgegeven. Wie het werk verspreidt, vaak ook in aangepaste vorm, moet anderen dezelfde rechten geven.

Het is dus geen afstand van rechten, maar juist een actieve manier om rechten te gebruiken om openheid te behouden.

Dat hangt af van de licentie en van wat je doet. Bij sommige copyleft-licenties kan openbaarmaking verplicht worden als je aangepaste software verspreidt.

Alleen intern gebruik leidt meestal niet automatisch tot zo’n verplichting, maar de precieze uitkomst hangt af van de situatie en licentie.

Ja, veel open source licenties staan commercieel gebruik toe. Dat is juist een kenmerk van open source.

Wel moet je de licentievoorwaarden naleven. Denk aan naamsvermelding, licentieteksten of voorwaarden bij verspreiding.

Ja, open source moet aanpassing toestaan. Verkoop kan ook, zolang de licentievoorwaarden worden gevolgd.

Bij sommige licenties moet je de aangepaste broncode meeleveren of beschikbaar maken wanneer je het aangepaste werk verspreidt.

Dat zijn manieren om de oorspronkelijke maker en de licentie zichtbaar te houden. Attribution betekent meestal naamsvermelding. Een notice file bevat juridische meldingen. Een license header staat vaak bovenaan een bestand.

Deze verplichtingen zorgen dat rechten en herkomst herkenbaar blijven.

Een patentclausule regelt dat gebruikers onder voorwaarden ook toestemming krijgen voor relevante patenten van bijdragers.

Dat kan belangrijk zijn omdat software niet alleen door auteursrecht, maar soms ook door patentrechten geraakt kan worden.

Het belangrijkste risico is dat licentievoorwaarden niet worden nageleefd. Dan gebruik je het werk mogelijk zonder geldige toestemming.

Dat kan leiden tot herstelverplichtingen, juridische claims, reputatieschade of problemen bij verkoop, aanbesteding of audit.

Open source compliance betekent dat een organisatie weet welke open source zij gebruikt, welke licenties daarbij horen en welke verplichtingen gelden.

Het is vooral normaal juridisch en organisatorisch beheer: registreren, controleren, naleven en kunnen uitleggen wat er is gebruikt.

Nee, niet door het open source karakter. Veiligheid hangt af van ontwerp, onderhoud, controle, gebruik en opvolging van kwetsbaarheden.

Openheid maakt controle mogelijk, maar is geen automatische garantie op veiligheid.

Nee. Iedereen kan vaak voorstellen doen, maar dat betekent niet dat iedereen zomaar wijzigingen mag doorvoeren.

Bij serieuze projecten beoordelen beheerders welke bijdragen worden opgenomen. Betrouwbaarheid hangt af van governance en onderhoud, niet alleen van de licentievorm.

Nee. Support kan vrijwillig, community-gedreven of commercieel zijn. Veel bedrijven leveren betaalde ondersteuning rond open source.

De licentie bepaalt de rechten op het werk; support is een aparte dienst.

Nee. Open source gaat over gebruiksrechten, niet over prijs.

Een open source product kan gratis downloadbaar zijn, maar ondersteuning, hosting, certificering, training of maatwerk kunnen betaald zijn.

Nee. Gratis gaat over prijs. Vrij gaat over rechten.

Een gratis product kan streng gesloten zijn. Een open source product geeft juist rechten om te gebruiken, te bestuderen, te delen en aan te passen.

Nee. Open source kan door vrijwilligers worden gemaakt, maar ook door bedrijven, overheden, universiteiten en stichtingen.

De licentie zegt niets over professionaliteit. Die moet je beoordelen aan de hand van kwaliteit, beheer en context.

Nee. Open source kan zeer professioneel zijn en commerciële software kan slecht onderhouden zijn. Het omgekeerde kan ook.

Professionaliteit blijkt uit onderhoud, documentatie, governance, kwaliteit en afspraken, niet uit open of gesloten licenties alleen.

Openheid betekent dat iedereen kan kijken, dus ook kwaadwillenden. Maar het betekent ook dat controle door gebruikers, onderzoekers en leveranciers mogelijk is.

Veiligheid ontstaat niet door geheimhouding alleen. Zij vraagt onderhoud, respons en zorgvuldig gebruik.

Nee. De juridische rechten zijn voor iedereen relevant: gebruikers, bestuurders, inkopers, juristen, auditors en beleidsmakers.

Ontwikkelaars werken vaak met de code, maar organisaties profiteren ook van transparantie, keuzevrijheid en controleerbaarheid.

Dat kan een afweging zijn, maar het is niet automatisch een nadeel. Open source gaat over bewust bepalen welke delen je wilt delen en onder welke voorwaarden.

Soms is open delen juist strategisch nuttig, bijvoorbeeld om samenwerking, vertrouwen of standaardisatie te bevorderen.

Dat verschilt per project. Controle kan komen van maintainers, gebruikers, securityonderzoekers, audits, automatische scans en organisaties die de software inzetten.

Open source maakt zulke controle mogelijk, maar organiseert die niet vanzelf.

Dat hangt af van de situatie. De projectbeheerders kunnen een update maken, maar de gebruiker of organisatie moet die update ook toepassen.

Open source verandert niet dat wie software inzet verantwoordelijk blijft voor zorgvuldig beheer.

Dat verschilt sterk. Actieve projecten kunnen snel reageren; verlaten projecten niet. Hetzelfde geldt overigens ook voor gesloten software.

Kijk daarom niet alleen naar de licentie, maar ook naar onderhoud, meldproces en releasepraktijk.

Supply-chain risico’s ontstaan wanneer je afhankelijk bent van onderdelen van anderen. Als zo’n onderdeel kwetsbaar, kwaadaardig of slecht onderhouden is, kan dat gevolgen hebben voor je eigen product.

Dit risico is niet exclusief voor open source, maar open source maakt afhankelijkheden vaak zichtbaarder.

Dependencies zijn onderdelen waar een product op steunt. Bij software zijn dat vaak bibliotheken of pakketten van anderen.

Ze zijn belangrijk omdat rechten, kwetsbaarheden en onderhoud van die onderdelen ook invloed hebben op je eigen gebruik.

Kijk naar de licentie, het onderhoud, de documentatie, de manier waarop wijzigingen worden beoordeeld en hoe veiligheidsmeldingen worden behandeld.

Betrouwbaarheid is een combinatie van juridische duidelijkheid, kwaliteit en beheer.

Gezonde signalen zijn duidelijke licentie-informatie, recente updates, begrijpelijke documentatie, een actief meldproces en zichtbare besluitvorming.

Ook helpt het als meerdere mensen of organisaties bijdragen, zodat het project niet volledig van één persoon afhankelijk is.

Let op oude releases, onbeantwoorde meldingen, ontbrekende licentie-informatie, onduidelijke onderhouders of geen reactie op beveiligingsproblemen.

Dat zijn projectrisico’s. Ze komen bij open en gesloten software voor, maar bij open source zijn ze vaak beter zichtbaar.

Bij een security audit beoordeelt iemand gericht of er kwetsbaarheden of zwakke plekken zijn. Bij open source kan de broncode daarbij direct worden onderzocht.

Een audit is een momentopname. Daarna blijven onderhoud en opvolging nodig.

Een SBOM is een software bill of materials: een overzicht van gebruikte softwareonderdelen.

Zo’n overzicht helpt om licenties, kwetsbaarheden en afhankelijkheden te beheren. Het is vooral nuttig voor organisaties die moeten kunnen uitleggen wat zij gebruiken.

Een open source project ontstaat wanneer een rechthebbende werk publiceert onder een open source licentie. Vaak komt daar documentatie, een plek voor bijdragen en een manier van besluitvorming bij.

De licentie is de juridische basis; de community en werkwijze bepalen hoe het project verder groeit.

Dat doen meestal de maintainers of beheerders van het project. Zij beoordelen of een bijdrage past bij kwaliteit, richting en afspraken van het project.

Open source betekent dus niet dat elke wijziging automatisch onderdeel wordt van het officiële project.

Een maintainer is iemand die een project beheert. Die persoon of groep beoordeelt bijdragen, maakt releases, bewaakt richting en onderhoudt documentatie of processen.

Bij open source is die rol belangrijk omdat rechten ruim zijn, maar samenwerking nog steeds organisatie vraagt.

Een contributor is iemand die bijdraagt aan een project. Dat kan code zijn, maar ook documentatie, vertaling, testen, ontwerp, uitleg of het melden van problemen.

Open source bijdragen zijn dus breder dan programmeren.

Een fork is een eigen kopie van een project waarop iemand zelfstandig verder kan werken. Dat is mogelijk omdat open source aanpassing en verspreiding toestaat.

Soms komt een verbetering later terug in het oorspronkelijke project. Soms groeit een fork uit tot een eigen richting.

Dat is een voorstel om een wijziging op te nemen in een project. De beheerder kan de wijziging beoordelen, bespreken, aanpassen of weigeren.

Het is een praktische manier om samenwerking rond open source te organiseren.

Community governance gaat over de afspraken waarmee een project besluiten neemt. Denk aan wie mag meebeslissen, hoe conflicten worden opgelost en hoe nieuwe beheerders worden aangewezen.

De licentie geeft rechten; governance regelt samenwerking.

Bij community-led projecten ligt de sturing vooral bij een gemeenschap van deelnemers. Bij company-led projecten heeft een bedrijf vaak een grote of beslissende rol.

Beide vormen kunnen goed werken, zolang duidelijk is wie beslist en onder welke voorwaarden.

Dat hangt af van de governance. Sommige projecten hebben duidelijke besluitregels, gedragscodes of stichtingen. Andere projecten zijn informeler.

Goede afspraken zijn belangrijk omdat open rechten niet automatisch betekenen dat iedereen het eens wordt.

Projecten stoppen als onderhouders geen tijd meer hebben, financiering ontbreekt, de behoefte verdwijnt of een betere oplossing ontstaat.

Dat is niet uniek voor open source. Het verschil is dat anderen bij open source soms kunnen doorgaan met een fork.

Bedrijven verdienen niet noodzakelijk aan het exclusief verkopen van de code, maar aan diensten eromheen. Denk aan hosting, support, implementatie, beheer, training, certificering of maatwerk.

De open licentie en het bedrijfsmodel zijn twee verschillende lagen.

Veel voorkomende modellen zijn betaalde ondersteuning, managed hosting, consultancy, certificering, training, dual licensing en open core.

Het uitgangspunt is vaak: de basisrechten zijn open, maar gemak, zekerheid of aanvullende diensten kunnen betaald zijn.

Open core betekent dat de kern van een product open source is, terwijl sommige extra functies gesloten of betaald zijn.

Dat kan werken, maar het vraagt duidelijke communicatie. Gebruikers moeten weten welk deel open is en welk deel niet.

Dual licensing betekent dat hetzelfde werk onder twee verschillende licenties beschikbaar is. Bijvoorbeeld een open source licentie en een commerciële licentie.

Dat kan organisaties keuze geven, maar kan alleen als de rechthebbende de rechten heeft om beide licenties aan te bieden.

Managed hosting of SaaS betekent dat iemand open source software als dienst aanbiedt. De gebruiker hoeft de software dan niet zelf te installeren en te beheren.

De software kan open source zijn, terwijl de dienst eromheen betaald is.

Bedrijven kunnen dat doen om vertrouwen te vergroten, samenwerking te stimuleren, een standaard te zetten of adoptie te versnellen.

Open source kan ook helpen om afhankelijkheid van één leverancier te verminderen en een ecosysteem te bouwen.

Omdat anderen mogen voortbouwen op bestaand werk. Zij hoeven niet steeds opnieuw te beginnen en kunnen verbeteringen delen.

De licentie maakt die samenwerking juridisch mogelijk.

Open source kan afhankelijkheid van één leverancier verkleinen omdat gebruikers rechten hebben om de software te bestuderen, aan te passen en elders te laten beheren.

Dat betekent niet dat overstappen altijd eenvoudig is, maar de juridische basis is minder gesloten.

Open source is interessant wanneer samenwerking, transparantie, controleerbaarheid, hergebruik of onafhankelijkheid belangrijk zijn.

Het is vooral sterk bij gedeelde infrastructuur, publieke waarden en situaties waarin vertrouwen meer vraagt dan een leveranciersbelofte.

Open source past minder goed wanneer de rechthebbende verspreiding, inzage of aanpassing juist wil beperken. Dat is een strategische keuze over controle.

Het is ook minder passend als een organisatie rechten wil geven zonder bereid te zijn licentievoorwaarden en beheer duidelijk vast te leggen.

Startups kunnen sneller bouwen op bestaande componenten en makkelijker vertrouwen winnen door openheid. Ook kunnen zij rond een open project een gemeenschap of markt ontwikkelen.

Daarbij moeten zij wel bewust omgaan met licenties, positionering en hun verdienmodel.

Voor overheden kan open source bijdragen aan transparantie, controleerbaarheid, hergebruik en minder afhankelijkheid van één leverancier.

Dat past goed bij publieke verantwoording, mits beheer, veiligheid en juridische naleving goed zijn geregeld.

Onderwijs kan open source gebruiken om te leren van echte voorbeelden, materiaal te delen en studenten te laten bijdragen aan bestaande projecten.

Omdat aanpassen is toegestaan, kan lesmateriaal of software beter aansluiten op de onderwijspraktijk.

Open source kan helpen omdat organisaties niet volledig afhankelijk zijn van gesloten kennis of één leverancier. Zij kunnen laten controleren hoe iets werkt en het laten aanpassen.

Soevereiniteit vraagt meer dan open source alleen, maar open rechten zijn een belangrijke bouwsteen.

Open source maakt zichtbaar onder welke voorwaarden een werk gebruikt mag worden en, bij software, hoe de broncode eruitziet.

Dat maakt controle en uitleg beter mogelijk. Transparantie ontstaat wel pas echt als documentatie en governance ook duidelijk zijn.

Omdat anderen bestaand werk mogen gebruiken en aanpassen, hoeft niet iedereen hetzelfde opnieuw te maken.

Dat kan verspilling verminderen en onderhoud delen, vooral wanneer meerdere partijen hetzelfde probleem hebben.

Open source laat zien hoe een organisatie werkt, welke kwaliteit zij nastreeft en waar zij voor staat. Mensen kunnen laagdrempelig bijdragen of leren kennen wat er gebeurt.

Dat kan aantrekkelijk zijn voor professionals die waarde hechten aan openheid en vakmanschap.

Concurrenten kunnen samenwerken aan onderdelen die voor iedereen nodig zijn, zonder dat die onderdelen het onderscheidende product hoeven te zijn.

De licentie geeft vooraf duidelijkheid over rechten, zodat samenwerking minder afhankelijk is van losse afspraken.

Publieke infrastructuur vraagt vertrouwen, continuïteit en controleerbaarheid. Open source kan helpen doordat de basis niet volledig achter gesloten deuren ligt.

Dat maakt onafhankelijke controle en gezamenlijk onderhoud beter mogelijk.

In deze gebieden kan open source bijdragen aan controleerbaarheid, hergebruik en onafhankelijk onderzoek.

Tegelijk blijven goede governance, databeheer, veiligheid en juridische beoordeling nodig. Open source is een basisvoorwaarde voor bepaalde vormen van controle, geen totaaloplossing.

Begin bij de licentie: mag het gebruik dat u voor ogen heeft? Kijk daarna naar onderhoud, documentatie, kwaliteit en afhankelijkheden.

Een populair pakket is niet automatisch passend. De keuze moet passen bij doel, risico en beheer.

Controleer de licentie, herkomst, onderhoudsstatus, kwetsbaarheden en noodzaak. Vraag ook of het onderdeel echt nodig is.

Elke dependency voegt rechten, verplichtingen en beheer toe.

Leg vast welke onderdelen worden gebruikt, welke versie, welke licentie en waar het onderdeel in zit.

Zorg ook dat duidelijk is wie verantwoordelijk is voor updates en naleving van voorwaarden.

Gebruik een combinatie van registratie, periodieke controle en hulpmiddelen die afhankelijkheden scannen.

Belangrijker nog: spreek af wie meldingen beoordeelt en wie beslist over updates of vervanging.

Er bestaan veel hulpmiddelen die afhankelijkheden, licenties en kwetsbaarheden in kaart brengen. Voorbeelden zijn scanners in ontwikkelplatformen, pakketbeheerders en gespecialiseerde compliance-tools.

De tool is slechts een hulpmiddel. De organisatie moet nog steeds keuzes maken en opvolging regelen.

Lees eerst de bijdrage-instructies en licentie. Beschrijf helder wat u wilt verbeteren en waarom.

Een goede bijdrage kan code zijn, maar ook documentatie, testen, vertaling of een duidelijk beschreven probleem.

Dat is zinvol als u wilt dat anderen het werk kunnen gebruiken, controleren, delen en aanpassen.

Maak die keuze bewust: bepaal doel, licentie, onderhoud, governance en wat u wel of niet van bijdragen verwacht.

Bepaal eerst wat u wilt toestaan en beschermen. Wilt u vooral brede herbruikbaarheid, kijk dan naar permissieve licenties. Wilt u dat vrijheid wordt doorgegeven, kijk dan naar copyleft.

Gebruik bij voorkeur bestaande, bekende licenties in plaats van zelf tekst te schrijven.

Zorg voor duidelijke documentatie, een vriendelijke manier om vragen te stellen, heldere besluitvorming en realistische verwachtingen.

Een community ontstaat niet alleen door code online te zetten. Zij vraagt aandacht, vertrouwen en onderhoud.

Verdeel rechten en verantwoordelijkheden. Documenteer processen, maak releases overdraagbaar en geef meerdere betrouwbare mensen beheerrechten.

Dat vergroot de continuïteit en maakt het project minder kwetsbaar.

Een Open Source Program Office, vaak OSPO genoemd, is een team of functie die open source gebruik en bijdragen binnen een organisatie organiseert.

Het helpt met beleid, licenties, samenwerking, community’s en verantwoord publiceren.

Minimaal is beleid nodig voor gebruik, bijdragen, publiceren, licentiecontrole en beveiligingsopvolging.

Het beleid moet praktisch zijn: mensen moeten weten wat mag, wanneer zij advies vragen en wie beslist.

Leg in gewone taal uit wat auteursrecht, licenties en verplichtingen betekenen. Gebruik voorbeelden uit het eigen werk.

Training moet niet alleen juridisch zijn, maar ook praktisch: wat registreer je, wat controleer je en waar vraag je hulp?

Zorg dat duidelijk is welke onderdelen zijn gebruikt, welke licenties gelden, welke controles zijn uitgevoerd en welke besluiten zijn genomen.

Auditbaar betekent vooral: achteraf kunnen uitleggen wat er is gebeurd en waarom.

Neem open source bewust mee in eisen, beoordelingscriteria en contractvoorwaarden. Vraag niet alleen naar een product, maar ook naar rechten, overdraagbaarheid en beheer.

Zo voorkomt u dat openheid alleen een wens blijft en niet in de opdracht terechtkomt.

Zie support als aanvulling op de open source rechten. Het contract kan afspraken bevatten over responstijden, updates, aansprakelijkheid, hosting of beheer.

De software kan open zijn, terwijl de ondersteuning professioneel en betaald is.

Kijk niet alleen naar licentiekosten. Tel ook beheer, support, training, integratie, migratie, compliance en onderhoud mee.

Open source kan goedkoper zijn, maar de echte waarde zit vaak ook in controle, flexibiliteit en minder afhankelijkheid.

Behandel open source als onderdeel van normaal risicobeheer. Kijk naar licenties, onderhoud, beveiliging, afhankelijkheden en continuïteit.

Het risico is niet dat iets open source is, maar dat gebruik onbewust of onbeheerd gebeurt.

Meet niet alleen bespaarde kosten. Kijk ook naar hergebruik, snelheid, transparantie, vermeden afhankelijkheid, samenwerking en kwaliteit van controle.

Sommige waarde is financieel, andere waarde zit in autonomie en vertrouwen.

Nee. Open source geeft belangrijke vrijheden, maar zegt niet automatisch iets over alle ethische keuzes rond gebruik, impact of governance.

Openheid kan wel helpen om discussie, controle en verantwoording mogelijk te maken.

Niet volledig. Open source licenties staan breed gebruik toe en beperken meestal niet waarvoor iemand het werk gebruikt.

Wie misbruik wil beperken, komt al snel buiten klassieke open source uit en moet nadenken over andere juridische of organisatorische middelen.

Klassieke open source licenties beperken gebruiksdoelen juist niet. Zij geven rechten aan iedereen, ook als de maker sommige toepassingen onwenselijk vindt.

Er bestaan licenties met ethische gebruiksbeperkingen, maar die worden doorgaans niet als open source in strikte zin gezien.

Open source geeft anderen controle over hun eigen gebruik: zij mogen bestuderen, aanpassen en delen. De oorspronkelijke maker geeft daardoor een deel van exclusieve controle op verspreiding en aanpassing los.

Dat is geen fout, maar precies de keuze die open source bijzonder maakt.

Open source kan publieke waarden ondersteunen zoals transparantie, controleerbaarheid, hergebruik en onafhankelijkheid.

Maar publieke waarden vragen ook goed bestuur, toegankelijkheid, veiligheid, financiering en verantwoordelijkheid.

Dat verschilt sterk per project. Sommige communities zijn open en behulpzaam, andere zijn moeilijk toegankelijk of afhankelijk van informele netwerken.

Inclusie vraagt actieve aandacht voor taal, gedrag, documentatie, besluitvorming en veilige deelname.

Dat is een belangrijk vraagstuk. Veel digitale infrastructuur wordt breed gebruikt, maar niet altijd breed gefinancierd.

Open source maakt gebruik mogelijk, maar onderhoud vraagt tijd, geld en verantwoordelijkheid van partijen die ervan afhankelijk zijn.

Open source kan macht spreiden omdat gebruikers meer rechten hebben dan alleen afnemen wat een leverancier aanbiedt. Zij kunnen laten controleren, aanpassen of overstappen.

Dat versterkt autonomie, maar alleen als er ook kennis, capaciteit en governance zijn om die rechten te benutten.

Helemaal voorkomen kan meestal niet binnen klassieke open source. Wel kunnen projecten kiezen voor passende licenties, governance, commerciële afspraken en een cultuur waarin bijdragen normaal zijn.

Ook gebruikers kunnen verantwoordelijkheid nemen door onderhoud, geld of kennis terug te geven.

Open source blijft belangrijk voor digitale infrastructuur, overheid, onderwijs, cloud, AI en security. De kern blijft juridisch: rechten geven om te gebruiken, te bestuderen, te delen en aan te passen.

De grote uitdaging is duurzaam beheer: zorgen dat open projecten niet alleen gebruikt, maar ook onderhouden en verantwoord bestuurd worden.

Pentest volgens MIAUW 15 vragen

MIAUW staat voor Methodiek voor Informatiebeveiligingsonderzoek met Auditwaarde. Het is een manier om beveiligingsonderzoek, zoals een pentest, gestructureerd en controleerbaar uit te voeren.

Het doel is dat een organisatie niet alleen een rapport krijgt, maar ook beter kan aantonen wat er is onderzocht, hoe dat is gedaan en welke conclusies daaruit volgen.

Lees meer op MIAUW.

Veel beveiligingsonderzoeken leveren nuttige bevindingen op, maar zijn achteraf moeilijk te beoordelen. Soms is onduidelijk wat precies binnen de scope viel, welke stappen zijn uitgevoerd of welk bewijs bij een conclusie hoort.

MIAUW helpt om die onderdelen vooraf en tijdens het onderzoek beter vast te leggen. Daardoor wordt het onderzoek bruikbaarder voor herstel, verantwoording en audits.

Lees meer op MIAUW en in Wat betekent auditwaarde?.

Nee. Een pentest is een vorm van beveiligingsonderzoek. MIAUW is een methodiek om zo’n onderzoek beter te structureren, vast te leggen en controleerbaar te maken.

Een pentest kan dus volgens MIAUW worden uitgevoerd, maar MIAUW is breder dan alleen het uitvoeren van technische tests.

Lees ook Wat is een pentest? en MIAUW.

Auditwaarde betekent dat een onderzoek achteraf goed beoordeeld kan worden. Een auditor of andere beoordelaar moet kunnen zien wat is afgesproken, wat is getest, welk bewijs er is en hoe conclusies tot stand zijn gekomen.

Dat maakt een onderzoek niet alleen nuttig voor techniek, maar ook voor bestuur, compliance en verantwoording.

Lees meer op MIAUW en Wat is een auditorverklaring bij MIAUW?.

MIAUW is bedoeld voor opdrachtgevers, pentesters, auditors, compliance-specialisten en bestuurders.

De opdrachtgever krijgt meer grip op het onderzoek. De onderzoeker krijgt een duidelijke structuur. De auditor krijgt beter toetsbare informatie. Bestuurders krijgen meer zekerheid over wat een rapport wel en niet zegt.

Lees meer op MIAUW.

Nee. Geen enkele methodiek kan garanderen dat een systeem veilig is.

MIAUW helpt wel om beveiligingsonderzoek beter uit te voeren, beter te documenteren en beter te gebruiken voor verbetering. Het vergroot dus de kwaliteit en bruikbaarheid van onderzoek, maar vervangt geen goed beveiligingsbeheer.

Lees ook Wat staat centraal in een MIAUW-onderzoek?.

Centraal staan duidelijke afspraken, een heldere scope, navolgbaar bewijs, reproduceerbare bevindingen en rapportage die bruikbaar is voor verschillende doelgroepen.

Een technisch team wil details om problemen op te lossen. Management wil weten wat het risico betekent. Een auditor wil kunnen beoordelen of het onderzoek zorgvuldig is uitgevoerd.

Lees meer op MIAUW.

Scope betekent: wat hoort wel en niet bij het onderzoek. Denk aan systemen, domeinen, applicaties, accounts, netwerken, perioden en onderzoeksvragen.

Een duidelijke scope voorkomt misverstanden. Zonder scope is achteraf moeilijk te zeggen of iets bewust buiten beeld bleef of per ongeluk niet is onderzocht.

Zie ook Hoe gaat OpenKAT om met scope en toestemming?.

Bewijs maakt bevindingen controleerbaar. Een rapport moet niet alleen zeggen dat er iets mis is, maar ook laten zien waarop die conclusie is gebaseerd.

Bewijs kan bestaan uit logs, screenshots, commando-uitvoer, configuratiegegevens of andere vastleggingen. Daarbij moet natuurlijk zorgvuldig worden omgegaan met gevoelige informatie.

Lees ook Wat betekent evidence-based security?.

Een bevinding is een vastgesteld probleem, risico of aandachtspunt uit het onderzoek.

Een goede bevinding beschrijft wat er is gevonden, waarom dat belangrijk is, welk bewijs erbij hoort, wat de impact kan zijn en welke maatregel helpt om het probleem te verminderen of op te lossen.

Lees ook Wat is het verschil tussen een risico en een kwetsbaarheid?.

Een kwetsbaarheid is een zwakke plek. Een risico gaat over wat die zwakke plek kan betekenen voor de organisatie.

Een kwetsbaarheid in een testsysteem zonder gevoelige data heeft vaak een ander risico dan dezelfde kwetsbaarheid in een publiek systeem met persoonsgegevens. Context is dus belangrijk.

Lees ook Wat is een bevinding?.

Nee. Grote organisaties hebben vaak meer formele audit- en compliance-eisen, maar kleinere organisaties hebben ook baat bij duidelijke afspraken, beter bewijs en bruikbare rapportage.

MIAUW kan juist helpen om beveiligingsonderzoek begrijpelijker en beter overdraagbaar te maken.

Lees meer op MIAUW.

Een auditorverklaring kan helpen om aan te tonen dat een onderzoek volgens afspraken is uitgevoerd, zonder dat alle technische details breed gedeeld hoeven te worden.

Dat is nuttig wanneer een volledige rapportage te gevoelig is voor brede verspreiding, maar een organisatie wel moet aantonen dat er serieus en controleerbaar onderzoek is gedaan.

Lees ook Als ik een pentest met MIAUW doe, moet ik die dan openbaar maken?.

Een pentest, voluit penetratietest, is een gecontroleerd beveiligingsonderzoek. Onderzoekers proberen kwetsbaarheden te vinden voordat kwaadwillenden dat doen.

Een pentest is geen willekeurige aanval. Er zijn afspraken over scope, toestemming, aanpak, rapportage en zorgvuldigheid. De onderzoekers gebruiken technieken die aanvallers ook kunnen gebruiken, maar met het doel om de beveiliging te verbeteren.

Bij de Methodiek voor Informatiebeveiligingsonderzoek met Auditwaarde (MIAUW) hebben we uitgebreid stilgestaan bij een definitie onder leiding van mr. V.A. de Pous. Daaruit kwam deze definitie:

‘Een door eigen personeel of derden uit te voeren offensief beveiligingsonderzoek, waarbij gecontroleerd wordt gezocht naar kwetsbaarheden in een of meer beveiligde netwerk- en informatiesystemen of onderdelen daarvan, die kunnen worden gebruikt voor het inbreken in deze systemen en/of die zonder opzet of autonoom de gegevensverwerking van de onderzochte organisatie kunnen verstoren of anderszins nadelige gevolgen kunnen hebben.’

Lees ook Wat is MIAUW?.

Nee, dat hoeft niet. Het doel van MIAUW is juist om de opdrachtgever centraal te stellen. Als je betaalt voor een rapportage, dan is het logisch dat je controle hebt over het product dat je koopt. Daarom zegt MIAUW wel iets over de leverancier: die mag de opdrachtgever geen beperkingen opleggen voor verspreiding. Dat staat zo beschreven:

Er worden aan de opdrachtgever geen beperkingen opgelegd met betrekking tot verspreiding/distributie, publicatie of opslaan van de rapportage en de onderliggende stukken. Uitgezonderd hiervan zijn financiële gegevens met betrekking tot de uitvoering van het onderzoek, zoals uurtarieven, prijzen en facturen.

Het grotere doel is dat je met een pentest ook kunt aantonen dat de belangrijke zaken goed zijn geregeld. Dat is lastig als je het onderzoek niet aan anderen mag tonen of verstrekken. Financiële informatie over het onderzoek hoeft daarvoor niet gedeeld te worden, want die zegt niets over de beveiligingsstatus.

Staat er te veel gevoelige informatie in het rapport om het breed te delen? Dan kan een auditorverklaring helpen. Daarmee kun je aantonen dat het onderzoek is uitgevoerd en wat de hoofduitkomst was, zonder alle technische details te verspreiden.

Kortom: de opdrachtgever bepaalt welk niveau van informatie met partners, toezichthouders of anderen wordt gedeeld, zonder daarin door de leverancier te worden belemmerd.

Lees ook Wat is een auditorverklaring bij MIAUW?.

OpenKAT 23 vragen

OpenKAT is de Open Kwetsbaarheden Analyse Tool. Het is open source-software die organisaties helpt hun digitale landschap in kaart te brengen en kwetsbaarheden, misconfiguraties en risico’s zichtbaar te maken.

OpenKAT draait om inzicht: wat hebben we, wat is zichtbaar, wat verandert er en waar moeten we iets mee?

Lees meer op OpenKAT.

OpenKAT helpt om je digitale buitenkant en binnenkant beter te begrijpen. Het verzamelt informatie over systemen, domeinen, software en instellingen en zet die om in bruikbaar inzicht.

In gewone taal: OpenKAT helpt zien waar digitale deuren, ramen en sloten zitten en welke daarvan aandacht nodig hebben.

Lees meer op OpenKAT.

Het aanvalsoppervlak is alles wat een aanvaller zou kunnen proberen te gebruiken om toegang te krijgen of schade te veroorzaken.

Denk aan websites, mailservers, cloudomgevingen, API’s, VPN’s, oude domeinen, vergeten testomgevingen en verkeerd ingestelde diensten. Hoe beter je dat oppervlak kent, hoe gerichter je kunt beveiligen.

Lees ook Waarom is continu inzicht belangrijk?.

Digitale omgevingen veranderen voortdurend. Er komen systemen bij, software wordt bijgewerkt, instellingen veranderen en nieuwe kwetsbaarheden worden ontdekt.

Een eenmalige scan is daarom een momentopname. Continu inzicht helpt om veranderingen te zien en sneller te reageren wanneer iets verslechtert of opnieuw kwetsbaar wordt.

Lees ook Kan OpenKAT veranderingen in de tijd laten zien?.

Nee. OpenKAT en pentesten vullen elkaar aan.

OpenKAT geeft continu technisch inzicht en kan veel signalen verzamelen. Een pentest is een gericht onderzoek door mensen, met context, creativiteit en diepgang. OpenKAT kan helpen om pentesten beter te richten en resultaten beter te volgen.

Lees ook Wat is een pentest? en OpenKAT.

Nee. Geen enkel securityproduct vindt alles automatisch.

OpenKAT helpt om veel informatie gestructureerd te verzamelen en te beoordelen. Maar goede scope, interpretatie, beheer en opvolging blijven nodig. Menselijke context blijft belangrijk.

Lees ook Hoe helpt OpenKAT bij prioriteren?.

In OpenKAT is een boefje een kleine onderzoekstaak of scanner die specifieke informatie verzamelt. Het kan bijvoorbeeld iets controleren over DNS, TLS, softwareversies of andere technische eigenschappen.

Het idee is modulair: veel kleine taken leveren samen een rijker beeld op van de digitale omgeving.

Lees ook Wat is normaliseren in OpenKAT?.

Een bevinding is een signaal dat aandacht vraagt. Dat kan een kwetsbaarheid zijn, maar ook een verkeerde instelling, ontbrekende beveiligingsmaatregel of afwijking van beleid.

Een bevinding is niet altijd meteen een incident. Het is vooral een aanleiding om te beoordelen wat het betekent en welke opvolging nodig is.

Lees ook Hoe helpt OpenKAT bij prioriteren?.

Evidence-based security betekent dat conclusies worden gebaseerd op vastgelegde gegevens, niet alleen op gevoel of losse aannames.

OpenKAT helpt door waarnemingen te bewaren en te koppelen aan bevindingen. Daardoor is beter te zien waarop een conclusie is gebaseerd en hoe de situatie in de tijd verandert.

Lees ook Waarom is bewijs belangrijk in MIAUW?.

Compliance gaat over aantonen dat je aan regels, normen of afspraken voldoet. OpenKAT kan technische waarnemingen koppelen aan beleid of normen.

Daardoor wordt duidelijker welke technische bevindingen ook bestuurlijk of juridisch relevant zijn. Dat helpt bij audits, rapportages en prioritering.

Lees ook Kan OpenKAT helpen bij NIS2?.

Nee. Securityspecialisten hebben de technische details nodig, maar OpenKAT is ook nuttig voor beheerders, auditors, compliance-teams en bestuurders.

Iedere rol kijkt anders naar dezelfde werkelijkheid: technische details voor oplossen, overzichten voor sturen en bewijs voor verantwoording.

Lees meer op OpenKAT.

Ja. OpenKAT is open source en kan zelf worden gebruikt. Dat vraagt wel technische kennis, beheer en zorgvuldige inrichting.

Sommige organisaties kiezen daarom voor zelfbeheer. Andere organisaties werken liever met een partner voor hosting, inrichting, beheer of ondersteuning.

Zie ook Partners en OpenKAT.

OpenKAT is securitygereedschap en moet zorgvuldig worden gebruikt. Scannen doe je alleen binnen een afgesproken scope en met toestemming.

De resultaten kunnen gevoelig zijn, omdat ze iets zeggen over kwetsbaarheden en instellingen. Bescherm die informatie dus goed en geef alleen toegang aan mensen die die informatie nodig hebben.

Lees ook Hoe gaat OpenKAT om met privacy?.

OpenKAT werkt met objecten die onderzocht kunnen worden. Dat kan bijvoorbeeld een domeinnaam, IP-adres, website, server, certificaat of andere technische component zijn.

Door zulke objecten apart vast te leggen, kan OpenKAT relaties leggen: welke website hoort bij welk domein, welk certificaat hoort bij welke dienst en welke bevinding hoort bij welk onderdeel.

Lees meer op OpenKAT.

Scanners leveren vaak ruwe uitvoer op. Normaliseren betekent dat die uitvoer wordt omgezet naar gegevens die OpenKAT op een vaste manier kan begrijpen en vergelijken.

Dat is belangrijk omdat OpenKAT informatie uit verschillende bronnen wil combineren. Pas als gegevens netjes zijn gestructureerd, kun je ze koppelen aan objecten, bevindingen, normen en tijdlijnen.

Lees ook Wat betekent evidence-based security?.

Een kwetsbaarheidsscanner zoekt meestal naar specifieke technische kwetsbaarheden. OpenKAT is breder: het kan gegevens uit meerdere bronnen combineren, relaties leggen, veranderingen in de tijd tonen en bevindingen koppelen aan beleid of normen.

OpenKAT kan dus scanners gebruiken, maar is zelf vooral een platform om waarnemingen, context en opvolging bij elkaar te brengen.

Lees meer op OpenKAT.

OpenKAT is bedoeld voor onderzoek binnen een afgesproken scope. Je scant dus alleen systemen waarvoor je toestemming hebt en waarvoor duidelijk is wat onderzocht mag worden.

Dat is belangrijk om juridische, technische en organisatorische redenen. Securityonderzoek zonder duidelijke scope kan risico’s veroorzaken en vertrouwen beschadigen.

Zie ook Wat is scope bij een MIAUW-onderzoek?.

Ja. Een belangrijk idee achter OpenKAT is dat je niet alleen een momentopname wilt, maar ook wilt zien hoe de situatie verandert.

Dat helpt bij vragen als: is een probleem opgelost, is het teruggekomen, is er iets nieuws ontstaan en wordt de beveiligingssituatie beter of slechter?

Lees ook Waarom is continu inzicht belangrijk?.

Niet elke bevinding heeft dezelfde urgentie. Een technisch probleem op een onbelangrijk testsysteem is vaak minder ernstig dan hetzelfde probleem op een publiek systeem met gevoelige gegevens.

OpenKAT helpt door technische signalen te koppelen aan context, beleid en normen. Daardoor kan een organisatie beter bepalen wat eerst moet worden opgepakt.

Lees ook Hoe helpt OpenKAT bij compliance?.

OpenKAT kan helpen bij de praktische kant van aantoonbare digitale weerbaarheid: inzicht krijgen in systemen, kwetsbaarheden, misconfiguraties en veranderingen in de tijd.

NIS2 gaat niet alleen over techniek, maar ook over governance, risico’s en aantoonbaarheid. OpenKAT kan daarvoor technische onderbouwing leveren, maar vervangt geen volledig NIS2-programma.

Lees ook Hoe helpt OpenKAT bij compliance?.

OpenKAT onderzoekt vooral technische gegevens, maar de uitkomsten kunnen gevoelig zijn. Een rapport met kwetsbaarheden of configuratiefouten kan misbruikt worden als het verkeerd terechtkomt.

Daarom is het belangrijk om toegang te beperken, resultaten goed te beschermen en alleen te scannen binnen een duidelijke scope.

Lees ook het privacybeleid van deze website en Is OpenKAT veilig om te gebruiken?.

Losse scanresultaten zijn vaak moeilijk te interpreteren. Relaties maken duidelijk hoe onderdelen samenhangen: welk domein bij welke website hoort, welke dienst op welk systeem draait en welke bevinding bij welk object hoort.

Door die relaties wordt OpenKAT meer dan een lijst meldingen. Het wordt een model van de digitale omgeving dat helpt om oorzaken, impact en opvolging beter te begrijpen.

Lees meer op OpenKAT.

Ja. OpenKAT is juist interessant omdat het informatie uit verschillende bronnen kan combineren. Denk aan scanners, externe databronnen, configuratiecontroles en eigen onderzoekstaken.

Het doel is niet om elk hulpmiddel te vervangen, maar om resultaten beter samen te brengen en bruikbaar te maken voor analyse, opvolging en verantwoording.

Lees meer op OpenKAT.

OciDeck 25 vragen

OciDeck is een presentatieprogramma waarin de inhoud centraal staat. Je bouwt slides vanuit duidelijke slidevormen, data en tekst, in plaats van vooral handmatig objecten over een canvas te schuiven.

Lees meer op OciDeck.

OciDeck is bedoeld voor mensen die presentaties zien als kennisdragers. Denk aan trainers, onderzoekers, security-professionals, ontwikkelaars, auditors, beleidsmakers en organisaties die grip willen houden op hun informatie.

Het is vooral interessant wanneer inhoud, hergebruik, controleerbaarheid en veilig delen belangrijk zijn.

Lees meer op OciDeck en Features van OciDeck.

Veel presentatiesoftware begint met een leeg canvas. Je sleept tekstvakken, afbeeldingen en vormen naar hun plek.

OciDeck begint bij de inhoud. Je kiest het soort slide, vult de inhoud in en laat de presentatie daaruit ontstaan. Dat maakt slides beter te controleren, hergebruiken en exporteren.

Lees ook Waarom Marp belangrijk is voor OciDeck.

Marp is een manier om presentaties te maken met Markdown. Markdown is een eenvoudige tekstnotatie.

Voor OciDeck is Marp belangrijk omdat de presentatie daardoor gewone tekst blijft. Dat maakt wijzigingen controleerbaar en zorgt dat de inhoud niet opgesloten zit in een gesloten bestandsformaat.

Lees meer op Waarom Marp belangrijk is voor OciDeck.

Niet per se. OciDeck biedt gestructureerde editors per slidetype. Je kunt dus werken zonder de hele tijd Markdown te schrijven.

Markdown is vooral de open basis onder de presentatie. Wie Markdown kent, kan daar extra voordeel uit halen, maar het is geen harde voorwaarde voor elk gebruik.

Lees ook Wat is Marp?.

Presentaties bevatten vaak meer gevoelige informatie dan mensen denken: namen, e-mailadressen, klantgegevens, tokens, screenshots, sprekersnotities of technische details.

OciDeck helpt om zulke informatie eerder zichtbaar te maken, voordat een presentatie wordt gedeeld of geëxporteerd.

Lees meer op Privacyfeatures in OciDeck.

OciWacht zoekt lokaal naar mogelijk gevoelige gegevens in een presentatie. Denk aan identificatienummers, e-mailadressen, telefoonnummers, tokens, sleutels of andere gevoelige patronen.

Per bevinding kan de maker kiezen wat ermee moet gebeuren: accepteren, markeren of weglaten uit presentatie en export.

Lees meer op Privacyfeatures in OciDeck.

Nee, niet voor de gewone verwerking van je presentatie. OciDeck web draait in je browser: de Flutter-web-app wordt geladen vanaf de server en daarna gebeuren bewerken, live preview, OciWacht, export naar PDF/PPTX/HTML en de CVSS-builder client-side. Deckinhoud gaat niet naar een backend om verwerkt te worden.

Er is ook geen telemetrie of analytics ingebouwd. De OciDeck-hostingserver krijgt dus geen applicatie-inzicht in je deck, edits, privacybevindingen of exports.

Er zijn wel nuances. Zoals elke webhost kan de server gewone access-logs hebben, bijvoorbeeld IP-adres, tijdstip, opgevraagde bestanden en user-agent. Dat laat zien dat iemand de app heeft geladen, maar niet wat die persoon in OciDeck doet.

Daarnaast is er een optionele fetch-proxy voor URL-import wanneer een bron geen CORS-toegang toestaat. Alleen als je zo’n non-CORS-URL opent via die proxy, ziet de server de URL die je hebt opgegeven en geeft hij de bytes door.

Andere uitgaande verbindingen zijn gebruiker-geïnitieerd en gaan naar door jou gekozen of geconfigureerde bestemmingen, zoals optionele AI-assistentie, WebDAV/Nextcloud, een CVE-database, secmodule-provisioning of een URL die je zelf importeert.

Wie OciDeck in de browser wil gebruiken, kan terecht op ocideck.nl.

Lees meer op Privacyfeatures in OciDeck.

Nee. Geen enkele scan vindt alles.

OciWacht is een hulpmiddel om risico’s eerder te zien en bewuster te delen. De maker blijft verantwoordelijk voor de inhoud en moet bij gevoelige presentaties altijd zelf blijven nadenken.

Lees ook Waarom zijn privacyfeatures in OciDeck belangrijk?.

Niet elke slide is voor elk publiek bedoeld. OciDeck kan helpen om per presentatie en per slide vast te leggen hoe breed informatie gedeeld mag worden.

Daarmee kan OciDeck helpen voorkomen dat een interne slide per ongeluk in een bredere presentatie of export terechtkomt.

Lees meer op Delen op het juiste niveau.

TLP staat voor Traffic Light Protocol. Het is een kleurensysteem om aan te geven hoe vertrouwelijk informatie is en met wie die informatie gedeeld mag worden.

Je hoeft de afkorting niet te kennen om het principe te begrijpen. De praktische vraag is: wie mag deze informatie zien?

Lees meer op Delen op het juiste niveau.

Ja. Grafieken in OciDeck blijven verbonden met data. Daardoor zijn ze beter controleerbaar en minder afhankelijk van screenshots of handmatig gemaakte afbeeldingen.

Dat is nuttig voor onderzoek, rapportages, dashboards en presentaties waarin cijfers moeten blijven kloppen.

Lees meer op Features van OciDeck.

Ja. Checklists kunnen tijdens het presenteren worden afgevinkt.

Dat is nuttig voor trainingen, workshops, demonstraties, securityreviews en rapportages waarin voortgang zichtbaar moet zijn. De checklist wordt dan onderdeel van het verhaal, niet iets naast de presentatie.

Lees meer op Features van OciDeck.

Ja. OciDeck is gericht op werken vanuit één bron en export naar bruikbare vormen zoals PDF, PPTX en zelfstandige offline HTML.

Het voordeel is dat dezelfde inhoud voor verschillende doelen gebruikt kan worden, zonder telkens handmatig nieuwe kopieën op te bouwen.

Lees meer op Features van OciDeck.

Ja. OciDeck is open source. De broncode staat in Forgejo:

https://pawprint.vigilis.online/LibreKAT/Ocideck

Lees ook OciDeck.

Slidevormen zijn vaste soorten slides, zoals een titel, lijst, tabel, grafiek, codevoorbeeld, vraag, tijdlijn of dashboard.

Door met slidevormen te werken, hoeft de maker minder handmatig te schuiven. De inhoud staat centraal en OciDeck kan die inhoud consistenter tonen, controleren en exporteren.

Lees meer op Features van OciDeck.

Ja. OciDeck ondersteunt slides met broncode en syntax highlighting. Code blijft daarbij echte tekst in plaats van een screenshot.

Dat is handig voor technische presentaties, trainingen en securityrapportages waarin code leesbaar en controleerbaar moet blijven.

Lees meer op Features van OciDeck.

Ja. OciDeck kan vrije Markdown-slides gebruiken met onder meer Mermaid-diagrammen en LaTeX-wiskunde.

Dat betekent dat diagrammen en formules als broninhoud kunnen worden bewaard, in plaats van als losse afbeelding die later moeilijk te wijzigen is.

Lees meer over wat Marp Markdown mogelijk maakt.

Markdown mode is bedoeld voor gebruikers die direct in de tekstbron van een deck willen werken. Dat kan handig zijn voor zoeken en vervangen, snelle tekstwijzigingen of technische controle.

Je hoeft Markdown mode niet altijd te gebruiken. De gestructureerde editors blijven er voor wie liever per slide werkt.

Lees ook Wat is Marp?.

OciDeck bevat een optionele MIAUW-pentestmodule. Die module is bedoeld voor rapportages volgens de Methodiek voor Informatiebeveiligingsonderzoek met Auditwaarde.

Denk aan finding-slides, samenvattingen, checklists, scope-overzichten en ondersteuning bij rapportage. De module staat standaard uit en is bedoeld voor situaties waarin MIAUW echt relevant is.

Lees meer op Features van OciDeck en Wat is MIAUW?.

Offline HTML-export betekent dat een presentatie als zelfstandige HTML-versie kan worden meegenomen of gedeeld, zonder dat er tijdens het tonen netwerktoegang nodig is.

Dat is handig voor trainingen, demonstraties en omgevingen waar je niet afhankelijk wilt zijn van cloudpresentaties of externe diensten.

Lees meer op Features van OciDeck.

Ja. OciDeck ondersteunt presenteren met onder meer fullscreen weergave, toetsenbordnavigatie, timer, notities, rehearsal mode en dual-screen presenter.

Dat maakt OciDeck niet alleen een editor, maar ook een hulpmiddel voor het daadwerkelijk geven van presentaties.

Lees meer op Features van OciDeck.

Ja. OciDeck kan werken met sprekersnotities en aparte notities voor deelnemers.

Dat is nuttig omdat niet alle informatie op de slide zelf hoeft te staan. Een spreker kan extra context hebben, terwijl deelnemers juist een nette samenvatting of verwijzing nodig hebben.

Lees meer op Features van OciDeck.

Ja. OciDeck kan Nextcloud/WebDAV gebruiken als bron voor OciDeck-pakketten en Marp Markdown-decks.

Dat past bij organisaties die documenten liever in eigen beheer of in een eigen samenwerkingsomgeving bewaren.

Lees meer op Features van OciDeck.

OciDeck is gericht op een toegankelijke interface, met onder meer toetsenbordbediening, screenreaderlabels, tekstschaal en aankondigingen bij slidewissels.

Toegankelijkheid gaat ook over structuur. Omdat slides uit echte inhoud bestaan, is het makkelijker om die inhoud begrijpelijk en controleerbaar te houden.

Lees meer op Features van OciDeck.