Støttede økosystemer

Dette er den ene listen. Når en annen side nevner økosystemer, følger den denne siden.

Skanning av avhengigheter

Skanning av avhengigheter (osv-scanner, på hver pull request og på standardbranchen) leser disse filene:

Containerimager skannes av Trivy: operativsystempakkene og språkpakkene i hvert image. Se Skanning av containerimager.

Oppløsning av Maven-avhengigheter

En pom.xml nevner bare de direkte avhengighetene. For å se hva de trekker inn, løser skanningen av avhengigheter opp hver pom.xml slik Maven ville gjort: foreldre-pom-er, importerte BOM-er, <dependencyManagement>, properties, scopes, ekskluderinger og versjonsintervaller. Den leser bare pom-er. Verken Maven, plugins eller kode fra repositoryet ditt kjøres.

• Hvor pom-ene kommer fra. Hver pom leses gjennom organisasjonens Maven-proxy, med plattformens proxy som reserveløsning. Modulene i et bygg med flere moduler leses fra repositoryet. <repositories> som er deklarert i en pom, kontaktes ikke: en artefakt som bare finnes i et privat repository, blir ikke løst opp, og den navngis (se under). Ingen oppløsningstjeneste utenfor fremforge blir spurt.
• Hva som bruker resultatet. Det oppløste treet er det funn i avhengigheter, statusen fremforge/dep-scan, repositoryets SBOM og pull requests som retter transitive avhengigheter leser, slik at de stemmer overens.
• Bufret. Et tre gjenbrukes i 24 timer så lenge pom-ene er uendret. Sårbarhetsvarsler matches på nytt ved hver skanning, så et nytt sårbarhetsvarsel skjules aldri av bufferen.

En pom som ikke kan løses opp, fremstår aldri som ren. De direkte avhengighetene sjekkes likevel, og:

• statusen fremforge/dep-scan sier det, også når den er grønn: 1 pom.xml not fully resolved: transitive dependencies not checked;
• kommentaren på pull requesten lister pom-en under Ikke fullstendig sjekket, med årsaken og artefaktene proxyen ikke hadde, også når det ikke finnes funn;
• sidene for funn i avhengigheter og SBOM viser Ikke fullstendig sjekket, med en lenke til avhengighetsproxyen når en artefakt mangler;
• SBOM-en har det med som en dekningsmerknad (CycloneDX: property-en fremforge:coverage:maven-unresolved og en incomplete-komposisjon; SPDX: kommentaren for opprettelsen);
• GET /orgs/{org}/code-security/deps/coverage (scope findings:read) returnerer det for standardbranchen. Som standard lister den bare repositoryer med noe som ikke er fullstendig sjekket; all=true lister alle repositoryer med en dekningspost, og repo=<name> filtrerer til ett.

curl -sS -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  "https://frem.sh/_app/api/v1/orgs/<org>/code-security/deps/coverage"

Den vanligste årsaken er en artefakt som Maven-proxyen din ikke har, for eksempel et internt bibliotek som er publisert et annet sted: legg til det repositoryet som upstream for proxyen. Andre årsaker er at proxyen ikke svarer, et tidsavbrudd eller et bygg med mer enn 60 pom-er (resten rapporteres, men løses ikke opp).

Kjente begrensninger. Oppløsningen leser pom-ene; den kjører ikke bygget. Derfor:

• sjekkes et bygg som skriver om avhengighetene sine med en plugin (relokering med maven-shade-plugin, flatten-maven-plugin, en generert pom) slik pom-ene deklarerer det, ikke slik pluginen endrer det;
• blir en profil som avhenger av miljøet på byggmaskinen din (en system property, en fil, operativsystemet eller JDK-en), kanskje ikke brukt slik bygget ditt bruker den.

For nøyaktig det treet bygget ditt leverer, kan du pushe en CycloneDX-SBOM fra CI; den matches også.

Terraform- og OpenTofu-providere

Det finnes ingen database med sårbarhetsvarsler for Terraform-providere, men en provider er et Go-program. For hver provider-versjon i en .terraform.lock.hcl skanner fremforge provider-binærfilen etter Go-modulene den ble bygget fra, og rapporterer sårbarhetsvarslene deres som funn i avhengighetene til repositoryet:

