CRACI pour les équipes PSIRT et les responsables de la sécurité produit

Le problème d'un responsable PSIRT

Un responsable de la sécurité produit doit rendre compte de réponses que le PSIRT ne produit pas seul. Quand une CVE touche une bibliothèque très utilisée, les clients, les dirigeants et, de plus en plus, les régulateurs posent les mêmes questions en quelques heures : sommes-nous touchés, dans quels produits et versions, depuis quand, et quand le correctif arrivera-t-il ?

Les réponses dépendent de l'inventaire, et l'inventaire provient généralement de scanners qui lisent les lockfiles ou les manifestes après coup. Ils listent des dépendances de développement jamais livrées et passent à côté de paquets que le build a téléchargés autrement. Le PSIRT demande alors aux équipes d'ingénierie de vérifier à la main, et la réponse arrive en plusieurs jours, avec des réserves.

Le FIRST PSIRT Services Framework juge un inventaire des composants de produits essentiel pour identifier rapidement les produits touchés par des vulnérabilités héritées. C'est par cet inventaire que CRACI commence. Pour une vue complète du rôle, consultez qu'est-ce qu'un PSIRT.

Ce que CRACI apporte à un PSIRT

Un inventaire enregistré à partir du build

CRACI exécute vos builds GitHub Actions sur ses propres runners et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets restaurés depuis les caches CI et les dépendances qu'aucun lockfile ne liste. C'est un enregistreur, pas un scanner. Chaque SBOM porte un état de complétude : un enregistrement partiel est donc signalé comme tel, et les SBOM s'exportent en CycloneDX ou SPDX.

Une surveillance continue de ce qui a été livré

Les SBOM surveillées sont réévaluées en continu à mesure que de nouvelles vulnérabilités sont publiées, et les résultats sont agrégés entre builds et dépôts. Une CVE publiée le mois prochain est confrontée aux releases que vous avez déjà livrées, pas seulement au prochain build. Les releases malveillantes connues qui ont une CVE publiée sont signalées comme toute autre vulnérabilité.

Produits, versions et périodes touchés

L'historique des builds montre chaque build passé avec sa SBOM, et lesquels contenaient une dépendance vulnérable, directe ou transitive : vous connaissez donc la période pendant laquelle vous avez été touchés, dans la limite de votre durée de conservation. La vue d'inventaire montre exactement quelles versions logicielles sont déployées sur quels produits. Ensemble, ils transforment « sommes-nous touchés ? » en une simple recherche.

Composants achetés

Les produits ne se composent que rarement de votre seul code. Vous pouvez ajouter des SBOM de fournisseurs, afin que les composants tiers soient surveillés en même temps que vos propres builds.

Tri, routage et VEX

Les équipes de sécurité trient les vulnérabilités découvertes et les envoient aux équipes responsables de la correction, ce qui correspond au modèle de PSIRT distribué où les équipes produit assurent la remédiation. CRACI prend en charge VEX. Consultez VEX pour voir comment les déclarations de non-impact évitent du travail à un PSIRT et à ses clients.

Empêcher une CVE corrigée de revenir dans les builds suivants

Les gates de politique peuvent bloquer un build selon les résultats, y compris les builds qui contiennent une CVE précise. Une fois un dossier PSIRT clos, une gate sur cette CVE empêche la version vulnérable de revenir discrètement dans une release ultérieure.

Des preuves pour les audits et les clients

L'API renvoie les SBOM, les traces réseau et la provenance de chaque build : l'enregistrement qui étaye un avis de sécurité ou une réponse d'audit est donc disponible hors de l'interface. Là où le Cyber Resilience Act de l'UE s'applique, CRACI soumet aussi les notifications requises aux autorités au nom du fabricant ; l'obligation reste celle du fabricant. Consultez qu'est-ce que le CRA.

La place de CRACI dans le processus PSIRT

Étape PSIRT	Ce qu'apporte CRACI
Préparation	Une SBOM par build, enregistrée pendant l'exécution, avec un état de complétude
Découverte	Réévaluation continue des SBOM surveillées, y compris les SBOM de fournisseurs
Vérification	Quels builds, versions et produits contiennent le composant, et depuis quand
Remédiation	Tri et envoi à l'équipe responsable ; gates de politique qui maintiennent la CVE hors des builds suivants
Publication et divulgation	Prise en charge de VEX ; export de SBOM ; accès API à l'enregistrement du build

Ces étapes suivent le cycle de vie de la gestion des vulnérabilités.

Ce que CRACI ne fait pas

• Analyse d'atteignabilité. CRACI montre qu'un paquet vulnérable était dans le build, pas si votre code appelle la fonction vulnérable.
• Analyse du code source. Le SAST et la recherche de secrets sont hors périmètre ; de nombreux bons outils le font aux côtés de CRACI.
• Systèmes CI autres que GitHub Actions. GitHub Actions aujourd'hui ; les autres systèmes CI figurent sur la roadmap.
• Conformité à votre place. CRACI fournit les preuves ; satisfaire à NIS2, au CRA ou à tout autre cadre relève du processus de votre organisation.

CRACI pour les équipes PSIRT : questions fréquentes

CRACI est-il un outil PSIRT ?

CRACI couvre la partie du travail PSIRT qui dépend de la connaissance de ce que vous livrez : SBOM de build, surveillance continue de celles-ci, identification des builds et produits contenant un composant vulnérable, et tri, puis envoi à l'équipe responsable. Votre canal de divulgation et votre processus d'avis de sécurité s'appuient sur cet enregistrement.

Comment CRACI sait-il ce que contient un produit ?

Les builds s'exécutent sur les runners GitHub Actions de CRACI, et CRACI enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets restaurés depuis les caches CI et les dépendances qu'aucun lockfile ne liste. C'est un enregistreur, pas un scanner. Chaque SBOM porte un état de complétude : vous savez donc quand l'enregistrement est partiel.

CRACI peut-il nous dire quelles anciennes releases ont été touchées par une CVE ?

Oui, dans la limite de votre durée de conservation. L'historique des builds montre chaque build passé et sa SBOM, et lesquels contenaient une dépendance vulnérable, directe ou transitive : vous connaissez donc la période pendant laquelle vous avez été touchés. La vue d'inventaire montre quelles versions logicielles sont déployées sur quels produits.

CRACI couvre-t-il les composants achetés à des fournisseurs ?

Vous pouvez ajouter des SBOM de fournisseurs : les composants achetés sont ainsi surveillés en même temps que vos propres builds.

CRACI prend-il en charge VEX ?

Oui. CRACI prend en charge VEX pour enregistrer la façon dont une vulnérabilité connue touche votre produit. Consultez VEX pour les statuts et les formats, et CSAF pour la façon dont les avis de sécurité les transportent.

Quels systèmes CI CRACI prend-il en charge ?

GitHub Actions aujourd'hui. Les autres systèmes CI figurent sur la roadmap.