Partager via

La prise en charge de GitHub Advanced Security et de l’identité managée et du principal de service pour Azure DevOps est désormais en disponibilité générale

  • Article

Nous sommes heureux d’annoncer que la prise en charge de GitHub Advanced Security et d’identité managée et du principal de service pour Azure DevOps est désormais en disponibilité générale !

Sur GitHub Advanced Security, nous avons également amélioré l’analyse du code pour inclure toutes les entrées fournies par l’utilisateur dans la tâche d’initialisation CodeQL. En outre, nous avons développé la prise en charge de CodeQL pour inclure Swift.

Dans boards, nous publions des règles Team Automation en préversion privée. À présent, vous pouvez configurer chaque niveau de backlog pour automatiser l’ouverture et la fermeture/résolution des éléments de travail en fonction de l’état de leurs enfants. Consultez les notes de publication si vous souhaitez vous inscrire dans la préversion privée.

Passez à la liste des fonctionnalités ci-dessous pour en savoir plus sur ces fonctionnalités.

Général

GitHub Advanced Security pour Azure DevOps

Azure Boards

Azure Pipelines

Général

Prise en charge des identités managées et du principal de service pour Azure DevOps désormais en disponibilité générale

La prise en charge des identités managées et des principaux de service Microsoft Entra ID dans Azure DevOps a désormais atteint la disponibilité générale.

Aujourd’hui, de nombreux scénarios d’intégration d’applications s’appuient sur des jetons d’accès personnels (PAT) pour s’intégrer à Azure DevOps. Bien que simples à utiliser, les PAT peuvent facilement être divulguées, ce qui peut permettre aux acteurs malveillants de s’authentifier en tant qu’utilisateurs puissants. Pour empêcher l’accès indésirable, les PAT nécessitent souvent une maintenance fastidieuse via des rotations d’informations d’identification régulières.

Vous pouvez désormais permettre aux applications d’utiliser plutôt des identités managées et des principaux de service pour s’intégrer à Azure DevOps via des API REST et des bibliothèques clientes. Cette fonctionnalité hautement demandée offre aux clients Azure DevOps une alternative plus sécurisée aux PAT. Les identités managées offrent la possibilité pour les applications s’exécutant sur des ressources Azure d’obtenir des jetons Azure AD sans avoir à gérer toutes les informations d’identification.

Les identités managées et les principaux de service peuvent être configurés dans Azure DevOps et accorder des autorisations à des ressources spécifiques (projets, dépôts, pipelines), tout comme les utilisateurs réguliers. Cela permet aux applications qui utilisent des identités managées ou des principaux de service de se connecter à Azure DevOps et d’effectuer des actions au nom d’eux-mêmes, au lieu d’un utilisateur, comme le fait PAT. Teams peut désormais mieux gérer ses services collectivement, au lieu de s’appuyer sur n’importe quel individu pour fournir un jeton pour l’authentification. En savoir plus sur la publication en disponibilité générale dans notre billet de blog public et notre documentation sur les fonctionnalités.

Nouvelles étendues Azure DevOps disponibles pour les applications de flux délégué OAuth d’identité Microsoft

Nous avons ajouté de nouvelles étendues Azure DevOps pour les applications OAuth déléguées sur la plateforme Microsoft Identity, également connue sous le nom d’applications OAuth d’ID Microsoft Entra. Ces nouvelles étendues permettront aux développeurs d’applications d’annoncer spécifiquement les autorisations qu’ils espèrent demander à l’utilisateur afin d’effectuer des tâches d’application. Cette fonctionnalité hautement demandée permet aux développeurs d’applications de demander uniquement les autorisations dont ils ont besoin pour leur application.

Auparavant, user_impersonation était la seule étendue disponible pour les développeurs d’applications à choisir. Cette étendue donne à l’application un accès complet à toutes les API Azure DevOps, ce qui signifie qu’elle sera en mesure de faire tout ce que l’utilisateur est en mesure de faire dans toutes les organisations auxquelles appartient l’utilisateur. Désormais, avec des étendues plus granulaires disponibles, vous pouvez vous reposer facilement pour que les applications puissent uniquement demander et accéder uniquement à ces API auxquelles les étendues demandées ont accordé l’autorisation d’accès.

En savoir plus sur ces nouvelles étendues dans notre billet de blog public annonce et documentation sur les fonctionnalités.

GitHub Advanced Security pour Azure DevOps

Modifications apportées à la tâche et aux variables d’entrée utilisateur d’analyse du code (CodeQL)

Toutes les entrées fournies par l’utilisateur sont désormais spécifiées dans la tâche d’initialisation CodeQL, qui est chargée de configurer l’environnement d’analyse CodeQL utilisé pour l’analyse du code avec CodeQL « AdvancedSecurity-Codeql-Init@1 ». Pour plus d’informations sur la configuration de GitHub Advanced Security pour Azure DevOps, consultez la documentation sur la configuration de GitHub Advanced Security pour Azure DevOps.

En outre, les entrées utilisateur sont prioritaires sur toutes les valeurs définies par les variables. Par exemple, si vous établissez la variable de langue comme advancedsecurity.codeql.language: Java et par la suite, pendant la phase d’initialisation CodeQL, vous spécifiez la langue comme entrée avec Language: cpp, l’entrée cpp remplacera la variable Java pour la langue. Vérifiez que vos entrées sont configurées avec précision.