• Økosystem Terraform, pakke provider-adressen (for eksempel registry.terraform.io/hashicorp/null), versjon den låste versjonen, manifest låsefilen. Sammendraget navngir Go-modulen og versjonen, for eksempel google.golang.org/grpc@v1.69.4 (built into the provider).
• Bare binærfilen låsefilen installerer. Et funn rapporteres bare når en av låsefilens hasher (zh: eller h1:) er provider-zip-filen som ble skannet. En låsefil som godtar andre bytes, får ingen funn for en binærfil den ikke ville installert.
• Samme sjekk som for alle avhengigheter. Funnene går gjennom terskelen din for avhengigheter, avvisninger og sammenligningen med basebranchen, så en pull request blokkeres bare av funn den selv legger til.
• Den første skanningen av en versjon skjer ikke umiddelbart. En versjon fremforge ikke har sett før, settes i kø når en låsefil som låser den, skannes første gang, og skannes i bakgrunnen, vanligvis innen en time. Funnene vises ved neste skanning av hvert repository som låser den; inntil da har versjonen ingen.
• Nåbarhet. Hvert funn sier om provider-binærfilen lenker inn en funksjon som sårbarhetsvarselet navngir: reachable eller not reachable, eller unknown når det ikke kan avgjøres. Se Nåbarhet.
• Rettet versjon. Den rettede versjonen for et funn er den første provider-utgivelsen der binærfilen ikke lenger har sårbarheten, blant de ti neste utgivelsene etter din og den nyeste. fremforge skanner disse utgivelsene på samme måte, så det kan ta en time eller to etter den første skanningen av versjonen din før den vises. Den forblir tom når ingen slik utgivelse finnes ennå, noe som er vanlig: den nyeste utgivelsen av en provider leverer ofte fortsatt den sårbare modulen.
• Hvor binærfilen kommer fra. linux_amd64-zip-filen hentes én gang, gjennom fremforges eget provider-speil, fra stedet providerens register publiserer. For HashiCorps providere er det HashiCorps utgivelsesside, releases.hashicorp.com, som fremforge ikke drifter: den brukes bare til å hente den offentlige provider-zip-filen, ingenting om repositoryet ditt sendes dit, og fremforge beholder kopien den skannet.

Ikke dekket: Terraform-moduler; en provider bygget før Go 1.18 (for eksempel hashicorp/null 3.1.0), der binærfilen ikke har noen modulliste å lese; og Go-standardbiblioteket provideren ble bygget med. Det åpnes ingen sikkerhetsrettelse for en provider: oppdater versjonen i konfigurasjonen din og kjør tofu init -upgrade eller terraform init -upgrade.

Versjoner av CI-actions

Hver uses: owner/repo@<version> i en workflow-fil direkte under .forgejo/workflows/, .gitea/workflows/ eller .github/workflows/ matches mot sårbarhetsvarslene for GitHub Actions (GHSA) i fremforges egen kopi av OSV-databasen, siden 18. oktober 2026. Det gjøres ingen kall til GitHub: sårbarhetsvarslene kommer fra den kopien og versjonen fra workflow-filen din.

