Sécurité avancée GitHub pour Azure DevOps (2023)

Microsoft apporte certains des outils GitHub Advanced Security à Azure DevOps. Je joue avec depuis un moment et ils ont présenté le dernier état de Microsoft Build 2023, qui comprend unAvant-première publique !. Cela signifie que vous pouvez l'essayer vous-même et que je peux enfin partager mes expériences avec vous ! Étant donné que j'enseigne à beaucoup de gens comment l'utiliser sur GitHub, vous pouvez également trouver certaines des différences entre les deux implémentations dans cet article 😉.

photo parAdi GoldsteinsurUnsplash

Qu'est-ce que la sécurité avancée de GitHub ?

GitHub Advanced Security (GHAS) est un ensemble d'outils qui vous aide à sécuriser votre code et vos pipelines. Il comprend les outils suivants :

• Numérisation de code
• Dependabot / Analyse des dépendances
• Numérisation secrète

Si vous souhaitez approfondir cette fonctionnalité, consultez mon cours d'apprentissage LinkedInici.

Dependabot / Analyse des dépendances

Analyse votre référentiel à la recherche de fichiers manifestes connus, tels que package.json, et vérifie s'il existe des vulnérabilités dans les packages que vous utilisez. Il créera ensuite une demande d'extraction pour mettre à jour le package vers une version plus récente qui ne présente pas la vulnérabilité. Il peut également automatiser la création de demandes d'extraction pour les mises à jour de version.

Numérisation secrète

Analyse votre référentiel à la recherche de secrets connus, tels que des mots de passe, et vous avertit s'il en trouve. Il vous avertira également si vous poussez un commit contenant un secret. Il analysera également vos demandes d'extraction de secrets et vous avertira s'il en trouve.

Numérisation de code

Analyse votre code à la recherche de vulnérabilités connues à l'aide de CodeQL (ou d'un autre outil de sécurité des applications statiques, également appelé SAST). Il peut également analyser vos demandes d'extraction de vulnérabilités et vous avertir s'il en trouve.

Microsoft apporte les fonctionnalités de GHAS dans Azure DevOps, car les clients le demandent depuis un certain temps. C'est un exemple de la façon dont ils exploitent les deux produits maintenant, puisque les nouvelles fonctionnalités seront d'abord conçues pour GitHub, et si cela a du sens, ils pourraient également intégrer certaines de ces fonctionnalités dans Azure DevOps.

Vous pouvez voir la synergie ici ainsi que bien sûr : tous les modèles d'analyse secrets connus de GHAS peuvent également être utilisés dans Azure DevOps, car ils peuvent le partager entre les entreprises.

Comment démarrer avec GitHub Advanced Security pour Azure DevOps

Vous devrez d'abord activer la sécurité avancée au niveau du référentiel, pour lequel vous aurez bien sûr besoin d'un accès au niveau administrateur du projet :

Après avoir activé la fonctionnalité (dépôt par dépôt, car cela vous coûtera des licences à l'avenir), vous obtiendrez un nouvel onglet "Sécurité avancée" dans le menu de votre référentiel. Cela vous montrera les résultats des analyses qui ont été effectuées sur votre référentiel.

Après avoir activé la fonctionnalité, vous obtiendrez des options de menu supplémentaires à gauche et à droite, ainsi que des tâches supplémentaires pour vos Azure Pipelines.

L'analyse secrète est automatiquement activée lorsque vous activez la sécurité avancée. Il lancera une tâche en arrière-plan qui analysera votre référentiel à la recherche de secrets. Il analysera également l'intégralité de l'historique de vos dépôts : tous les commits et toutes les branches seront vérifiés, pour les modèles secrets connus. Une fonctionnalité supplémentaire est la « protection anti-poussée ». Cela vous évitera de pousser un commit contenant un secret. Il s'agit d'une fonctionnalité intéressante pour empêcher les secrets d'être poussés vers votre référentiel et "arrêter la fuite" de nouvelles alertes qui arrivent.

#

Pour démarrer avec l'analyse des dépendances, vous devez l'injecter dans un pipeline. Pour ce faire, ajoutez la tâche suivante à votre pipeline :

 - tâche: AdvancedSecurity-Dependency-Scanning@1

La prochaine fois que ce pipeline s'exécutera, il analysera votre référentiel à la recherche de fichiers manifestes connus, tels que.csprojpour les projets C#, oupackage.jsonpour les projets NodeJS. À partir de ces fichiers manifestes, il rassemble les informations sur les packages que vous extrayez et peut également vérifier l'écosystème sous-jacent pour les dépendances de ces packages (les bibliothèques s'appuient également sur d'autres bibliothèques). Il vérifiera ensuite s'il existe des vulnérabilités dans les packages que vous utilisez. Vous pouvez vérifier chaque package que vous utilisez, ainsi que toutes leurs dépendances, avec leurs numéros de version par rapport à la base de données nationale des vulnérabilités (NVDde l'institut NIST). La version qui n'est plus vulnérable (le cas échéant) est également enregistrée dans le NVD.

