Partager via

Ignorer les alertes d’analyse des dépendances dans Advanced Security

  • Article

L’analyse des dépendances dans Advanced Security détecte les composants code source ouvert utilisés dans votre code source et identifie s’il existe des vulnérabilités associées. Toutes les vulnérabilités détectées des composants open source sont signalées comme une alerte. Avec cette mise à jour, vous pouvez ignorer les alertes d’analyse des dépendances dans Advanced Security que vous pensez être un risque faux positif ou acceptable.

Dans Azure Repos, nous avons modifié le comportement par défaut pour supprimer l’autorisation « Modifier les stratégies » lors de la création d’une branche.

Consultez les notes de publication pour en savoir plus sur ces fonctionnalités.

GitHub Advanced Security pour Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Général

Exclusions d’alertes pour les alertes de balayage des dépendances dans Advanced Security

Vous pouvez désormais ignorer les alertes d’analyse des dépendances que vous pensez être un risque faux positif ou acceptable. Il s’agit des mêmes options de licenciement pour l’analyse secrète et les alertes d’analyse de code dans Advanced Security que vous pouvez utiliser actuellement.

Ignorer une alerte d’analyse des dépendances

Notez que vous devrez peut-être réexécuter le pipeline de détection avec la tâche d’analyse des dépendances, ainsi que vérifier que vous disposez Advanced Security: dismiss alerts des autorisations nécessaires pour ignorer ces alertes.

Pour en savoir plus sur les licenciements d’alerte, consultez Ignorer les alertes d’analyse des dépendances.

Azure Boards

Nous avons apporté une petite amélioration pour copier l’URL de l’élément de travail à partir de plusieurs domaines dans Azure Boards. Faciliter l’obtention du lien direct vers un élément de travail spécifique.

Image de l’élément de menu contextuel copier le lien dans le backlog

Le lien copier a été ajouté aux menus contextuels du formulaire d’élément de travail, du backlog et du backlog des tâches.

Remarque

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

Azure Pipelines

Les tâches Kubernetes prennent désormais en charge kubelogin

Nous avons mis à jour les tâches KubernetesManifest@1, HelmDeploy@0, Kubernetes@1 et AzureFunctionOnKubernetes@1 pour prendre en charge kubelogin. Cela vous permet de cibler Azure Kubernetes Service (AKS) configuré avec l’intégration Azure Active Directory.

Kubelogin n’est pas préinstallé sur les images hébergées. Pour vous assurer que les tâches mentionnées ci-dessus utilisent kubelogin, installez-la en insérant la tâche KubeloginInstaller@0 avant la tâche qui dépend de celle-ci :

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Améliorations apportées à l’API REST Approbations

Les approbations augmentent la sécurité de votre pipeline YAML en vous donnant la possibilité de passer en revue manuellement un déploiement en production. Nous avons mis à jour l’API REST de requête d’approbations pour la rendre plus puissante. Maintenant, vous :

  • N’avez pas besoin de spécifier une liste de approvalIds. Tous les paramètres sont désormais facultatifs.
  • Peut spécifier une liste de userIds pour récupérer la liste des approbations en attente sur ces utilisateurs. Actuellement, l’API REST retourne la liste des approbations pour lesquelles les utilisateurs sont explicitement affectés en tant qu’approbateurs.
  • Peut spécifier les state approbations à renvoyer, par exemple pending.

Voici un exemple : GET https://dev.azure.com/fabrikamfiber/fabrikam-chat/_apis/pipelines/approvals?api-version=7.1-preview.1&userId=00aa00aa-bb11-cc22-dd33-44ee44ee44ee&state=pending retourne

{
    "count": 2,
    "value":
    [
        {
            "id": "87436c03-69a3-42c7-b5c2-6abfe049ee4c",
            "steps": [],
            "status": "pending",
            "createdOn": "2023-06-27T13:58:07.417Z",
            "lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers": [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/87436c03-69a3-42c7-b5c2-6abfe049ee4c"
                }
            }
        },
        {
            "id": "2549baca-104c-4a6f-b05f-bdc4065a53b7",
            "steps": [],
            "status": "pending",
            "createdOn": "2023-06-27T13:58:07.417Z",
            "lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers": [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/2549baca-104c-4a6f-b05f-bdc4065a53b7"
                }
            }
        }
    ]
}