• Versjonen er taggen (actions/download-artifact@v4.1.2), eller, for en action som er låst til en commit, versjonskommentaren ved siden av (actions/download-artifact@<sha> # v4.1.2), som er slik låseverktøy skriver den. En låst action uten en slik kommentar har ingen versjon å matche.
• Et funn er et funn i avhengigheter: økosystem GitHub Actions, pakke owner/repo, workflow-filen som manifest. Det går gjennom terskelen din for avhengigheter, avvisninger og sammenligningen med basebranchen, så en pull request blokkeres bare av funn den selv legger til, i sjekken fremforge/dep-scan.
• Hvis fremforges kopi av sårbarhetsvarslene for GitHub Actions mangler, feiler skanningen av avhengigheter for et repository med workflower som nevner versjonerte actions, i stedet for å bestå uten funn.

Ikke dekket: en tagg med bare hovedversjon (@v4) eller en branch, som ikke navngir noen versjon; workflow-filer i underkataloger eller utenfor disse tre katalogene, sammensatte actions’ egen action.yml, og workflow-filer som er symbolske lenker. Om en referanse er låst til en commit, sjekkes separat; se Låsing av workflower.

Sikkerhetsrettelser

Sikkerhetsrettelser åpner en pull request for:

• npm, inkludert Yarn, pnpm og Bun med bun.lock (ikke den binære bun.lockb: kjør bun install --save-text-lockfile én gang for å bytte);
• Go;
• PyPI;
• Maven;
• Gradle med låsefil, som oppdateres i en jobb på organisasjonens egen runner;
• NuGet;
• Cargo;
• Composer, composer.json og composer.lock;
• pub, pubspec.yaml og pubspec.lock;
• RubyGems, Gemfile.lock, som oppdateres i en jobb på organisasjonens egen runner (Bundler leser Gemfile, som er Ruby-kode fremforge ikke kjører);
• Hex, mix.lock, som oppdateres i en jobb på organisasjonens egen runner, i det offisielle elixir-imaget (Mix leser mix.exs, som er Elixir-kode);
• CRAN (R), renv.lock, som oppdateres i en jobb på organisasjonens egen runner, i rocker/r-ver-imaget: bare posten for den pakken endres, og en rettelse som krever at andre pakker flyttes, avvises (se CRAN);
• GitHub Actions, workflow-filen: actionen flyttes til den laveste versjonen som retter alle åpne sårbarhetsvarsler, låst til taggens commit med taggen som kommentar (@<sha> # v4.1.3). Taggene leses fra action-speilet på frem.sh, aldri fra github.com;
• base-imager: FROM-linjen i en Dockerfile, innenfor samme hovedversjon.

De retter direkte avhengigheter, og disse transitive (se Transitive avhengigheter):

• npm med package-lock.json, låst med overrides;
• pnpm med pnpm-lock.yaml (låsefilversjon 9.0), låst med overrides;
• Yarn 1 med yarn.lock, låst med resolutions (Yarn 2 og nyere støttes ikke);
• PyPI med uv.lock eller poetry.lock, ved å flytte oppføringen i låsefilen;
• Maven, låst med <dependencyManagement> i den pom.xml funnet kom fra (eller rot-pom.xml, for en pakke som er sett i en opplastet SBOM);
• Gradle med gradle.lockfile, låst med en avhengighetsbegrensning (constraint);
• Go-moduler merket // indirect i go.mod;
• Composer-pakker som composer.json ikke nevner, ved å oppdatere composer.lock i en jobb på organisasjonens egen runner;
• RubyGems, Hex og CRAN: hver rettelse er en oppdatering av låsefilen, så en pakke som en annen pakke trekker inn, rettes på samme måte som en pakke manifestet nevner.

Ikke rettet, hver med årsaken angitt på funnet: bun.lockb, som bare Bun kan skrive om, og pub- og Bun-pakker som manifestet ikke nevner. For alle andre økosystemer, også Swift Package Manager, svarer en forespørsel om rettelse not yet supported. Conan har ingen sårbarhetsvarsler å rette (se tabellen over).

Nåbarhet

Nåbarhet gir en vurdering for:

Alle andre økosystemer får vurderingen unknown.

Avhengighetsproxy

Avhengighetsproxyen leverer npm-, PyPI-, Maven-, NuGet-, Go-, Cargo-, Helm- og RPM-pakker, containerimager og Terraform- og OpenTofu-moduler.

Ikke dekket

Terraform-moduler og versjoner av Helm-charts sjekkes ikke mot sårbarhetsvarsler. Versjoner av CI-actions gjør det; se Versjoner av CI-actions. Terraform- og OpenTofu-providere gjør det, ut fra binærfilene; se Terraform- og OpenTofu-providere. Containerimagene et Helm-chart ruller ut, gjør det; se Imager som Helm-chartene dine ruller ut. Infrastruktur-som-kode-filer får bare sjekker for feilkonfigurasjon, i sin egen sjekk, fremforge/iac-scan; se IaC-skanning. Om action-referanser er låst til en commit, sjekkes også; se Låsing av workflower.