In-toto
devsecopsDéfinition
In-toto est un framework open source de sécurisation de la supply chain logicielle qui fournit un mécanisme cryptographique pour vérifier l'intégrité d'un pipeline de développement logiciel de bout en bout. Développé à l'Université de New York (NYU) et maintenant sous l'égide de la CNCF (Cloud Native Computing Foundation), in-toto permet de définir et de vérifier que chaque étape du processus de build (de la récupération du code source au déploiement) a bien été exécutée par les acteurs autorisés et que les artefacts n'ont pas été modifiés entre les étapes. Le problème fondamental qu'in-toto adresse est la question de la confiance dans les étapes intermédiaires d'un pipeline : même si vous faites confiance au code source et au binaire final, comment vérifier que le processus de build entre les deux n'a pas été compromis ou que des étapes de sécurité requises (tests, scans SAST, revues) n'ont pas été sautées ? In-toto fonctionne via deux composants : les Layout files et les Link metadata. Un Layout file définit les étapes attendues du pipeline (fetch source code, run tests, compile, package), qui doit les exécuter (clé publique autorisée), et les vérifications de cohérence entre étapes (les outputs de l'étape N doivent être les inputs de l'étape N+1). Des Link files sont générés par chaque étape du pipeline, signés par l'acteur exécutant l'étape, documentant les inputs, les outputs, et le résultat de l'opération. L'intégration d'in-toto avec Sigstore (in-toto + Cosign) et SLSA est naturelle : in-toto fournit le format d'attestation (in-toto Statement), Sigstore fournit l'infrastructure de signature sans clé (keyless signing via OIDC), et SLSA définit les niveaux de maturité attendus. Le framework in-toto est utilisé par des projets majeurs comme le Python Package Index (PyPI) pour signer les releases.
Layout et Link : les deux piliers d'in-toto
Le Layout (signé par le propriétaire du projet) définit : les steps attendus (fetch, test, build, package), les functionaries autorisés par step (clés publiques), les expected materials/products de chaque step, et les inspections de vérification finale. Les Links (signés par les acteurs exécutant chaque step) documentent : les materials utilisés (hash des inputs), les products générés (hash des outputs), les commandes exécutées, et l'environnement. La vérification compare les Links aux attentes du Layout.
In-toto et Sigstore : signing sans clé
L'intégration in-toto + Sigstore (Rekor transparency log + Cosign keyless signing) permet la génération d'attestations in-toto signées dans les pipelines GitHub Actions sans gestion de clés privées : le pipeline s'authentifie via l'OIDC token GitHub, obtient un certificat de courte durée de Sigstore Fulcio, signe l'attestation, et publie dans le Rekor transparency log. Cette approche élimine le problème de gestion des clés tout en garantissant la non-répudiation cryptographique.