Ondersteunde ecosystemen

Dit is de enige lijst. Als een andere pagina ecosystemen noemt, volgt die deze pagina.

Afhankelijkheden scannen

Het scannen van afhankelijkheden (osv-scanner, bij elke pull request en op de standaardbranch) leest deze bestanden:

Containerimages worden door Trivy gescand: de besturingssysteempakketten en de taalpakketten in elk image. Zie Containerimages scannen.

Maven-afhankelijkheden oplossen

Een pom.xml noemt alleen zijn directe afhankelijkheden. Om te zien wat die binnenhalen, lost de afhankelijkheidsscan elke pom.xml op zoals Maven dat zou doen: parent-poms, geïmporteerde BOM’s, <dependencyManagement>, properties, scopes, exclusions en versiebereiken. Er worden alleen poms gelezen. Er draait geen Maven, geen plugin en geen code uit je repository.

• Waar de poms vandaan komen. Elke pom wordt gelezen via de Maven-proxy van je organisatie, met de proxy van het platform als terugvaloptie. De eigen modules van een build met meerdere modules worden uit de repository gelezen. <repositories> die in een pom zijn gedeclareerd, worden niet benaderd: een artefact dat alleen in een privérepository staat, wordt niet opgelost en wordt wel genoemd (zie hieronder). Er wordt geen oplosdienst buiten fremforge geraadpleegd.
• Wat het resultaat gebruikt. De opgeloste boom is wat afhankelijkheidsbevindingen, de status fremforge/dep-scan, de SBOM van de repository en pull requests voor transitieve fixes lezen, zodat ze overeenkomen.
• Gecachet. Een boom wordt 24 uur hergebruikt zolang de poms niet veranderen. Advisories worden bij elke scan opnieuw vergeleken, dus een nieuwe advisory wordt nooit door de cache verborgen.

Een pom die niet kan worden opgelost, komt nooit als schoon uit de controle. Zijn directe afhankelijkheden worden nog steeds gecontroleerd, en:

• de status fremforge/dep-scan meldt het, ook als hij groen is: 1 pom.xml not fully resolved: transitive dependencies not checked;
• het commentaar op de pull request noemt de pom onder Niet volledig gecontroleerd, met de reden en de artefacten die de proxy niet had, ook als er geen bevindingen zijn;
• de pagina’s met afhankelijkheidsbevindingen en SBOM’s tonen Niet volledig gecontroleerd, met een link naar de dependency proxy als er een artefact ontbreekt;
• de SBOM bevat het als dekkingsnotitie (CycloneDX: de property fremforge:coverage:maven-unresolved en een incomplete-compositie; SPDX: het commentaar bij het aanmaken);
• GET /orgs/{org}/code-security/deps/coverage (scope findings:read) geeft het terug voor de standaardbranch. Standaard toont het alleen repository’s met iets wat niet volledig is gecontroleerd; all=true toont elke repository met een dekkingsrecord, en repo=<name> filtert op één repository.

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

De gebruikelijke reden is een artefact dat je Maven-proxy niet heeft, zoals een interne bibliotheek die ergens anders is gepubliceerd: voeg die repository toe als upstream van de proxy. Andere redenen zijn een proxy die niet antwoordt, een time-out, of een build met meer dan 60 poms (de rest wordt gemeld, niet opgelost).

Bekende beperkingen. Het oplossen leest de poms; het voert de build niet uit. Dus:

• een build die zijn afhankelijkheden met een plugin herschrijft (relocatie met maven-shade-plugin, flatten-maven-plugin, een gegenereerde pom) wordt gecontroleerd zoals de poms hem declareren, niet zoals de plugin hem verandert;
• een profiel dat afhangt van de omgeving van je buildmachine (een system property, een bestand, het besturingssysteem of de JDK) wordt mogelijk niet toegepast zoals je build het toepast.

Voor de exacte boom die je build uitlevert, push je een CycloneDX-SBOM vanuit CI; die wordt ook vergeleken.

Terraform- en OpenTofu-providers

Er bestaat geen advisorydatabase voor Terraform-providers, maar een provider is een Go-programma. Voor elke providerversie in een .terraform.lock.hcl scant fremforge de providerbinary op de Go-modules waaruit hij is gebouwd, en meldt hun advisories als afhankelijkheidsbevindingen van de repository:

• Ecosysteem Terraform, pakket het adres van de provider (bijvoorbeeld registry.terraform.io/hashicorp/null), versie de vastgelegde versie, manifest het lockbestand. De samenvatting noemt de Go-module en haar versie, bijvoorbeeld google.golang.org/grpc@v1.69.4 (built into the provider).
• Alleen de binary die de lock installeert. Een bevinding wordt alleen gemeld als een van de hashes van de lock (zh: of h1:) de providerzip is die is gescand. Een lock die andere bytes accepteert, krijgt geen bevindingen voor een binary die hij niet zou installeren.
• Dezelfde controle als voor elke afhankelijkheid. De bevindingen gaan door je drempel voor afhankelijkheden, je negeringen en de vergelijking met de basisbranch, zodat een pull request alleen wordt geblokkeerd door bevindingen die hij toevoegt.
• De eerste scan van een versie is niet direct. Een versie die fremforge nog niet eerder heeft gezien, wordt in de wachtrij gezet zodra een lock die hem vastpint voor het eerst wordt gescand, en op de achtergrond gescand, meestal binnen het uur. De bevindingen verschijnen bij de volgende scan van elke repository die hem vastpint; tot dan heeft die versie er geen.
• Bereikbaarheid. Elke bevinding vermeldt of de providerbinary een functie linkt die de advisory noemt: bereikbaar of niet bereikbaar, of onbekend als dat niet kan worden bepaald. Zie Bereikbaarheid.
• Gefixte versie. De gefixte versie van een bevinding is de eerste providerrelease waarvan de binary de advisory niet meer bevat, binnen de tien releases na de jouwe en de nieuwste. fremforge scant die releases op dezelfde manier, dus het kan na de eerste scan van je versie een uur of twee duren voordat hij verschijnt. Hij blijft leeg als zo’n release nog niet bestaat, wat vaak voorkomt: de nieuwste release van een provider bevat vaak nog de kwetsbare module.
• Waar de binary vandaan komt. De linux_amd64-zip wordt één keer opgehaald, via de eigen providermirror van fremforge, van de locatie die de registry van de provider publiceert. Voor de providers van HashiCorp is dat de releasesite van HashiCorp, releases.hashicorp.com, die fremforge niet beheert: die wordt alleen gebruikt om de openbare providerzip op te halen, er wordt niets over je repository naartoe gestuurd, en fremforge bewaart de kopie die het heeft gescand.

Niet gedekt: Terraform-modules; een provider die is gebouwd vóór Go 1.18 (bijvoorbeeld hashicorp/null 3.1.0), waarvan de binary geen modulelijst bevat om te lezen; en de Go-standaardbibliotheek waarmee de provider is gebouwd. Voor een provider wordt geen beveiligingsfix geopend: werk de versie in je configuratie bij en voer tofu init -upgrade of terraform init -upgrade uit.

Versies van CI-actions

Elke uses: owner/repo@<version> in een workflowbestand dat direct onder .forgejo/workflows/, .gitea/workflows/ of .github/workflows/ staat, wordt sinds 18 oktober 2026 vergeleken met de GitHub Actions-advisories (GHSA) in de eigen kopie van de OSV-database van fremforge. Er wordt geen aanroep naar GitHub gedaan: de advisories komen uit die kopie en de versie uit je workflowbestand.

