Schließen von Warnungen zur Abhängigkeitsüberprüfung in Advanced Security

  • Artikel

Die Abhängigkeitsüberprüfung in Advanced Security erkennt die in Ihrem Quellcode verwendeten Open Source-Komponenten und identifiziert, ob es zugeordnete Sicherheitsrisiken gibt. Alle gefundenen Sicherheitsrisiken aus Open-Source-Komponenten werden als Warnung gekennzeichnet. Mit diesem Update können Sie Benachrichtigungen zur Abhängigkeitsüberprüfung in Advanced Security schließen, von denen Sie glauben, dass es sich um ein falsch positives oder akzeptables Risiko handelt.

In Azure Repos wurde das Standardverhalten geändert, um die Berechtigung "Richtlinien bearbeiten" beim Erstellen einer neuen Verzweigung zu entfernen.

Schauen Sie sich die Versionshinweise an, um mehr über diese Features zu erfahren.

GitHub Advanced Security für Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Allgemein

Verwerfen von Warnungen für Abhängigkeitsüberprüfungswarnungen in Advanced Security

Sie können jetzt alle Warnungen zum Überprüfen von Abhängigkeiten schließen, die Sie als falsch positiv oder akzeptabel eingestuft haben. Dies sind die gleichen Kündigungsoptionen für geheime Überprüfungen und Codeüberprüfungswarnungen in Advanced Security, die Sie derzeit verwenden können.

Dismiss a dependency scanning alert

Beachten Sie, dass Sie möglicherweise die Erkennungspipeline mit der Abhängigkeitsscanaufgabe erneut ausführen müssen, und stellen Sie sicher, dass Sie über die Advanced Security: dismiss alerts Berechtigungen verfügen, um diese Warnungen zu schließen.

Weitere Informationen zu Warnungsentlassungen finden Sie unter Schließen von Warnungsüberprüfungswarnungen.

Azure Boards

Wir haben eine kleine Verbesserung vorgenommen, um die Arbeitsaufgaben-URL aus mehreren Bereichen in Azure Boards zu kopieren. Einfacheres Abrufen des direkten Links zu einer bestimmten Arbeitsaufgabe.

Image for copy link context menu item on backlog

Der Link zum Kopieren wurde den Kontextmenüs im Arbeitsaufgabenformular, dem Backlog und dem Aufgabenrückstand hinzugefügt.

Hinweis

Dieses Feature ist nur in der Vorschauversion von New Boards Hubs verfügbar.

Azure Pipelines

Kubernetes-Aufgaben unterstützen jetzt Kubelogin

Wir haben die Aufgaben KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 und AzureFunctionOnKubernetes@1 aktualisiert, um Kubelogin zu unterstützen. Dadurch können Sie Azure Kubernetes Service (AKS) als Ziel verwenden, der mit Azure Active Directory-Integration konfiguriert ist.

Kubelogin ist nicht auf gehosteten Images vorinstalliert. Um sicherzustellen, dass oben Erwähnung ed Tasks Kubelogin verwenden, installieren Sie sie, indem Sie die KubeloginInstaller@0 Aufgabe vor dem Vorgang einfügen, der davon abhängt:

 - task: KubeloginInstaller@0

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

Verbesserungen an Genehmigungen REST-API

Genehmigungen erhöhen sie die Sicherheit Ihrer YAML-Pipeline, indem Sie die Möglichkeit erhalten, eine Bereitstellung für die Produktion manuell zu überprüfen. Wir haben die Genehmigungen Abfrage-REST-API aktualisiert, um die Leistung zu verbessern. Jetzt:

  • Sie müssen keine Liste von approvalIdn angeben. Alle Parameter sind jetzt optional.
  • Kann eine Liste von userIdn angeben, um die Liste der Genehmigungen abzurufen, die für diese Benutzer ausstehen. Derzeit gibt die REST-API die Liste der Genehmigungen zurück, für die die Benutzer explizit als Genehmigende zugewiesen werden.
  • Kann die state zurückzugebenden Genehmigungen angeben, pendingz. B. .

Hier ist ein Beispiel: Gibt zurück. GET https://dev.azure.com/fabrikamfiber/fabrikam-chat/_apis/pipelines/approvals?api-version=7.1-preview.1&userId=47acd774-9773-6c31-bbb6-5a0585695d19&state=pending

{
    "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"
                }
            }
        }
    ]
}

Deaktivieren einer Prüfung

Wir haben Debuggingprüfungen weniger mühsam durchgeführt. Manchmal funktioniert eine Aufruf-Azure-Funktion oder die REST-API-Überprüfung nicht ordnungsgemäß, und Sie müssen sie beheben. Zuvor mussten Sie solche Überprüfungen löschen, um zu verhindern, dass sie eine Bereitstellung versehentlich blockieren. Nachdem Sie die Prüfung behoben haben, mussten Sie sie wieder hinzufügen und richtig konfigurieren, um sicherzustellen, dass alle erforderlichen Header festgelegt sind oder die Abfrageparameter korrekt sind. Das ist mühsam.

