Sécurisez la chaîne de développement logiciel avec SLSA Mohamed Abdennebi Cloud Security Lead AppMod Days 2023

Comment vous assurer que le code déployé en prod est bien le vôtre ?

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

Comment s'assurer de l'authenticité et la de traçabilité de vos artefacts ?

1 Authenticité : Binary Authorization

Prod Cluster GKE Image malveillante Image vérifiée Binary Authorization

Binary Authorization Policy Attestation Trois concepts : Attestor

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

Binary Authorization Pour signer une image : L'attestation qui sera présentée à Binary Authorization :

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

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

Démo

Peut-on mieux faire ?

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 ?

2 Traçabilité : SLSA

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

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éé.

La provenance SLSA

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

Les règles SLSA

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

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

SLSA et Cloud Build Google Cloud Build supporte SLSA Level 3 Build !

Le badge SLSA 3 pour l'artéfact créé par Cloud Build SLSA et Cloud Build

No content

Démo

À compléter chez vous… Créer un attestor qui vérifie la provenance SLSA :

3 SLSA et Binary Authorization

Continuous Validation (CV)

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

Signatures Vérifiées Images récentes Image dans la liste blanche Scan vulnérabilités Provenance SLSA Continuous Validation

Continuous Validation : Example Policy

Continuous Validation : Example Policy Rappel : J'ai indiqué dans la policy que le repo git devrait être : github.com/abdennebi/google-cloud-slsa

Démo

En résumé

Questions/Réponses