Nel dicembre 2021 è stato aggiornato in pochi giorni.Trovare dove Log4j esisteva in produzione ha richiesto molto più tempo. di Log4Shell La maggior parte dei progetti Java colpiti avevano Log4j come dipendenza indiretta accoppiato con qualcosa di diverso, non scelto direttamente. 80% di quelli avevano cinque o più livelli in profondità nel loro albero di dipendenza. i team di sicurezza hanno trascorso le vacanze prendendo attraverso JARs/build e eseguendo ricerche recursive su centinaia di repos, cercando di rispondere a una domanda che avrebbe dovuto essere triviale: what's in our software? Il patch è disponibile. The problem was inventory Dipendenza transitoria Tu aggiungi Il progetto Node.js ha bisogno di Necessità di body-parser I bisogni del Raw-Body Un pacchetto diventa un albero. express body-parser raw-body unpipe 
 
 
 Dipendenze dirette: cosa metti in package.json Dipendenze transitive: tutto ciò che questi pacchetti tirano in di Il rapporto varia per ecosistema, Maven amplifica le dipendenze più di npm, che amplifica più di PyPI, ma il modello detiene, le dipendenze dirette potrebbero contare nelle dozzine. Il rapporto di Ivanti Ogni pacchetto in quell'albero ha i propri manutenzori, le pratiche di rilascio e la postura di sicurezza. Alcuni sono mantenuti da team di grandi aziende. Altri sono progetti laterali che non hanno visto un compromesso in tre anni. Dal punto di vista della tua applicazione in esecuzione, sono tutti ugualmente fidati. Il   Nel 2018 ha sfruttato questo. un mantenitore ha consegnato un popolare pacchetto npm a qualcuno che ha offerto di aiutare. Come dipendenza, quel pacchetto conteneva codice difettoso mirato ai portafogli Bitcoin di Copay, due milioni di download settimanali proseguiti per mesi prima che qualcuno si accorgasse event-stream Attacco flatmap-stream Il codice maligno è in Era un livello più profondo, nascosto in una dipendenza transitoria che nessuno stava osservando. event-stream Perché ho costruito questo? I gestori di pacchetti installano le dipendenze, risolvono i conflitti di versione e scaricano i pacchetti. Non ti dicono cosa è cambiato tra ieri e oggi. due volte produce lo stesso risultato, ma non puoi facilmente confrontare l'albero di dipendenza del martedì con quello del lunedì npm install Gli scanner di vulnerabilità trovano CVEs conosciuti, corrispondono alle versioni dei pacchetti contro i database delle vulnerabilità rivelate. Non ti dicono dei pacchetti che sembrano ancora vulnerabili, dei pacchetti che potrebbero diventare il prossimo Log4j. Lock file pin versioni. Essi garantiscono costruzioni riproducibili e prevengono aggiornamenti inaspettati. Non ti aiutano a capire cosa 47 nuovi pacchetti hanno appena entrato nel tuo codebase quando qualcuno ha aggiunto una nuova dipendenza, Il file di blocco diff mostra centinaia di righe di JSON.. 
 
 Buona fortuna a questo in un pr Buona fortuna a questo in un pr Quello che manca è il confronto, generare un'immagine rapida delle tue dipendenze oggi. Generare un altro domani. Diffondere. Vedere esattamente cosa è cambiato: nuovi pacchetti, pacchetti rimossi, aggiornamenti di versione, cambiamenti di licenza Questo è ciò che le SBOM consentono. a elenca ogni componente del tuo software, diretto e transitivo, con versioni, licenze e hash. Confronta due SBOM e ottieni una visione chiara di ciò che è diverso Software Bill of Materials Volevo uno strumento per diffondere SBOM, segnalare cambiamenti sospetti e far rispettare le politiche in CI. Non ho trovato uno che funzionasse come volevo, quindi ho costruito sbagliato Impostazione # Install to ./bin
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sh

# Install to /usr/local/bin (requires sudo)
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sudo sh -s -- -b /usr/local/bin

# Install specific version
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sh -s -- -v 0.2.0
 $ sbomlyze --version
sbomlyze v0.2.3
 Avrai bisogno di un generatore SBOM. , che supporta la maggior parte degli ecosistemi dei pacchetti e le immagini dei contenitori (sono le migliori) Obiettivo curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
 Obiettivi di output o formati SPDX. sbomlyze legge entrambi. CicloneX Esempio: aggiungere espressione Ecco un esempio minimo che mostra cosa succede quando si aggiunge una singola dipendenza. V1 - lodash only: package.json
---------------
{
  "name": "test-app",
  "version": "1.0.0",
  "dependencies": {
    "lodash": "^4.17.21"
  }
}
--------------
 npm install
