SBOM-onderhoud bij productreleases
Sytance · Bijgewerkt
Een SBOM moet gekoppeld blijven aan de softwarerelease die erin wordt beschreven. Een software-update kan de componenten veranderen, terwijl een correctie van de SBOM alleen informatie over een ongewijzigde release kan rechtzetten. Door beide versies vast te leggen, kan worden vastgesteld wat klanten hebben ontvangen en welke inventaris die software correct beschrijft.
De software die in elke inventaris wordt beschreven
Kies een herhaalbaar moment in het build- of releaseproces om de SBOM te genereren. Bewaar de broncoderevisie, opgeloste afhankelijkheden, buildconfiguratie en identiteit van het uiteindelijke artefact die nodig zijn om de inventaris opnieuw te maken of te onderzoeken.
De CycloneDX-gids maakt onderscheid tussen inventarissen die worden gegenereerd op basis van broncode, tijdens een build en tijdens het gebruik. Deze fasen kunnen verschillende software omvatten. Door de fase te benoemen, weet de ontvanger of de SBOM gedeclareerde afhankelijkheden, een buildresultaat of geïmplementeerde software beschrijft.
Combineer voor een gateway informatie uit de applicatiebuild, de basisimage en meegeleverde firmwarecomponenten. Bewaar de koppeling met elke SBOM van een leverancier. Voor een cloudservice die de gateway gebruikt, kan een afzonderlijke inventaris met een eigen releasecyclus nodig zijn.
Wijzigingen in componenten tussen releases
Een releasevergelijking toont welke componenten zijn toegevoegd, verwijderd, bijgewerkt of opnieuw gebouwd en welke afhankelijkheidspaden zijn gewijzigd. Alleen componenten tellen kan een vervanging missen: de ene bibliotheek kan worden verwijderd en een andere toegevoegd zonder dat het totaal verandert.
Gebruik genormaliseerde identiteiten voor de vergelijking, maar bewaar de oorspronkelijke versie en identificatiegegevens. Als een tool eerder onbekende pakketten begint te herkennen, maak dan onderscheid tussen beter inzicht en een daadwerkelijke softwarewijziging.
- Toegevoegde of verwijderde componenten en hun bovenliggende afhankelijkheidspaden.
- Versiewijzigingen, patches in afgeleide versies en gewijzigde artefacthashes.
- Wijzigingen in licentievermeldingen of producenten van componenten.
- Nieuwe hiaten, gecorrigeerde identificatiegegevens en revisies van SBOM's van leveranciers.
Controles vóór de release
Valideer het bestand aan de hand van de formaatversie en beoordeel vervolgens de inhoud. Controleer of elke verwijzing kan worden opgelost, of het hoofdproduct de beoogde release is en of de ontvanger toegang heeft tot gekoppelde SBOM's van componenten.
Voer kwetsbaarheids- en licentiecontroles uit op de kandidaat en leg de resultaten voor die release vast. Een nieuw probleem met hoge prioriteit vereist een besluit over de behandeling ervan. Beoordeel een oude uitzondering opnieuw als de componentversie of de aannames over de werking zijn veranderd.
Archiveer het goedgekeurde artefact, de SBOM, buildverwijzingen en beoordelingsuitkomst samen. Controleer bij gebruik van een handtekening de handtekening en bevestig dat deze van de verwachte uitgever afkomstig is.
Correcties in een bestaande SBOM
De gezamenlijke SBOM-richtsnoeren van 2026 schrijven een SBOM voor elke softwareversie of update voor en een herziene SBOM wanneer fouten worden gecorrigeerd of nieuwe componentgegevens bekend worden. De richtsnoeren maken ook onderscheid tussen informatie die onbekend is en informatie die bewust wordt achtergehouden.
Een leverancier corrigeert bijvoorbeeld de producent van een component terwijl de firmwarebytes ongewijzigd blijven. Behoud de firmware-identiteit, geef een nieuwe SBOM-revisie uit, licht de correctie toe en bewaar het vorige document. Zo kunnen ontvangers een gegevenscorrectie onderscheiden van een software-update.
Publiceer een update via het afgesproken distributiekanaal. Een stabiele landingspagina kan naar de huidige revisie verwijzen, terwijl onveranderlijke bestanden de geschiedenis bewaren. Bevestig dat ontvangers kunnen vaststellen welke revisie een eerdere versie vervangt.
Nieuwe kwetsbaarheden in ondersteunde releases
Zoek na ontvangst van een advies naar componentidentiteiten in alle ondersteunde releases. Beoordeel de daadwerkelijke builds en het productgebruik voordat de impact wordt vastgesteld. Houd de componentinventaris gescheiden van de kwetsbaarheidsbeoordeling, zodat dezelfde SBOM opnieuw kan worden beoordeeld wanneer nieuwe informatie beschikbaar komt.
Als gatewayrelease 1.0 een getroffen bibliotheek bevat en release 1.1 deze verwijdert, verandert de nieuwe release niets aan de samenstelling van geïnstalleerde apparaten met versie 1.0. Het team moet nog steeds een reactie voor die apparaten bepalen en nauwkeurig vastleggen welke versies onder een advies of VEX-verklaring vallen.
Spreek af wie updates van leveranciers bijhoudt, wie de impact beoordeelt, wie een reactie goedkeurt en wie deze communiceert. Bepaal het moment van beoordeling op basis van de ondersteuningsverplichtingen voor het product en de ernst van nieuwe informatie, in plaats van uitsluitend te vertrouwen op de volgende geplande release.
Bewaren en overdragen van gegevens
Bewaar aan het einde van de ondersteuningsperiode de koppeling tussen releases en SBOM's en de besluiten die nodig zijn om eerdere leveringen toe te lichten. Beperk de toegang tot gevoelige gegevens waar nodig en zorg er tegelijk voor dat bevoegde ontvangers de informatie kunnen krijgen die hun is toegezegd.
Bij een overdracht moet een nieuwe beheerder de inventaris voor een productversie kunnen vinden, een component kunnen opzoeken en de recentste impactbeoordeling kunnen lezen. Door één ondersteunde release te doorlopen, kunnen ontbrekende gegevens of toegangsrechten aan het licht komen.