APP / APP-04
Sécurité des dépendances et de la chaîne d'approvisionnement logicielle — SCA/SBOM
Connaître les composants d'un produit logiciel et en maîtriser la provenance, les vulnérabilités et les mises à jour. Un SBOM décrit les composants ; il doit être utilisé et tenu à jour pour garantir la sécurité.
QUAND C'EST UTILE
Une réponse ciblée
à un besoin défini.
De nombreuses dépendances open source, la demande des clients concernant un cahier des charges logiciel, un incident chez le fournisseur ou l’impossibilité d’identifier les produits grâce à un composant vulnérable.
EN UN COUP D'ŒIL
Famille
Sécurité des applications
Engagement
Conseil et mise en œuvre
Référence
APP-04
PORTÉE ET RÉSULTATS
Ce que couvre la mission.
Portée
- Inventaire des composants
- dépendances directes/transitives
- SBOM
- analyse de la vulnérabilité
- provenance de l'objet d'art
- signatures lorsque c'est nécessaire
- mises à jour
- Traitement des exceptions
Livrables
- SBOM lié à la version
- Registre des dépendances
- Priorisation contextuelle
- Politique de provenance
- Processus de mise à jour
- preuves de vérification et limites de couverture
Preuve de réception
Le SBOM de la version cible est reproduisable ; les composants critiques sont identifiés ; un alertes d’essai est lié aux produits concernés ; les processus de mise à jour et d’exception fonctionnent.
LIVRAISON
Comment le travail est structuré.
Approche
Comprendre l’architecture ; sélectionner les risques et les exigences ; intégrer ou vérifier les contrôles ; tester ; les transmettre aux équipes et planifier des contrôles de régression.
Prérequis et responsabilités
Client : code, architecture, développeurs, environnement de test et accès au pipeline. Fournisseur : expertise et contrôles ; correction du code uniquement lorsqu'elle est incluse.
Facteurs de portée
Applications, langages, référentiels, dépendances, rôles, pipelines, volume et profondeur. Séparer les licences d'outils, le développement de remédiation et la maintenance.
Questions à clarifier
Les composants de chaque version peuvent-ils être reconstitués ? Qui surveille les vulnérabilités après la sortie de la version ? Les dépendances dans les images et les fichiers binaires sont-elles visibles ?
LIMITES IMPORTANTES
La présence d’un composant vulnérable ne prouve pas toujours qu’il peut être exploité, et l’absence d’un SBOM complet ne signifie pas nécessairement qu’il n’est pas utilisé. La licence logicielle nécessite une analyse distincte.
Les contrôles s'appliquent aux versions et au périmètre convenus. Aucun scanner, SBOM ou framework ne garantit à lui seul la sécurité du logiciel livré.
EN PRATIQUE
Situations illustratives.
Ces exemples décrivent des engagements possibles et des résultats cibles. Il ne s'agit pas de références clients ni de résultats obtenus.
Scénario 01
Un fournisseur reçoit un alertes concernant une bibliothèque commune. Projet : associer les SBOM aux versions livrées et évaluer l’exposition. Objectif : une liste de produits justifiée à corriger plutôt qu’une réaction uniforme dans tout le catalogue.
Scénario 02
Un client demande des SBOM aux fournisseurs. Projet : définir le format, la version et l’utilisation des résultats. Objectif : des informations exploitables ; les SBOM incomplets ou périmés sont signalés plutôt que traités comme des garanties.
Contexte technologique et de référence
Exemples : outils SCA/SBOM et de vérification de la provenance ; pratiques de l’SSDF du NIST, avec des formats et des intégrations définis lors de la phase de cadrage.
L'ensemble final des technologies est convenu lors du cadrage, sur la base de l'interopérabilité, des licences, des droits d'accès et des exigences opérationnelles.
SERVICES CONNECTÉS
Construisez l'étape suivante.
Ces services peuvent compléter la mission. Ils ne sont pas inclus automatiquement.
Commencer une conversation
Clarifiez la portée.
Nous clarifierons l'objectif, les dépendances et les responsabilités de ce service avant de proposer la livraison.