La tâche de publication n’est plus nécessaire pour configurer l’analyse du code

Auparavant, lors de la configuration de l’analyse du code, vous deviez inclure la tâche de publication (AdvancedSecurity-Publish@1) dans le pipeline YAML ou le pipeline classique. Avec cette mise à jour, nous avons éliminé la nécessité de la tâche de publication et les résultats sont désormais publiés directement sur le service de sécurité avancé au sein de la tâche d’analyse (AdvancedSecurity-Codeql-Analyze@1).

Vous trouverez ci-dessous la tâche requise pour l’analyse du code.

Screenshot of required code scanning tasks.

Pour plus d’informations, reportez-vous à la documentation de configuration de l’analyse du code.

L’analyse du code CodeQL prend désormais en charge Swift

Nous développons notre prise en charge de l’analyse du code CodeQL pour inclure Swift ! Cela signifie que les développeurs travaillant sur des bibliothèques et des applications Swift pour les plateformes Apple peuvent désormais tirer parti de notre analyse de sécurité de code de premier plan. Nos fonctionnalités actuelles incluent la détection de problèmes tels que l’injection de chemin d’accès, les extractions de vues web risquées, diverses utilisations de chiffrement et d’autres formes de gestion ou de traitement non filtré des données utilisateur non filtrées.

Swift fait désormais partie de notre liste de langages de programmation pris en charge, qui inclut C/C++, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, C# et Go. Au total, ces langages nous permettent d’effectuer près de 400 case activée complètes sur votre code, tout en conservant un faible taux de faux positifs et garantissant une haute précision.

Pour plus d’informations sur la configuration de GitHub Advanced Security pour Azure DevOps, consultez la documentation sur la configuration de GitHub Advanced Security pour Azure DevOps pour vos dépôts.

Azure Boards

Règles Team Automation (préversion privée)

Important

Depuis le 11/9/2023, nous ne prenons aucune nouvelle organisation dans la préversion privée. Nous avons eu de bons commentaires avec seulement quelques bogues mineurs à résoudre. Nous travaillons sur ces bogues et publierons la fonctionnalité à tous dans les prochains sprints.

Vous pouvez maintenant configurer chaque niveau de backlog pour automatiser l’ouverture et la fermeture/résolution des éléments de travail en fonction de l’état de leurs enfants. Il existe deux scénarios principaux que nous essayons de résoudre.

  1. Lorsqu’un seul élément enfant est activé, activez le parent.

  2. Lorsque tous les éléments enfants sont fermés, fermez le parent (ou résolvez-le).

Pour activer ces paramètres, vous cliquez sur la configuration au niveau du backlog pour votre équipe. Accédez ensuite à l’onglet Règles Automation > pour afficher les deux règles différentes que vous pouvez appliquer à votre backlog. Chaque niveau de backlog (exigences, fonctionnalités, épopées) peut être configuré pour la façon dont votre équipe souhaite fonctionner.

Screenshots of Team Settings.

Par exemple, quand une tâche enfant est définie sur Active, rendez l’article utilisateur parent actif. Ensuite, lorsque toutes les tâches sont terminées, définissez l’article utilisateur sur Fermé.

Gif to demo Team automation rules.

Si vous souhaitez vous inscrire dans la préversion privée, envoyez-nous un e-mail avec le nom de votre organisation (dev.azure.com/{nom de l’organisation}). Veuillez comprendre que nous allons limiter le nombre d’organisations dans la préversion. Notre espoir est d’obtenir quelques organisations pour fournir des commentaires, puis libérer à tout le monde dans les sprints de 2 à 3.

Les fonctionnalités ont été classées par ordre de priorité en fonction de ce ticket de suggestion de la Communauté des développeurs.

Remarque

Cette fonctionnalité sera disponible uniquement avec la préversion de New Boards Hubs.

Azure Pipelines

Les journaux de pipeline contiennent désormais l’utilisation des ressources

Les journaux de pipeline Azure peuvent maintenant capturer les métriques d’utilisation des ressources, telles que la mémoire, l’utilisation du processeur et l’espace disque disponible. Les journaux incluent également les ressources utilisées par l’agent de pipeline et les processus enfants, notamment les tâches exécutées dans un travail.

Screenshot of logs including resources used by the pipeline.

Si vous pensez que votre travail de pipeline peut rencontrer des contraintes de ressources, activez les journaux détaillés pour que les informations d’utilisation des ressources soient injectées dans les journaux de pipeline. Ils fonctionnent sur n’importe quel agent, indépendamment du modèle d’hébergement.

L’agent Azure Pipelines prend désormais en charge Alpine Linux

L’agent de pipeline v3.227 prend désormais en charge les versions Alpine Linux 3.13 et ultérieures. Alpine Linux est une image populaire pour conteneur (base). Vous trouverez l’agent sur la page des versions. Les versions Alpine Linux de l’agent ont un préfixe vsts-agent-linux-musl , par exemple vsts-agent-linux-musl-x64-3.227.1.tar.gz.

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Screenshot Make a suggestion.

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Rajesh Ramamurthy