Nawet w sytuacji, gdy coraz więcej firm integruje narzędzia automatycznego testowania bezpieczeństwa aplikacji w procesach CI / CD (ang. continuous integration and deployment), rezultaty mogą nie być od razu widoczne z uwagi na ilość błędów trafiających do produkcji w wyniku świadomych decyzji programistów.

W sierpniu br. firma Enterprise Strategy Group opublikowała wyniki badania przeprowadzonego na zamówienie Veracode na grupie prawie 400 północnoamerykańskich programistów i specjalistów ds. bezpieczeństwa aplikacji. Wynika z niego, że wiele organizacji świadomie decyduje się na produkcyjne wdrażanie oprogramowania zawierającego błędy w kodzie. 48% ankietowanych przyznało, że ich organizacje robią to regularnie, a 31% – okazjonalnie. Decyzję tę podejmował najczęściej menedżer zarządzający rozwojem oprogramowania, specjalista ds. bezpieczeństwa albo obaj – w porozumieniu.

Zobacz również:

• Najpopularniejsze stanowiska pracy w chmurze obliczeniowej

Najczęstszym powodem takiego postępowania była konieczność zmieszczenia się w terminie dostarczenia produktu – odpowiedziało tak 54% uczestników badania. 49% wskazało, że dopuszczane podatności nie stanowiły poważnego zagrożenia, a 45% przyznało, że błędy były wykrywane zbyt późno, bo można je było usunąć nie naruszając przy tym harmonogramu.

Co gorsza, 60% uczestników badania przyznało, że aplikacje wdrożone produkcyjnie przez ich organizacje zawierały podatności, które w ciągu ostatniego roku zostały wykorzystane za pośrednictwem exploitów wskazanych na liście OWASP Top 10. Zestawienie to zawiera najpoważniejsze zagrożenia dla aplikacji webowych w tym wstrzykiwanie SQL, naruszenia mechanizmów autoryzacyjnych i błędy w kontroli dostępu.

DevSecOps. Bez kontroli jakości nie ma bezpieczeństwa

Niemal 80% ankietowanych przez Enterprise Strategy Group deklaruje, że w ich organizacjach specjaliści ds. bezpieczeństwa współpracują bezpośrednio z programistami – na przykład w ramach codziennych spotkań developerskich zespołów scrum – w celu testowania poprawności kodu bądź tworzenia schematów zagrożeń. Mimo to programistom brakuje przeszkolenia w kwestii cyberbezpieczeństwa. W efekcie realizacja zadań związanych z oceną stanu zabezpieczeń aplikacji w rzeczywistości nie jest integralnym elementem odpowiedzialności zespołu deweloperskiego, gdyż zajmuje się nią pojedyncza osoba z zespołu, jego szef albo przedstawiciel działu security.

Zaledwie 15% badanych firm wymagało od wszystkich zatrudnionych programistów formalnego szkolenia z zakresu bezpieczeństwa. W mniej niż połowie organizacji deweloperzy musieli przechodzić takie kursy częściej niż raz w roku.

Veracode, dostawca rozwiązań bezpieczeństwa aplikacji, publikuje zresztą własne statystyki dotyczące tego obszaru. Jak wynika z ubiegłorocznego opracowania „State of Software Security Vol. 10”, 83% spośród 85 tys. przeanalizowanych przez firmę aplikacji zawierało przynajmniej jedną podatność, a 20% – co najmniej jedną podatność o statusie krytycznym. Ogółem specjaliści doszukali się w badanej próbce 10 mln luk.

DevSecOps. Kultura DevSecOps

Mimo tych zasadniczo niepokojących statystyk, zdaniem Andrzeja Dyjaka, konsultanta ds. bezpieczeństwa i autora kursu Akademia Bezpiecznego Kodu i tak kraje zachodnie wyprzedzają nas o dekadę pod względem podejścia do bezpieczeństwa aplikacji.

Dyjak, w trakcie swojego wystąpienia na konferencji SEMAFOR 2020 podkreślał, że tworzenie oprogramowania w podejściu DevSecOps musi opierać się na dwóch filarach. Pierwszym z nich jest odpowiednia kultura wytworzona i pielęgnowana w organizacji, a jej elementy to odpowiedzialność za bezpieczeństwo produktu oraz świadomość ryzyk. Drugi filar stanowią narzędzia i procesy testowania bezpieczeństwa w ramach analizy statycznej i dynamicznej.

Pierwsza grupa narzędzi, określana też akronimem SAST, jest mocno związana ze stosem technologicznym, czyli zestawem narzędzi, bibliotek i środowisk programistycznych niezbędnych w pracy dewelopera oprogramowania. To nic innego jak szukanie wzorców podatności w kodzie aplikacji bez jej uruchamiania; sprawdzanie, czy programista nie popełnił oczywistych błędów. SAST bazuje na technologiach zaprojektowanych do analizy kodu źródłowego aplikacji i plików binarnych pod kątem kodowania i warunków projektowania, które wskazują na luki w zabezpieczeniach. Analiza dynamiczna (DAST) to z kolei testowanie aplikacji w stanie pracy, w oderwaniu od stosu technologicznego. W dużym uproszczeniu narzędzia DAST można nazwać skanerami podatności.

„Narzędzia nie zastąpią testów penetracyjnych i pracy człowieka-pentestera – maszyna się nie myli, ale nie jest twórcza”

– mówił Dariusz Czerniawski, członek zarządu w ISACA Warsaw Chapter, inny z prelegentów konferencji SEMAFOR. Jednak dla zapewnienia sprawnego przepływu pracy przy częstych aktualizacjach aplikacji procesy analizy bezpieczeństwa muszą być przynajmniej częściowo zautomatyzowane.

DevSecOps. Programisto, do dzieła

Podejście DevSecOps z częstym, systematycznym skanowaniem aplikacji w poszukiwaniu podatności znacząco poprawia odsetek oprogramowania z usuniętymi lukami i skraca czas niezbędny do wydania poprawek, co jest szczególnie istotne w kontekście błędów krytycznych. Według „Veracode State of Software Security Vol. 10” w porównaniu do 2018 r. odsetek naprawionych aplikacji zwiększył się w 2019 r. z 52 do 56%. Z kolei w wypadku aplikacji skanowanych raz w miesiącu lub rzadziej średni czas aktualizacji wynosił 68 dni, podczas gdy aplikacje skanowane minimum raz dziennie na aktualizację czekały przeciętnie 19 dni.

Wyniki te, jak i wnioski z badania Enterprise Strategy Group potwierdzają, jak istotne jest dziś konsekwentne, tak wcześnie jak to tylko możliwe, rozszerzanie procesu rozwoju aplikacji o etap testowania zabezpieczeń. W przeszłości zadanie to leżało po stronie działu bezpieczeństwa i realizowane było po zakończeniu prac programistycznych. Dziś odpowiednimi kompetencjami powinni wykazać się również sami deweloperzy.

Nowe modele i sposoby dostarczania oprogramowania – chmura publiczna, kontenery i mikrousługi – przyniosły kres dużych wydań aplikacji i rzadkich update’ów. W ich miejsce mamy błyskawiczne cykle wydawnicze, a aplikacje są dzielone na mniejsze, działające niezależnie moduły. W efekcie oprogramowanie wytwarzane jest po prostu za szybko, a nowe wersje aplikacji, tzw. release’y, mogą trafiać „na produkcję” w hurtowych ilościach nawet jednego dnia, by testowanie bezpieczeństwa metodą waterfall było skuteczne. Sytuację dodatkowo komplikuje fakt, że produkt końcowy, czyli aplikacja o określonej funkcjonalności, zawiera zarówno kod wytworzony wewnętrznie, jak i elementy zaciągnięte z otwartych, bezpłatnych repozytoriów bądź za pośrednictwem menedżerów pakietów).

Dlatego funkcjonowanie developmentu, operacji i bezpieczeństwa jako odrębnych silosów organizacyjnych nie ma i nie może mieć racji bytu. Warto, by deweloperzy zdali sobie sprawę, że utrzymanie i zabezpieczanie oprogramowania zależy również od nich.