Freigeben über


Stärkung der Sicherheits- und Repositoryintegration

Mit diesem Update verbessern wir die Sicherheit und Authentifizierung in Azure DevOps. Überlappende Geheimnisse für Azure DevOps OAuth sorgen für eine nahtlose Rotation von Geheimnissen, während GitHub Advanced Security eine bessere Filterung der Sicherheitsübersichtsseite bietet. Das stellt sicher, dass bei der Veröffentlichung in mehreren Repositorys Warnungen zu Abhängigkeiten und Code-Scans ordnungsgemäß weitergeleitet werden.

Zu den gehosteten Imageupdates in Azure Pipelines gehören Ubuntu-24.04, Windows 2025 und mac-OS 15 Sequoia, die eine sicherere und zuverlässigere Erfahrung gewährleisten.

Weitere Informationen finden Sie in den Versionshinweisen.

Allgemein

GitHub Advanced Security für Azure DevOps

Azure-Pipelines

Testpläne

Allgemein

Überlappende geheime Schlüssel für Azure DevOps OAuth

Wir freuen uns, die neue Funktion überlappende Geheimnisse in Azure DevOps OAuth einzuführen, die zur Verbesserung der Sicherheit entwickelt wurde und Geheimnisrotationen optimiert. Mit diesem Feature können Sie Ihrem OAuth-Client einen neuen geheimen Schlüssel hinzufügen, während die vorherige weiterhin aktiv bleibt, um einen kontinuierlichen Betrieb Ihrer Anwendungen sicherzustellen. Sie können diese Geheimnisse programmatisch über die API oder über die Benutzeroberfläche der Seite der Visual Studio-App verwalten.

Im Rahmen fortlaufender Sicherheitsverbesserungen ist Azure DevOps OAuth ab 2026 zur Ausmusterung vorgesehen. Wir empfehlen Ihnen, zu Microsoft Entra ID OAuth für verbesserte Sicherheitsfeatures und langfristige Investitionen zu migrieren. In der Zwischenzeit empfehlen wir, Ihre Geheimnisse regelmäßig mit unserer neuen Funktion für überlappende Geheimnisse zu aktualisieren.

Abschaffung der Statistiktags für Sprachen auf der Projektzusammenfassungsseite

In den kommenden Wochen werden wir die Sprachen-Statistik-Tags von der Seite "Projektzusammenfassung" entfernen. Durch das Entfernen dieser Tags wird die Leistung optimiert, was zu schnelleren Ladezeiten und einer reaktionsfähigen Benutzeroberfläche führt.

Das Update erfolgt automatisch, ohne dass eine Aktion erforderlich ist.

Erlaubnis für Lieferpläne hinzugefügt

Als Teil unserer kontinuierlichen Sicherheitsverbesserungen haben wir eine neue Berechtigung auf Projektebene " Übermittlungspläne verwalten" eingeführt. Diese Änderung wurde implementiert, um unbeabsichtigten Lese-/Schreibzugriff für Benutzer in der Gruppe "Leser" zu verhindern.

GitHub Advanced Security für Azure DevOps

Sicherheitsübersichtsrisikoseite mit neuen Spalten und Filteroptionen erweitert

Unter der Registerkarte Risiko finden Sie neu hinzugefügte Spalten, die neue, feste und verworfene Sicherheitswarnungen in Ihrer Organisation anzeigen. Wir haben Filteroptionen hinzugefügt, um Ergebnisse nach Projekt, Tool (geheime Schlüssel, Abhängigkeiten oder Codeüberprüfungsergebnisse) und einen zeitbasierten Filter zum Definieren von Suchgrenzen zu verfeinern.

Darüber hinaus fügt das Anwenden eines Filters einen URL-Abfrageparameter hinzu, sodass Sie die vorab gefilterte Ansicht für andere Personen in Ihrer Organisation freigeben können.

Multi-Repository-Veröffentlichungsszenarien, die für GitHub Advanced Security für Azure DevOps unterstützt werden

