Stosowanie nowoczesnych, bezpiecznych frameworków programistycznych w celu zapewnienia bezpiecznych praktyk kodowania na każdym etapie procesu bezpiecznego wytwarzania oprogramowania (SDLC) może znacząco ograniczyć ryzyko oraz podatności związane z tworzeniem aplikacji, zwłaszcza krytyczne podatności zero-day. Do najczęstszych zagrożeń należą cross-site scripting (XSS), SQL injection oraz manipulacja oprogramowaniem, gdy złośliwi aktorzy instalują backdoory w kodzie źródłowym. Startupy mają przewagę nad ugruntowanymi organizacjami, które nie wdrożyły frameworków programistycznych, ponieważ mogą dostosować najlepsze podejście do swoich potrzeb już na wczesnym etapie rozwoju oprogramowania. Z kolei duże organizacje mogą napotkać trudności przy wdrażaniu bezpiecznych frameworków oraz poprawianiu niebezpiecznego kodu po wydaniu oprogramowania lub aplikacji.

Z badania przeprowadzonego przez Dimensional Research wśród 300 specjalistów ds. IT i cyberbezpieczeństwa wynika, że ponad 54% respondentów przyznało, iż ich organizacja świadomie wypuściła oprogramowanie zawierające potencjalne luki bezpieczeństwa. Z kolei zespół badaczy Google Project Zero (GPZ) w 2022 roku odkrył 18 podatności zero-day wynikających z wadliwych poprawek w oprogramowaniu Microsoft Windows, Apple iOS i WebKit, Google Chromium, Pixel oraz Atlassian Confluence. W raporcie Verizon Data Breach Report z 2019 roku stwierdzono, że główną przyczyną naruszeń bezpieczeństwa danych jest niebezpieczne oprogramowanie, odpowiadające za od 26% do 40% wycieków i kradzieży danych. Tegoroczny raport wskazuje, że aplikacje webowe stały się najczęstszym wektorem ataków prowadzących do naruszeń bezpieczeństwa, odpowiadając za 40%–60% incydentów.

Firmy podejmują ogromne ryzyko, publikując oprogramowanie bez odpowiednich zabezpieczeń. Niebezpieczne aplikacje i systemy nadal pozostają główną przyczyną wycieków danych, ponieważ wiele organizacji nie traktuje priorytetowo bezpieczeństwa kodu źródłowego i nie przeznacza na to odpowiedniego budżetu, co prowadzi do wydawania oprogramowania zawierającego podatności. Przykładem tego trendu jest rosnąca popularność platform low-code i no-code, które pozwalają budować aplikacje w środowisku wizualnym, co dla firm oznacza oszczędności związane z zatrudnianiem programistów oraz szybszy proces tworzenia aplikacji. Niestety, takie projekty często realizują osoby bez doświadczenia programistycznego lub bez solidnego zaplecza IT, co może prowadzić do poważnych luk w zabezpieczeniach.

Co więcej, aż 98% respondentów badania Dimensional Research wskazało, że kod dostarczany przez zewnętrznych dostawców, w tym oprogramowanie open-source, zwiększa ryzyko dla łańcucha dostaw.

Startupy mogą minimalizować ryzyko związane z niebezpiecznym kodem, wdrażając nowoczesne, bezpieczne frameworki programistyczne. Do rekomendowanych frameworków należą: NIST Secure Software Development Framework (SSDF), BSA Framework for Secure Software, SAFECode Fundamental Practices for Secure Software Development oraz OWASP Security Knowledge Framework (SKF) – otwartoźródłowy projekt bazujący na OWASP Application Security Verification Standard (ASVS) oraz OWASP Mobile Application Security Verification Standard (MASVS), które zawierają listy kontrolne wspierające proces zabezpieczania aplikacji. Warto podkreślić, że OWASP ASVS jest powszechnie uznawanym standardem weryfikacji bezpieczeństwa aplikacji. Ostatecznie, aby skutecznie podnosić poziom zabezpieczeń, zespoły deweloperskie powinny uwzględniać aspekty bezpieczeństwa na każdym etapie procesu bezpiecznego wytwarzania oprogramowania (SDLC).

Największe ryzyka bezpieczeństwa związane z niebezpiecznym kodem

