Politiques de sécurité

Sécurité › Politiques contient les règles que votre organisation applique. Les pages de résultats montrent ce qui a été trouvé. Les onglets de politique décident de ce qu’un résultat bloque, et de ce qu’un push, une fusion, un téléchargement ou un pull a le droit de faire. Seul un propriétaire de l’organisation peut modifier une politique, et chaque modification est écrite dans le journal d’audit.

Les onglets

Les onglets de résultats montrent les résultats ; ce que fait un analyseur se règle ici. L’onglet Exceptions sous Résultats est l’endroit où un résultat est accepté pour un temps, avec ou sans l’approbation d’une seconde personne.

Analyseurs

Sécurité › Politiques › Analyseurs contient les paramètres de chaque analyseur. Jusqu’au 2026-10-15, ils se trouvaient en haut de l’onglet de résultats de chaque analyseur, qui montre désormais d’abord ses résultats, puis une ligne avec l’état de l’analyseur et un lien vers cette page.

• SAST : activé ou désactivé, et la gravité (info, warning, error) à partir de laquelle la vérification fremforge/sast échoue.
• Dépendances : activé ou désactivé, et la gravité (de low à critical) à partir de laquelle la vérification fremforge/dep-scan échoue.
• Licences : si l’analyse des licences s’exécute sur les pull requests. Ce que signifie un résultat de licence relève de la politique de licences.
• Analyse des secrets : si les pull requests qui ajoutent un secret sont bloquées.
• Images de conteneurs : l’analyse des images et le blocage des pulls se trouvent dans Politiques d’images.

Un enregistrement refusé, par exemple une gravité qui ne fait pas partie des choix, revient à la section de l’analyseur avec la raison. L’API et les ressources Terraform sont inchangées : PUT /orgs/{org}/code-security/{scanner}/settings et les ressources fremforge_*_settings.

Âge de la version

Sécurité › Politiques › Âge de la version est un nombre de jours, de 0 à 14, indiquant depuis combien de temps une nouvelle version doit avoir été publiée avant que votre organisation l’adopte. Jusqu’au 2026-10-16, c’étaient quatre paramètres à quatre endroits. Il règle désormais les quatre :

Rien n’a changé de lui-même. Chaque endroit a conservé sa propre valeur. Là où elles diffèrent, la page affiche chaque valeur actuelle et ce qu’un enregistrement fixerait, et propose la valeur des correctifs de sécurité. Rien n’est écrit tant qu’un propriétaire n’a pas enregistré, et Enregistrer n’est proposé que pour le nombre dont la page a montré les effets.

Un correctif d’une vulnérabilité connue comme exploitée n’attend toujours pas dans la vérification de pull request, dans les correctifs de sécurité, ni pour un téléchargement via le proxy de dépendances. Les paquets de votre propre registre attendent toujours.

La voie des correctifs de sécurité dans la vérification de pull request

Dans la vérification fremforge/release-age, une version qui corrige une vulnérabilité présente sur votre branche de base, de n’importe quelle gravité, attend 24 heures au lieu de votre âge de version. Une version n’est admissible que si toutes ces conditions sont remplies :

• Votre branche de base résout une version antérieure du paquet, et la pull request la retire.
• Un avis affecte cette version antérieure et nomme une version corrigée égale ou inférieure à la nouvelle. Une release qui prétend seulement corriger quelque chose n’est pas admissible.
• L’avis est relu, quelle que soit sa gravité : un avis GitHub que GitHub a relu, ou un enregistrement de la base de données propre à l’écosystème (RustSec, la base de vulnérabilités Go, PyPA). Il a été publié, et relu, au moins 24 heures avant la vérification. Un paquet et un avis publiés ensemble le même jour ne sont donc jamais admissibles.
• Aucun enregistrement de paquet malveillant ne correspond à la nouvelle version. La détection des malwares n’est jamais assouplie pour cette voie.

Une nouvelle dépendance transitive introduite uniquement par le correctif bénéficie des mêmes 24 heures dans l’un de ces deux cas :

• Un avis la nomme aussi comme correctif, selon les mêmes règles que ci-dessus.
• Les personnes qui publient le correctif la publient aussi. L’utilisateur npm qui a publié cette version doit être connu, et doit être un mainteneur du correctif. En plus, l’une de ces conditions doit être vraie :
  • Chaque mainteneur de la dépendance maintient aussi le correctif.
  • La dépendance et le correctif déclarent le même dépôt source, comme le font les paquets d’un monodépôt.

