In april 2023 brachten DHS, CISA, DOE en CESER een rapport uit met de titel 'Software stuklijst (SBOM) levenscyclusrapport delen'. Het doel van het rapport was om de huidige manieren te onderzoeken waarop mensen SBOM's delen en om in algemene termen te schetsen hoe dit delen beter kan worden gedaan, met meer verfijning om een betere transparantie in software mogelijk te maken.
Het rapport deelt de levenscyclus van SBOM op in drie fasen: ontdekking, toegang en transport. De reis van mijn leven is hoe een gebruiker of consument zich bewust kan worden van het bestaan van een nieuwe SBOM van een auteur of aanbieder. Toegang tot is hoe een gebruiker of consument toegang kan krijgen tot deze SBOM en alle relevante gegevens die daarbij horen (SBOM-verrijking). Vervoer is hoe een consument de SBOM kan ontvangen. Hoe geautomatiseerder het proces is, hoe beter het is voor alle betrokken partijen.
Hoewel het rapport niet specifiek melding maakt van hulpmiddelen, bevat het wel verschillende voorbeelden en lijsten met attributen die dergelijke gewenste hulpmiddelen zouden kunnen bevatten.
We waren heel blij om hier bij Scribe te ontdekken dat ons platform, dat het delen van SBOM informatie als onderdeel van het kerngebruik ervan, krijgt zeer hoge cijfers als het wordt vergeleken met de gepubliceerde lijst met vereisten.
In dit artikel bespreken we de drie delen van de levenscyclus van het delen van SBOM, zoals gespecificeerd in het rapport, en onderzoeken we de meest geavanceerde oplossing zoals gezien door CISA. We sluiten af met een beschrijving van hoe Het platform van Scribe beantwoordt aan deze eisen.
SBOM Verfijning van de levenscyclus delen
De reis van mijn leven is de beginfase van de levenscyclus en gaat over hoe een consument zich bewust wordt van het bestaan van een SBOM van een auteur of aanbieder. Dit kan zo simpel zijn als het plaatsen van een nieuwe SBOM op een gestandaardiseerde plaatsing op de website van een leverancier of op een locatie in een softwareopslagplaats. Het moet voor de consument duidelijk genoeg zijn hoe hij toegang tot deze SBOM-gegevens kan krijgen of op zijn minst kan aanvragen, zodat hij deze later kan raadplegen en downloaden voor eigen gebruik. Soms zal de consument contact moeten houden met de aanbieder en om updates over zijn SBOM moeten vragen. Als alternatief kunnen automatische, continue updates beschikbaar worden gesteld.
Een zeer verfijnde aanpak, zoals vermeld in het rapport, legt een grotere onderzoekslast bij de aanbieder om het leven van de consument gemakkelijker te maken. Idealiter bestaat er een bekend en goed gedocumenteerd proces dat ideaal is voor automatisering en waarbij weinig handmatig hoeft te worden gedaan. Ter illustratie: een aanbieder zou een publiceren/abonneren service die gebruikers automatisch op de hoogte houdt van informatie over nieuwe SBOM's, evenals bijgewerkte versies van bestaande SBOM's en een mechanisme om deze te lokaliseren. Bovendien zouden meer geavanceerde niveaus nauwkeuriger moeten zijn in het verwijzen van klanten naar de gevraagde informatie, terwijl irrelevante informatie verborgen blijft.
Toegang tot is de volgende stap en beschrijft hoe u toegang krijgt tot de gegevens. De nadruk van deze fase ligt op de toegangsbeperkingen die aan de SBOM worden opgelegd en hoe een gebruiker toestemming krijgt om door te gaan naar de transportfase. De eenvoudigste manier is om de SBOM volledig toegankelijk te maken voor het publiek, zonder dat er zelfs een vereiste is om toegangscontroles in te voeren. Maar realistisch gezien zou een provider kunnen eisen dat SBOM's in een repository worden bewaard, waar toegang daartoe handmatig moet worden goedgekeurd of een rol moet worden gedefinieerd voordat deze aan een specifieke ontvanger wordt verleend. Bovendien hebben SBOM's mogelijk specifieke granulariteit van toegangscontrole nodig om te garanderen dat klanten alleen bepaalde SBOM-versies kunnen bekijken die aan een product zijn gekoppeld of toegang hebben tot bepaalde delen van de gegevens.
Bij een zeer geavanceerde aanpak kan een consument toegang vragen om een SBOM te bekijken en kan er automatisch een beperkt account worden aangemaakt. Als een consument kan aantonen dat hij een apparaat of stukje software heeft aangeschaft dat relevant is voor de betreffende SBOM, zoals een softwaresleutel, kan automatisch toegang tot SBOM’s worden verleend. Bij toegangscontroles op rollen of organisatieniveau is er sprake van een hoge mate van granulariteit van de rechten. Deze functie vereist een hoog niveau van verfijning vanwege de vereiste om de machtigingen van elke gewenste activiteit te analyseren en te begrijpen, en om de gegevens bij te houden die nodig zijn om de aankopen van klanten automatisch te valideren. Met behulp van een systeem als Public Key Infrastructure-delegatie met behulp van certificaatondertekening kan een provider authenticatie- en toegangscontroleverzoeken delegeren aan een andere organisatie voor een nog hoger niveau van verfijning.
Vervoer is de laatste stap en beschrijft de methode waarmee een consument de SBOM ontvangt. SBOM's kunnen op verschillende manieren worden getransporteerd van de ene locatie naar de andere of van de ene locatie naar een aantal locaties. Dit proces wordt door sommige methoden effectiever vergemakkelijkt dan door andere. Een kopie die op een harde schijf wordt opgeslagen en door de auteur naar de consument wordt verzonden, kan voldoende zijn als het SBOM-transport slechts de verplaatsing van één SBOM betreft. Er moet een methode beschikbaar komen waarmee klanten de SBOM veilig kunnen ophalen als een groot consumentenbestand deze nodig heeft. Deze fase is nodig voordat de consument de gegevens kan gebruiken. Houd er rekening mee dat de meeste praktische SBOM-toepassingen een machinaal leesbaar formaat vereisen, dus het transport moet daar rekening mee houden.
Met behulp van gevestigde protocollen moet het transportfaseproces grondig worden gedocumenteerd om zoveel mogelijk transportautomatisering mogelijk te maken. Een application programming interface (API) moet toegankelijk, herhaalbaar en consistent zijn. Het zou voldoende zijn om een OpenAPI-interface als zeer geavanceerd te classificeren als deze documentatie biedt voor een Representational State Transfer (REST) of RESTful API. 13 Andere API-standaarden, zoals Simple Object Access Protocol (SOAP) of Graph Query Language (GraphQL), kunnen ook als voldoende worden beschouwd. REST is slechts een populair voorbeeld van een gestandaardiseerde interface. In feite zijn alle interfaces die een vergelijkbaar niveau van integratiegemak bieden voldoende om als zeer geavanceerd te worden gecategoriseerd.
Hoe beantwoordt het Scribe-platform aan de vereisten?
Scribe heeft een platform ontwikkeld dat een automaat mogelijk maakt publiceren/abonneren service. Een softwareproducent kan zijn CI-pijplijnen aan het platform koppelen, zodat elke keer dat hij een build uitvoert, een overeenkomstige SBOM wordt gemaakt. Deze SBOM's worden vervolgens verrijkt met aanvullende informatie en zijn toegankelijk op basis van het specifieke project, de build-pijplijn, de datum en het tijdstip. De producent kan aan elk project abonnees toevoegen, zodat hij of zij dat eenmaal doet publiceren een nieuwe softwareversie. Alle abonnees worden hiervan op de hoogte gesteld en hebben onmiddellijk volledige toegang, niet alleen tot de nieuwe SBOM maar ook tot alle andere beveiligingsinformatie die daarbij hoort. De abonnees hebben op hun gemak toegang tot de SBOM's waartoe ze toegang hebben en kunnen deze downloaden wanneer ze maar willen.
Zodra de bouwpijplijnkoppeling is voltooid en een abonnee aangeeft geïnteresseerd te zijn in de gegevens, wordt de hele informatiestroom geautomatiseerd en vereist er weinig tot geen handmatige tussenkomst. De beveiligingsgegevens worden gecodeerd en beveiligd door Scribe en alleen de producent en goedgekeurde abonnees hebben toegang. Ontdekking gebeurt automatisch, toegang wordt bepaald door de producent en transport is afhankelijk van de grillen van de abonnee.
De toekomst van SBOM-delen
Tegenwoordig gebeurt het delen van SBOM even vaak via e-mail als via een geautomatiseerd systeem, maar deze aanpak is niet schaalbaar. Om meer delen mogelijk te maken, moeten er meer tools en platforms zoals die van Scribe beschikbaar, gebruiksvriendelijk en benaderbaar worden. Een verscheidenheid aan deeloplossingen die zijn ontworpen voor de behoeften van verschillende belanghebbenden zou voordelig zijn voor het SBOM-deel-ecosysteem. Deze voorwaarden bestaan omdat een bepaalde leverancier door zijn klanten kan worden gevraagd verschillende transportmethoden te gebruiken, en een klant door zijn upstream-partners kan worden voorzien van SBOM-gegevens met behulp van verschillende methoden. We hebben meer oplossingen nodig die kunnen omgaan met de geïdentificeerde speciale situaties en tegelijkertijd proberen, wanneer dit praktisch mogelijk is, handmatige processen af te schaffen en acties te vermijden die de interoperabiliteit belemmeren. Het doel van de industrie zou moeten zijn om de opkomst te voorkomen van talloze SBOM-deeloplossingen die incompatibel zijn met elkaar in een grotere toeleveringsketen, omdat dat de bestaande problemen alleen maar zou verergeren.
Aangezien de Het Scribe-platform is gratis te gebruiken voor maximaal 100 builds per maand. Ik moedig u aan om het eens te proberen en te zien aan hoeveel van uw beveiligings- en regelgevingsbehoeften het platform voldoet. We hebben nog een lange weg te gaan voordat we een werkelijk universeel platform hebben dat voldoet aan onze visie, maar het is een goed startpunt dat we graag met de wereld willen delen.
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
