SLA des constats et de la plateforme

Comprenez les états SLA de remédiation des constats et les objectifs de disponibilité Team ou Regulated, avec leurs limites et webhooks.

Deux sens distincts de SLA

CodeCleared utilise « SLA » dans deux contextes. Il faut les distinguer dans les communications aux parties prenantes.

SLA de remédiation des constats

Sur la branche de gouvernance, un constat peut être opened, at_risk, breached, ignored, resolved ou reopened. Ces états suivent l’engagement de remédiation défini par votre politique. Abonnez-vous aux webhooks finding.sla.* si un autre système doit réagir, ou utilisez le suivi des tickets Jira / Linear pour ouvrir des tickets automatiquement.

Un constat ignoré reste une décision tracée. Un ignore au niveau rule ou CVE marque les constats correspondants comme ignored sur la gouvernance ; désignorer les remet en revue active s’il ne reste aucun autre ignore actif qui les couvre. Un ignore d’occurrence ne concerne qu’une clé de constat.

Horloge de délai (paramètre organisation)

Par défaut, les échéances partent de la première détection plus les jours de sévérité (comportement historique inchangé).

L’organisation peut basculer l’horloge sur corrigible depuis : pour les vulnérabilités, le délai démarre quand CodeCleared observe pour la première fois qu’un correctif est disponible (fixableFromAt). Tant qu’aucun correctif n’est connu, il n’y a pas d’échéance (pas de at_risk / breached dus à l’horloge seule). Un changement de ce paramètre recalcule immédiatement les constats ouverts. Il n’existe pas de webhook « unbreached » quand un constat quitte breached ; Virtual 0 et le tableau de bord suivent le statut stocké.

Les autres types de constats utilisent toujours la première détection.

Ignorer tant qu’aucun correctif (project unit)

Indépendamment, une project unit peut activer ignorer tant qu’aucun correctif n’est disponible. Les vulnérabilités non corrigibles reçoivent alors un ignore système (awaiting-fix, une ligne par occurrence package) jusqu’à ce qu’un correctif soit connu. C’est distinct de l’ignore manuel Non corrigible, qui ne se termine jamais automatiquement. Les lignes awaiting-fix ne sont ni créables ni suppressibles via l’API d’ignore — désactivez le réglage de la project unit. Quand un correctif apparaît (scan ou rafraîchissement du cache d’advisories), le système ne lève que l’awaiting-fix de cette occurrence et reprend l’horloge selon le réglage org.

Colonnes « corrigible » sur le tableau Virtual 0

Pour les constats de type vulnérabilité, le tableau SLA / Virtual 0 affiche :

Corrigible — si CodeCleared connaît actuellement un correctif (fixedVersion du scan et/ou données d’advisory OSV en cache).
Corrigeable depuis — la date à laquelle CodeCleared a observé pour la première fois qu’un correctif était disponible, plus le nombre de jours écoulés.

Il s’agit d’un horodatage de découverte plateforme, pas d’une date officielle « correctif publié le » côté vendor (NVD/OSV). Les caches d’advisories se rafraîchissent via un import bulk nocturne et un sync périodique par ID (décalage typique jusqu’à environ 24 h pour les correctifs visibles seulement via OSV), en plus des métadonnées de correctif déjà présentes au scan. Après ces rafraîchissements, les constats suivis et les ignores auto se mettent à jour sans attendre un nouveau scan. Les autres types de constats affichent « — ».

SLA de disponibilité de la plateforme

Team a un objectif de disponibilité de 99,9 % et Regulated de 99,99 %, selon l’accord applicable. Ces chiffres décrivent la disponibilité du service ; ils ne promettent pas qu’un constat sera corrigé, qu’une analyse finira à une heure donnée ou que tout risque sera détecté.