Zalecenia dotyczące zabezpieczania cyklu życia programowania

  • Artykuł

Dotyczy tego zalecenia listy kontrolnej dotyczącej zabezpieczeń platformy Azure Well-Architected Framework:

SE:02 Zachowaj bezpieczny cykl projektowania przy użyciu wzmocnionego, głównie zautomatyzowanego i kontrolowanego łańcucha dostaw oprogramowania. Uwzględnij bezpieczny projekt przy użyciu modelowania zagrożeń w celu ochrony przed implementacjami, które są pokonane przez zabezpieczenia.

Powiązany przewodnik: Analiza zagrożeń

W tym przewodniku opisano zalecenia dotyczące wzmacniania poziomu kodu, środowiska programistycznego i łańcucha dostaw oprogramowania przez zastosowanie najlepszych rozwiązań w zakresie zabezpieczeń w całym cyklu programowania. Aby zrozumieć te wskazówki, musisz mieć wiedzę na temat metodyki DevSecOps.

Diagram cyklu zabezpieczeń.

Usługa DevSecOps integruje zabezpieczenia z procesami DevOps przez:

  • Automatyzowanie testowania i walidacji zabezpieczeń.

  • Implementowanie narzędzi takich jak potoki zabezpieczeń w celu skanowania kodu i infrastruktury jako kodu (IaC) pod kątem luk w zabezpieczeniach.

Podstawowym elementem obciążenia jest kod aplikacji, który implementuje logikę biznesową. Kod i proces tworzenia kodu muszą być wolne od wad zabezpieczeń, aby zapewnić poufność, integralność i dostępność.

Nie wystarczy zabezpieczyć tylko płaszczyznę infrastruktury przy użyciu kontrolek dotyczących tożsamości i sieci i innych miar. Zapobiegaj nieprawidłowej implementacji kodu lub naruszonego bloku kodu w celu wzmocnienia ogólnego poziomu zabezpieczeń. Płaszczyzna użycia, czyli kod aplikacji, musi być również wzmocniona. Proces integrowania zabezpieczeń z cyklem życia programowania jest zasadniczo procesem wzmacniania zabezpieczeń. Podobnie jak w przypadku wzmacniania zabezpieczeń zasobów, zaostrzenie tworzenia kodu jest również niezależne od kontekstu. Celem jest zwiększenie zabezpieczeń, a nie wymagań funkcjonalnych aplikacji. Aby uzyskać informacje dotyczące wzmacniania zabezpieczeń, zobacz Zalecenia dotyczące wzmacniania zabezpieczeń zasobów.

Definicje

Okres Definicja
Security Development Lifecycle (SDL) Zestaw rozwiązań oferowanych przez firmę Microsoft, który obsługuje wymagania dotyczące zapewniania zabezpieczeń i zgodności.
Cykl życia tworzenia oprogramowania (SDLC) Wieloestowy, systematyczny proces tworzenia systemów oprogramowania.

Kluczowe strategie projektowania

Środki zabezpieczeń należy zintegrować w wielu punktach z istniejącym cyklem życia tworzenia oprogramowania (SDLC), aby zapewnić:

  • Wybory projektowe nie prowadzą do luk w zabezpieczeniach.

  • Kod aplikacji i konfiguracja nie tworzą luk w zabezpieczeniach z powodu implementacji możliwej do wykorzystania i nieprawidłowych praktyk kodowania.

  • Oprogramowanie pozyskane za pośrednictwem łańcucha dostaw nie wprowadza zagrożeń bezpieczeństwa.

  • Procesy tworzenia i wdrażania kodu aplikacji nie są modyfikowane.

  • Luki w zabezpieczeniach ujawnione za pośrednictwem zdarzeń są ograniczane.

  • Nieużywane zasoby są prawidłowo zlikwidowane.

  • Wymagania dotyczące zgodności nie są naruszone ani ograniczone.

  • Rejestrowanie inspekcji jest implementowane w środowiskach deweloperskich.

W poniższych sekcjach przedstawiono strategie zabezpieczeń dla często praktykowanych faz SDLC.

Zbieranie i dokumentowanie wymagań dotyczących zabezpieczeń