Désactiver une vérification

Nous avons effectué des vérifications de débogage moins fastidieuses. Parfois, une vérification de la fonction Azure invoke ou de l’API REST Invoke ne fonctionne pas correctement, et vous devez la corriger. Auparavant, vous deviez supprimer ces vérifications pour les empêcher de bloquer de manière erronée un déploiement. Une fois que vous avez corrigé la vérification, vous deviez l’ajouter et la configurer correctement, en vous assurant que tous les en-têtes requis sont définis ou que les paramètres de requête sont corrects. C’est fastidieux.

Maintenant, vous pouvez simplement désactiver une vérification. La vérification désactivée ne s’exécutera pas dans les évaluations ultérieures de la suite de vérification.

Désactivez une image de vérification.

Une fois que vous avez corrigé la vérification erronée, vous pouvez simplement l’activer.

Activez une image de vérification.

Mises à jour des planifications yaML cron

Dans les pipelines YAML, vous pouvez définir des déclencheurs planifiés à l’aide de la cron propriété YAML.

Nous avons mis à jour le fonctionnement de la propriété batch. En résumé, si vous définissez batchsur true, la planification cron ne s’exécutera pas si une autre exécution de pipeline planifiée est en cours. Cela, quelle que soit la version du dépôt de pipeline.

Les tableaux suivants décrivent la manière dont always et batch interagissent.

Toujours Batch Comportement
false false Exécutions de pipelines uniquement s’il existe une modification par rapport à la dernière exécution planifiée réussie du pipeline
false true Exécutions de pipelines uniquement s’il existe une modification par rapport à la dernière exécution planifiée réussie du pipeline et qu’il n’y a pas d’exécution planifiée du pipeline en cours
true false Exécutions de pipeline en fonction de la planification cron
true true Exécutions de pipeline en fonction de la planification cron

Par exemple, supposons always: false et batch: true. Supposons qu’il existe une planification cron qui spécifie que le pipeline doit s’exécuter toutes les 5 minutes. Imaginez qu’il y a une nouvelle validation. Dans les 5 minutes, le pipeline démarre son exécution planifiée. Imaginez qu’une exécution de pipeline prend 30 minutes. Dans ces 30 minutes, aucune exécution planifiée n’a lieu, quel que soit le nombre de validations. L’exécution planifiée suivante se produit uniquement une fois l’exécution planifiée en cours terminée.

Votre pipeline YAML peut contenir plusieurs planifications cron et vous souhaiterez peut-être que votre pipeline exécute différentes étapes/travaux en fonction des exécutions de planification cron. Par exemple, vous disposez d’une build nocturne et d’une build hebdomadaire, et vous souhaitez que pendant la génération hebdomadaire de votre pipeline collecte plus de statistiques.

Nous rendons cela possible en introduisant une nouvelle variable système prédéfinie nommée Build.CronSchedule.DisplayName qui contient la displayName propriété d’une planification cron.

Nouvelles bascules pour contrôler la création de pipelines classiques

L’année dernière, nous avons lancé un paramètre de configuration Pipelines pour désactiver la création de pipelines de build et de mise en production classiques.

En réponse à vos commentaires, nous avons divisé le bouton bascule initial en deux : un pour les pipelines de build classiques et un pour les pipelines de mise en production classiques, les groupes de déploiement et les groupes de tâches.

Désactiver la création

Si votre organisation a la Disable creation of classic build and release pipelines bascule activée, les deux bascules sont activées. Si le bouton bascule d’origine est désactivé, les deux nouvelles bascules sont désactivées.

Azure Repos

Suppression de l’autorisation « Modifier les stratégies » pour le créateur de branche

Auparavant, lorsque vous avez créé une nouvelle branche, nous vous accordons l’autorisation de modifier des stratégies sur cette branche. Avec cette mise à jour, nous modifions le comportement par défaut pour ne pas accorder cette autorisation même si le paramètre « Gestion des autorisations » est activé pour le référentiel.

Image de gestion des autorisations.

Vous aurez besoin de l’autorisation « Modifier les stratégies » accordée explicitement (manuellement ou via l’API REST) par héritage des autorisations de sécurité ou via l’appartenance à un groupe.

É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.

Faire une suggestion

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

Merci,

Silviu Andrica