Écosystèmes pris en charge

Voici la liste de référence. Lorsqu’une autre page nomme des écosystèmes, elle suit cette page.

Analyse des dépendances

L’analyse des dépendances (osv-scanner, sur chaque pull request et sur la branche par défaut) lit ces fichiers :

Les images de conteneurs sont analysées par Trivy : les paquets du système d’exploitation et les paquets de langage contenus dans chaque image. Voir Analyse des images de conteneurs.

Résolution des dépendances Maven

Un pom.xml ne nomme que ses dépendances directes. Pour voir ce qu’elles entraînent, l’analyse des dépendances résout chaque pom.xml comme le ferait Maven : poms parents, BOM importés, <dependencyManagement>, propriétés, scopes, exclusions et plages de versions. Elle ne lit que des poms. Ni Maven, ni aucun plugin, ni aucun code de votre dépôt ne s’exécute.

• D’où viennent les poms. Chaque pom est lu via le proxy Maven de votre organisation, avec le proxy de la plateforme en repli. Les modules propres d’un build multi-modules sont lus depuis le dépôt. Les <repositories> déclarés dans un pom ne sont pas contactés : un artefact que seul un dépôt privé détient n’est pas résolu, et il est nommé (voir ci-dessous). Aucun service de résolution extérieur à fremforge n’est sollicité.
• Ce qui utilise le résultat. L’arbre résolu est ce que lisent les résultats de dépendances, le statut fremforge/dep-scan, le SBOM du dépôt et les pull requests de correctif transitif, si bien qu’ils concordent.
• Mis en cache. Un arbre est réutilisé pendant 24 heures tant que les poms ne changent pas. Les avis sont rapprochés à nouveau à chaque analyse : un nouvel avis n’est donc jamais masqué par le cache.

Lorsqu’un pom ne peut pas être résolu, il n’apparaît jamais comme propre. Ses dépendances directes sont tout de même vérifiées, et :

• le statut fremforge/dep-scan l’indique même lorsqu’il est vert : 1 pom.xml not fully resolved: transitive dependencies not checked ;
• le commentaire de la pull request liste le pom sous Pas entièrement vérifié, avec la raison et les artefacts que le proxy n’avait pas, même lorsqu’il n’y a aucun résultat ;
• les pages des résultats de dépendances et des SBOM affichent Pas entièrement vérifié, avec un lien vers le proxy de dépendances lorsqu’un artefact manque ;
• le SBOM le porte comme note de couverture (CycloneDX : la propriété fremforge:coverage:maven-unresolved et une composition incomplete ; SPDX : le commentaire de création) ;
• GET /orgs/{org}/code-security/deps/coverage (portée findings:read) le renvoie pour la branche par défaut. Par défaut, il ne liste que les dépôts ayant quelque chose de pas entièrement vérifié ; all=true liste chaque dépôt ayant un enregistrement de couverture, et repo=<name> filtre sur un seul.

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

La raison habituelle est un artefact que votre proxy Maven n’a pas, comme une bibliothèque interne publiée ailleurs : ajoutez ce dépôt comme amont du proxy. Les autres raisons sont un proxy qui ne répond pas, un délai dépassé, ou un build de plus de 60 poms (les suivants sont signalés, pas résolus).

Limites connues. La résolution lit les poms ; elle n’exécute pas le build. Par conséquent :

• un build qui réécrit ses dépendances avec un plugin (relocalisation par maven-shade-plugin, flatten-maven-plugin, un pom généré) est vérifié tel que ses poms le déclarent, pas tel que le plugin le modifie ;
• un profil qui dépend de l’environnement de votre machine de build (une propriété système, un fichier, le système d’exploitation ou le JDK) peut ne pas être appliqué comme votre build l’applique.

Pour l’arbre exact que livre votre build, envoyez un SBOM CycloneDX depuis la CI ; il est rapproché lui aussi.

Providers Terraform et OpenTofu

Il n’existe pas de base d’avis pour les providers Terraform, mais un provider est un programme Go. Pour chaque version de provider d’un .terraform.lock.hcl, fremforge analyse le binaire du provider à la recherche des modules Go à partir desquels il a été construit, et signale leurs avis comme résultats de dépendances du dépôt :

