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

À 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 contrôles 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 surveillant vos dépendances et en vous informant lorsqu’elles contiennent une vulnérabilité connue. Vous pouvez même activer Dependabot pour déclencher automatiquement des requêtes de tirage qui mettent à niveau la dépendance vers une version sécurisée. Pour plus d’informations, consultez « [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) » et « [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates) ».

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

L’application action de révision des dépendances d’une révision de dépendance sur vos demandes de tirage (pull requests) vous permet de voir facilement si une demande de tirage introduit une version vulnérable d’une dépendance dans votre référentiel. Lorsqu'une vulnérabilité est détectée, le action de révision des dépendances peut bloquer la fusion du pull request. 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. Cette pratique revêt une importance particulière pour les référentiels accessibles à un grand nombre de personnes et s’avère indispensable pour les référentiels publics.

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

          GitHub partenaires avec de nombreux fournisseurs pour détecter automatiquement le moment où les secrets sont validés ou stockés dans vos dépôts publics et les packages npm publics dont vous dépendez, et avertiront le fournisseur afin qu’il puisse prendre les mesures appropriées pour garantir la sécurité de votre compte. Pour plus d’informations, consultez « [AUTOTITLE](/code-security/secret-scanning/managing-alerts-from-secret-scanning/about-alerts##about-partner-alerts) ».

Vous pouvez activer et configurer une analyse supplémentaire qui vous alertera au sujet des secrets accidentellement divulgués sur GitHub si vous en êtes propriétaire :

• Des référentiels publics.
• Une organisation utilisant GitHub Team ou GitHub Enterprise Cloud avec une licence pour GitHub Secret Protection or GitHub Advanced Security. Secret scanning analyse également vos dépôts privés.

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

En plus de votre code, vous devez probablement utiliser des secrets dans d’autres endroits. Par exemple, pour autoriser GitHub Actions les flux de travail, Dependabotou votre GitHub Codespaces environnement de développement à communiquer avec d’autres systèmes. Pour en savoir plus sur les bonnes pratiques de stockage et d’utilisation sécurisés des secrets, consultez Utilisation de secrets dans GitHub Actions, Configuration de l’accès aux registres privés pour Dependabot et Gestion des secrets spécifiques à votre compte pour GitHub Codespaces.

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

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 dispose 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 façons différentes d’aborder à la fois comment et quand vous analysez votre code. Pour bien démarrer, consultez À propos de l’analyse du code.

Étapes suivantes

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)