״Les éditeurs de logiciels doivent être tenus responsables lorsqu’ils ne respectent pas leur devoir de diligence envers les consommateurs, les entreprises ou les fournisseurs d’infrastructures critiques – (la Maison Blanche).
Aujourd'hui, tout fournisseur de logiciels est censé assumer une plus grande responsabilité pour garantir l'intégrité et la sécurité des logiciels par le biais d'accords contractuels, de versions et de mises à jour de logiciels, de notifications et d'atténuation des vulnérabilités. Récemment, l'ESF (Enduring Security Framework), un groupe de travail intersectoriel, a publié des lignes directrices qui incluent les meilleures pratiques et normes recommandées pour aider les clients à mettre en œuvre des mesures de sécurité au sein de la chaîne d'approvisionnement logicielle. Dans cet article, j'approfondirai la recommandation pratique d'utiliser la notation des risques basée sur le SBOM comme mécanisme efficace de triage et de priorisation.
Les méthodes courantes de compromission des chaînes d'approvisionnement logicielles persistent, notamment l'exploitation de défauts de conception logicielle, l'incorporation de composants tiers vulnérables dans un produit logiciel, l'infiltration du réseau du fournisseur avec un code malveillant avant la livraison finale du produit logiciel et l'injection de logiciels malveillants dans le logiciel déployé. dans l’environnement client.
Une nomenclature logicielle (SBOM) est devenu un élément crucial de la sécurité des logiciels et de la gestion des risques de la chaîne d'approvisionnement logicielle. Un SBOM sert d'inventaire imbriqué, fournissant une liste d'ingrédients qui constituent les composants logiciels.
L'opérationnalisation des SBOM à grande échelle nécessite l'automatisation et la standardisation des outils dans les déploiements de systèmes, le développement de produits et l'échange de données entre les fournisseurs de logiciels et les consommateurs.
Il existe quelques informations importantes lisibles par machine Formats standards SBOM soutenu par l’industrie. CycloneDX et SPDX définissent la manière dont les SBOM sont créés, analysés et partagés. VEX est une forme complémentaire d'avis de sécurité qui indique si un ou plusieurs produits sont affectés par une ou plusieurs vulnérabilités connues. Ainsi, il offre l'avantage de montrer qu'un produit n'est pas concerné par une vulnérabilité spécifique, même si cette vulnérabilité existe dans son SBOM.
La corrélation du contenu SBOM entre les produits logiciels déployés au sein de l'entreprise peut fournir des informations précieuses aux équipes de sécurité des applications, de réponse aux incidents et d'investigation, de gestion des risques et d'approvisionnement. Les organisations sont censées générer et gérer une grande quantité de données SBOM pour les produits internes ainsi que consommer des données externes qui doivent être gérées de manière efficace. Il est donc nécessaire de soutenir processus automatisation du SBOMgestion des risques pilotée À l'échelle.
Utilisation des SBOM et de la notation des risques
La notation des risques peut servir à générer un aperçu condensé dérivé du contenu SBOM, permettant des comparaisons rapides avec des sources de données externes et facilitant une prise de décision rapide basée sur les SBOM reçus et la priorisation.
- Le SBOM améliore la transparence, améliorant ainsi la gestion des actifs logiciels, la gestion des correctifs, l'identification des lacunes techniques en matière de dette et la gestion des vulnérabilités pour les organisations clientes. Il offre également le potentiel d’extraire la provenance des composants pour valider l’intégrité et la confiance.
- L'analyse de l'alignement du contenu SBOM sur les produits logiciels mis en œuvre dans l'entreprise fournit des informations précieuses pour les équipes de réponse aux incidents, la gestion des risques et la validation des processus d'approvisionnement.
Transformer le SBOM en informations sur les risques à grande échelle – Justification de la notation des risques
Un défi clé pour chaque professionnel AppSec et RSSI est de gérer la fatigue des alertes dans l’ensemble de vos produits et services. Y compris l'évaluation des risques externes provenant de composants logiciels tiers.
Les principaux obstacles à la mise en œuvre sont un support contractuel ou basé sur une licence obsolète qui peut avoir un impact sur la disponibilité des correctifs et des mises à jour de produits en aval, ainsi que la croissance exponentielle de la complexité des dépendances au sein des produits logiciels, qu'ils soient open source ou fermés.
A score de risque est une mesure utilisée pour prédire les aspects du logiciel et des risques actuels et futurs du logiciel et de ses composants, qui peut efficacement prendre en charge la priorisation à grande échelle.
Score de risque = probabilité x impact
La notation des risques permet aux organisations de comprendre les risques liés à leur chaîne d'approvisionnement logicielle en fonction de facteurs de risque définis et d'anticiper le risque futur potentiel d'un produit logiciel donné dans l'entreprise.
Un score de risque efficace peut être sur une échelle de 1 à 10 (telle que CVSS et Scorecard), afin que nous puissions aligner chaque composant de risque sur l'échelle de 1 à 10 pour faciliter la référence.
Un score de risque agrégé: Dans de nombreux systèmes et systèmes de systèmes complexes, il peut y avoir plusieurs SBOM dans le cadre de la solution collective et, par conséquent, un ensemble de scores de risque.
Composantes de notation des risques :
1.Vulnérabilités : Cartographie des vulnérabilités connues à l'aide de l'énumération CVE et Score CVSS à partir des flux disponibles tels que les avis NVD, OSV et Github.
2. Contexte des fournisseurs : VEX et contexte consultatif des fournisseurs qui peuvent modifier la décision de notation des vulnérabilités dans le contexte de l'utilisation. Lier les SBOM aux vulnérabilités active les indicateurs de risque, tandis que les documents VEX permettent à un consommateur de hiérarchiser les vulnérabilités.
3. EPSS 3.0 : Métrique d'exploitabilité de FIRST, qui prédit la probabilité (entre 0 et 1.0) d'exploitation dans les 30 prochains jours. C'est un moyen efficace couche de vraisemblance supplémentaire au score CVSS qui peut aider à prioriser les CVE les plus importants à traiter en premier.
4. KEV: La CISA a également créé un flux de renseignements sur les menaces accessible au public, connu aujourd'hui sous le nom de Catalogue CISA KEV (vulnérabilités exploitables connues). Ce catalogue contient environ 5 % de tous les CVE identifiés qui sont confirmés par la CISA comme ayant été ou activement exploités. Il s’agit donc d’un bon point de départ pour prioriser les vulnérabilités à fort impact à traiter. De plus, cela fait partie de la liste de contrôle que vous valideriez avant l’approbation finale de la nouvelle version.
5. Renseignements sur les menaces – Ajouter supplémentaire sources de menaces et de vulnérabilités flux paquets malveillants connus (Exemples : flux privés de Snyk, Sonatype, Graynoise, etc.)
6. Réputation OSS : la La carte de score open SSF évalue de manière indépendante les mesures de performance affectant différentes parties de la chaîne d'approvisionnement logicielle, notamment le code source, la construction, les dépendances, les tests et la réputation de maintenance des projets open source (note de 1 à 10).
7. Performances dans le temps: Les vulnérabilités critiques MTTR (Mean Time To Repair) d’une version de produit/package pourraient donner une mesure pertinente de la performance en matière de risque de sécurité.
8. Impact et le contexte. Dans cet aspect, la priorisation basée sur le contexte commercial du produit logiciel aiderait à prioriser et à trier la forêt de vulnérabilités.
Quelques exemples sont
- Criticité du module/produit : Est-ce critique pour la mission (sensibilité ou criticité)
- Dans combien de produits ai-je cette vulnérabilité spécifique ?
- Exposition à l’externalité d’un service/composant
9. Exposition à la conformité – Licences : Les licences de logiciels propriétaires et open source sont importantes pour valider la conformité à la politique juridique de l'organisation.
Concept de couches de notation des risques – Ajout de mesures de risque aux SBOM :
- Accueille avec énumération CVE et score CVSS basé sur les données SBOM.
- Consommer et ajouter du contexte VEX pour redéfinir les priorités
- Évaluer les CVE avec un score EPSS élevé (c'est-à-dire 0.6-1.0)
- Donner la priorité à la liste KEV – pour adresse en premier.
- Évaluez par le score de réputation OpenSSF (1-10) – identifiez les dépendances à risque.
- Analysez exposition au réseau externe (en utilisant le vecteur CVSS)
- Évaluer le risque accumulé par le quantité de produit par vulnérabilité.
- Évaluer par le étiquette de la criticité du SBOM de conteneurs spécifiques pour l'entreprise.
- Identifier violation de la conformité risques liés à l’utilisation de l’analyse des dépendances SBOM conformément à la politique de licence de l’entreprise.
- Partager et gérer les données as attestations dans une plateforme collaborative avec des workflows vers d'autres systèmes tels que Jira et autres via API et lisibles par machine.
Tirer parti des SBOM avec la notation des risques pour des cas d'utilisation pratiques :
- Triage continu des vulnérabilités des produits en utilisant des mesures de risque pour prioriser un plan de travail de mise à jour des correctifs pour tous les produits.
- Comparez les produits côte à côte en fonction des mesures de risque.
- Comparez et approuvez les mises à jour des nouvelles versions avant le déploiement/la publication.
- Suivez l’écart de dette technique à l’aide des seuils de notation des risques pour les versions de produits.
- Créez un rapport rapide des 50 principaux risques liés à mes produits les plus critiques.
- Analyse d'impact pour accélérer une réponse aux incidents – en cas de découverte d'une vulnérabilité activement exploitée dans la nature. Dans ce cas, le temps compte pour identifier rapidement comment je suis impacté et quel serait le rayon d'explosion de la carte thermique de cette exposition.
Comment utiliser la plateforme Scribe Hub pour une gestion efficace des risques :
- Plateforme de gestion centralisée du SBOM – Créer, gérer et partager des SBOM ainsi que leurs aspects de sécurité : vulnérabilités, avis VEX, licences, réputation, exploitabilité, tableaux de bord, etc.
- Créer et déployer des logiciels sécurisés – Détectez les falsifications en signant et en vérifiant en permanence le code source, les images de conteneurs et les artefacts à chaque étape de vos pipelines CI/CD.
- Automatisez et simplifiez la sécurité SDLC – Contrôler le risque dans votre usine logicielle et garantissez la fiabilité du code en traduisant la sécurité et la logique métier en politiques automatisées, appliquées par des garde-fous
- Activez la transparence. Améliorer la vitesse de livraison – Donnez aux équipes de sécurité les capacités nécessaires pour exercer leurs responsabilités, en rationalisant le contrôle de sécurité sans entraver les livrables de l’équipe de développement.
- Appliquer les politiques. Démontrer la conformité - Surveillez et appliquez les politiques et la gouvernance SDLC pour améliorer la posture en matière de risques logiciels et démontrer la conformité nécessaire pour votre entreprise.
Deux exemples de Centre de scribe les capacités d’analyse des risques sont présentées :
Vulnérabilités cartographiées par SBOM, notation des risques par données CVSS, VEX, EPSS et KEV.
Série chronologique des performances de la version SBOM au fil du temps indiquant le MTTR le temps moyen nécessaire pour réparer les vulnérabilités critiques identifiées.
Résumé
La notation des risques basée sur le SBOM permet aux organisations d'évaluer les risques liés à la chaîne d'approvisionnement en évaluant les facteurs de risque prédéfinis et en prévoyant les risques futurs potentiels associés à un produit logiciel spécifique au sein de l'entreprise. Le score de risque sert de mesure quantitative pour anticiper les risques actuels et potentiels liés au logiciel et à ses composants.
Cette mesure de notation est dérivée d'indicateurs provenant du SBOM, de VEX, entre autres flux, et s'aligne sur le contenu prenant en charge la gestion des risques de la chaîne d'approvisionnement (SCRM). Lors de l'application ou de l'évaluation d'un score de risque, des facteurs tels que le contexte d'utilisation du logiciel, la manière dont il est accédé ou isolé, ainsi que les processus et systèmes qu'il prend en charge doivent être pris en compte.
Scribe Hub sert de plate-forme collaborative conçue pour l'extraction, la gestion, la collecte d'attestations et l'analyse des risques des SBOM à grande échelle. Cette plate-forme traite efficacement plusieurs flux de données externes pour gérer les subtilités des systèmes et produits logiciels complexes.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
