Actuellement une des problématiques les plus complexes pour les développeurs logiciels est la nécessité de choisir de façon sécurisée des composants logiciels et des outils externes qu'ils utilisent comme dépendances pour construire leurs propres logiciels. Pour répondre à cette problématique OpenSSF, en collaboration avec google, à lancé SLSA en 2021.
SLSA (Supply chain Levels for Software Artifacts), est un framework de sécurité composé de règles de contrôle à mettre en place pour assurer l'intégrité des artefacts dans une chaîne de build, éviter toutes sortes de compromissions (comme illustrées dans la figure ci-dessous) et ainsi protéger l’infrastructure de déploiement.
Ce qui différencie SLSA des autres frameworks dans le domaine, c'est sa conception basée sur la création automatique de métadonnées vérifiables, plutôt que sur la fourniture d'une simple liste de bonnes pratiques.
)
SLSA se base sur un composant central et obligatoire dans son fonctionnement qui est la Provenance.
La Provenance est matérialisée par un fichier de Métadonnées qui décrit la façon dont un artefact a été produit, à savoir : une description détaillée sur le build et son écosystème. La Provenance représente un type de prédicat dans la software attestation comme l'illustre la figure suivante :
SLSA est conçue pour être adaptable à toutes les organisations et pour cela elle définit quatre niveaux de conformité incrémentale.
- Niveau 1 : ce niveau est atteignable par la documentation du processus de build automatique ainsi que la génération et publication de la Provenance.
- Niveau 2 : En plus des pré-requis du niveau 1, pour atteindre ce niveau il faut signer la provenance afin que le consommateur puisse vérifier l’authenticité de la Provenance.
- Niveau 3 : En plus des pré-requis du niveau 2, pour atteindre ce niveau il faut que le système de build soit très sécurisé afin de garantir que la signature de la Provenance soit non falsifiable.
- Niveau 4 : En plus des pré-requis du niveau 2, pour atteindre ce niveau il faut qu’il y ait au moins deux personnes pour la review des changements et que le processus de build soit reproductible et impénétrable.
Dans la pratique il y a deux outils utilisés :
- Sigstore : outil et standard pour signature et vérification des artefacts.
- Kyverno : outil de gestion et de vérification des politiques de sécurité conçu pour Kubernetes. Il supporte la vérification d'une provenance SLSA pour les images des conteneurs déployés dans des pods.
Enfin, si vous souhaitez tester et pratiquer, il existe actuellement deux systèmes de build, Github Actions et Google Cloud Build, qui vous permettent d'atteindre facilement le niveau 3 de SLSA. Mais comme vous pouvez le voir, il s'agit d'un jeune projet, il faut donc un certain temps pour que les différents systèmes de build l'adoptent, pour cela vous devez vous référer à la documentation du système de build pour connaître le niveau de support de SLSA.
Merci pour votre lecture. Cet article vous a plu, partager sur vos réseaux 😉
Article issu de notre participation aux Kubernetes Community Days France 2023
Abdelouahab EL OUAZZANY - Avril, 2023
VOUS AVEZ UN PROJET ?
Audit, migration, infogérance ?
Skale-5 vous écoute : contact@skale-5.com
Nous suivre :
