What the H@ck is DevSecOps, czyli o pewnej konferencji i o bezpiecznym kodowaniu.
Za nami wizyta na What The H@ck czołowym, polskim evencie z zakresu bezpieczeństwa IT. Zdecydowanie wpisujemy to wydarzenie na listę wyjątkowo udanych, tegorocznych konferencji branżowych. Lokalizacja (PGE Narodowy), dobra organizacja ) i strefa networking’owa, w ramach której można było porozmawiać m.in. z prelegentami – robiły robotę. Bardzo dobrze zorganizowane były również targi pracy i strefa wystawiennicza. Zdecydowanie największe wrażenie robiły jednak same prelekcje – od tych wysoko specjalistycznych, po te zdecydowanie bardziej miękkie, prowadzone przez prelegentów, którzy, co ważne, potrafili przekazać swoją wiedzę w przystępny sposób.
Na konferencji można było wybrać jedną z wielu ścieżek tematycznych, ale mnie najbardziej zainteresował panel „Jak z podejścia DevOps zrobić DevSecOps” Macieja Nogasa. Podczas wystąpień prelegenci pokazywali m.in. korzyści z łączenia procesów developerskich z operacyjnymi, a także wynikające z tego znaczne oszczędności finansowe oraz czasowe. W trakcie prelekcji można było dowiedzieć się również, w jakich okolicznościach powstała zyskująca na popularności metodyka DevSecOps, która polega na dodaniu do procesów wytwarzania oprogramowania (Dev) i utrzymania (Ops), wątków związanych z bezpieczeństwem (Sec). W jakim celu? Po to, żeby myśleć o bezpieczeństwie nie na końcu procesu wytwórczego, podczas audytu oprogramowania, ale na każdym jego etapie.
Nasz najważniejszy wniosek po konferencji? Musimy zmienić nasze podejście do usług automatyzujących proces wytwórczy. Uczestnictwo w What the H@ck przekonało nas do tego, żeby odejść od tradycyjnego wykonywania audytu bezpieczeństwa w momencie, gdy produkt jest całkowicie gotowy. Postanowiliśmy włączyć do naszych procesów zagubione „Sec” i wprowadzić zagadnienia związane z bezpieczeństwem do cyklu DevOps, wymuszając tym samym wykonywanie testów bezpieczeństwa na każdym etapie projektu. Dzięki takiemu podejściu obniżymy koszt projektów i zminimalizujemy opóźnienia wynikające z naprawiania błędów bezpieczeństwa, które zazwyczaj wychodziły podczas końcowego audytu. Wyeliminujemy tym samym również często pojawiający się problem programistów związany z koniecznością podejmowania decyzji dotyczących bezpieczeństwa.
Michał Wiśniewski, IT Operations & DevOps Leader