syft . -o cyclonedx-json > ../v1-sbom.json
 V2 - add express: package.json
---------------
{
  "name": "test-app",
  "version": "1.0.0",
  "dependencies": {
    "lodash": "^4.17.21",
    "express": "^4.18.2"
  }
}
---------------
 npm install
syft . -o cyclonedx-json > ../v2-sbom.json
 Diff: sbomlyze v1-sbom.json v2-sbom.json
 Output: 📊 Drift Summary:
  ⚠️  Integrity drift: 1 components (hash changed without version change!)

+ Added (68):
  + accepts 1.3.8
  + array-flatten 1.1.1
  + body-parser 1.20.4
  + bytes 3.1.2
  + call-bind-apply-helpers 1.0.2
  + call-bound 1.0.4
  + content-disposition 0.5.4
  + content-type 1.0.5
  + cookie 0.7.2
  + cookie-signature 1.0.7
  + debug 2.6.9
  + depd 2.0.0
  + destroy 1.2.0
  + dunder-proto 1.0.1
  + ee-first 1.1.1
  + encodeurl 2.0.0
  + es-define-property 1.0.1
  + es-errors 1.3.0
  + es-object-atoms 1.1.1
  + escape-html 1.0.3
  + etag 1.8.1
  + express 4.22.1
  + finalhandler 1.3.2
  + forwarded 0.2.0
  + fresh 0.5.2
  + function-bind 1.1.2
  + get-intrinsic 1.3.0
  + get-proto 1.0.1
  + gopd 1.2.0
  + has-symbols 1.1.0
  + hasown 2.0.2
  + http-errors 2.0.1
  + iconv-lite 0.4.24
  + inherits 2.0.4
  + ipaddr.js 1.9.1
  + math-intrinsics 1.1.0
  + media-typer 0.3.0
  + merge-descriptors 1.0.3
  + methods 1.1.2
  + mime 1.6.0
  + mime-db 1.52.0
  + mime-types 2.1.35
  + ms 2.0.0
  + negotiator 0.6.3
  + object-inspect 1.13.4
  + on-finished 2.4.1
  + parseurl 1.3.3
  + path-to-regexp 0.1.12
  + proxy-addr 2.0.7
  + qs 6.14.1
  + range-parser 1.2.1
  + raw-body 2.5.3
  + safe-buffer 5.2.1
  + safer-buffer 2.1.2
  + send 0.19.2
  + serve-static 1.16.3
  + setprototypeof 1.2.0
  + side-channel 1.1.0
  + side-channel-list 1.0.0
  + side-channel-map 1.0.1
  + side-channel-weakmap 1.0.2
  + statuses 2.0.2
  + toidentifier 1.0.1
  + type-is 1.6.18
  + unpipe 1.0.0
  + utils-merge 1.0.1
  + vary 1.1.2