Niebezpieczny kod oprogramowania wiąże się z różnymi zagrożeniami bezpieczeństwa i podatnościami, które mogą zostać wykorzystane przez złośliwych aktorów. Jednym z głównych ryzyk dla oprogramowania komputerowego jest sytuacja, gdy dane użytkowników są wykonywane tak, jakby były częścią kodu aplikacji. Złośliwy aktor może wstrzyknąć kod JavaScript do aplikacji i uruchomić go w przeglądarce internetowej (np. XSS), aby wyrządzić większe szkody. Każdy wprowadzony do oprogramowania danych może zostać zmanipulowany, co jest niebezpieczne, jeśli nie są one odpowiednio filtrowane lub walidowane.

OWASP Top 10 to regularnie aktualizowany dokument świadomościowy dla programistów i aplikacji webowych, uznawany na całym świecie, który wymienia najistotniejsze zagrożenia bezpieczeństwa dla aplikacji webowych.

OWASP Top 10: 2021 – ryzyka bezpieczeństwa aplikacji webowych

• Złamana kontrola dostępu: Ma miejsce, gdy atakujący pomyślnie wykonuje eskalację uprawnień i omija autoryzację, aby uzyskać dostęp, modyfikować, usuwać lub wykonywać akcje poza zamierzonymi uprawnieniami aplikacji lub systemu.
• Błędy kryptograficzne: Podmiot zewnętrzny (np. aplikacja webowa) ujawnia dane wrażliwe z powodu wad oprogramowania, słabej lub braku szyfrowania, braku haszowania i solenia haseł lub braku włączenia zabezpieczenia HTTPS; może to prowadzić do niewystarczającej ochrony baz danych, niewłaściwego użycia systemów danych lub błędnych konfiguracji. Te podatności mogą stworzyć idealne warunki do wstrzyknięć SQL, umożliwiając atakującym łatwe odczytanie haseł w postaci tekstu jawnego.
• Wstrzyknięcie: Gdy dane użytkownika lub wejście nie są walidowane, filtrowane lub oczyszczane przez aplikację, lub gdy niezaufane dane w postaci zapytań, pól formularzy, nagłówków lub ciasteczek są wysyłane do interpreterów lub wywołują bazy danych, atakujący może wysłać polecenia do bazy danych i oszukać ją, aby wykonała niepożądane akcje, które chce wykonać (zamiast tych, które zaprogramowano). Przykładem jest sytuacja, gdy atakujący wstrzykuje złośliwe dane wejściowe zwane ładunkiem, które zwracają wrażliwe informacje i umożliwiają atakującemu modyfikację lub usunięcie danych, jeśli tego chce. Rodzaje wstrzyknięć to Cross-Site Scripting (XSS) za pomocą JavaScript (najczęściej spotykane), HTML, ActiveX czy Flash na podatnej dynamicznej stronie internetowej. Inne typy to wstrzyknięcie SQL, wstrzyknięcie poleceń systemu operacyjnego oraz wstrzyknięcie LDAP.

