Skip to main content

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. Si vous disposez au moins d’un accès en lecture au dépôt, vous pouvez exporter les graphe des dépendances pour le dépôt en tant que nomenclature logicielle compatible SPDX (SBOM), via l’interface utilisateur de GitHub ou l’API REST GitHub. Pour plus d’informations, consultez « Exportation d’une nomenclature logicielle pour votre dépôt ».

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 alertes Dependabot » et « À propos des mises à jour de sécurité Dependabot ».

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

Le action de révision des dépendances 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, action de révision des dépendances peut bloquer la fusion de la demande de tirage. Pour plus d’informations, consultez « À propos de la vérification 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. Ceci est particulièrement important pour les dépôts auxquels de nombreuses personnes pourraient avoir accès et même critique pour les dépôts publics.

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

Note

Secret scanning est disponible pour les référentiels suivants :

  • Référentiels appartenant à l’organisation avec GitHub Advanced Security activé

  • pour une entreprise avec GitHub Advanced Security activé

Remarque : Votre administrateur de site doit activer l’secret scanning pour l’instance avant de pouvoir utiliser cette fonctionnalité. Pour plus d’informations, consultez « Configuration de l’analyse de secrets pour votre appliance ».

Vous ne pourrez peut-être pas activer ni désactiver les secret scanning si un propriétaire d'entreprise a défini une stratégie au niveau de l'entreprise. Pour plus d’informations, consultez « Application de stratégies de sécurité et d’analyse du code pour votre entreprise ».

Vous pouvez configurer l'secret scanning pour rechercher les secrets émis par de nombreux fournisseurs de services et être averti quand des secrets sont détectés. Vous pouvez également définir des modèles personnalisés pour détecter des secrets supplémentaires au niveau du dépôt, de l'organisation ou de l'entreprise. Pour plus d’informations, consultez « À propos de l’analyse des secrets » et « Modèles d’analyse de secrets pris en charge ».

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

Il est probable que vous deviez utiliser des secrets ailleurs que dans votre code. Par exemple, pour autoriser les workflows GitHub Actions ou Dependabot à 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 « Utilisation de secrets dans GitHub Actions » et « Configuration de l’accès aux registres privés pour Dependabot. »

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

Note

Référentiels appartenant à l’organisation avec GitHub Advanced Security activé

Remarque : Votre administrateur de site doit activer l’code scanning avant de pouvoir utiliser cette fonctionnalité. Pour plus d’informations, consultez « Configuration de l’analyse de code pour votre appliance ».

Vous ne pourrez peut-être pas activer ou désactiver lcode scanning si un propriétaire d’entreprise a défini une stratégie GitHub Advanced Security (GHAS) au niveau de l’entreprise. Pour plus d’informations, consultez « Application de stratégies de sécurité et d’analyse du code pour votre entreprise ».

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 bien démarrer, 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 bien démarrer, consultez À propos de l’analyse du code.

Étapes suivantes