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

Taiga Learning · Fiche d’exercice
https://taiga.training/fr/lessons/supply-chain/

Utilisez des informations fictives ou approuvées. Ne placez pas de secrets dans cette fiche.

## Objectifs d’apprentissage
- Distinguer un inventaire de dépendances d’une preuve de sécurité.
- Expliquer pourquoi un nom de package et une installation réussie ne suffisent pas.
- Remonter d’un artefact à son code source et à sa procédure de build.

## Exercice
Choisissez une modification fictive d’export CSV qui ajoute un package. Rédigez une note d’acceptation couvrant sa nécessité, son identité exacte, sa version, sa licence, sa maintenance, les vulnérabilités détectées et son comportement à l’installation. Dessinez le parcours du commit revu à l’artefact déployé.

## Votre réponse
- Scénario et périmètre :
- Hypothèses et questions ouvertes :
- Réponse ou décision proposée, avec justification :

## Vérifier votre réponse
| Affirmation ou critère | Preuve ou test | Résultat ou lacune | Responsable |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Action suivante
- Action, responsable et date :
- Quand réexaminerez-vous cette réponse ?

## Principe à retenir
Examinez les dépendances et le parcours du build. Même une modification sûre du code source peut produire un artefact de livraison non fiable.

## Sources
- [SLSA: provenance](https://slsa.dev/spec/v1.2/provenance)
- [NIST: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)

Cette fiche sert à apprendre. La remplir n’autorise pas à elle seule une modification en production.