Celem fazy wymagań jest zebranie i przeanalizowanie funkcjonalnych i niefunkcjonalnych wymagań aplikacji lub nowej funkcji aplikacji. Ta faza jest ważna, ponieważ ułatwia tworzenie barier zabezpieczających dostosowanych do celów aplikacji. Ochrona danych i integralności aplikacji powinna być podstawowym wymaganiem w każdej fazie cyklu projektowania.

Rozważmy na przykład aplikację, która musi obsługiwać krytyczne przepływy użytkowników, które umożliwiają użytkownikowi przekazywanie danych i manipulowanie nimi. Opcje projektowania zabezpieczeń powinny obejmować gwarancje interakcji użytkownika z aplikacją, takie jak uwierzytelnianie i autoryzowanie tożsamości użytkownika, zezwalanie tylko na dozwolone akcje na danych i zapobieganie wstrzyknięciu kodu SQL. Podobnie należy uwzględnić wymagania niefunkcjonalne, takie jak dostępność, skalowalność i możliwość konserwacji. Opcje zabezpieczeń powinny obejmować granice segmentacji, ruch przychodzący i wychodzący zapory oraz inne kwestie związane z zabezpieczeniami.

Wszystkie te decyzje powinny prowadzić do dobrej definicji stanu zabezpieczeń aplikacji. Udokumentowanie wymagań dotyczących zabezpieczeń w uzgodnionej specyfikacji i odzwierciedlenie ich na liście prac. Powinno to wyraźnie określać inwestycje w zabezpieczenia oraz kompromisy i zagrożenia, które firma chce podjąć, jeśli inwestycje nie zostaną zatwierdzone przez zainteresowanych stron biznesowych. Możesz na przykład udokumentować konieczność używania zapory aplikacji internetowej (WAF) przed aplikacją, takiej jak usługa Azure Front Door lub aplikacja systemu Azure Gateway. Jeśli osoby biorące udział w projekcie biznesowym nie są przygotowane do zaakceptowania dodatkowych kosztów uruchamiania zapory aplikacji internetowej, muszą zaakceptować ryzyko, że ataki w warstwie aplikacji mogą być kierowane do aplikacji.

Zbieranie wymagań dotyczących zabezpieczeń jest krytyczną częścią tej fazy. Bez tego nakładu pracy fazy projektowania i implementacji będą oparte na niestated wyborach, co może prowadzić do luk w zabezpieczeniach. Może być konieczne późniejsze zmianę implementacji w celu uwzględnienia zabezpieczeń, co może być kosztowne.

Tłumaczenie wymagań dotyczących zabezpieczeń na wymagania techniczne

W fazie projektowania wymagania dotyczące zabezpieczeń są konwertowane na wymagania techniczne. W specyfikacji technicznej udokumentuj wszystkie decyzje projektowe, aby zapobiec niejednoznaczności podczas implementacji. Oto kilka typowych zadań:

Definiowanie wymiaru zabezpieczeń architektury systemu

Nakładanie architektury za pomocą mechanizmów kontroli zabezpieczeń. Na przykład kontrolki, które są praktyczne w granicach izolacji dla strategii segmentacji, typy tożsamości wymaganych dla składników aplikacji i typ metod szyfrowania do użycia. Aby zapoznać się z przykładowymi architekturami, zobacz ilustracje w sekcjach Przykład w artykułach Zarządzanie tożsamościami i dostępem oraz Sieć .

Ocena zapewnianych przez platformę dostępności

Ważne jest, aby zrozumieć podział odpowiedzialności między Tobą a dostawcą usług w chmurze. Unikaj nakładania się na siebie natywne mechanizmy zabezpieczeń platformy Azure, na przykład. Uzyskasz lepsze pokrycie zabezpieczeń i będziesz w stanie przydzielić zasoby programistyczne do potrzeb aplikacji.

Jeśli na przykład projekt wywołuje zaporę aplikacji internetowej w ruchu przychodzącym, możesz odciążyć tę odpowiedzialność za moduł równoważenia obciążenia, taki jak Application Gateway lub Azure Front Door. Unikaj replikowania funkcji jako kodu niestandardowego w aplikacji.

