Introduction : Pourquoi la sécurité de la chaîne d’approvisionnement logicielle est essentielle En décembre 2020, le monde a découvert que SolarWinds — une plateforme de gestion informatique largement reconnue — avait été compromise. Des attaquants ont injecté du code malveillant dans le processus de build du logiciel Orion, distribuant une mise à jour corrompue à … Lire la suite
Présentation Si vous construisez le même Dockerfile deux fois et obtenez des images différentes, vous ne pouvez pas vérifier l’intégrité du build. Un build non reproductible signifie que vous n’avez aucun moyen de confirmer que l’artefact en production a bien été produit à partir du code source que vous avez audité. Les attaquants peuvent exploiter … Lire la suite
Présentation Tekton est un puissant framework open source natif de Kubernetes permettant de créer des systèmes d’intégration continue et de livraison continue (CI/CD). Il s’exécute sous forme de Custom Resource Definitions (CRDs) sur n’importe quel cluster Kubernetes, vous permettant de définir des pipelines sous forme de YAML déclaratif, portables d’un environnement à l’autre. Tekton Chains … Lire la suite
Pourquoi les SBOMs sont importants : l’impératif réglementaire et sécuritaire Un Software Bill of Materials (SBOM) est un inventaire formel et lisible par machine de chaque composant, bibliothèque et dépendance qui constitue un logiciel. Considérez-le comme l’étiquette nutritionnelle de votre application — sauf qu’au lieu des calories et du sodium, vous répertoriez les paquets, versions, … Lire la suite
Pourquoi la signature d’images container est essentielle Chaque fois que vous récupérez une image container et la déployez en production, vous accordez une confiance implicite à cet artefact. Mais comment vérifiez-vous que l’image n’a pas été altérée ? Comment confirmez-vous qu’elle a réellement été construite par votre pipeline CI/CD et non injectée par un attaquant … Lire la suite
Introduction La signature de code est depuis longtemps un pilier de la sécurité logicielle. Lorsque vous vérifiez une signature, vous savez qui a signé un artefact. Mais savoir qui a signé quelque chose ne vous dit pas comment il a été construit, où il a été construit, ni quel code source a été utilisé. Un … Lire la suite
Présentation La provenance SLSA (Supply-chain Levels for Software Artifacts) est un enregistrement vérifiable qui décrit comment un artefact a été construit : le dépôt source, la plateforme de build, le point d’entrée et les matériaux d’entrée. Lorsqu’elle est associée à une image container, la provenance permet aux consommateurs de répondre à une question critique avant … Lire la suite
Présentation Chaque image container produite par votre pipeline CI/CD devrait être signée cryptographiquement avant d’atteindre un quelconque environnement. Les images non signées constituent un angle mort — vous n’avez aucune preuve qu’elles proviennent de votre pipeline, aucune garantie qu’elles n’ont pas été altérées en transit, et aucun mécanisme de politique pour bloquer les déploiements non … Lire la suite
Introduction : Qu’est-ce que SLSA et pourquoi devriez-vous vous en soucier ? Supply-chain Levels for Software Artifacts — SLSA (prononcé « salsa ») — est un framework de sécurité créé par Google et désormais maintenu par l’Open Source Security Foundation (OpenSSF). Son objectif est d’une simplicité trompeuse : rendre plus difficile pour les attaquants de … Lire la suite
Ce qu’il faut concrètement modifier dans les environnements CI/CD réels 🔐 Renforcement des accès et de l’identité En cas de non-conformité des contrôles SSO/MFA : Imposer le SSO SAML pour l’organisation GitHub/GitLab. Désactiver l’authentification par mot de passe pour les administrateurs. Imposer la MFA matérielle pour les rôles privilégiés. Supprimer les jetons d’accès personnels sans … Lire la suite
