Dat is daarmee verbonden in een bepaalde softwareapplicatie. Met behulp van SCA-tools wordt de gehele codebase van een applicatie doorzocht om alle open source-bibliotheken en componenten te achterhalen die in de applicatie worden gebruikt, hun versies worden gecontroleerd en ook de bekende kwetsbaarheden voor die componenten worden opgespoord.
Doel van SCA
Het belangrijkste doel van SCA is het beperken van de risico's die voortvloeien uit de integratie van OSS-componenten. Dit zijn; beveiligingsproblemen, gebruik van oude of verouderde bibliotheken/componenten en de noodzaak om zich te houden aan open-sourcelicenties. Op deze manier helpt SCA dergelijke risico's te voorkomen en de juiste softwarebeveiliging en compliance gedurende de gehele levenscyclus van de software te handhaven.
Methodologieën van SCA
SCA-tools maken doorgaans gebruik van de volgende methodologieën:
- Afhankelijkheid scannen: SCA-tools bepalen, op basis van de afhankelijkheden vermeld in de projectbuildbestanden (Maven, npm, Gradle, etc.), de gebruikte open-sourcecomponenten.
- Binaire analyse: Sommige SCA-tools zijn in staat open-sourcecomponenten in gecompileerde binaire bestanden te bepalen.
- Handtekening matching: SCA-tools werken op basis van een database met geïdentificeerde open-sourcecomponenten en hun handtekeningen om binnen de applicatie naar overeenkomsten te zoeken.
- Kwetsbaarheidsdetectie: Alle gevonden elementen worden gekoppeld aan de databases met bekende kwetsbaarheden (bijv. NVD, CVE) voor detectie van beveiligingsbedreigingen door SCA-tools.
Voordelen van SCA
SCA biedt verschillende voordelen voor softwarebeveiligingsbeheer:
- verbeterde beveiliging: SCA voorkomt misbruik van bekende kwetsbaarheden, omdat het de open-sourcecomponenten aanwijst die kunnen worden misbruikt om de applicatie in gevaar te brengen.
- Compliance Management: Met behulp van SCA-tools worden ook open source-licenties nageleefd om juridische problemen te voorkomen.
- Risk Mitigation: SCA-tools geven een risicobeeld van de software zodat er vooraf risicomanagement kan plaatsvinden.
- Continue monitoring: De meeste beschikbare SCA-tools zijn in staat om de open-sourcecomponenten voortdurend te monitoren en de ontwikkelaars te informeren over de nieuwe kwetsbaarheden zodra deze worden gevonden.
Software stuklijst (SBOM) begrijpen
SBOM staat voor Software stuklijst en het is een gedetailleerde lijst van alle componenten, bibliotheken en afhankelijkheden waaruit de softwareapplicatie bestaat. Het bevat informatie over het onderdeel, zoals de naam, de versie, het licentietype en de bron van waaruit het is geïnstalleerd. Een SBOM geeft een momentopname van de softwarecomponenten, wat cruciaal is bij het bepalen van de veiligheid van de software en het beperken van risico's.
Doel van SBOM
Het belangrijkste doel van een SBOM is om licht te werpen op de softwarestuklijst. Een SBOM legt elk onderdeel vast dat in een applicatie is opgenomen, waardoor organisaties inzicht krijgen in hun softwaretoeleveringsketen, risicoprofiel en compliancestatus.
Methodologieën van SBOM
Voor het maken van een SBOM zijn doorgaans de volgende methodologieën nodig:
- Component identificatie: Het definiëren van alle componenten, bibliotheken en afhankelijkheden die deel uitmaken van de software. Beveiliging is een groot probleem, vooral op het gebied van softwareontwikkeling. Om te garanderen dat de software die we ontwikkelen en gebruiken veilig is, is het nodig om de verschillende onderdelen ervan en de risico's die deze met zich meebrengen te begrijpen. Er zijn twee belangrijke instrumenten op dit gebied, namelijk de Software Composition Analysis (SCA) en de Software Bill of Materials (SBOM). Hoewel beide verband houden met de verbetering van de softwarebeveiliging, verschillen ze in hun functies, benaderingen en voordelen. Dit artikel richt zich ook op de vergelijking van SCA en SBOM over de relatie, het doel, de aanpak en de voordelen ervan op het gebied van softwarebeveiligingscontrole.
-
Softwarecompositieanalyse (SCA) begrijpen
- Software Samenstelling Analyse (SCA) wordt gedefinieerd als het proces of de reeks instrumenten die helpen bij het identificeren van de open-sourcecomponenten, hun beveiligingsstatus en de licenties.
- Metagegevensverzameling: aanvullende informatie verzamelen over de componenten, zoals de versie, licentie en bron.
- Relaties documenteren: Het documenteren en tonen van de relatieve onderlinge samenhang tussen de onderdelen waaruit het softwaresysteem bestaat.
- Geautomatiseerde tools: Gebruik maken van software-engineeringautomatisering om de SBOM te produceren en bij te werken.
Voordelen van SBOM
SBOM biedt verschillende voordelen voor softwarebeveiligingsbeheer:
- Transparantie: Zorgt voor een duidelijke en gedetailleerde documentatie van de softwarecomponenten, waardoor het inzicht in de supply chain wordt verbeterd.
- RISICO BEHEER: Hierdoor kan men de kwetsbaarheid kennen die verband houdt met componenten van derden en ook de licentienaleving die daarmee gepaard gaat.
- Conformiteit: Naleving van wettelijke en industriële normen die de implementatie van SBOM's vereisen.
- Reactie op incidenten: Maakt een snelle beheersing van beveiligingsinbreuken mogelijk, omdat het informatie biedt over de getroffen subonderdelen.
Belangrijkste verschillen tussen SCA en SBOM
SCA en SBOM houden dus verband met het beheer van softwarebeveiliging, maar hebben verschillende functies en doelstellingen. Dit zijn de belangrijkste verschillen tussen SCA en SBOM:
1. Reikwijdte en focus
- SCA: Gecentreerd op procedures voor het lokaliseren en voorkomen van de integratie van open-source-elementen in een applicatie. Het belangrijkste doel is om bestaande zwakke punten te identificeren en licenties te beheren.
- SBOM: somt alle klassen, bibliotheken en afhankelijkheden op die in een toepassing aanwezig zijn en maakt het mogelijk deze eenvoudig te catalogiseren. Het primaire doel van dit raamwerk is het vergroten van de zichtbaarheid en het beperken van risico’s in de softwaretoeleveringsketen.
2. Methodologie
- SCA: Identificeert open-sourcecomponenten via het afhankelijkheidsscanmechanisme, binaire analyse en handtekeningmatching om kwetsbaarheden te detecteren.
- SBOM: Omvat de identificatie van alle elementen, het verzamelen van metadata en het vastleggen van interacties om te resulteren in een gedetailleerde lijst van de softwarecomponenten.
3. Output en resultaten
- SCA: Produceert rapporten over de ontdekte zwakke punten, niet-naleving van licenties en risicobeoordelingen van de open-sourcecomponenten.
- SBOM: Creëert een inventarisatierapport dat alle aangemelde componenten bevat, samen met hun versie, licenties en bron, en hoe ze zich verhouden tot andere componenten.
4. Gebruiksgevallen
- SCA:
- Het scannen en oplossen van geïdentificeerde problemen met bekende kwetsbaarheden in open-sourcebibliotheken.
- Naleving van licenties van open source software.
- Constant scannen van de open-sourcecomponenten op nieuwe kwetsbaarheidsrapporten.
- SBOM:
- Het verbeteren van de zichtbaarheid van de schakels in de software supply chain.
- Het mogelijk maken van het risicomanagementproces door alle benodigde informatie over de beschikbare softwarecomponenten aan te bieden.
- Voldoen aan de richtlijnen van regelgeving en industrieën die het gebruik van SBOM's verplicht stellen.
- Assisteren bij de respons op incidenten door meer beschrijvende gegevens aan te bieden over de componenten die zijn getroffen.
Relatie tussen SCA en SBOM
SCA en SBOM zijn tools die synergetisch kunnen worden geïmplementeerd om het softwarebeveiligingsbeheer te verbeteren. Terwijl SCA zich concentreert op risico's die verband houden met open-sourcecomponenten, biedt SBOM een uitgebreider beeld van de samenstelling van de software, met daarin zowel propriëtaire elementen als elementen van derden. De combinatie van SCA en SBOM zorgt ervoor dat het volledige beeld van de software van de organisatie wordt vastgelegd en dat risico's met succes worden beperkt.
Voorbeeld van geïntegreerd gebruik
Stel dat een organisatie van plan is een webapplicatie te maken en talloze open-sourcebibliotheken en componenten van derden te gebruiken. Hier ziet u hoe SCA en SBOM kunnen worden geïntegreerd om de beveiliging te verbeteren:
- Het genereren van de SBOM: Er wordt automatisch een SBOM gemaakt door de organisatie, die informatie bevat over alle componenten, bibliotheken en afhankelijkheden die in de applicatie worden gebruikt, hun versie, licenties en oorsprong.
- SCA uitvoeren: De organisatie gebruikt SCA-tools om te zoeken naar de aanwezigheid van kwetsbaarheden in de elementen van de applicatie die gebaseerd zijn op open source code. De geïdentificeerde componenten worden vergeleken met de databases met kwetsbaarheden en het rapport over onthulde kwetsbaarheden wordt gegeven door de SCA-tool.
- Risico's beheren: Met deze structuur gebruikt de organisatie de SBOM om de volledige samenstelling van de applicatie en de interacties tussen de elementen ervan te identificeren. De SBOM helpt bij het definiëren van risico's die verband houden met componenten van derden en bedrijfseigen componenten die niet door de SCA-tool worden onthuld.
- Continue monitoring: De organisatie ververst altijd de SBOM en voert periodiek SCA-scans uit om te controleren op nieuwe kwetsbaarheden en om de naleving van licenties te controleren. Samen bieden SCA en SBOM een holistische beoordeling van de kwetsbaarheden in de softwarebeveiliging en maken ze een efficiënte risicobeperking mogelijk.
Voordelen van softwarebeveiligingsbeheer
De integratie van SCA en SBOM biedt verschillende voordelen voor softwarebeveiligingsbeheer:
- Uitgebreid risicobeheerDoor het vermogen van SCA om kwetsbaarheden te identificeren te integreren met de zichtbaarheid van SBOM in de softwarestuklijst, kunnen risico's in organisaties beter worden aangepakt.
- Verbeterde zichtbaarheid: SBOM geeft een duidelijk overzicht van alle softwarecomponenten, waardoor de algehele zichtbaarheid van de software en de toeleveringsketen wordt verbeterd.
- Proactieve beveiliging: SCA maakt de vroege detectie en eliminatie mogelijk van bedreigingen die zijn ingebed in open-sourcecomponenten om beveiligingsbedreigingen te voorkomen.
- Nalevingsgarantie: Deze twee, namelijk SCA en SBOM, helpen bij het vermijden van juridische gevolgen die gepaard gaan met het niet naleven van regelgeving en normen.
- Efficiënte respons op incidenten: Tijdens het beveiligingsincident maken de gedetailleerde gegevens van SBOM dus een snelle detectie en verwijdering van de aangetaste componenten mogelijk.
Best practices voor gecentraliseerd SBOM-beheer
Omdat SBOM's steeds vaker voorkomen in C-SCRM-standaarden, is het beheer van een SBOM van cruciaal belang voor organisaties. De NSA en CISA hebben maatregelen getroffen voor het SBOM-management om aspecten van de authenticiteit, integriteit en betrouwbaarheid van de softwareproducten op te nemen.
De creatie van een gecentraliseerd SBOM-beheerplatform op hoog niveau kan nieuwe kansen openen voor organisaties die proberen het niveau van hun softwarebeveiliging te verbeteren. Deze platforms geven een uitgebreid beeld van alle softwarecomponenten en de daaraan verbonden risico's, waardoor het beheer van de software-toeleveringsketens in organisaties wordt verbeterd. In de volgende sectie gaan we dieper in op de elementen van dit concept, evenals op de aanbevelingen van de NSA en CISA over het juiste gebruik van een gecentraliseerd SBOM-beheerplatform.
Belangrijkste functionaliteiten van een gecentraliseerd SBOM-beheerplatform
- SBOM Input- en outputbeheer:
- Ondersteuning voor meerdere formaten: Het moet verschillende versies van het SBOM-formaat accommoderen en adresseren, zoals Cyclone DX en het gestandaardiseerde formaat van SBOM, bekend als SPDX. Het zou SBOM's moeten kunnen exporteren en importeren in het formaat JSON, XML en CSV.
- Nalevingscontroles: het zou de structuur en formaatsyntaxis van het SBOM-bestand moeten verifiëren aan de hand van de juiste formaatspecificatie. Een automatische correctiefunctie die helpt bij het normaliseren en corrigeren van een SBOM-bestand tijdens het importeren is handig.
- Aggregatie en conversie: Het moet mogelijk zijn om meerdere SBOM's te verzamelen en het ene formaat en/of type van het SBOM-bestand naar het andere te vertalen.
- SBOM's genereren en verwerken:
- Component identificatie: Het moet de basis-SBOM-velden bevatten, inclusief de naam van de leverancier, de naam van het onderdeel, de onderdeel-ID, de onderdeelversie, de onderdeelafhankelijkheid en de auteur van het onderdeel.
- Afhankelijkheidstoewijzing: Er zijn interfacefuncties nodig om de afhankelijkheden van de componenten visueel te beschrijven en om de herkomstgegevens van de componenten weer te geven, inclusief externe verrijkingen.
- Validatie en tracking van kwetsbaarheden:
- Integriteitsvalidatie: De hash-informatie van elke component zal worden vastgelegd en getoond, terwijl ook digitale handtekeningen voor SBOM en de integriteit van de component zullen worden verstrekt. Er moeten ook andere gerelateerde links worden verstrekt waar de gegevens over de herkomst zijn verzameld.
- Continue updates: Het platform moet dagelijks worden bijgewerkt vanuit de kwetsbaarheidsdatabases en de gebruikers informeren over nieuwe kwetsbaarheden en updates. Het moet in staat zijn onderscheid te maken tussen nieuwe kwetsbaarheden en de update van de vorige en informatie bieden over hoe prioriteit kan worden gegeven aan reacties op kwetsbaarheden en risico's.
- Integratie van bedreigingsinformatie: Het combineren van meerdere bronnen van informatie over dreigingen, samen met de unieke mogelijkheid om organisatiespecifieke beleidsregels toe te passen bij het inzetten van het beleid, versterkt het platform verder.
- Gebruikersinterface en integratie:
- Gebruiksvriendelijke interface: Het moet gebonden zijn aan Human-Computer Interface (HCI)-standaarden, toegankelijk zijn en informatie gemakkelijk te evalueren maken. Er zijn essentiële grafische weergavemethoden en -formaten voor informatiekenmerken over softwarecomponenten, kwetsbaarheden, licenties, leveranciers, gebruikers en gebruikersorganisaties.
- API's en ecosysteemintegratie: Een “API First”-ontwerp betekent dat gegevens ook op geautomatiseerde wijze eenvoudig tussen het systeem en andere systemen kunnen worden overgedragen.
- Schaalbare architectuur en configuratiebeheer:
- Ondersteuning voor suborganisaties: Het platform moet manieren bevatten om specifieke suborganisaties in een onderneming aan te pakken waarvan kan worden verwacht dat ze verschillende regels of beleid hebben met betrekking tot risicotolerantie.
- Uitgebreid configuratiebeheer: Het moet een oplossing bieden voor het opschalen van SBOM-configuratiebeheer, bijvoorbeeld voor het structureren van SBOM's, en voor het versiebeheer en het bijhouden van wijzigingen. Het moet ook manieren bevatten waarop SBOM's van verschillende versies van dezelfde software kunnen worden gecontroleerd en met elkaar vergeleken.
Gecentraliseerd SBOM-beheer implementeren: best practices
Het implementeren van een gecentraliseerd SBOM-beheerplatform omvat verschillende best practices om de effectiviteit en efficiëntie ervan te garanderen:
- Zet een beveiligd uitwisselingspunt op: Er moet een gemeenschappelijke basis tot stand worden gebracht die veilig is voor de softwareleveranciers en consumenten. Dit helpt bij het beschermen van intellectueel eigendom en bevordert de betrouwbaarheid, nauwkeurigheid en actuele gegevens van de SBOM-informatie-uitwisseling.
- Integreer SBOM-gegevens met andere beveiligingssystemen: Integreer SBOM-gegevens met systeemgegevens voor acquisitiebeveiliging, activabeheer, bedreigingsinformatie en kwetsbaarheidsbeheer. De integratie helpt bij het wijzen op de risico's die een softwareontwikkelingsbedrijf kan tegenkomen bij de selectie van zijn leveranciers en opdrachtnemers, en verbetert ook de algemene veiligheid van de softwaretoeleveringsketen.
- Automatiseer het genereren en beheren van SBOM: Maak gebruik van SBOM-generatie en beheerautomatisering van verschillende soorten softwareontwikkelingsprocesoutputs. Door gebruik te maken van automatisering zijn de SBOM’s actueel en zo nauwkeurig mogelijk.
- Continu toezicht en actualisering: Veranker de constante surveillance- en updateprocessen die zullen helpen nieuwe kwetsbaarheden te identificeren en deze op te nemen in de huidige SBOM om de nieuwste status van de softwaresamenstelling en risico's aan te geven.
- Risicoscore en prioriteitstelling: Maak een risicobeoordelingstechniek om de risiconiveaus en de risico's verbonden aan softwarecomponenten, inclusief de gevoeligheden, te evalueren. Dit helpt bij het nemen van beslissingen die nodig zijn bij risicobeheer en het uitroeien van kwetsbaarheden.
- Gebruikerstraining en -bewustzijn: Informeer de getrainde gebruikers over het gebruik van het SBOM-beheerplatform en de informatie die ze waarschijnlijk van het platform zullen halen. Daarom zijn bewustzijn en educatie van cruciaal belang om het volledige potentieel van het platform te realiseren.
- Regelmatige audits en beoordelingen: Controleer en evalueer altijd het maken van SBOM's om te garanderen dat er geen ontbrekende inhoud is en dat het SBOM-beheerplatform efficiënt is. Dit helpt bij het identificeren van de tekortkomingen en de gebieden die verbetering behoeven.
Samenvatting
Software Composition Analysis (SCA) en Software Bill of Materials (SBOM) zijn van cruciaal belang bij het verbeteren van het softwarebeveiligingsbeheer. SCA wordt gebruikt om de risico's die verband houden met het gebruik van open-sourcecomponenten te beoordelen en te beperken, terwijl SBOM een gedetailleerde catalogus van alle componenten creëert, waardoor het niveau van transparantie wordt verbeterd en het gemakkelijker wordt om risico's te beheren. Op deze manier zal de succesvolle combinatie van SCA en SBOM bijdragen aan het verkrijgen van een duidelijker inzicht in het softwarebeveiligingsprofiel van de organisatie en het beheersen van risico's.
Het uitbreiden van een effectieve oplossing voor het beheer van de SBOM naar een gecentraliseerd platform benadrukt de voorwaarden voor het beheersen van risico's in de softwaretoeleveringsketen. Dergelijke platforms bieden uitgebreide risicobeschrijvingen, constante realtime tracking en updates, en helpen ervoor te zorgen dat aan alle vereisten wordt voldaan. Als de begeleiding effectief wordt uitgevoerd en de geboden functionaliteiten van SBOM-beheerplatforms worden benut, wordt de cybersecurity van een organisatie en de veiligheid van de software supply chain aanzienlijk versterkt.
Voor meer gedetailleerde richtlijnen over SBOM-beheer raadpleegt u de aanbevelingen van de NSA en CISA in de documenten “Securing the Software Supply Chain: This are the “Best Practices for Consuming Software Bill of Materials” en “Recommendations for Software Bill of Materials (SBOM ) Administratie”.
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
