Vad är en beroendegraf?

Noder, kanter och vägar

I en beroendegraf är varje paket en nod, och varje ”är beroende av” är en kant från ett paket till ett annat. Ditt projekt ligger högst upp. Dess direkta beroenden ligger en kant bort, och dess transitiva beroenden är allt längre ner. Vägen från ditt projekt till ett paket är paketets beroendeväg, och ett paket kan ha flera.

Graf, träd eller lista

Samma beroenden kan visas på tre sätt, och vart och ett besvarar en annan fråga.

Vy	Vad den visar	Vad den tappar
Platt lista	Varje paket en gång, med sin version	Varför varje paket finns där
Träd	Varje väg från ditt projekt, så som pakethanterare skriver ut den	Delade paket upprepas, så trädet överdriver storleken
Graf	Varje paket en gång, med en kant från varje förälder	Svårare att läsa med blotta ögat utan ett visningsverktyg

Delade paket är skälet till att grafer spelar roll. När två av dina beroenden behöver samma paket bildas en diamant: en nod med två föräldrar. För att åtgärda en sårbarhet i paketet behöver du känna till båda vägarna, eftersom vilken förälder som helst kan låsa den gamla versionen.

Vad du använder en beroendegraf till

• Hitta vägen till åtgärden. Ett sårbart transitivt paket åtgärdas genom att uppgradera eller åsidosätta något på dess väg. Grafen visar vilket direkt beroende som ska ändras.
• Mäta påverkansradien. När ett säkerhetsmeddelande dyker upp visar grafen vilka av dina direkta beroenden, tjänster och produkter som leder till det berörda paketet.
• Granska licenser. En copyleft-licens djupt ner i grafen gäller lika mycket som en högst upp, och vägen visar vilket beroende som förde in den.
• Planera uppgraderingar. En större uppgradering av ett paket ändrar allt under det. Grafen visar hur mycket av ditt träd som ändras.
• Upptäcka riskkoncentration. Ett litet paket utan underhåll som många vägar går igenom är en enskild felpunkt.

Så får du en beroendegraf

Från din pakethanterare. Alla pakethanterare skriver ut det upplösta trädet, och de flesta kan förklara varför ett enskilt paket finns där. Transitiva beroenden listar kommandona för npm, pnpm, Python, Go, Rust, Maven och Gradle.

Från GitHub. Beroendegrafen under ett repos flik Insights är en sammanställning av manifesten och lockfilerna i repot, plus beroenden som skickats in via dependency submission API. För ekosystem som stöder det visar GitHub den transitiva väg som drog in varje beroende, och grafen kan exporteras som en SBOM.

Från en SBOM. CycloneDX registrerar grafen i en dependencies-sektion, där varje komponent listar vad den är beroende av. SPDX använder DEPENDS_ON-relationer mellan paket. En CycloneDX-graf för en del av en Express-app ser ut så här:

"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"] }
]

Här visas debug under två föräldrar: en diamant. Många SBOM:er utelämnar relationerna och listar bara komponenter, vilket behåller förteckningen men gör att alla vägar går förlorade.

En graf är bara så bra som sin källa

De flesta beroendegrafer byggs från manifest och lockfiler, så de visar trädet som pakethanteraren planerade. De visar inte paket som återställts från CI-cachar, byggverktyg som installerats av setup-steg eller kod som hämtats av installationsskript och nedladdningar, och de kan inte avgöra om bygget installerade exakt det som står i lockfilen. Se varför en lockfile inte är en registrering av vad som levererades.

Beroendegrafer i CRACI

CRACI bygger sin graf från själva bygget. Det är en GitHub Actions-runner som registrerar varje paket som varje jobb hämtar, i alla led av trädet och inklusive paket som återställs från CI-cachar, i en SBOM som anger sin egen fullständighet.

• En grafvy av SBOM:en. Beroendevyn visar SBOM:ens beroendelager i vyerna Pivot, Graph, Blob, Chord och Sunburst, med filter för djup och allvarlighetsgrad.
• Exporter med hela trädet. Exporter i CycloneDX och SPDX inkluderar transitiva beroenden, vart och ett med sin deklarerade licens.
• Berörda byggen över tid. När en ny sårbarhet dyker upp visar bygghistoriken vilka tidigare byggen som innehöll det sårbara paketet, direkt eller transitivt.

Se SBOM-generering i CRACI, eller boka en demo för att utforska grafen för ett av dina egna byggen.

Beroendegrafer: vanliga frågor

Vad är en beroendegraf?

En beroendegraf är en karta över alla paket som din programvara är beroende av, med en pil från varje paket till de paket det behöver. Den visar inte bara vad som finns i din programvara utan också varför: vägen från din kod till varje transitivt beroende.

Vad är skillnaden mellan ett beroendeträd och en beroendegraf?

Ett träd visar varje väg för sig, så ett paket som behövs av två föräldrar visas två gånger. En graf visar varje paket en gång, med en kant från varje förälder som behöver det. Pakethanterare skriver ut träd eftersom de är lätta att läsa; verktyg som analyserar påverkan arbetar med grafen.

Innehåller en SBOM en beroendegraf?

Det kan den göra. CycloneDX har en sektion med beroenden där varje komponent listar de komponenter den är beroende av, och SPDX uttrycker samma sak med DEPENDS_ON-relationer. Många SBOM:er utelämnar relationerna och listar bara komponenter, vilket gör att vägarna går förlorade.

Hur ser jag beroendegrafen för ett GitHub-repo?

Öppna repots flik Insights och välj Dependency graph. GitHub bygger den från manifesten och lockfilerna i repot, plus allt som skickats in via dess dependency submission API, och för ekosystem som stöder det visas vägen som drog in varje transitivt beroende.

Vad är ett diamantberoende?

Två av dina beroenden är beroende av samma paket, så grafen bildar en diamant. Om de behöver inkompatibla versioner av paketet måste pakethanteraren installera två kopior eller misslyckas, vilket är ett av skälen till att en graf blir svårare att hantera än den ser ut att vara.