Unterstützte Ökosysteme

Das ist die eine Liste. Wenn eine andere Seite Ökosysteme nennt, folgt sie dieser Seite.

Abhängigkeits-Scanning

Das Abhängigkeits-Scanning (osv-scanner, bei jedem Pull Request und auf dem Standard-Branch) liest diese Dateien:

Container-Images werden von Trivy gescannt: die Betriebssystempakete und die Sprachpakete in jedem Image. Siehe Container-Image-Scanning.

Auflösung von Maven-Abhängigkeiten

Eine pom.xml nennt nur ihre direkten Abhängigkeiten. Um zu sehen, was diese nach sich ziehen, löst das Abhängigkeits-Scanning jede pom.xml so auf, wie Maven es täte: Eltern-POMs, importierte BOMs, <dependencyManagement>, Properties, Scopes, Ausschlüsse und Versionsbereiche. Es liest nur POMs. Weder Maven noch ein Plugin noch Code aus deinem Repository wird ausgeführt.

• Woher die POMs kommen. Jede POM wird über den Maven-Proxy deiner Organisation gelesen, mit dem Proxy der Plattform als Rückfall. Die eigenen Module eines Multi-Modul-Builds werden aus dem Repository gelesen. In einer POM angegebene <repositories> werden nicht kontaktiert: Ein Artefakt, das nur ein privates Repository hat, wird nicht aufgelöst und wird benannt (unten). Kein Auflösungsdienst außerhalb von fremforge wird gefragt.
• Was das Ergebnis verwendet. Den aufgelösten Baum lesen Abhängigkeitsbefunde, der Status fremforge/dep-scan, die SBOM des Repositorys und Korrektur-Pull-Requests für transitive Abhängigkeiten, sodass sie übereinstimmen.
• Zwischengespeichert. Ein Baum wird 24 Stunden lang wiederverwendet, solange sich die POMs nicht ändern. Advisorys werden bei jedem Scan neu abgeglichen, sodass eine neue Advisory nie durch den Cache verdeckt wird.

Wenn sich eine POM nicht auflösen lässt, sieht sie nie sauber aus. Ihre direkten Abhängigkeiten werden trotzdem geprüft, und:

• der Status fremforge/dep-scan sagt es, auch wenn er grün ist: 1 pom.xml not fully resolved: transitive dependencies not checked;
• der Pull-Request-Kommentar listet die POM unter Nicht vollständig geprüft, mit dem Grund und den Artefakten, die der Proxy nicht hatte, auch wenn es keine Befunde gibt;
• die Seiten für Abhängigkeitsbefunde und SBOMs zeigen Nicht vollständig geprüft, mit einem Link zum Abhängigkeits-Proxy, wenn ein Artefakt fehlt;
• die SBOM trägt es als Hinweis zur Abdeckung (CycloneDX: die Property fremforge:coverage:maven-unresolved und eine Composition incomplete; SPDX: der Creation-Kommentar);
• GET /orgs/{org}/code-security/deps/coverage (Scope findings:read) liefert es für den Standard-Branch. Standardmäßig listet es nur Repositorys, in denen etwas nicht vollständig geprüft ist; all=true listet jedes Repository mit einem Abdeckungseintrag, und repo=<name> filtert auf eines.

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

Der übliche Grund ist ein Artefakt, das dein Maven-Proxy nicht hat, etwa eine interne Bibliothek, die anderswo veröffentlicht wird: Füge dieses Repository als Upstream des Proxys hinzu. Andere Gründe sind ein Proxy, der nicht antwortet, eine Zeitüberschreitung oder ein Build mit mehr als 60 POMs (die übrigen werden gemeldet, nicht aufgelöst).

Bekannte Grenzen. Die Auflösung liest die POMs; sie führt den Build nicht aus. Deshalb:

• wird ein Build, der seine Abhängigkeiten mit einem Plugin umschreibt (Relocation mit maven-shade-plugin, flatten-maven-plugin, eine generierte POM), so geprüft, wie seine POMs ihn angeben, nicht so, wie das Plugin ihn ändert;
• wird ein Profil, das von der Umgebung deiner Build-Maschine abhängt (eine System-Property, eine Datei, das Betriebssystem oder das JDK), womöglich nicht so angewendet, wie dein Build es anwendet.

Für den genauen Baum, den dein Build ausliefert, pushe eine CycloneDX-SBOM aus der CI; auch sie wird abgeglichen.

Terraform- und OpenTofu-Provider

Es gibt keine Advisory-Datenbank für Terraform-Provider, aber ein Provider ist ein Go-Programm. Für jede Provider-Version in einer .terraform.lock.hcl scannt fremforge das Provider-Binary auf die Go-Module, aus denen es gebaut wurde, und meldet deren Advisorys als Abhängigkeitsbefunde des Repositorys:

• Ökosystem Terraform, Paket die Provider-Adresse (zum Beispiel registry.terraform.io/hashicorp/null), Version die gesperrte Version, Manifest die Lock-Datei. Die Zusammenfassung nennt das Go-Modul und seine Version, zum Beispiel google.golang.org/grpc@v1.69.4 (built into the provider).
• Nur das Binary, das die Lock-Datei installiert. Ein Befund wird nur gemeldet, wenn einer der Hashes der Lock-Datei (zh: oder h1:) das gescannte Provider-Zip ist. Eine Lock-Datei, die andere Bytes akzeptiert, erhält keine Befunde für ein Binary, das sie nicht installieren würde.
• Dieselbe Prüfung wie bei jeder Abhängigkeit. Die Befunde durchlaufen deine Abhängigkeitsschwelle, Verwerfungen und den Vergleich mit dem Basis-Branch, sodass ein Pull Request nur durch Befunde blockiert wird, die er hinzufügt.
• Der erste Scan einer Version erfolgt nicht sofort. Eine Version, die fremforge noch nicht gesehen hat, wird in die Warteschlange gestellt, wenn eine Lock-Datei, die sie pinnt, zum ersten Mal gescannt wird, und im Hintergrund gescannt, normalerweise innerhalb einer Stunde. Ihre Befunde erscheinen beim nächsten Scan jedes Repositorys, das sie sperrt; bis dahin hat diese Version keine.
• Erreichbarkeit. Jeder Befund sagt, ob das Provider-Binary eine Funktion einbindet, die die Advisory nennt: erreichbar oder nicht erreichbar, oder unbekannt, wenn sich das nicht entscheiden lässt. Siehe Erreichbarkeit.
• Korrigierte Version. Die korrigierte Version eines Befunds ist das erste Provider-Release, dessen Binary die Advisory nicht mehr enthält, unter den nächsten zehn Releases nach deinem und dem neuesten. fremforge scannt diese Releases auf dieselbe Weise, daher kann es nach dem ersten Scan deiner Version ein bis zwei Stunden dauern, bis sie erscheint. Sie bleibt leer, solange es noch kein solches Release gibt, was häufig ist: Das neueste Release eines Providers liefert oft noch das verwundbare Modul aus.
• Woher das Binary kommt. Das Zip für linux_amd64 wird einmalig über den eigenen Provider-Mirror von fremforge von dem Ort abgerufen, den die Registry des Providers veröffentlicht. Für die Provider von HashiCorp ist das die Release-Seite von HashiCorp, releases.hashicorp.com, die fremforge nicht betreibt: Sie wird nur verwendet, um das öffentliche Provider-Zip abzurufen, nichts über dein Repository wird an sie gesendet, und fremforge behält die gescannte Kopie.

Nicht abgedeckt: Terraform-Module; ein Provider, der vor Go 1.18 gebaut wurde (zum Beispiel hashicorp/null 3.1.0), dessen Binary keine lesbare Modulliste enthält; und die Go-Standardbibliothek, mit der der Provider gebaut wurde. Eine Sicherheitskorrektur für einen Provider wird nicht geöffnet: Aktualisiere die Version in deiner Konfiguration und führe tofu init -upgrade oder terraform init -upgrade aus.

CI-Action-Versionen

Jedes uses: owner/repo@<version> in einer Workflow-Datei direkt unter .forgejo/workflows/, .gitea/workflows/ oder .github/workflows/ wird seit dem 18. Oktober 2026 mit den GitHub-Actions-Advisorys (GHSA) in der eigenen Kopie der OSV-Datenbank von fremforge abgeglichen. Es erfolgt kein Aufruf an GitHub: Die Advisorys stammen aus dieser Kopie und die Version aus deiner Workflow-Datei.

