Indicateurs de remédiation
Les indicateurs de remédiation montrent si les fonctionnalités de tri et de correction font leur travail pour votre organisation. La page mesure les indicateurs de réussite de l’atteignabilité et des Correctifs de sécurité sur vos propres résultats, sur les 30 ou 90 derniers jours, et compare chaque période avec le même nombre de jours juste avant.
Vous la trouverez sous Sécurité › Rapports › Indicateurs de remédiation (/<org>/_admin/security/reports/remediation). Les propriétaires de l’organisation et les membres de l’équipe Auditors de l’organisation peuvent l’ouvrir. Choisissez 30 derniers jours ou 90 derniers jours en haut de la page.
Chaque chiffre concerne uniquement votre organisation. Rien n’est comparé avec d’autres organisations ni calculé à partir d’elles.
La même page contient la carte Contribuer des chiffres anonymes : une option, désactivée par défaut, qui ajoute anonymement les chiffres de votre organisation à ceux que fremforge publie. Voir Chiffres anonymes.
Ce qu’elle montre
| Section | Ce qu’elle montre |
|---|---|
| Atteignabilité | Les résultats de dépendances ouverts par écosystème, répartis par verdict : atteignable, non atteignable (unreachable) et inconnu. La Couverture est la part dont le verdict n’est pas inconnu. La part sans chemin d’appel est la part pour laquelle le moteur n’a trouvé aucun chemin de votre code vers la fonction vulnérable. Les objectifs sont 60 % de couverture pour Go et 30 % pour npm, et 30 % de non atteignables pour Go. Les écosystèmes sans moteur sont signalés. |
| Tendance de la couverture | La couverture et la part de non atteignables par jour, à partir d’un instantané quotidien des propres résultats de votre organisation. L’instantané a commencé le 2026-10-14, si bien que le graphique se remplit à partir de cette date ; tant que deux jours ne sont pas enregistrés, le panneau indique qu’il collecte des données. |
| Pull requests de correctif de sécurité | Par moteur, déterministe (montées de version de dépendances) et assisté par IA (SAST, avec votre propre clé de modèle) : les demandes faites sur la période, les pull requests ouvertes, fusionnées, fermées et encore en attente de revue, et le taux de fusion (fusionnées divisées par ouvertes). Les objectifs sont 70 % pour les pull requests déterministes et 40 % pour celles assistées par IA. |
| Résultats corrigés par un correctif de sécurité | Les résultats qu’une analyse a cessé de signaler après la fusion de leur pull request de correctif de sécurité, par type et par jour. L’API renvoie aussi findings_fixed_by_renovate : les résultats dont le paquet a été mis à jour par l’une des pull requests de sécurité propres à Renovate hébergé alors qu’ils étaient ouverts (comptés depuis le 2026-10-14). |
| Délai de correction | Le nombre médian de jours entre la première détection d’un résultat de dépendance élevé ou critique et le moment où une analyse ne l’a plus signalé. Cette période comparée à la précédente et, au sein de cette période, les résultats corrigés par AutoFix comparés à ceux corrigés autrement. |
| Délai de correction par type de résultat | Pour les dépendances, les images de conteneurs, l’IaC, les secrets et le SAST, toutes gravités : le nombre médian de jours de correction des résultats corrigés sur cette période et sur la précédente, les médianes par gravité, et les résultats ignorés sur cette période avec leur propre médiane. Voir les définitions ci-dessous. |
| Délai de fusion des correctifs de sécurité | Le nombre médian d’heures entre l’ouverture et la fusion des pull requests de correctif de sécurité fusionnées sur cette période et sur la précédente : déterministes, assistées par IA, et pull requests de sécurité propres à Renovate hébergé. Les pull requests Renovate sont comptées depuis le 24 octobre 2026, date à laquelle leur heure d’ouverture a commencé à être enregistrée ; la page indique la date. |
| Connues comme exploitées | Les résultats ouverts de dépendances et d’images de conteneurs dont la vulnérabilité est listée comme exploitée par l’EU Vulnerability Database de l’ENISA ou le catalogue Known Exploited Vulnerabilities de la CISA, avec des liens vers les listes de résultats filtrées. |
| Dépassements de SLA | Par jour, les résultats de chaque analyseur ouverts au-delà de leur SLA, toutes gravités ainsi qu’élevés et critiques, et les nouveaux dépassements par jour. Les totaux pour cette période et pour la précédente. |
Comment les chiffres sont calculés
- Résultats uniques. Un résultat de dépendance compte une fois par dépôt, paquet et avis, quel que soit le nombre de branches ou de pull requests qui le signalent. Les résultats de dépendances ouverts sont comptés de la même façon chaque jour de la tendance.
- L’instantané quotidien est pris une fois par jour pour votre seule organisation, à partir du même décompte que les chiffres de couverture ci-dessus, et n’est jamais combiné avec les données d’autres organisations. Il est conservé aussi longtemps que votre paramètre d’historique des résultats lorsque vous en avez réglé un, sinon pendant 18 mois, et il est supprimé lorsque votre organisation est supprimée. Une conservation légale le maintient.
- Les verdicts ne sont pas des dérogations. Un résultat non atteignable reste ouvert et est compté comme ouvert partout. Voir atteignabilité.
- Les pull requests de correctif de sécurité sont comptées à la date à laquelle le correctif a été demandé. Une pull request encore en attente de revue fait baisser le taux de fusion jusqu’à ce qu’elle soit fusionnée ou fermée.
- Le délai de correction et les dépassements de SLA proviennent de l’historique des résultats, qui commence lorsque le suivi de l’historique de votre organisation a démarré (la page indique la date). Un résultat déjà ouvert à cette date compte à partir du moment où il a été enregistré pour la première fois.
- Ce qui compte comme ouvert et corrigé (délai de correction par type) :
- Ouvert correspond à la première détection du résultat sur la branche par défaut. Un résultat signalé uniquement par une pull request n’est pas compté.
- Corrigé correspond à la première analyse qui ne le signale plus. Pour un résultat que son analyseur marque comme résolu, c’est exact ; sinon, c’est la mise à jour quotidienne de l’historique qui l’a manqué la première, donc au plus un jour de retard.
- Une dérogation n’est pas une correction. Les résultats ignorés sont comptés à part, avec le nombre médian de jours entre l’ouverture et la dérogation.
- Un résultat qui revient repart de zéro. Il compte à partir de sa réapparition, pas de sa première apparition.
- Les résultats IaC ont leur propre type depuis le 24 octobre 2026 ; auparavant, ils étaient comptés avec les images de conteneurs. L’historique antérieur à cette date a été déplacé vers l’IaC lorsque l’enregistrement du résultat par l’analyseur existe encore.
- Le délai de fusion va de l’ouverture de la pull request à sa fusion, pour les pull requests fusionnées sur la période. Les pull requests encore ouvertes ou fermées sans fusion ne sont pas comptées.
- Les échéances de SLA sont les mêmes échéances effectives que celles des pastilles SLA et du rapport de conformité, y compris un SLA plus long pour les résultats non atteignables lorsque votre politique de SLA définit un multiplicateur. Un résultat dépasse son SLA lorsque l’échéance passe alors qu’il n’est ni corrigé ni ignoré.
API
Les mêmes chiffres sont disponibles via l’API avec un jeton disposant de la portée findings:read :
curl -H "Authorization: Bearer $FREMFORGE_TOKEN" \
"https://frem.sh/_app/api/v1/orgs/<org>/code-security/remediation-metrics?days=30"days vaut 30 (par défaut) ou 90. La réponse contient les sections ci-dessus sous reachability, autofix, time_to_fix, time_to_fix_by_type, time_to_merge, known_exploited et sla, ainsi que window et targets. Les pourcentages sont des nombres de 0 à 100 avec une décimale, ou null lorsqu’il n’y a rien à diviser. Voir la spécification OpenAPI pour le schéma.