Partager via

Suivi des liens AB# amélioré dans les demandes de tirage GitHub

  • Article

Avec cette mise à jour, les liens AB# apparaissent désormais directement dans la section Développement des demandes de tirage GitHub, tant qu’ils sont inclus dans la description de la demande de tirage. Cette amélioration simplifie l’accès aux éléments de travail liés via l’intégration d’Azure Boards et GitHub.

Nous sommes également heureux d’introduire des outils de surveillance améliorés, offrant une meilleure visibilité sur l’intégrité de votre dépôt et vous aidant à maintenir ses performances plus efficacement !

Pour plus d’informations, consultez les notes de publication.

GitHub Advanced Security pour Azure DevOps

Azure Boards :

Azure Repos

Azure Pipelines

Azure Test Plans :

GitHub Advanced Security pour Azure DevOps

Branches de demande de tirage (pull request) désormais visibles dans le sélecteur de branche Advanced Security

Les branches de demande de tirage ont été précédemment masquées dans le sélecteur de branches, même si l’analyse sur les branches de demande de tirage était possible. À présent, ces branches sont visibles dans le sélecteur de branche de sécurité avancée et peuvent être recherchées.

Capture d’écran des branches de demande d’extraction.

Mises à jour automatiques pour branche par défaut modifications dans Advanced Security

Dans le passé, l’onglet Référentiel Advanced Security n’a pas été automatiquement mis à jour lorsque le branche par défaut modifié, nécessitant une sélection manuelle de la nouvelle branche dans le sélecteur de branche. À présent, l’onglet détecte et affiche automatiquement des alertes pour le branche par défaut nouvellement désigné lors de la visite de la page.

En outre, les mises à jour de la vue d’ensemble de la sécurité reflètent les modifications branche par défaut, bien qu’il peut y avoir un léger délai avant le traitement des résultats de l’alerte mis à jour.

Prise en charge SARIF tierce générique pour Advanced Security

Vous pouvez désormais charger des résultats à partir de votre outil d’analyse tiers pour afficher sous l’onglet Analyse du code de sécurité avancée.

À l’aide d’un outil d’analyse qui publie un fichier SARIF dans le $(Agent.TempDirectory)/.advsec répertoire, est conforme à la norme SARIF 2.1 et exécute advancedSecurity-Publish@1 une fois la tâche chargée les résultats dans l’onglet Analyse du code.

Remarque

Le chemin d’accès au fichier associé à un résultat dans le fichier SARIF doit être accessible à la AdvancedSecurity-Publish@1 tâche exécutée dans l’agent de build.

ID de règle d’alerte désormais intégrés aux empreintes digitales des résultats

Auparavant, les résultats de l’outil tiers avec la même empreinte digitale, le hachage, l’outil et le nom de règle étaient regroupés en une seule alerte, même s’ils avaient des ID de règle différents.

Avec cette mise à jour, les ID de règle sont désormais inclus dans l’empreinte digitale, créant des alertes distinctes pour les résultats avec différents ID de règle, même si d’autres points de données sont identiques. Les alertes existantes seront mises à jour et fractionnées en conséquence.

Ensemble développé de détections d’analyse des secrets

Nous développons l’ensemble des modèles partenaires qui peuvent être détectés avec l’analyse secrète. Cette extension apporte plusieurs modèles de confiance élevés pour les nouveaux types de jetons.

Pour plus d’informations sur les types de modèles de partenaires détectés par GitHub Advanced Security Secret Scan, consultez alertes d’analyse des secrets pour GitHub Advanced Security pour Azure DevOps.

Azure Boards

Dans le cadre de nos améliorations continues apportées à l’intégration d’Azure Boards + GitHub, nous sommes heureux d’introduire une nouvelle fonctionnalité qui simplifie l’affichage des liens AB#. Avec cette mise à jour, les liens AB# apparaissent désormais directement dans la section Développement des demandes de tirage GitHub, ce qui facilite l’accès aux éléments de travail liés sans effectuer de recherches dans des descriptions ou des commentaires.

Capture d’écran des demandes de tirage GitHub.

Ces liens s’affichent uniquement lorsque AB# est inclus dans la description de la demande de tirage. Si vous liez directement à partir d’un élément de travail, ils ne seront pas affichés dans la section Développement. En outre, la suppression du lien AB# de la description le supprime du contrôle développement.

Prise en charge de l’API REST pour la connexion de référentiels GitHub

Nous introduisons de nouveaux points de terminaison d’API REST qui vous permettent d’automatiser l’ajout et la suppression de dépôts GitHub dans vos projets Azure DevOps. En outre, nous avons augmenté la limite de référentiel par connexion de 500 à 2 000 lors de l’utilisation de ces points de terminaison.

Ces points de terminaison sont les suivants :

Nous avons également fourni des exemples de code pour vous aider à commencer.

Supprimer définitivement les pièces jointes

Dans certains cas, la suppression d’une pièce jointe d’un élément de travail peut ne pas résoudre complètement les risques de sécurité, en particulier si le fichier est marqué comme malveillant. Les liens partagés vers la pièce jointe peuvent toujours être accessibles entre d’autres éléments de travail, commentaires ou canaux externes. Pour résoudre ce problème, nous avons ajouté une fonctionnalité qui permet aux utilisateurs disposant des autorisations « Supprimer définitivement les éléments de travail » pour supprimer définitivement les pièces jointes.

SScreenshot de supprimer définitivement les pièces jointes d’élément de travail.