Jetzt können Sie einfach eine Überprüfung deaktivieren. Die deaktivierte Überprüfung wird in nachfolgenden Überprüfungssuite-Auswertungen nicht ausgeführt.

Disable a check image.

Nachdem Sie die fehlerhafte Überprüfung behoben haben, können Sie sie einfach aktivieren.

Enable a check image.

Updates für YAML-Cron-Zeitpläne

In YAML-Pipelines können Sie geplante Trigger mithilfe der cron YAML-Eigenschaft definieren.

Wir haben die Funktionsweise der batch-Eigenschaft aktualisiert. Kurz gesagt: Wenn Sie batch auf true festlegen, wird der Cronzeitplan nicht ausgeführt, wenn eine andere geplante Pipelineausführung aktuell ausgeführt wird. Dies ist unabhängig von der Version des Pipelinerepositorys.

In der folgenden Tabelle wird beschrieben, wie always und batch interagieren.

Immer Batch Verhalten
false false Pipeline wird nur ausgeführt, wenn eine Änderung im Hinblick auf den letzten erfolgreichen geplanten Pipelinelauf erfolgt
false true Pipeline wird nur ausgeführt, wenn es eine Änderung im Hinblick auf den letzten erfolgreichen geplanten Pipelinelauf gibt und keine laufenden geplanten Pipelineausführungen ausgeführt werden.
true false Die Pipeline wird gemäß dem Cron-Zeitplan ausgeführt.
true true Die Pipeline wird gemäß dem Cron-Zeitplan ausgeführt.

Angenommen always: false und batch: true. Angenommen, es gibt einen Cron-Zeitplan, der angibt, dass die Pipeline alle 5 Minuten ausgeführt werden soll. Stellen Sie sich vor, es gibt einen neuen Commit. Innerhalb von 5 Minuten beginnt die Pipeline mit der geplanten Ausführung. Stellen Sie sich vor, dass eine Pipelineausführung 30 Minuten dauert. Innerhalb dieser 30 Minuten findet unabhängig von der Anzahl der Commits keine geplante Ausführung statt. Die nächste geplante Ausführung erfolgt erst nach Abschluss der aktuellen geplanten Ausführung.

Ihre YAML-Pipeline kann mehrere cron-Zeitpläne enthalten, und Sie möchten, dass Ihre Pipeline unterschiedliche Phasen/Aufträge basierend auf dem Terminplan ausführt. Beispielsweise haben Sie einen nächtlichen Build und einen wöchentlichen Build, und Sie wünschen, dass während des wöchentlichen Builds Ihre Pipeline weitere Statistiken sammelt.

Wir ermöglichen dies durch Einführung einer neuen vordefinierten Systemvariable, Build.CronSchedule.DisplayName die die displayName Eigenschaft eines Cron-Zeitplans enthält.

Neue Umschaltfläche zum Steuern der Erstellung klassischer Pipelines

Im letzten Jahr haben wir eine Pipelines-Konfigurationseinstellung gestartet, um die Erstellung klassischer Build- und Releasepipelines zu deaktivieren.

Als Reaktion auf Ihr Feedback haben wir den anfänglichen Umschalter in zwei unterteilt: eine für klassische Buildpipelinen und eine für klassische Releasepipelinen, Bereitstellungsgruppen und Aufgabengruppen.

Disable creation

Wenn ihre Organisation die Disable creation of classic build and release pipelines Umschaltfläche aktiviert hat, sind beide neuen Umschaltflächen aktiviert. Wenn der ursprüngliche Umschalter deaktiviert ist, sind beide neuen Umschaltflächen deaktiviert.

Azure Repos

Entfernen der Berechtigung "Richtlinien bearbeiten" für Zweigstellenersteller

Wenn Sie zuvor eine neue Verzweigung erstellt haben, erhalten Sie die Berechtigung zum Bearbeiten von Richtlinien für diese Verzweigung. Mit diesem Update ändern wir das Standardverhalten so, dass diese Berechtigung nicht erteilt wird, auch dann nicht, wenn die Einstellung „Berechtigungsverwaltung“ für das Repository aktiviert ist.

Permission management image.

Ihnen muss die Berechtigung „Richtlinien bearbeiten“ explizit (entweder manuell oder über die REST-API) durch Vererbung von Sicherheitsberechtigungen oder durch eine Gruppenmitgliedschaft gewährt werden.

Nächste Schritte

Hinweis

Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Navigieren Sie zu Azure DevOps.

Senden von Feedback

Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Make a suggestion

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Silviu Andrica