Freigeben über

Verbesserungen an geheimen Scanfunktionen und new Board Hub standardmäßig aktiviert

  • Artikel

Wir freuen uns, ihnen mitzuteilen, dass wir eine Sicherheitsübersicht einführen, einen einzigen Bereich der Glasansicht für Ihre Advanced Security-Warnungen und -Aktivierungen, und wir haben auch unsere geheimen Scanfunktionen verbessert, indem wir weitere Partnermuster in GitHub Advanced Security hinzufügen! Dadurch werden die Erkennungsfähigkeiten unserer geheimen Scanfunktion erheblich erhöht, was eine sicherere Umgebung für Ihre Projekte bietet.

Mit diesem Update sind wir in der Nähe, den New Boards Hub zu Ihrer Standarderfahrung zu machen! Es wird ein aktualisiertes Design, eine bessere Leistung und verbesserte Barrierefreiheit eingeführt. Darüber hinaus zeigen wir eine Vorschau von zwei neuen Features in Boards an: AB#-Links auf GitHub-Pullanforderungen und eine zuverlässigere GitHub-Repositorysuche, wodurch das Risiko von Timeouts entfernt wird.

Weitere Informationen finden Sie in den Versionshinweisen.

GitHub Advanced Security für Azure DevOps

Azure Boards

Azure Pipelines

GitHub Advanced Security für Azure DevOps

Sicherheitsübersicht – Risiko- und Abdeckungsansichten

Sie können jetzt eine organisationsweite Ansicht Ihrer Repositorys sowie deren Advanced Security-Warnungen und den Status der Advanced Security-Aktivierung aller Repositorys in Ihrer Organisation anzeigen.

Das Sicherheitsübersichtsfeature für Advanced Security finden Sie unter Navigation zur Sicherheitsübersicht für Organisationseinstellungen>. Weitere Informationen finden Sie in der Sicherheitsübersicht auf GitHub Advanced Security für Azure DevOps.

Erweiterter Satz geheimer Überprüfungserkennungen

Wir erweitern den Satz von Partnermustern, die mit geheimer Überprüfung erkannt werden können. Diese Erweiterung bringt viele Vertrauenswürdigkeitsmuster für neue Tokentypen mit sich. Zu diesen neuen Mustern gehören eine große Anzahl von Azure-Ressourcenanbietern und andere SaaS-Anbieter über das GitHub Advanced Security Secret Scanning-Partnerprogramm.

Weitere Informationen zu den Arten von Partnermustern, die von GitHub Advanced Security Secret Scanning erkannt werden, finden Sie unter "Geheime Überprüfungswarnungen" für GitHub Advanced Security für Azure DevOps.

Geheime Überprüfung erkennt jetzt Nichtanbietermuster

Die geheime Überprüfung erkennt jetzt viele Nichtanbietermuster, einschließlich:

  • HTTP-Authentifizierungsheader
  • MongoDB-Verbindungszeichenfolgen
  • MySQL/Postgres/SQL Server Verbindungszeichenfolge s
  • Private Schlüssel für OpenSSH
  • PRIVATE RSA-Schlüssel

Hinweis

Die Erkennung von Nicht-Anbietermustern befindet sich derzeit in der Vorschau und kann geändert werden.

Die Erkennung dieser Muster ist für alle gitHub Advanced Security-fähigen Repositorys in Azure DevOps aktiviert. Resultierende geheime Schlüssel werden in einem neuen, separaten Filter in der Liste der geheimen Überprüfungsbenachrichtigungen mit dem Namen "Konfidenz" angezeigt.

Weitere Informationen zu den Mustertypen, die von GitHub Advanced Security Secret Scanning erkannt werden, finden Sie unter "Geheime Überprüfungswarnungen" für GitHub Advanced Security für Azure DevOps.

Azure Boards

Neuer Boards-Hub standardmäßig aktiviert

Wenn Sie mit dem Fortschritt des New Boards Hub schritthalten, wissen Sie wahrscheinlich, dass die Vorschau seit einiger Zeit aktiv war. Tatsächlich haben wir offiziell die Vorschau des New Boards Hub vor etwas mehr als zwei Jahren angekündigt.

Heute freuen wir uns, die letzte Phase unserer Reise bekanntzugeben. Wir beginnen mit dem Prozess, den New Boards Hub als Standarderfahrung für alle unsere Kunden zu gestalten. Dies geschieht in zwei Wellen mit dem ersten Start mitte April. Der Rolloutprozess für jede Welle erstreckt sich über mehrere Wochen, da wir jeden anderen Tag schrittweise einen anderen Satz von Kunden einführen.

Weitere Informationen finden Sie hier in unserem neuesten Blogbeitrag.

Nach mehreren Wochen in der Vorschau freuen wir uns, eine verbesserte Oberfläche zum Verknüpfen von Arbeitsaufgaben mit GitHub bekannt zu geben. Suchen Sie das gewünschte Repository, und führen Sie einen Drilldown aus, um die spezifische Pullanforderung oder den Commit zu finden und zu verknüpfen. Es ist nicht mehr erforderlich, dass mehrere Fensteränderungen vorgenommen und kopiert/eingefügt werden (obwohl Sie diese Option noch haben).

GIF zum Demo Hinzufügen von Linkverbesserungen.

Hinweis

Dieses Feature ist nur in der Vorschau des Neuen Boards-Hubs verfügbar.

