Odrzucanie alertów skanowania zależności w usłudze Advanced Security

Skanowanie zależności w usłudze Advanced Security wykrywa składniki typu open source używane w kodzie źródłowym i identyfikuje, czy występują jakiekolwiek skojarzone luki w zabezpieczeniach. Wszelkie znalezione luki w zabezpieczeniach ze składników typu open source są oflagowane jako alert. Dzięki tej aktualizacji można odrzucić alerty skanowania zależności w usłudze Advanced Security, które uważasz za fałszywie dodatnie lub akceptowalne.

W usłudze Azure Repos zmieniliśmy domyślne zachowanie, aby usunąć uprawnienie "Edytuj zasady" podczas tworzenia nowej gałęzi.

Zapoznaj się z informacjami o wersji, aby dowiedzieć się więcej o tych funkcjach.

Usługa GitHub Advanced Security dla usługi Azure DevOps

• Odrzucanie alertów dotyczących alertów skanowania zależności w usłudze Advanced Security

Azure Boards

• Kopiuj link do elementu roboczego

Azure Pipelines

• Zadania kubernetes obsługują teraz rozwiązanie kubelogin
• Aktualizacje harmonogramów cron YAML
• Wyłączanie sprawdzania
• Ulepszenia interfejsu API REST zatwierdzeń
• Nowe przełączanie w celu kontrolowania tworzenia klasycznych potoków

Azure Repos

• Usuwanie uprawnień "Edytuj zasady" do twórcy gałęzi

Ogólne

Odrzucanie alertów dotyczących alertów skanowania zależności w usłudze Advanced Security

Teraz możesz odrzucić wszystkie alerty skanowania zależności, które uważasz za fałszywie dodatnie lub akceptowalne. Są to te same opcje odrzucania dla skanowania wpisów tajnych i alertów skanowania kodu w usłudze Advanced Security, których obecnie można używać.

Należy pamiętać, że może być konieczne ponowne uruchomienie potoku wykrywania z zadaniem skanowania zależności, a także upewnić się, że masz Advanced Security: dismiss alerts uprawnienia, aby odrzucić te alerty.

Aby dowiedzieć się więcej na temat odrzucania alertów, zobacz Odrzucanie alertów skanowania zależności.

Azure Boards

Kopiuj link do elementu roboczego

Wprowadziliśmy niewielką poprawę w celu skopiowania adresu URL elementu roboczego z kilku obszarów w usłudze Azure Boards. Ułatwianie uzyskiwania bezpośredniego linku do określonego elementu roboczego.

Link kopiowania został dodany do menu kontekstowych w formularzu elementu roboczego, liście prac i liście prac zadań.

Uwaga

Ta funkcja będzie dostępna tylko w wersji zapoznawczej usługi New Boards Hubs.

Azure Pipelines

Zadania kubernetes obsługują teraz rozwiązanie kubelogin

Zaktualizowaliśmy zadania KubernetesManifest@1, HelmDeploy@0, Kubernetes@1 i AzureFunctionOnKubernetes@1 w celu obsługi narzędzia kubelogin. Dzięki temu można kierować usługę Azure Kubernetes Service (AKS) skonfigurowaną z integracją usługi Azure Active Directory.

Platforma Kubelogin nie jest wstępnie zainstalowana na hostowanych obrazach. Aby upewnić się, że wymienione powyżej zadania używają narzędzia kubelogin, zainstaluj je, wstawiając zadanie KubeloginInstaller@0 przed zadaniem, które jest od niego zależne:

 - task: KubeloginInstaller@0

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

Ulepszenia interfejsu API REST zatwierdzeń

Zatwierdzenia zwiększają bezpieczeństwo potoku YAML, umożliwiając ręczne przejrzenie wdrożenia w środowisku produkcyjnym. Zaktualizowaliśmy interfejs API REST zapytań dotyczących zatwierdzeń, aby był bardziej zaawansowany. Teraz:

• Nie musisz określać listy approvalIds. Wszystkie parametry są teraz opcjonalne.
• Może określić listę userIds, aby pobrać listę zatwierdzeń oczekujących na tych użytkowników. Obecnie interfejs API REST zwraca listę zatwierdzeń, dla których użytkownicy są jawnie przypisywani jako osoby zatwierdzające.
• Można określić state zatwierdzenia, które mają zostać zwrócone, na przykład pending.

Oto przykład: 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 zwraca

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

Wyłączanie sprawdzania