! Duplicates in second SBOM (1):
  ! ms: [2.0.0 2.1.3]
 Un cambiamento di linea in package.json aggiunto I progetti, il progetto è partito da Componenti per * 71 68 3 In una PR t diff spettacoli Il I pacchetti transitivi non appaiono da nessuna parte nella recensione del codice, sono invisibili a meno che non si generino SBOM e non vengano confrontati. "added express to dependencies" 67 Questo è tipico. La maggior parte dei framework attira decine di dipendenze transitive. React, Angular, Django, Rails, hanno tutti alberi di dipendenza profonda. Ognuno di quei pacchetti corre in produzione con gli stessi privilegi del tuo codice. Comprendere le uscite elenca ogni nuovo pacchetto nel tuo albero di dipendenza, ognuno ora in produzione. Alcuni di cui hai sentito parlare (body-parser, cookie). Altri di cui hai bisogno (dunder-proto, gopd, es-object-atoms). Tutti hanno accesso uguale alla memoria delle tue applicazioni, alla rete e al file system. Added components pacchetti di bandiera che appaiono più volte con versioni diverse, in questa uscita, Le diverse parti di Express richiedono versioni diverse, e npm installa entrambe. ottenere un CVE, è necessario tracciare attraverso il tuo albero di dipendenza per trovare ogni percorso che lo attira, quindi aggiornare i pacchetti lungo quei percorsi. Con una versione, questo è semplice. Con più versioni incastonate a diverse profondità, diventa noioso Duplicates ms ms cattura componenti in cui il hash è cambiato ma la versione è rimasta la stessa. Questo può accadere legittimamente un mantenitore di pacchetti ricostruisce e ripubblica senza colpire la versione, può anche indicare la manipolazione. Qualcuno compromette un account del registro, spinge il codice modificato sotto un numero di versione esistente. La versione sembra invariata, ma il codice è diverso. Integrity drift Esecuzione politica Puoi definire regole e creare errori che le violano.Le politiche consentono di codificare gli standard organizzativi e applicarli automaticamente. politica.json {
  "max_added": 5,
  "max_removed": 3,
  "max_changed": 10,
  "deny_licenses": ["GPL-3.0", "AGPL-3.0"],
  "require_licenses": false,
  "deny_duplicates": true
}
 sbomlyze v1-sbom.json v2-sbom.json --policy policy.json
 Output when violated ❌ Policy Errors (2):
  [max_added] too many components added: 68 > 5
  [deny_duplicates] found 1 duplicate components in result
 Il codice di uscita 1 fallisce 
 
 
 
 
 
 
 
 
 
 
 
 Field 
 Function 
 
 
 
 max_added 
 Cap on new packages 
 
 
 
 max_removed 
 Cap on removed packages 
 
 
 
 max_changed 
 Cap on version changes 
 
 
 
 deny_licenses 
 Block specific licenses 
 
 
 
 require_licenses 
 Require license info 
 
 
 
 deny_duplicates 
 Fail on duplicate versions max_added Cap su nuovi pacchetti max_removed Cap sui pacchetti rimossi max_changed Cambiamenti nella versione deny_licenses Blocco delle licenze specifiche require_licenses Richiede la licenza info deny_duplicates Il fallimento delle versioni duplicate Le soglie dipendono dalla vostra base di codice, un progetto di greenfield potrebbe impostare , Un codebase stabilito con dipendenze di lockeddown potrebbe impostare , iniziare a rilassarsi, osservare come sembrano i PR normali, quindi stringere max_added: 10 max_added: 3 Il blocco delle licenze riguarda la conformità.Alcune organizzazioni non consegnano il codice GPL nei prodotti proprietari, alcune non usano il codice AGPL nelle applicazioni SaaS.La politica li cattura prima della fusione piuttosto che durante la revisione legale mesi dopo. Il blocco duplicato è più severo, molti legittimi alberi di dipendenza hanno duplicati. Si potrebbe iniziare con questo disattivato e abilitarlo più tardi mentre si pulisce il vostro albero di dipendenza. L’integrazione Ecco un flusso di lavoro GitHub Actions che genera SBOM sia per il ramo di base che per il ramo PR, quindi li diffonde name: SBOM Diff

on:
  pull_request:
    branches: [main]

jobs:
  sbom-diff:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.21'

      - name: Install tools
        run: |
          go install github.com/rezmoss/sbomlyze/cmd/sbomlyze@latest
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Generate baseline SBOM
        run: |
          git checkout origin/main
          npm ci
          syft . -o cyclonedx-json > baseline.json

      - name: Generate PR SBOM
        run: |
          git checkout ${{ github.head_ref }}
          npm ci
          syft . -o cyclonedx-json > pr.json

      - name: Diff
        run: sbomlyze baseline.json pr.json --policy policy.json
 Il flusso di lavoro controlla entrambi i rami, genera un SBOM per ciascuno, e li confronta, se la politica fallisce, il PR fallisce Gli sviluppatori vedono esattamente quali pacchetti sono cambiati e perché il build è fallito Puoi anche eseguire questo senza un file di politica per ottenere visibilità senza applicazione, l'uscita diff appare nei log CI. Uscita JSON per la scrittura e il custom tooling, Impostazione di JSON: sbomlyze sbomlyze v1-sbom.json v2-sbom.json --json > diff.json

jq '.diff.added | length' diff.json
jq '.diff.added[].name' diff.json
jq '.diff.duplicates' diff.json
 Puoi creare controlli personalizzati su questo,flag pkgs da manutenzori specifici.Alert su pacchetti con bassi numeri di download.Cross reference contro un permisslist interno.Il JSON ti dà i dati; scrivi la logica Immagini dei container Le immagini dei contenitori contengono più del codice dell'applicazione, l'immagine di base porta i pacchetti OS libc, openssl, coreutils. La tua applicazione aggiunge il suo runtime e le dipendenze, un contenitore tipico ha centinaia di componenti da più ecosistemi Syft scansiona direttamente le immagini dei container syft nginx:1.24-alpine -o cyclonedx-json > nginx-1.24.json