Wybierz tylko zaufane struktury, biblioteki i oprogramowanie łańcucha dostaw. Projekt powinien również określać bezpieczną kontrolę wersji. Zależności aplikacji powinny być pozyskiwane od zaufanych firm. Zewnętrzni dostawcy powinni być w stanie spełnić wymagania dotyczące zabezpieczeń i udostępnić swój plan odpowiedzialnego ujawnienia. Wszelkie zdarzenia zabezpieczeń powinny być natychmiast zgłaszane, aby można było podjąć niezbędne działania. Ponadto niektóre biblioteki mogą być zabronione przez Organizację. Na przykład oprogramowanie może być bezpieczne przed lukami w zabezpieczeniach, ale nadal jest niedozwolone z powodu ograniczeń licencjonowania.

Aby upewnić się, że te wskazówki są zgodne ze wszystkimi współautorami oprogramowania, należy zachować listę zatwierdzonych i/lub niezatwierdzonych struktur, bibliotek i dostawców. Jeśli to możliwe, umieść zabezpieczenia w potokach programowania, aby obsługiwać listę. Jak najwięcej, zautomatyzuj korzystanie z narzędzi do skanowania zależności pod kątem luk w zabezpieczeniach.

Określ wzorce projektowe zabezpieczeń, które powinien implementować kod aplikacji.

Wzorce mogą obsługiwać obawy dotyczące zabezpieczeń, takie jak segmentacja i izolacja, silna autoryzacja, jednolite zabezpieczenia aplikacji i nowoczesne protokoły. Niektóre wzorce operacyjne, takie jak wzorzec kwarantanny, mogą pomóc zweryfikować i zablokować użycie oprogramowania, które może potencjalnie wprowadzić luki w zabezpieczeniach.

Aby uzyskać więcej informacji, zobacz Wzorce projektowe chmury, które obsługują zabezpieczenia.

Bezpieczne przechowywanie wpisów tajnych aplikacji

Bezpiecznie zaimplementuj użycie wpisów tajnych aplikacji i wstępnie udostępnionych kluczy używanych przez aplikację. Poświadczenia i wpisy tajne aplikacji nigdy nie powinny być przechowywane w drzewie kodu źródłowego. Użyj zasobów zewnętrznych, takich jak usługa Azure Key Vault, aby upewnić się, że jeśli kod źródłowy stanie się dostępny dla potencjalnego atakującego, nie można uzyskać dodatkowego dostępu. Ogólnie rzecz biorąc, znajdź sposoby uniknięcia wpisów tajnych. Użycie tożsamości zarządzanych, jeśli to możliwe, jest jednym ze sposobów osiągnięcia tego celu. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące zarządzania wpisami tajnymi aplikacji.

Definiowanie planów testów

Zdefiniuj jasne przypadki testowe pod kątem wymagań dotyczących zabezpieczeń. Oceń, czy możesz zautomatyzować te testy w potokach. Jeśli twój zespół ma procesy do testowania ręcznego, uwzględnij wymagania dotyczące zabezpieczeń dla tych testów.

Uwaga

Wykonaj modelowanie zagrożeń w tej fazie. Modelowanie zagrożeń może potwierdzić, że wybory projektowe są zgodne z wymaganiami dotyczącymi zabezpieczeń i uwidaczniają luki, które należy ograniczyć. Jeśli obciążenie obsługuje wysoce poufne dane, zainwestuj w ekspertów ds. zabezpieczeń, którzy mogą pomóc w przeprowadzaniu modelowania zagrożeń.

Początkowe ćwiczenie modelowania zagrożeń powinno nastąpić w fazie projektowania, gdy jest definiowana architektura oprogramowania i projekt wysokiego poziomu. Wykonanie tej czynności w tej fazie pomaga zidentyfikować potencjalne problemy z zabezpieczeniami przed ich włączeniem do struktury systemu. Jednak to ćwiczenie nie jest jednorazowym działaniem. Jest to ciągły proces, który powinien być kontynuowany w trakcie ewolucji oprogramowania.

Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące analizy zagrożeń.

Bezpieczne praktyki programistyczne i testowe

W fazie programowania i testowania celem jest zapobieganie wadom zabezpieczeń i manipulowaniu w potokach kodu, kompilowania i wdrażania.

Dobrze wytrenowane w bezpiecznych rozwiązaniach dotyczących kodu

Zespół programistyczny powinien mieć formalne i wyspecjalizowane szkolenia w zakresie bezpiecznych praktyk kodowania. Na przykład deweloperzy sieci Web i interfejsu API mogą potrzebować określonego szkolenia w celu ochrony przed atakami skryptowymi między witrynami, a deweloperzy zaplecza mogą skorzystać ze szczegółowego szkolenia, aby uniknąć ataków na poziomie bazy danych, takich jak ataki polegających na wstrzyknięciu kodu SQL.

