Délai de correction (SLA)
Chaque résultat ouvert (SAST, dépendances, images de conteneurs, logiciels malveillants) porte une pastille SLA à côté de sa gravité. La pastille est calculée à partir d’une seule donnée, l’ancienneté du résultat, et d’une seule configuration, la politique de SLA par gravité de votre organisation.
Valeurs par défaut
D’emblée, chaque organisation dispose des objectifs suivants :
| Gravité | SLA par défaut |
|---|---|
| Critique | 7 jours |
| Élevée | 30 jours |
| Moyenne | 90 jours |
| Faible | pas de SLA |
Ces valeurs par défaut correspondent aux rythmes de correctifs courants en entreprise cités dans NIST SP 800-40r4 et dans des référentiels similaires. Resserrez-les si vos exigences d’audit l’imposent.
États possibles de la pastille
La couleur de la pastille indique son état ; son texte indique les jours.
- Dans les délais (vert) : sous le SLA, à moins de 80 % du chemin vers l’échéance. La pastille affiche l’âge du résultat rapporté au SLA, par exemple
12/30 j. - Échéance proche (orange) : entre 80 % et 100 % de l’échéance. Prévoyez un correctif cette semaine. La pastille affiche les jours restants, par exemple
5 j restants. - Dépassé (rouge) : échéance passée. Comptabilisé dans le récapitulatif hebdomadaire et dans la tuile « Dépassements de SLA » de la vue d’ensemble. La pastille affiche le dépassement, par exemple
3 j hors SLA. - Pas de SLA (gris) : aucune politique n’est associée à la gravité (le cas par défaut pour
low). La pastille affichePas de SLA.
Le seuil de 80 % de l’échéance pour l’état échéance proche est délibéré : la plupart des correctifs demandent un vrai travail de préparation, de relecture et de déploiement, et faire apparaître l’avertissement avant l’échéance vous laisse cette marge.
Définir la politique de l’organisation
Le SLA de l’organisation se modifie sous Sécurité › Prioriser › Délai de correction (SLA) (/<org>/_admin/security/prioritise/sla). Choisissez une échéance plus courte par gravité : le calcul des dépassements lit immédiatement la ligne security_sla_policy de l’organisation, sans nouvelle analyse. Les valeurs par défaut ci-dessus s’appliquent tant que vous ne les remplacez pas. Si vous avez besoin d’une forme de SLA personnalisée qui ne repose pas sur le temps écoulé (par exemple des jours ouvrés ou des calendriers de jours fériés), ouvrez un ticket de support.
Résultats non atteignables (multiplicateur optionnel)
Pour les résultats sur les dépendances et les images de conteneurs, fremforge calcule un verdict d’atteignabilité. Votre organisation peut allonger le SLA des résultats dont le verdict est non atteignable (unreachable) d’un facteur entier compris entre 1 et 4, avec le multiplicateur situé sur la même page, Sécurité › Prioriser › Délai de correction (SLA). La valeur par défaut, 1, le désactive.
| Verdict | SLA |
|---|---|
Aucun chemin d’appel (unreachable) | Le SLA complet × le multiplicateur |
| Atteignable, inconnu ou non analysé | Le SLA complet, toujours |
| Exploitation connue : répertoriée par l’UE (ENISA EUVD) ou les États-Unis (CISA KEV) | Le SLA complet, quelle que soit la gravité et quel que soit le verdict |
| Critique avec un EPSS dans les 10 % supérieurs | Le SLA complet, quel que soit le verdict |
L’échéance est toujours comptée à partir de la première détection du résultat. Si une analyse ultérieure trouve un chemin d’appel, ou ne parvient pas à trancher, le SLA complet s’applique de nouveau immédiatement : un résultat peut donc passer directement à Dépassé. Une pastille allongée affiche ×2 (ou ×3, ×4), et son infobulle indique les deux échéances ; lorsque le multiplicateur est activé, l’infobulle d’une pastille au SLA complet explique pourquoi elle n’est pas allongée. Les résultats SAST, de licence, de secrets et de logiciels malveillants n’ont pas de verdict et conservent le SLA complet.
Le multiplicateur ne modifie que les échéances. Ce qui bloque une pull request reste inchangé, et aucun résultat n’est masqué ni ignoré.
Les résultats sur des branches de version protégées affichent eux aussi une date de correction issue de cette politique, mais ils ne sont comptés ni dans les dépassements de SLA, ni dans la tuile SLA, ni dans aucune métrique de SLA.
À propos de la portée du SLA. Le tableau ci-dessus est l’horloge de correction des résultats : le délai dont vous disposez pour clore un résultat signalé sur votre code. Elle est distincte de deux autres SLA documentés ailleurs sur fremforge :
- Le SLA de correctif des CVE de la plateforme (Critique 48 h / Élevée 72 h / Moyenne 7 j) couvre la rapidité avec laquelle fremforge corrige sa propre pile ; voir les engagements de sécurité de la plateforme dans Sécurité et chaîne d’approvisionnement.
- Le SLA de divulgation des vulnérabilités (correctif critique en 24 h / divulgation 30 j après le correctif, etc.) couvre les vulnérabilités de fremforge lui-même signalées par des chercheurs ; voir Divulgation des vulnérabilités.
Via l’API REST
La politique de SLA par gravité peut être définie via l’API publique : c’est utile pour imposer une posture cohérente à de nombreuses organisations depuis un script de configuration ou un pipeline de conformité.
- Mettre à jour la politique
PUT /_app/api/v1/orgs/:slug/security/sla-policycorps :{ "critical_sla_days": 3, "high_sla_days": 14, "medium_sla_days": 60, "low_sla_days": null, "unreachable_sla_multiplier": 2 }
Chaque champ de jours accepte de 1 à 365 jours, ou null pour laisser une gravité sans SLA ; un champ de jours absent vaut null. unreachable_sla_multiplier accepte un nombre entier de 1 (désactivé) à 4 ; contrairement aux champs de jours, l’omettre conserve la valeur enregistrée. GET /_app/api/v1/orgs/:slug/security renvoie la politique. Chaque modification est auditée sous code-security.sla_policy.updated, avec le multiplicateur précédent lorsqu’il a changé. Nécessite un jeton d’accès personnel (PAT) avec la portée policy:write :
curl -X PUT \
-H "Authorization: Bearer ${FREMFORGE_PAT}" \
-H "Content-Type: application/json" \
-d '{"critical_sla_days":3,"high_sla_days":14,"medium_sla_days":60,"low_sla_days":null}' \
https://frem.sh/_app/api/v1/orgs/acme/security/sla-policyConsultez la référence de l’API REST publique pour la spécification OpenAPI complète.
Le rapport de conformité mesure le respect du SLA sur la période de votre choix : résultats corrigés dans leur SLA, corrigés après, et encore ouverts au-delà, par gravité. Lorsque le multiplicateur est activé, il mesure chaque résultat par rapport à la même échéance que sa pastille et affiche le SLA de la politique à côté du SLA allongé.
Comment les dépassements alimentent d’autres pages
- Le widget des PR de sécurité ouvertes sur
/<org>/_admin/overviewmet d’abord en avant la recommandation dépassée la plus grave. - Le récapitulatif hebdomadaire compte les dépassements dans son résumé d’en-tête.
- Le transfert vers le SIEM émet des événements d’audit
code-security.sla.breachedla première fois qu’un résultat franchit la limite. Lorsque le multiplicateur est activé, l’événement d’un résultat allongé contient aussifull_sla_daysetunreachable_sla_multiplier.
Le décompte du récapitulatif, la tuile de la vue d’ensemble et l’événement SIEM utilisent tous les mêmes échéances que les pastilles, multiplicateur compris. L’API des résultats les renvoie également, sous la forme d’un objet sla sur chaque résultat de dépendance et d’image (state, sla_days, due_at, full_sla_days, full_due_at, unreachable_multiplier, exempt). exempt vaut known_exploited (avec exempt_sources : euvd, cisa_kev) ou exploit_likely (critique, EPSS dans les 10 % supérieurs) lorsqu’un multiplicateur activé n’a pas été appliqué pour cette raison, et null sinon.
Voir aussi
- Recommandations OSV : la liste de correctifs qui boucle la boucle.
- Protection au push : les secrets sont traités avant la réception plutôt que par une horloge de SLA.