• De versie is de tag (actions/download-artifact@v4.1.2) of, voor een action die aan een commit is vastgepind, het versiecommentaar ernaast (actions/download-artifact@<sha> # v4.1.2), zoals pinningtools het schrijven. Een vastgepinde action zonder zo’n commentaar heeft geen versie om mee te vergelijken.
• Een bevinding is een afhankelijkheidsbevinding: ecosysteem GitHub Actions, pakket owner/repo, het workflowbestand als manifest. Ze gaat door je drempel voor afhankelijkheden, je negeringen en de vergelijking met de basisbranch, zodat een pull request in de controle fremforge/dep-scan alleen wordt geblokkeerd door bevindingen die hij toevoegt.
• Als de kopie van fremforge van de GitHub Actions-advisories ontbreekt, faalt de afhankelijkheidsscan van een repository waarvan de workflows actions met een versie noemen, in plaats van zonder bevindingen te slagen.

Niet gedekt: een tag met alleen een hoofdversie (@v4) of een branch, die geen versie noemt; workflowbestanden in submappen of buiten die drie mappen, de eigen action.yml van composite actions, en workflowbestanden die een symlink zijn. Of een verwijzing aan een commit is vastgepind, wordt apart gecontroleerd; zie Workflow-pinning.

Beveiligingsfixes

Beveiligingsfixes openen een pull request voor:

• npm, inclusief Yarn, pnpm en Bun met bun.lock (niet het binaire bun.lockb: voer één keer bun install --save-text-lockfile uit om over te stappen);
• Go;
• PyPI;
• Maven;
• Gradle met een lockfile, die wordt vernieuwd in een job op de eigen runner van je organisatie;
• NuGet;
• Cargo;
• Composer, composer.json en composer.lock;
• pub, pubspec.yaml en pubspec.lock;
• RubyGems, Gemfile.lock, die wordt bijgewerkt in een job op de eigen runner van je organisatie (Bundler leest de Gemfile, en dat is Ruby-code die fremforge niet uitvoert);
• Hex, mix.lock, die wordt bijgewerkt in een job op de eigen runner van je organisatie, in het officiële elixir-image (Mix leest mix.exs, en dat is Elixir-code);
• CRAN (R), renv.lock, die wordt bijgewerkt in een job op de eigen runner van je organisatie, in het rocker/r-ver-image: alleen het record van dat pakket verandert, en een fix waarvoor andere pakketten moeten meeveranderen, wordt geweigerd (zie CRAN);
• GitHub Actions, het workflowbestand: de action wordt verplaatst naar de laagste versie die elke openstaande advisory oplost, vastgepind aan de commit van die tag met de tag als commentaar (@<sha> # v4.1.3). De tags worden gelezen uit de actionmirror op frem.sh, nooit van github.com;
• basisimages: de FROM-regel van een Dockerfile, binnen dezelfde hoofdversie.

Ze herstellen directe afhankelijkheden, en deze transitieve (zie Transitieve afhankelijkheden):

• npm met package-lock.json, vastgepind met overrides;
• pnpm met pnpm-lock.yaml (lockfileversie 9.0), vastgepind met overrides;
• Yarn 1 met yarn.lock, vastgepind met resolutions (Yarn 2 en later worden niet ondersteund);
• PyPI met uv.lock of poetry.lock, door het item in de lock te verplaatsen;
• Maven, vastgepind met <dependencyManagement> in de pom.xml waar de bevinding vandaan kwam (of de root-pom.xml, voor een pakket uit een geüploade SBOM);
• Gradle met gradle.lockfile, vastgepind met een dependency constraint;
• Go-modules die in go.mod met // indirect zijn gemarkeerd;
• Composer-pakketten die composer.json niet noemt, door composer.lock bij te werken in een job op de eigen runner van je organisatie;
• RubyGems, Hex en CRAN: elke fix is een update van het lockbestand, dus een pakket dat door een ander pakket wordt binnengehaald, wordt op dezelfde manier hersteld als een pakket dat het manifest noemt.

Niet hersteld, elk met de reden bij de bevinding: bun.lockb, dat alleen Bun kan herschrijven, en pub- en Bun-pakketten die het manifest niet noemt. Voor elk ander ecosysteem, ook Swift Package Manager, antwoordt een fixverzoek not yet supported. Conan heeft geen advisories om te herstellen (zie de tabel hierboven).

Bereikbaarheid

Bereikbaarheid geeft een oordeel voor:

Elk ander ecosysteem krijgt het oordeel onbekend.

Dependency proxy

De dependency proxy levert npm-, PyPI-, Maven-, NuGet-, Go-, Cargo-, Helm- en RPM-pakketten, containerimages, en Terraform- en OpenTofu-modules.

Niet gedekt

Terraform-modules en versies van Helm-charts worden niet vergeleken met kwetsbaarheidsadvisories. Versies van CI-actions wel; zie Versies van CI-actions. Terraform- en OpenTofu-providers ook, op basis van hun binaries; zie Terraform- en OpenTofu-providers. De containerimages die een Helm-chart uitrolt ook; zie Images die je Helm-charts uitrollen. Infrastructure-as-code-bestanden krijgen alleen controles op misconfiguratie, in een eigen controle, fremforge/iac-scan; zie IaC-scans. Of action-verwijzingen aan een commit zijn vastgepind, wordt ook gecontroleerd; zie Workflow-pinning.