Si vous tombez un jour sur une clé USB posée négligemment sur la table d'une salle de réunion, la brancheriez-vous dans votre portable ? "Jamais !" me diriez-vous. Pourtant, c'est ce que nous faisons presque tout le temps avec les dépendances logicielles que nous récupérons d'Internet. Ces dépendances ou artefacts sont devenus si complexes que nous ne maîtrisons plus leur contenu ou leurs dépendances transitives. Cette complexité s’étend à nos chaînes de production logicielle qui peuvent être corrompues à des endroits multiples : le référentiel de code source, le système de build ou le registre d'artefacts.Pour sécuriser notre chaîne de build ou "software supply chain", nous devons être capables de vérifier l'authenticité et l'intégrité des dépendances. De même, en tant que producteurs d'artefacts, nous devons garantir un niveau équivalent de sécurité et de transparence à nos consommateurs. Mais comment faire sans alourdir la chaîne CI/CD ni nuire à la productivité du développeur ? La réponse ? C’est la communauté open source qui l’a apportée avec SLSA et Sigstore, principaux sujets de ce talk. Pour commencer, nous parlerons de SLSA dont le but est de vous accompagner dans l’amélioration de votre chaîne de build en appliquant de bonnes pratiques de sécurité par paliers successifs. Nous parlerons également de Sigstore et de la manière avec laquelle il permet d’implémenter SLSA en rendant transparente la signature et l’attestation des artefacts. Nous clôturerons le talk par une démo sur la protection des déploiements dans Kubernetes à l'aide du moteur de règles "Kyverno".

1. Sécurisez votre software supply chain
avec SLSA, Sigstore et Kyverno
Speaker :
Mohamed Abdennebi, @abdennebi
SFEIR
#KCDFrance 2023

2. Les attaques sur la supply chain
#KCDFrance 2023
Source : https://www.sonatype.com/state-of-the-software-supply-chain/introduction
Attaques
Confusion de dépendance
Typosquatting
Injection de code
malicieux

3. La supply chain logicielle
Source
Repo
Build
System
Package
Repo
Dépendances
(C)
Build à partir
d'un autre
source repo
(B)
Compromission
du source repo
(D)
Compromission
du process de
build
(F)
Upload de
package modifié
(G)
Compromission
du package
repo
(A)
Soumettre des
changements
non autorisés
(H)
Utilisation d'un
package vérolé
(E)
Utilisation d'une
dépendance
vérolée

4. Best Practices & Frameworks
#KCDFrance 2023
● OWASP : Top 10 CI/CD Security Risks, 2022
● CNCF : Software Supply Chain Best Practices, 2021
● NIST SSDF : Secure Software Development Framework, 2022
● CIS Software Supply Chain Security Guide, 2022
● SLSA : (1.0 RC1 février 2023)

5. SLSA

6. SLSA
#KCDFrance 2023
● Security Levels for Software Artifacts
● Objectif : assurer l'intégrité de la supply chain
● Projet de l'Open Source Security Foundation (OpenSSF)
● Inspiré par « Binary Authorization for Borg » au sein de Google
Borg et SLSA : https://cloud.google.com/docs/security/binary-authorization-for-borg

7. SLSA
#KCDFrance 2023
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éé.

8. Qu'est-ce une attestation ?
#KCDFrance 2023
C'est un ensemble d'informations sur un artéfact.
👉 Permet au consommateur de décider d'utiliser ou non un artéfact en fonction des
informations contenues dans l'attestation.
Une attestation peut fournir :
● Détails sur le build : Provenance SLSA
● Liste des dépendances : SBOM (Software Bill of Materials)
● Liste des vulnérabilités de l'OS ou des dépendances
● Inventer la vôtre :)

9. Provenance SLSA
#KCDFrance 2023
subject:
- name: ghcr.io/albasystems/hello-slsa
digest:
sha256: 278ca5a875482d3321235a0a3d3b9307fa0701c99228accf0168acb6d62cf183
predicate:
buildType: https://github.com/slsa-framework/slsa-github-generator/container@v1
builder:
id: https://github.com/albasystems/slsa-generator/.github/workflows/slsa3.yml@refs/tags/v1.5.0
invocation:
configSource:
entryPoint: ".github/workflows/build.yml"
environment:
github_actor: abdennebi
github_actor_id: '787057'
github_event_name: push
...
materials:
- uri: git+https://github.com/albasystems/hello-slsa@refs/heads/main
digest:
sha1: 7a9d468e70d401ceebaf9e2b22496f62c0656c0b

10. Provenance SLSA
#KCDFrance 2023
À quoi servira la provenance ?
● Remonter du binaire au code source (lien fort entre les deux)
● Garantir l'intégrité du binaire
● Rejouer le build pour recréer l'artéfact

11. Les règles SLSA
#KCDFrance 2023
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

12. Build Track L1 : Provenance
#KCDFrance 2023
Description : Provenance publiée
1. Le mainteneur documente les valeurs que doit avoir la provenance.
2. Le mainteneur produit à chaque build une attestation de
provenance.
3. Les consommateurs vérifient que le package est conforme au
contenu de la provenance et aux valeurs documentées par le
mainteneur.
La provenance n'est pas nécessairement exhaustive.

13. Build Track L2 : Build Service
#KCDFrance 2023
Description : Service de build existe + provenance signée
1. Le build est hébergé sur un service de build qui génère et signe
automatiquement la provenance.
⚠ Postulat de base : le système de build est correctement
sécurisé.
2. Le consommateur vérifie l'authenticité de la provenance ainsi que
les informations qu'elle contient.

14. Build Track L3 : Hardened Builds
#KCDFrance 2023
Description : Build renforcé + provenance non-falsifiable
1. Les jobs contrôlés par l'utilisateur ne peuvent pas accéder à la clé de
signature pour éviter de forger des provenances
2. Isolation des jobs : les jobs de build ne peuvent pas s'influencer les
uns les autres, même au sein d'un même projet.
3. VMs, containers de build éphémères

15. En résumé
#KCDFrance 2023
Si vous avez un système de build capable :
- De lancer des jobs isolés les un des autres
- D'assurer qu'il sont éphémères
- Générer et signer des provenance automatiquement sans l'intervention ni
l'influence des jobs utilisateurs.
Alors il est éligible au niveau SLSA 3 et vous avez la garantie que ce que vous
déployez a été protégé contre toute modification.

16. SLSA Build Track
Source Build Package
Dépendances
(C)
Build à partir
d'un autre
source repo
(B)
Compromission
du source repo
(D)
Compromission
du process de
build
(F)
Upload de
package modifié
(G)
Compromission
du package
repo
(A)
Soumettre des
changements
non autorisés
(H)
Utilisation d'un
package vérolé
(E)
Utilisation d'une
dépendance
vérolée

17. Implémentation de SLSA
#KCDFrance 2023
Objectif : Construire un container et atteindre le niveau SLSA Build L3
En utilisant
1. Github Actions et Github Workflows comme système de build
2. Sigstore pour la signature des provenances

18. Sigstore
Le «Let's Encrypt» de la signature
de code

19. Sigstore
#KCDFrance 2023
Service d'utilité publique pour la signature d'artéfacts logiciels.
Inspiré de Let's Encrypt.
Sous l'égide de l'OpenSSF.
C'est une PKI pour livraison de certificat de signature de code
● Cosign : CLI de signature pour les containers et blobs
● Fulcio : CA qui délivre des certificats de signature X.509
● Rekor : Transparency Log pour certificats et les signatures

20. Sigstore
#KCDFrance 2023
Principes de la signature keyless :
● On s'authentifie auprès de son provider OIDC (OpenId Connect)
● On échange son "Identity Token" contre un certificat d'une durée
de vie de 10 min
👉 Pas de gestion de clé privée, elle est jetée dès que l'artéfact est
signé.
👉 Pas de complexité liée à la révocation car le certificat a une
durée de vie très courte.

21. Démo time !
#KCDFrance 2023
Démo 1 : Signature keyless avec Sigstore
Démo 2 : Générer un container estampillé SLSA
Build L3
Démo 3 : Déployer le container dans un cluster
Kubernetes en vérifiant sa provenance par Kyverno

22. Démo 1
#KCDFrance 2023
Signature keyless avec Sigstore
Repo git :
https://github.com/albasystems/hello-slsa

23. Démo 2
#KCDFrance 2023
Générer un container SLSA Build L3 (avec provenance signée
par Sigstore)
SLSA

24. Démo 2
#KCDFrance 2023
Nous utilisons Github Actions comme système de build.
Pour générer une provenance non falsifiable, il nous faut :
1. Isoler la génération de provenance contre toute interférence
externe (y compris les développeurs)
2. Le générateur de provenance doit avoir une identité OIDC
pour pouvoir signer la provenance.

25. Démo 2
#KCDFrance 2023
Les "Reusable Workflows" répondent aux exigences précédentes :
● Sont séparés du repo de l'utilisateur
● Sont appelés par les workflow de l'utilisateur mais sans aucune
interférence (Isolation)
● Ont leur propre identité OIDC 👉 Ils peuvent signer les
provenance en utilisant Sigstore
● Se lancent dans une nouvelle VM éphémère

26. Démo 2
#KCDFrance 2023
rekor
container
registry
publier
signature
publier
provenance
signée
Provenance generator
workflow
Build workflow
Project Repo
"Hello SLSA"
Provenance generator
repo
Trigger
Dev
DevSecOps
Push
Alba
Systems

27. Autorisation binaire avec
Kyverno

28. Kyverno
#KCDFrance 2023
● « Policy Engine » pour Kubernetes
● Open Source, fait partie des projets CNCF
● Il peut :
○ valider
○ muter
○ générer et nettoyer les ressources Kubernetes
👉 Nous allons l'utiliser pour valider la provenance des
pods

29. Démo 3
#KCDFrance 2023
Déployer le container dans un cluster
Kubernetes et vérifier sa provenance par Kyverno
SLSA

30. #KCDFrance 2023
Merci !