• Niezabezpieczony projekt: Wynik niebezpiecznego projektu jest bezpośrednim rezultatem braku 1) modelu zagrożeń, 2) bezpiecznego cyklu życia wytwarzania oprogramowania (SSDLC) oraz, co najważniejsze, 3) odpowiednich zabezpieczeń na etapie planowania. Zespół deweloperów, specjalistów ds. bezpieczeństwa, IT i zapewnienia jakości (QA) w organizacji może nie stworzyć lub nie przewidzieć potrzebnych zabezpieczeń dla konkretnych zagrożeń. Ważne jest, aby nie ignorować projektu na wczesnym etapie rozwoju, ponieważ OWASP stwierdza, że idealna implementacja nie jest w stanie naprawić niebezpiecznego projektu. Jednakże bezpieczny projekt może zawierać wady implementacyjne, które prowadzą do podatnych na wykorzystanie luk. To jest zasadnicza różnica między niebezpiecznym projektem a niebezpieczną implementacją.
• Błędy w konfiguracji bezpieczeństwa: Błędy w konfiguracji zabezpieczeń wynikają z niewłaściwie skonfigurowanych ustawień, takich jak uprawnienia w usługach chmurowych. Niedostateczne wzmocnienie bezpieczeństwa oprogramowania lub aplikacji może również prowadzić do błędów w konfiguracji zabezpieczeń. Błędy w konfiguracji to główne zagrożenie bezpieczeństwa dla Kubernetes – open-source’owej platformy do zarządzania kontenerami. Pięć najczęstszych błędów w konfiguracji bezpieczeństwa w kontenerach Kubernetes to: uruchamianie uprzywilejowanych kontenerów, powiązanie z uprawnieniami cluster-admin, brak polityk zasobów, niezmienny system plików kontenera oraz zablokowane Ingress i Egress.
• Podatne i przestarzałe komponenty: Podatne, nieobsługiwane lub przestarzałe oprogramowanie, w tym brak wiedzy na temat wszystkich wersji komponentów używanych po stronie klienta i serwera (a także zagnieżdżonych zależności), może tworzyć tę lukę. Programiści muszą być na bieżąco, testując kompatybilność zaktualizowanych, zaktualizowanych lub poprawek bibliotek. Niewyczyszczenie nieużywanych lub zbędnych komponentów, a także zależności, funkcji, plików lub dokumentacji, może pozostawić miejsce dla atakujących na ciche uzyskanie dostępu do nich i pozostanie niezauważonym przez długi czas. Do tej sytuacji pasuje dobrze powiedzenie: „Co niewidoczne, nie zaszkodzi” – przynajmniej dopóki nie będzie za późno.
• Błędy identyfikacji i uwierzytelniania: Używanie słabych, niezaszyfrowanych haseł domyślnych to tylko niektóre z przykładów słabości uwierzytelniania. Ponadto brak implementacji dwuskładnikowego uwierzytelniania (2FA) może stworzyć przestrzeń dla ataków siłowych, ataków z użyciem skradzionych danych logowania i ponownego wykorzystania skradzionych poświadczeń. Odwołaj się do tego wpisu, aby dowiedzieć się, jak wdrożyć silne hasła i dwuskładnikowe uwierzytelnianie.
• Błędy integralności oprogramowania i danych: Kod i infrastruktura, które nie chronią przed naruszeniami integralności, mogą prowadzić do błędów integralności oprogramowania i danych. Niebezpieczny proces ciągłej integracji i ciągłego wdrażania (CI/CD) może wprowadzić potencjalne zagrożenie w postaci nieautoryzowanego dostępu, złośliwego kodu lub kompromitacji systemu. Przykładem kodu i infrastruktury, które nie chronią przed naruszeniami integralności, jest sytuacja, w której aplikacja polega na innych wtyczkach, bibliotekach lub modułach z nieznanych źródeł, repozytoriów lub sieci dostarczania treści (CDN). Ponadto automatyczne aktualizacje mogą występować w aplikacjach bez odpowiedniego sprawdzania integralności, co może prowadzić do zainstalowania wcześniej zaufanej aplikacji. Doskonałym przykładem tej sytuacji jest głośna złośliwa aktualizacja SolarWinds, o której można przeczytać tutaj.
• Błędy w logowaniu i monitorowaniu bezpieczeństwa: Niedostateczne logowanie, wykrywanie, monitorowanie i aktywna reakcja mogą powodować te błędy. Logowanie i monitorowanie są kluczowe, ponieważ pomagają wykrywać naruszenia bezpieczeństwa. Logowanie zdarzeń, takich jak udane i nieudane logowania, w tym podejrzana aktywność, może pomóc wykryć zagrożenia tak szybko, jak się pojawią. Muszą być wdrożone alerty dla odpowiednich progów i procesów eskalacji reakcji.
• Błąd Server-Side Request Forgery (SSRF): Błędy SSRF występują, gdy aplikacja internetowa pobiera zdalny zasób bez weryfikacji dostarczonego przez użytkownika adresu URL. Błąd SSRF może umożliwić atakującemu wymuszenie wysłania żądania do nieoczekiwanego celu, nawet gdy ochrona jest zapewniona przez zaporę ogniową, VPN lub inny rodzaj listy kontrolnej dostępu (ACL). SSRF staje się coraz bardziej poważnym zagrożeniem z powodu rosnącego użycia usług chmurowych, w tym złożoności architektur.

Cykl życia oprogramowania (SDLC)

Cykl życia oprogramowania, czyli SDLC, to systematyczny model składający się z kilku etapów projektowania, tworzenia i testowania oprogramowania, które deweloperzy muszą przestrzegać. Etapy te obejmują cały cykl życia oprogramowania, od jego powstania do zakończenia. Ważne jest, aby śledzić te etapy, przyjmując nowoczesne, bezpieczne ramy oprogramowania jako wytyczne. SSDLC, czyli Secure SDLC, pomaga deweloperom przestrzegać zasad bezpiecznego kodowania na każdym etapie rozwoju, od planowania do ostatniego etapu operacji i utrzymania. Przestrzeganie SSDLC pozwala także deweloperom łagodzić luki w oprogramowaniu, które łatwo mogą zostać przeoczone na jakimkolwiek etapie, zapobiegając tym samym wydaniu niebezpiecznego produktu.