Im Rahmen unserer kontinuierlichen Verbesserungen an der Azure Boards + GitHub-Integration zeigen wir eine Vorschau eines Features an, das die Erfahrung mit AB#-Links verbessert. Mit diesem Update werden Ihre AB#-Links jetzt direkt im Abschnitt "Entwicklung" der GitHub-Pullanforderung angezeigt. Dies bedeutet, dass Sie die verknüpften Arbeitsaufgaben anzeigen können, ohne durch beschreibung oder Kommentare navigieren zu müssen, was zu einem einfacheren Zugriff auf diese AB#-Links führt.

Screenshots von AB#-Links.

Diese Links sind nur verfügbar, wenn Sie AB# im Pull der Anforderungsbeschreibung verwenden. Sie werden nicht angezeigt, wenn Sie direkt aus der Pullanforderung aus der Arbeitsaufgabe eine Verknüpfung herstellen. Wenn Sie den AB#-Link aus der Beschreibung entfernen, wird er auch aus dem Entwicklungssteuerelement entfernt.

Wenn Sie an der Vorschau teilnehmen möchten, wenden Sie sich bitte direkt per E-Mail an uns. Stellen Sie sicher, dass Sie Ihren GitHub-Organisationsnamen (github.com/{Organisationsname}) einschließen.

Herstellen einer Verbindung mit Verbesserungen der GitHub-Repositorysuche (Vorschau)

Bisher war die Verbindung eines Azure DevOps-Projekts mit einer GitHub-Organisation mit Tausenden von Repositorys eine Herausforderung. Kunden mit diesen vielen GitHub-Repositorys können Timeoutfehler oder lange Wartezeiten haben. Heute wird eine Vorschau angekündigt, die die Blockierung großer GitHub-Organisationen entsperrt. Sie können jetzt tausende Repositorys durchsuchen und auswählen, ohne dass Timeoutprobleme auftreten.

Wir freuen uns, dieses Feature auf Anfrage zu aktivieren. Wenn Sie interessiert sind, senden Sie uns bitte Ihren Azure DevOps-Organisationsnamen (dev.azure.com/{organization}).

Azure Pipelines

Berechtigung zum Bearbeiten der Warteschlangenbuildkonfiguration

Um Die Sicherheitslage Ihrer Pipelines zu verbessern, fügen wir eine neue Pipelineberechtigung namens Edit queue build configuration hinzu, die steuert, wer die Werte von Variablen definiert, die zur Warteschlangenzeit und zu Freitext-Laufzeitparametern festgelegt werden können.

Screenshot der Berechtigungen.

Variablen, die zu Warteschlangenzeit und Parametern festgelegt werden, ermöglichen es Ihnen, konfigurierbare YAML-Pipelines zu schreiben. Leider stellen sie auch die Möglichkeit vor, Benutzereingaben auszuführen. Die neue Berechtigung entschärft dieses Risiko.

Benutzer, die nur über die Berechtigung "Warteschlangenbuild " verfügen, können Builds in der Warteschlange warteschlangen und die Werte von Laufzeitparametern bearbeiten, die über einen vordefinierten Wertesatz verfügen. Das heißt, sie können Werte für Parameter auswählen, die vom Typ sind boolean, number oder sie haben den values Eigenschaftensatz.

Wenn ein Parameter z. B. Freitext enthalten kann, können objectnur benutzer, die über die Konfigurationsberechtigung zum Erstellen der Bearbeitungswarteschlange verfügen, diese festlegen.

Betrachten Sie eine Pipeline mit den folgenden Parametern, die definiert sind:

parameters:
- name: Configuration
  type: string
  values:
  - release
  - debug
  default: debug
- name: UseNewDeploymentMethod
  type: boolean
  default: false
- name: AzureSKU
  type: object
  default:
    WUS1: Standard D2lds v5
    WUS2: Standard D2lds v5
    WUS3: Standard D2lds v5

Wenn ein Benutzer, der eine Ausführung in die Warteschlange stellt, nur über die Berechtigung zum Warteschlangenbuild verfügt. Wenn sie die Pipeline in die Warteschlange stellen, können sie nur die Werte der Pipeline und UseNewDeploymentMethod parameter Configuration angeben. Sie können den Wert für den AzureSKU Parameter nicht angeben.

Screenshot der Pipeline ausführen.

Das Ändern von Variablen, die zur Warteschlangenzeit als festgelegt gekennzeichnet sind, erfordert auch die Erstellungsberechtigung für die Bearbeitungswarteschlange. Andernfalls kann der Variablewert nicht geändert werden.

Screenshot von Variablen.

Um sicherzustellen, dass die neue Berechtigung Ihre täglichen Arbeitslasten nicht beeinträchtigt, erhält jeder, der über die Warteschlangenbuildberechtigung verfügt, die Konfigurationsberechtigung "Warteschlange bearbeiten". Anschließend können Sie diese Berechtigung nach Bedarf entfernen.

TFX überprüft, ob eine Aufgabe einen End of Life Node-Läufer verwendet.

Aufgabenautoren verwenden TFX zum Veröffentlichen von Erweiterungen. TFX wurde aktualisiert, um Überprüfungen für andere Node-Runner-Versionen durchzuführen.

Erweiterungen, die Aufgaben mit einer Node-Runner-Version enthalten, die das Ende der Lebensdauer (EOL) (bis einschließlich Node 16) enthält, sehen diese Warnung:

Task < TaskName > ist von einem Vorgangsläufer abhängig, der das Ende der Lebensdauer ist und in Zukunft entfernt wird. Autoren sollten die Richtlinien für das Node-Upgrade überprüfen: https://aka.ms/node-runner-guidance

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.

Einen Vorschlag unterbreiten

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

Vielen Dank,

Dan Hellem