Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule wymieniono zalecenia, które można zobaczyć w Microsoft Defender dla Chmury, jeśli łączysz Azure DevOps,GitHub lub środowisko GitLab przy użyciu strony Ustawienia środowiska.
Zalecenia wyświetlane w twoim środowisku są oparte na zasobach, które chronisz i na dostosowanej konfiguracji. Zalecenia można zobaczyć w portalu , które mają zastosowanie do zasobów.
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 Azure DevOps
repozytoria Azure DevOps powinny mieć włączoną GitHub Advanced Security for Azure DevOps (GHAzDO)
Opis: Zabezpieczenia metodyki DevOps w Defender dla Chmury korzystają z centralnej konsoli, aby umożliwić zespołom ds. zabezpieczeń ochronę aplikacji i zasobów przed kodem do chmury w Azure DevOps. Dzięki włączeniu repozytoriów GitHub Advanced Security for Azure DevOps (GHAzDO), w tym GitHub Advanced Security for Azure DevOps, uzyskasz wyniki dotyczące wpisów tajnych, zależności i luk w zabezpieczeniach kodu w repozytoriach Azure DevOps uwidoczny Microsoft Defender dla Chmury.
Istotność: wysoka
Azure DevOps repozytoria 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ń rozwiązania zabezpieczające firmy Microsoft DevOps skanuje tylko kompilacje, na których jest skonfigurowany do uruchomienia. W związku z tym wyniki mogą nie odzwierciedlać pełnego stanu wpisów tajnych w repozytoriach.
Istotność: wysoka
Azure DevOps repozytoria 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ść: średnia
Repozytoria Azure DevOps powinny mieć rozwiązane problemy wykryte podczas skanowania zależności pod kątem luk w zabezpieczeniach
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ść: średnia
Azure DevOps repozytoria 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ść: średnia
Azure DevOps potoki 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.
Istotność: wysoka
Azure DevOps połączenia usługi nie powinny udzielać dostępu do wszystkich potoków
Opis: Połączenia usług są używane do tworzenia połączeń z 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.
Istotność: wysoka
Azure DevOps bezpieczne pliki 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.
Istotność: wysoka
Azure DevOps grup zmiennych ze zmiennymi tajnymi nie należy 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.
Istotność: wysoka
Azure DevOps klasyczne połączenia usługi Azure 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 Azure, aby nawiązać połączenie z subskrypcjami 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ść: średnia
(Wersja zapoznawcza) Azure DevOps repozytoria 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ść: średnia
(Wersja zapoznawcza) Azure DevOps repozytoria powinny wymagać co najmniej dwóch recenzentów zatwierdzenia wypychania kodu
Opis: Aby zapobiec bezpośredniemu zatwierdzeniu niezamierzonych lub złośliwych zmian, ważne jest zaimplementowanie zasad ochrony dla gałęzi domyślnej w repozytoriach 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 udostępniane w Defender dla Chmury podstawowym stanie zabezpieczeń, jeśli masz połączenie Azure DevOps z Defender dla Chmury.
Istotność: wysoka
(Wersja zapoznawcza) Azure DevOps repozytoria 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 gałęzi domyślnej w repozytoriach 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 udostępniane w Defender dla Chmury podstawowym stanie zabezpieczeń, jeśli masz połączenie Azure DevOps z Defender dla Chmury.
Istotność: wysoka
(Wersja zapoznawcza) Azure DevOps projekty powinny mieć wyłączone tworzenie potoków klasycznych
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.
Istotność: wysoka
zalecenia dotyczące GitHub
GitHub organizacje nie powinny wprowadzać wpisów tajnych akcji dostępnych dla wszystkich repozytoriów
Opis: W przypadku wpisów tajnych używanych w przepływach pracy akcji GitHub przechowywanych na poziomie GitHub organizacji 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 udostępniane w Defender dla Chmury podstawowym stanie zabezpieczeń, jeśli masz połączenie Azure DevOps z Defender dla Chmury.
Istotność: wysoka
GitHub repozytoria powinny mieć włączone skanowanie wpisów tajnych
Description: 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.
Istotność: wysoka
GitHub repozytoria powinny mieć włączone skanowanie kodu
Description: 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, 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ść: średnia
GitHub repozytoria powinny mieć włączone skanowanie Dependabot
Description: 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ść: średnia
GitHub repozytoria 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.
Istotność: wysoka
GitHub repozytoria 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ść: średnia
Repozytoria GitHub powinny mieć usunięte wyniki skanowania podatności zależności.
Opis: GitHub repozytoria powinny mieć rozwiązane wyniki skanowania luk w zabezpieczeniach pod kątem luk w zabezpieczeniach.
Ważność: średnia
GitHub repozytoria powinny mieć infrastrukturę w miarę rozwiązywania ustaleń skanowania 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ść: średnia
GitHub repozytoria powinny mieć włączone zasady ochrony dla domyślnej gałęzi
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.
Istotność: wysoka
GitHub repozytoria 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ść: średnia
GitHub organizacje 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.
Istotność: wysoka
GitHub repozytoria nie powinny używać własnych modułów uruchamiaczy
Opis: Self-Hosted modułów uruchamiający na 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 uruchamiającego Self-Hosted nie powinny być używane w przypadku przepływów pracy akcji.
Istotność: wysoka
GitHub organizacje 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.
Istotność: wysoka
GitHub organizacje 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.
Istotność: wysoka
GitHub organizacje 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.
Istotność: wysoka
(Wersja zapoznawcza) GitHub repozytoria 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ść: średnia
(Wersja zapoznawcza) GitHub organizacje nie powinny wprowadzać wpisów tajnych akcji dostępnych dla wszystkich repozytoriów
Opis: W przypadku wpisów tajnych używanych w przepływach pracy akcji GitHub przechowywanych na poziomie GitHub organizacji 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.
Istotność: wysoka
(Wersja zapoznawcza) GitHub organizacje powinny blokować Sugestie funkcji Copilot zgodne z kodem publicznym
Opis: Włączenie filtru GitHub Copilot w celu zablokowania sugestii dotyczących kodu pasujących do kodu publicznego w 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 GitHub Copilot sprawdza sugestie dotyczące kodu otaczającego ich kod o około 150 znakach względem kodu publicznego w GitHub. Jeśli istnieje dopasowanie lub zbliża się do niego, sugestia nie zostanie wyświetlona.
Istotność: wysoka
(Wersja zapoznawcza) GitHub organizacje powinny wymuszać uwierzytelnianie wieloskładnikowe dla współpracowników zewnętrznych
Opis: Wymuszanie uwierzytelniania wieloskładnikowego dla współpracowników zewnętrznych w organizacji GitHub to środek zabezpieczający, 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.
Istotność: wysoka
(Wersja zapoznawcza) GitHub repozytoria 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.
Istotność: 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.
Istotność: 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ść: średnia
Projekty GitLab powinny mieć rozpoznane wyniki skanowania luk w zabezpieczeniach zależności
Opis: GitHub repozytoria powinny mieć rozwiązane wyniki skanowania luk w zabezpieczeniach pod kątem luk w zabezpieczeniach.
Ważność: średnia
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ść: średnia
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ść: średnia
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 Azure DevOps narzędzie rozwiązania zabezpieczające firmy Microsoft 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)
Istotność: 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ść: średnia
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ść: średnia
GitHub repozytoria powinny mieć włączone skanowanie kodu
Description: 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, 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ść: średnia
GitHub repozytoria powinny mieć włączone skanowanie wpisów tajnych
Description: 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)
Istotność: wysoka
GitHub repozytoria powinny mieć włączone skanowanie Dependabot
Description: 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ść: średnia