Charlotte Freeman, advocaat voor softwarebeveiliging, synopsys
De publicatie van Executive Order 14028 in mei 2021 zette de term “Software Bill of Materials” (SBOM) in de dagelijkse volkstaal. Maar waarom is het zo belangrijk dat elk bedrijf er een heeft?
Executive Order (EO) 14028 introduceerde nieuwe regelgeving voor bedrijven die producten of diensten met software leveren aan Amerikaanse overheidsinstanties. Het bevel gaf de Amerikaanse National Telecommunications and Information Administration (NTIA) opdracht om een reeks minimumvereisten voor een SBOM te publiceren, wat het deed in juli 2021. Als dit snel lijkt, is dat omdat het zo was. Maar dat komt deels omdat de NTIA sinds 2018 bezig is met het definiëren en publiceren van deze normen. In sommige opzichten maakte de EO het werk dat dit team had gedaan officieel.
Een SBOM is een hulpmiddel dat wordt gebruikt bij het bouwen van volwassen beveiligingsmodellen. Nu de industrie overgaat van een DevOps- naar een DevSecOps-model, is het bouwen en onderhouden van nauwkeurige SBOM’s een cruciale stap om de softwaretoeleveringsketen te beveiligen. Een SBOM somt alle open source en componenten van derden op in een codebase, evenals de componentversies en de licenties die van toepassing zijn op die componenten.
Hoewel de SBOM-normen en best practices die zijn uiteengezet in EO 14028 technisch alleen van toepassing zijn op federale departementen en agentschappen en hun technologieleveranciers, is het waarschijnlijk dat ze – waar mogelijk – ook zullen worden overgenomen door bredere categorieën kopers en leveranciers in kritieke infrastructuur als een “North Star” voor veiligheidsverwachtingen. Bovendien maakt de EO gebruik van het aanbestedingsproces en de contractuele taal van de overheid om naleving te stimuleren – een model dat in de commerciële sector zou kunnen worden toegepast.
“Deze specifieke Executive Order erkent dat wat we hebben gedaan, en het tempo waarin we het hebben gedaan, duidelijk niet werkt. We hoeven alleen maar te kijken naar alle cyberincidenten die we op het avondnieuws zien. Deze EO erkent dat er iets anders moet gebeuren en is in feite een oproep tot wapens.
Tim Mackey, AppSec gedecodeerd
De bevindingen van het Building Security In Maturity Model (BSIMM)-rapport van 2021 geven aan dat softwarerisico’s is bedrijfsrisico’s, en om bedrijfsrisico’s effectief te beheren, moeten bedrijven softwarerisico’s aanpakken. Elke organisatie die software bouwt, moet een SBOM voor zijn applicaties onderhouden, omdat organisaties doorgaans een mix van op maat gemaakte code, commerciële standaardcode en open source-componenten gebruiken om software te maken. Als organisaties niet weten wat ze in hun applicaties hebben, kunnen ze de kwetsbaarheidsgebieden niet aanpakken zoals ze worden onthuld.
Het BSIMM12-rapport laat ook zien hoe bedrijven reageren op de toename van supply chain- en ransomware-aanvallen. Van kwaadaardige inbreuken op de toeleveringsketen zoals SolarwindsOrion, tot cyberaanvallen zoals die die Schreiber Foods in oktober 2021 troffen en de roomkaasvoorziening van het land net voor de feestdagen verstoorden, het wordt steeds duidelijker dat elk bedrijf een softwarebedrijf is.
Het rapport schetst drie categorieën van beveiligingsactiviteiten die bedrijven in de BSIMM-gemeenschap het afgelopen jaar hebben toegepast. Een kernactiviteit is het beveiligen van de software supply chain, wat begint met het bouwen en onderhouden van een nauwkeurige SBOM. Het concept van een SBOM is afgeleid van fabricage, waarbij een stuklijst een inventaris is met alle items die nodig zijn om een product te maken. In de auto-industrie houden fabrikanten bijvoorbeeld voor elk voertuig een gedetailleerde Bill of Materials bij. De stuklijst bevat onderdelen die door de oorspronkelijke fabrikant zelf zijn gebouwd, evenals onderdelen van externe leveranciers. Wanneer een defect onderdeel wordt ontdekt, weet de autofabrikant precies om welke voertuigen het gaat en kan hij eigenaren van voertuigen op de hoogte stellen van de noodzaak van reparatie of vervanging.
De SBOM-richtlijnen in Executive Order 14028
Het is belangrijk om te onthouden dat de richtlijnen die in juli zijn uitgebracht, de minimum regelgevende elementen. Uw beveiligingsteams mogen verwachten dat de richtlijnen rond naleving van de SBOM-regelgeving zich blijven ontwikkelen. Voorlopig heeft de NTIA echter de minimumelementen van een SBOM gedefinieerd en die elementen in de volgende drie categorieën ingedeeld:
- Data velden
- Ondersteuning voor automatisering
- Praktijken en processen
Data velden
Gegevensvelden leggen basislijngegevens over elk onderdeel vast en houden deze bij, zodat deze in de hele softwaretoeleveringsketen kunnen worden gevolgd. Hiermee kunt u het onderdeel koppelen aan andere bronnen van nuttige gegevens, zoals kwetsbaarheids- of licentiedatabases.
De minimaal vereiste gegevensvelden zijn:
- Naam van leverancier
- Componentnaam:
- Componentversie
- Andere unieke identificatiegegevens
- afhankelijkheidsrelatie
- Auteur van SBOM-gegevens
- Tijdstempel
Hoewel deze informatie vrij eenvoudig lijkt, kan het verrassend ingewikkeld zijn om vast te leggen. Productnamen kunnen bijvoorbeeld worden verdoezeld door allerlei problemen, van fusies en overnames tot rebranding en zelfs typfouten die in de codebases zijn terechtgekomen. Er zijn een aantal hulpmiddelen die u kunnen helpen bij het zoeken naar en vastleggen van deze informatie.
Ondersteuning voor automatisering
Om SBOM’s op schaal en tussen organisaties bruikbaar te maken en omdat het doel is om ze te automatiseren, moeten ze machineleesbaar zijn. De NTIA heeft de volgende formaten goedgekeurd:
Praktijken en processen
Het is nog in de kinderschoenen met het definiëren van de praktijken en processen die de NTIA nodig heeft voor het gebruik van SBOM. Er zijn echter enkele voorlopige richtlijnen vrijgegeven die beschrijven hoe SBOM’s moeten worden verspreid en gedeeld. Het NTIA-document bevat zelfs een sectie over het opvangen van fouten waarin wordt erkend dat in industrieën waar snelheid cruciaal is voor succes, verwachtingen geen perfectie zouden moeten vereisen. Dit gedeelte herhaalt dat het overkoepelende doel van deze richtlijnen, EO 14028, en het SBOM-proces zelf is om de softwaretoeleveringsketen te beveiligen en snel te handelen, en om onze beveiligingspraktijken en -processen te blijven verbeteren.
Ga voor meer informatie over het SBOM-proces naar Synopsys.