Un dépôt déclaré ne suffit jamais à lui seul. Le champ repository d’un package.json contient ce que l’éditeur y écrit, si bien que n’importe qui peut revendiquer le dépôt de quelqu’un d’autre. Une dépendance dont l’éditeur est inconnu attend toujours.

Sinon, elle attend votre âge de version complet, et la pull request attend avec elle. Toute autre nouvelle version de la pull request garde votre âge de version. La voie ne rend jamais la vérification plus stricte. Avec un âge de version de 1 jour ou de 0, rien ne change.

Le statut de la vérification nomme chaque version passée par la voie et l’avis qu’elle corrige, par exemple 1 version(s) via the security-fix lane (24h): body-parser@2.4.0 fixes GHSA-…. Chacune de ces versions écrit code-security.release_age.waived_security_fix_lane dans le journal d’audit, avec le paquet, la version, les avis, le correctif qui l’a introduite et la pull request. Les téléchargements via le proxy de dépendances et Renovate hébergé gardent leurs propres règles. Les types de paquets qui ont leur propre âge minimal dans la politique de paquets le conservent, et la page les liste. Lorsque la politique de paquets n’est pas en mode Enforce, un téléchargement trop récent est seulement enregistré.

Un point n’est pas couvert : pour npm, pnpm et Yarn 1, Renovate hébergé résout le fichier de verrouillage via la vue du registre npm filtrée par âge de version de fremforge, qui conserve 3 jours pour chaque organisation. Avec un âge de version plus long, la vérification fremforge/release-age retient toujours la pull request jusqu’à ce que chaque version du fichier de verrouillage soit assez ancienne.

Via l’API : GET/PUT /orgs/{org}/release-age (policy:read, policy:write) avec {"days": 7, "package_policy_version": 12}, et POST /orgs/{org}/release-age/preview avec {"days": 7} pour savoir ce qu’un PUT changerait, endroit par endroit. Le PUT est vérifié par rapport à la version de la politique de paquets, comme un enregistrement de politique de paquets, et répond 409 policy-version-conflict lorsqu’elle a changé. Chaque modification écrit security.release_age.updated dans le journal d’audit, à côté des événements des paramètres qu’elle a modifiés.

Politiques d’images

Sécurité › Politiques › Politiques d’images comporte deux parties. Toutes deux se trouvaient auparavant en bas de Résultats › Images de conteneurs.

• Analyse et blocage des pulls. Active ou désactive l’analyse des images et définit l’action de blocage : none, warn ou block_pull. Avec block_pull, le pull d’une image ayant un résultat non ignoré égal ou supérieur à votre seuil de blocage est refusé, et la vérification fremforge/image-scan échoue. Voir Commutateurs de politique.
• Signatures des images au pull. À quelles signatures cosign vous faites confiance (une liste de signataires de confiance, de clés, ou le Sigstore public), à quelles images cela s’applique, et si un pull non signé est seulement enregistré (shadow) ou refusé (enforce). Voir Signatures d’images.

Règles des dépôts

Sécurité › Politiques › Règles des dépôts est une page unique pour les règles auxquelles chaque dépôt de l’organisation est soumis.

• Protection de branche (#org-baseline). La règle que reçoit chaque nouveau dépôt pour ses branches protégées : approbations requises, revue CODEOWNERS, vérifications de statut, historique linéaire et le reste. L’enregistrement applique immédiatement les valeurs par défaut aux dépôts existants. Voir Protection de branche.
• Signature des commits (#commit-signing). Un seul paramètre : lorsqu’il est activé, la branche par défaut de chaque dépôt exige des commits signés, et les nouveaux dépôts reçoivent la même exigence via les valeurs par défaut ci-dessus. Si un ancien paramètre a désynchronisé les deux, la page l’indique ; enregistrer la signature des commits les réaligne. Voir Require signed commits.
• Verrouillage global de l’organisation (#actions-gate) : Actions uniquement sur les branches protégées. Lorsqu’il est activé, un workflow ne s’exécute que sur une branche protégée, si bien qu’un push vers toute autre branche ne peut pas exécuter de code avec les secrets de l’organisation. Voir Actions uniquement sur les branches protégées.

Les anciennes adresses fonctionnent toujours : _admin/repo-defaults ainsi que les paramètres de signature des commits et d’Actions sous Organisation › Dépôts et Build et déploiement › Environnements renvoient désormais ici, par un lien ou une redirection.

API et Terraform

La liste complète, avec les portées et les champs, se trouve dans la référence de l’API et sur la page du provider Terraform.