Als zuvor eine Pipelinedefinition in einem Repository gespeichert wurde und der quellcode, der von GitHub Advanced Security gescannt werden soll, in einer anderen war, wurden Die Ergebnisse verarbeitet und an das falsche Repository übermittelt. Anstatt Warnungen mit dem Quellcode im Repository zu veröffentlichen, wurden sie im Repository angezeigt, in dem die Pipeline definiert wurde.

Jetzt leiten sowohl Abhängigkeitsscans als auch Codeüberprüfung Warnungen ordnungsgemäß an das Repository weiter, das den gescannten Quellcode in Szenarien mit mehreren Repositorys enthält.

Um diese Funktion zu aktivieren, legen Sie die Pipeline-Umgebungsvariable advancedsecurity.publish.repository.infer: true so fest, dass das veröffentlichende Repository vom Repository im Arbeitsverzeichnis inferiert wird.

Wenn Sie ein Repository nicht explizit auschecken oder einen Alias zum Auschecken Ihres Repositorys verwenden, verwenden Sie stattdessen die Variable advancedsecurity.publish.repository: $[ convertToJson(resources.repositories['YourRepositoryAlias']) ].

YAML-Codeausschnitt:

  trigger:
  - main

resources:
  repositories:
    - repository: BicepGoat
      type: git
      name: BicepGoat
      ref: refs/heads/main
      trigger:
        - main

jobs:
  # Explicit - `advancedsecurity.publish.repository` explicitly defines the repository to submit SARIF to.
  - job: "AdvancedSecurityCodeScanningExplicit"
    displayName: "🛡 Infrastructure-as-Code Scanning (Explicit)"
    variables:
      advancedsecurity.publish.repository: $[ convertToJson(resources.repositories['BicepGoat']) ]
    steps:
      - checkout: BicepGoat
      - task: TemplateAnalyzerSarif@1
        displayName: Scan with Template Analyzer
      - task: AdvancedSecurity-Publish@1
        displayName: Publish to IaC Scanning Results to Advanced Security


  # Infer - `advancedsecurity.publish.repository.infer` specifies that the `AdvancedSecurity-Publish` must
  # infer repository to submit SARIF to from the working directory on the build agent.
  - job: "AdvancedSecurityCodeScanningInfer"
    displayName: "🛡 Infrastructure-as-Code Scanning (Infer)"
    variables:
      advancedsecurity.publish.repository.infer: true
    steps:
      - checkout: BicepGoat
      - task: TemplateAnalyzerSarif@1
        displayName: Scan with Template Analyzer
      - task: AdvancedSecurity-Publish@1
        displayName: Publish to IaC Scanning Results to Advanced Security

Diensthaken für GitHub Advanced Security für Azure DevOps-Warnungen (Vorschau)

Sie können jetzt Diensthaken für GitHub Advanced Security-Warnungsereignisse konfigurieren, einschließlich:

  • Neue Warnung erstellt
  • Geänderte Warnungsdaten
  • Warnungszustand geändert

Genau wie bei anderen Repository-Ereignissen können Sie nach Repository und Branch filtern. Speziell für Warnungen können Sie nach Warnungstyp (Abhängigkeiten, Codeüberprüfung oder Geheimschlüssel) und Warnungsschweregrad filtern.

Um an der Vorschau teilzunehmen, füllen Sie das Vorschau-Interessenformular aus oder senden Sie uns eine E-Mail!

pnpm v9-Unterstützung kommt zu GitHub Advanced Security für Azure DevOps-Abhängigkeitsscans

Mit dem Erreichen des Endes der Lebensdauer von pnpm v8 Ende April wird das nächste Update zur Abhängigkeitsprüfung pnpm v9 unterstützen. Dieses Update reagiert auf Ihre Developer Community Anforderung für den pnpm v9-Support.

Azure-Pipelines

Gehostete Bildupdates

Wir werden Updates einführen, um die gehosteten Agents von Azure Pipelines sicher und aktuell zu halten. Diese Updates umfassen die neue Unterstützung für Ubuntu-24.04, Windows 2025-Images und macOS-15 Sequoia, während ältere Images wie Ubuntu-20.04 und Windows Server 2019 eingestellt werden.

Weitere Details finden Sie in unserem Blogbeitrag.

macOS-15 Sequoia ist allgemein verfügbar