• Die Version ist das Tag (actions/download-artifact@v4.1.2) oder, bei einer auf einen Commit gepinnten Action, der Versionskommentar daneben (actions/download-artifact@<sha> # v4.1.2), so wie Pinning-Werkzeuge ihn schreiben. Eine gepinnte Action ohne einen solchen Kommentar hat keine Version zum Abgleichen.
• Ein Befund ist ein Abhängigkeitsbefund: Ökosystem GitHub Actions, Paket owner/repo, die Workflow-Datei als Manifest. Er durchläuft deine Abhängigkeitsschwelle, Verwerfungen und den Vergleich mit dem Basis-Branch, sodass ein Pull Request in der Prüfung fremforge/dep-scan nur durch Befunde blockiert wird, die er hinzufügt.
• Fehlt die Kopie der GitHub-Actions-Advisorys bei fremforge, schlägt der Abhängigkeits-Scan eines Repositorys, dessen Workflows versionierte Actions nennen, fehl, statt ohne Befunde durchzulaufen.

Nicht abgedeckt: ein Tag nur mit Hauptversion (@v4) oder ein Branch, die keine Version nennen; Workflow-Dateien in Unterverzeichnissen oder außerhalb dieser drei Verzeichnisse, die eigene action.yml von Composite Actions und per Symlink eingebundene Workflow-Dateien. Ob eine Referenz auf einen Commit gepinnt ist, wird separat geprüft; siehe Workflow-Pinning.

Sicherheitskorrekturen

Sicherheitskorrekturen öffnen einen Pull Request für:

• npm, einschließlich Yarn, pnpm und Bun mit bun.lock (nicht die binäre bun.lockb: Führe einmal bun install --save-text-lockfile aus, um umzustellen);
• Go;
• PyPI;
• Maven;
• Gradle mit einer Lockfile, die in einem Job auf dem eigenen Runner deiner Organisation aktualisiert wird;
• NuGet;
• Cargo;
• Composer, composer.json und composer.lock;
• pub, pubspec.yaml und pubspec.lock;
• RubyGems, Gemfile.lock, die in einem Job auf dem eigenen Runner deiner Organisation aktualisiert wird (Bundler liest die Gemfile, die Ruby-Code ist, den fremforge nicht ausführt);
• Hex, mix.lock, die in einem Job auf dem eigenen Runner deiner Organisation aktualisiert wird, im offiziellen Image elixir (Mix liest mix.exs, das Elixir-Code ist);
• CRAN (R), renv.lock, die in einem Job auf dem eigenen Runner deiner Organisation aktualisiert wird, im Image rocker/r-ver: Nur der Eintrag dieses Pakets ändert sich, und eine Korrektur, die das Verschieben anderer Pakete erfordert, wird abgewiesen (siehe CRAN);
• GitHub Actions, die Workflow-Datei: Die Action wird auf die niedrigste Version gehoben, die jede offene Advisory behebt, gepinnt auf den Commit dieses Tags mit dem Tag als Kommentar (@<sha> # v4.1.3). Die Tags werden aus dem Action-Mirror auf frem.sh gelesen, nie von github.com;
• Basis-Images: die FROM-Zeile eines Dockerfiles, innerhalb derselben Hauptversion.

Sie beheben direkte Abhängigkeiten und diese transitiven (siehe Transitive Abhängigkeiten):

• npm mit package-lock.json, gepinnt mit overrides;
• pnpm mit pnpm-lock.yaml (Lockfile-Version 9.0), gepinnt mit overrides;
• Yarn 1 mit yarn.lock, gepinnt mit resolutions (Yarn 2 und neuer werden nicht unterstützt);
• PyPI mit uv.lock oder poetry.lock, durch Verschieben des Lock-Eintrags;
• Maven, gepinnt mit <dependencyManagement> in der pom.xml, aus der der Befund stammt (oder der Root-pom.xml bei einem Paket, das in einer hochgeladenen SBOM gesehen wurde);
• Gradle mit gradle.lockfile, gepinnt mit einem Dependency Constraint;
• Go-Module, die in go.mod mit // indirect markiert sind;
• Composer-Pakete, die composer.json nicht nennt, durch Aktualisieren von composer.lock in einem Job auf dem eigenen Runner deiner Organisation;
• RubyGems, Hex und CRAN: Jede Korrektur ist eine Aktualisierung der Lock-Datei, sodass ein Paket, das ein anderes Paket mitbringt, genauso behoben wird wie eines, das das Manifest nennt.

Nicht behoben, jeweils mit Grund am Befund: bun.lockb, die nur Bun umschreiben kann, sowie pub- und Bun-Pakete, die das Manifest nicht nennt. Für jedes andere Ökosystem, Swift Package Manager eingeschlossen, antwortet eine Korrekturanforderung mit not yet supported. Conan hat keine Advisorys, die behoben werden könnten (siehe die Tabelle oben).

Erreichbarkeit

Die Erreichbarkeit liefert ein Urteil für:

Jedes andere Ökosystem erhält das Urteil unbekannt.

Abhängigkeits-Proxy

Der Abhängigkeits-Proxy liefert npm-, PyPI-, Maven-, NuGet-, Go-, Cargo-, Helm- und RPM-Pakete, Container-Images sowie Terraform- und OpenTofu-Module aus.

Nicht abgedeckt

Terraform-Module und Helm-Chart-Versionen werden nicht mit Schwachstellen-Advisorys abgeglichen. CI-Action-Versionen schon; siehe CI-Action-Versionen. Terraform- und OpenTofu-Provider ebenfalls, anhand ihrer Binarys; siehe Terraform- und OpenTofu-Provider. Die Container-Images, die ein Helm-Chart ausrollt, ebenfalls; siehe Images, die deine Helm-Charts ausrollen. Infrastructure-as-Code-Dateien erhalten nur Prüfungen auf Fehlkonfigurationen, in ihrer eigenen Prüfung fremforge/iac-scan; siehe IaC-Scanning. Ob Action-Referenzen auf einen Commit gepinnt sind, wird ebenfalls geprüft; siehe Workflow-Pinning.