Deweloperzy powinni być zobowiązani do ukończenia tego szkolenia, zanim będą mogli uzyskać dostęp do produkcyjnego kodu źródłowego.

Należy również wykonywać wewnętrzne przeglądy kodu równorzędnego w celu promowania ciągłego uczenia.

Korzystanie z narzędzi do testowania zabezpieczeń

Wykonaj modelowanie zagrożeń, aby ocenić zabezpieczenia architektury aplikacji.

Użyj statycznego testowania zabezpieczeń aplikacji (SAST), aby przeanalizować kod pod kątem luk w zabezpieczeniach. Zintegruj tę metodologię ze środowiskiem deweloperów, aby wykrywać luki w zabezpieczeniach w czasie rzeczywistym.

Użyj dynamicznego testowania zabezpieczeń aplikacji (DAST) podczas wykonywania. Ten łańcuch narzędzi może sprawdzać błędy w domenach zabezpieczeń i symulować zestaw ataków w celu przetestowania odporności zabezpieczeń aplikacji. Jeśli to możliwe, zintegruj to narzędzie z potokami kompilacji.

Przestrzegaj standardów branżowych na potrzeby bezpiecznych praktyk kodowania. Aby uzyskać więcej informacji, zobacz sekcję Zasoby społeczności w tym artykule.

Użyj składników linters i analizatorów kodu, aby zapobiec wypchnięciu poświadczeń do repozytorium kodu źródłowego. Na przykład analizatory platformy kompilatora .NET (Roslyn) sprawdzają kod aplikacji.

Podczas procesu kompilacji użyj dodatków potoku, aby przechwycić poświadczenia w kodzie źródłowym. Skanuj wszystkie zależności, takie jak biblioteki innych firm i składniki struktury, w ramach procesu ciągłej integracji. Badanie składników podatnych na zagrożenia oflagowanych przez narzędzie. Połącz to zadanie z innymi zadaniami skanowania kodu, które sprawdzają współczynnik zmian kodu, wyniki testów i pokrycie.

Użyj kombinacji testów. Aby uzyskać ogólne informacje na temat testowania zabezpieczeń, zobacz Zalecenia dotyczące testowania zabezpieczeń.

Pisanie wystarczającej ilości kodu

Zmniejszenie śladu kodu zmniejsza również prawdopodobieństwo wystąpienia wad zabezpieczeń. Użyj ponownie kodu i bibliotek, które są już używane i zostały za pomocą weryfikacji zabezpieczeń zamiast duplikowania kodu.

Korzystanie z funkcji platformy Azure to inny sposób zapobiegania niepotrzebnemu kodowi. Jednym ze sposobów jest korzystanie z usług zarządzanych. Aby uzyskać więcej informacji, zobacz Używanie opcji platformy jako usługi (PaaS).

Domyślnie napisz kod z podejściem odmów wszystkich. Utwórz listy dozwolonych tylko dla jednostek, które wymagają dostępu. Jeśli na przykład masz kod, który musi określić, czy ma być dozwolona operacja uprzywilejowana, należy napisać go tak, aby wynik odmowy był domyślnym przypadkiem, a wynik zezwalania występuje tylko wtedy, gdy jest to dozwolone przez kod.

Ochrona środowisk deweloperskich

Aby zapobiec narażeniu, stacje robocze deweloperów muszą być chronione za pomocą silnych mechanizmów kontroli sieci i tożsamości. Upewnij się, że aktualizacje zabezpieczeń są stosowane pilnie.

Agenci kompilacji są wysoce uprzywilejowani i mają dostęp do serwera kompilacji i kodu. Muszą one być chronione za pomocą tej samej platformy co składniki obciążenia. Oznacza to, że dostęp do agentów kompilacji musi być uwierzytelniony i autoryzowany, powinny być podzielone na segmenty sieciowe za pomocą kontrolek zapory, powinny podlegać skanowaniu luk w zabezpieczeniach itd. Agenci kompilacji hostowani przez firmę Microsoft powinni być preferowani przez własnych agentów kompilacji. Agenci hostowani przez firmę Microsoft zapewniają korzyści, takie jak czyste maszyny wirtualne dla każdego uruchomienia potoku.