Das image macOS-15 wird ab dem 1. April auf von Azure Pipelines gehosteten Agents verfügbar sein. Um dieses Bild zu verwenden, aktualisieren Sie Ihre YAML-Datei so, dass sie vmImage:'macos-15'enthält:

- job: macOS15
  pool:
    vmImage: 'macOS-15'
  steps:
  - bash: |
      echo Hello from macOS Sequoia
      sw_vers

Installierte MacOS-15-Software finden Sie unter Imagekonfiguration.

Das Image macOS-14 wird weiterhin verwendet, wenn macOS-latest angegeben wird. Wir werden macOS-latest im April auf die Verwendung von macOS-15 aktualisieren.

Windows-2025-Image ist in der Vorschau verfügbar

Das windows-2025-Image ist jetzt in der Vorschauversion für von Azure Pipelines gehostete Agents verfügbar. Um dieses Bild zu verwenden, aktualisieren Sie Ihre YAML-Datei so, dass sie vmImage:'windows-2025'enthält:

- job: win2025
  pool:
    vmImage: 'windows-2025'
  steps:
  - pwsh: |
      Write-Host "(Get-ComputerInfo).WindowsProductName"
      Get-ComputerInfo | Select-Object WindowsProductName
      Write-Host "`$PSVersionTable.OS"
      $PSVersionTable.OS

Informationen zur installierten Windows Server 2025-Software finden Sie unter Imagekonfiguration.

Das neueste Ubuntu-Pipelineimage wird mit Ubuntu-24.04 eingeführt

In den kommenden Wochen werden Pipelineaufträge, die ubuntu-latest spezifizieren, ubuntu-24.04 anstelle von ubuntu-22.04 verwenden.

Anleitungen zu Aufgaben, die Tools verwenden, die sich nicht mehr auf dem bild ubuntu-24.04 befinden, finden Sie in unserem Blogbeitrag. Um Ubuntu 22.04 weiterhin zu verwenden, verwenden Sie die ubuntu-22.04 Bildbezeichnung:

- job: ubuntu2404
  pool:
    vmImage: 'ubuntu-24.04'
  steps:
  - bash: |
      echo Hello from Ubuntu 24.04
      lsb_release -d
  - pwsh: |
      Write-Host "`$PSVersionTable.OS"
      $PSVersionTable.OS

Das Ubuntu-20.04-Pipelineimage ist veraltet und wird am 1. April eingestellt.

Wir stellen die Unterstützung für das Ubuntu 20.04-Image in Azure Pipelines ein, da der Support bald endet. Den Einstellungsplan mit dem Zeitplan für Brownouteinschränkungen finden Sie in unserem Blogbeitrag.

Workload-Identitätsverbund verwendet Entra-Aussteller

Vor knapp einem Jahr haben wir den Workload-Identitätsverbund allgemein verfügbar gemacht. Mithilfe des Workload-Identitätsverbunds können Sie eine Dienstverbindung ohne einen geheimen Schlüssel konfigurieren. Die Identität (App-Registrierung, verwaltete Identität), die die Dienstverbindung untermauert, kann nur für den vorgesehenen Zweck verwendet werden: die in den Verbundanmeldeinformationen der Identität konfigurierte Dienstverbindung.

Wir ändern nun das Format der Verbundanmeldeinformationen für neue Azure- und Docker-Dienstverbindungen. Vorhandene Dienstverbindungen funktionieren wie zuvor.

  Azure DevOps-Aussteller Entra-Aussteller (neue Dienstverbindungen)
Emittent https://vstoken.dev.azure.com/<organization id> https://login.microsoftonline.com/<Entra tenant id>/v2.0
Betreff sc://<organization name>/<project name>/<service connection name> <entra prefix>/sc/<organization id>/<service connection id>

Es gibt keine Änderung der Konfiguration, und die Art und Weise, wie Token abgerufen werden, bleibt gleich. Pipelineaufgaben müssen nicht aktualisiert werden und funktionieren wie zuvor.

Die Schritte zum Erstellen einer Dienstverbindung ändern sich nicht, und in den meisten Fällen ist der neue Aussteller nicht sichtbar. Wenn eine Azure-Dienstverbindung manuell konfiguriert wird, werden die neuen Verbundanmeldeinformationen angezeigt:

