Rapport de conformité

Le rapport de conformité répond aux questions qu’un auditeur pose sur la gestion des vulnérabilités : ce qui était ouvert, ce qui a été corrigé et à quelle vitesse, si les correctifs ont respecté vos SLA par gravité, quels risques ont été acceptés et par qui, et quelle politique était en vigueur. Vous choisissez la période et, si vous le souhaitez, un dépôt.

Vous le trouverez sous Sécurité › Rapports › Rapport de conformité (/<org>/_admin/security/reports/compliance). Les propriétaires de l’organisation et les membres de l’équipe Auditors de l’organisation peuvent l’ouvrir et le télécharger.

Ce qu’il contient

Section	Ce qu’elle montre
Résultats ouverts	Les résultats ouverts à la fin de la période, par type et par gravité. Types : dépendances, images de conteneurs (y compris les images récupérées via le proxy de dépendances), IaC, licences, SAST, secrets, malwares et paquets du registre. Les résultats ignorés et corrigés ne sont pas comptés.
Remédiation	Par gravité : les résultats ouverts, corrigés et ignorés sur la période, le délai moyen entre ouverture et correction, et le respect des SLA. Par type : ouverts, corrigés, ignorés, le délai moyen de correction, et encore ouverts. Puis le délai de fusion des pull requests de correctif de sécurité fusionnées sur la période (heures médianes, par source) ; il couvre toute l’organisation, et il est donc omis d’un rapport portant sur un seul dépôt. La page des indicateurs de remédiation définit ouvert, corrigé et délai de fusion.
Dépassements de SLA	Les résultats de tout type dont l’échéance de SLA est passée sur la période alors qu’ils étaient encore ouverts, à côté des événements `code-security.sla.breached` enregistrés pour les résultats de dépendances (ceux envoyés à votre SIEM).
Exceptions en vigueur	Les exceptions approuvées en vigueur à la fin de la période, avec qui a demandé et qui a approuvé chacune, et sa date d’expiration. Une exception révoquée ou expirée plus tard apparaît quand même si elle était en vigueur à ce moment-là.
Composants les plus risqués	Jusqu’à 20 composants classés selon un décompte pondéré par gravité de leurs avis ouverts (critique 10, élevée 5, moyenne 2, faible 1). Issus de l’inventaire des composants.
Paramètres de politique	Les paramètres en vigueur au moment de la génération du rapport : jours de SLA, politique d’analyse et seuils des analyseurs, la politique de licences avec ses listes de refus, d’avertissement et d’autorisation, la politique de paquets avec ses listes de refus et d’autorisation, le mode d’analyse des modèles et les paramètres d’exception.
Historique des résultats	Chaque résultat qui a été ouvert à un moment de la période, avec la date de son ouverture, de sa correction ou de sa dérogation, et son état de SLA. CSV uniquement.
Inventaire IA	Les fichiers de modèles que détient votre organisation au moment de la génération du rapport : combien, combien votre politique d’analyse des modèles bloque ou bloquerait, combien ont un résultat ignoré, votre mode d’analyse des modèles, les récupérations de modèles en CI sans révision fixe, et les fichiers par licence déclarée. Toujours pour toute l’organisation. Le CSV liste chaque fichier de modèle.
IaC par référentiel et par domaine NIS2	Les résultats IaC ouverts au moment de la génération du rapport, groupés par les contrôles de référentiel que testent leurs vérifications et par domaine NIS2 ; voir ci-dessous. Pour le dépôt lorsque vous en choisissez un.

Les gravités suivent la vue d’ensemble de la sécurité : un SAST error compte comme élevé et warning comme moyen ; une licence interdite compte comme critique et une licence restreinte comme élevée ; les secrets et les malwares sont critiques.

Le respect des SLA pour une gravité correspond aux résultats corrigés dans leur SLA, divisés par ceux corrigés dans le délai, ceux corrigés après et ceux encore ouverts au-delà à la fin de la période. Une gravité sans SLA n’a pas de taux de respect.

Résultats non atteignables. Si votre organisation a activé le multiplicateur de SLA, chaque chiffre de SLA (respect, dépassements sur la période et date d’échéance de chaque résultat) utilise la même échéance que les pastilles SLA, le résumé et les événements SIEM de dépassement : un résultat de dépendance ou d’image n’est mesuré par rapport au SLA allongé que lorsque chacune de ses lignes actuelles a le verdict Non atteignable, et jamais lorsque son EPSS le rend susceptible d’être exploité. Lorsque le SLA allongé diffère du SLA de la politique, le rapport affiche les deux : « 30, 60 sans chemin d’appel » et le nombre de résultats mesurés par rapport au SLA allongé. Le CSV et le JSON portent sla_days (l’échéance utilisée), policy_sla_days, policy_sla_due_at et sla_multiplier par résultat, et unreachable_sla_days et stretched_sla_findings par gravité. Avec un multiplicateur de 1, rien ne change.

Les résultats des paquets du registre n’apparaissent que pour une organisation dont le pipeline de politique de paquets est activé. Sinon, le rapport les omet et l’indique ; votre propre politique de paquets et ses exceptions restent listées.

IaC par référentiel et par domaine NIS2

