Zalecenia dotyczące zabezpieczeń dla zasobów devOps
W tym artykule wymieniono zalecenia, które można zobaczyć w Microsoft Defender dla Chmury, jeśli łączysz środowisko Usługi Azure DevOps, GitHub lub GitLab przy użyciu strony Ustawienia środowiska. Zalecenia wyświetlane w twoim środowisku są oparte na zasobach, które chronisz i na dostosowanej konfiguracji.
Aby dowiedzieć się więcej o akcjach, które można wykonać w odpowiedzi na te zalecenia, zobacz Korygowanie zaleceń w Defender dla Chmury.
Dowiedz się więcej o korzyściach i funkcjach zabezpieczeń metodyki DevOps.
Rekomendacje metodyki DevOps nie wpływają na wskaźnik bezpieczeństwa. Aby zdecydować, które zalecenia należy rozwiązać jako pierwsze, przyjrzyj się ważności poszczególnych rekomendacji i jej potencjalnemu wpływowi na wskaźnik bezpieczeństwa.
Zalecenia dotyczące usługi Azure DevOps
Repozytoria usługi Azure DevOps powinny mieć włączoną usługę GitHub Advanced Security dla usługi Azure DevOps (GHAzDO)
Opis: Zabezpieczenia metodyki DevOps w Defender dla Chmury używają konsoli centralnej, aby umożliwić zespołom ds. zabezpieczeń ochronę aplikacji i zasobów przed kodem do chmury w usłudze Azure DevOps. Dzięki włączeniu repozytoriów Usługi GitHub Advanced Security dla usługi Azure DevOps (GHAzDO), w tym usługi GitHub Advanced Security dla usługi Azure DevOps, uzyskasz wyniki dotyczące wpisów tajnych, zależności i luk w zabezpieczeniach kodu w repozytoriach usługi Azure DevOps przedstawionych w Microsoft Defender dla Chmury.
Ważność: Wysoka
Repozytoria usługi Azure DevOps powinny mieć rozpoznane wyniki skanowania wpisów tajnych
Opis: Wpisy tajne zostały znalezione w repozytoriach kodu. Natychmiast koryguj, aby zapobiec naruszeniu zabezpieczeń. Wpisy tajne znalezione w repozytoriach mogą wyciekać lub wykrywać przez przeciwników, co prowadzi do naruszenia zabezpieczeń aplikacji lub usługi. Narzędzie do skanowania poświadczeń DevOps zabezpieczeń firmy Microsoft skanuje tylko kompilacje, na których jest skonfigurowany do uruchamiania. W związku z tym wyniki mogą nie odzwierciedlać pełnego stanu wpisów tajnych w repozytoriach.
Ważność: Wysoka
Repozytoria usługi Azure DevOps powinny mieć rozpoznane wyniki skanowania kodu
Opis: Luki w zabezpieczeniach zostały znalezione w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach.
Ważność: średni rozmiar
Repozytoria usługi Azure DevOps powinny mieć rozpoznane wyniki skanowania luk w zabezpieczeniach zależności
Opis: Luki w zabezpieczeniach zależności znalezione w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach.
Ważność: średni rozmiar
Repozytoria usługi Azure DevOps powinny mieć infrastrukturę w miarę rozwiązywania problemów ze skanowaniem kodu
Opis: Problemy z konfiguracją zabezpieczeń infrastruktury jako kodu znalezione w repozytoriach. Wykryto problemy w plikach szablonów. Aby poprawić stan zabezpieczeń powiązanych zasobów w chmurze, zdecydowanie zaleca się skorygowanie tych problemów.
Ważność: średni rozmiar
Potoki usługi Azure DevOps nie powinny mieć wpisów tajnych dostępnych dla kompilacji rozwidlenia
Opis: W repozytoriach publicznych możliwe jest, że osoby spoza organizacji tworzą rozwidlenia i uruchamiają kompilacje w rozwidlonym repozytorium. W takim przypadku, jeśli to ustawienie jest włączone, osoby zewnętrzne mogą uzyskać dostęp do wpisów tajnych potoku kompilacji, które miały być wewnętrzne.
Ważność: Wysoka
Połączenia usługi Azure DevOps nie powinny udzielać dostępu do wszystkich potoków
Opis: Połączenia usług są używane do tworzenia połączeń z usługi Azure Pipelines do usług zewnętrznych i zdalnych do wykonywania zadań w zadaniu. Uprawnienia potoku kontrolują, które potoki są autoryzowane do korzystania z połączenia z usługą. Aby zapewnić bezpieczeństwo operacji potoku, połączenia usług nie powinny mieć dostępu do wszystkich potoków YAML. Pomaga to zachować zasadę najniższych uprawnień, ponieważ luka w zabezpieczeniach składników używanych przez jeden potok może być używana przez osobę atakującą do ataku na inne potoki z dostępem do krytycznych zasobów.
Ważność: Wysoka
Bezpieczne pliki usługi Azure DevOps nie powinny udzielać dostępu do wszystkich potoków
Opis: Bezpieczne pliki umożliwiają deweloperom przechowywanie plików, które mogą być współużytkowane przez potoki. Te pliki są zwykle używane do przechowywania wpisów tajnych, takich jak certyfikaty podpisywania i klucze SSH. Jeśli bezpieczny plik ma dostęp do wszystkich potoków YAML, nieautoryzowany użytkownik może ukraść informacje z bezpiecznych plików przez utworzenie potoku YAML i uzyskanie dostępu do bezpiecznego pliku.
Ważność: Wysoka
Grupy zmiennych usługi Azure DevOps ze zmiennymi tajnymi nie powinny udzielać dostępu do wszystkich potoków
Opis: Grupy zmiennych przechowują wartości i wpisy tajne, które można przekazać do potoku YAML lub udostępnić w wielu potokach. Grupy zmiennych można udostępniać i używać w wielu potokach w tym samym projekcie. Jeśli grupa zmiennych zawierająca wpisy tajne jest oznaczona jako dostępna dla wszystkich potoków YAML, osoba atakująca może wykorzystać zasoby obejmujące zmienne tajne, tworząc nowy potok.
Ważność: Wysoka
Klasyczne połączenia usługi azure DevOps nie powinny być używane do uzyskiwania dostępu do subskrypcji
Opis: Użyj typu połączeń usługi Azure Resource Manager (ARM) zamiast połączeń usługi klasycznej platformy Azure, aby nawiązać połączenie z subskrypcjami platformy Azure. Model usługi ARM oferuje wiele ulepszeń zabezpieczeń, w tym silniejszą kontrolę dostępu, ulepszoną inspekcję, wdrażanie/zarządzanie oparte na usłudze ARM, dostęp do tożsamości zarządzanych i magazyn kluczy na potrzeby wpisów tajnych, uwierzytelniania opartego na uprawnieniach entra oraz obsługę tagów i grup zasobów w celu usprawnienia zarządzania.
Ważność: średni rozmiar
(Wersja zapoznawcza) Repozytoria usługi Azure DevOps powinny mieć rozwiązane wyniki testów zabezpieczeń interfejsu API
Opis: Luki w zabezpieczeniach interfejsu API znalezione w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach.
Ważność: średni rozmiar
(Wersja zapoznawcza) Repozytoria usługi Azure DevOps powinny wymagać minimalnej zgody dwóch recenzentów na potrzeby wypychania kodu
Opis: Aby zapobiec bezpośredniemu zatwierdzeniu niezamierzonych lub złośliwych zmian, ważne jest zaimplementowanie zasad ochrony dla domyślnej gałęzi w repozytoriach usługi Azure DevOps. Zalecamy wymaganie od co najmniej dwóch recenzentów kodu zatwierdzenia żądań ściągnięcia przed scaleniem kodu z gałęzią domyślną. Wymagając zatwierdzenia od co najmniej dwóch recenzentów, można zmniejszyć ryzyko nieautoryzowanych modyfikacji, co może prowadzić do niestabilności systemu lub luk w zabezpieczeniach.
To zalecenie jest dostępne w Defender dla Chmury podstawowym stanie zabezpieczeń, jeśli połączono usługę Azure DevOps z Defender dla Chmury.
Ważność: Wysoka
(Wersja zapoznawcza) Repozytoria usługi Azure DevOps nie powinny zezwalać żądaniom na zatwierdzanie własnych żądań ściągnięcia
Opis: Aby zapobiec bezpośredniemu zatwierdzeniu niezamierzonych lub złośliwych zmian, ważne jest zaimplementowanie zasad ochrony dla domyślnej gałęzi w repozytoriach usługi Azure DevOps. Zalecamy, aby twórcy żądań ściągnięcia zatwierdzali własne zgłoszenia, aby upewnić się, że każda zmiana przechodzi obiektywną recenzję przez kogoś innego niż autor. Dzięki temu można zmniejszyć ryzyko nieautoryzowanych modyfikacji, co może prowadzić do niestabilności systemu lub luk w zabezpieczeniach.
To zalecenie jest dostępne w Defender dla Chmury podstawowym stanie zabezpieczeń, jeśli połączono usługę Azure DevOps z Defender dla Chmury.
Ważność: Wysoka
(Wersja zapoznawcza) Projekty usługi Azure DevOps powinny mieć wyłączone tworzenie klasycznych potoków
Opis: Wyłączenie tworzenia klasycznych potoków kompilacji i wydania zapobiega problemowi zabezpieczeń wynikającemu z języka YAML i potoków klasycznych współużytkujących te same zasoby, na przykład tych samych połączeń usługi. Potencjalni atakujący mogą wykorzystać klasyczne potoki do tworzenia procesów, które unikają typowych mechanizmów ochrony skonfigurowanych wokół nowoczesnych potoków YAML.
Ważność: Wysoka
Zalecenia dotyczące usługi GitHub
Organizacje usługi GitHub nie powinny udostępniać wpisów tajnych akcji wszystkim repozytoriom
Opis: W przypadku wpisów tajnych używanych w przepływach pracy akcji usługi GitHub przechowywanych na poziomie organizacji usługi GitHub można użyć zasad dostępu do kontrolowania, które repozytoria mogą używać wpisów tajnych organizacji. Wpisy tajne na poziomie organizacji umożliwiają udostępnianie wpisów tajnych między wieloma repozytoriami. Zmniejsza to konieczność tworzenia zduplikowanych wpisów tajnych. Jednak po udostępnieniu wpisu tajnego do repozytorium każda osoba z dostępem do zapisu w repozytorium może uzyskać dostęp do wpisu tajnego z dowolnej gałęzi w przepływie pracy. Aby zmniejszyć obszar ataków, upewnij się, że wpis tajny jest dostępny tylko z wybranych repozytoriów.
To zalecenie jest dostępne w Defender dla Chmury podstawowym stanie zabezpieczeń, jeśli połączono usługę Azure DevOps z Defender dla Chmury.
Ważność: Wysoka
Repozytoria GitHub powinny mieć włączone skanowanie wpisów tajnych
Opis: Usługa GitHub skanuje repozytoria pod kątem znanych typów wpisów tajnych, aby zapobiec fałszywemu użyciu wpisów tajnych, które zostały przypadkowo zatwierdzone w repozytoriach. Skanowanie wpisów tajnych spowoduje skanowanie całej historii usługi Git we wszystkich gałęziach znajdujących się w repozytorium GitHub pod kątem wszystkich wpisów tajnych. Przykłady wpisów tajnych to tokeny i klucze prywatne, które dostawca usług może wystawiać na potrzeby uwierzytelniania. Jeśli wpis tajny zostanie zaewidencjonowany w repozytorium, każdy, kto ma dostęp do odczytu do repozytorium, może użyć wpisu tajnego, aby uzyskać dostęp do usługi zewnętrznej z tymi uprawnieniami. Wpisy tajne powinny być przechowywane w dedykowanej, bezpiecznej lokalizacji poza repozytorium projektu.
Ważność: Wysoka
Repozytoria GitHub powinny mieć włączone skanowanie kodu
Opis: Usługa GitHub używa skanowania kodu do analizowania kodu w celu znalezienia luk w zabezpieczeniach i błędów w kodzie. Skanowanie kodu może służyć do znajdowania, klasyfikowania i określania priorytetów poprawek istniejących problemów w kodzie. Skanowanie kodu może również uniemożliwić deweloperom wprowadzanie nowych problemów. Skanowania mogą być zaplanowane przez określone dni i godziny lub skanowania mogą być wyzwalane, gdy w repozytorium wystąpi określone zdarzenie, takie jak wypychanie. Jeśli skanowanie kodu wykryje potencjalną lukę w zabezpieczeniach lub błąd w kodzie, usługa GitHub wyświetli alert w repozytorium. Luka w zabezpieczeniach jest problemem w kodzie projektu, który może zostać wykorzystany w celu uszkodzenia poufności, integralności lub dostępności projektu.
Ważność: średni rozmiar
Repozytoria GitHub powinny mieć włączone skanowanie dependabotów
Opis: Usługa GitHub wysyła alerty Dependabot, gdy wykrywa luki w zabezpieczeniach zależności kodu, które mają wpływ na repozytoria. Luka w zabezpieczeniach jest problemem w kodzie projektu, który może zostać wykorzystany w celu uszkodzenia poufności, integralności lub dostępności projektu lub innych projektów korzystających z jego kodu. Luki w zabezpieczeniach różnią się w zależności od typu, ważności i metody ataku. Gdy kod zależy od pakietu, który ma lukę w zabezpieczeniach, ta zależność podatna na zagrożenia może spowodować szereg problemów.
Ważność: średni rozmiar
Repozytoria GitHub powinny mieć rozpoznane wyniki skanowania wpisów tajnych
Opis: Wpisy tajne znalezione w repozytoriach kodu. Powinno to zostać natychmiast skorygowane, aby zapobiec naruszeniu zabezpieczeń. Wpisy tajne znalezione w repozytoriach mogą być ujawnione lub wykryte przez przeciwników, co prowadzi do naruszenia zabezpieczeń aplikacji lub usługi.
Ważność: Wysoka
Repozytoria GitHub powinny mieć rozpoznane wyniki skanowania kodu
Opis: Luki w zabezpieczeniach znalezione w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach.
Ważność: średni rozmiar
Repozytoria GitHub powinny mieć rozpoznane wyniki skanowania luk w zabezpieczeniach zależności
Opis: Repozytoria GitHub powinny mieć rozpoznane wyniki skanowania luk w zabezpieczeniach pod kątem luk w zabezpieczeniach.
Ważność: średni rozmiar
Repozytoria GitHub powinny mieć infrastrukturę w miarę rozwiązywania problemów ze skanowaniem kodu
Opis: Problemy z konfiguracją zabezpieczeń infrastruktury jako kodu zostały znalezione w repozytoriach. Wykryto problemy w plikach szablonów. Aby poprawić stan zabezpieczeń powiązanych zasobów w chmurze, zdecydowanie zaleca się skorygowanie tych problemów.
Ważność: średni rozmiar
Repozytoria GitHub powinny mieć zasady ochrony dla domyślnej gałęzi włączonej
Opis: Domyślna gałąź repozytorium powinna być chroniona za pośrednictwem zasad ochrony gałęzi, aby zapobiec bezpośredniemu zatwierdzeniu niezamierzonych/złośliwych zmian w repozytorium.
Ważność: Wysoka
Repozytoria GitHub powinny wymuszać wypychanie do domyślnej gałęzi wyłączone
Opis: Ponieważ domyślna gałąź jest zwykle używana do wdrażania i innych działań uprzywilejowanych, wszelkie zmiany w tej gałęzi powinny być stosowane ostrożnie. Włączenie wymuszonych wypchnięć może wprowadzać niezamierzone lub złośliwe zmiany w gałęzi domyślnej.
Ważność: średni rozmiar
Organizacje usługi GitHub powinny mieć włączoną ochronę wypychaną skanowania wpisów tajnych
Opis: Usługa Push Protection zablokuje zatwierdzenia zawierające wpisy tajne, co uniemożliwia przypadkowe ujawnienie wpisów tajnych. Aby uniknąć ryzyka ujawnienia poświadczeń, ochrona wypychana powinna być automatycznie włączona dla każdego repozytorium obsługującego skanowanie wpisów tajnych.
Ważność: Wysoka
Repozytoria GitHub nie powinny używać własnych modułów uruchamiaczy
Opis: Self-Hosted Runners on GitHub brak gwarancji działania w efemerycznych czystych maszynach wirtualnych i może być trwale naruszony przez niezaufany kod w przepływie pracy. W związku z tym moduły uruchamiane samodzielnie nie powinny być używane w przypadku przepływów pracy akcji.
Ważność: Wysoka
Organizacje usługi GitHub powinny mieć uprawnienia przepływu pracy akcji ustawione na uprawnienia tylko do odczytu
Opis: Domyślnie przepływy pracy akcji powinny mieć przyznane uprawnienia tylko do odczytu, aby uniemożliwić złośliwym użytkownikom wykorzystanie nadmiernych przepływów pracy w celu uzyskania dostępu do zasobów i manipulowania nimi.
Ważność: Wysoka
Organizacje usługi GitHub powinny mieć więcej niż jedną osobę z uprawnieniami administratora
Opis: Posiadanie co najmniej dwóch administratorów zmniejsza ryzyko utraty dostępu administratora. Jest to przydatne w przypadku scenariuszy kont break-glass.
Ważność: Wysoka
Organizacje usługi GitHub powinny mieć uprawnienia podstawowe ustawione na żadne uprawnienia lub odczyt
Opis: Uprawnienia podstawowe powinny być ustawione na wartość brak lub odczyt dla organizacji, aby przestrzegać zasady najniższych uprawnień i zapobiegać niepotrzebnemu dostępowi.
Ważność: Wysoka
(Wersja zapoznawcza) Repozytoria GitHub powinny mieć rozwiązane wyniki testów zabezpieczeń interfejsu API
Opis: Luki w zabezpieczeniach interfejsu API zostały znalezione w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach.
Ważność: średni rozmiar
(Wersja zapoznawcza) Organizacje usługi GitHub nie powinny udostępniać wpisów tajnych akcji wszystkim repozytoriom
Opis: W przypadku wpisów tajnych używanych w przepływach pracy akcji usługi GitHub przechowywanych na poziomie organizacji usługi GitHub można użyć zasad dostępu do kontrolowania, które repozytoria mogą używać wpisów tajnych organizacji. Wpisy tajne na poziomie organizacji umożliwiają udostępnianie wpisów tajnych między wieloma repozytoriami, co zmniejsza konieczność tworzenia zduplikowanych wpisów tajnych. Jeśli jednak wpis tajny jest dostępny dla repozytorium, każda osoba z dostępem do zapisu w repozytorium może uzyskać dostęp do wpisu tajnego z dowolnej gałęzi w przepływie pracy. Aby zmniejszyć obszar ataków, upewnij się, że wpis tajny jest dostępny tylko z wybranych repozytoriów.
Ważność: Wysoka
(Wersja zapoznawcza) Organizacje usługi GitHub powinny blokować sugestie copilot zgodne z kodem publicznym
Opis: Włączenie filtru Copilot w usłudze GitHub w celu zablokowania sugestii dotyczących kodu pasujących do publicznego kodu w usłudze GitHub zwiększa bezpieczeństwo i zgodność z przepisami. Zapobiega przypadkowemu włączeniu kodu publicznego lub open source, zmniejszając ryzyko problemów prawnych i zapewniając przestrzeganie postanowień licencyjnych. Ponadto pomaga uniknąć wprowadzania potencjalnych luk w zabezpieczeniach z kodu publicznego do projektów organizacji, zapewniając tym samym lepszą jakość kodu i bezpieczeństwo. Po włączeniu filtru narzędzie GitHub Copilot sprawdza sugestie dotyczące kodu z otaczającym ich kodem zawierającym około 150 znaków względem kodu publicznego w usłudze GitHub. Jeśli istnieje dopasowanie lub zbliża się do niego, sugestia nie zostanie wyświetlona.
Ważność: Wysoka
(Wersja zapoznawcza) Organizacje usługi GitHub powinny wymuszać uwierzytelnianie wieloskładnikowe dla współpracowników zewnętrznych
Opis: Wymuszanie uwierzytelniania wieloskładnikowego dla współpracowników zewnętrznych w organizacji usługi GitHub to środek zabezpieczeń, który wymaga od współpracowników użycia dodatkowej formy identyfikacji oprócz hasła w celu uzyskania dostępu do repozytoriów i zasobów organizacji. Zwiększa to bezpieczeństwo, chroniąc przed nieautoryzowanym dostępem, nawet jeśli hasło zostało naruszone, i pomaga zapewnić zgodność ze standardami branżowymi. Obejmuje to informowanie współpracowników o wymaganiu i zapewnienie wsparcia dla przejścia, ostatecznie zmniejszenie ryzyka naruszeń danych.
Ważność: Wysoka
(Wersja zapoznawcza) Repozytoria GitHub powinny wymagać minimalnej zgody dwóch recenzentów na wypychanie kodu
Opis: Aby zapobiec bezpośredniemu zatwierdzeniu niezamierzonych lub złośliwych zmian, ważne jest zaimplementowanie zasad ochrony dla domyślnej gałęzi w repozytoriach GitHub. Zalecamy wymaganie od co najmniej dwóch recenzentów kodu zatwierdzenia żądań ściągnięcia przed scaleniem kodu z gałęzią domyślną. Wymagając zatwierdzenia od co najmniej dwóch recenzentów, można zmniejszyć ryzyko nieautoryzowanych modyfikacji, co może prowadzić do niestabilności systemu lub luk w zabezpieczeniach.
Ważność: Wysoka
Zalecenia dotyczące narzędzia GitLab
Projekty GitLab powinny mieć rozpoznane wyniki skanowania wpisów tajnych
Opis: Wpisy tajne zostały znalezione w repozytoriach kodu. Powinno to zostać natychmiast skorygowane, aby zapobiec naruszeniu zabezpieczeń. Wpisy tajne znalezione w repozytoriach mogą być ujawnione lub wykryte przez przeciwników, co prowadzi do naruszenia zabezpieczeń aplikacji lub usługi.
Ważność: Wysoka
Projekty GitLab powinny mieć rozpoznane wyniki skanowania kodu
Opis: Luki w zabezpieczeniach zostały znalezione w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach.
Ważność: średni rozmiar
Projekty GitLab powinny mieć rozpoznane wyniki skanowania luk w zabezpieczeniach zależności
Opis: Repozytoria GitHub powinny mieć rozpoznane wyniki skanowania luk w zabezpieczeniach pod kątem luk w zabezpieczeniach.
Ważność: średni rozmiar
Projekty GitLab powinny mieć infrastrukturę w miarę rozwiązywania problemów ze skanowaniem kodu
Opis: Problemy z konfiguracją zabezpieczeń infrastruktury jako kodu zostały znalezione w repozytoriach. Wyświetlone problemy zostały wykryte w plikach szablonów. Aby poprawić stan zabezpieczeń powiązanych zasobów w chmurze, zdecydowanie zaleca się skorygowanie tych problemów.
Ważność: średni rozmiar
Przestarzałe zalecenia dotyczące zabezpieczeń metodyki DevOps
Repozytoria kodu powinny mieć rozpoznane wyniki skanowania kodu
Opis: Zabezpieczenia metodyki DevOps w Defender dla Chmury wykryły luki w zabezpieczeniach w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach. (Brak powiązanych zasad)
Ważność: średni rozmiar
Repozytoria kodu powinny mieć rozpoznane wyniki skanowania wpisów tajnych
Opis: Zabezpieczenia metodyki DevOps w Defender dla Chmury znalazły wpis tajny w repozytoriach kodu. Powinno to zostać natychmiast skorygowane, aby zapobiec naruszeniu zabezpieczeń. Wpisy tajne znalezione w repozytoriach mogą być ujawnione lub wykryte przez przeciwników, co prowadzi do naruszenia zabezpieczeń aplikacji lub usługi. W przypadku usługi Azure DevOps narzędzie Microsoft Security DevOps CredScan skanuje tylko kompilacje, na których został skonfigurowany do uruchomienia. W związku z tym wyniki mogą nie odzwierciedlać pełnego stanu wpisów tajnych w repozytoriach. (Brak powiązanych zasad)
Ważność: Wysoka
Repozytoria kodu powinny mieć rozpoznane wyniki skanowania dependabot
Opis: Zabezpieczenia metodyki DevOps w Defender dla Chmury wykryły luki w zabezpieczeniach w repozytoriach kodu. Aby poprawić stan zabezpieczeń repozytoriów, zdecydowanie zaleca się skorygowanie tych luk w zabezpieczeniach. (Brak powiązanych zasad)
Ważność: średni rozmiar
Repozytoria kodu powinny mieć infrastrukturę w miarę rozwiązywania ustaleń skanowania kodu
Opis: Zabezpieczenia metodyki DevOps w Defender dla Chmury znalazły infrastrukturę jako problemy z konfiguracją zabezpieczeń kodu w repozytoriach. Wyświetlone problemy zostały wykryte w plikach szablonów. Aby poprawić stan zabezpieczeń powiązanych zasobów w chmurze, zdecydowanie zaleca się skorygowanie tych problemów. (Brak powiązanych zasad)
Ważność: średni rozmiar
Repozytoria GitHub powinny mieć włączone skanowanie kodu
Opis: Usługa GitHub używa skanowania kodu do analizowania kodu w celu znalezienia luk w zabezpieczeniach i błędów w kodzie. Skanowanie kodu może służyć do znajdowania, klasyfikowania i określania priorytetów poprawek istniejących problemów w kodzie. Skanowanie kodu może również uniemożliwić deweloperom wprowadzanie nowych problemów. Skanowania mogą być zaplanowane przez określone dni i godziny lub skanowania mogą być wyzwalane, gdy w repozytorium wystąpi określone zdarzenie, takie jak wypychanie. Jeśli skanowanie kodu wykryje potencjalną lukę w zabezpieczeniach lub błąd w kodzie, usługa GitHub wyświetli alert w repozytorium. Luka w zabezpieczeniach jest problemem w kodzie projektu, który może zostać wykorzystany w celu uszkodzenia poufności, integralności lub dostępności projektu. (Brak powiązanych zasad)
Ważność: średni rozmiar
Repozytoria GitHub powinny mieć włączone skanowanie wpisów tajnych
Opis: Usługa GitHub skanuje repozytoria pod kątem znanych typów wpisów tajnych, aby zapobiec fałszywemu użyciu wpisów tajnych, które zostały przypadkowo zatwierdzone w repozytoriach. Skanowanie wpisów tajnych spowoduje skanowanie całej historii usługi Git we wszystkich gałęziach znajdujących się w repozytorium GitHub pod kątem wszystkich wpisów tajnych. Przykłady wpisów tajnych to tokeny i klucze prywatne, które dostawca usług może wystawiać na potrzeby uwierzytelniania. Jeśli wpis tajny zostanie zaewidencjonowany w repozytorium, każdy, kto ma dostęp do odczytu do repozytorium, może użyć wpisu tajnego, aby uzyskać dostęp do usługi zewnętrznej z tymi uprawnieniami. Wpisy tajne powinny być przechowywane w dedykowanej, bezpiecznej lokalizacji poza repozytorium projektu. (Brak powiązanych zasad)
Ważność: Wysoka
Repozytoria GitHub powinny mieć włączone skanowanie dependabotów
Opis: Usługa GitHub wysyła alerty Dependabot, gdy wykrywa luki w zabezpieczeniach zależności kodu, które mają wpływ na repozytoria. Luka w zabezpieczeniach jest problemem w kodzie projektu, który może zostać wykorzystany w celu uszkodzenia poufności, integralności lub dostępności projektu lub innych projektów korzystających z jego kodu. Luki w zabezpieczeniach różnią się w zależności od typu, ważności i metody ataku. Gdy kod zależy od pakietu, który ma lukę w zabezpieczeniach, ta zależność podatna na zagrożenia może spowodować szereg problemów. (Brak powiązanych zasad)
Ważność: średni rozmiar