Kopieren Sie diese Werte wie zuvor, wenn Sie eine Verbunds-Anmeldeinformation für eine App-Registrierung oder eine verwaltete Identität erstellen.

Automatisierung

Verwenden Sie beim Erstellen einer Dienstverbindung in der Automatisierung mit der REST-API-die von der API zurückgegebenen Verbundanmeldeinformationen:

authorization.parameters.workloadIdentityFederationIssuer
authorization.parameters.workloadIdentityFederationSubject

Ebenso gibt die azuredevops_serviceendpoint_azurerm Ressource beim Erstellen einer Dienstverbindung mit dem Terraform azuredevops-Anbieter workload_identity_federation_issuer und workload_identity_federation_subject Attribute zurück.

Weitere Informationen

Gradle@4-Aufgabe

Es wurde eine neue Gradle@4 Aufgabe mit Unterstützung für Gradle 8.0-erstellt. Die integrierte Code Coverage-Option wird ab Gradle aus der Gradle@4-Aufgabe entfernt. So verwenden Sie Code Coverage mit Gradle in Ihrer Pipeline:

Die Konfiguration der SonarQube-Analyse wurde in die Erweiterungen SonarQube oder SonarCloud in der Aufgabe Prepare Analysis Configurationverschoben.

Identität des Benutzers, der die Ausführung einer Phase angefordert hat

Um die Sicherheit Ihrer YAML-Pipelines zu verbessern, sollten Sie wissen, wer eine Phase zur Ausführung angefordert hat. Um diese Notwendigkeit zu beheben, wurden zwei neue vordefinierte Variablen hinzugefügt, Build.StageRequestedBy und Build.StageRequestedById. Diese Variablen ähneln den Build.RequestedFor und Build.RequestedForId Variablen, aber für eine Phase, nicht für einen Lauf.

Wenn ein Benutzer einen Benutzer explizit auslöst, z. B. bei einer manuell ausgelösten Phase oder beim erneuten Ausführen einer Phase, wird seine Identität verwendet, um die beiden Variablen auszufüllen.

Testpläne

Verbesserungen für Code-Coverage-Ergebnisse v2-Aufgabe

Mit dieser Version werden mehrere Verbesserungen an der v2-Aufgabe hinzugefügt:

  • Erweiterte Unterstützung für verschiedene Codeabdeckungsformate, einschließlich .coverage,.covx,.covb,.cjson,.xml,.lcov und pycov1.
  • Generierung einer umfassenden cjson-Datei (und eines Codeabdeckungsberichts), die detaillierte Codeabdeckungsinformationen wie Dateinamen, Zeilen abgedeckt/nicht abgedeckt usw. enthält.
  • Unterstützung für Diff-Coverage (PR-Coverage): v2 kann PR-Kommentare zur Diff-Coverage für mehrere Sprachen innerhalb derselben Pipeline generieren.
  • v2-Aufgabe unterstützt jetzt die Aufgabe "Build Quality Check", die in v1-Aufgaben nicht unterstützt wurde.

Exportieren von Testfällen mit benutzerdefinierten Spalten in XLSX

Sie können jetzt Testfälle mit benutzerdefinierten Spalten in XLSX exportieren. Basierend auf Ihrem Feedback unterstützt Testpläne das Exportieren von Testfällen mit benutzerdefinierten Spalten, wodurch Sie mehr Flexibilität und Kontrolle über die daten erhalten, die Sie freigeben und analysieren. Diese Erweiterung hilft Ihnen, Exporte an Ihre Bedürfnisse anzupassen und sicherzustellen, dass die informationen, die Sie exportieren, relevant und umsetzbar sind.

Nächste Schritte

Hinweis

Diese Features werden in den nächsten zwei bis drei Wochen bereitgestellt.

Gehen Sie zu Azure DevOps und schauen Sie sich an.

Zu Azure DevOps wechseln

So geben Sie Feedback

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

Einen Vorschlag machen

Sie können auch die Community auf Stack Overflowum Ratschläge bitten und Ihre Fragen beantworten lassen.

Danke

Silviu Andrica