Durcir GitHub Actions en une semaine : plan pour équipes de dev

Tout utilisateur disposant d'un accès en écriture à un dépôt peut lire tous les secrets qui y sont configurés. Les identifiants utilisés par vos workflows doivent donc porter le moindre privilège que le job permet. La référence de GitHub sur l'utilisation sécurisée dit la même chose du GITHUB_TOKEN : ne lui accordez que les permissions minimales nécessaires. Les cinq tâches ci-dessous demandent une journée chacune.

Le Top 10 des risques de sécurité CI/CD de l'OWASP nomme les zones de risque que ce plan couvre : gestion des identités et des accès inadéquate (CICD-SEC-2), abus de la chaîne de dépendances (CICD-SEC-3), exécution de pipeline empoisonné (CICD-SEC-4), hygiène insuffisante des identifiants (CICD-SEC-6) et validation inadéquate de l'intégrité des artefacts (CICD-SEC-9).

Lundi : réduire ce que le token peut faire

Partez du principe que toute personne pouvant pousser du code dans le dépôt peut en lire les secrets. Réduisez ensuite ce que ces identifiants permettent d'atteindre.

GitHub recommande de définir la permission par défaut du GITHUB_TOKEN en lecture seule pour le contenu du dépôt, puis de l'élever job par job. Dans un fichier de workflow :

permissions:
  contents: read

jobs:
  release:
    permissions:
      contents: write

Passez en revue chaque workflow et demandez-vous quels jobs écrivent réellement quelque chose. Donnez l'accès en écriture à ces jobs et laissez tous les autres en lecture.

Mardi : auditer les actions que vous exécutez

Dressez la liste de toutes les actions utilisées dans vos workflows, y compris celles appelées depuis des workflows réutilisables que vous maintenez. Pour chacune, lisez le code source de l'action et celui du dépôt qui l'exécute.

Les recommandations de GitHub sur l'audit des secrets sont précises quant à ce qu'il faut rechercher. Vérifiez que les secrets ne sont pas envoyés vers des hôtes non prévus et qu'ils ne sont pas affichés explicitement dans les logs.

Appliquez ensuite le moindre privilège aux identifiants eux-mêmes. Puisque l'accès en écriture au dépôt donne un accès en lecture à ses secrets, chaque identifiant utilisé par un workflow ne doit pouvoir faire que ce dont ce workflow a besoin. Un token de déploiement capable d'administrer tout le compte cloud ne passe pas ce test.

Mercredi : injection de script

Les valeurs de contexte non fiables, comme le titre d'une pull request, deviennent un problème lorsqu'on les place directement dans un script en ligne. La référence de GitHub propose deux moyens de l'éviter.

L'approche recommandée consiste à utiliser une action qui reçoit la valeur de contexte en argument, car la valeur n'est alors jamais utilisée pour générer un script shell. Si vous devez conserver un script en ligne, placez l'expression dans une variable d'environnement intermédiaire :

- name: Check PR title
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: |
    if [[ "$TITLE" =~ ^octocat ]]; then exit 0; else exit 1; fi

Dans l'exemple de GitHub, un titre égal à a"; ls $GITHUB_WORKSPACE" fait échouer la vérification et la commande n'est pas exécutée. La valeur est stockée en mémoire et utilisée comme variable, elle n'interagit donc pas avec la génération du script. GitHub suggère aussi de placer les variables shell entre guillemets doubles pour éviter le word splitting, ce qui relève des bonnes pratiques générales du shell.

Pour repérer les cas à examiner, recherchez les expressions de contexte dans vos workflows et lisez chaque occurrence dans son bloc run: :

grep -rn 'github.event' .github/workflows

Jeudi : secrets et environnements protégés

Placez les secrets de déploiement dans des environnements et exigez des relecteurs. Un job de workflow ne peut pas accéder aux secrets d'un environnement tant qu'un relecteur n'a pas donné son approbation.

GitHub est clair : le masquage automatique n'est pas garanti, car la valeur d'un secret peut être transformée de plusieurs façons. Le masquage repose en grande partie sur la recherche d'une correspondance exacte, et il est effectué par le runner. Un secret n'est donc masqué que si un job l'a utilisé et que le runner y a eu accès. Servez-vous de ce tableau pour votre revue :

Les erreurs peuvent atteindre STDOUT et STDERR de manière imprévue : lisez donc les logs à la main après vos tests. Si un secret non masqué se retrouve dans un log d'exécution, supprimez le log et renouvelez le secret. Supprimez les secrets devenus inutiles et renouvelez les autres périodiquement, ce qui réduit la durée pendant laquelle une valeur compromise reste exploitable.

Vendredi : propriété des workflows et des livrables

Cette section relève de nos propres conseils. Les sources citées plus haut ne les prescrivent pas, et ils ne sont attribués ni à GitHub, ni à l'OWASP, ni au NIST.

Décidez qui est autorisé à modifier les workflows qui construisent et publient vos logiciels, et consignez-le par écrit. Si vous utilisez CODEOWNERS sur votre plateforme, le répertoire .github/workflows est un chemin pertinent à couvrir. Identifiez ensuite quel workflow produit vos artefacts de release, puisque ce sont eux que vos clients ou vos systèmes de production vont considérer comme dignes de confiance.

Les sources ne vont que partiellement jusqu'au bout sur les artefacts. L'OWASP classe la validation inadéquate de l'intégrité des artefacts sous CICD-SEC-9, et l'insuffisance de journalisation et de visibilité sous CICD-SEC-10. Le Secure Software Development Framework (SP 800-218) du NIST fournit un vocabulaire commun que clients et fournisseurs peuvent utiliser pour parler de développement sécurisé. Aucune de ces sources ne donne de recette de signature, nous n'en proposons donc pas.

Enfin, déterminez qui remarque les changements apportés aux fichiers de workflow, aux secrets ou aux approbations d'environnement, et comment cette personne en est informée.

Par où commencer

1. Définissez la permission par défaut du GITHUB_TOKEN en lecture seule pour le contenu du dépôt, et ajoutez des blocs permissions aux jobs qui ont besoin de plus.
2. Listez toutes les actions utilisées, lisez leur code source et vérifiez qu'elles n'envoient pas de secrets vers des hôtes inattendus et ne les affichent pas dans les logs.
3. Recherchez les expressions de contexte dans les blocs run: et déplacez-les dans une variable d'environnement intermédiaire, ou dans une action.
4. Déplacez les secrets de production dans un environnement avec relecteurs obligatoires, découpez les secrets structurés en valeurs uniques, enregistrez les valeurs dérivées et renouvelez tout ce qui est apparu dans un log.
5. Consignez par écrit qui peut modifier les workflows qui construisent les artefacts de release, et qui est prévenu lorsqu'ils changent.

Si vous souhaitez un second avis sur vos pipelines, notre accompagnement en développement logiciel sécurisé couvre la configuration CI/CD. Un test d'intrusion peut montrer si une pull request permet d'atteindre vos secrets.