Avis de sécurité pour vos dépôts

Lorsque quelqu’un trouve une faiblesse dans un logiciel que vous maintenez, vous la corrigez d’abord et vous prévenez ensuite. Un avis de sécurité est la manière de prévenir : une déclaration courte et structurée de ce qui est affecté, avec quelle gravité, et quelle version corrige le problème. Les analyseurs lisent les avis pour avertir tous ceux qui dépendent de votre paquet.

fremforge conserve les avis d’une organisation sous Sécurité › Rapports › Avis de sécurité, et via l’API à /_app/api/v1/orgs/{org}/security-advisories.

Rédiger en privé

Nouvel avis ouvre un brouillon. Un brouillon indique :

• le dépôt concerné ;
• un titre d’une ligne et une description : ce qu’est la faiblesse, qui est affecté, l’impact, et comment la corriger ou la contourner ;
• les paquets affectés, chacun avec son écosystème, son nom de paquet, ses versions vulnérables et la première version corrigée ;
• la gravité, sous forme de vecteur CVSS ou de niveau (critique, élevée, moyenne, faible) ;
• les faiblesses (identifiants CWE), un identifiant CVE facultatif et des références.

Un brouillon n’est visible que par :

• les propriétaires de l’organisation. Ses auditeurs voient uniquement qu’il existe, son dépôt, son état et ses dates, jamais son contenu ;
• les administrateurs du dépôt concerné (voir Administrateurs de dépôt) ;
• les personnes qu’ils y invitent (voir Collaborateurs).

Son titre, sa description, ses références et ses commentaires sont stockés chiffrés. Les outils opérationnels et les agents d’IA de fremforge ne voient ni le texte ni qui l’a écrit.

Les personnes qui peuvent voir un brouillon peuvent en discuter dans des commentaires confidentiels. Ils restent privés, y compris après la publication de l’avis.

Versions vulnérables

Écrivez les versions vulnérables sous forme d’une ou deux contraintes, de la même manière que GitHub :

> est refusé : le format OSV n’a pas de borne inférieure exclusive, utilisez donc >=. Avec < X, la première version corrigée est X. Laissez Version corrigée vide, ou utilisez <= pour la dernière version affectée.

Écosystèmes : npm, PyPI, Maven (groupId:artifactId), Go (le chemin du module), crates.io, RubyGems, NuGet, Packagist, Pub, Hex, GitHub Actions (owner/repository), SwiftURL et CRAN.

Gravité

Un vecteur de base CVSS 3.1 fixe la gravité à partir de son score de base, calculé par fremforge. Un vecteur de base CVSS 4.0 est vérifié et conservé tel quel. Choisissez alors vous-même la gravité : le score CVSS 4.0 n’est pas calculé.

Publier

Publier l’avis nécessite une gravité et au moins un paquet affecté.

• Pour un dépôt public (non privé, dans une organisation dont la visibilité est publique), l’avis devient public immédiatement : une page à https://frem.sh/_app/advisories/<id> et un enregistrement OSV (voir ci-dessous). Le caractère public du dépôt est revérifié à chaque lecture publique. Si vous rendez le dépôt privé par la suite, ses avis cessent d’être servis dès la lecture suivante.
• Pour un dépôt privé, l’avis reste visible uniquement au sein de votre organisation. Il ne devient pas public si vous ouvrez le dépôt plus tard ; publiez-en un nouveau.

Publiez le correctif avant l’avis : l’avis indique à tout le monde où se trouve la faiblesse.

Le développement du correctif se fait pour l’instant en dehors de fremforge. Un avis contient du texte ; fremforge ne propose pas de fork privé temporaire pour lui. Un dépôt privé de votre organisation serait lisible par chaque équipe ayant accès à tous les dépôts, ce qui inclut par défaut Members et Viewers ; ce n’est donc pas proposé. Développez le correctif comme votre projet gère les correctifs de sécurité non publiés, et publiez l’avis une fois la version corrigée publiée.

Chaque avis a un identifiant de la forme FFSA-xxxx-xxxx-xxxx, fixé à la création du brouillon.

Administrateurs de dépôt