Agenci kompilacji niestandardowej dodają złożoność zarządzania i mogą stać się wektorem ataku. Poświadczenia maszyny kompilacji muszą być bezpiecznie przechowywane i należy regularnie usuwać wszelkie tymczasowe artefakty kompilacji z systemu plików. Izolację sieci można osiągnąć, zezwalając tylko na ruch wychodzący z agenta kompilacji, ponieważ używa modelu ściągania komunikacji z usługą Azure DevOps.

Ponadto należy zabezpieczyć repozytorium kodu źródłowego. Udzielanie dostępu do repozytoriów kodu na zasadzie konieczności znajomości i zmniejszanie narażenia na luki w zabezpieczeniach, jak najwięcej, aby uniknąć ataków. Zapoznaj się z dokładnym procesem przeglądania kodu pod kątem luk w zabezpieczeniach. W tym celu użyj grup zabezpieczeń i zaimplementuj proces zatwierdzania oparty na uzasadnieniach biznesowych.

Ochrona kodu w potokach wdrażania

Nie wystarczy tylko zabezpieczyć kod. Jeśli działa w potokach możliwych do wykorzystania, wszystkie działania związane z zabezpieczeniami są daremne i niekompletne. Środowiska kompilacji i wydania muszą być również chronione , ponieważ chcesz uniemożliwić złym aktorom uruchamianie złośliwego kodu w potoku.

Utrzymywanie aktualnego spisu każdego składnika zintegrowanego z aplikacją

Każdy nowy składnik zintegrowany z aplikacją zwiększa obszar ataków. Aby zapewnić właściwą odpowiedzialność i alerty podczas dodawania lub aktualizowania nowych składników, należy mieć spis tych składników. Przechowuj je poza środowiskiem kompilacji. Regularnie sprawdzaj, czy manifest pasuje do tego, co znajduje się w procesie kompilacji. Dzięki temu nie zostaną nieoczekiwanie dodane żadne nowe składniki, które zawierają tylne drzwi lub inne złośliwe oprogramowanie.

Zadania potoku

  • Ściąganie zadań w potoku z zaufanych źródeł, takich jak witryna Azure Marketplace. Uruchamianie zadań napisanych przez dostawcę potoku. Zalecamy wykonywanie zadań usługi GitHub lub funkcji GitHub Actions. Jeśli używasz przepływów pracy usługi GitHub, preferuj zadania utworzone przez firmę Microsoft. Ponadto zweryfikuj zadania, ponieważ są one uruchamiane w kontekście zabezpieczeń potoku.

  • Wpisy tajne potoku. Zasoby wdrażania uruchamiane wewnątrz potoku mają dostęp do wszystkich wpisów tajnych w tym potoku. Aby uniknąć niepotrzebnego narażenia, należy zapewnić odpowiednią segmentację dla różnych etapów potoku . Używaj magazynów wpisów tajnych wbudowanych w potok. Pamiętaj, że w niektórych sytuacjach można unikać używania wpisów tajnych. Zapoznaj się z użyciem tożsamości obciążeń (na potrzeby uwierzytelniania potoku) i tożsamościami zarządzanymi (na potrzeby uwierzytelniania między usługami).

Zachowaj oddzielne środowiska

Dane używane w różnych środowiskach muszą być oddzielone. Dane produkcyjne nie powinny być używane w niższych środowiskach , ponieważ te środowiska mogą nie mieć rygorystycznych mechanizmów kontroli zabezpieczeń, które ma produkcja. Unikaj nawiązywania połączenia z aplikacji nieprodukcyjnej z produkcyjną bazą danych i unikaj łączenia składników nieprodukcyjnych z sieciami produkcyjnymi.

Progresywne narażenie

Użyj progresywnej ekspozycji, aby wydać funkcje do podzbioru użytkowników na podstawie wybranych kryteriów. Jeśli występują problemy, wpływ zostanie zminimalizowany dla tych użytkowników. Takie podejście jest wspólną strategią ograniczania ryzyka, ponieważ zmniejsza obszar powierzchni. Ponieważ funkcja dojrzała i masz większe zaufanie do gwarancji bezpieczeństwa, możesz stopniowo wydać ją do szerszego zestawu użytkowników.

Ochrona kodu w środowisku produkcyjnym

