Welke software zit er in uw software?

Vrijwel elk kwetsbaarheidsincident van de afgelopen jaren begon bij een component die ooit door iemand was toegevoegd en waarvan later niemand meer wist dat hij erin zat. Niet bij zelfgeschreven code, maar bij een bibliotheek die met een bibliotheek meekwam.

Dat maakt de vraag 'gebruiken wij dit?' tot de belangrijkste van de eerste uren na een melding. Organisaties die het antwoord binnen een uur hebben, kunnen gericht handelen. Organisaties die het niet weten, moeten alles nalopen of maar hopen.

Inmiddels staat de eis om dit inzichtelijk te maken ook in standaardvoorwaarden voor ICT-inkoop, en zakelijke afnemers vragen er in vragenlijsten naar. Het is dus niet langer alleen een goed idee.

• Welke onderdelen van derden zijn gebruikt, met naam en versie.
• Waar die vandaan komen en onder welke licentie ze staan.
• Welke onderdelen op hun beurt weer andere onderdelen meebrengen.
• Wanneer het overzicht is gemaakt, want een lijst van vorig jaar zegt weinig.

Een gemiddelde applicatie brengt via een handvol bewust gekozen bibliotheken al snel enkele honderden onderdelen mee. Vrijwel niemand heeft die individueel gekozen; ze kwamen mee omdat iets anders ze nodig had.

Dat is op zichzelf geen probleem — het is precies waarom software tegenwoordig snel te bouwen is. Het wordt een probleem op het moment dat er in een van die honderden iets wordt gevonden en niemand kan zeggen of het meekwam.

Daar komt bij dat het beeld verandert bij elke oplevering. Een overzicht is dus niet iets wat u één keer maakt, maar iets wat automatisch met elke versie meekomt.

Wie een moderne webapplicatie opent en de gebruikte onderdelen laat opsommen, komt zelden onder de vijfhonderd uit. Daarvan zijn er misschien twintig bewust gekozen; de rest kwam mee omdat iets anders ze nodig had, en die weer iets anders.

Dat is geen teken van slordigheid. Het is hoe software tegenwoordig gemaakt wordt, en het is de reden dat u vandaag in weken iets krijgt waar tien jaar geleden maanden voor stonden.

Het maakt de vraag alleen wel onmogelijk om uit het hoofd te beantwoorden. Iedere leverancier die zonder te kijken zegt dat een bepaald onderdeel er niet in zit, gokt — en dat is precies waarom het overzicht geautomatiseerd moet worden gemaakt.

Voor software die u zelf laat bouwen, is dit gereedschapswerk: er bestaan hulpmiddelen die zo'n overzicht genereren bij elke oplevering, in een gangbaar formaat. Dat kost eenmalig een halve dag om in te richten en daarna niets.

Voor software die u inkoopt, vraagt u het op. Reken erop dat u het niet altijd meteen krijgt: veel leveranciers hebben het zelf nog niet, en dat is geen kwade wil maar achterstand. Vraag in dat geval om een termijn.

Wat u niet wilt is een lijst in een tekstdocument die iemand met de hand heeft gemaakt. Die is bij de eerste oplevering al verouderd en geeft een gevoel van zekerheid dat er niet is.

• Zoek in het overzicht of het onderdeel voorkomt, en in welke versie.
• Bepaal of de kwetsbare functie bij u daadwerkelijk wordt gebruikt — niet elk lek raakt elke gebruiker.
• Vraag uw leverancier binnen welke termijn hij bijwerkt, en of er tussentijds een maatregel is.
• Leg vast wat u heeft geconstateerd en wat u heeft besloten, ook als de conclusie is dat u niet geraakt wordt.

Een kwetsbaarheid in een breed gebruikt onderdeel wordt meestal op een woensdagmiddag bekend, en dan begint overal hetzelfde rondje: gebruiken wij dit? Organisaties met een actueel overzicht hebben het antwoord in minuten. De rest belt leveranciers die het ook niet weten.

Dat verschil is niet academisch. In de uren tussen bekendmaking en de eerste misbruikpogingen zit de ruimte om iets te doen. Wie die uren besteedt aan uitzoeken óf het speelt, heeft ze niet meer om het op te lossen.

Het is bovendien het moment waarop u merkt of uw leverancier dit op orde heeft. Een leverancier die uit zichzelf laat weten dat hij het heeft nagekeken en wat de uitkomst is, hoeft u dat jaar verder weinig te bewijzen.

Naast veiligheid heeft zo'n overzicht een tweede nut dat vaak onopgemerkt blijft: het maakt zichtbaar onder welke voorwaarden u die onderdelen gebruikt. De meeste open-source-licenties zijn ruim en leggen u weinig op. Een aantal legt verplichtingen op die kunnen doorwerken naar de code die u eromheen bouwt.

Dat wordt zelden een probleem, maar als het er een is, is het er een van formaat: het kan betekenen dat u code moet vrijgeven die u als eigen bezit beschouwde. Dat wilt u weten voordat u iets bouwt, niet nadat een klant ernaar vraagt.

Voor een overzicht dat automatisch wordt gegenereerd, is dit meestal een kwestie van één keer doorlopen en een handvol uitzonderingen beoordelen. Zonder overzicht is het een zoektocht van dagen.

• De leverancier levert bij elke oplevering een actueel overzicht van gebruikte componenten mee.
• Het overzicht staat in een gangbaar, machineleesbaar formaat.
• Het bevat de licentie per onderdeel.
• Bij een gemelde kwetsbaarheid laat de leverancier binnen een afgesproken termijn weten of het geleverde geraakt wordt.
• Het bijwerken van componenten met bekende kwetsbaarheden valt binnen het onderhoud.

Het meest onderschatte voordeel is dat u ziet hoe verouderd uw software werkelijk is. Een lijst met componenten en hun leeftijd vertelt binnen vijf minuten of er structureel wordt bijgewerkt of dat er alleen wordt bijgebouwd.

Dat is bruikbare informatie bij een verlenging, bij een leverancierswissel en bij de vraag of een systeem nog jaren mee kan. Het is bovendien een gesprek dat u kunt voeren op basis van feiten in plaats van indrukken.

En het maakt de kwaliteitsvraag concreet. In plaats van te vragen of er goed wordt onderhouden, vraagt u hoeveel van de gebruikte onderdelen ouder zijn dan twee jaar. Dat is een getal, en over getallen valt beter te praten.

Begin bij het systeem waar de meeste gegevens in zitten of dat het langst meegaat. Daar is het antwoord het meest waard en daar is de kans op verouderde onderdelen het grootst.

Vraag het op, en behandel het antwoord niet als een afvinkpunt maar als informatie. Kijk hoe oud de onderdelen zijn, of er licenties tussen zitten die opvallen, en of het overzicht automatisch is gegenereerd of met de hand.

Neem het daarna op in uw standaardvragen bij nieuwe opdrachten. Vanaf het begin gevraagd kost het een leverancier weinig; achteraf gevraagd kost het hem dagen en u een discussie.

• Hoe snel moet een kwetsbaarheid gedicht zijn?
• Wat een auditor wil zien
• Software in beheer nemen

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.