7 etapów SDLC:

1. Planowanie: Pierwszy etap to etap planowania, kiedy zespół zaczyna planować projekt. W startupie zespół określa, jakiego rodzaju oprogramowanie chce stworzyć, a następnie wymyśla rozwiązania. Tworzą plan, jak osiągnąć swoje cele. Dodatkowo określają koszt projektu, jak pozyskają finansowanie, czy brakuje im jakichś zasobów, a przede wszystkim harmonogram i czas, jaki będzie potrzebny do zakończenia projektu.
2. Analiza systemów i wymagania: Drugi etap to moment, kiedy startup zaczyna pracować nad problemem lub ocenia potrzebę wprowadzenia zmian. Zespół może określić funkcjonalne wymagania projektu oraz zbadać lub przeanalizować potrzeby użytkowników końcowych. Narzędzia wspierające startupy w tym etapie to inżynieria systemów wspomagana komputerowo (CSA), zbieranie wymagań i analiza strukturalna.
3. Projektowanie i prototypowanie: Trzeci etap to określenie specyfikacji, funkcji i operacji niezbędnych do spełnienia funkcjonalnych wymagań proponowanego systemu. Deweloperzy mogą opracować szczegóły aplikacji, takie jak interfejsy użytkownika i systemu, wymagania dotyczące sieci oraz bazy danych. Dokument SRS (Specyfikacja Wymagań Systemowych) jest opracowywany w bardziej logiczną strukturę i wykorzystywany jako wytyczna do wyboru języka programowania. Budowany jest prototyp, który jest testowany i modyfikowany do momentu osiągnięcia oczekiwanego wyniku. Prototypowanie przyspiesza proces rozwoju i ułatwia pracę analitykom systemowym.
4. Rozwój: Czwarty etap to moment, w którym rozpoczyna się faktyczna praca rozwojowa i rozpoczęcie produkcji. Deweloper lub personel IT, taki jak inżynier sieciowy i/lub deweloper bazy danych, zaczyna realizować główne zadania projektu. Etap ten może obejmować tworzenie wykresów przepływu, aby zapewnić organizację procesu. Skupienie się na szkoleniu zespołu deweloperskiego może być ogromnym atutem w tym etapie.
5. Testowanie: Piąty etap obejmuje integrację systemów i testowanie. Rozpoczynają się testy oprogramowania lub produktu, które zwykle przeprowadza specjalista ds. zapewnienia jakości (QA). Testowanie może być powtarzane kilkakrotnie w celu wykrycia błędów, problemów z działaniem lub wad oprogramowania. Jest to dobry etap na włączenie testów bezpieczeństwa, takich jak testy penetracyjne lub skanowanie kodu źródłowego.
6. Implementacja i integracja: Szósty etap to moment, w którym większość kodu oprogramowania jest zapisywana. Obejmuje wdrożenie nowego systemu i przeniesienie projektu do produkcji przez przeniesienie danych i komponentów ze starego systemu do nowego za pomocą bezpośredniego przełączenia.
7. Operacje i utrzymanie: Siódmy i ostatni etap SDLC to etap utrzymania oraz regularnie wymaganych aktualizacji. Jest to etap, w którym użytkownicy końcowi mogą dostosować system, dodać nowe funkcje lub spełnić dodatkowe wymagania.

Nowoczesne frameworki bezpiecznego wytwarzania oprogramowania

Ponieważ niebezpieczny kod nadal stanowi jedno z największych krytycznych zagrożeń bezpieczeństwa co roku, najlepiej jest rozpocząć wdrażanie frameworka, który pomoże w stosowaniu praktyk bezpiecznego kodowania. Wykorzystanie nowoczesnych frameworków bezpiecznego wytwarzania oprogramowania może poprawić postawę bezpieczeństwa startupu oraz stanowić łatwe do śledzenia wytyczne dla deweloperów i zespołów zajmujących się bezpieczeństwem. Framework może również pomóc Twojemu startupowi w odpowiednim mapowaniu środków kontrolujących bezpieczeństwo i zapobiec wydaniu wysoce niebezpiecznego oprogramowania

Frameworki bezpiecznego wytwarzania oprogramowania

Oto cztery najskuteczniejsze frameworki bezpiecznego wytwarzania oprogramowania. To od Twojego startupu zależy, który z nich będzie odpowiedni do realizacji Twojego projektu.

1) NIST Secure Software Development Framework (SSDF): Framework SSDF opracowany przez NIST opiera się na podstawowych, solidnych i bezpiecznych praktykach wytwarzania oprogramowania, które są zgodne z dokumentami organizacji takich jak BSA, OWASP i SAFECode. Praktyki SSDF muszą być dodane i zintegrowane z każdym wdrożeniem SDLC.

Praktyki SSDF

Zgodnie z informacjami na stronie NIST, praktyki SSDF są uporządkowane w cztery grupy i zdefiniowane następująco:

1. Przygotowanie organizacji (PO): Zapewnienie, że ludzie, procesy i technologie w organizacji wykonują bezpieczne wytwarzanie oprogramowania na poziomie organizacyjnym lub w ramach poszczególnych grup i projektów rozwojowych.
2. Ochrona oprogramowania (PS): Ochrona wszystkich komponentów oprogramowania przed manipulacją i nieautoryzowanym dostępem.
3. Tworzenie dobrze zabezpieczonego oprogramowania (PW): Tworzenie dobrze zabezpieczonego oprogramowania z minimalnymi lukami bezpieczeństwa w jego wydaniach.
4. Reakcja na luki (RV): Identyfikowanie pozostałych luk w oprogramowaniu i odpowiednia reakcja w celu ich usunięcia oraz zapobieganie podobnym problemom w przyszłości.

Każda praktyka jest opisana przez następujące elementy:

• Praktyka: Nazwa praktyki i jej unikalny identyfikator, a następnie krótkie wyjaśnienie, na czym polega ta praktyka i dlaczego jest korzystna.
• Zadanie: Akcja, którą może być konieczne wykonanie, aby wdrożyć konkretną praktykę.
• Przykład implementacji (Notional Implementation Example): Przykład narzędzi, procesów lub innych metod, które pomagają w realizacji zadania.
• Odwołanie: Wskazanie dokumentu z ustaloną praktyką bezpiecznego wytwarzania oprogramowania i jej mapowanie na konkretne zadanie.

Przykład znajduje się w tabeli 1 poniżej.

2) OWASP Security Knowledge Framework (SKF): OWASP SKF to całkowicie open-source’owa aplikacja internetowa, która wykorzystuje OWASP Application Security Verification Standard (ASVS) do wyjaśniania zasad bezpiecznego kodowania w różnych językach programowania. Jej celem jest pomoc deweloperom oraz innym osobom w nauce i wdrażaniu bezpieczeństwa już na etapie projektowania oprogramowania, aby tworzone aplikacje były bezpieczne z założenia. Realizuje to poprzez zarządzane projekty deweloperskie z listami kontrolnymi, takimi jak OWASP-ASVS/OWASP-MASVS. Dodatkowo zawiera laboratoria do ćwiczenia weryfikacji bezpieczeństwa, takie jak SKF-labs czy OWASP Juice-shop. OWASP SKF jest na bieżąco aktualizowane, a jego repozytorium na GitHubie jest dostępne tutaj.

Lista kontrolna OWASP dotycząca bezpiecznego kodowania

Bezpieczeństwo oprogramowania ma na celu utrzymanie poufności, integralności i dostępności informacji, znanej również jako CIA. Osiągnięcie tego celu możliwe jest poprzez wdrażanie kontrol zabezpieczeń, które pomagają łagodzić luki w zabezpieczeniach. Lista kontrolna praktyk bezpiecznego kodowania to skuteczna metoda eliminowania luk w oprogramowaniu w miarę możliwości.

Lista kontrolna OWASP dotycząca bezpiecznego kodowania:

• Walidacja wejścia
• Kodowanie wyjścia
• Uwierzewanie i zarządzanie hasłami
• Zarządzanie sesjami
• Kontrola dostępu
• Praktyki kryptograficzne
• Obsługa błędów i logowanie
• Ochrona danych
• Bezpieczeństwo komunikacji
• Konfiguracja systemu
• Bezpieczeństwo bazy danych
• Zarządzanie plikami
• Zarządzanie pamięcią

OWASP ASVS

OWASP Application Security Verification Standard (ASVS) to dokument składający się z następujących rozdziałów (V1, V2, V3), które zawierają szczegółowe instrukcje dotyczące wymagań zabezpieczeń. Każde wymaganie posiada identyfikator w formacie <rozdział>.<sekcja>.<wymaganie>, gdzie każdy element to liczba, np. 1.11.3. Dla zachowania zwięzłości szczegółowo opiszę jedynie 14 rozdziałów.

14 rozdziałów OWASP ASVS:

• V1 Architektura, projektowanie i modelowanie zagrożeń: Obejmuje podstawowe aspekty solidnej architektury zabezpieczeń: dostępność, poufność, integralność przetwarzania, nieodrzucalność i prywatność. Kładzie nacisk na krytyczną potrzebę „przesunięcia w lewo”, począwszy od programistów, którzy wprowadzają listy kontrolne bezpiecznego kodowania, mentoring, szkolenia, kodowanie, testowanie, budowanie, wdrażanie, konfigurację, operacje oraz niezależne testowanie.
• V2 Uwierzytelnianie: NIST 800-63B to złoty standard uwierzytelniania, który obejmuje hasła i autoryzację dwuetapową. Więcej informacji na ten temat znajduje się w naszym artykule na temat zarządzania hasłami i uwierzytelniania.
• V3 Zarządzanie sesjami: Zapewnia, że aplikacja posiada następujące funkcje zarządzania sesjami: 1) Sesje są unikalne i nie mogą być dzielone ani zgadywane, 2) Czas wygaśnięcia sesji następuje po odpowiednim okresie bezczynności, a sesja staje się nieważna.
• V4 Kontrola dostępu: Ten rozdział ustala wytyczne, które zapewniają, że aplikacja przestrzega określonych wymagań dotyczących kontroli dostępu (np. tylko osoby posiadające odpowiednie poświadczenia mogą uzyskać dostęp do określonych zasobów).
• V5 Walidacja, sanizacja i kodowanie: Obejmuje standardy zapobiegające atakom typu injection, tworząc bezpieczny proces walidacji danych wejściowych, filtracji i kodowania danych wyjściowych.
• V6 Przechowywana kryptografia: Kładzie nacisk na to, że obsługa błędów w aplikacji musi być solidna, a moduły kryptograficzne muszą być awaryjnie bezpieczne, zapewniając bezpieczny dostęp do kluczy kryptograficznych i wykorzystanie generatorów liczb losowych w celu spełnienia wymagań kryptograficznych.
• V7 Obsługa błędów i logowanie: Koncentruje się na właściwym logowaniu i obsłudze błędów.
• V8 Ochrona danych: Poufność, integralność i dostępność (CIA) muszą być zachowane podczas przechowywania i przesyłania danych, dane muszą być chronione i archiwizowane, a dostęp do nich musi być zapewniony wyłącznie uprawnionym użytkownikom.
• V9 Komunikacja: W tym rozdziale znajdują się wskazówki dla programistów dotyczące stosowania silnego szyfrowania lub zabezpieczeń warstwy transportu przez cały czas oraz zalecenia dotyczące używania najnowszych algorytmów konfiguracji i wyłączania wszystkich niebezpiecznych algorytmów i szyfrów w celu utrzymania bezpieczeństwa danych aplikacji.
• V10 Złośliwy kod: Określa wymagania dotyczące kodu, które muszą być spełnione. Złośliwa aktywność w kodzie musi być obsługiwana w sposób bezpieczny i prawidłowy, aby nie miała wpływu na resztę organizacji. Ataki czasowe, bomby czasowe, nieautoryzowany kod lub backdoory muszą być eliminowane.
• V11 Logika biznesowa: Opisuje, jak przestrzegać wymagań logiki biznesowej, aby złośliwi aktorzy nie mogli ich obejść.
• V12 Pliki i zasoby: Wyjaśnia, jak dane pochodzące z niezaufanych źródeł są obsługiwane zgodnie z regulacjami i jak dane z zewnętrznych oraz niezaufanych źródeł muszą być przechowywane poza katalogiem webroot oraz posiadać ograniczone uprawnienia.
• V13 API i usługi internetowe: Zawiera zalecenia dotyczące API w aplikacjach: API muszą mieć odpowiednią autoryzację, niezbędne parametry zarządzania sesjami oraz uwierzytelnianie w celu uzyskania dostępu do wszystkich usług internetowych. Zawiera również zalecenia dotyczące właściwej walidacji danych wejściowych i kontroli bezpieczeństwa.
• V14 Konfiguracja: Ten rozdział obejmuje szereg wymagań dotyczących konfiguracji. Zapewnia, że zweryfikowana aplikacja posiada bezpieczne, powtarzalne i automatyzowalne środowisko budowania. Aplikacja musi posiadać wzmocnioną bibliotekę stron trzecich oraz odpowiedni system zarządzania konfiguracją i zależnościami, aby filtruj przestarzałe lub niebezpieczne komponenty.

3) BSA Framework for Secure Software: BSA Framework for Secure Software jest podzielony na sześć kolumn: Funkcje, Kategorie, Podkategorie, Oświadczenia diagnostyczne, Wdrażanie, Uwagi i Odniesienia informacyjne. Ma na celu ustanowienie elastycznego, adaptowalnego, nastawionego na wyniki, opartego na ryzyku, opłacalnego i powtarzalnego podejścia do bezpieczeństwa oprogramowania. Określa najlepsze praktyki związane z procesami organizacyjnymi i możliwościami produktów w całym cyklu życia oprogramowania (SDLC).

Funkcje

Funkcje organizują podstawowe działania związane z bezpieczeństwem oprogramowania na najwyższym poziomie, zgodnie z SDLC.

Funkcje ram frameworku:

• Bezpieczny rozwój: Dotyczy bezpieczeństwa w fazie rozwoju oprogramowania, kiedy projekt oprogramowania jest koncepcyjnie tworzony, inicjowany, rozwijany i wprowadzany na rynek.
• Bezpieczne możliwości: Określa kluczowe cechy bezpieczeństwa zalecane dla produktu oprogramowania.
• Bezpieczny cykl życia: Funkcja ta dotyczy zagadnień związanych z utrzymaniem bezpieczeństwa w produkcie oprogramowania od jego powstania aż do końca jego życia.

Kategorie

Kategorie dzielą funkcję na wyodrębnione rozważania i dyscypliny, które są istotne dla danej funkcji. Kategorie mogą być łączone z innymi kategoriami, takimi jak „Zarządzanie podatnościami” lub „Powiadamianie o podatnościach i łatanie”.

Podkategorie

Podkategorie dzielą kategorię na wyodrębnione, jednostkowe pojęcia wyrażające zidentyfikowane najlepsze praktyki związane z bezpieczeństwem oprogramowania.

Oświadczenia diagnostyczne

Oświadczenia diagnostyczne identyfikują konkretne, weryfikowalne wyniki. Dostarczają zestaw wyników wspierających osiągnięcie rezultatów dla każdej kategorii.

Uwagi dotyczące wdrażania

Dostarczają dodatkowych informacji, gdy to konieczne, takich jak przykłady, jak organizacje mogą osiągnąć cele bezpieczeństwa opisane w oświadczeniach diagnostycznych, interpretacje tego, jak oświadczenia diagnostyczne mogą być stosowane w różnych środowiskach rozwoju oraz wytyczne dotyczące dostosowywania wdrożenia do ryzyka.

Źródła informacyjne

Są to dodatkowe zasoby, które identyfikują i opisują najlepsze praktyki, wytyczne lub dodatkowe informacje dotyczące wdrażania powiązanego Oświadczenia Diagnostycznego.

Framework BSA Software Security Fundamentals opiera się na pięciu podstawowych zasadach:

1. Oparte na ryzyku
2. Skoncentrowane na wynikach
3. Elastyczne
4. Dostosowalne
5. Zgodne z międzynarodowo uznawanymi standardami

These are additional resources that identify and describe best practices, guidelines, or further information for implementing an associated Diagnostic Statement. 

4) SAFECode: Podstawową zasadą frameworku SAFECode jest ocena zapewnienia bezpieczeństwa oprogramowania, która koncentruje się głównie na procesie bezpiecznego wytwarzania oprogramowania i jego zastosowaniu do produktu będącego przedmiotem oceny, uwzględniając kontekst środowiska operacyjnego, w jakim dany produkt ma funkcjonować. Żadna pojedyncza praktyka, narzędzie czy lista kontrolna nie stanowi „złotego środka” gwarantującego lepsze zapewnienie bezpieczeństwa oprogramowania.

Zasady przewodnie dla oceny bezpieczeństwa oprogramowania 

1. Zapewnienie bezpieczeństwa oprogramowania nie jest osiągane przez pojedynczą praktykę, narzędzie czy listę kontrolną; wynika ono z kompleksowego, bezpiecznego procesu inżynierii oprogramowania.
2. Należy zastosować podejście wielowarstwowe do oceny bezpieczeństwa nabytego oprogramowania, oparte na dojrzałości dostawcy technologii opracowującego to oprogramowanie.
3. Bieżące problemy, przed którymi stają wielu klientów i dostawców, wymagają pilnego rozwiązania w krótkim okresie oraz kompleksowych, szeroko akceptowanych międzynarodowych standardów w średnim lub długim okresie.
4. Klienci mogą wymagać dowodów na poparcie roszczeń dostawcy.
5. Klienci potrzebują wglądu w procesy zapewnienia bezpieczeństwa na poziomie korporacyjnym i produktowym, aby wspierać swoje potrzeby w zakresie zarządzania ryzykiem.

Rysunek 1: Przegląd frameworku oceny SAFECode

Trzypoziomowe podejście do oceny (Three-Tier Assessment Approach)

Jeśli dostawca nie posiada dojrzałego procesu zapewnienia bezpieczeństwa oprogramowania lub nie jest w stanie udzielić informacji na temat tego procesu, to narzędzia testowe lub inne techniki testowania produktów w celu wykrycia wad bezpieczeństwa w kodzie produktu mogą stanowić podstawę oceny. To podejście to Trzypoziomowe podejście do oceny (Three-Tier Assessment Approach), które jest skuteczne w wykrywaniu wad bezpieczeństwa i może dać klientowi pewność co do bezpieczeństwa produktu. (Zob. ocenę w trzech poziomach na Rysunku 1.)

Ocena dwupoziomowa (Two-Tier Assessment

Jeśli standard przemysłowy nie ma zastosowania, ocena powinna opierać się na aktualnych i dobrze zrozumianych najlepszych praktykach branżowych (ocena drugiego poziomu na Rysunku 1).

Jednopoziomowa ocena (Tier-One Assessment)

Załóżmy, że klient stwierdza, że jego wymagania dotyczące zarządzania ryzykiem wymagają wysokiego stopnia pewności w zakresie zapewnienia dla konkretnej aplikacji oprogramowania, a dostawca posiada dojrzały, bezpieczny proces tworzenia oprogramowania; może on udostępnić wgląd w swoją metodologię bezpieczeństwa oprogramowania. W takim przypadku zaleca się podejście oparte na procesie oceny. Jeśli międzynarodowy standard jest dostępny i ma zastosowanie do dostawcy, to standard ten powinien wyznaczać zakres oceny (ocena pierwszego poziomu na Rysunku 1).

Podsumowanie

Startup musi przestrzegać nowoczesnego frameworku bezpieczeństwa oprogramowania, aby zapewnić, że deweloperzy będą stosować wytyczne dotyczące najlepszych praktyk bezpiecznego kodowania w trakcie cyklu życia oprogramowania (SDLC). W rzeczywistości żaden pojedynczy framework ani lista kontrolna nie stanowią srebrnej kuli, która zapewnia maksymalne bezpieczeństwo na wszystkich poziomach. Niemniej jednak, może to znacząco zmniejszyć luki w bezpieczeństwie i wyeliminować niedbałe błędy, takie jak wydanie produktu lub aplikacji z niebezpiecznym kodem bez jego wcześniejszego przeglądu. Startup może uniknąć katastrofy finansowej lub naruszenia danych, zapobiegając najważniejszym ryzykom bezpieczeństwa, które wciąż wpływają na oprogramowanie. Dzięki odpowiedniemu podejściu do bezpieczeństwa oprogramowania, startupy mogą poprawić swoje zabezpieczenia i zapewnić zdrową ciągłość biznesową.

Źródła:

1. https://dzone.com/articles/low-code-and-no-code-the-security-challenge
2. https://www.zdnet.com/article/google-half-of-zero-day-exploits-linked-to-poor-software-fixes/
3. https://www.reversinglabs.com/newsroom/press-releases/survey-software-supply-chain-risk-software-tampering
4. https://owasp.org/www-project-top-ten/
5. https://thenewstack.io/armo-misconfiguration-is-number-1-kubernetes-security-risk/
6. https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everything-you-need-to-know
7. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
8. https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf