Det tog meget længere tid at finde, hvor Log4j eksisterede i produktion. Log4Sælger De fleste af de berørte Java-projekter havde Log4j som en indirekte afhængighed bundtet med noget andet, ikke valgt direkte. 80% af dem havde det fem eller flere niveauer dybt i deres afhængighedstræ. what's in our software? Patchen var tilgængelig. The problem was inventory Transitionelle afhængigheder Du tilføjer til et Node.js projekt. Express behov Body-parser behov Raw-body behov En pakke bliver til et træ. express body-parser raw-body unpipe 
 
 
 Direkte afhængigheder: Hvad du sætter i package.json Transitive afhængigheder: Alt, hvad disse pakker trækker ind En Forholdet varierer efter økosystem, Maven forstærker afhængigheder mere end npm, hvilket forstærker mere end PyPI, men mønsteret holder,du direkte afhængigheder kan tælle i snesevis. Ivanti beretning Hver pakke i træet har sine egne vedligeholdere, udgivelsespraksis og sikkerhedsposition. Nogle er vedligeholdt af teams hos store virksomheder. Andre er sideprojekter, der ikke har set et kompromis i tre år. Den   I 2018 udnyttede en vedligeholder en populær npm-pakke til en person, der tilbød at hjælpe. som en afhængighed, at pakken indeholdt forvirret kode målretning Copay bitcoin tegnebøger, to millioner ugentlige downloads fortsatte i måneder, før nogen bemærkede event-stream angreb flatmap-stream T ondsindet kode wasnt i Det var et niveau dybere, skjult i en transitiv afhængighed, som ingen kiggede på. event-stream Hvorfor har jeg bygget dette? Pakkeadministratorer installerer afhængigheder, løser versionskonflikter og downloader pakker. De fortæller dig ikke, hvad der har ændret sig mellem i går og i dag. to gange producerer det samme resultat, men du kan ikke nemt sammenligne tirsdagens afhængighedstræ med mandagens npm install Sårbarhedsscannere finder kendte CVEs, de matcher pakkeversioner mod databaser af afslørede sårbarheder. De kan ikke fortælle dig om pakker, der er sårbare endnu, pakker, der kan blive den næste Log4j. Lock filer pin versioner. De sikrer reproducerbare builds og forhindre uventede opdateringer. De hjælper ikke dig med at forstå, hvad 47 nye pakker lige indtastet din codebase, når nogen tilføjede en ny afhængighed, Lock fil diff viser hundredvis af linjer af JSON.. 
 
 Held og lykke med at gennemgå det i en PR Held og lykke med at gennemgå det i en PR Hvad der mangler er sammenligning, generer et øjebliksbillede af dine afhængigheder i dag. Generer en anden i morgen. Diffusér dem. Se præcis, hvad der er ændret: nye pakker, fjernet pakker, versionopdateringer, licensændringer Det er det, der gør det muligt. a. Lister hver komponent i din software, direkte og transitiv, med versioner, licenser og hashes. Sammenlign to SBOM'er, og du får et klart billede af, hvad der er anderledes Software Bill of Materials Jeg ønskede et værktøj til at diff SBOMs, flag mistænkelige ændringer, og håndhæve politikker i CI. Jeg fandt ikke en, der fungerede, som jeg ønskede, så jeg byggede Svævler Setup # 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
 Du vil have brug for en SBOM generator. , som understøtter de fleste pakkeøkosystemer og containerbilleder (de er de bedste) Målet curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
 Målsætning Output eller SPDX-formater. sbomlyze læser begge. CyklonerX Eksempel: Tilføj ekspress Her er et minimalt eksempel på, hvad der sker, når du tilføjer en enkelt afhængighed. 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]
 En linje ændring i package.json tilføjet Udviklingen, projektet gik fra Tilbage til *71 68 3 I et PR t diff shows Den transitive pakker vises ikke nogen steder i kodeanmeldelsen, de er usynlige, medmindre du genererer SBOM'er og sammenligner dem "added express to dependencies" 67 Dette er typisk. De fleste rammer trækker i snesevis af transitive afhængigheder. React, Angular, Django, Rails,de har alle dybe afhængighedstræer.Hver af disse pakker kører i produktion med de samme privilegier som din egen kode. Forstå udbyttet Nogle har du hørt om (body-parser, cookie). Andre har du havent (dunder-proto, gopd, es-object-atoms). De har alle lige adgang til dine applikationer hukommelse, netværk og filsystem. Added components flagpakker, der vises flere gange med forskellige versioner, i denne output, vises som både 2.0.0 og 2.1.3. Forskellige dele af Express har brug for forskellige versioner, og npm installerer begge. får en CVE, skal du spore gennem dit afhængighedstræ for at finde hver sti, der trækker det ind, og derefter opdatere pakkerne langs disse stier. Duplicates ms ms fanger komponenter, hvor hash ændrede sig, men versionen forblev den samme. Dette kan ske legitimt en pakkeholder genopbygger og genpublicerer uden at støde på versionen, det kan også indikere manipulation. Nogen kompromitterer en registreringskonto, skubber ændret kode under et eksisterende versionnummer. Versionen ser uændret ud, men koden er anderledes. Integrity drift Politisk håndhævelse Du kan definere regler og fejlbygge, der overtræder dem. Politikker giver dig mulighed for at kodificere organisatoriske standarder og håndhæve dem automatisk politik.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
 Udgangskode 1 fejler CI 
 
 
 
 
 
 
 
 
 
 
 
 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 på nye pakker max_removed Cap på fjernede pakker max_changed Cap på version ændringer deny_licenses Blokering af specifikke licenser require_licenses Kræver licens info deny_duplicates Fejl med duplikerede versioner Tærsklerne afhænger af din kodebase, et greenfield-projekt kan indstille , En etableret codebase med lockeddown-afhængigheder kan indstille , start løs, observer, hvordan normale PR'er ser ud, så stram max_added: 10 max_added: 3 Licensblokering handler om overensstemmelse.Nogle organisationer kan ikke sende GPL-kode i proprietære produkter, nogle kan ikke bruge AGPL i SaaS-applikationer. Duplicate blokering er strengere, mange legitime afhængighed træer har duplikater. Du kan starte med denne deaktiveret og aktivere det senere som du rydde op din afhængighed træ. Denne integration Her er en GitHub Actions-arbejdsproces, der genererer SBOM'er for både baseafdelingen og PR-afdelingen, og diffuser dem derefter 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
 Arbejdsprocessen tjekker begge grene, genererer en SBOM for hver og sammenligner dem, hvis politikken fejler, PR fejler Udviklere kan se præcis, hvilke pakker der er ændret, og hvorfor bygningen brød sammen. Du kan også køre dette uden en politikfil for at få synlighed uden håndhævelse,diff output vises i CI logs. JSON udgang For skrivning og custom tooling, Udgang til 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
 Du kan opbygge brugerdefinerede checks på toppen af dette, flag pkgs fra specifikke vedligeholdere. Advarsel om pakker med lave download tæller. Cross reference mod en intern allowlist. JSON giver dig dataene; du skriver logikken Billeder af container Containerbilleder indeholder mere end din applikationskode, basisbilledet bringer OS-pakkerne libc, openssl, coreutils.Din applikation tilføjer sin løbetid og afhængigheder, en typisk container har hundredvis af komponenter fra flere økosystemer Syft scanner containerbilleder direkte 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 har 1.393 komponenter. nginx:1.27-alpine har 1.047,ver bunp ændret hundredvis af pakker, Alpine base billedopdateringer, biblioteksopgraderinger, fjernet pkgs Disse ændringer er usynlige, hvis du kun sporer applikationsafhængigheder, du Dockerfile siger ,diff viser en linje ændret, den faktiske ændring til din implementerede software er hundredvis af pkgs. FROM nginx:1.27-alpine sbomlyze fungerer på SBOM-niveau, så det håndterer hvad Syft registrerer OS-pakker, applikationsafhængigheder, binære filer, konfigurationsfiler, alt i en diff Single SBOM stater Når du vil have en oversigt over en SBOM uden sammenligning 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]
 Høje Tællinger tyder på pakker, der kan være uvedligeholdt eller dårligt dokumenteret, legitime pkgs normalt har licensfiler, manglende licenser kan også indikere overensstemmelsesrisiko, du sender kode med uklar juridisk status. "without license" Lav hashdækning begrænser din evne til at verificere integritet. Uden hash kan du ikke opdage, om en pakke blev ændret, efter den blev offentliggjort Uventede pakketyper er værd at undersøge. Hvis din Node.js-applikation viser Python-pakker, trak noget dem ind. Måske et build-værktøj, måske en testramme, måske noget, der ikke burde være der. anbefalinger du har brug for baseline til at diff mod. Inkludere SBOM generation i dit release pipeline. Arkiver dem sammen med dine build artefakter Store SBOMs for each release, syft . -o cyclonedx-json > sbom-v${VERSION}.json
 Når der opstår en hændelse, kan du sammenligne den berørte version med tidligere versioner. Uden at genopbygge gamle bygninger. "when did this package enter our dependency tree?" Selv uden at blokere, hjælper synlighed, anmeldere kan se den fulde indvirkning af afhængighedsændringer. Bliver Denne kontekst ændrer revisionen Diff on every PR. "Added axios" "added axios and 12 transitive dependencies" Når du udtrykker godkendelse ( pakker), skriv ned hvorfor link til sikkerhedsanmeldelsen, bemærk hvem der godkendte det, seks måneder senere, når nogen spørger om afhængigheden, svaret eksisterer Document big additions. 68   diffing viser, hvad der er ændret. Sårbarhedsscanning viser, hvad der er sårbart. Forskellige spørgsmål, begge nyttige. diffing fanger nye afhængigheder, før de akkumulerer CVEs. scanning fanger eksisterende afhængigheder, når CVEs afsløres. Combine with vulnerability scanning. SBOM Se gennem dit afhængighedstræ. Forskningspakker, du ikke genkender. Tjek vedligeholdelsesstatus, sidste komitédato, åbne problemer, busfaktor. Identificer kandidater til udskiftning eller fjernelse. Review quarterly. Sammendrag # 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 er noget, jeg har bygget til min egen daglige arbejdsproces. Mange andre SBOM og afhængighed analyse værktøjer findes; nogle kan passe dine behov bedre, nogle værre. Jeg hævder ikke, at intet andet virker, eller at dette er den eneste løsning. Jeg kiggede rundt, ikke fandt noget, der matcher, hvordan jeg ønskede at arbejde, og bygget min egen. Hvis det er nyttigt for dig, stor. Hvis du finder noget andet, der fungerer bedre for din situation, så brug det. Hvis du er dybere ind i dette rum end jeg er, eller du tror der er en bedre tilgang, vil jeg virkelig gerne høre det, åbne et problem, sende en PR, eller bare fortælle mig, at jeg er forkert. Til hvile: 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

Denne lyd er produceret på historiens originalsprog!

SBOM Diffing: Gør afhængighedsændringer synlige, før de gør ondt

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet MinIO: The HackerNoon Company of the Week

Meet Stellar: HackerNoon Company of the Week

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Bright Data: HackerNoon Company of the Week

Meet MinIO: The HackerNoon Company of the Week

Meet Stellar: HackerNoon Company of the Week

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Bright Data: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps