Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Bonnes pratiques pour sécuriser le code dans votre chaîne d’approvisionnement

Conseils sur la façon de protéger le centre de votre chaîne d’approvisionnement, le code que vous écrivez et le code dont vous dépendez.

À propos de ce guide

Ce guide décrit les modifications les plus importantes que vous pouvez apporter pour améliorer la sécurité de votre code. Chaque section décrit une modification que vous pouvez apporter à vos processus pour améliorer la sécurité. Les modifications les plus importantes sont listées en premier.

Quel est le risque ?

Les principaux risques dans le processus de développement sont les suivants :

  • Utilisation de dépendances avec des vulnérabilités de sécurité qu’un attaquant pourrait exploiter.
  • Fuite d’informations d’authentification ou d’un jeton qu’un attaquant peut utiliser pour accéder à vos ressources.
  • Introduction dans votre propre code d’une vulnérabilité qu’un attaquant pourrait exploiter.

Ces risques exposent vos ressources et vos projets à une attaque et sont transmis directement à toute personne qui utilise un package que vous créez. Les sections suivantes expliquent comment vous pouvez protéger vos utilisateurs et vous-même contre ces risques.

Créer un programme de gestion des vulnérabilités pour les dépendances

Vous pouvez sécuriser le code dont vous dépendez en créant un programme de gestion des vulnérabilités pour les dépendances. De manière générale, il doit inclure des processus qui garantissent que vous :

  1. Créez un inventaire de vos dépendances.

  2. Savez quand il existe une vulnérabilité de sécurité dans une dépendance.

  3. Appliquez des révisions de dépendances à vos demandes de tirage.

  4. Évaluez l’impact de cette vulnérabilité sur votre code et décidez quelle action effectuer.

Génération automatique de l’inventaire

Pour commencer, vous souhaitez effectuer un inventaire complet de vos dépendances. Le graphe de dépendances d’un dépôt affiche les dépendances pour les écosystèmes pris en charge. Si vous archivez vos dépendances ou utilisez d’autres écosystèmes, vous devez le compléter avec des données provenant d’outils tiers ou en listant les dépendances manuellement. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

Détection automatique des vulnérabilités dans les dépendances

Dependabot peut vous aider en supervisant vos dépendances et en vous avertissant quand elles contiennent une vulnérabilité connue. Vous pouvez même activer Dependabot pour déclencher automatiquement des demandes de tirage qui mettent à jour la dépendance vers une version sécurisée. Pour plus d’informations, consultez « À propos des Dependabot alerts » et « À propos des mises à jour de sécurité Dependabot ».

Détection automatique des vulnérabilités dans les demandes de tirage

Le dependency review action applique une révision des dépendances à vos demandes de tirage, ce qui vous permet de déterminer facilement si une demande de tirage introduit une version vulnérable d’une dépendance dans votre référentiel. Quand une vulnérabilité est détectée, dependency review action peut bloquer la fusion de la demande de tirage. Pour plus d’informations, consultez « Application de la révision des dépendances ».

Évaluation de l’exposition au risque d’une dépendance vulnérable

Quand vous découvrez que vous utilisez une dépendance vulnérable, par exemple, une bibliothèque ou un framework, vous devez évaluer le niveau d’exposition de votre projet et déterminer quelle action effectuer. Les vulnérabilités sont généralement signalées avec un score de gravité qui donne une idée de leur impact potentiel. Le score de gravité est un guide utile, mais ne peut pas vous indiquer l’impact complet de la vulnérabilité sur votre code.

Pour évaluer l’impact d’une vulnérabilité sur votre code, vous devez également prendre en compte la façon dont vous utilisez la bibliothèque et déterminer dans quelle mesure cela pose réellement un risque pour votre système. Peut-être que la vulnérabilité fait partie d’une fonctionnalité que vous n’utilisez pas et que vous pouvez mettre à jour la bibliothèque affectée et continuer avec votre cycle de publication normal. Ou peut-être que votre code est trop exposé au risque et que vous devez mettre à jour la bibliothèque affectée et diffuser immédiatement une build mise à jour. Cette décision dépend de la façon dont vous utilisez la bibliothèque dans votre système et seul vous êtes à même de la prendre.

Sécuriser vos jetons de communication

Le code doit souvent communiquer avec d’autres systèmes sur un réseau et nécessite des secrets (comme un mot de passe ou une clé API) pour s’authentifier. Votre système a besoin d’accéder à ces secrets pour s’exécuter, mais il est recommandé de ne pas les inclure dans votre code source. C’est particulièrement important pour les dépôts auxquels de nombreuses personnes pourraient avoir accès et critique pour les dépôts publics.

Détection automatique des secrets commités dans un dépôt

Remarque : Les Secret scanning alerts for partners s’exécutent automatiquement sur les dépôts publics dans tous les produits sur GitHub.com. Les Secret scanning alerts for users sont disponibles dans les dépôts publics ainsi que dans les dépôts détenus par des organisations qui utilisent GitHub Enterprise Cloud et qui disposent d’une licence pour GitHub Advanced Security.

Les Pour plus d’informations, consultez « À propos des secret scanning alerts for users » et « À propos de la GitHub Advanced Security ».

GitHub collabore avec de nombreux fournisseurs pour détecter automatiquement quand les secrets sont commités ou stockés dans vos dépôts publics et avertit le fournisseur afin qu’il puisse prendre les mesures appropriées pour garantir la sécurité de votre compte. Pour plus d’informations, consultez « À propos de l’secret scanning alerts for partners ».

Vous pouvez activer et configurer une analyse supplémentaire qui vous alertera en cas de fuite accidentelle de secrets sur GitHub si vous possédez :

  • des référentiels publics sur GitHub.com.
  • une organisation utilisant GitHub Enterprise Cloud avec une licence pour GitHub Advanced Security. Secret scanning analyse également vos référentiels privés.

Stockage sécurisé des secrets que vous utilisez dans GitHub

Il est probable que vous deviez utiliser des secrets ailleurs que dans votre code. Par exemple, pour autoriser les workflows GitHub Actions, Dependabot ou votre environnement de développement GitHub Codespaces à communiquer avec d’autres systèmes. Pour plus d’informations sur la façon de stocker et d’utiliser des secrets de manière sécurisée, consultez « Secrets chiffrés dans les actions », « Gestion des secrets chiffrés pour Dependabot » et « Gestion des secrets chiffrés pour vos codespaces ».

Conserver les modèles de codage vulnérables hors de votre dépôt

Remarque : Code scanning est disponible pour tous les dépôts publics sur GitHub.com. Code scanning est également disponible pour des dépôts privés appartenant à des organisations qui utilisent GitHub Enterprise Cloud et ont une licence pour GitHub Advanced Security. Pour plus d’informations, consultez « À propos de GitHub Advanced Security ».

Créer un processus de révision de demande de tirage

Vous pouvez améliorer la qualité et la sécurité de votre code en vous assurant que toutes les demandes de tirage sont révisées et testées avant qu’elles ne soient fusionnées. GitHub a de nombreuses fonctionnalités que vous pouvez utiliser pour contrôler le processus de révision et de fusion. Pour commencer, consultez « À propos des branches protégées ».

Rechercher les modèles vulnérables dans votre code

Il est souvent difficile pour les réviseurs de repérer sans assistance les modèles de code non sécurisés. En plus de rechercher les secrets dans votre code, vous pouvez vérifier s’il contient des modèles associés à des vulnérabilités de sécurité. Par exemple, une fonction qui n’est pas sécurisée au niveau de la mémoire ou qui ne parvient pas à placer dans une séquence d’échappement une entrée utilisateur susceptible d’entraîner une vulnérabilité d’injection. GitHub offre plusieurs approches pour déterminer comment et quand analyser votre code. Pour commencer, consultez « À propos de l’analyse du code ».

Étapes suivantes