De 5 Meest Voorkomende Problemen in SBOMs
Interlynk
Software Bill of Materials (SBOM) helpt bij het opbouwen en communiceren van een inventaris van softwarecomponenten en de bijbehorende risico's. De regelgeving en monitoringseisen van SBOM zijn goed begrepen. Het bouwen van een "goede" SBOM vereist echter nog steeds het vermijden van verschillende valkuilen, aangezien sommige populaire SBOM-bouwers nog in ontwikkeling zijn.
Hier zijn de vijf meest voorkomende problemen waar we tegenaan lopen bij het omgaan met SBOM's.
1. Specificatie verwarringen
De meest voorkomende verschijnen in tools die meer dan één specificatie ondersteunen. We zien consistent dat de implementatie van de verwerking van één specificatie leidt tot ongeldige waarden voor de andere.
2. Onjuist Geïdentificeerde Identifiers
CPE en PURL zijn twee van de meest voorkomende manieren om onderdelen wereldwijd te identificeren, vooral in kwetsbaarheidsbeheer. Bovendien vereisen zowel CycloneDX als SPDX document-specifieke interne unieke identificatoren ( bom-ref en SPDXID respectievelijk). Dit helpt om aanvullende componentinformatie bij te houden, zoals de relatie tussen componenten.
Maar deze vereisten rond de identificatoren kunnen leiden tot twee veelvoorkomende soorten uitdagingen:
2.1 Ontbrekende of Ongeldig CPE/PURL
Een SBOM die leeg is voor CPE of PURL is niet nuttig voor kwetsbaarheidstracking. Het kan nog steeds dienen als een ingrediëntenlijst en licentie-inventaris wanneer licentie-informatie aanwezig is.
2.2 Onconsistente Unieke Identificator
Het andere meest voorkomende probleem is een SBOM met ongeldige of dubbele identificatoren aanwezig in de SBOM. De bom-ref en SPDXID zijn bedoeld om uniek te zijn in het document en hebben specificatie-specifieke beperkingen (bijv., SPDXID mag geen speciale tekens bevatten).
3. Licentie om te verwarren
Het specificeren en bijhouden van open-source softwarelicenties was een van de vroegste gebruikstoepassingen voor de SPDX-specificatie. Sindsdien hebben de SPDX-licentie-uitdrukkingen de lijst met licenties verbeterd en de mogelijkheid om meerdere licenties of specifieke uitzonderingen daarop uit te drukken.
CycloneDX 1.5 en SPDX 2.3 en hoger ondersteunen het specificeren van commerciële licenties naast de teksten en links naar externe documenten.
Helaas is het al te gebruikelijk om tegen ongeldige licentie-ID's of licentie-uitdrukkingen in SBOM's aan te lopen.
4. Gezichtsloze SBOM
De SBOM bestaat in de context van een software- of hardwarecomponent van een systeem. Daarom, zonder juiste identificatie van de component zelf, wordt de rest van de SBOM een ingrediëntenlijst voor een onbekende. NTIA Minimum Elementen stelt voor de component te identificeren met Naam, Versie, en Andere Unieke Identifiers om specifieke opzoekingen zoals opzoekingen naar kwetsbaarheden te ondersteunen.
Het is echter gebruikelijk om SBOM's tegen te komen zonder die minimale dataset.
Een voorbeeld:
Let op dat er geen versie is opgegeven in de primaire component, en er geen kwetsbaarheidsidentificatie aanwezig is. Dit maakt de SBOM onbruikbaar voor het volgen van kwetsbaarheden over versies en het samenvoegen van SBOM in de volgorde van productreleases. Het ontcijferen van versie 6.2.12-rc230906104347 vereist product-specifieke foutgevoelige aanpassingen.
5. SBOM burrito
De meest gebruikte SBOM-specificaties, CycloneDX en SPDX, hebben een redelijke mate van flexibiliteit. Helaas nemen sommige SBOM-bouwers een omweg om SBOM-inhoud te omhullen met extra gegevens.
Een voorbeeld:
Dit volgt geen van beide specificaties, en er is menselijke tussenkomst nodig om te begrijpen dat de daadwerkelijke SBOM begint bij de “sbom” knooppunt.
De appID, scanId, type en repo:id zijn allemaal details die niet toepasselijk zijn buiten de reikwijdte van deze tool. Dit maakt het automatiseren van de consumptie van dergelijke SBOM een plakbandoefening.
Bovendien heeft de burrito-wrapper geen versiebeheer en kan het elke downstream-automatisering zonder waarschuwing breken.
Interlynk probeert het openbaar maken van beveiligingsproblemen eenvoudig, duidelijk en geautomatiseerd te maken. Interlynk’s open source-tool, sbomqs, kan de meest voorkomende problemen met de SBOM’s identificeren en is open voor het bijhouden van andere veelvoorkomende fouten die u misschien tegenkomt. Neem gerust contact met ons op via hello@interlynk.io