CISA SBOM Kaderdocument: Derde Editie
Interlynk
In de Verenigde Staten werkt de Cybersecurity and Infrastructure Security Agency (CISA) sinds 2018 aan het bevorderen van Software Bill of Materials (SBOM) standaarden en adoptie.
De focus van CISA ligt op het operationaliseren en opschalen van het gebruik van SBOM door tools te delen, technologieën aan te bevelen en gebruikscases te beschrijven. Tegelijkertijd heeft CISA gewerkt aan de onderliggende vereisten om de volgende adoptiefase te ondersteunen.
Vorige week publiceerde CISA Framing Software Component Transparency, 3rd Edition om deze volgende fase vooruit te helpen.
Achtergrond
Na een scherpe stijging van aanvallen op de softwareleveringsketen die meerdere federale agentschappen aangrepen, nam NTIA en daarna CISA de taak op zich om de transparantie in softwareleveringsketens te verbeteren. CISA erkent dat beperkte zichtbaarheid in deze leveringsketens leidt tot hogere cybersecurityrisico's, verhoogt de kosten voor technologieonderhoud en moedigt aan om meer op snelheid dan op veiligheid te focussen. In 2018 heeft de NTIA samengewerkt met industriele en gemeenschapspartners om softwareleveringsketens transparanter te maken, met als doel risico's, kosten en de tijd die nodig is om cybersecurity-incidenten aan te pakken, te verminderen. Aanbevelingen voor Software Bill of Materials (SBOM) en Vulnerability Exploitability eXchange (VEX) zijn voortgekomen uit deze collaboratieve werkgroepen.
Kadersoftwarecomponenttransparantie
De eerste editie van Framing Software Component Transparency kwam uit in 2019, gevolgd door de tweede in 2021.
De SBOM Tooling en Implementatie Werkgroep is verantwoordelijk geweest voor de Derde Editie. Deze groep heeft als doel een model te ontwikkelen voor softwarecomponentinformatie die openlijk kan worden gedeeld tussen industrieën.
In dit model is de Software Bill of Materials (SBOM) het belangrijkste artefact—het somt de componenten van software op, omvat eigendomdetails en toont aan hoe componenten met elkaar verbonden zijn.
Derde Editie Wijzigingen
Het software benoemingsprobleem - het vermogen om uniek een software of component binnen de SBOM te identificeren - is een van de belangrijkste uitdagingen bij het verwerken van SOM. De primaire focus van de Derde Uitgave is het aanbevelen van praktijken die helpen deze uitdaging aan te pakken.
Om dit te bereiken, richt het zich op -
1. Het verklaren van een vereiste minimale set Baseline Attributen die nodig zijn om Componenten met voldoende relatieve uniekheid te identificeren
2. Het identificeren van aanvullende, optionele Attributen en externe elementen buiten de baseline set om een verscheidenheid aan SBOM-toepassingen te ondersteunen en
3. Het mogelijk maken van correlatie van SBOM's met externe bronnen voor relevante analyse
Baseline Attributen van Componenten
Deze editie richt zich op het definiëren van verplichte Baseline Attributen voor componentidentificatie.
Een componentattribuut volwassenheidsniveau wordt ook gespecificeerd voor organisaties/tools die aanvullende details willen verstrekken om aan bredere vereisten te voldoen.
Deze volwassenheidsniveaus zijn:
Minimaal Verwacht
Aanbevolen Praktijk
Aspiratiedoel
De lijst met baseline-attributen is als volgt, samen met hun minimale en aanbevolen details:
SBOM niveau Attributen
Tijdstempel
Type
Primaire Component
Component niveau Attributen
Component Naam
Versie
Leverancier Naam
Minimaal: Als de component ongewijzigd is, gebruik dan de upstream leveranciersnaam, anders vervang het door de leveranciersnaam van de primaire component
Unieke Identifiersome tekst
Aanbevolen: Ten minste één unieke identifier voor elke component
Minimaal: Zoveel mogelijk wereldwijd unieke identificaties voor elke component
Cryptografische Hashes
Aanbevolen: Ten minste één veilige hash en zijn algoritme voor de primaire component
Minimaal: Ten minste één hash en zijn algoritme voor elke component indien bekend
Relaties
Aanbevolen: Relaties en hun volledigheid voor alle opgenomen componenten
Minimaal: Relaties en hun volledigheid voor de primaire component en zijn directe afhankelijkheden
Licentie
Aanbevolen: Licentie-informatie voor zoveel mogelijk
Minimaal: Licentie-informatie voor de primaire component
Auteursrechtmelding
Aanbevolen: Auteursrechtmelding voor zoveel mogelijk
Minimaal: Auteursrechtmelding voor de primaire component
Bovendien verduidelijkt deze editie hoe om te gaan met scenario's wanneer de gegevens die nodig zijn om de SBOM te voltooien onbekend, niet beschikbaar of niet verklaarbaar zijn.
Onbekende Component Attributen
Een onbekend attribuut moet worden behandeld met
Het gebruik van de waarde "geen bewering" (d.w.z., gegevens ontbreken) anders dan de waarde "geen waarde" (d.w.z. het Attribuut is niet van toepassing voor deze specifieke SBOM).
Na alle redelijke inspanningen om "geen bewering" uit de Baseline Attributen te verwijderen.
Geredigeerde Componenten
Als een component redactie vereist, moet deze de componentversie en cryptografische hashes evenals zijn afhankelijkheidsrelaties blijven behouden.
Onbekende Afhankelijkheden
Als een SBOM bekende onbekende afhankelijkheden bevat, moeten de velden voor relatievolledigheid worden gebruikt om de staat van volledigheid van elke component te verklaren.
Aanvullende Informatie
De derde editie verduidelijkt het uitbreiden van SBOM om aanvullende use-cases te ondersteunen door aanvullende informatie te verstrekken zoals -
End-of-life gegevens of niveau van ondersteuning voor componenten
Aanduiding van welke technologieën een Component implementeert of ondersteunt
SWID Verwijderd
In een andere belangrijke verandering heeft de derde editie SWID verwijderd uit het aanbevolen formaat en de mapping voor de resterende SPDX en CycloneDX-formaten bijgewerkt.
Conformiteit met de Derde Editie
sbomqs - Interlynk's open source multi-specificatie SBOM hulpmiddel is bijgewerkt om de SBOM conformiteit met de derde editie te controleren. Met de buildversie 0.2.2 of later, kan sbomqs de naleving van de SBOM uitsplitsen langs de lijnen van
score voor elk veld bij voltooiing
percentage voltooiing van specifieke basislijnattribuut
volwassenheidsniveau van basislijnattribuut - Geen / Minimum / Aanbevolen
Met de opdracht - sbomqs naleving -f sbom.cdx.json --kleur
Samenvatting
CISA blijft toegewijd aan softwaretransparantie en de SBOM werkgroepen helpen bij het standaardiseren en operationaliseren van SBOM om de transparantie van softwarerisico's te verbeteren. De derde editie van Framing Software Component Transparency bevat praktische richtlijnen voor SBOM toolbouwers en operators om consistentie in de generatie van SBOM te waarborgen en echte waarde te extraheren uit dergelijke SBOM's.
Bij Interlynk verbeteren we onze open source-tools en platformmogelijkheden naarmate de specificaties worden verduidelijkt. Interlynk's open source-hulpmiddelen zoals sbomqs en sbomasm, evenals Interlynk's gratis SBOM beheerplatform - https://app.interlynk.io/ blijven de meest vertrouwde en actuele hulpmiddelen voor het werken met SBOM.