Analyse antimalware

fremforge fait passer les surfaces de téléversement listées sous Surfaces par un analyseur basé sur ClamAV. Si une signature correspond, le téléversement est rejeté avec HTTP 422 et une ligne de résultat est ajoutée au journal d’analyse antimalware du tenant.

L’analyseur fonctionne sans Cisco Talos et sans abuse.ch. Tous deux soumettent l’usage commercial à une licence payante, et nous ne voulons pas, sur le chemin d’analyse, d’un sous-traitant que nous ne pouvons pas pleinement identifier.

Pile de signatures

La fraîcheur des flux est surveillée par les opérateurs de fremverk ; les clients ne voient pas directement la fraîcheur des signatures. Le SLA couvre la disponibilité de l’analyseur.

Attribution. YARA-Forge Core est compilé par YARA-Forge à partir de dépôts publics de règles YARA, et chaque règle est attribuée à ses auteurs dans ses métadonnées. Il est utilisé sous la Detection Rule License 1.1. Les signatures Linux Malware Detect sont de R-fx Networks. Voir les mentions tierces.

Surfaces

Analysées, en échec fermé (téléversement rejeté si l’analyseur est injoignable) :

• PUT d’objets LFS
• POST de pièces jointes de tickets et de PR
• PUT / POST vers le registre de paquets, pour chaque type de paquet (npm, Maven, PyPI, NuGet, Cargo, couches de conteneurs et les autres), y compris les publications depuis des tâches de runners hébergés par fremforge vers le registre d’une organisation

Un téléversement de plus de 4 Gio ne peut pas être entièrement analysé et est refusé avec HTTP 413.

Analysés uniquement si votre organisation l’active (désactivé par défaut) :

• Les paquets et images de conteneurs récupérés via le proxy de dépendances. Voir Récupérations du proxy de dépendances.

NON analysés :

• Les push du protocole Git (objets git). La détection des secrets au moment du push est gérée séparément par la protection des push.
• Les artefacts de workflow. Ils ont une courte durée de vie, sont limités au tenant, et la politique dit déjà « n’acceptez pas d’artefacts auxquels vous ne faites pas confiance ». Les fichiers de modèles qu’ils contiennent sont vérifiés par l’analyse des modèles, sous forme de résultats uniquement.

Récupérations du proxy de dépendances

Ce que le proxy de dépendances récupère depuis un registre amont (fichiers de paquets npm, PyPI, Maven, NuGet, Go, Cargo, Helm et RPM, et couches d’images de conteneurs) n’est pas analysé par ClamAV par défaut. C’est le même fonctionnement que GitHub et GitLab, qui n’analysent pas non plus les téléchargements de paquets avec un antivirus : les registres publics détectent les malwares lors de la publication d’un paquet et les publient sous forme d’alerte de malware.

Ce qui s’applique toujours à chaque organisation, que l’analyse ClamAV soit activée ou non :

• Paquets connus comme malveillants. Chaque version de paquet servie par le proxy est comparée aux alertes de malware OSV MAL- dans le cadre de votre politique de paquets. Une correspondance est refusée pour toute organisation, quel que soit le mode de la politique (depuis le 2026-10-11 ; depuis le 2026-10-10 pour les organisations internes de fremforge) : le téléchargement répond 403 avec la raison, et la version est retirée des métadonnées de paquet servies par le proxy, de sorte que les gestionnaires de paquets se résolvent vers une version non malveillante. Voir Paquets malveillants.
• Un contenu que ClamAV a déjà trouvé infecté reste bloqué. Un fichier ou une couche d’image qu’une analyse a trouvé infecté est refusé à toutes les organisations, qu’elles analysent ou non.
• Les téléversements et les images poussées sont toujours analysés, comme indiqué sous Surfaces.

Pour que le proxy analyse avec ClamAV ce qu’il récupère, activez Analyse antivirus du proxy : analyser les paquets et images récupérés (ClamAV) sous Administration de l’organisation → Build et déploiement → Proxy de dépendances, ou définissez malware_scan: true avec PUT /orgs/{org}/dependency-proxy. Une fois l’option activée, chaque fichier de paquet et chaque couche d’image que le proxy récupère pour votre organisation passe en flux par ClamAV, et ceux qu’il trouve infectés ou ne peut pas analyser entièrement sont retenus. Cela inclut un fichier de plus de 4 Gio, sauf une couche de modèle safetensors ou GGUF qui réussit sa vérification de format. Une analyse de couche d’image qui dépasse son délai n’est pas un verdict : la couche est retenue et mise en file pour l’analyseur de couches en arrière-plan de fremforge, et un pull ultérieur est servi dès que cette analyse est réussie. Un fichier de paquet dont l’analyse dépasse son délai est traité de la même façon : il est retenu pour cette requête, analysé en arrière-plan et servi lors d’une requête ultérieure dès que cette analyse est réussie. Pendant cette attente, un RPM est stocké et analysé uniquement dans l’espace propre à votre organisation, comme tout contenu RPM. Un fichier que le proxy a mis en cache pour une autre organisation sans analyse est récupéré et analysé de nouveau avant d’être servi à votre organisation.