• Écosystème Terraform, paquet l’adresse du provider (par exemple registry.terraform.io/hashicorp/null), version la version verrouillée, manifeste le fichier de verrouillage. Le résumé nomme le module Go et sa version, par exemple google.golang.org/grpc@v1.69.4 (built into the provider).
• Uniquement le binaire qu’installe le fichier de verrouillage. Un résultat n’est signalé que lorsque l’un des hachages du fichier de verrouillage (zh: ou h1:) correspond à l’archive zip du provider qui a été analysée. Un fichier de verrouillage qui accepte d’autres octets n’obtient aucun résultat pour un binaire qu’il n’installerait pas.
• La même vérification que pour toute dépendance. Les résultats passent par votre seuil de dépendances, vos dérogations et la comparaison avec la branche de base : une pull request n’est donc bloquée que par les résultats qu’elle ajoute.
• La première analyse d’une version n’est pas immédiate. Une version que fremforge n’a encore jamais vue est mise en file d’attente lorsqu’un fichier de verrouillage qui l’épingle est analysé pour la première fois, puis analysée en arrière-plan, généralement dans l’heure. Ses résultats apparaissent à l’analyse suivante de chaque dépôt qui la verrouille ; d’ici là, cette version n’en a aucun.
• Atteignabilité. Chaque résultat indique si le binaire du provider lie une fonction nommée par l’avis : atteignable ou non atteignable, ou inconnu lorsque cela ne peut pas être déterminé. Voir Atteignabilité.
• Version corrigée. La version corrigée d’un résultat est la première release du provider dont le binaire ne porte plus l’avis, parmi les dix releases suivant la vôtre et la plus récente. fremforge analyse ces releases de la même manière : elle peut donc apparaître une heure ou deux après la première analyse de votre version. Elle reste vide lorsqu’aucune release de ce type n’existe encore, ce qui est fréquent : la release la plus récente d’un provider embarque souvent encore le module vulnérable.
• D’où vient le binaire. L’archive zip linux_amd64 est récupérée une seule fois, via le miroir de providers propre à fremforge, depuis l’emplacement publié par le registre du provider. Pour les providers de HashiCorp, il s’agit du site de releases de HashiCorp, releases.hashicorp.com, que fremforge n’exploite pas : il sert uniquement à récupérer l’archive publique du provider, rien concernant votre dépôt ne lui est envoyé, et fremforge conserve la copie qu’il a analysée.

Non couverts : les modules Terraform ; un provider construit avant Go 1.18 (par exemple hashicorp/null 3.1.0), dont le binaire ne contient aucune liste de modules à lire ; et la bibliothèque standard Go avec laquelle le provider a été construit. Aucun correctif de sécurité n’est ouvert pour un provider : mettez à jour la version dans votre configuration et exécutez tofu init -upgrade ou terraform init -upgrade.

Versions des actions CI

Chaque uses: owner/repo@<version> d’un fichier de workflow situé directement sous .forgejo/workflows/, .gitea/workflows/ ou .github/workflows/ est rapproché des avis GitHub Actions (GHSA) de la copie de la base OSV propre à fremforge, depuis le 18 octobre 2026. Aucun appel n’est fait à GitHub : les avis proviennent de cette copie et la version de votre fichier de workflow.

