Hva er en avhengighetsgraf?

Noder, kanter og stier

I en avhengighetsgraf er hver pakke en node, og hvert «er avhengig av» er en kant fra én pakke til en annen. Prosjektet ditt ligger øverst. De direkte avhengighetene er én kant unna, og de transitive avhengighetene er alt lenger ned. Ruten fra prosjektet ditt til en gitt pakke er avhengighetsstien dens, og én pakke kan ha flere.

Graf, tre eller liste

De samme avhengighetene kan vises på tre måter, og hver av dem svarer på et annet spørsmål.

Visning	Hva den viser	Hva den mister
Flat liste	Hver pakke én gang, med versjon	Hvorfor hver pakke er der
Tre	Hver sti fra prosjektet ditt, slik pakkebehandlere skriver det ut	Delte pakker gjentas, så treet ser større ut enn det er
Graf	Hver pakke én gang, med en kant fra hver forelder	Vanskeligere å lese med øyet uten et visningsverktøy

Delte pakker er grunnen til at grafer er viktige. Når to av avhengighetene dine trenger samme pakke, danner den en diamant: én node med to foreldre. For å rette en sårbarhet i den må du kjenne begge stiene, fordi hver av foreldrene kan feste den gamle versjonen.

Dette bruker du en avhengighetsgraf til

• Finne veien til rettingen. En sårbar transitiv pakke rettes ved å oppgradere eller overstyre noe på stien dens. Grafen viser hvilken direkte avhengighet du må flytte.
• Måle skadeomfanget. Når en advisory kommer, viser grafen hvilke av de direkte avhengighetene, tjenestene og produktene dine som fører til den berørte pakken.
• Gå gjennom lisenser. En copyleft-lisens dypt nede i grafen gjelder like mye som en øverst, og stien forteller deg hvilken avhengighet som introduserte den.
• Planlegge oppgraderinger. En større oppgradering av én pakke endrer alt under den. Grafen viser hvor mye av treet ditt som flytter seg.
• Oppdage risikokonsentrasjon. En liten, uvedlikeholdt pakke som mange stier går gjennom, er et enkeltfeilpunkt.

Slik får du en avhengighetsgraf

Fra pakkebehandleren. Alle pakkebehandlere skriver ut det oppløste treet, og de fleste kan forklare hvorfor en enkelt pakke er der. Transitive avhengigheter lister opp kommandoene for npm, pnpm, Python, Go, Rust, Maven og Gradle.

Fra GitHub. Avhengighetsgrafen under fanen Insights i et repositorium er et sammendrag av manifestene og lockfilene i repositoriet, pluss avhengigheter sendt inn via API-et for dependency submission. For økosystemer som støtter det, viser GitHub den transitive stien som brakte inn hver avhengighet, og den kan eksportere grafen som en SBOM.

Fra en SBOM. CycloneDX registrerer grafen i en dependencies-seksjon, der hver komponent lister opp hva den er avhengig av. SPDX bruker DEPENDS_ON-relasjoner mellom pakker. En CycloneDX-graf for en del av en Express-app ser slik ut:

"dependencies": [
  { "ref": "my-app", "dependsOn": ["express"] },
  { "ref": "express", "dependsOn": ["body-parser", "send"] },
  { "ref": "body-parser", "dependsOn": ["raw-body", "debug"] },
  { "ref": "send", "dependsOn": ["mime-types", "debug"] }
]

Her dukker debug opp under to foreldre: en diamant. Mange SBOM-er utelater relasjonene og lister bare opp komponenter. Da beholder du oversikten, men mister hver eneste sti.

En graf er bare så god som kilden

De fleste avhengighetsgrafer bygges ut fra manifester og lockfiler, så de viser treet pakkebehandleren planla. De viser ikke pakker gjenopprettet fra CI-cacher, byggeverktøy installert av oppsettsteg eller kode hentet av installasjonsskript og nedlastinger, og de kan ikke si om bygget installerte nøyaktig det som står i lockfilen. Se hvorfor en lockfile ikke viser hva som ble levert.

Avhengighetsgrafer i CRACI

CRACI bygger grafen sin ut fra selve bygget. Det er en GitHub Actions-runner som registrerer hver pakke hver jobb henter, på alle nivåer i treet og inkludert pakker gjenopprettet fra CI-cacher, i en SBOM som angir sin egen fullstendighet.

• En grafvisning av SBOM-en. Avhengighetsvisningen viser avhengighetslagene i SBOM-en i visningene Pivot, Graph, Blob, Chord og Sunburst, med filtre for dybde og alvorlighetsgrad.
• Eksporter med hele treet. Eksporter i CycloneDX og SPDX inkluderer transitive avhengigheter, hver med sin deklarerte lisens.
• Berørte bygg over tid. Når en ny sårbarhet dukker opp, viser byggehistorikken hvilke tidligere bygg som inneholdt den sårbare pakken, direkte eller transitiv.

Se SBOM-generering i CRACI, eller book en demo for å utforske grafen til et av dine egne bygg.

Avhengighetsgrafer: ofte stilte spørsmål

Hva er en avhengighetsgraf?

En avhengighetsgraf er et kart over hver pakke programvaren din er avhengig av, med en pil fra hver pakke til pakkene den trenger. Den viser ikke bare hva som er i programvaren din, men også hvorfor: stien fra koden din til hver transitive avhengighet.

Hva er forskjellen på et avhengighetstre og en avhengighetsgraf?

Et tre viser hver sti for seg, så en pakke som to foreldre trenger, dukker opp to ganger. En graf viser hver pakke én gang, med en kant fra hver forelder som trenger den. Pakkebehandlere skriver ut trær fordi de er lette å lese; verktøy som analyserer konsekvenser, jobber med grafen.

Inneholder en SBOM en avhengighetsgraf?

Det kan den. CycloneDX har en dependencies-seksjon der hver komponent lister opp komponentene den er avhengig av, og SPDX uttrykker det samme med DEPENDS_ON-relasjoner. Mange SBOM-er utelater relasjonene og lister bare opp komponenter, og da går stiene tapt.

Hvordan ser jeg avhengighetsgrafen til et GitHub-repositorium?

Åpne fanen Insights i repositoriet og velg Dependency graph. GitHub bygger den ut fra manifestene og lockfilene i repositoriet, pluss det som sendes inn via API-et for dependency submission, og for økosystemer som støtter det, viser den stien som brakte inn hver transitive avhengighet.

Hva er en diamantavhengighet?

To av avhengighetene dine er begge avhengige av samme pakke, så grafen danner en diamant. Hvis de trenger inkompatible versjoner av den, må pakkebehandleren installere to kopier eller feile, og det er en av måtene en graf blir vanskeligere å håndtere enn den ser ut.