Wprowadziliśmy testy debugowania mniej żmudne. Czasami sprawdzanie wywołania funkcji platformy Azure lub wywołania interfejsu API REST nie działa poprawnie i należy go naprawić. Wcześniej trzeba było usunąć takie kontrole, aby uniemożliwić im błędne blokowanie wdrożenia. Po naprawieniu sprawdzania trzeba było go ponownie dodać i skonfigurować poprawnie, upewniając się, że wszystkie wymagane nagłówki są ustawione lub parametry zapytania są poprawne. To jest żmudne.

Teraz możesz po prostu wyłączyć sprawdzanie. Wyłączone sprawdzanie nie zostanie uruchomione w kolejnych ocenach pakietu sprawdzania.

Po naprawieniu błędnego sprawdzania można go tylko włączyć.

Aktualizacje harmonogramów cron YAML

W potokach YAML można zdefiniować zaplanowane wyzwalacze przy użyciu cron właściwości YAML.

Zaktualizowaliśmy sposób działania właściwości batch. W skrócie, jeśli ustawisz wartość batch na true, harmonogram cron nie zostanie uruchomiony, jeśli w toku będzie inny zaplanowany przebieg potoku. Dzieje się tak niezależnie od wersji repozytorium potoku.

W poniższej tabeli opisano sposób always i batch interakcję.

Zawsze	Batch	Zachowanie
false	false	Potok jest uruchamiany tylko wtedy, gdy istnieje zmiana w odniesieniu do ostatniego pomyślnego zaplanowanego uruchomienia potoku
false	true	Potok jest uruchamiany tylko wtedy, gdy nastąpiła zmiana w odniesieniu do ostatniego pomyślnego zaplanowanego uruchomienia potoku i nie ma zaplanowanego uruchomienia potoku w toku
true	false	Przebiegi potoku zgodnie z harmonogramem cron
true	true	Przebiegi potoku zgodnie z harmonogramem cron

Załóżmy na przykład, że always: false i batch: true. Załóżmy, że istnieje harmonogram cron określający, że potok powinien być uruchamiany co 5 minut. Wyobraź sobie, że istnieje nowe zatwierdzenie. W ciągu 5 minut potok uruchamia zaplanowane uruchomienie. Załóżmy, że uruchomienie potoku trwa 30 minut. W ciągu tych 30 minut nie ma zaplanowanego przebiegu, niezależnie od liczby zatwierdzeń. Następny zaplanowany przebieg odbywa się dopiero po zakończeniu bieżącego zaplanowanego przebiegu.

Potok YAML może zawierać wiele harmonogramów cron i możesz chcieć, aby potok uruchamiał różne etapy/zadania na podstawie harmonogramu cron. Na przykład masz nocną kompilację i cotygodniową kompilację i chcesz, aby podczas cotygodniowej kompilacji potok zbierał więcej statystyk.

Umożliwi to wprowadzenie nowej wstępnie zdefiniowanej zmiennej systemowej o nazwie Build.CronSchedule.DisplayName zawierającej displayName właściwość harmonogramu cron.

Nowe przełączanie w celu kontrolowania tworzenia klasycznych potoków

W ubiegłym roku uruchomiliśmy ustawienie konfiguracji Potoki, aby wyłączyć tworzenie klasycznych potoków kompilacji i wydania.

W odpowiedzi na Twoją opinię podzieliliśmy początkowy przełącznik na dwa: jeden dla klasycznych potoków kompilacji i jeden dla klasycznych potoków wydania, grup wdrożeń i grup zadań.

Jeśli twoja organizacja ma Disable creation of classic build and release pipelines przełącznik, oba nowe przełączniki są włączone. Jeśli oryginalny przełącznik jest wyłączony, oba nowe przełączniki są wyłączone.

Azure Repos

Usuwanie uprawnień "Edytuj zasady" do twórcy gałęzi

Wcześniej po utworzeniu nowej gałęzi udzielono Ci uprawnień do edytowania zasad w tej gałęzi. W przypadku tej aktualizacji zmieniamy domyślne zachowanie, aby nie udzielać tego uprawnienia, nawet jeśli ustawienie „Zarządzanie uprawnieniami” jest włączone dla repozytorium.

Będziesz także potrzebować uprawnienia „Edytuj zasady” przyznanego jawnie (ręcznie lub za pośrednictwem interfejsu API REST) poprzez dziedziczenie uprawnień zabezpieczeń lub poprzez członkostwo w grupie.

Następne kroki

Uwaga

Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.

Przejdź do usługi Azure DevOps i przyjrzyj się.

Przejdź do usługi Azure DevOps

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.

Możesz również uzyskać porady i odpowiedzi na pytania społeczności w witrynie Stack Overflow.

Dzięki,

Silviu Andrica