Sécuriser la chaine de développement logiciel avec SLSA dans Google Cloud

Transcript

1. Sécurisez la chaîne de développement logiciel avec SLSA Mohamed Abdennebi Cloud Security Lead AppMod Days 2023
2. Comment vous assurer que le code déployé en prod est bien le vôtre ?
3. Devs Test Cluster GKE Prod Cluster GKE Cloud Deploy déploiement depuis le laptop Image de prod code malveillante Risques sur le déploiement Step 1 : Test Step 2 : Scan Step 3 : QA Step 1 : Build Cloud Build Git Source Repository
4. Comment s'assurer de l'authenticité et la de traçabilité de vos artefacts ?
5. 1 Authenticité : Binary Authorization
6. Prod Cluster GKE Image malveillante Image vérifiée Binary Authorization
7. Binary Authorization Policy Attestation Trois concepts : Attestor
8. Binary Authorization Exemples d'attestors : • Scan de vulnérabilité OS • Tests end-to-end • Test de sécurité des applications (SAST/DAST) • Génération de la liste de dépendances (SBOM) • Un humain pour valider une mise en prod
9. Binary Authorization Pour signer une image : L'attestation qui sera présentée à Binary Authorization :
10. Git Source Repository Cloud Build Devs Test Cluster GKE Prod Cluster GKE Cloud Deploy Image malveillante Image de developpement Image de prod Demo : Binary Authorization Artifact Registry
11. Git Source Repository Cloud Build Devs Test Cluster GKE Prod Cluster GKE Cloud Deploy Image malveillante Image de developpement Image de prod Demo : Binary Authorization Artifact Registry
12. Démo
13. Peut-on mieux faire ?
14. La signature est-elle suffisante ? • Où se trouve le code source ? • À quel commit correspond l'image ? • Quel est le système de build utilisé ? • Quels sont les dépendances utilisées ? • Quels sont les tool chains utilisées lors du build ?
15. 2 Traçabilité : SLSA
16. SLSA • Cadre de sécurité pour la supply chain • Ensemble de règles : ◦ Producteurs : Fournir un logiciel intègre ◦ Consommateurs : Vérifier l'intégrité et l'origine du logiciel avant de l'utiliser • Projet de l'Open Source Security Foundation (OpenSSF) • Projet neutre et communautaire : ◦ Google, Intel, vmWare, RedHat, Chainguard, Kusari ◦ Github, Gitlab, TektonCD, FluxCD, Docker, etc. Security Levels for Software Artifacts
17. SLSA Les deux piliers de SLSA : Un ensemble de règles de sécurité, adoptables de manière progressive. Une provenance est une attestation qui décrit le build : où, comment et par qui un artéfact a été créé.
18. La provenance SLSA
19. Provenance SLSA subject: - name: https://europe-west1-docker.pkg.dev/my-project/my-repo/hello:v0.4.3 digest: sha256: a0d0dbaadb7d9fe41ecf1d4f4614c69deff152bc5df270a84b7200661762d9d0 Artéfact predicate: builder: id: https://cloudbuild.googleapis.com/GoogleHostedWorker buildType: https://cloud.google.com/build/gcb-buildtypes/google-worker/v1 Builder invocation: configSource: entryPoint: "app/cloudbuild.yaml" Entrypoint systemSubstitutions: COMMIT_SHA: 9abeb2126387d50ad44b52924758ab34220d9be6 LOCATION: europe-west1 TRIGGER_NAME: hello-app-trigger ... Variables materials: - uri: git+https://github.com/abdennebi/google-cloud-slsa" digest: sha1: 9abeb2126387d50ad44b52924758ab34220d9be6 Source + dépendances
20. Les règles SLSA
21. Les règles SLSA Les règles sont structuré autour de « tracks » qui sont des aspects particuliers à sécuriser et qui peuvent être traités en parallèle : • Version actuelle : build • Versions futures : source, dépendances et autres 👉 Le build track est réparti sur 3 niveaux à appliquer de manière progressive
22. Les 3 niveaux SLSA Build track Niveau Exigences Objectif Build Level 1 Provenance publiée Documentation Build Level 2 Provenance signée Système de build existe Contrer la falsification après le build Build Level 3 Provenance signée, non-forgeable Système de build renforcé Contrer la falsification pendant le build
23. SLSA et Cloud Build Google Cloud Build supporte SLSA Level 3 Build !
24. Le badge SLSA 3 pour l'artéfact créé par Cloud Build SLSA et Cloud Build
26. Démo
27. À compléter chez vous… Créer un attestor qui vérifie la provenance SLSA :
28. 3 SLSA et Binary Authorization
29. Continuous Validation (CV)
30. Binary Authorization Policy n'effectue la vérification qu'au moment du déploiement 👉 Deploy time security control 👉 Bloque les déploiement CV surveille en permanence les images des pods en cours d'exécution 👉 Runtime security control 👉 Consigne dans Audit Log les non conformités Continuous Validation Continuous validation GKE Cluster
31. Signatures Vérifiées Images récentes Image dans la liste blanche Scan vulnérabilités Provenance SLSA Continuous Validation
32. Continuous Validation : Example Policy
33. Continuous Validation : Example Policy Rappel : J'ai indiqué dans la policy que le repo git devrait être : github.com/abdennebi/google-cloud-slsa
34. Démo
35. En résumé
36. Questions/Réponses