Stel, je runt een softwarehuis en in dat verband ben je de maker van een standaard softwareapplicatie. Voordat je het product op de markt brengt, onderwerp je het vanzelfsprekend aan een reeks gedegen functionele en technische testen. Je wenst immers een product aan de man te brengen dat door afnemers zonder onaanvaardbare risico’s kan worden gebruikt. Ernstige gebreken moeten nog voor ingebruikname worden blootgelegd en worden verholpen. De testen die jij als producent van het pakket in eigen huis uitvoert, kunnen worden onderscheiden van de acceptatietest die afnemers niet zelden zelf uitvoeren alvorens ze de aangeschafte software in hun productieomgeving inzetten.
In het streven zo veilig mogelijke software te maken en te exploiteren, wensen makers van software hun nieuwe producten of updates op bestaande producten steeds vaker ook te testen op security. Decennialang waren securitytesten een tamelijk ondergeschoven kindje in softwareland, maar die tijd ligt inmiddels goeddeels achter ons. Softwareproducenten schakelen – vaak op eigen initiatief, maar soms ook onder druk van hun (toekomstige) afnemers – externe specialisten in om het product te onderwerpen aan een of meer penetratietesten. Zoiets kan vanuit een security-optiek natuurlijk alleen maar worden toegejuicht. De bevindingen van een penetratietest kunnen worden gebruikt om zwakheden in de security aan het daglicht te brengen en om vervolgens tot correctieve stappen over te gaan.
Old school
Het is in juridische zin al snel ‘old school’ wanneer je als softwareproducent de jou bekende kwetsbaarheden in jouw product onder de pet houdt en die kennis niet met jouw afnemers deelt. De zorgplicht die je tegenover de afnemers en gebruikers van jouw product hebt, noopt in het algemeen tot een vergaande open opstelling. Doe je dat niet, dan ga je juridisch mogelijk al snel de fout in.
Softwareontwikkelaars schakelen mij nogal eens in om juridisch te adviseren over een voorgenomen penetratietest op hun producten. Aan een dergelijke test zitten talloze voetangels en klemmen, die je goed voor ogen moet houden voordat je met zo’n test begint. Als onderdeel van mijn advisering sta ik doorgaans diepgaand stil bij de volgende vraag: ben je als softwaremaker bereid om de resultaten van de penetratietest echt serieus te nemen en alle geconstateerde vulnerabilities de wereld uit te helpen? Het antwoord van serieuze softwaremakers is daarop zonder enig voorbehoud ‘ja’. Wie A zegt moet ook B zeggen, is dan de gedachte. Terecht.
Juridische risico’s
Maar sommigen geven op die vraag slechts een vaag of ontwijkend antwoord. ‘Dat hangt er vanaf wat het werk gaat kosten’, of ‘we zullen eerst nog functionaliteit moeten ‘bouwen’ en dan pas kijken we of we nog tijd over hebben voor eventuele kwetsbaarheden’. Softwaremakers die zo terughoudend in de wedstrijd zitten, wijs ik dan op de forse juridische risico’s van de penetratietest.
Aan welk risico moet je dan zoal denken? Sinds jaar en dag geldt er in het Nederlandse recht de spelregel dat een leverancier die een product in de markt zet waarvan hij weet dat het behept is met een gebrek, niet met succes de aansprakelijkheidsbeperkingen die in het contract met afnemers zijn afgesproken uit de kast kan trekken. Softwareleveranciers hebben in hun standaardcontracten of hun algemene voorwaarden dikwijls een bepaling opgenomen die zegt dat de leverancier tegenover de afnemer slechts in beperkte zin aansprakelijk is voor schade die de afnemer lijdt vanwege een gebrekkig softwareproduct. De aansprakelijkheid van de leverancier kan volgens zo’n bepaling bijvoorbeeld tot een maximum aantal euro’s zijn gelimiteerd.
Op de blaren
Hoewel dat in verhoudingen met zakelijke afnemers algemeen gesproken geldige contractsbepalingen zijn, komen die beperkingen niettemin volledig in de lucht te hangen wanneer je als leverancier weet dat je een gebrekkig product levert. En dat is wat een penetratietest nu precies doet: de resultaten van de test scheppen kennis en wetenschap rondom kwetsbaarheden en met het oog op het aansprakelijkheidsrisico van de leverancier is die kennis en wetenschap dus zeker niet neutraal. Wie A zegt, maar B niet accepteert, moet zelf op de blaren zitten.
Kortom, de makers van software die de resultaten van een penetratietest geheel of gedeeltelijk aan hun laars lappen, stellen zich bloot aan het risico van ongelimiteerde aansprakelijkheid. Dat risico poets je dus niet weg met wat mooie volzinnen in een contract. Afspraken sneuvelen dan al snel.
Deze bijdrage is geschreven door IT-jurist Mr. Peter van Schelven van BIJ PETER – Wet & Rechten verscheen ook op Security Vandaag.