Les administrateurs d’un dépôt gèrent les avis et les signalements privés de ce dépôt sans être propriétaires de l’organisation, comme GitHub le permet aux administrateurs de dépôt. Ils trouvent les signalements envoyés aux dépôts qu’ils administrent sous Signalements reçus par les dépôts que vous administrez à /_app/security-reports, peuvent les accepter ou les rejeter, et lire et commenter les brouillons de ces dépôts. Le fait que quelqu’un administre un dépôt est demandé à frem.sh à chaque requête, si bien qu’un changement de permissions s’applique immédiatement. Un propriétaire de l’organisation compte comme administrateur de chaque dépôt de l’organisation.

Collaborateurs

Invitez des personnes sur un avis en brouillon ou publié par leur identifiant frem.sh, par exemple un chercheur externe ou un mainteneur d’un autre projet. Elles n’ont pas besoin d’être membres de votre organisation. Une personne invitée lit l’avis et ses commentaires confidentiels, et ajoute des commentaires, depuis sa propre page à /_app/security-reports. Elle ne peut ni le modifier ni le publier. La retirer met fin à son accès immédiatement. Jusqu’à 20 personnes peuvent être invitées sur un même avis.

Signalement privé de vulnérabilités

Avec le signalement privé de vulnérabilités activé, toute personne connectée à frem.sh qui peut lire un dépôt peut vous signaler une faiblesse en privé, y compris des personnes extérieures à votre organisation. Sans lui, une personne qui trouve une faiblesse doit deviner une adresse e-mail ou ouvrir un ticket public.

Il est désactivé tant que vous ne l’activez pas. Les propriétaires définissent une valeur par défaut pour toute l’organisation sous Sécurité › Rapports › Avis de sécurité › Paramètres, et peuvent l’activer ou le désactiver pour des dépôts individuels au même endroit ; un paramètre de dépôt l’emporte sur la valeur par défaut.

Ce qu’envoie l’auteur d’un signalement

Le formulaire de signalement se trouve à https://frem.sh/_app/security-reports/new?repo=<org>/<repository>. Ajoutez-y un lien depuis le SECURITY.md de votre dépôt. Un signalement comporte un titre, une description, les versions affectées, la manière dont la faiblesse a été trouvée et une preuve de concept facultative. Il est stocké chiffré, et seuls les propriétaires de l’organisation, les administrateurs du dépôt et l’auteur du signalement le voient. Son texte ne figure jamais dans un e-mail ni dans le journal d’audit ; le journal d’audit désigne les signalements par leur identifiant.

Pour que le canal reste utilisable, fremforge limite les signalements :

• 3 par personne vers un même dépôt, et 10 par personne au total, sur 24 heures ;
• aucun depuis un compte de moins de 24 heures ;
• 5 par minute depuis une même adresse IP.

Une requête qui dépasserait une limite est refusée et rien n’est stocké.

Statuer sur un signalement

Les propriétaires de l’organisation reçoivent un e-mail lorsqu’un signalement arrive, et le trouvent sous Sécurité › Rapports › Avis de sécurité › Signalements privés. Les administrateurs du dépôt le trouvent sur leur propre page à /_app/security-reports.

• Accepter crée un brouillon d’avis à partir du signalement, y invite l’auteur du signalement comme collaborateur, et lui demande d’accepter un crédit de reporter.
• Ne pas accepter clôt le signalement avec une raison : pas une vulnérabilité, doublon, hors périmètre, spam ou autre.

Dans les deux cas, l’auteur du signalement est prévenu par e-mail. Il peut retirer un signalement tant qu’aucune décision n’a été prise. Un signalement rejeté est supprimé 2 ans après son rejet. Les signalements acceptés et leurs avis restent dans votre organisation.

Analyse des dépendances

Un avis publié est rapproché de l’inventaire des dépendances de votre organisation chaque jour et juste après sa publication : un dépôt qui dépend d’une version affectée reçoit un résultat sous Sécurité › Résultats › Dépendances, avec l’identifiant FFSA de l’avis, comme toute autre vulnérabilité. Retirer l’avis supprime les résultats qu’il a produits.

Pour les autres organisations, un avis n’est rapproché que lorsqu’il figure dans le flux de la plateforme de fremforge. Cela exige, avec une revérification quotidienne :

• que le dépôt soit public ; et
• que votre organisation possède de manière vérifiable chaque paquet affecté : un paquet de votre organisation dans le registre de paquets frem.sh, ou un module Go sous frem.sh/<your organisation>/ ; ou bien que fremforge ait relu l’avis et l’ait approuvé.

