Vérifier ce qui entre dans la version livrée

Vérifier si la dépendance est nécessaire

Un agent peut proposer un package qui semble résoudre un problème. Cette suggestion est une proposition, pas une preuve que le package existe ou convient. Avant l’installation, vérifiez le registre, l’éditeur, le nom du package et la version exacts.

Pour un export CSV fictif, l’environnement d’exécution peut déjà fournir le comportement nécessaire. Un nouveau package peut rester un choix pertinent, mais il ajoute de la maintenance et des chemins d’exécution. Comparez l’effort d’implémentation aux responsabilités durables qu’ajoute la dépendance.

Examinez la licence et les environnements d’exécution pris en charge. Consultez l’activité de maintenance et les avis de sécurité pertinents. Un nom familier peut désigner un autre package dans un autre registre. Une installation réussie montre seulement que l’installation s’est terminée.

Examiner le comportement à l’installation et pendant le build

Les dépendances peuvent exécuter du code pendant l’installation ou le build. Limitez les identifiants et l’accès réseau dans ces environnements. N’exposez pas les secrets de production à un job qui traite une pull request non fiable.

Utilisez un fichier de verrouillage versionné lorsque l’écosystème le permet. Exigez que le build le respecte. Examinez ses modifications avec celles du code source, y compris les packages transitifs inattendus. Figer les versions améliore la reproductibilité, mais ne rend pas sûre une version vulnérable.

Le SSDF du NIST couvre la protection du logiciel et les pratiques de développement sur tout le cycle de vie. Adoptez cette perspective plus large pour concevoir l’environnement de build. Lire le référentiel.

Distinguer inventaire et provenance

Une nomenclature logicielle, ou SBOM, recense les composants d’un logiciel. Elle aide à identifier les versions touchées lorsqu’un composant devient préoccupant. Elle ne permet pas, à elle seule, d’établir que ces composants sont sûrs.

La provenance décrit la façon dont un artefact a été produit. SLSA définit un format de provenance pour les informations sur le build et ses entrées. La vérification doit relier ces informations à un producteur de confiance et à l’artefact que vous souhaitez utiliser. Un fichier nommé « provenance » ne suffit pas. Provenance SLSA.

Pour le service d’export, consignez une chaîne que vous pouvez examiner :

1. Le commit revu identifie le code source accepté.
2. Le build identifie ses entrées et son environnement d’exécution.
3. L’artefact possède une empreinte stable.
4. Les contrôles identifient l’artefact ou le code source examiné.
5. Le déploiement consigne l’artefact installé dans l’environnement cible.

Évitez de refaire un build différent après approbation sans procédure de vérification définie. Un tag mutable comme latest peut désigner une autre image plus tard.

Déterminer la portée d’un résultat

Une vulnérabilité détectée nécessite du contexte : version touchée, comportement accessible, exposition, correctif disponible et conséquence. Consignez les preuves qui justifient toute exception temporaire. Attribuez-lui un responsable, une expiration et un déclencheur de réexamen.

Ne désactivez pas tout un scanner parce qu’un résultat n’est pas applicable. Ne déclarez pas une analyse sans problème lorsqu’elle n’a pas pu se terminer. Un délai dépassé, un package non pris en charge ou un flux d’avis de sécurité indisponible signifie qu’il manque des preuves.

Enfin, prévoyez les mises à jour après la livraison. De nouveaux avis peuvent toucher l’artefact accepté hier. Le responsable du service a besoin d’un inventaire, d’une procédure de réponse et de la capacité à produire une version corrigée.

Poursuivez avec la gestion continue des vulnérabilités pour relier les analyses répétées à des corrections vérifiées en production.