Een flink aantal jaar geleden hoorde ik voor het eerst van OWASP: de Open Web Application Security Project. Ze zijn met name bekend geworden met hun top-10: een lijst met tien risicovolste kwetsbaarheden die in web applicaties aangetroffen worden. Deze lijst heeft tot doel om het bewustzijn te vergroten binnen organisaties en vooral binnen ontwikkelteams. Maar ze doen veel meer dan het publiceren en onderhouden van deze top-10.

Ze ontwikkelen verschillende applicaties en tools op het gebied van security. De OWASP Dependecy Checker is daar een voorbeeld van. Deze stelt je in staat om van alle dependencies van je project te controleren of er kwetsbaarheden bekend zijn in de NVD (Nationale Kwetsbaarheden Database) en wat deze inhouden. En naar welke versie je moet upgraden om er niet meer vatbaar voor te zijn. Tot voor kort heb ik geen inspanning gedaan om de afhankelijkheden van mijn projecten gestructureerd tegen het licht te houden. Het gebruik van dependencies met bekende kwetsbaarheden staat overigens op plek 9 in de OWASP top-10 van 2017.

Tijdens Devoxx Antwerpen afgelopen november zag ik deze presentatie van Julien Topçu getiteld: “Find and Track the hidden vulnerabilities inside your dependencies”. En ik was verkocht. Hoe is het mogelijk dat ik een dergelijke belangrijke tool niet eerder ingezet heb in onze buildstraat? Thuisgekomen ben ik meteen gaan experimenteren met de eenvoudigste, eerste stap: laat de maven plugin maar eens zien welke vulnerabilities er in onze dependencies zitten. Documentatie over de plugin was wat lastig te vinden, maar even doorzetten, en dan vindt je wel het een en ander. Proefondervindelijk kwam ik erachter dat versie 4.x bedoeld is voor gebruik met Java 8 en nieuwer, terwijl 3.x draait op oudere Java versies. En je hebt internet nodig in je buildstraat, want de plugin gaat periodiek de NVD downloaden.

Het inzetten van de plugin blijkt een appeltje en een eitje, het echte werk zit erin om vast te stellen in hoeverre jouw software geraakt wordt door een gevonden veiligheidsprobleem. Je moet de kwetsbaarheid analyseren en inschatten hoe een hacker hier misbruik van kan maken. Het is niet ondenkbaar dat je dit verkeerd inschat. Het heeft daarom mijn voorkeur om elke kwetsbare dependency op te waarderen naar een versie, indien beschikbaar, waarin dit is opgelost. Dit kan aanpassingen aan je eigen code vergen, wanneer de nieuwe versie API wijzigingen heeft.

Dependency checker probeert van elke dependency de naam, leverancier en versie te bepalen. De manier waarop dit gebeurt kan fouten opleveren. Ik heb bij een klant gemerkt dat een aantal bibliotheken, die het bedrijf zelf maakt en alleen intern distribueert, herkent werden als een open source dependency die kwetsbaarheden bevat. Een ‘false positive’ dus. Je kunt aan de maven plugin een lijst met deze ‘false positives’ doorgeven, om het proces te helpen. Via het HTML rapport dat dependency checker oplevert, kun je van een false positive eenvoudig een entry genereren voor deze lijst.

Wanneer je de tool nieuw inzet op een project en je een achterstand hebt weggewerkt aan gevonden kwetsbare dependencies, is het zaak om na te denken hoe je deze tool structureel wilt inzetten in je buildstraat. Hou er rekening mee dat deze plugin bij multi module projecten al snel enkele minuten aan de feedbackloop toe zal voegen. Daarnaast moet je je realiseren dat de aangetroffen kwetsbaarheden niet alleen afhankelijk zijn van de dependencies die het project gebruikt, maar ook van de bugs die in de NVD gepubliceerd worden. Dit kan er voor zorgen dat kwetsbaarheden in legacy applicaties, waar slechts incidenteel onderhoud aan gepleegd wordt, lang onopgemerkt kunnen blijven. Het is daarom raadzaam om de dependency check voor ieder project dagelijks in een eigen job te draaien.

Vooral bij grotere organisaties komt het voor dat de gevonden kwetsbaarheden buiten het ontwikkelteam gerapporteerd moeten worden, bijv. aan een security afdeling. Als het team inschat dat de gevonden kwetsbaarheid in de dependency op geen enkele manier misbruikt kan worden, dan wil de security afdeling deze argumentatie ook weten. Voor deze administratie kan gebruik gemaakt worden van de applicatie Dependency-Track of via een SonarQube plugin. Allebei zijn Open Source projecten van OWASP.

Als jouw project nog geen tooling gebruikt om haar afhankelijkheden te controleren op bekende kwetsbaarheden uit de NVD database, dan raad ik aan om OWASP dependency checker zeker uit te proberen. “Protect yourself at all times” is altijd goed advies.