״Softwareleveranciers moeten aansprakelijk worden gesteld als ze er niet in slagen de zorgplicht na te komen die ze aan consumenten, bedrijven of aanbieders van kritieke infrastructuur verschuldigd zijn'(het Witte Huis).
Tegenwoordig wordt van elke softwareleverancier verwacht dat hij een grotere verantwoordelijkheid op zich neemt voor het waarborgen van de integriteit en veiligheid van software door middel van contractuele overeenkomsten, softwarereleases en -updates, meldingen en het beperken van kwetsbaarheden. Onlangs heeft het ESF (Enduring Security Framework), een sectoroverschrijdende werkgroep, richtlijnen uitgegeven met aanbevolen best practices en standaarden om klanten te helpen bij het implementeren van beveiligingsmaatregelen binnen de softwaretoeleveringsketen. In dit artikel zal ik dieper ingaan op de praktische aanbeveling om SBOM-gestuurde risicoscores te gebruiken als een effectief mechanisme voor triage en prioritering.
Er bestaan nog steeds veelgebruikte methoden om softwaretoeleveringsketens in gevaar te brengen, waaronder het exploiteren van ontwerpfouten in software, het inbouwen van kwetsbare componenten van derden in een softwareproduct, het infiltreren van het netwerk van de leverancier met kwaadaardige code vóór de uiteindelijke levering van het softwareproduct, en het injecteren van kwaadaardige software in de geïmplementeerde software. in de klantomgeving.
Een softwarestuklijst (SBOM) is uitgegroeid tot een cruciaal element in softwarebeveiliging en risicobeheer van de softwaretoeleveringsketen. Een SBOM fungeert als een geneste inventaris en biedt een lijst met ingrediënten die softwarecomponenten vormen.
De operationalisering van SBOM's op grote schaal vereist toolautomatisering en standaardisatie bij systeemimplementaties, productontwikkeling en gegevensuitwisseling tussen softwareleveranciers en consumenten.
Er zijn een paar belangrijke machineleesbare SBOM-standaardformaten ondersteund door de industrie. CycloneDX en SPDX definiëren de manier waarop SBOM's worden gemaakt, geanalyseerd en gedeeld. VEX is een aanvullende vorm van een beveiligingsadvies dat aangeeft of een product of producten getroffen zijn door een bekende kwetsbaarheid of kwetsbaarheden. Het biedt dus het voordeel dat het aantoont dat een product niet wordt getroffen door een specifieke kwetsbaarheid, zelfs als deze kwetsbaarheid bestaat in de SBOM ervan.
Het correleren van SBOM-inhoud tussen softwareproducten die binnen de onderneming worden ingezet, kan krachtige inzichten opleveren voor de applicatiebeveiliging, incidentrespons- en forensische teams, risicobeheer en inkoop. Van organisaties wordt verwacht dat ze een grote hoeveelheid SBOM-gegevens voor interne producten genereren en beheren, maar ook externe gegevens gebruiken die op een effectieve manier moeten worden beheerd. Daarom is er behoefte aan ondersteuning automatisering van SBOM-gedreven risicomanagement op schaal.
SBOM's en risicoscores gebruiken
Risicoscores kunnen dienen als middel om een beknopt overzicht te genereren dat is afgeleid van SBOM-inhoud, waardoor snelle vergelijkingen met externe gegevensbronnen mogelijk zijn en snelle besluitvorming op basis van ontvangen SBOM's en prioritering wordt vergemakkelijkt.
- De SBOM vergroot de transparantie, waardoor het beheer van softwaremiddelen, het patchbeheer, de identificatie van hiaten in de technische schulden en het kwetsbaarheidsbeheer voor klantorganisaties worden verbeterd. Het biedt ook de mogelijkheid om de herkomst van componenten te achterhalen om de integriteit en het vertrouwen te valideren.
- Het analyseren van de afstemming van SBOM-inhoud tussen softwareproducten die in de onderneming zijn geïmplementeerd, levert waardevolle inzichten op voor incidentresponsteams, risicobeheer en validatie van inkoopprocessen.
SBOM omzetten in risico-informatie op schaal – Reden voor risicoscores
Een belangrijke uitdaging voor elke AppSec-professional en CISO is het beheersen van de waarschuwingsmoeheid voor uw producten en diensten. Inclusief het evalueren van externe risico's afkomstig van softwarecomponenten van derden.
De belangrijkste belemmeringen voor de implementatie zijn verouderde contractuele of op licenties gebaseerde ondersteuning die van invloed kan zijn op de beschikbaarheid van downstream-patches en productupdates en de exponentiële groei van de complexiteit van afhankelijkheden binnen softwareproducten, ongeacht of deze open-source of closed-source zijn.
A risicoscore is een maatstaf die wordt gebruikt om aspecten van de huidige en toekomstige risico's van de software en de componenten ervan te voorspellen en die de prioritering op schaal effectief kan ondersteunen.
Risicoscore = waarschijnlijkheid x impact
Met Risk Scoring kunnen organisaties het risico van hun softwaretoeleveringsketen begrijpen op basis van gedefinieerde risicofactoren en anticiperen op het potentiële toekomstige risico van een bepaald softwareproduct in de onderneming.
Een effectieve risicoscore kan een schaal van 1 tot 10 hebben (zoals CVSS en Scorecard), zodat we voor het gemak elke risicocomponent kunnen afstemmen op de schaal van 1 tot 10.
Een geaggregeerde risicoscore: In veel complexe systemen en systemen van systemen kunnen er meerdere SBOM's zijn als onderdeel van de collectieve oplossing en dus een verzameling risicoscores.
Componenten voor risicoscores:
1. Kwetsbaarheden: Het in kaart brengen van bekende kwetsbaarheden met behulp van CVE-opsomming en CVSS-score van beschikbare feeds zoals NVD, OSV en Github Advisories.
2. Context van leveranciers: VEX en adviescontext van leveranciers die de beslissing over kwetsbaarheidsscores in de gebruikscontext kunnen veranderen. Het koppelen van SBOM's aan kwetsbaarheden maakt risicovlaggen mogelijk, terwijl VEX-documenten een consument in staat stellen kwetsbaarheden te prioriteren.
3. EPSS 3.0: Exploitatiemetriek van FIRST, die de waarschijnlijkheid (tussen 0 en 1.0) voor exploitatie in de komende 30 dagen voorspelt. Dit is een effectieve extra waarschijnlijkheidslaag aan de CVSS-score die kan helpen bij het prioriteren van de belangrijkste CVE’s die als eerste moeten worden afgehandeld.
4. KEV: CISA heeft ook een openbaar beschikbare feed met bedreigingsinformatie gemaakt die tegenwoordig bekend staat als de CISA KEV-catalogus (bekende exploiteerbare kwetsbaarheden).. Deze catalogus bevat ongeveer 5% van alle geïdentificeerde CVE's waarvan door de CISA is bevestigd dat ze actief of actief worden geëxploiteerd. Daarom is dit een goed startpunt om prioriteit te geven aan het aanpakken van kwetsbaarheden met een grote impact. Bovendien maakt dit deel uit van de checklist die u moet valideren voordat de nieuwe versie definitief wordt goedgekeurd.
5. Informatie over bedreigingen – Extra toevoegen bronnen van dreiging en kwetsbaarheid voeden bekende kwaadaardige pakketten (Voorbeelden: privéfeeds van Snyk, Sonatype, Graynoise, enz.)
6. OSS-reputatie: The open SSF-scorekaart evalueert onafhankelijk prestatiemaatstaven die van invloed zijn op verschillende delen van de softwaretoeleveringsketen, waaronder broncode, build, afhankelijkheden, testen en projectonderhoud. reputatie van open source-projecten (beoordeling 1-10).
7. Prestaties in de loop van de tijd: MTTR (Mean Time To Repair) kritische kwetsbaarheden van een product-/pakketversie kunnen een relevante maatstaf geven voor de prestaties op het gebied van beveiligingsrisico's.
8. botsing en context. In dit aspect zou prioritering op basis van de zakelijke context van het softwareproduct helpen bij het prioriteren en beoordelen van het kwetsbaarheidsbos.
Een paar voorbeelden zijn:
- Kritiek van de module/product: Is dit bedrijfskritisch (gevoeligheid of kriticiteit)
- In hoeveel producten heb ik de specifieke kwetsbaarheid?
- Externe blootstelling van een dienst/component
9. Blootstelling aan naleving – Licenties: Zowel propriëtaire als open-source softwarelicenties zijn belangrijk om de naleving van het juridische beleid van de organisatie te valideren.
Concept van risicoscorelagen – Risicometrieken toevoegen aan SBOM's:
- Start met CVE-opsomming en CVSS-score op basis van de SBOM-gegevens.
- Consumeer en voeg VEX-context toe om de prioriteit opnieuw te prioriteren
- Evalueer CVE's met een hoge EPSS-score (dwz 0.6-1.0)
- Geef prioriteit aan de KEV-lijst – aan adres eerst.
- Evalueer op basis van de OpenSSF-reputatiescore (1-10) – identificeer risicovolle afhankelijkheden.
- Analyseren blootstelling naar het externe netwerk (met behulp van CVSS-vector)
- Evalueren accumuleert risico door de hoeveelheid producttelling per kwetsbaarheid.
- Evalueer door de label van de kriticiteit van specifieke container-SBOM voor het bedrijf.
- Identificeren schending van de naleving risico's bij het gebruik van de SBOM-afhankelijkhedenanalyse volgens het bedrijfslicentiebeleid.
- Delen en de gegevens beheren as attesten in een samenwerkingsplatform met workflows naar andere systemen zoals Jira en anderen via API en machinaal leesbaar.
SBOM's benutten met risicoscores voor praktische gebruiksscenario's:
- Continue kwetsbaarheidsanalyse voor producten door gebruik te maken van risicostatistieken om prioriteit te geven aan een patchwerkplan voor alle producten.
- Vergelijk producten naast elkaar op basis van risicostatistieken.
- Vergelijk en keur nieuwe versie-updates goed vóór implementatie/release.
- Volg de technische schuldenkloof met behulp van de risicoscoredrempels voor productversies.
- Maak snel een rapport van de 50 belangrijkste risico's voor mijn meest kritische producten.
- Impactanalyse om de reactie op incidenten te versnellen – in het geval dat er een actief misbruikte kwetsbaarheid in het wild wordt gevonden. In dit geval, tijd is belangrijk om snel te identificeren welke impact ik heb en wat de straal van de hittekaart van deze blootstelling zou zijn.
Hoe u het Scribe Hub-platform gebruikt voor effectief risicobeheer:
- Gecentraliseerd SBOM-beheerplatform – Creëer, beheer en deel SBOM's samen met hun beveiligingsaspecten: kwetsbaarheden, VEX-adviezen, licenties, reputatie, exploiteerbaarheid, scorekaarten, enz.
- Bouw en implementeer veilige software – Detecteer manipulatie door voortdurend de broncode, containerimages en artefacten te ondertekenen en te verifiëren in elke fase van uw CI/CD-pijplijnen.
- Automatiseer en vereenvoudig SDLC-beveiliging – Beheers het risico in uw softwarefabriek en zorg voor de betrouwbaarheid van code door beveiliging en bedrijfslogica te vertalen naar geautomatiseerd beleid, afgedwongen door vangrails
- Maak transparantie mogelijk. Verbeter de bezorgsnelheid – Geef beveiligingsteams de mogelijkheden om hun verantwoordelijkheid uit te oefenen, waardoor de beveiligingscontrole wordt gestroomlijnd zonder de prestaties van het ontwikkelteam te belemmeren.
- Beleid afdwingen. Toon naleving aan - Bewaak en handhaaf het SDLC-beleid en -beheer om de softwarerisico's te verbeteren en de naleving aan te tonen die nodig is voor uw bedrijf.
Twee voorbeelden van Schrijver Hub mogelijkheden voor risicoanalyse worden gepresenteerd:
Kwetsbaarheden in kaart gebracht per SBOM, risicoscore op basis van CVSS-, VEX-, EPSS- en KEV-gegevens.
Tijdreeksen van de prestaties van de SBOM-versie in de loop van de tijd, waarbij MTTR de gemiddelde tijd aangeeft voor het repareren van kritieke geïdentificeerde kwetsbaarheden.
Samenvatting
Door SBOM aangestuurde risicoscores kunnen organisaties risico's in de toeleveringsketen beoordelen door vooraf gedefinieerde risicofactoren te evalueren en potentiële toekomstige risico's te voorzien die verband houden met een specifiek softwareproduct binnen de onderneming. De risicoscore dient als een kwantitatieve maatstaf om te anticiperen op zowel huidige als toekomstige risico's met betrekking tot de software en de componenten ervan.
Deze scoremetriek is afgeleid van indicatoren afkomstig van onder meer de SBOM en VEX, en komt overeen met de inhoud die Supply Chain Risk Management (SCRM) ondersteunt. Bij het toepassen of evalueren van een risicoscore moet rekening worden gehouden met factoren zoals de gebruikscontext van de software, de manier waarop deze wordt benaderd of geïsoleerd, en de processen en systemen die deze ondersteunt.
Scribe Hub fungeert als een samenwerkingsplatform dat is ontworpen voor de extractie, het beheer, het verzamelen van attesten en de risicoscoringsanalyse van SBOM's op grote schaal. Dit platform verwerkt op efficiënte wijze meerdere externe datafeeds om de complexiteit van complexe systemen en softwareproducten aan te kunnen.
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
