Paquets malveillants
fremforge compare les paquets que vous livrez réellement aux alertes MAL-* d’OSV : des paquets qu’un registre ou un chercheur a confirmés comme délibérément malveillants, par exemple un typosquat ou une version détournée qui vole des identifiants à l’installation. Deux éléments sont vérifiés :
- Les dépôts. Le SBOM le plus récent de la branche par défaut de chaque dépôt.
- Les images de conteneurs. Les paquets de langage contenus dans chaque image publiée dans le registre de paquets de votre organisation.
Un paquet malveillant est toujours critique. Ce n’est pas une vulnérabilité avec une version corrigée : supprimez-le, et considérez comme compromise toute machine qui l’a installé ou exécuté.
Cette vérification est distincte de l’analyse antimalware, qui applique les signatures ClamAV aux fichiers téléversés.
Quand la vérification s’exécute
| Quoi | Quand c’est vérifié |
|---|---|
| La branche par défaut d’un dépôt | Juste après chaque push sur cette branche (son SBOM est généré et comparé en une minute environ), puis chaque jour à 05:00 UTC |
| Une image de conteneur | Après chaque push, ré-étiquetage ou suppression dans le registre de paquets (en 15 minutes environ), puis chaque jour |
L’exécution quotidienne compte, car un paquet est souvent déclaré malveillant plusieurs semaines après sa publication. Le code et les images qui n’ont pas changé sont donc à nouveau comparés aux alertes les plus récentes.
La comparaison s’exécute sur les propres scanners de fremforge, à partir d’une copie hors ligne de la base de données OSV. Rien de votre code ni de vos images n’est envoyé à osv.dev.
Ce qui est comparé dans une image
L’image est analysée avec Trivy, à partir du même pull que celui de l’analyse des images de conteneurs. Ce sont ses paquets de langage qui sont comparés : npm, PyPI, Maven, Go, crates.io, RubyGems, NuGet, Packagist, Pub et Hex. Les paquets du système d’exploitation (apk, deb, rpm) ne le sont pas, car les alertes MAL-* portent sur les registres de langage.
Pour une image multi-architecture, c’est la variante linux/amd64 qui est analysée.
Résultats
Les résultats sont listés sous Sécurité › Résultats › Dépendances › Logiciels malveillants. Filtrez par source (Dépôts ou Images de conteneurs) et par état :
- Ouverts. Le paquet se trouve sur la branche par défaut, ou dans au moins un digest publié de l’image.
- Ignorés. Quelqu’un a décidé qu’il était acceptable, en indiquant un motif.
- Résolus. Il a disparu : retiré de la branche par défaut, ou plus aucun tag ni digest publié de l’image ne le contient. S’il réapparaît, le résultat est rouvert.
Un résultat d’image correspond à une ligne par nom d’image. Il liste les tags et les digests qui contiennent actuellement le paquet, de sorte que ré-étiqueter le même contenu ne crée pas de second résultat.
Le badge de l’onglet et la tuile Paquets malveillants de la vue d’ensemble de l’organisation comptent les résultats ouverts des deux sources.
Alertes
Une alerte de sécurité est envoyée aux membres de l’organisation qui ont activé les alertes de sécurité lorsqu’un paquet malveillant est détecté pour la première fois, lorsqu’un paquet résolu réapparaît, et lorsqu’une décision d’ignorer atteint sa date de fin. Un résultat toujours présent le lendemain ne déclenche pas de nouvelle alerte. Les résultats ouverts sont aussi comptés dans le récapitulatif de sécurité.
Ignorer un résultat
Dépliez Ignorer sur la ligne, choisissez un motif et, si vous le souhaitez, une date de fin. Passé cette date, le résultat est rouvert et déclenche une nouvelle alerte. L’action groupée est disponible dans la liste des résultats ouverts.
- Résultat de dépôt. L’ignorer empêche aussi les pull requests de ce dépôt d’échouer à l’analyse des dépendances pour la même version du paquet et la même alerte, avec la même date de fin.
- Résultat d’image. L’ignorer l’empêche de bloquer les pulls de l’image (voir ci-dessous). Cela n’ignore pas le même paquet dans un dépôt, même s’il porte le même nom.
Chaque décision d’ignorer est enregistrée dans le journal d’audit, avec l’auteur, le motif et la date de fin.
Récupérer une image qui contient un paquet malveillant
Le pull d’une image de conteneur dont le digest a un résultat de paquet malveillant ouvert et non ignoré est refusé avec 403 DENIED. Le message nomme le paquet et l’alerte, et renvoie vers l’onglet Logiciels malveillants. Cela s’applique à toutes les organisations, quel que soit leur paramètre de blocage de l’analyse des images, et aux pulls par tag comme par digest.
Pour débloquer un pull : poussez une image corrigée, ou ignorez le résultat.
Appliqué depuis le 2026-10-04. Entre le 2026-10-03 et le 2026-10-04, la vérification fonctionnait en mode observation : un pull qui aurait été refusé était journalisé mais tout de même servi.
Télécharger un paquet du registre qui embarque un paquet malveillant
Il en va de même pour tous les autres types de paquets de votre registre (npm, Maven, PyPI, NuGet, Cargo, Go et les autres) : un fichier qui embarque un paquet répertorié dans une alerte OSV MAL-* est refusé avec 403 au téléchargement, pour toutes les organisations, quel que soit le mode de leur politique de paquets. La réponse nomme la règle. Pour laisser passer un fichier, demandez une exception pour la règle malware ; elle doit être approuvée par une seconde personne.
Appliqué depuis le 2026-10-11. Auparavant, un tel téléchargement était enregistré et servi.