Par référentiel. Une ligne par référentiel : combien de ses contrôles ont un résultat ouvert, combien de ses contrôles les vérifications de fremforge testent, les résultats ouverts, et les identifiants des contrôles ayant des résultats. Les correspondances sont les spécifications de conformité propres à Trivy (MIT), dans la version qu’exécutent les analyseurs, pour neuf référentiels : CIS Docker 1.6.0, CIS Kubernetes 1.23, RKE2 CIS 1.24, EKS CIS 1.4, le guide de durcissement Kubernetes de la NSA 1.0, les Pod Security Standards baseline et restricted, et CIS AWS 1.2 et 1.4. Seuls les identifiants de contrôles, les gravités et les vérifications qui les testent sont inclus ; le texte des référentiels n’est pas reproduit (le CIS le publie sous sa propre licence), et le nom de chaque référentiel renvoie vers sa spécification publiée. Il n’y a pas de référentiel Azure ni Google Cloud : Trivy ne publie de correspondance pour aucun des deux.

Par domaine NIS2. Les mêmes résultats, selon la mesure de l’article 21(2) de NIS2 que concerne chaque vérification : (b) gestion des incidents, (c) continuité des activités, (e) configuration sécurisée, (h) cryptographie et chiffrement, (i) contrôle d’accès. Ce regroupement est propre à fremforge, établi à partir du titre de chaque vérification, car il n’existe aucune correspondance ouverte entre ces vérifications et NIS2. Ce n’est pas une correspondance officielle et elle n’atteste la conformité à aucune mesure.

Les vérifications propres de votre organisation comptent dans le domaine NIS2 (e), sauf si leur titre nomme l’un des autres ; elles ne correspondent à aucun contrôle de référentiel. En l’absence de résultat IaC ouvert, la section l’indique en une ligne.

Formats

Résumé PDF : chaque section résumée sur quelques pages A4, dans la langue de votre console (anglais, danois, allemand, français, néerlandais, norvégien ou suédois).
CSV : un fichier par section (open, remediation, sla, exceptions, components, policy, findings, ai_inventory, iac_compliance), chacun complet, avec des noms de colonnes stables en anglais, pour un tableur ou un script. iac_compliance a une ligne par contrôle de référentiel ayant des résultats et une par domaine NIS2 : grouping, framework, version, control, severity, checks (les identifiants de vérifications, séparés par des espaces) et open_findings.

Chaque téléchargement est enregistré dans le journal d’audit sous compliance.security_report.generated.

La période

Des jours entiers en UTC, bornes incluses, au plus 366 jours. Par défaut, les 30 derniers jours. Un résultat ouvert à 00:00:00 le premier jour ou corrigé à 23:59:59 le dernier compte comme faisant partie de la période.

D’où vient l’historique

La plupart des analyseurs remplacent leurs résultats à chaque analyse, si bien que les tables des analyseurs ne peuvent pas à elles seules dire quand quelque chose a été corrigé. fremforge enregistre donc le cycle de vie de chaque résultat (ouvert, corrigé, ignoré) une fois par jour pour chaque organisation, et de nouveau à chaque génération de rapport. Le rapport lit cet enregistrement, et sa dernière section, À propos de l’historique, indique ce qu’il peut et ne peut pas montrer :

L’historique commence à la date à laquelle l’enregistrement a démarré pour votre organisation. Une correction antérieure à cette date n’est comptée que si l’analyseur a conservé le résultat (il marque les résultats qu’une analyse ultérieure ne signale plus, et les résultats de paquets malveillants et de paquets du registre conservent leurs propres dates de résolution). Pour un résultat déjà ouvert, la date d’ouverture est celle que l’analyseur a enregistrée.
Les heures de correction sont exactes à l’heure près ou à un jour près. Lorsque l’analyseur a marqué la correction, son heure est utilisée. Lorsqu’un résultat a simplement disparu, la correction est enregistrée lorsque l’enregistrement quotidien, ou un rapport, ne le trouve plus pour la première fois.
Les résultats d’un dépôt supprimé, renommé ou transféré comptent comme corrigés le jour de leur retrait : après la fenêtre de restauration de 30 jours pour un dépôt supprimé, ou dès que l’ancien nom n’existe plus pour un dépôt supprimé définitivement, renommé ou transféré. Voir Conservation des preuves.
Les résultats SAST qui étaient ouverts avant le début de l’enregistrement portent leur dernière analyse comme date d’ouverture, car l’analyseur SAST ne conserve pas de date de première détection.
Les dérogations sont affichées telles qu’elles sont aujourd’hui ; une dérogation levée plus tard ne figure pas dans le rapport.

Via l’API REST

GET /_app/api/v1/orgs/{org}/security/compliance-report
    ?from=2026-09-01&to=2026-09-30
    &repo=web                          optional, a repository of the org
    &format=json | pdf | csv           default json
    &section=open|remediation|sla|exceptions|components|policy|findings|ai_inventory|iac_compliance   with format=csv
    &lang=en|da|de|fr|nl|sv            PDF language; else Accept-Language, else English

Nécessite un jeton disposant de findings:read. Le JSON est le rapport complet, y compris history.notes. Exemple :

curl -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
  "https://frem.sh/_app/api/v1/orgs/acme/security/compliance-report?from=2026-07-01&to=2026-09-30&format=pdf&lang=da" \
  -o compliance-report.pdf

Le joindre au résumé hebdomadaire

Un propriétaire de l’organisation peut joindre le PDF au résumé de sécurité : cochez Joindre ce rapport en PDF au résumé de sécurité en bas de la page du rapport. C’est désactivé par défaut. Le rapport joint couvre la période propre au résumé (7 jours, ou 1 jour pour un abonnement quotidien) et est rédigé dans la langue de chaque destinataire.

Via l’API : PUT /_app/api/v1/orgs/{org}/security/compliance-report/settings avec {"digest_attachment": true} (policy:write) ; lisez-le avec GET sur le même chemin (policy:read).

Protection de branche Récapitulatif quotidien des alertes