Le CERT-In (Indian Computer Emergency Response Team), qui dépend du MeitY (ministère de l'électronique et des technologies de l'information), n'a cessé d'étendre son rôle d'autorité nationale en matière de cybersécurité depuis sa désignation en vertu de la loi de 2008 modifiant la loi sur les technologies de l'information (Information Technology Amendment Act).
En 2024, le CERT-In a publié ses premières lignes directrices sur le SBOMSoftware Bill of Materials), définissant les éléments minimaux, les formats et les exigences de mise en œuvre.
Un an plus tard, en juillet 2025, la version 2.0 a considérablement élargi le champ d'application, en étendant la couverture à SBOM, QBOM, CBOM, AIBOM et HBOM, faisant ainsi de la sécurisation des chaînes d'approvisionnement en logiciels une stratégie de résilience nationale essentielle.
Pour les DSI et les RSSI, ces directives ont des conséquences opérationnelles, financières et réglementaires. Les organisations doivent être prêtes à démontrer des pratiques SBOM prêtes à être auditées, à aligner les fournisseurs et les partenaires sur les exigences de conformité et à adopter l'automatisation pour gérer les SBOM à grande échelle.
Cet article fournit une feuille de route étape par étape pour atteindre la conformité aux directives SBOM du CERT-In, couvrant le champ d'application, les normes techniques, la sélection des fournisseurs et les meilleures pratiques pour les entreprises indiennes et les organisations internationales ayant des opérations en Inde.
- Lignes directrices du CERT-In pour le SBOM : Champ d'application, applicabilité et exigences clés
- Comment le SBOM d'OPSWAT aide à répondre aux exigences du CERT-In
- Alignement des composants Software sur la conformité CERT-In SBOM
- Formats de SBOM et normes techniques acceptés dans le cadre du CERT-In
- Comment évaluer et sélectionner les fournisseurs de services de mise en conformité avec le SBOM ?
- Meilleures pratiques pour une mise en œuvre transparente du SBOM
- Automatiser, respecter et protéger : L'approche OPSWAT de la gestion du SBOM
- MetaDefender Software Supply Chain™
- FAQ
- Considérations sectorielles : Institutions financières, Supply Chain et infrastructures critiques
- Quelles sont les prochaines étapes ? Il est essentiel de se préparer aux lignes directrices du Cert-In SBOM
Lignes directrices du CERT-In pour le SBOM : Champ d'application, applicabilité et exigences clés
Qu'est-ce que le CERT-In et pourquoi a-t-il publié des lignes directrices pour le SBOM ?
Le CERT-In est l'agence nationale indienne de cybersécurité. Les lignes directrices du SBOM visent à renforcer la sécurité de la chaîne d'approvisionnement, à améliorer la visibilité des composants logiciels et à garantir des réponses plus rapides et normalisées aux vulnérabilités.
Qu'est-ce que le CERT-In et pourquoi a-t-il publié des lignes directrices pour le SBOM ?
La conformité s'applique aux gouvernements, au secteur public, aux services essentiels et aux exportateurs de logiciels, ainsi qu'aux développeurs, aux intégrateurs et aux revendeurs tout au long du cycle de vie des logiciels.
Éléments Core d'un SBOM selon les lignes directrices du CERT-In
Selon les lignes directrices, les SBOM doivent inclure des données telles que
- Nom du composant, version, fournisseur et licence
- Dépendances et origine
- Vulnérabilités et état des correctifs
- Dates de fin de vie, restrictions d'utilisation et criticité
- Identifiants uniques, sommes de contrôle et informations sur les auteurs
En exigeant ces éléments minimaux, le CERT-In s'assure que les SBOM sont exploitables, lisibles par une machine et prêts à être audités.
Comment le SBOM d'OPSWAT aide à répondre aux exigences du CERT-In
OPSWAT OM aide à l'automatisation et à la collecte des champs de données du CERT-In SBOM, afin de fournir une visibilité et une transparence dans les principaux domaines, depuis les détails des composants logiciels, la transparence et les risques, jusqu'aux licences et à l'utilisation.
Détails du composant Software
- Nom du composant : Nom du composant logiciel ou de la bibliothèque.
- Version du composant : Numéro de version ou identifiant du composant.
- Fournisseur du composant : Entité fournissant le composant (vendeur, tiers ou source ouverte).
- Origine du composant : Source du composant (propriétaire, open-source ou tierce partie).
- Identifiant unique : Code distinct permettant de suivre le composant à travers les versions et les propriétaires.
- Auteur des données du SBOM : Entité responsable de la création de l'entrée du SBOM.
- Horodatage : Date et heure d'enregistrement de l'entrée dans le SBOM.
Transparence des Software et risques
- Dépendances du composant : Autres composants ou bibliothèques sur lesquels ce composant s'appuie.
- Vulnérabilités : Problèmes de sécurité connus liés au composant, avec la gravité et les références CVE.
- État du correctif : Mise à jour actuelle ou disponibilité des correctifs pour les vulnérabilités.
- Sommes de contrôle ou hachages : Valeurs cryptographiques permettant de vérifier l'intégrité des fichiers.
- Propriété exécutable : Si le composant peut être exécuté.
- Propriété Archive : Indique si le composant est présenté sous forme de fichier d'archive.
- Date de publication : Date à laquelle le composant a été publié pour la première fois.
Licences et utilisation
- Licence du composant : Type de licence et conditions régissant l'utilisation du composant.
- Restrictions d'utilisation : Limitations légales ou réglementaires sur l'utilisation des composants.
Alignement des composants Software sur la conformité CERT-In SBOM
La mise en conformité avec le CERT-In est un processus progressif qui nécessite une coordination entre les équipes de développement, de sécurité, d'exploitation et de conformité. Chaque partie prenante joue un rôle dans la création, la maintenance et le partage des SBOM à différents moments du cycle de vie du logiciel.
Le tableau ci-dessous, qui contient du contenu et des exemples tirés des lignes directrices techniques du CERT-In, illustre la manière dont les responsabilités du SBOM s'alignent sur les composants logiciels courants :
| Software | Exemple | Niveau du SBOM | SBOM Auteur | Pourquoi ? |
|---|---|---|---|---|
| Application principale | Une application d'analyse de données | SBOM au niveau de l'application | Créé par l'équipe de développement du produit | SBOM complet livré avec l'application au client ou au régulateur |
| Composant Software clé [base de données, cadre] | PostgreSQL | SBOM de niveau supérieur | Développé en interne si le fournisseur n'a pas fourni de SBOM | Assurer la traçabilité des composants critiques |
| Plate-forme/logiciel intermédiaire [par exemple, serveur web, environnement d'exécution]. | Server Apache Tomcat | Livraison SBOM | Fourni par la plateforme/le fournisseur | Partagé lors de la passation de marché ; intègre les composants fournis par le fournisseur |
| Bibliothèques tierces/SDK | Postfix & Twilio SDK | SBOM transitif | Créé par le fournisseur en amont ou en interne s'il n'est pas disponible | Couvre les dépendances indirectes et les services externes |
Une fois les rôles et les responsabilités définis, les organisations peuvent passer aux étapes pratiques de la mise en conformité. Une feuille de route par étapes permet de développer la maturité des personnes, des processus et de la technologie.
1. Procéder à une évaluation de l'état de préparation et à une analyse des lacunes
Identifier les pratiques actuelles pour l'inventaire des logiciels, le suivi des vulnérabilités et les SBOM fournis par les fournisseurs. Les comparer aux champs de données et aux formats requis par le CERT-In.
2. Mettre en place une politique interne du SBOM et une structure de gouvernance
Définir des rôles clairs pour les développeurs, les opérations informatiques, les achats, la sécurité et les équipes chargées de la conformité. La gouvernance garantit que les SBOM sont créés, maintenus et partagés de manière cohérente dans l'ensemble de l'entreprise.
3. Sélectionner et mettre en œuvre des outils de génération de SBOM
L'automatisation est cruciale. Les outils doivent :
- Générer des SBOM pour chaque nouvelle version, correctif ou mise à jour
- Intégrer les pipelines DevOps, les référentiels de sources et les registres de conteneurs.
- Sortie aux formats CycloneDX et SPDX pour l'alignement réglementaire
4. Intégrer les flux de travail du SBOM dans le SDLC et les achats
Intégrer la génération de SBOM à chaque étape du cycle de développement durable :
- Conception SBOM : composants planifiés
- SBOM source : dépendances de développement
- Construire le SBOM : pendant la compilation
- SBOM analysé : inspection après construction
- SBOM déployé : environnement installé
- SBOM Runtime : surveillance des composants actifs
Les contrats d'approvisionnement devraient imposer la fourniture de SBOM par tous les fournisseurs.
5. Maintenir la conformité et la préparation à l'audit
Mettre en place des mises à jour continues du SBOM, intégrer les avis de vulnérabilité tels que VEX (Vulnerability Exploitability eXchange) et CSAF, et garantir un stockage et un partage sécurisés grâce au cryptage, au protocole HTTPS et aux signatures numériques.
Vous voulez savoir comment tirer parti du SBOM pour votre stratégie de sécurité ?
Formats de SBOM et normes techniques acceptés dans le cadre du CERT-In
CycloneDX et SPDX : les normes acceptées
Le CERT-In reconnaît CycloneDX et SPDX comme les principaux formats lisibles par machine pour l'automatisation des SBOM.
- CycloneDX : léger, centré sur la sécurité, optimisé pour la gestion des vulnérabilités
- SPDX : axé sur les licences, largement adopté pour la documentation de conformité
Comment évaluer et sélectionner les fournisseurs ou les solutions de conformité CERT-In SBOM ?
Le choix du bon fournisseur ou de la bonne solution est essentiel pour la conformité et l'efficacité opérationnelle.
Critères clés pour l'évaluation des fournisseurs de conformité CERT-In SBOM
- Support pour SPDX et CycloneDX
- Intégration avec les pipelines DevOps et les flux de travail CI/CD
- Capacité à générer plusieurs niveaux de SBOM (conception, construction, déploiement, exécution)
- Des rapports prêts à être vérifiés et des mécanismes de partage sécurisés
Questions à poser aux fournisseurs potentiels sur l'alignement du CERT-In
La sélection des bons partenaires est tout aussi essentielle que la mise en place de processus SBOM internes. Les DSI et les responsables des achats devraient inclure l'alignement du CERT-In dans leurs listes de contrôle des appels d'offres et des vérifications préalables. Les questions clés à poser sont les suivantes
- Fournissez-vous des SBOM dans des formats approuvés par le CERT-In (SPDX, CycloneDX) ?
- Quelle est la fréquence de mise à jour de vos SBOM - au moment de la publication seulement, ou en continu ?
- Quelle automatisation proposez-vous pour la génération, la validation et le partage sécurisé des SBOM ?
- Comment assurez-vous la distribution sécurisée du SBOM (par exemple, cryptage, RBAC, signatures numériques) ?
- Votre solution s'intègre-t-elle aux pipelines DevOps, aux bases de données de vulnérabilités et aux avis du CERT-In ?
- Comment soutenir les audits de conformité et les rapports réglementaires en cours ?
Poser ces questions dès le départ permet de s'assurer que les fournisseurs ne sont pas seulement conformes sur le papier, mais qu'ils sont capables de maintenir des pratiques SBOM qui s'alignent sur les lignes directrices en constante évolution du CERT-In.
Liste de contrôle pour la sélection et l'intégration des fournisseurs
- Prise en charge des champs de données et des formats requis par le CERT-In
- Automatise la génération, le suivi et les mises à jour
- Contrôles d'accès basés sur les rôles et partage sécurisé
- Adoption démontrée dans les secteurs réglementés
Meilleures pratiques pour une mise en œuvre transparente du SBOM
Stratégies éprouvées pour les grandes entreprises
- Commencer par des flux de travail fondamentaux et développer la maturité au fil du temps
- Rendre obligatoire la mise en œuvre du SBOM dans tous les contrats d'achat
- Adopter une approche "shift-left" en intégrant la génération de SBOM dès le début du SDLC
- Former le personnel à la sensibilisation au SBOM et aux exigences réglementaires
Erreurs courantes et comment les éviter
Même les initiatives SBOM bien intentionnées peuvent échouer si les organisations les abordent de manière superficielle. Le CERT-In insiste sur le fait que les SBOM doivent être précis, complets et continuellement mis à jour. Voici quelques-uns des pièges les plus courants et comment les éviter :
| Erreur courante | Explication | Comment l'éviter |
|---|---|---|
| Traiter le SBOM comme un rapport statique | De nombreuses organisations génèrent un SBOM au moment de la publication et ne le mettent jamais à jour. Elles ne voient donc pas les vulnérabilités introduites par les correctifs, les mises à jour ou les nouvelles dépendances. | Traitez le SBOM comme un inventaire vivant. Automatisez les mises à jour via votre pipeline CI/CD afin que chaque nouvelle version actualise les données du SBOM. |
| Ne pas inclure les dépendances transitives | Le fait de ne pas tenir compte des composants indirects, tels que les bibliothèques open-source intégrées par d'autres dépendances, crée des angles morts dangereux que les attaquants exploitent. | Utilisez des outils automatisés de génération de SBOM qui cartographient de manière récursive toutes les dépendances directes et transitives, garantissant ainsi une couverture complète de votre chaîne d'approvisionnement en logiciels. |
| S'appuyer sur la création manuelle sans automatisation | La compilation manuelle des SBOM prend du temps, est sujette aux erreurs et n'est pas viable à l'échelle de l'entreprise. Elle augmente également le risque d'incohérence des formats. | Intégrer l'automatisation et la normalisation. Adopter des outils qui génèrent des SBOM dans des formats approuvés par le CERT-In, tels que SPDX et CycloneDX, et imposer la validation avant la diffusion. |
En évitant ces erreurs et en intégrant les pratiques SBOM dans les flux de développement quotidiens, les organisations peuvent faire de la conformité un avantage stratégique, en réduisant les risques tout en répondant aux exigences du CERT-In.
Préparation aux audits
Maintenir des référentiels SBOM complets, documenter les pratiques de gouvernance et s'aligner sur les modèles d'audit CERT-In.
Se prémunir contre les changements réglementaires
La feuille de route du CERT-In laisse déjà entrevoir des exigences plus larges en matière de nomenclature (matériel, IA et cloud). Les entreprises qui adoptent des outils évolutifs et flexibles seront les mieux placées pour s'adapter.
Automatiser, respecter et protéger : L'approche OPSWAT de la gestion du SBOM
OPSWAT SBOM
OPSWAT SBOM permet aux développeurs de disposer d'un inventaire précis des composants logiciels dans le code source et les conteneurs. Gardez une longueur d'avance sur les attaquants, découvrez les menaces et détectez les vulnérabilités sans affecter la vitesse de développement.
SBOM pour Software Packages & Artifacts (paquetages et artefacts Software
Permet aux équipes de développement de logiciels d'identifier, de hiérarchiser et de traiter les vulnérabilités de sécurité et les problèmes de licence des dépendances open-source.
SBOM pour Software Packages & Artifacts (paquetages et artefacts Software
Permet aux équipes de développement de logiciels d'identifier, de hiérarchiser et de traiter les vulnérabilités de sécurité et les problèmes de licence des dépendances open-source.
SBOM pour les images de Container
Analyser les images de conteneurs et générer des SBOM pour le nom du paquet, les informations sur la version et les vulnérabilités potentielles.
MetaDefender Software Supply Chain™
Aller au-delà de la conformité SBOM et s'attaquer aux attaques avancées et évolutives de la chaîne d'approvisionnement en logiciels.
OPSWAT MetaDefender Software Supply Chain offre une visibilité accrue et une défense solide contre les risques liés à la chaîne d'approvisionnement. Grâce à nos technologies de détection et de prévention des menaces, votre cycle de développement logiciel (SDLC) est protégé contre les malwares et les vulnérabilités, renforçant ainsi la sécurité des applications et le respect de la conformité.
Détecter les logiciels malveillants dans le code
La combinaison de plus de 30 moteurs antivirus augmente les taux de détection et empêche efficacement les logiciels malveillants d'infecter les postes de travail, les conteneurs ou le code source.
Identifier les secrets codés
Proactive DLPTM identifie les informations d'identification telles que les mots de passe, les secrets, les jetons, les clés API ou d'autres informations sensibles laissées dans le code source.
Secure conteneurs contre les attaques de Supply Chain
Évaluer les logiciels malveillants, les vulnérabilités et les autres risques potentiels présents sous chaque couche d'une image de conteneur.
Les intégrations en toute simplicité
Que votre équipe utilise des référentiels de code source, des registres de conteneurs, des services binaires ou une combinaison d'outils, MetaDefender Software Supply Chain fournit des intégrations natives avec les plateformes les plus courantes pour sécuriser l'ensemble de votre SDLC.
FAQ
Quelles sont les sanctions applicables en cas de non-respect des lignes directrices du CERT-In SBOM ?
Les audits réglementaires et les restrictions potentielles sur les contrats avec le gouvernement et les services essentiels. Le non-respect des directives du CERT-In SBOM peut rendre les organisations vulnérables aux violations de données, ce qui peut entraîner de lourdes amendes.
À quelle fréquence les SBOM doivent-ils être mis à jour ?
À chaque nouvelle version, mise à jour, correctif ou changement de fournisseur.
Est-il possible d'inclure des composants à code source ouvert et des composants tiers ?
Oui. Une visibilité complète de toutes les dépendances - directes et transitives - est obligatoire.
Les petites entreprises sont-elles exemptées ?
Les entreprises en phase de démarrage qui n'appartiennent pas à des secteurs réglementés peuvent bénéficier d'une aide limitée, mais leur adoption est fortement encouragée.
Comment le CERT-In s'aligne-t-il sur les normes mondiales ?
L'approche de l'Inde reflète les cadres internationaux tels que le NIST et la loi sur la cyber-résilience de l'UE, garantissant ainsi une compatibilité transfrontalière.
Comment traiter les divulgations de vulnérabilités ?
Par le biais d'avis VEX et CSAF, intégrés aux alertes CERT-In et aux systèmes SBOM internes.
Quel est le rôle de l'automatisation ?
L'automatisation permet une conformité continue, réduit les erreurs humaines et garantit l'évolutivité dans les environnements informatiques hybrides.
Considérations sectorielles : Institutions financières, Supply Chain et infrastructures critiques
Secteur financier
Les banques et les NBFC doivent aligner les pratiques du SBOM sur les mandats de la RBI en matière de cybersécurité, avec des exigences d'audit plus strictes pour le traitement des données sensibles.
Supply Chain
Les fournisseurs doivent fournir des SBOM dans le cadre des contrats. Les organisations doivent tenir des inventaires internes et externes des SBOM à des fins de transparence et de gestion des risques.
Infrastructures critiques
Des secteurs comme les télécommunications, la défense et l'énergie sont confrontés à des chevauchements réglementaires. Les pratiques du SBOM doivent s'intégrer dans des cadres plus larges pour la résilience des systèmes et la sécurité nationale.
Quelles sont les prochaines étapes ? Il est essentiel de se préparer aux lignes directrices du Cert-In SBOM
Les lignes directrices du CERT-In en matière de SBOM marquent un tournant pour les entreprises indiennes. Ce qui n'était au départ qu'une simple question de SBOM s'est transformé en un cadre complet pour la visibilité de la chaîne d'approvisionnement en logiciels et la gestion des risques.
La technologie SBOM d'OPSWAT va au-delà de la conformité, en intégrant la visibilité de la chaîne d'approvisionnement à travers le SDLC et en intégrant la sécurité multicouche avec les référentiels de code, les registres de conteneurs et les pipelines DevOps.
Découvrez comment OPSWAT peut aider votre entreprise à simplifier la conformité CERT-In SBOM et à sécuriser votre chaîne d'approvisionnement en logiciels.
