Branches de release

Si vous maintenez d’anciennes versions sur des branches telles que release/1.x, ces branches sont elles aussi livrées à vos clients. fremforge analyse chaque branche de release protégée avec les mêmes analyseurs que votre branche par défaut. Ses résultats sont listés par branche, et aucun d’eux n’est compté dans les chiffres de votre branche par défaut.

Quelles branches sont analysées

Une branche est analysée comme branche de release lorsque les deux conditions suivantes sont remplies :

elle correspond à l’un des motifs de branches protégées de votre organisation (Dépôts › Protection de branche, main,master,release/* par défaut), ou à l’une des règles de protection de branche propres au dépôt ;
ce n’est pas la branche par défaut du dépôt.

La branche par défaut est celle que Forgejo enregistre pour le dépôt, jamais un paramètre de l’analyse. Si vous renommez la branche par défaut, le nouveau nom compte comme branche par défaut dès l’analyse suivante, et l’ancien nom est désormais traité comme une branche de release, s’il est toujours protégé.

Quand elles sont analysées

Au push. Un push vers une branche de release demande une analyse de cette branche. Plusieurs push rapprochés donnent une seule analyse du dernier commit.
Chaque semaine. Chaque branche de release est réanalysée au moins une fois par semaine, afin que les nouveaux avis atteignent les branches sur lesquelles personne ne pousse. Une branche est analysée immédiatement la première fois qu’elle est trouvée.
Les branches supprimées ou non protégées sont oubliées. Supprimer une branche retire ses résultats. Une branche qui ne correspond plus à aucun motif de protection est retirée au passage hebdomadaire suivant.

Analyser une branche de release coûte le même temps de runner qu’analyser votre branche par défaut, à chaque push et une fois par semaine. Les branches de release ne sont pas incluses dans la réanalyse quotidienne des images ni dans le balayage hebdomadaire de l’historique des secrets.

Tenues à l’écart de votre branche par défaut

Les résultats des branches de release sont stockés à part. Les chiffres de votre branche par défaut ne changent pas : la vue d’ensemble, les listes de résultats et leurs décomptes, les dépassements de SLA et les indicateurs de SLA, ainsi que le cycle de vie des résultats.

Date limite de correction, pas d’indicateurs de SLA. Chaque résultat d’une branche de release affiche une date limite de correction tirée de votre délai de correction (SLA) pour sa gravité, comptée à partir de la première fois où le résultat a été vu sur cette branche, ou Pas de SLA lorsque la gravité n’en a pas. Ces dates sont affichées pour la planification. Elles ne sont pas comptées dans les dépassements de SLA, la tuile SLA ni aucun indicateur de SLA.
Les alertes et le résumé hebdomadaire listent les branches de release dans une section à part : les résultats critiques et élevés nouveaux et ouverts, par branche. Les chiffres de la branche par défaut qu’ils contiennent ne changent pas.

Dans la console

Sécurité › Résultats › Tous affiche une ligne de branches dès qu’une branche de release a été analysée : Branche par défaut, puis une puce par branche de release avec ses résultats ouverts. Choisir une branche ne liste que les résultats de cette branche, avec une colonne À corriger avant. Les filtres de type et de gravité fonctionnent comme d’habitude.

Le menu de chaque ligne propose :

Ignorer sur cette branche : voir Dérogations.
Proposer une PR de correctif sur cette branche, sur un résultat de dépendance qui a une version corrigée : voir Correctifs de sécurité. Tant qu’un correctif est en file d’attente ou que sa pull request est ouverte, la ligne renvoie vers celle-ci à la place.

Dérogations

Une dérogation sur une branche de release ne s’applique qu’à cette branche. C’est une entrée de la même liste d’Exceptions que toute autre dérogation, avec l’identifiant branch.<finding id> et la portée branch, et elle nomme la branche. Révoquez-la à cet endroit, et le résultat est de nouveau ouvert. Les paramètres d’exception de votre organisation s’appliquent, y compris l’expiration maximale.

Limitation : lorsque les dérogations nécessitent une approbation, seul un approbateur peut ignorer un résultat de branche de release. La file de demande et d’approbation ne couvre pas encore les branches de release. Une dérogation par quelqu’un d’autre est refusée (403 approval-required via l’API, un avis dans la console) et le résultat reste ouvert.

Correctifs de sécurité

Un résultat de dépendance qui a une version corrigée peut obtenir une pull request de correctif de sécurité vers sa branche de release. Tout fonctionne comme sur votre branche par défaut, avec ces différences :

La pull request cible la branche de release, depuis sa propre branche security-fix/<branch>/<package>-<version>, par exemple security-fix/release-1.x/lodash-4.17.21.
Elle corrige chaque résultat ouvert sur ce paquet sur cette branche, avec la version la plus basse qui les corrige tous.
Un seul correctif actif par paquet et par branche. Le même paquet sur votre branche par défaut et sur release/1.x reçoit deux correctifs distincts. Les limites de votre organisation comptent toutes les branches ensemble.
Une pull request que l’exécution ouvre vers toute autre branche est fermée, avec le motif scope_base.
Un correctif compte comme résolu lorsque l’analyse suivante de la branche de release ne signale plus ses résultats.

Il n’est jamais fusionné automatiquement, comme sur la branche par défaut.

Pull requests vers une branche de release

Les vérifications d’une pull request vers une branche de release la comparent avec la dernière analyse de cette branche, pas avec celle de la branche par défaut. Une pull request n’est bloquée que par les résultats qu’elle introduit. Une pull request qui ne modifie que de la configuration n’est pas bloquée par des résultats déjà présents sur la branche de release.

API

Appel	Ce qu’il fait
`GET /orgs/{org}/security/release-branches`	Les branches de release analysées, chacune avec son nombre de résultats ouverts.
`GET /orgs/{org}/security/findings?branch=release/1.x`	Les résultats de cette branche, sous la même forme que ceux de la branche par défaut, avec en plus `branch` et `fix_by`. Une branche inconnue renvoie `404 unknown-branch`.
`POST /orgs/{org}/security/release-findings/{id}/dismiss`	Ignorer sur cette branche : `reason`, `expires_at` facultatif.
`POST /orgs/{org}/security/release-findings/{id}/autofix`	Mettre en file un correctif de sécurité vers cette branche. La réponse contient `base_branch`.

curl -sS "https://frem.sh/_app/api/v1/orgs/acme/security/findings?branch=release%2F1.x" \
  -H "Authorization: Bearer $FREMFORGE_TOKEN"

Les lectures nécessitent findings:read, et les dérogations et correctifs findings:write. Voir la référence de l’API pour chaque champ.

Si Forgejo est injoignable

Pour enregistrer une analyse, fremforge doit savoir si la branche analysée est la branche par défaut. Lorsque Forgejo ne peut pas le dire, l’analyse n’est pas abandonnée, et la réponse n’est pas devinée non plus. L’analyse est mise en attente et enregistrée dès que Forgejo répond, normalement en quelques minutes. D’ici là, les résultats de cette branche affichent l’analyse précédente.

Délai de correction (SLA)Divulgation des vulnérabilités