De verhoogde regelgevende en juridische druk op softwareproducerende organisaties om hun toeleveringsketens te beveiligen en de integriteit van hun software te waarborgen, mag geen verrassing zijn. De afgelopen jaren is de softwaretoeleveringsketen een steeds aantrekkelijker doelwit geworden voor aanvallers die mogelijkheden zien om hun aanvallen met ordes van grootte te vermenigvuldigen. Zoek bijvoorbeeld niet verder dan de Log4j-inbreuk van 2021, waarbij Log4j (een open-source logframework onderhouden door Apache en gebruikt in een groot aantal verschillende applicaties) de oorzaak was van exploits die duizenden systemen in gevaar brachten.
De communicatiefunctionaliteit van Log4j was kwetsbaar en bood dus een opening voor een aanvaller om kwaadaardige code in de logs te injecteren, die vervolgens op het systeem kon worden uitgevoerd. Na de ontdekking zagen beveiligingsonderzoekers miljoenen pogingen tot exploits, waarvan er vele uitmondden in succesvolle Denial-of-Service (DoS)-aanvallen. Volgens een aantal van de laatste onderzoeken van Gartner zal in 2025 bijna de helft van de ondernemingen het doelwit zijn geweest van een software supply chain-aanval.
Maar wat is de software supply chain? Om te beginnen wordt het gedefinieerd als de som van alle code, mensen, systemen en processen die bijdragen aan de ontwikkeling en levering van softwareartefacten, zowel binnen als buiten een organisatie. En wat het beveiligen van de softwaretoeleveringsketen zo uitdagend maakt, is de complexe en sterk gedistribueerde aard van het ontwikkelen van moderne applicaties. Organisaties hebben wereldwijde teams van ontwikkelaars in dienst die vertrouwen op een ongekend aantal open source-afhankelijkheden, samen met een breed scala aan codeopslagplaatsen en artefactregisters, CI/CD-pijplijnen en infrastructuurbronnen die worden gebruikt voor het bouwen en implementeren van hun applicaties.
En hoewel beveiliging en compliance consequent een topprioriteit zijn voor bedrijfsorganisaties, wordt de uitdaging van het beveiligen van de softwaretoeleveringsketens van de organisatie steeds groter. Veel organisaties boeken materiële vooruitgang met het operationeel maken van DevSecOps-praktijken, maar een groot deel van hen bevindt zich nog in de beginfase van het uitzoeken wat ze moeten doen.
Dat is precies waarom we dit artikel hebben samengesteld. Hoewel het volgende geenszins een uitputtende lijst is, volgen hier vier leidende principes om de beveiligingsinspanningen van uw softwaretoeleveringsketen in de goede richting te krijgen.
Houd bij het toepassen van beveiliging rekening met alle aspecten van uw softwaretoeleveringsketen
Aangezien meer dan 80% van de codebases ten minste één open-source kwetsbaarheid heeft, is het logisch dat OSS-afhankelijkheden een centrale focus zijn geweest van software supply chain-beveiliging. Moderne software supply chains omvatten echter andere entiteiten waarvan de beveiligingshoudingen over het hoofd worden gezien of niet breed genoeg worden begrepen binnen de organisatie om goed te worden beheerd. Deze entiteiten zijn code repositories, CI- en CD-pipelines, infrastructuur en artefactregisters, die elk beveiligingscontroles en regelmatige nalevingsbeoordelingen vereisen.
Frameworks zoals OWASP Top-10 voor CI/CD en CIS Software Supply Chain Security Benchmark. Het naleven van deze raamwerken vereist gedetailleerde RBAC, het toepassen van het principe van de minste privileges, het scannen van containers en infrastructuur-als-code op kwetsbaarheden en misconfiguraties, het isoleren van builds, het integreren van applicatiebeveiligingstests en het juiste beheer van geheimen – om er maar een paar te noemen.
SBOM’s zijn essentieel voor het oplossen van zero-days en andere componentproblemen
Een deel van Executive Order 14028, medio 2021 uitgevaardigd door het Witte Huis om de cyberbeveiligingspositie van het land te versterken, schrijft voor dat softwareproducenten hun federale klanten voorzien van een software stuklijst (SBOM’s). SBOM’s zijn in wezen formele documenten die bedoeld zijn om inzicht te geven in alle componenten waaruit een stuk software bestaat. Ze bieden een gedetailleerde, machinaal leesbare inventaris met een overzicht van alle open source-bibliotheken en bibliotheken van derden, afhankelijkheden en componenten die zijn gebruikt bij het bouwen van de software.
Of een organisatie nu wel of niet verplicht is door EO 14028, het genereren en beheren van SBOM’s voor softwareartefacten is een waardevolle praktijk. SBOM’s zijn een onmisbaar hulpmiddel voor het oplossen van componentproblemen of zero-day-kwetsbaarheden. Wanneer SBOM’s worden opgeslagen in een doorzoekbare repository, bieden ze een kaart van waar een specifieke afhankelijkheid bestaat en stellen ze beveiligingsteams in staat snel kwetsbaarheden terug te traceren naar getroffen componenten.
Beheer de levenscyclus van softwareontwikkeling met beleid-als-code
In de wereld van moderne applicatieontwikkeling zijn ijzersterke vangrails een essentieel hulpmiddel voor het elimineren van fouten en opzettelijke acties die de veiligheid en compliance in gevaar brengen. Een goed bestuur in de hele softwaretoeleveringsketen betekent dat de organisatie het gemakkelijk heeft gemaakt om de goede dingen te doen en extreem moeilijk om de verkeerde dingen te doen.
Hoewel veel platforms en tools kant-en-klaar beleid bieden dat snel kan worden afgedwongen, maakt policy-as-code op basis van de Open Policy Agent-industriestandaard het schrijven en afdwingen van volledig aanpasbaar beleid mogelijk. Beleid dat alles regelt, van toegangsrechten tot het toestaan of weigeren van het gebruik van OSS-afhankelijkheden op basis van criteria zoals leverancier, versie, pakket-URL en licentie.
Verifieer en verzeker het vertrouwen in uw software-artefacten met behulp van SLSA
Hoe kunnen gebruikers en consumenten weten dat een stukje software betrouwbaar is? Om de betrouwbaarheid van een softwareartefact te bepalen, wil je weten wie de code heeft geschreven, wie deze heeft gebouwd en op welk ontwikkelingsplatform deze is gebouwd. Weten welke componenten erin zitten, zou ook iets zijn dat u moet weten.
Het is mogelijk om te beslissen of u software wilt vertrouwen zodra de herkomst – het bewijs van de oorsprong en de keten van bewaring – van de software kan worden geverifieerd. Hiervoor is het Supply Chain Levels for Software Artefacts (SLSA) raamwerk gecreëerd. Het geeft softwareproducerende organisaties de mogelijkheid om informatie vast te leggen over elk aspect van de softwaretoeleveringsketen, de eigenschappen van artefacten en hun constructie te verifiëren en het risico op beveiligingsproblemen te verminderen. In de praktijk is het essentieel voor softwareproducerende organisaties om de SLSA-frameworkvereisten over te nemen en na te leven en een manier te implementeren voor het verifiëren en genereren van softwareattesten, dit zijn geauthenticeerde verklaringen (metadata) over softwareartefacten in hun softwaretoeleveringsketens.
Gezien de omvang en complexiteit van het beveiligen van de moderne software-toeleveringsketen, zijn de bovenstaande richtlijnen slechts een oppervlakkige schets. Maar net als al het andere in de wereld van het bouwen en implementeren van moderne applicaties evolueert de praktijk snel. Om u op weg te helpen, raden wij u aan dit te lezen Hoe u software veilig kunt leveren – een e-boek vol best practices die zijn ontworpen om uw beveiligingspositie te versterken en de risico’s voor uw bedrijf te minimaliseren.
