Moderne softwarepakketten zijn veiliger dan ooit tevoren, dankzij de vooruitgang op het gebied van cyberbeveiliging. Ze worden echter ook geconfronteerd met de meest geavanceerde bedreigingen, waardoor ze net zo kwetsbaar als veilig zijn. Supply chain-aanvallen zoals Zonnewinden en ernstige kwetsbaarheden zoals Log4Shell behoren tot de nieuwste bedreigingen waarmee softwaresystemen vandaag de dag worden geconfronteerd. Dergelijke aanvallen op de toeleveringsketen van software hebben een dynamisch effect en zijn moeilijker te navigeren, omdat ze misbruik maken van kwetsbaarheden in systemen die buiten uw directe controle liggen.
De eerste stap bij het bestrijden van dergelijke aanvallen op de toeleveringsketen van software is echter het hebben van duidelijke kennis van de pakketten, afhankelijkheden en componenten die in uw software zijn opgenomen. Daarom is het belangrijk om een Software Bill of Material (SBOM) voor uw build te genereren. Het vergroot niet alleen de zichtbaarheid van kwetsbaarheden in de softwaretoeleveringsketen; een SBOM is ook belangrijk geworden voor compliancedoeleinden. Het genereren van SBOM is verplicht gesteld door een recente uitvoerend bevel uitgevaardigd door de Amerikaanse federale overheid om de cyberbeveiliging te verbeteren en de authenticiteit te garanderen van componenten van derden die in softwarepakketten worden gebruikt.
Volgens een Gartner Volgens de voorspelling zal 60% van de organisaties die verantwoordelijk zijn voor de ontwikkeling van kritieke infrastructuursoftware tegen 2025 gestandaardiseerde SBOM's nodig hebben. Het creëren van een SBOM begint met het selecteren van een tool die aansluit bij de normen en doelstellingen van uw organisatie, waarbij de fases van de softwareontwikkelingslevenscyclus worden bepaald waarin moet worden gewerkt. pas de SBOM toe, bevestig dat deze aan het formaat voldoet en voer een kwetsbaarheidsscan uit. Het genereren van een SBOM is een delicaat en ingewikkeld proces. In dit artikel wordt besproken wanneer het genereren van SBOM nodig is en hoe u dit voor uw software kunt genereren.
Wanneer moet u een softwarestuklijst genereren?
Het genereren van een Software Bill of Materials (SBOM) is essentieel voor het beveiligen van uw softwarebuilds en uw gehele softwaretoeleveringsketen. Het genereren van SBOM kan worden geïntegreerd in verschillende fasen van het bouwproces van uw software. U kunt een stuklijst genereren met behulp van de broncode tijdens de bouwtijd, tijdens runtime of terwijl u forensisch onderzoek doet naar de software. Van dit alles raden experts aan om tijdens de bouwtijd een SBOM te genereren. Dat komt omdat SBOM-generatoren tijdens het bouwen nauwkeuriger zijn en een completere lijst met afhankelijkheden genereren. Omdat dit echter niet altijd praktisch is, kan de SBOM op elk ander moment tijdens de DevOps-levenscyclus worden gegenereerd.
Het is vermeldenswaard dat het type tool voor het genereren van SBOM dat moet worden gebruikt, afhangt van de fase in de DevOps-levenscyclus waarin de SBOM-documentatie wordt gegenereerd. Hieronder volgen de verschillende fasen waarin SBOM's kunnen worden gegenereerd tijdens de levenscyclus van de build. Elke periode heeft verschillende voordelen en afwegingen. Het is het beste om de doelgroep en de use-case te begrijpen voor de SBOM-gegevens die u genereert en een aanpak te kiezen die voor u het beste resultaat oplevert.
In de broncodefase
Door de artefacten en eventuele bijbehorende bronnen zoals manifesten, metadata en lock-bestanden te onderzoeken, genereren bron- of binaire tools een Software Bill of Materials in de broncodefase. In dit stadium kunt u een analyse van softwarecomponenten of een binaire analyse van uw software uitvoeren.
Een SCA-tool (softwarecomponentanalyse) is ontworpen om een stukje software en de bijbehorende manifestbestanden te analyseren om de componenten ervan te bepalen. Binaire analysetools analyseren daarentegen de metagegevens van de software en bouwen artefactinformatie op om een SBOM te genereren. Voorbeelden van analysetools die in deze fase worden gebruikt, zijn CycloneDX, It-Depends, Fossa, AppSonar, Cybellum, Black Duck en Fortress.
U kunt een kwetsbaarheidsanalysator gebruiken in combinatie met een SBOM die in de broncodefase is gegenereerd om vroegtijdig waarschuwingen over kwetsbaarheden te ontvangen in de software die wordt gebouwd. Er zijn echter beperkingen aan de SBOM's die in dit stadium worden gegenereerd. Ten eerste zijn ze niet compleet, omdat de informatie die tijdens het bouwen met afhankelijkheid wordt gegenereerd vaak ontbreekt. Bovendien kunnen ze informatie bevatten over componenten die niet zijn gebruikt in het uiteindelijk geïmplementeerde product.
Tijdens de bouwtijd
Door de SBOM tijdens het bouwen te maken met een tool die gebruik maakt van het bouwsysteem, beschikt u over de meest exacte kennis van wat er in een binair bestand past, inclusief transitieve en niet-vastgezette afhankelijkheden. Dit wordt ondersteund door de NTIA-onderzoek naar de SBOM-productie en -levering van softwareleveranciers.
De NTIA raadt aan om voor elke nieuwe componentrelease een SBOM te maken. Dit betekent dat u elke keer dat u een nieuwe versie van uw software bijwerkt of vrijgeeft, een nieuwe SBOM moet maken. Leveranciers zijn ook verplicht nieuwe SBOM's te maken wanneer ze een fout in de vorige ontdekken of nieuwe informatie over hun softwarecomponenten te weten komen die nog niet eerder was gedocumenteerd.
Voor het genereren van uw SBOM tijdens de bouwtijd wordt gebruik gemaakt van een plug-in die werkt met de oorspronkelijke omgeving waarmee u uw software bouwt. De meeste ontwikkelomgevingen hebben plug-ins die integreren met het afhankelijkheidsbeheersysteem om automatisch een SBOM te genereren. Voorbeelden van build-time SBOM-generatoren zijn SPDX, de CycloneDX Maven-plug-in en OWASP's Dependency-Track-Check.
Hoewel Build-time SBOM-generatoren het meest uitgebreid en nauwkeurig zijn, zijn ze moeilijker in te stellen vergeleken met andere methoden. Bovendien werkt deze methode niet voor sommige buildsystemen en kunt u deze methode niet gebruiken voor oudere producten.
SBOM genereren tijdens runtime
Een SBOM-generator die tijdens runtime werkt, is ontworpen om de bibliotheken vast te leggen die de software, app-server of plug-ins tijdens runtime gebruiken. Dit type generator geeft ook details over alle services die door de software worden aangeroepen, evenals de poorten en actieve bibliotheken waartoe deze toegang heeft. Deze methode voor het genereren van SBOM's is echter niet algemeen beschikbaar. Bovendien bestaat er geen duidelijke workflow voor het samenvoegen van de gegevens die met deze methode zijn gegenereerd, met de originele SBOM-documentatie. Jbom en ThreatMapper zijn voorbeelden van runtime SBOM-generatoren.
Een softwarestuklijst genereren: een stapsgewijze handleiding
Het handmatig genereren van een softwarestuklijst is tijdrovend en vervelend voor ontwikkelaars. Het op deze manier opsommen van alle componenten van een softwareprogramma is meestal onpraktisch. Er zijn nu echter talloze tools voor het genereren van SBOM beschikbaar die dit proces vereenvoudigen. Hoe u dit kunt doen, hangt af van de normen van uw organisatie en wanneer u uw SBOM wilt genereren tijdens de ontwikkelingslevenscyclus.
Door SBOM-workflows te integreren in softwareontwikkelingspijplijnen, kunt u het SBOM-proces automatiseren. Het Scribe-platform is zo'n tool die de manier vereenvoudigt waarop u uw softwarestuklijst maakt. Met Scribe kunt u uw SBOM vanaf één plek beheren en delen. Op deze manier kunt u de integriteit van uw softwarecomponenten valideren en kwetsbaarheden in de softwarepijplijn naadloos volgen. Dit gedeelte is een stapsgewijze handleiding voor het genereren van softwarestuklijsten met Scribe.
Stap 1: Registreer en log in bij Scribe Trust Hub.
Voordat u begint, moet u weten dat het Scribe-platform een webinterface heeft – Scribe Trust Hub – die toegankelijk is vanuit uw browser. De Scribe-bewijsverzamelaar werkt echter alleen op Linux- en Mac-apparaten. Om een integriteitsrapport en SBOM met Scribe te genereren, moet u toestemming hebben om het buildscript van uw project te wijzigen en het relevante codefragment toe te voegen dat nodig is om uw project met Scribe te verbinden. Houd er rekening mee dat hoewel Scribe SBOM's kan genereren voor projecten die zijn geschreven in elke programmeertaal die een containerimage genereert, de huidige release alleen werkt voor Node.js-projecten.
De eerste stap voor het integreren van Scribe in uw project is registreren op Scribe Trust Hub. Nadat u zich heeft geregistreerd en ingelogd, navigeert u naar het tabblad “Producten” en klikt u op Configuratie. Scribe heeft op deze pagina een demoproduct waarmee u kunt communiceren om het platform onder de knie te krijgen en hoe het werkt.
Stap 2: Integreer Scribe Trust Hub
De volgende stap is om Scribe te verbinden met de Continuous Integration Pipeline van uw project. Dit automatiseert het SBOM-generatieproces. Over het algemeen kunt u codefragmenten van Scribe Trust Hub toevoegen aan twee punten in uw CI-pijplijn. U kunt de code plaatsen bij het afrekenen van de broncode of bij de uiteindelijk gebouwde afbeelding. De eerste optie wordt aanbevolen maar is niet verplicht, terwijl de tweede optie verplicht is.
De CI-installatie van Scribe werkt momenteel alleen voor Jenkins via Kubernetes en GitHub Actions. Het proces van het integreren van Scribe voor deze CI-opstellingen is vergelijkbaar. U heeft de volgende inloggegevens nodig op de instellingenpagina van uw Scribe Hub-product om aan de slag te gaan:
- Product sleutel
- klant-ID
- Cliëntgeheim
De productsleutel varieert van product tot product, terwijl de klantreferenties uniek zijn voor uw account.
CI-integratie voor Jenkins opzetten
Om CI-integraties voor Jenkins in te stellen, kunt u het codefragment toevoegen om “Gensbom” (de tool van Scribe Trust Hubs voor het verzamelen van bewijsmateriaal en het genereren van SBOM's) aan te roepen bij het afrekenpunt en/of na het maken van een Docker-image.
Begin met het toevoegen van de bovenstaande inloggegevens aan uw bouwomgeving volgens de unieke instructies voor Jenkins. Voeg vervolgens het codefragment toe aan uw pijplijn volgens de instructies hier.
CI-integratie voor GitHub-acties instellen
Het proces voor het opzetten van CI-integratie voor GitHub Actions is vergelijkbaar met dat van Jenkins. Het belangrijkste idee is om de bewijsverzamelaar en SBOM-generator van Scribe bekend te maken als “Gensbom”. Om aan de slag te gaan, volgt u de GitHub-instructies om inloggegevens voor productconfiguratie en het codefragment toe te voegen aan de pijplijn volgens de instructies hier
Integratie van Scribe Trust Hub met andere CI-systemen
Hoewel Scribe alleen native ondersteuning biedt voor Jenkins- en GitHub-acties, kun je het mogelijk ook voor andere CI-systemen gebruiken. Download om te beginnen de tool "Gensbom" vanaf uw Unix-gebaseerde opdrachtregelinterface. Voeg vervolgens uw product- en klantgegevens toe en roep vervolgens Scribe gensbom aan vanuit uw build-script, hetzij bij het afrekenen, hetzij na de uiteindelijke gebouwde afbeelding.
Stap 3: Het genereren van de softwarestuklijst
De gensbom CLI-tool van Scribe genereert de Software Bill of Materials (SBOM) voor Docker en Open Containers Images (OCI). Deze tool werkt alleen op Mac- of Linux-systemen. De uiteindelijke SBOM die door Scribe wordt gegenereerd, is in het CycloneDX JSON-formaat, een van de standaardmachines en door mensen leesbare formaten die worden herkend voor SBOM's. De open containerimages kunnen worden geëxtraheerd uit Docker, een lokale schijf of een extern register, afhankelijk van het geval.
Hoewel er standaardinstellingen zijn voor de naam, map en pad van de afbeelding waaruit de SBOM wordt gegenereerd, is het mogelijk om deze standaardinstellingen desgewenst dienovereenkomstig te wijzigen.
Stap 4: SBOM exporteren
Met Scribe Trust Hub kunt u uw softwarestuklijst ook naadloos exporteren en delen als onderdeel van het validatieproces van uw software. De SBOM wordt gegenereerd in het CycloneDX JSON-rapportageformaat en beschrijft alle open-source afhankelijkheden van de geanalyseerde Docker-image. Nadat de SBOM is gegenereerd, kunt u deze met één klik exporteren. Rechtsboven in het rapport vindt u de knop 'SBOM exporteren'. Klik erop om uw softwarestuklijsten te exporteren.
Conclusie
Het genereren van een softwarestuklijst wordt een steeds belangrijker stap voor het beveiligen van uw softwaretoeleveringsketen en ook voor compliancedoeleinden. Ongeacht uw redenen voor het genereren van een SBOM, u zult Scribe Trust Hub een gebruiksvriendelijke en flexibele manier vinden om de workflow voor het genereren van SBOM's voor elk van uw softwarebuilds te automatiseren.