Faza produkcji przedstawia ostatnią odpowiedzialność za rozwiązanie luk w zabezpieczeniach. Zachowaj rekord złotego obrazu opublikowanego w środowisku produkcyjnym.

Zachowaj wersjonowane artefakty

Zachowaj katalog wszystkich wdrożonych zasobów i ich wersji. Te informacje są przydatne podczas klasyfikacji zdarzeń, rozwiązywania problemów i powrotu systemu do stanu roboczego. Wersjonowane zasoby można również porównać z opublikowanymi powiadomieniami o typowych lukach w zabezpieczeniach i zagrożeniach (CVE). Aby wykonać te porównania, należy użyć automatyzacji.

Poprawki awaryjne

Projekt zautomatyzowanego potoku powinien mieć elastyczność obsługi zarówno regularnych, jak i awaryjnych wdrożeń. Ta elastyczność jest ważna, aby obsługiwać szybkie i odpowiedzialne poprawki zabezpieczeń.

Wydanie jest zwykle skojarzone z wieloma bramami zatwierdzania. Rozważ utworzenie procesu awaryjnego w celu przyspieszenia poprawek zabezpieczeń. Proces może obejmować komunikację między zespołami. Potok powinien umożliwiać szybkie wdrażanie wycofywania i wycofywania, które dotyczą poprawek zabezpieczeń, krytycznych usterek i aktualizacji kodu, które występują poza regularnym cyklem życia wdrażania.

Uwaga

Zawsze ustalaj priorytety poprawek zabezpieczeń nad wygodą. Poprawka zabezpieczeń nie powinna wprowadzać regresji ani usterki. Jeśli chcesz przyspieszyć poprawkę za pośrednictwem potoku awaryjnego, należy dokładnie rozważyć, które testy automatyczne można pominąć. Oceń wartość każdego testu względem czasu wykonywania. Na przykład testy jednostkowe zwykle kończą się szybko. Integracja lub kompleksowe testy mogą być uruchamiane przez długi czas.

Utrzymywanie zabezpieczeń kodu w całym cyklu życia

Celem tej fazy jest upewnienie się, że stan zabezpieczeń nie ulega rozkładowi w czasie. SDLC to ciągły proces agile. Pojęcia omówione w poprzednich fazach dotyczą tej fazy, ponieważ wymagania zmieniają się w czasie.

Zarządzanie poprawkami. Aktualizuj oprogramowanie, biblioteki i składniki infrastruktury przy użyciu poprawek zabezpieczeń i aktualizacji.

Ciągłe ulepszanie. Ciągła ocena i poprawa bezpieczeństwa procesu tworzenia oprogramowania dzięki uwzględnieniu przeglądów kodu, opinii, lekcji wyciągniętych i zmieniających się zagrożeń.

Likwiduj starsze zasoby , które są nieaktualne lub nie są już używane. W ten sposób zmniejsza obszar powierzchni aplikacji.

Konserwacja obejmuje również poprawki zdarzeń. Jeśli problemy zostaną znalezione w środowisku produkcyjnym, należy je szybko zintegrować z powrotem z procesem, aby nie powtarzały się.

Stale ulepszaj bezpieczne praktyki kodowania, aby nadążyć za zagrożeniami.

Ułatwienia platformy Azure

Cykl życia programowania zabezpieczeń firmy Microsoft (SDL) zaleca bezpieczne rozwiązania, które można zastosować do cyklu projektowania. Aby uzyskać więcej informacji, zobacz Cykl projektowania zabezpieczeń firmy Microsoft.

Usługa Defender for DevOps i narzędzia SAST są dołączone do usługi GitHub Advanced Security lub Azure DevOps. Te narzędzia mogą pomóc w śledzeniu wskaźnika zabezpieczeń dla organizacji.

Postępuj zgodnie z zaleceniami dotyczącymi zabezpieczeń platformy Azure opisanymi w następujących zasobach:

Aby znaleźć poświadczenia w kodzie źródłowym, rozważ użycie narzędzi, takich jak GitHub Advanced Security i narzędzia do analizy kodu źródłowego OWASP.

Zweryfikuj zabezpieczenia dowolnego kodu open source w aplikacji. Te bezpłatne narzędzia i zasoby mogą pomóc w ocenie:

Lista kontrolna zabezpieczeń

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna zabezpieczeń