Commencez par un produit

La boucle de travail

Inventaire, surveiller, décider, puis informer

Chaque étape ultérieure lit les mêmes produits et versions. Vous ne commencez pas par un dump de scanner ni par une chaîne de reconstruction.

1. Créer les produits et versions

   Un produit est ce pour quoi le CRA vous tient responsable. Donnez-lui un nom, une période de support et une classe de risque. Listez ensuite chaque version de firmware que vous avez mise sur le marché. C'est contre cette liste qu'une autorité, et plus tard un avis, circonscrira le périmètre.

2. Attacher les SBOM

   Téléversez CycloneDX ou SPDX par version, ou faites pousser votre pipeline à chaque compilation depuis GitHub Actions, GitLab CI, ou tout CI capable d'appeler l'API. Si le document fournisseur manque ou que vous ne lui faites pas pleinement confiance, dérivez un inventaire depuis le binaire firmware.

3. Surveiller les SBOM

   Des passages planifiés revérifient chaque inventaire stocké contre le renseignement sur les vulnérabilités. Les nouveaux constats élevés et critiques vont dans votre boîte PSIRT, jamais chez vos clients. La superposition KEV et EUVD vous dit quand quelque chose que vous avez déjà livré est activement exploité.

4. Trier les découvertes et les effets

   Un scan n'est pas une décision. Pour chaque constat, consignez si le produit est concerné, non concerné, ou un faux positif, avec justification et historique. Ce journal est ce que lisent les évaluateurs, les paquets article 14 et les avis clients.

5. Notifier, puis publier les avis

   Lorsqu'un constat est activement exploité dans une version déjà livrée, horodatez la prise de connaissance et préparez le paquet 24 heures, 72 heures et 14 jours à copier dans l'ENISA SRP. Alloy ne soumet pas. Séparément, activez la page de sécurité publique de votre organisation et publiez des avis circonscrits aux versions réellement concernées.