Een moderne applicatie bestaat vaak voor wel 80% tot 90% uit open-source componenten. Wat u als ontwikkelaar zelf expliciet toevoegt aan uw project (de directe afhankelijkheden), is slechts het topje van de ijsberg.
Zodra u één ogenschijnlijk simpele library toevoegt, trekt deze vaak zijn eigen set aan benodigdheden mee. Die libraries hebben op hun beurt óók weer afhankelijkheden. Dit kettingreactie-fenomeen noemen we transitieve afhankelijkheden. Een simpel project met 5 directe libraries explodeert al snel tot een web van 500+ geneste componenten.
Het gevaar onder water
Een SBOM die alleen de "directe" ingrediënten laat zien, geeft een vals gevoel van veiligheid. De ware complexiteit bevindt zich diep onder de wateroppervlakte:
- Patchen is een logistieke nachtmerrie: Als er een ernstige kwetsbaarheid (CVE) wordt gevonden in laag 4 van uw ijsberg, kunt u die niet zomaar zelf met één druk op de knop updaten. U bent afhankelijk van de makers van de libraries in laag 3, 2 en 1.
- Dependency Confusion: Hoe groter en ondoorzichtiger de boom van afhankelijkheden wordt, hoe makkelijker het is voor aanvallers om ergens diep in de structuur een malafide pakket te verstoppen met een vergelijkbare naam.
- De Blinde Vlek (API's en SaaS): Een applicatie bestaat zelden alléén uit code. Hoe zit het met afhankelijkheden van cloud-diensten of SaaS-betaalproviders? Als een cruciale externe API wordt gecompromitteerd, loopt uw applicatie net zo goed gevaar.
Van lezen naar doen
Benieuwd hoe ver úw organisatie is met de CRA? Test het in twee minuten met de gratis Quickscan, of verdiep u in de 4-weekse Survival Challenge.