La propriété provient des enregistrements propres à frem.sh, jamais du nom du paquet : un scope npm ou un chemin de module qui ressemble simplement au nom de votre organisation ne compte pas. Si vous perdez le paquet ou rendez le dépôt privé, l’avis quitte le flux de la plateforme lors de l’exécution quotidienne suivante. Le flux de la plateforme est servi à /_app/api/v1/advisories?scope=platform, et fremforge l’intègre aux bases OSV que lisent ses analyseurs.

Retirer, clore, supprimer

• Un avis publié est retiré, jamais supprimé. Il reste dans le flux avec withdrawn renseigné, afin que les analyseurs apprennent qu’il ne s’applique plus.
• Un brouillon que vous ne publiez pas peut être clos (et rouvert) ou supprimé avec ses commentaires.

Crédits

Créditez les personnes qui ont trouvé, signalé ou corrigé la faiblesse, par leur identifiant frem.sh et un type de crédit OSV. Un crédit n’est affiché publiquement et exporté qu’une fois que la personne créditée l’a accepté, sur sa propre page à /_app/security-reports. Se créditer soi-même ne nécessite aucune acceptation.

Export : OSV et CSAF

Chaque avis, brouillons compris, peut être téléchargé en :

• OSV 1.6 : le format que lisent les analyseurs de dépendances (osv-scanner, Trivy, et l’analyse des dépendances propre à fremforge) ;
• CSAF 2.0 : un document csaf_security_advisory, le format d’avis lisible par machine que les recommandations au titre du Cyber Resilience Act de l’UE et le BSI attendent des fabricants. Un brouillon est en TLP AMBER avec le statut draft, un avis publié en TLP WHITE avec le statut final.

Chaque téléchargement est enregistré dans le journal d’audit (security.advisory.exported), car l’export d’un brouillon décrit une faiblesse qui n’est pas encore corrigée.

Le flux OSV public

Les avis publiés des dépôts publics sont servis sans authentification, de la modification la plus ancienne à la plus récente, au plus 100 par page :

# The first page
curl -s 'https://frem.sh/_app/api/v1/advisories?limit=100'

# The next page: pass the `next` value of the previous answer as `since`
curl -s 'https://frem.sh/_app/api/v1/advisories?since=2026-10-25T00:00:00Z'

# One advisory
curl -s https://frem.sh/_app/api/v1/advisories/FFSA-xxxx-xxxx-xxxx

Chaque enregistrement suit le schéma OSV, avec l’identifiant CVE (s’il y en a un) en alias et database_specific.source défini à fremforge. Le caractère public du dépôt est vérifié à chaque requête, si bien que l’avis d’un dépôt rendu privé n’est plus servi dès la lecture suivante. Les lectures publiques sont limitées à 60 requêtes par minute par adresse client (429 au-delà).

Demander un identifiant CVE

fremforge n’est pas une CVE Numbering Authority et ne demande pas d’identifiants CVE à votre place. Sous Demander un identifiant CVE, un avis vous fournit son contenu sous forme de texte pour le formulaire de demande CVE de MITRE, ou pour la CNA qui couvre votre projet s’il y en a une. Envoyez-le vous-même, puis saisissez dans l’avis l’identifiant CVE que vous recevez. L’API fournit le même texte à /orgs/{org}/security-advisories/{id}/cve-request.

Le Cyber Resilience Act de l’UE

Le CRA attend d’un fabricant qu’il gère les vulnérabilités de ses produits : qu’il les corrige, et qu’il publie des informations sur celles qui sont corrigées. Les avis avec export CSAF soutiennent cette démarche. Ils ne vous rendent pas conforme à eux seuls, et fremforge ne signale rien à l’ENISA ni à un CSIRT national à votre place. Le signalement au titre de l’article 14 du CRA reste de votre ressort.

Pas encore disponible

• Un fork privé temporaire pour y développer le correctif : non proposé, voir Publier.

API

findings:read ne lit que les avis publiés des dépôts publics, avec les seuls crédits acceptés. Les brouillons, les avis clos, les avis des dépôts privés et les commentaires de tous les avis nécessitent advisories:read, que findings:read n’inclut pas et que les jetons créés pour les jobs CI ne détiennent pas par défaut. Un crédit nomme un utilisateur frem.sh : un identifiant inconnu est refusé.

Les schémas complets se trouvent dans la référence de l’API.