Su SBOM, BitBucket e OWASP Dependency Track

Tutorial

Il museo di architetture antiche e moderne con cui sono coinvolto mi ha costretto a cercare di proteggerle. Ad esempio, una vecchia dipendenza può diventare vulnerabile alla CVE o un solido progetto open-source può diventare commerciale. È qui che il concetto di Software Bill of Material (SBOM) è entrato in gioco per catalogare le licenze e l’ecosistema delle dipendenze dei sistemi. Questo artefatto di compilazione, a sua volta, viene poi analizzato per determinare se i componenti costituenti sono:

  1. Vulnerabili all’exploit, o
  2. Sotto licenze dalle condizioni poco gradite, come troppo commerciali o troppo predatorie.

Questo articolo spiegherà come controllare tali vulnerabilità utilizzando:

  1. BitBucket pipes per la generazione di SBOM, e
  2. Come Dependency Track dell’OWASP può analizzarlo.

Conosci il tuo rischio

Non sapere cosa si nasconde nel tuo codice e nei container è un piacere, ma pericoloso. Tuttavia, far passare tutti i tuoi componenti attraverso un analizzatore di dipendenze può dare un feedback travolgente. È meglio creare un cruscotto e incorporare nella cultura del team che il numero di problemi di dipendenza dovrebbe essere sempre inferiore oggi rispetto a ieri.

Wikipedia afferma che: “L’Open Worldwide Application Security Project (OWASP) è una comunità online che produce articoli, metodologie, documentazione, strumenti e tecnologie liberamente disponibili nei campi dell’IoT, del software di sistema e della sicurezza delle applicazioni web.” Non sorprende quindi che forniscano una piattaforma per tracciare e analizzare le vulnerabilità nei sistemi. La sua caratteristica più sorprendente è il suo cruscotto principale:

Il grafico più grande al centro mostra il numero di vulnerabilità per tutti i progetti monitorati. Le metriche su quelle critiche, medie e basse sono visualizzate appena sotto. Dependency Track recupera le vulnerabilità conosciute da una o più fonti. La più nota di queste è la lista di Common Vulnerabilities and Exposures (CVE) dal National Vulnerability Database degli Stati Uniti. Ad ogni CVE è assegnato un livello di criticità da sconosciuto e basso a critico. Questa analisi del rischio viene eseguita da Dependency Track regolarmente dietro le quinte utilizzando il pertinente Software Bill of Material (SBOM) come input.

La sezione direttamente sotto il grafico più grande dettaglia le violazioni delle policy, con le policy configurate in base a ciò che si ritiene importante. È possibile registrare determinate dipendenze come indesiderate, oppure si può richiedere che determinate licenze o addirittura gruppi di licenze siano visualizzati nel cruscotto e segnalati. Questo meccanismo di feedback è configurabile su base per-policy.

La sezione superiore mostra le vulnerabilità del portafoglio, i progetti a rischio, i componenti vulnerabili e un punteggio di rischio nel tempo.

Ci sono più visualizzazioni, grafici e statistiche come i progressi nell’auditing, le vulnerabilità per progetto nel tempo e le vulnerabilità per componente nel tempo, tra le altre, ma rivolgiamo piuttosto la nostra attenzione a come BitBucket può generare e inviare l’SBOM a Dependency Track.

BitBucket Prepara l’SBOM

La preparazione dell’SBOM avviene nel pipeline CI/CD di BitBucket che si esegue dopo che le richieste pull sono state unite al ramo principale. Questo garantisce che i dashboard siano sempre aggiornati con lo stato delle cose. 

Ho usato una pipe di BitBucket che avvolge syft per generare un CycloneDX SBOM. I comandi syft per l’analisi del codice e dei container differiscono leggermente.

Analisi del Codice

Il comando syft per analizzare il codice dalla radice del tuo progetto è il seguente:  

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

Questo comando genera l’SBOM in un file chiamato code-cdx-sbom.json e utilizza la rete per recuperare informazioni sulle licenze da internet; ad esempio, dai repository centrali di Maven.

Il pipe syft BitBucket di shiftleftcyber (grazie!) è quindi configurato nel blocco di script del pipeline BitBucket per avvolgere questo comando syft come segue:

YAML

 

Il readme del progetto syft elenca un’impressionante varietà di linguaggi supportati, ma l’ho usato solo su Java e JavaScript con un progetto Python in backlog.

Cosa si nasconde nei tuoi container?

Per scansionare un container dal tuo registro, si esegue il seguente comando nell’ambito di un “docker login”:

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

Il corrispondente pipe di BitBucket è:

YAML

 

Il switch all-layers istruisce syft a ispezionare tutti i livelli dell’immagine del container e non solo il prodotto finale.

BitBucket come mezzo di deposito

Rimane solo che Dependency Track acquisisca l’SBOM. Ho usato il pipe sorella pipe del pipe BitBucket che ha generato l’SBOM:

YAML

 

Ho specificato tre parametri di input:

  1. URL dell’istanza di Dependency Track
  2. L’ID del progetto di Dependency Track da caricare nell’SBOM
  3. La chiave API per autorizzare il caricamento

Il progetto ID può essere facilmente trovato cliccando su “Visualizza dettagli” dalla vista del progetto:

Seguito dalla copia dell’Identificatore dell’oggetto in basso:

La chiave API si trova nel campo di inserimento dalla denominazione simile del team Automazione, accessibile dal menu Amministrazione nel pannello sinistro:

Conclusione

Incidenti passati hanno insegnato che lo sfruttamento delle debolezze tende a causare interruzioni del servizio che possono riversarsi su sistemi o settori limitrofi. Ciò comporta spese impreviste e disagi. La ripresa da ciò allontanerà sviluppatori e risorse dagli obiettivi del team. 

La licenza di un progetto aperto, inoltre, può diventare commerciale e portare a un’organizzazione che viene colpita da tariffe di licenza retroattive. Dall’altra parte della scala, possono essere fatte richieste per aprire l’IP critico utilizzato per ottenere il vantaggio competitivo a causa di condizioni di licenza predatorie. 

È quindi responsabilità di ciascun sviluppatore implementare e supportare strategie attive per contrastare questi rischi. Se il tuo codice è su BitBucket, l’approccio sopra descritto può aiutare i tuoi sistemi a adeguarsi al programma. Tuttavia, l’API di Dependency Track non limita l’accesso esclusivamente a BitBucket e devono esistere modi per ottenere il Software Bill of Materials da altre tecnologie di pipeline CI/CD.

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