Sur GitHub, ces informations sont utilisées pour créer une demande d'extraction pour mettre à jour le package vers une version plus récente qui ne présente pas la vulnérabilité. Il peut également automatiser la création de demandes d'extraction pour les mises à jour de version. Ceci n'est pas disponible pour GitHub Advanced Security pour Azure DevOps. Je m'attends à ce que cela soit ajouté plus tard, mais pour l'instant, vous devrez créer vous-même les demandes d'extraction.

Dans l'alerte, vous obtiendrez des informations sur la version du package que vous utilisez, la première version non vulnérable, ainsi que le type de vulnérabilité, afin que vous puissiez connaître le type de vecteur d'attaque pour cette alerte.

Pour activer l'analyse de code, vous devez également injecter CodeQL dans un pipeline Azure (d'autres outils SAST fonctionneront également, tant qu'ils téléchargent unSARIFdéposer):

 - tâche: AdvancedSecurity-Codeql-Init@1 contributions: langues: 'csharp' - tâche: AdvancedSecurity-Codeql-Autobuild@1 - tâche: AdvancedSecurity-Codeql-Analyze@1 - tâche: AdvancedSecurity-Publish@1

Il y a quelques étapes à noter ici :

1. Init créera une base de données locale vide qui sera remplie avec tous les chemins de code que votre code emprunte (par exemple : la méthode A appelle la méthode B). Vous l'alimentez également dans l'un des langages pris en charge (C#, Java, C/C++, Python, JavaScript/TypeScript, Go ou Ruby).
2. L'étape de construction automatique essaiera de construire votre application, basée sur des modèles connus pour la langue que vous avez sélectionnée. Parfois, la construction automatique échoue pour certains projets, vous pouvez alors utiliser vos propres étapes de construction à sa place.
3. Avec Analyze, vous exécutez toutes les requêtes CodeQL sur la base de données créée à l'étape 1. Cela créera également un fichier SARIF contenant tous les résultats des requêtes (si une requête a un résultat, elle deviendra une alerte).
4. L'étape de publication téléchargera en fait le fichier SARIF vers le service de sécurité avancée, qui vous montrera ensuite les résultats dans l'interface utilisateur.

Les requêtes qui seront exécutées se trouvent dans le référentiel CodeQL surgithub.com. Il existe un ensemble par défaut avec des taux de bruit faibles, mais vous pouvez également utiliserrequêtes étenduesen les configurant ainsi :

 - tâche: AdvancedSecurity-Codeql-Analyze@1 contributions: suite de requêtes: 'sécurité-et-qualité'

Notez que dans Azure DevOps, vous configurez ceci sur leAnalysertâche où, comme vous le faites dans GitHub dans leInitmarcher.

Sachez que l'ajout de requêtes plus étendues augmentera la durée du pipeline, ainsi que le nombre d'alertes que vous recevrez : les requêtes étendues ont un peu plus de bruit et potentiellement aussi plus de faux positifs. Par exemple, à partir de mon application de démonstration, je suis passé de 4 alertes normales à 7 alertes supplémentaires lorsque j'ai ajouté les requêtes étendues desécurité-et-qualité.

Le conseil est d'exécuter ces requêtes àmoinssur une demande d'extraction, ainsi que sur un calendrier : la communauté qui construit ces requêtes est super active (150 à 200 demandes d'extraction par mois dans ce référentiel), vous obtiendrez donc de nouvelles requêtes qui pourraient trouver des vulnérabilités dans votre code.

Lorsqu'un résultat des requêtes est présent, vous les verrez également apparaître dans les journaux :

À partir du téléchargement du fichier SARIF, vous obtiendrez alors les alertes générées dans l'aperçu de la sécurité avancée :

Lorsque vous ouvrez une alerte, vous obtenez plus d'informations sur la page de détail :

De là, vous pouvez à nouveau en savoir plus sur la vulnérabilité trouvée, avec des liens vers le numéro Common Weakness Enumeration (CWE) sur leMitre site.

Pour corriger les alertes, vous devrez en fait corriger le résultat lui-même. Il n'existe pas encore de moyen de rejeter les alertes dans Azure DevOps (quelque chose que nous avons du côté GitHub).

Correction des alertes d'analyse secrètes

Pour l'analyse secrète, l'interface utilisateur affiche actuellement l'avertissement indiquant que vous devez traiter ce secret comme une valeur divulguée, et la correction ne peut être effectuée qu'en révoquant le secret.

Puisqu'il n'y a pas encore de moyen de rejeter cette alerte via l'interface utilisateur, la seule façon de s'en débarrasser est de réécrire l'historique du référentiel afin que le commit ne soit plus dans l'historique. Je m'attends à ce que les alertes de rejet soient ajoutées à l'avenir, mais pour l'instant, c'est le seul moyen de se débarrasser de l'alerte.

Correction des alertes d'analyse des dépendances

Pour vous débarrasser d'une alerte d'analyse de dépendance, vous devrez créer une demande d'extraction pour mettre à niveau la dépendance vers une version qui n'est plus vulnérable. Lorsque l'analyse de détection s'exécutera à nouveau, l'alerte sera fermée. Vous avez un lien vers le pipeline qui a détecté que la dépendance vulnérable n'est plus présente :

Adressage des alertes de lecture de code

La correction des alertes d'analyse de code est un peu plus compliquée, car vous devrez réellement corriger le code à l'origine de l'alerte. Une fois le problème résolu, la prochaine analyse fermera l'alerte et renverra à l'analyse qui a fermé l'alerte. À partir de là, vous pouvez également trouver le commit qui a résolu le problème, vous avez donc cette traçabilité de bout en bout.

Notez qu'actuellement, vous ne pouvez pas exclure du code de l'analyse CodeQL (sur GitHub, vous le pouvez). Cela signifie également que votre suite de tests unitaires, par exemple, sera également analysée, avec un bon changement, elle y trouvera également des problèmes (j'ai eu le même problème avec mon projet de test).

Tableau de bord

Pour une vue d'ensemble de la façon dont vous vous en sortez dans l'ensemble du projet ou de l'organisation, vous devrez regarderMicrosoft Defender pour DevOps, qui est un outil de Microsoft Azure. Étant donné que Defender n'est pas encore intégré (je pense que vous avez besoin d'un indicateur de fonctionnalité pour l'activer), je n'ai pas encore de captures d'écran. Je les ajouterai dès que j'aurai accès !

L'intégration a du sens du point de vue d'Azure et l'intègre dans les outils que les utilisateurs d'Azure Cloud utilisent. Mais si vous utilisez uniquement Azure DevOps, je m'attendrais à ce qu'un aperçu trouve également des modèles ou des dépendances répétés dans votre organisation Azure DevOps. Je ne serais pas surpris s'ils ajoutaient cet aperçu quelque part dans le futur.

Résumé

Dans l'ensemble, la plupart des fonctionnalités initiales sont déjà intégrées, avec certainement des choix différents en la comparant à l'implémentation de GitHub (par exemple, le tableau de bord). Vous pouvez voir qu'il n'en est qu'à ses débuts, mais je m'attends à ce que le reste des fonctionnalités / ajustements se fassent rapidement, maintenant que la partie initiale a été intégrée (ce qui est souvent le plus de travail).

Nous avons maintenant de bonnes fonctionnalités de sécurité intégrées dans Azure DevOps, directement dans l'expérience du développeur, et c'est là que cela doit arriver à mon avis : avec les personnes qui peuvent agir sur les résultats et les corriger au début de leur processus. J'espère qu'ils intégrerontdépendance-examen-actionéquivalent pour Azure DevOps ensuite, de sorte que les développeurs seront également en mesure d'arrêter la fuite (des dépendances vulnérables entrantes).

Si vous voulez en savoir plus ou avez des questions, utilisez les commentaires ci-dessous !