Het bouwen van veilige softwareproducten of -applicaties vereist in dit tijdperk een volledige kennis van de exacte componenten van de applicatie die u bouwt. De afhankelijkheden, licenties, bestanden en andere activa waaruit uw softwarepakket bestaat, zijn potentiële kwetsbaarheden waardoor kwaadwillende actoren een aanval op uw software en andere applicaties verderop in de toeleveringsketen kunnen lanceren.
Als onderdeel van de inspanningen om de recente toename van de frequentie en impact van aanvallen op softwaretoeleveringsketensheeft de federale overheid in samenwerking met de NTIA een uitvoeringsbevel uitgevaardigd waarin verschillende maatregelen worden beschreven om de cyberbeveiliging te verbeteren en de integriteit van componenten van derden die in softwarepakketten worden gebruikt, te garanderen. Eén zo’n maatregel is de Software stuklijst.
Dit is een formeel document dat alle componenten van een softwarepakket bevat en de supply chain-relaties tussen deze componenten. Het opstellen van een uitgebreide Software Bill of Material is niet alleen standaardpraktijk, het is ook wettelijk verplicht. Dit bericht definieert de reikwijdte van de Software Bill of Materials en de minimale elementen die moeten worden opgenomen in een uitgebreide stuklijst.
Wat bieden de minimale componenten van NTIA van een SBOM?
De SBOM dient als formele gids voor bedrijven die software bouwen, kopen of exploiteren en biedt alle informatie die zij nodig hebben om hun inzicht in de softwaretoeleveringsketen te vergroten. Het helpt ook om opkomende kwetsbaarheden gemakkelijk op te sporen als deze zich voordoen risico's voor de toeleveringsketen van software verminderen. Wil de SBOM echter voldoen aan de gestelde eisen van de federale overheid, dan zijn er enkele basiselementen die deze moet bevatten. Deze elementen worden vaak ingedeeld in drie categorieën:
- Data velden: Van een SBOM wordt verwacht dat deze belangrijke gegevens over softwarecomponenten oplevert, zoals de naam van het onderdeel, de naam van de leverancier, de softwareversie en andere unieke identificatiegegevens. Het moet ook de relaties tussen afhankelijkheden gedetailleerd beschrijven. Deze gegevens maken het mogelijk om alle softwarecomponenten nauwkeurig te identificeren en ze in de hele softwaretoeleveringsketen op te sporen.
- Automatiseringsondersteuning: De Software Bill of Materials moet machinaal leesbaar zijn en ook automatisch kunnen worden gegenereerd. Hierdoor is het continu volgen van de gegevens in de SBOM mogelijk. Meestal hebben deze documenten standaardformaten zoals SPDX-, CycloneDX- en SWID-tags, waardoor ze ook voor mensen leesbaar zijn.
- Praktijken en processen: Van de SBOM-documentatie wordt ook verwacht dat deze de standaardpraktijken en -processen voor het opstellen en bijwerken van de SBOM gedetailleerd beschrijft. Het moet ook praktijken omvatten voor het verspreiden van en toegang krijgen tot de SBOM, evenals maatregelen voor het afhandelen van incidentele fouten.
De minimaal vereiste elementen van de SBOM-documentatie van NTIA bieden een duidelijk criterium van wat er wordt verwacht in een SBOM-richtlijn voor de basisgebruiksscenario's van uw Software Bill of Materials, zoals het beheren van kwetsbaarheden, het inventariseren van softwarecomponenten en het beheren van softwarelicenties. Het raamwerk wordt bijgewerkt en kan aanvullende elementen bevatten die de bruikbaarheid ervan in de nabije toekomst vergroten. In de volgende secties van deze pagina zullen we deze belangrijke componenten van uw Software Bill of Materials gedetailleerder uitleggen. De minimaal vereiste elementen van een softwarestuklijst omvatten zeven gegevensvelden, zoals hieronder gespecificeerd.
Gegevensvelden: minimale vereisten
Het doel van de Software Bill of Materials is om informatie te verschaffen die gebruikers en andere belanghebbenden helpt softwarecomponenten gemakkelijk te identificeren. Een van de eerste en belangrijkste elementen van de SBOM zijn naar verwachting de gegevens die moeten worden opgenomen voor elk onderdeel dat in het document wordt beschreven. De gegevens helpen niet alleen bij de identificatie van individuele componenten, maar maken het ook gemakkelijker om de componenten te volgen op de verschillende plaatsen waar ze in de softwaretoeleveringsketen worden gebruikt.
- Naam van leverancier: De leverancier is de maker of fabrikant van het betreffende softwareonderdeel. Dit is de naam van de persoon of organisatie die de softwarecomponenten maakt, definieert en identificeert.
- component Naam: Dit verwijst naar de aangewezen naam die aan de software is toegewezen, zoals gedefinieerd door de oorspronkelijke leverancier of fabrikant. In gevallen waarin er meerdere namen en aliassen voor de software zijn, kunnen deze ook worden genoteerd.
- Componentversie: Op de SBOM dient het vrijgavenummer of categorienummer te worden vermeld zoals opgegeven door de leverancier of fabrikant. De versiegegevens dienen als identificatiemiddel dat elke wijziging in de software specificeert ten opzichte van een eerder geïdentificeerde versie van de volgende release van de software.
- Andere unieke identificatiegegevens: Dit verwijst naar andere identificatiegegevens dan de componentnaam en -versie. Deze aanvullende identificatiegegevens bieden een extra identificatielaag voor de component en kunnen ook worden gebruikt als opzoeksleutel om de component in relevante databases te vinden.
- Afhankelijkheidsrelatie: Dit is een van de belangrijkste gegevenscomponenten van een Software Bill of Materials, omdat de SBOM bedoeld is om gedetailleerd aan te geven hoe softwarecomponenten in elkaar passen. De afhankelijkheidsrelatie specificeert de relatie tussen software X die binnen uw applicatie wordt gebruikt en de upstream-componenten ervan.
- Auteur van SBOM-gegevens: Dit verwijst naar de persoon die de SBOM-gegevens heeft gemaakt. Soms kan de softwareleverancier ook als auteur optreden. In veel gevallen is de auteur echter een ander individu of een andere groep.
Automatiseringsondersteuning: minimale vereisten
Het gebruik van de Software Bill of Materials overschrijdt vaak de grenzen van de organisatie. Dit betekent dat de gegevens in de SBOM vaak door meerdere afdelingen binnen een organisatie en ook door meerdere organisaties worden gebruikt. Om het gebruiksgemak van deze documentatie te garanderen, beveelt de NTIA aan dat de SBOM een formaat heeft dat zowel machinaal als voor mensen leesbaar is. Het voorbereiden en verzenden van de SBOM in standaard geautomatiseerde formaten zoals deze verbetert de interoperabiliteit van dit document voor de verschillende beoogde doeleinden.
De NTIA kent drie aanleverformaten voor het genereren en verzenden van SBOM’s. Uw softwarestuklijst moet overeenkomen met een van deze formaten om te voldoen aan de normen die zijn vastgelegd door de uitvoeringsbesluit van de regering op het gebied van cyberbeveiliging. Deze standaardformaten omvatten:
- Softwarepakket gegevensuitwisseling (SPDX)
- Software-identificatietags (SWID).
- CycloonDX
Softwarepakket gegevensuitwisseling (SPDX)
De SPDX is een open standaard voor het aanleveren van SBOM-data. Het legt belangrijke informatie vast over de software, inclusief de componenten, herkomst, licenties en auteursrechten. Het biedt ook beveiligingsreferenties. De SPDX versie 2.2 is de meest recente versie en ondersteunt het bestandstype YAML 1.2, JavaScript Object Notation en Resource Description Framework (RDF/XML). tag: waarde plat tekstbestand en .xls-spreadsheets
Software-identificatietags (SWID).
SWID-tags zijn ontworpen om de componenten van elk softwareproduct te helpen identificeren en contextualiseren. Het Software Identification Tags-project (SWID Tags) is een set tools voor het genereren en valideren van de identificatietags van een stukje software. Deze op Java gebaseerde tools ondersteunen XML SWID-tags op basis van het gestandaardiseerde formaat zoals gedefinieerd door ISO/IEC 19770-2:2015, en Concise Binary Object Representation (CBOR). De NIST heeft een website met een lijst met nuttige bronnen voor:
- SWID- en CoSWID-tags bouwen
- Validatie van SWID- en CoSWID-tags op basis van specifieke schemavereisten en best-practicerichtlijnen
- Een webapp die een SWID-tagvalidatieservice biedt die kan worden geïmplementeerd op een Java-toepassingsserver
- SWID repo-client voor het plaatsen van tags in de National Vulnerability Database
CycloonDX
CycloonDX beweert een ‘lichtgewicht Software Bill of Materials (SBOM)-standaard’ te zijn. Het is nuttig voor de analyse van supply chain-componenten en applicatiebeveiliging. Organisaties die CycloneDX adopteren, kunnen naadloos voldoen aan de minimale SBOM-vereisten en in de loop van de tijd uitgroeien tot meer geavanceerde gebruiksscenario's van de SBOM-documentatie.
CycloneDX SBOM's worden doorgaans gepresenteerd in XML-, JSON- of Protocol Buffers-formaten. De specificatie bevat vaak deze vijf velden:
- De metagegevens van de stuklijst: Dit omvat de algemene informatie over de applicatie of het softwareproduct zelf.
- Componenten: Dit is een uitgebreide inventaris die alle bedrijfseigen en open-sourcecomponenten van de software omvat.
- Servicesinformatie: hier worden alle externe API's beschreven die de applicatie waarschijnlijk zal aanroepen tijdens de werking ervan. Het omvat alle eindpunt-URL's, authenticatievereisten en het doorlopen van vertrouwensgrenzen.
- Afhankelijkheden: De documentatie beschrijft ook alle componenten en services binnen het softwarepakket. Dit omvat zowel directe als transitieve relaties.
- Composities: Dit verwijst naar de volledigheid van alle samenstellende delen, inclusief de individuele componenten, services en afhankelijkheidsrelaties. Elke compositie wordt doorgaans beschreven in termen van of ze compleet, onvolledig, onvolledig alleen van de eerste partij, onvolledig alleen van derden of volledig onbekend zijn.
Praktijken en processen: minimumvereisten
Het laatste element van uw Software Bill of Material richt zich op de werking van het SBOM-gebruik zelf. De praktijken en processen omvatten de operationele details van het genereren en gebruiken van de SBOM en moeten worden opgenomen in elk beleid of contract dat daarom vraagt. Hieronder volgen de belangrijkste vereisten die moeten worden beschreven in het gedeelte Praktijken en processen van uw softwarestuklijst:
- Frequentie: In deze sectie wordt beschreven hoe vaak een organisatie een nieuwe softwarefactuur voor materialen moet genereren. Over het algemeen raadt de NTIA aan dat u een nieuwe SBOM genereert telkens wanneer uw softwarecomponent wordt bijgewerkt of er een nieuwe versie wordt uitgebracht. Van leveranciers wordt ook verwacht dat ze nieuwe SBOM's genereren wanneer ze een fout in de originele versie ontdekken of nieuwe details leren over de componenten van hun software die niet in de oorspronkelijke documentatie waren opgenomen.
- Diepte: De diepgang van uw SBOM is afhankelijk van wat er in het document staat. Om aan de regelgeving te voldoen, wordt van uw SBOM verwacht dat deze alle componenten op het hoogste niveau en alle transitieve afhankelijkheden omvat. In situaties waarin de auteur niet alle transitieve afhankelijkheden kan opnemen, moet het document de consument vertellen waar hij deze kan vinden.
- Er zijn gevallen waarin de SBOM-auteur om de een of andere reden geen volledige afhankelijkheidsgrafiek kan geven. Dit kan zijn omdat de component geen verdere afhankelijkheden heeft of omdat ze niet weten of deze afhankelijkheden bestaan of niet. De SBOM-auteur is verplicht deze reden op te geven.
- Distributie en levering: Het doel van deze eis is ervoor te zorgen dat SBOM’s snel en in een gemakkelijk verteerbaar formaat worden aangeleverd. Hoewel deze eis niet specificeert hoeveel dagen of weken de SBOM's moeten worden afgeleverd, moeten ze zo snel mogelijk worden ingeleverd. Ook moeten de juiste rollen en toegangsmachtigingen voor de SBOM zijn ingesteld wanneer deze wordt afgeleverd. Ten slotte bepaalt de eis dat de SBOM ofwel bij elke instance van het product kan worden verspreid, ofwel op een andere gemakkelijk toegankelijke manier beschikbaar kan worden gesteld, bijvoorbeeld via een openbare website.
- Toegangscontrole: In gevallen waarin de leverancier besluit de toegang tot de SBOM-gegevens te beperken tot specifieke gebruikers of klanten, is de auteur verplicht de voorwaarden voor toegangscontrole te specificeren. Er is ook behoefte aan specifieke mogelijkheden voor consumenten die de SBOM-gegevens in hun eigen beveiligingstools willen integreren.
- Accommodatie van fouten: SBOM kan helpen bij het verbeteren van softwareborging en risicobeheer van de softwaretoeleveringsketen. Het is echter nog verre van perfect. Consumenten moeten dus tolerant zijn ten aanzien van de occasionele onbedoelde fouten of weglatingen die kunnen optreden bij het opstellen van SBOM’s.
Verder denken dan de minimumvereisten van NTIA
Tot nu toe hebben we de minimale elementen besproken die vereist zijn in uw Software Bill of Materials. Deze minimumelementen vertegenwoordigen de aanbevolen vereisten, vooral voor de meest elementaire gebruiksscenario's van deze documentatie. Hoewel ze een goede basis leggen voor de herkomst en beveiliging van software, moet men verder kijken dan deze vereisten. Hieronder volgen enkele aanbevelingen die u kunt overwegen voor geavanceerdere SBOM-gebruiksscenario's.
Aanvullende gegevensvelden
Naast de gegevensvelden die in het document met minimale vereisten worden behandeld, zijn er aanvullende gegevensvelden die worden aanbevolen voor gevallen waarin een hoger beveiligingsniveau noodzakelijk is. Enkele van deze aanvullende gegevensvelden zijn onder meer:
- Een cryptografische hash van de softwarecomponenten
- Gegevens over de levenscyclusfase van software
- Relaties tussen andere componenten
- Licentie-informatie
Cloudgebaseerde software en Software-as-a-Service
Een ander potentieel gebied waar de SBOM-vereisten verder kunnen gaan dan de basis is het beheer van Software-as-a-Service (SaaS)-producten. Dit soort softwareproducten brengen unieke uitdagingen met zich mee als het om SBOM-gegevens gaat. Om te beginnen zijn de beveiligingsrisico’s in de cloudcontext uniek. Ook de verantwoordelijkheid voor het omgaan met deze risico’s ligt bij de dienstverlener. Het voorbereiden van SBOM-documentatie voor cloudgebaseerde software is ook complexer omdat deze doorgaans een kortere releasecyclus hebben.
SBOM Integriteit en Authenticiteit
Een ander waarschijnlijk probleem dat de moeite van het vermelden waard is, is het proces van het authenticeren van de bron van SBOM-gegevens zelf. Momenteel zijn handtekeningen en publieke sleutelinfrastructuur de beste oplossingen voor het verifiëren van de integriteit van software in de digitale wereld van vandaag. Auteurs en leveranciers van SBOM's moeten mogelijk gebruik maken van deze bestaande softwarehandtekeningen om de betrouwbaarheid van SBOM-gegevens te verbeteren.
Kwetsbaarheid en exploiteerbaarheid in afhankelijkheden
Hoewel het doel van SBOM's is om kwetsbaarheden gemakkelijker te kunnen detecteren, is het belangrijk op te merken dat niet alle kwetsbaarheden in afhankelijkheden grote risico's vormen voor software die daarvan afhankelijk is. Om verspilling van tijd en middelen te voorkomen, zullen softwareleveranciers maatregelen moeten treffen om de potentiële impact van een afhankelijkheidskwetsbaarheid op software die downstream gebruikt te bepalen en het risiconiveau (of het gebrek daaraan in dit geval) aan de gebruikers van de SBOM moeten communiceren. gegevens stroomafwaarts.
Flexibiliteit versus uniformiteit in de implementatie
Wanneer er over softwarebeveiliging wordt gesproken, komt de kwestie van flexibiliteit en uniformiteit altijd op de voorgrond. Dit geldt ook voor geavanceerde gebruiksscenario's van SBOM's. Om SBOMs succesvol te implementeren zal er behoefte zijn aan breed beleid dat van toepassing is op alle gebieden, maar ook aan specifieke gevallen waarin flexibiliteit nodig zal zijn.