Co 10 firma nie jest zainteresowana DevSecOps. Jakie są przesłanki do wdrożenia tej koncepcji w organizacji?

Koncepcja DevOps, integrująca zespoły programistyczne (Dev) i operacyjne (Ops), wniosła nową jakość w procesie wytwarzania oprogramowania. Współpraca dwóch działów zwiększyła jakość, niezawodność i szybkość dostarczania projektowanych rozwiązań. Mimo korzyści wynikających z tego podejścia wielu przedstawicieli branży IT zwracało także uwagę na jego ograniczenia. Na fali tych głosów pojawił się pomysł rozszerzenia DevOps o nowy element – bezpieczeństwo (Sec).

Zgodnie z koncepcją DevSecOps nie powinno być ono osobnym procesem, a elementem uwzględnianym na każdym etapie wytwarzania oprogramowania. Jak wskazują eksperci Linux Polska, po kilkunastu latach od początków kształtowania się tego podejścia, kompleksowy program DevSecOps wdrożyła zaledwie co piąta organizacja. Dlaczego?

DevSecOps znany, ale niewdrażany powszechnie

Raport ISC2 z 2024 roku wskazuje, że nie wszystkie organizacje widzą sens we wdrożeniu DevSecOps. Kompleksowy program oparty na tym podejściu posiada zaledwie 21 proc. z nich, a kolejne 36 proc. wskazuje, że działa zgodnie z tą filozofią jedynie w pewnym zakresie. Co piąty badany przyznał, że nie jest zaznajomiony z DevSecOps, a 13 proc. uważa, że to tylko określenie, które nie wnosi niczego nowego do procesu wytwarzania oprogramowania. Zróżnicowanie poglądów na temat tego podejścia podkreśla także fakt, że wdrożenie DevSecOps rozważa 26 proc. organizacji, a wyklucza – 11 proc^[1].

Jak wyjaśnia Dariusz Świąder, CEO Linux Polska, z jednej strony dane wskazują na coraz większe zainteresowanie integracją praktyk dotyczących bezpieczeństwa w całym cyklu życia aplikacji, z drugiej zaś – uwidaczniają opór w wielu organizacjach.

– Coraz więcej firm zauważa korzyści biznesowe wynikające z wdrożenia DevSecOps. Mowa przede wszystkim o wytwarzaniu lepszego, bezpieczniejszego oprogramowania, przyspieszeniu wydawania jego nowych wersji, a także poprawie efektywności pracy wszystkich zespołów. Kwestie te wiążą się oczywiście z mniejszymi kosztami i lepszym odbiorem wśród klientów organizacji. Jak to jednak bywa w świecie IT, również i ten medal ma dwie strony. Tą drugą stanowią wszelkie wyzwania związane z wdrożeniem praktyk DevSecOps. Głównym problemem jest luka kompetencyjna i konieczność poszerzania wiedzy programistów i operatorów o kwestie związane z bezpieczeństwem. Brak doświadczenia może wpłynąć na wybór nieodpowiednich narzędzi, a przez to – spowolnienie rozwoju oprogramowania. Dlatego też do wdrożenia i utrzymania zintegrowanego środowiska narzędziowego DevSecOps zawsze podchodzimy kompleksowo, opierając je na standaryzowanych procesach i narzędziach – dodaje Dariusz Świąder, CEO Linux Polska. 

Narzędzia bezpieczeństwa integrowane na różnych etapach

Badania pokazują, że organizacje nie posiadają jednolitej strategii integracji środków bezpieczeństwa w procesie wytwarzania oprogramowania. Najczęściej działanie to jest podejmowane podczas wstępnej fazy planowania i analizy (24 proc. odpowiedzi) lub fazy projektowania (21 proc.). Nieco rzadziej wskazywane opcje to faza testowania i integracji (9 proc.), rozwoju i kodowania (8 proc.), eksploatacji i utrzymania (5 proc.) oraz wdrożenia i wydania (4 proc.)^[2].

Jak tłumaczy Tomasz Dziedzic, Chief Technology Officer w Linux Polska, właściwe podejście do bezpieczeństwa wymaga jego integracji z całym cyklem życia oprogramowania. W raporcie ISC2 opcję tę wskazało jednak zaledwie 16 proc. osób^[3].

– Badania pokazują, że najczęściej bezpieczeństwo staje się częścią procesu wytwarzania oprogramowania dopiero w pewnej jego fazie. Taki sposób działania stwarza mylne wrażenie, że zagrożenia pojawiają się w jakimś konkretnym momencie. Istotą DecSecOps jest zagwarantowanie elementu „Sec” na każdym etapie tworzenia i wdrażania aplikacji – od projektowania, aż po utrzymanie oprogramowania. Ten cel osiągamy przy pomocy implementacji ciągłego monitoringu i obserwowalności w zautomatyzowanych procesach wytwórczych. Dzięki temu organizacja zyskuje lepszą kontrolę nad jakością kodu, a także może przyspieszyć i zwiększyć niezawodność wdrożeń – mówi Tomasz Dziedzic, Linux Polska.

Ekspert zwraca również uwagę na konieczność współpracy zespołów deweloperskiego, bezpieczeństwa i operacyjnego w celu identyfikacji i naprawy potencjalnych luk i zagrożeń.

– Współdziałanie wszystkich zespołów zaangażowanych w DevSecOps wymaga oczywiście wprowadzenia pewnych zmian w kulturze organizacyjnej firmy, a także poszerzenia wiedzy na temat bezpieczeństwa. Pomagamy organizacjom we wdrażaniu zmian oraz wspieramy je w promowaniu współpracy opartej na przepływie informacji oraz ciągłym uczeniu i doskonaleniu. Realizację projektów DevSecOps traktujemy jako długofalowy proces, w którym oprócz wdrożeń technologicznych konieczne jest także dzielenie się wiedzą oraz zachęcanie do zmiany podejścia do bezpieczeństwa – dodaje Tomasz Dziedzic, Linux Polska.

Współpraca, która przynosi korzyści wszystkim zespołom

Wdrożenie DevSecOps przynosi organizacji wiele korzyści biznesowych, ale na tym zalety rozwiązania się nie kończą. Jak wskazuje Dariusz Świąder, CEO Linux Polska, integracja bezpieczeństwa z całym cyklem życia oprogramowania usprawnia pracę wszystkich zespołów zaangażowanych w ten proces.

– W przypadku zespołu bezpieczeństwa najważniejszą kwestią jest redukcja zagrożenia związanego z tworzeniem i utrzymaniem aplikacji. DevSecOps umożliwia wczesne wykrywanie i eliminację podatności, a także ułatwia zapewnienie zgodności z obowiązującymi regulacjami. Zespoły deweloperskie mogą liczyć na automatyzację testów i bardziej efektywne wykrywanie błędów, co prowadzi do szybszych wdrożeń i poprawy jakości kodu. Z kolei zespoły operacyjne z pewnością docenią większą efektywność działań, możliwość elastycznego skalowania aplikacji, bardziej stabilne systemy oraz mniejsze ryzyko przestojów. Na podejściu DevSecOps korzysta każdy, dlatego warto rozważyć jego wdrożenie w organizacji – podsumowuje Dariusz Świąder, CEO Linux Polska.

 

^[1] ISC2, Cloud Security Report 2024,

^[2] Jak wyżej.

^[3] Jak wyżej.