Retenir les nouvelles images jusqu’à la fin de l’analyse antimalware (block_until_scanned) attend cette analyse ; l’analyse ClamAV doit donc être activée. Une requête qui laisserait block_until_scanned activé avec malware_scan désactivé est refusée avec 400 scan-pair.

Ce qui se passe lorsqu’une correspondance se déclenche

1. Le proxy rejette le téléversement avec HTTP 422 et un corps qui nomme la signature, le SHA-256 des octets rejetés et un renvoi vers la procédure de dérogation.
2. Une ligne de résultat est écrite dans malware_scan_findings via le point de terminaison /internal/malware-scan/ingest de l’API (authentification mutuelle, bearer + liste d’adresses IP autorisées).
3. Le résultat apparaît immédiatement dans l’administration du tenant, sous Sécurité, Analyse antimalware, avec le chemin du téléversement, la signature correspondante, l’auteur de la tentative de téléversement et la taille du fichier.

Dérogations (faux positifs)

Certaines signatures se déclenchent sur des fixtures de test légitimes, des échantillons de recherche en sécurité ou des artefacts inoffensifs qui correspondent par hasard à un ancien motif. Les administrateurs du tenant peuvent ajouter une dérogation qui met sur liste blanche une paire précise empreinte SHA-256 + dépôt.

1. Administration du tenant → Sécurité › Résultats › Logiciels malveillants. Dépliez Dérogations actives et cliquez sur Ajouter une dérogation.
2. Collez le SHA-256 du fichier rejeté (indiqué dans la réponse 422).
3. Choisissez la portée : ce dépôt uniquement, ou tous les dépôts de l’organisation.
4. Définissez une expiration (90 jours par défaut ; 1 an au maximum).
5. Ajoutez une justification (texte libre, consigné dans le journal d’audit de l’organisation).

Une dérogation ne court-circuite que la décision fondée sur l’empreinte. Si une autre signature correspond aux mêmes octets, le téléversement est tout de même rejeté. Les opérateurs de fremverk examinent les dérogations chaque trimestre dans le cadre de la revue de sécurité.

Via l’API REST

Les résultats et les dérogations de l’analyse antimalware sont exposés sur l’API publique. Utilisez-la pour relier les alertes de rejet de téléversement à un système de tickets externe, automatiser le cycle de vie des dérogations ou piloter le tout depuis un agent IA.

• Lister les résultats GET /_app/api/v1/orgs/:slug/malware-scan/findings
• Écarter un résultat POST /_app/api/v1/orgs/:slug/malware-scan/findings/:id/dismiss
• Lister les dérogations GET /_app/api/v1/orgs/:slug/malware-scan/overrides
• Créer une dérogation POST /_app/api/v1/orgs/:slug/malware-scan/overrides corps : { "kind": "file", "signature": "sha256:...", "reason": "test fixture", "expires_at": "2027-01-01T00:00:00Z" }
• Révoquer une dérogation DELETE /_app/api/v1/orgs/:slug/malware-scan/overrides/:id

Lister nécessite la portée findings:read, et écarter un résultat nécessite findings:write. Créer ou révoquer une dérogation nécessite policy:write, car une dérogation exempte des téléversements de l’analyse ; le jeton de runner d’une tâche de CI ne la porte jamais. Utilisez un jeton d’accès personnel (PAT) :

curl -X POST \
  -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  -H "Content-Type: application/json" \
  -d '{"kind":"file","signature":"sha256:abc123...","reason":"known-clean test artefact","expires_at":"2027-01-01T00:00:00Z"}' \
  https://frem.sh/_app/api/v1/orgs/acme/malware-scan/overrides

Voir la référence de l’API REST publique pour la spécification OpenAPI complète.

SLA et posture d’échec fermé

Si le démon ClamAV est injoignable, les téléversements sont rejetés avec HTTP 503 et un Retry-After. C’est la décision d’échec fermé prévue par notre politique d’utilisation acceptable. L’alternative (échec ouvert pendant une panne de l’analyseur) ouvrirait une fenêtre pendant laquelle l’engagement de la politique d’utilisation acceptable serait contourné sans bruit ; nous ne pensons pas que ce compromis en vaille la peine. Les opérateurs sont alertés dans les 5 minutes en cas d’indisponibilité de l’analyseur.

Test de fumée EICAR

Un CronJob canari téléverse le fichier de test EICAR standard toutes les 30 minutes et vérifie que le téléversement est rejeté. Si trois exécutions consécutives du canari réussissent (c’est-à-dire que le rejet ne se produit plus), les opérateurs sont alertés. Cela couvre le cas où la base de signatures a été livrée intacte mais n’a pas pu être chargée.