Over SBOM’s, BitBucket en OWASP Dependency Track

Handleidingen

Het museum van oude en nieuwe architecturen waarmee ik betrokken ben, dwong me om me bezig te houden met het waarborgen ervan. Bijvoorbeeld, een oude afhankelijkheid kan CVE worden of een solide open-source project kan commercieel worden. Dit is waar het concept van een Software Bill of Material (SBOM) tot stand kwam om het licentie- en afhankelijkheidsecosysteem van systemen te catalogiseren. Dit build-artifact wordt vervolgens geanalyseerd om te bepalen of de samenstellende componenten:

  1. Kwetsbaar zijn voor exploitatie, of
  2. Gelicenseerd zijn onder onaanvaardbare voorwaarden, zoals te commercieel of te roofzuchtig.

Dit artikel zal uitleggen hoe je zulke kwetsbaarheden kunt beheersen met:

  1. BitBucket-pijpen voor SBOM-generatie, en
  2. Hoe OWASP’s Dependency Track dit kan analyseren.

Ken uw risico

Niet weten wat er in je code en containers schuilgaat is een zegen, maar gevaarlijk. Het door alle componenten laten lopen via een afhankelijkheidsanalysator kan overweldigende feedback geven. Het is beter om een dashboard te maken en in de teamcultuur te verankeren dat het aantal afhankelijkheidsproblemen altijd minder zou moeten zijn vandaag dan het gisteren was.

Wikipedia stelt dat: “Het Open Worldwide Application Security Project (OWASP) is een online gemeenschap die vrij toegankelijke artikelen, methodologieën, documentatie, tools en technologieën produceert op het gebied van IoT, systeemsoftware en webapplicatiebeveiliging.” Het is daarom niet verrassend dat zij een platform bieden om kwetsbaarheden in systemen te volgen en te analyseren. Het meest opvallende kenmerk is het hoofd dashboard:

De grootste grafiek in het midden toont het aantal kwetsbaarheden voor alle projecten die worden gevolgd. Statistieken over kritieke, gemiddelde en lage kwetsbaarheden worden net daaronder weergegeven. Dependency Track haalt bekende kwetsbaarheden uit een of meer bronnen. De meest opvallende hiervan is de lijst van Common Vulnerabilities and Exposures (CVE) van de Verenigde Staten National Vulnerability Database. Elke CVE krijgt een niveau van kriticiteit toegewezen, variërend van onbekend en laag tot kritiek. Deze risicoanalyse wordt door Dependency Track regelmatig op de achtergrond uitgevoerd met behulp van de relevante Software Bill of Material (SBOM) als invoer.

De sectie direct onder de grootste grafiek beschrijft beleidsinbreuken, waarbij beleidsregels worden geconfigureerd op basis van wat men belangrijk vindt. Men kan bepaalde afhankelijkheden registreren als ongewenst, of men kan eisen dat bepaalde licenties of zelfs groepen van licenties op het dashboard worden weergegeven en gerapporteerd. Dit feedbackmechanisme is configureerbaar op basis van elk beleid.

De bovenste sectie toont vervolgens portfoliokwesties, projecten met risico, kwetsbare componenten en een risicoscore in de loop van de tijd.

Er zijn meer weergaven, grafieken en statistieken zoals de voortgang van audits, kwetsbaarheden per project in de loop van de tijd en kwetsbaarheden per component in de loop van de tijd, onder andere, maar laten we onze aandacht richten op hoe BitBucket de SBOM kan genereren en naar Dependency Track kan verzenden.

BitBucket Bereidt de SBOM Voor

De voorbereiding van de SBOM gebeurt in de BitBucket CI/CD-pijplijn die wordt uitgevoerd nadat pull requests zijn samengevoegd met de hoofdbranch. Dit zorgt ervoor dat de dashboards altijd up-to-date zijn met de stand van zaken.

Ik heb een BitBucket-pijp gebruikt die syft omhult om een CycloneDX SBOM te genereren. De syft commando’s voor code- en containerondervragingen verschillen enigszins.

Code Sniffing

Het syft commando om code vanaf de root van je project te analyseren is als volgt:

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

Dit commando geeft de SBOM weer in een bestand genaamd code-cdx-sbom.json en gebruikt het netwerk om licentie-informatie van internet op te halen; bijvoorbeeld, van de centrale Maven-repositories.

De syft BitBucket-pijp van shiftleftcyber (bedankt!) wordt vervolgens geconfigureerd in het scriptblok van de BitBucket-pijplijn om deze syft opdracht als volgt te omhullen:

YAML

 

De readme van het syft-project vermeldt een indrukwekkende reeks ondersteunde talen, maar ik heb het alleen gebruikt op Java en JavaScript met een Python project in de backlog.

Wat Zit Er in Jouw Containers?

Om een container uit jouw register te scannen, voert men de volgende opdracht uit binnen de reikwijdte van een “docker login”:

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

De bijbehorende BitBucket-pijp is:

YAML

 

De all-layers schakel instructeert syft om alle lagen van de containerafbeelding te inspecteren en niet alleen het eindproduct.

BitBucket als het Medium van Storting

Het enige wat resteert is dat Dependency Track de SBOM opneemt. Ik gebruikte de zuster pijp van de BitBucket-pijp die de SBOM genereerde:

YAML

 

Ik specificeerde drie invoerparameters:

  1. URL van de Dependency Track-instantie
  2. De ID van het Dependency Track-project om de SBOM te laden
  3. De API-sleutel om de upload te autoriseren

De project-ID kan eenvoudig worden gevonden door op “Bekijk details” te klikken vanuit de projectweergave:

Vervolgens door de Object Identifier onderaan te kopiëren:

De API-sleutel is te vinden in het gelijknamige invoerveld van het Automatisering-team, toegankelijk via het menu Beheer in het linker paneel:

Conclusie

Eerdere incidenten hebben geleerd dat het exploiteren van kwetsbaarheden vaak leidt tot serviceonderbrekingen die kunnen overslaan naar aangrenzende systemen of industrieën. Dit veroorzaakt onverwachte kosten en ongemak. Het herstel hiervan zal ontwikkelaars en middelen afleiden van teamdoelen.

De licentieverlening van een open project kan bovendien commercieel worden en resulteren in een organisatie die met achterstallige licentiekosten wordt geconfronteerd. Aan de andere kant kunnen eisen worden gesteld om kritieke IP die gebruikt wordt om het concurrentievoordeel te behalen, open-source te maken vanwege roofzuchtige licentievoorwaarden.

Het is daarom de verantwoordelijkheid van elke ontwikkelaar om actieve strategieën te implementeren en te ondersteunen om deze risico’s tegen te gaan. Als jouw code op BitBucket staat, kan de hierboven beschreven aanpak jouw systeem(s) helpen om met het programma in overeenstemming te komen. De Dependency Track API beperkt de toegang echter niet uitsluitend tot BitBucket en er moeten manieren zijn om Software Bill of Materials vanuit andere CI/CD-pijplijntechnologieën naar het systeem te krijgen.

Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track