Cette action peut être effectuée à partir de l’onglet Pièces jointes du formulaire d’élément de travail, sous une nouvelle section appelée « Pièces jointes supprimées ». Cette section est visible uniquement aux utilisateurs disposant des autorisations nécessaires pour supprimer définitivement les éléments de travail.

Une fois qu’une pièce jointe est définitivement supprimée, tous les liens associés retournent une erreur « Pièce jointe de fichier n’existe pas ».

Remarque

Cette fonctionnalité est disponible uniquement dans le hub New Boards.

Azure Repos

Nouveau panneau « Intégrité et utilisation » dans le hub de fichiers de dépôt

À mesure que les référentiels Git augmentent, ils accumulent des validations, des objets blob et d’autres données, ce qui peut augmenter la charge sur l’infrastructure Azure DevOps, ce qui a un impact sur les performances et l’expérience utilisateur. La gestion d’un référentiel sain est essentielle pour garantir des performances et une fiabilité cohérentes.

Pour prendre en charge ce problème, nous allons maintenant surveiller plusieurs facteurs tels que la taille du référentiel, la fréquence de validation, le contenu et la structure. Si votre référentiel commence à forcer l’infrastructure, vous pouvez recevoir une notification avec des recommandations d’action corrective. En gérant l’intégrité de votre référentiel, vous pouvez empêcher les interruptions et garantir des opérations fluides.

Pour vérifier l’intégrité de votre référentiel, accédez à Azure Repos, > Files et choisissez « Intégrité et utilisation » dans le menu points de suspension pour accéder au volet d’intégrité et d’utilisation du référentiel.

Capture d’écran de l’intégrité et de l’utilisation.

Azure Pipelines

L’agent Azure Pipeline v4 s’exécute sur .NET 8

L’agent Azure Pipeline v3 utilise actuellement .NET 6, mais avec la fin de vie pour .NET 6 approche, nous mettons à niveau l’agent vers .NET 8. Cette mise à jour sera déployée au cours des prochaines semaines.

Si vous utilisez des agents auto-hébergés sur un système d’exploitation qui n’est pas pris en charge par .NET 8, votre agent n’est pas mis à niveau vers v4. Au lieu de cela, les pipelines s’exécutant sur des systèmes d’exploitation non pris en charge affichent des avertissements dans les journaux de pipeline. Vous pouvez utiliser le script QueryAgentPoolsForCompatibleOS.ps1 pour identifier les agents de pipeline s’exécutant de manière proactive sur des systèmes d’exploitation obsolètes.

Les versions de système d’exploitation suivantes ne seront pas prises en charge par l’agent v4 mis à jour :

  • Alpine Linux 3.13 - 3.16
  • Debian 10
  • Fedora 36 - 38
  • macOS 10 &11
  • openSUSE 15.0 - 15.4
  • Oracle Linux 7
  • Red Hat Enterprise Linux 7
  • SUSE Enterprise Linux 12
  • Ubuntu, 16.04, 18.04
  • Windows 7, 8 et 10 jusqu’à 21H2

Mode aperçu pour la validation des arguments des tâches shell

Les tâches shell telles que Bash@3, BatchScript@1, CmdLine@2 et PowerShell@2 peuvent être protégées contre l’injection de commandes en activant la validation des arguments des tâches shell dans les paramètres de l’organisation ou du projet.

L’activation de la validation des arguments des tâches shell peut interrompre les scripts existants, car l’entrée est rejetée par la validation d’entrée. Par exemple, certains caractères sont considérés comme un séparateur de commandes et rejetés lorsque ce paramètre est activé.

Pour faciliter cette transition, nous avons ajouté un mode d’aperçu. Avec le mode préversion activé, vous recevez des avertissements dans vos journaux d’audit et de pipeline, ce qui vous donne une visibilité sur les problèmes potentiels sans interrompre vos tâches ou flux de travail.

Accédez à l’audit des restrictions de tâche des > paramètres > des paramètres des paramètres > de l’organisation > sur :

Capture d’écran générale de l’activation de l’audit.

Azure Test Plans

Intégration transparente du pipeline de build pour l’exécution de cas de test

Nous avons simplifié le processus d’exécution de cas de test en intégrant en toute transparence les configurations de pipeline de build. Les définitions de build et les ID définis au niveau du plan de test se propagent automatiquement à Web Runner, ce qui élimine la nécessité d’une configuration manuelle à chaque fois. Cette amélioration permet de gagner du temps et d’améliorer l’efficacité, ce qui vous permet de vous concentrer sur des tâches plus critiques.

Gif pour démonstration de l’intégration du pipeline pour l’exécution de cas de test.

Tester et envoyer des commentaires dans Manifest V3 (version Edge)

Nous avons progressivement publié cette mise à niveau dans Chrome, et nous développons maintenant le déploiement vers Edge.

Cette mise à jour passe de notre implémentation de Manifest V2 à V3, conformément à la planification de dépréciation de Google pour Manifest V2. Bien que les principales fonctionnalités de l’extension restent inchangées, la mise à jour améliore la sécurité et les performances.

Pour plus d’informations, consultez notre billet de blog récent sur cette mise à jour. Tester l’extension de commentaires dans le manifeste V3

Étapes suivantes

Remarque

Nous déployons la fonctionnalité. La réception de celle-ci dans votre organisation dépend de différents facteurs et peut arriver ultérieurement si vous ne l’avez pas encore.

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.

Faire une suggestion

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

Merci,

Dan Hellem