Cette série d’articles a pour but d’identifier les meilleures pratiques à mettre en place pour sécuriser votre processus de livraison et vos pipelines CI/CD :
0. DevSecOp : Sécuriser les pipelines CI/CD, comprendre les fondements
1. La sécurité du système de gestion des versions
2. Sécuriser les pipelines d’intégration continue (CI)
3. Sécuriser les pipelines de déploiement continu (CD)
4. Gestion des secrets dans les pipelines CI/CD
5. Gestion sécurisée des artefacts dans les pipelines CI/CD
Par Gologic, en collaboration avec Alexandre Couëdelo.
Les « artifacts » sont les produits générés par vos pipelines d’intégration continue (CI) lors du processus d’assemblage (build). Ces artefacts sont en fait du code compilé (binaires) ou une image (container image) prête à être déployée sur un serveur.
Étant donné la récente augmentation des attaques exploitant les vulnérabilités de la chaîne de livraison logicielle (SolarWinds ou Codecov), sécuriser les artefacts est maintenant plus important que jamais. En s’appuyant sur les connaissances de nos discussions précédentes sur les « pipelines d’intégration continue (CI) sécurisés » et les « pipelines de livraison continue (CD) sécurisés », cet article se concentre sur l’aspect central de la gestion sécurisée des artefacts.
Le défi de sécurité auquel nous sommes confrontés avec l’artefact est la traçabilité de bout en bout. Pour chaque artefact, nous aimerions livrer un certificat qui vérifie la source et l’origine de chacun de ses composants et transformations (build process).
Dans cet article, vous découvrirez le SLSA (« Supply-chain Levels for Software Artifacts »), un nouveau framework de sécurité qui fournit des directives sur l’intégrité et la sécurité des artefacts logiciels. Ensuite, nous examinerons les points clés pour renforcer la sécurité de vos artefacts.
SLSA — Supply-chain Levels for Software Artifacts
Le framework SLSA identifie trois niveaux de maturité progressifs, chacun conçu pour fournir un niveau de sécurité de plus en plus élevé.
- Niveau SLSA 1 : Met l’accent sur la documentation et l’automatisation pour garantir que le processus d’assemblage (build) est cohérent et reproductible. À ce niveau, l’exigence produit une liste de provenances, telle qu’une « software bill of materials » (SBOM).
- Niveau SLSA 2 : Ce niveau introduit la notion d’artefacts signés. Cela garantit que l’artefact ne peut pas être modifié après le processus d’assemblage.
- Niveau SLSA 3 : Ce niveau introduit la notion de « plateforme d’assemblage sécurisée ». L’objectif d’une telle plateforme est de garantir qu’un artefact a été construit à partir de source officielle en utilisant le processus d’assemblage officiel. Les assemblages (build) sont entièrement reproductibles et traçables.
SLSA vise à devenir une norme mondiale à laquelle tous les processus d’assemblage devraient adhérer. Idéalement, chaque dépendance que vous utilisez devrait avoir un niveau SLSA certifié. Cette certification reflète le niveau de confiance que vous pouvez accorder à leur composant logiciel. De toute évidence, vous devriez viser à atteindre le niveau SLSA le plus élevé possible pour vos composants logiciels. On pourrait imaginer à l’avenir d’interdire l’accès aux logiciels tiers qui ne soient pas SLSA 3.
Renforcement de la sécurité des artefacts
Maintenant, examinons de plus près les actions nécessaires pour sécuriser vos artefacts. Nous examinerons quatre points clés qui contribuent chacun à atteindre les niveaux SLSA de 1 à 3.
- Dépendances tierces
La génération et publication de l’inventaire des dépendances sont les principales exigences pour atteindre le niveau 1 de SLSA. La liste des dépendances appelée « Software Bill of Material » (SBOM) offre une plus grande transparence qui permet une meilleure gestion des risques et aide à prévenir les vulnérabilités potentielles dues à des dépendances vulnérables. Lorsqu’une nouvelle vulnérabilité est découverte, vous pouvez rapidement identifier les logiciels impactés via leurs SBOM sans avoir à les scanner. - Estampillage des artefacts et validation des sceaux
Pour atteindre le niveau 2 de SLSA, la principale exigence est de mettre en œuvre des sceaux numériques (stamps). Ce sceau est une forme de signature générée à l’aide d’une clé privée accessible uniquement au composant de la plateforme d’assemblage responsable de la génération de « l’attestation de provenance ». En utilisant la clé publique correspondante, la cible de déploiement (serveur, Kubernetes, etc.) peut s’assurer que l’artefact n’a pas été altéré après le processus de construction. Cette signature numérique offre une validation solide et pratiquement inviolable, donnant aux utilisateurs confiance en l’intégrité de l’artefact et en les protégeant contre certaines attaques de la chaîne d’approvisionnement. - Code Source
Le premier prérequis pour atteindre le niveau 3 de SLSA est de pouvoir valider qu’un artefact « a été construit à partir de la source officielle » et « en utilisant le processus d’assemblage officiel ». Le code source, les scripts de pipeline et le manifeste du pipeline sont tous stockés dans le dépôt de code (GitHub, Gitlab, etc.). Le processus d’assemblage doit valider et ajouter ces références à l’attestation de provenance. De plus, vous pouvez exiger que tous les commits soient signés par les développeurs pour certifier leurs origines. - Plateforme de construction sécurisée
La deuxième exigence pour atteindre le niveau 3 de SLSA est la « certification » de votre plateforme d’assemblage (build platform). Le workflow d’assemblage doit être capable de prouver son identité. C’est là que les choses deviennent plus techniques ! Pour obtenir la certification de la plateforme d’assemblage, votre plateforme doit disposer d’un « security control plane » (tel que Sigstore) qui fournit des clés de signature éphémères générées pour un agent de build à l’aide d’une « workload identity ». Workload identity est un concept qui fait référence à l’attribution d’une identité unique et vérifiable aux applications ou serveurs par votre fournisseur d’infonuagique. Les métadonnées de la plateforme d’assemblage sont ensuite ajoutées au certificat de provenance et peuvent être validées via votre « security control plane ».
Conclusion
Nous avons vu l’importance de gérer de manière sécurisée les artefacts de notre chaîne d’approvisionnement en logiciels. Il existe plusieurs types d’attaques contre lesquels nous devons nous protéger, et pour ce faire, nous voulons pouvoir produire un certificat d’origine inviolable pour chaque artefact.
Nous avons introduit le cadre SLSA conçu pour fournir des directives pour assurer l’intégrité et la sécurité des artefacts logiciels, qui se compose de trois niveaux progressifs de sécurité. Nous avons exploré le processus de renforcement de la sécurité des artefacts basé sur les recommandations SLSA, qui comprennent le suivi des dépendances, la mise en œuvre de signatures numériques, la validation du code source et la certification de la plateforme de construction.
Dans notre prochain et dernier article, nous allons conclure cette série en orientant notre attention sur l’observabilité, la mise en place d’alertes automatisées et la priorisation des menaces critiques.
Ne manquez pas cette occasion d’approfondir vos connaissances en DevSecOps. Restez à jour, améliorez vos compétences et sécurisez vos pipelines CI/CD avec nos guides pratiques. Contactez-nous pour une consultation personnalisée.
Par Gologic, en collaboration avec Alexandre Couëdelo.
