Conserver les dépendances
lisibles.
Un guide pratique de continuité pour identifier les composants tiers importants et convenir des réponses lorsque l'un d'eux change, se dégrade ou devient indisponible. Ce n'est pas un scan de vulnérabilités ni une assurance fournisseur.
UTILISEZ-LE POUR: À utiliser pour rendre la surface des dépendances, la propriété, les décisions de version et les hypothèses de repli vérifiables avant une release (fallback).
Effectuez l'étape suivante connue.
- Listez les dépendances des parcours clients : paquets applicatifs, outils de build, API externes, fournisseurs de livraison et services opérationnels. Attribuez un propriétaire responsable à chaque dépendance importante.
- Consignez la version ou la configuration du service dans les éléments de preuve de la release. Utilisez le lockfile approuvé par l’équipe, les contrôles de provenance ou de revue fournisseur plutôt que des substitutions non révisées.
- Pour chaque dépendance, documentez l’effet côté client si elle est retardée ou indisponible et l’option approuvée de dégradation progressive ou d’escalade, si elle existe.
- Examinez les avis des fournisseurs et le comportement observé via les canaux approuvés ; effectuez les changements par la voie normale de release révisée plutôt que de modifier une dépendance durant un incident sans autorisation.
Vérifiez que chaque dépendance matérielle a un propriétaire, une source de vérité et une référence de release actuelle.
Comparez l'ensemble des dépendances planifiées pour la release avec le lockfile ou l'enregistrement plateforme révisé en utilisant l'outillage approuvé par l'équipe.
Simulez, par exercice tabletop, l'interruption d'une dépendance unique : identifiez qui décide, quel comportement client est acceptable et quand escalader.
Notes de source, pas une certitude empruntée.
Base de planification : directives OWASP pour la chaîne d'approvisionnement logicielle
- OWASP — Software Supply Chain Security Cheat Sheet ↗OWASP recommande l'inventaire des dépendances, la génération automatisée de SBOM lorsque cela est approprié, la surveillance, le verrouillage des versions, l'inventaire des outils de build et des contrôles de provenance.
Rédaction : Brouillon éditorial d'activation SIU ; directives opérationnelles liées à la source. Révisé par : L'ingénierie, la plateforme, la sécurité et les responsables fournisseurs examinent la liste des dépendances matérielles. Revalider : Revalider trimestriellement et avant toute modification d’une dépendance, d’un build, d’un fournisseur ou du mode de repli.