• La version est le tag (actions/download-artifact@v4.1.2), ou, pour une action épinglée sur un commit, le commentaire de version à côté (actions/download-artifact@<sha> # v4.1.2), qui est la forme qu’écrivent les outils d’épinglage. Une action épinglée sans un tel commentaire n’a pas de version à rapprocher.
• Un résultat est un résultat de dépendance : écosystème GitHub Actions, paquet owner/repo, le fichier de workflow comme manifeste. Il passe par votre seuil de dépendances, vos dérogations et la comparaison avec la branche de base : une pull request n’est donc bloquée que par les résultats qu’elle ajoute, dans la vérification fremforge/dep-scan.
• Si la copie des avis GitHub Actions de fremforge est absente, un dépôt dont les workflows nomment des actions versionnées fait échouer son analyse des dépendances plutôt que de réussir sans résultat.

Non couverts : un tag majeur seul (@v4) ou une branche, qui ne nomment aucune version ; les fichiers de workflow dans des sous-répertoires ou en dehors de ces trois répertoires, les action.yml propres aux actions composites, et les fichiers de workflow liés symboliquement. L’épinglage d’une référence sur un commit est vérifié séparément ; voir Épinglage des workflows.

Correctifs de sécurité

Les correctifs de sécurité ouvrent une pull request pour :

• npm, y compris Yarn, pnpm et Bun avec bun.lock (pas le binaire bun.lockb : exécutez une fois bun install --save-text-lockfile pour basculer) ;
• Go ;
• PyPI ;
• Maven ;
• Gradle avec un fichier de verrouillage, rafraîchi dans un job sur le runner propre à votre organisation ;
• NuGet ;
• Cargo ;
• Composer, composer.json et composer.lock ;
• pub, pubspec.yaml et pubspec.lock ;
• RubyGems, Gemfile.lock, mis à jour dans un job sur le runner propre à votre organisation (Bundler lit le Gemfile, qui est du code Ruby que fremforge n’exécute pas) ;
• Hex, mix.lock, mis à jour dans un job sur le runner propre à votre organisation, dans l’image officielle elixir (Mix lit mix.exs, qui est du code Elixir) ;
• CRAN (R), renv.lock, mis à jour dans un job sur le runner propre à votre organisation, dans l’image rocker/r-ver : seul l’enregistrement de ce paquet change, et un correctif qui exige de changer d’autres paquets est refusé (voir CRAN) ;
• GitHub Actions, le fichier de workflow : l’action passe à la version la plus basse qui corrige chaque avis ouvert, épinglée sur le commit de ce tag avec le tag en commentaire (@<sha> # v4.1.3). Les tags sont lus depuis le miroir d’actions sur frem.sh, jamais depuis github.com ;
• les images de base : la ligne FROM d’un Dockerfile, au sein de la même version majeure.

Ils corrigent les dépendances directes, ainsi que ces dépendances transitives (voir Dépendances transitives) :

• npm avec package-lock.json, épinglées via overrides ;
• pnpm avec pnpm-lock.yaml (version de fichier de verrouillage 9.0), épinglées via overrides ;
• Yarn 1 avec yarn.lock, épinglées via resolutions (Yarn 2 et versions ultérieures ne sont pas pris en charge) ;
• PyPI avec uv.lock ou poetry.lock, en déplaçant l’entrée du fichier de verrouillage ;
• Maven, épinglées via <dependencyManagement> dans le pom.xml d’où provient le résultat (ou le pom.xml racine, pour un paquet vu dans un SBOM envoyé) ;
• Gradle avec gradle.lockfile, épinglées via une contrainte de dépendance ;
• Go, les modules marqués // indirect dans go.mod ;
• Composer, les paquets que composer.json ne nomme pas, en mettant à jour composer.lock dans un job sur le runner propre à votre organisation ;
• RubyGems, Hex et CRAN : chaque correctif est une mise à jour du fichier de verrouillage, si bien qu’un paquet entraîné par un autre est corrigé de la même manière qu’un paquet nommé par le manifeste.

Non corrigés, chacun avec sa raison sur le résultat : bun.lockb, que seul Bun peut réécrire, et les paquets pub et Bun que le manifeste ne nomme pas. Pour tout autre écosystème, Swift Package Manager compris, une demande de correctif répond not yet supported. Conan n’a pas d’avis à corriger (voir le tableau ci-dessus).

Atteignabilité

L’atteignabilité donne un verdict pour :

Tout autre écosystème reçoit le verdict inconnu.

Proxy de dépendances

Le proxy de dépendances sert les paquets npm, PyPI, Maven, NuGet, Go, Cargo, Helm et RPM, les images de conteneurs, et les modules Terraform et OpenTofu.

Non couvert

Les modules Terraform et les versions de charts Helm ne sont pas rapprochés des avis de vulnérabilité. Les versions des actions CI le sont ; voir Versions des actions CI. Les providers Terraform et OpenTofu le sont, à partir de leurs binaires ; voir Providers Terraform et OpenTofu. Les images de conteneurs qu’un chart Helm déploie le sont ; voir Images déployées par vos charts Helm. Les fichiers d’infrastructure as code ne font l’objet que de vérifications de mauvaise configuration, dans leur propre vérification, fremforge/iac-scan ; voir Analyse IaC. L’épinglage des références d’actions sur un commit est vérifié lui aussi ; voir Épinglage des workflows.