syft nginx:1.27-alpine -o cyclonedx-json > nginx-1.27.json
sbomlyze nginx-1.24.json nginx-1.27.json
 nginx:1.24-alpine ha 1.393 componenti. nginx:1.27-alpine ha 1.047, il ver bunp ha cambiato centinaia di pacchetti, aggiornamenti dell'immagine di base alpina, aggiornamenti della biblioteca, rimossi pkgs Queste modifiche sono invisibili se si seguono solo le dipendenze applicative, dice Dockerfile ,la diff mostra una riga cambiata, il cambiamento effettivo al software implementato è centinaia di pkgs. FROM nginx:1.27-alpine sbomlyze funziona a livello SBOM, quindi gestisce tutto ciò che Syft rileva pacchetti OS, dipendenze applicative, binari, file di configurazione, tutto in un unico diff Stati singoli SBOM Quando si desidera una panoramica di uno SBOM senza confronto sbomlyze v2-sbom.json
 output 📦 SBOM Statistics
==================

Total Components: 71

By Package Type:
  npm          70
  unknown      1

Licenses:
  With license:    69
  Without license: 2

  Top Licenses:
    MIT                            66
    ISC                            2
    BSD-3-Clause                   1

Integrity:
  With hashes:    1
  Without hashes: 70

⚠️  Duplicates Found: 1
  ms: [2.0.0 2.1.3]
 alto I conti suggeriscono pacchetti che possono essere non mantenuti o scarsamente documentati, legittimi pkgs di solito hanno file di licenza, le licenze mancanti possono anche indicare il rischio di conformità, si sta spedendo il codice con uno stato giuridico non chiaro. "without license" La copertura hash bassa limita la tua capacità di verificare l'integrità. Senza hash, non puoi rilevare se un pacchetto è stato modificato dopo la pubblicazione Se la tua applicazione Node.js mostra pacchetti Python, qualcosa li ha tirati in. Forse uno strumento di build, forse un framework di test, forse qualcosa che non dovrebbe esserci. Raccomandazioni hai bisogno di basilini da diffondere. Includere la generazione SBOM nel tuo pipeline di rilascio. Archiviarli accanto ai tuoi artefatti di costruzione Store SBOMs for each release, syft . -o cyclonedx-json > sbom-v${VERSION}.json
 Quando si verifica un incidente, è possibile confrontare la versione interessata con le versioni precedenti, è possibile rispondere Senza ricostruire vecchi edifici. "when did this package enter our dependency tree?" Anche senza bloccare, la visibilità aiuta, i revisori possono vedere l'impatto completo dei cambiamenti di dipendenza. diventa Questo contesto cambia la revisione Diff on every PR. "Added axios" "added axios and 12 transitive dependencies" Quando si approva Express ( pacchetti), scrivere il perché link alla recensione di sicurezza, nota chi l'ha approvato, sei mesi dopo quando qualcuno chiede la dipendenza, la risposta esiste Document big additions. 68   diffing mostra ciò che è cambiato. la scansione della vulnerabilità mostra qual è la vulnerabilità. Domande diverse, entrambe utili. Diffing cattura nuove dipendenze prima che accumulino CVE. La scansione cattura le dipendenze esistenti quando vengono rivelate CVE. Combine with vulnerability scanning. SBOM Guarda attraverso il tuo albero di dipendenza. Pacchetti di ricerca che non riconosci. Controlla lo stato di manutenzione, l'ultima data di commissione, i problemi aperti, il fattore bus. Identificare i candidati per la sostituzione o la rimozione. Review quarterly. riassunto # Generate
syft . -o cyclonedx-json > sbom.json

# Compare
sbomlyze baseline.json current.json

# Enforce
sbomlyze baseline.json current.json --policy policy.json
 A Note on Tooling sbomlyze è qualcosa che ho costruito per il mio flusso di lavoro quotidiano. Ci sono molti altri strumenti di analisi SBOM e dipendenza; alcuni potrebbero soddisfare le tue esigenze meglio, alcuni peggio. Non sto affermando che nulla di più funziona o che questa è l'unica soluzione. Ho guardato intorno, non ho trovato qualcosa che corrisponde a come volevo lavorare, e ho costruito il mio. Se è utile per te, grande. Se sei più profondo in questo spazio di quanto io sia, o pensi che ci sia un approccio migliore, mi piacerebbe veramente sentirlo, aprire un problema, inviare una PR, o semplicemente dirmi che ho torto. Il riposo: https://github.com/rezmoss/sbomlyze

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Questo audio è prodotto nella lingua originale della storia!

SBOM Diffing: rendere visibili i cambiamenti di dipendenza prima che facciano male

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

The Ultimate FAQ Guide to HackerNoon's Business Blogging

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

The Fall of OM by Mantra DAO: Accident or Pattern?

I Built an AI Copilot That Thinks in Exploits, Not Prompts

The Ultimate FAQ Guide to HackerNoon's Business Blogging

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

The Fall of OM by Mantra DAO: Accident or Pattern?

I Built an AI Copilot That Thinks in Exploits, Not Prompts

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps