Aktualności Biznes

Duch walki w branży IT, czyli 5 najważniejszych różnic między DevSecOps a sportem

Pewnego dnia zacząłem się zastanawiać nad podobieństwami między sportem a światem
oprogramowania, a w szczególności tymi pojawiającymi się w użytecznym i dość
popularnym procesie DevOps. Olśniło mnie! Jeżeli na świecie istnieje jedna rzecz, która
ze sportem nie ma nic wspólnego, to na pewno jest to metodyka DevSecOps.
Dlaczego? Już spieszę z przykładami i wyjaśnieniem.
1. Nie da się zwalić winy na bramkarza
Wybaczcie, że zacznę od przykładu tak konkretnego, jednak jest on mi bardzo bliski –
głównie dlatego, że w latach szkolnych kończyłem zwykle jako bramkarz, a tej funkcji nikt
przecież nie lubił. Gdy piłka przelatywała czy wręcz przetaczała się obok mnie –
i w konsekwencji lądowała w siatce – za sytuację taką zawsze obwiniano mnie. Nie tylko jest
to sytuacja o beznadziejnym wpływie na zespołowe morale, nie powinna być ona bowiem
również postrzegana jako odzwierciedlenie funkcjonowania zespołu.
Co mam na myśli? Zawsze jestem ostrożny, kiedy spotykam się ze stwierdzeniem, że
„w DevSecOps za bezpieczeństwo odpowiadają wszyscy”. Nie każdy jest ekspertem od
bezpieczeństwa, jednak każdy powinien brać choć trochę odpowiedzialności za zrozumienie
prawidłowości procesów i za postępowanie zgodnie z jej założeniami. W momencie, gdy coś
pójdzie nie po naszej myśli, winy nie należy nigdy zrzucać na ramiona jednej osoby. I nie
zapominajmy jeszcze o jednej kwestii: DevSecOps każdorazowo daje szansę na naprawę
tego, co poszło nie tak, naprawa ta jest szybka, a następnie ma miejsce wdrożenie testów,
które pozwolą na upewnienie się, że ta wrażliwość systemu nie będzie nigdy więcej
narażona na atak.
2. Nie wiadomo, kim jest przeciwnik
W sporcie zwykle jasna jest tożsamość adwersarza, jego położenie oraz to, co dany
zawodnik w danym momencie robi. Może nie będziecie w stanie zawsze go zatrzymać, ale
przynajmniej wiadomo, kim on jest i jaki jest jego cel, czyli co próbuje osiągnąć.
W przypadku DevSecOps powyższe nie ma miejsca, sytuacja taka występuje jeszcze
rzadziej niż w świecie normalnych projektów programistycznych. Dzieje się tak, ponieważ
jako zespół zajmujecie się opracowywaniem, testowaniem i wykorzystaniem warstw
systemu, natomiast Wasi oponenci mogą reprezentować różny poziom umiejętności, mogą
też korzystać z różnych zasobów.

Kluczowe jest tu „zespołowe” podejście do sprawy. Jeżeli wdrażacie prawdziwą pracę
zespołową, połączona wiedza ekspercka może być używana w wielu warstwach abstrakcji,
na sposoby zwykle trudno osiągalne w standardowym modelu programistycznym: „design,
develop, test, deploy”. To z kolei daje Wam szerszy i głębszy wgląd w sposoby zwiększenia
bezpieczeństwa projektu.
3. Nie gracie na zasadach takich samych jak Wasz przeciwnik
To dość trudna kwestia. W sporcie istnieją zasady, zgodnie z którymi postępować muszą
obie strony. W przeciwnym razie strona, która je złamie, musi liczyć się z konsekwencjami
nakładanymi przez sędziego, arbitra bądź innego oficjela.
Oczywiście miło byłoby żyć w świecie, gdzie strona atakująca zawsze będzie schwytana
i karana (w momencie, gdy podejmie ona kroki zmierzające do ataku infrastruktur lub
aplikacji), jednak póki co nic nie wskazuje na to, że taka bajkowa rzeczywistość wkrótce
nastąpi. Biorąc pod uwagę mało prawdopodobny scenariusz, w którym adwersarza
będziemy „gonić” w czasie rzeczywistym w ramach aktywnego kontrataku, rozważyć trzeba
to, jakie możemy wdrożyć środki łagodzące, jak je stosować, i jak szybko można je
wprowadzić do działania.
Co istotne, nie może być to obszar pozostawiony do dyspozycji wyłącznie ekspertom
zespołu bezpieczeństwa. Mimo iż są oni w stanie przewidzieć prawdopodobne ataki, to
kluczowy personel inżynieryjny i operacyjny najlepiej nadaje się do przewidywania
potencjalnego wpływu ataku na działanie systemu. To te zespoły powinny projektować
odpowiednie środki łagodzące, do przeciwdziałania problemom.
4. W grę zaangażowany jest cały zespół – za każdym razem przez cały czas
W większości gier zespołowych drużyna nigdy nie znajduje się w całości na boisku, korcie
czy lodowisku. Jedną z zalet działań DevSecOps jest możliwość zaangażowania wszystkich
członków zespołu w cały proces. Trener nie musi przebywać poza boiskiem. W działania
można zaangażować psychologa, eksperta od wyników czy specjalistów od techniki, gdy
tylko zaistnieje taka potrzeba.
Każdy z członków zespołu wnosi swój wkład w rozwój oprogramowania, w miarę pojawiania
się zmian w aplikacji, środowisku wdrożenia czy w krajobrazie bezpieczeństwa. Zespoły
DevSecOps nie powinny być izolowane od innych działów firmy: jeżeli trzeba je przez jeden
lub dwa dni zaangażować, nie wahajmy się tego zrobić. Nie bójmy się wykonywania
szybkich ruchów i przyznawania się do tego, że potrzebujemy pomocy.
5. Porażki są OK – i to w dużych ilościach
Gdy myślimy o zmaganiach sportowych, bardzo wiele emocji poświęcamy zwycięstwu
naszych zespołów w każdym spotkaniu. W zasadzie jednak najlepsi sportowcy i najlepsze
sportowe drużyny wiedzą również jak przegrywać, a przede wszystkim jak przekuć porażkę
na późniejsze sukcesy.
W DevSecOps powinniśmy kibicować naszym zespołom, jednak z intencją odniesienia przez

nie porażek – częstych i szybkich. Nasze aplikacje i projekty można usprawnić tylko poprzez
doświadczenie i obserwowanie błędów. Nikt nie wierzy w nieśmiertelność systemów lub
aplikacji: nie należy zadawać pytania, czy będziemy obiektem ataku lub włamań, tylko kiedy
do tego dojdzie. Wasze procesy projektujcie w taki sposób, aby można było szukać
zachowań odbiegających od normy. Bądźcie gotowi na łagodzenie ich skutków. Należy
także upewnić się, że istnieją procesy, które pozwolą ocenić, co poszło nie tak, a co za tym
idzie zbudować nową wersję projektu – lepszego, solidniejszego i odporniejszego.
Kilka słów podsumowania
No dobrze, nie będę udawać, że między DevSecOps i sportem nie ma żadnych
podobieństw. Naturalnie istnieje wiele wspólnych cech między nimi. Niektóre z bardziej
oczywistych przykładów: jak znaczące zmiany wymagają odgórnego zobowiązania, jak
i oddolnego zaangażowania; istota budowania zespołu, którego członkowie będą w stanie
się między sobą sprawnie komunikować; zdolność do reakcji na zagrożenia w czasie
rzeczywistym.
Skąd zatem pomysł na niniejszy artykuł? Celem ostatecznie nie było ograniczenie się do
podania różnic. Czasami dogłębne zrozumienie istoty danego zjawiska czy problemu jest
możliwe dzięki porównaniu czegoś do rzeczy, która pozostaje odwrotnością, a nie jest jego
odpowiednikiem. Mam nadzieję, że ten artykuł choć w pewnym stopniu pozwolił zrozumieć
metodykę DevSecOps.

Autor: Mike Bursell, Chief Security Architect, Red Hat

Komentarze