Co to znaczy być Agile?
Zadając powyższe pytanie można spodziewać się różnych odpowiedzi. Podobnie jest z terminem DevOps lub DevSecOps — kultura współpracy deweloperów z zespołami operacyjnymi przez niektórych sprowadzana jest do ścisłych ram rozwiązań technicznych, takich jak narzędzia CI/CD. Nie dziwi więc fakt, że zwinne zarządzanie nie skończyło się na manifeście Agile, tylko ewoluowało w kierunku metodyk takich jak SCRUM, wraz z narzędziami, rolami projektowymi i procesami.
Gdy bezpiecznik zostaje zaangażowany do oceny oprogramowania wytworzonego w projekcie Agile, niekoniecznie poczuje się zobowiązany do wzięcia pod uwagę kultury zespołu. Efekty pracy nagle zostają poddane ciężkiej krytyce. Zaczyna się przerzucanie odpowiedzialności i zbywanie problemów, które nasila się jeszcze bardziej, jeśli wybrana metodyka nie została prawidłowo wdrożona.
Choć relatywny koszt usunięcia błędu programistów już w działającym i dostarczonym klientowi oprogramowaniu może być nawet 30 razy wyższy niż wykrycie i obsługa tego problemu na wczesnych etapach SDLC, bezpieczeństwo często nie umie komunikować swojej wartości.
Bycie zwinnym to gotowość na dostarczanie tego, czego chce klient dokładnie wtedy, kiedy tego potrzebuje. Jeśli odpowiednio wcześnie nie zakomunikujemy klientowi zagrożeń i potencjalnych konsekwencji zaniedbań, nie liczmy na późniejsze wsparcie. Tylko na poziomie ryzyka możemy przedstawić korzyści z inwestycji w bezpieczeństwo.
Jakie problemy Agile przekładają się na cyberbezpieczeństwo?
Według raportu State of Agile 2023 do najczęstszych problemów zwinności należą: opór przed zmianą, brak zaangażowania managementu, brak zrozumienia docelowego sposobu pracy oraz niewystarczające środki na transformację. Tam, gdzie Agile już działa, często wdrożenie nie jest możliwe w każdym projekcie, a zespoły nie współpracują ze sobą wystarczająco ściśle.
Na dodatek kultura organizacji może nie współgrać z nowym podejściem. Wracając jednak na moment do manifestu Agile – zakłada on między innymi, że działające oprogramowanie jest ważniejsze od szczegółowej dokumentacji.
Niestety manifest bywa wykorzystywany jako pretekst, by pominąć niepriorytetowe elementy w całości. Najczęstsze problemy Agile z bezpośrednim przełożeniem na cyberbezpieczeństwo to:
Brak zasobów (czas oraz budżet).
Brak dokumentacji pozwalającej szybko wdrożyć się w projekt.
Brak priorytetu na security wśród interesariuszy.
Brak interakcji między zespołami, źle zaprojektowana komunikacja.
Wybiórcze adresowanie zagrożeń.
Brak transparentności w temacie security.
Brak świadomości cyberbezpieczeństwa.
Punkty 1 i 2 to problemy, o których najczęściej zespoły wiedzą i w miarę możliwości starają się przeciwdziałać. Pozycje od 3 do 5 dość łatwo zauważyć, jednak ciężko naprawić. A punkty 6 i 7 — stanowią prawdziwą, zagnieżdżoną przyczynę pozostałych problemów z listy.
Komunikacja cyberbezpieczeństwa w projektach IT i jej wpływ na kulturę organizacji
“Choć nie każdy bug to podatność, to każda podatność jest bugiem.” Deweloperzy przyzwyczajeni są do tego, że ich pracę wspierają inżynierzy QA (Quality Assurance). Wiedzą, że bugi są częścią ich codzienności, że do ich obowiązków należy poprawianie kodu. Mimo to, gdy chodzi o łatanie podatności, znacznie trudniej jest przekonać ich do współpracy.
Ta różnica w podejściu bierze się z błędów w komunikacji i raportowaniu. Blame culture jest wciąż powszechnym problemem. Często dochodzi do sytuacji, w których zespoły bezpieczeństwa postrzegane są jako krytycy, a nie partnerzy. Zamiast konstruktywnego dialogu, pojawia się opór. Tymczasem prawdziwy postęp wymaga zmiany perspektywy — przejścia od obwiniania do wspólnego uczenia się.
Dobrą praktyką jest wdrażanie osób odpowiedzialnych za QA w testowanie cyberbezpieczeństwa, tak by stało się ono częścią codziennej pracy nad jakością. Wiele osób może być zainteresowanych taką szansą nowej ścieżki rozwoju. Idealnie, gdy tester lub deweloper zostaje nominowany na Security Championa — Point of Contact wewnątrz zespołu w zakresie security. Zachęcam do sprawdzenia projektu OWASP Security Champions Guide, który zawiera konkretne wskazówki jak efektywnie wdrożyć inicjatywę Security Championa do organizacji.
Niestety, sam Security Champion nie wystarczy, jeśli praca deweloperów nie zostanie doceniona. Priorytetami w liście zadań na dany sprint zwykle są nowe funkcjonalności, dlatego bardzo istotne jest, by bezpieczeństwo było szczegółowo opisywane jako jedno z kryteriów akceptacji ukończenia konkretnych zadań.
Należy zastanowić się, jakie wymagania pod kątem bezpieczeństwa musi spełnić dana funkcjonalność, a następnie uwzględnić w planowaniu sprintu czas na spełnienie tych wymagań.
Warto również tworzyć user stories dedykowane cyberbezpieczeństwu, wykorzystując przyjazne i wrogie persony (na przykład haker i inżynier devsecops). Takie podejście daje szerokie pole do zaangażowania zespołu w dyskusję o bezpieczeństwie już na etapie projektowania i stanowi świetny punkt wyjścia do modelowania zagrożeń.
Rolą wspierającą w projektach zwinnych jest często Scrum Master. Warto pamiętać, że początkowo rola ta nie była zawodem entry-level, a raczej funkcją, którą przypisywano osobie już pracującej jako deweloper czy inżynier QA nad danym projektem. Jest to istotne, gdyż dziś wielu Scrum Masterów bez wcześniejszego doświadczenia w IT nie rozumie cyklu wytwarzania oprogramowania.
Choć ta pozycja nie wymaga technicznej wiedzy, dobry scrum master celuje poza wymagane minimum, rozwijając się na przykład w stronę Agile Coach’a. Angażujmy Scrum Masterów we wsparcie komunikacji na styku biznesu, deweloperów i security. Często mogą mieć oni świetne pomysły oraz czas i chęci, by zająć się wdrożeniem ich w życie. Wymagajmy również zrozumienia procesów SDLC oraz technologii w której działa zespół deweloperski.
Bez tego, Scrum Master nie będzie w stanie prawidłowo identyfikować problemów które napotyka jego team.
Security, które wspiera, czyli jakie?
Jeśli deweloperzy zaczynają rozmawiać o security podczas codziennej pracy nad produktem, to kolejnym punktem na liście zmian jest to, by bezpieczne rozwiązanie było również najprostszym i najszybszym do wykorzystania. Warto zadać sobie kilka pytań:
Czy dział security jest łatwo dostępny, gdy szukamy pomocy?
Czy mamy zdefiniowane ogólne wymagania security pod daną technologię i etapy SDLC, i czy nasze zespoły produktowe są o nich informowane?
Czy istnieje security toolkit, czyli narzędzia, których projekt może używać proaktywnie, by samodzielnie testować swoje rozwiązania?
Czy mamy zebrane dobre praktyki, standardy i materiały szkoleniowe pod kątem bezpieczeństwa?
Czy deweloperzy znają personalnie choć jedną osobę z działu security?
Mikrozmiany, takie jak stworzenie listy najczęstszych zagrożeń i podatności dla naszych produktów, kanał na Slacku dedykowany problemom z bezpieczeństwem czy sesje wymiany wiedzy po testach penetracyjnych mogą pozytywnie wpłynąć na postrzeganie zespołu security w firmie.
Wszelkie wspólne inicjatywy, takie jak hackathony i spotkania z IT podsumowujące wyniki audytów (jako dodatkowy element raportowania) będą budować transparentność, pozwalając nieco “odczarować” ponure skojarzenia z tematem. Ciekawym pomysłem jest również opisywanie w szczegółach poważnych podatności i błędów popełnionych w firmie, a następnie zapisywaniu takiego materiału jako “lessons learned”.
Taki materiał stanowi nie tylko doskonałe źródło wiedzy na przyszłość, ale podkreśla również otwartość organizacji na popełnianie tych błędów. Choć poprzednie zdanie brzmi dość kontrproduktywnie, najgorszy błąd to taki, którego nikt nie zgłosił, bo bał się to zrobić.
Trendy w bezpiecznym Agile
Choć spada zadowolenie z wdrażania zwinnych metodyk, szczególnie w średnich i dużych firmach, organizacje nadal szukają efektywnych sposobów na usprawnianie swojej pracy, kierując się najczęściej w stronę SCRUM i SAFe. Ponad 20% firm wdraża swoje własne zwinne modele — to zarówno szansa jak i zagrożenie dla działów bezpieczeństwa, które powinny szczególną uwagę zwracać na otrzymanie wsparcia wyższego kierownictwa.
Rośnie znaczenie DevSecOps, czyli podejścia opartego o kulturę bezpieczeństwa i automatyzację testów. W praktyce bywa, że DevSecOps jest rozumiane jako rola inżyniera DevOps z doświadczeniem we wdrażaniu narzędzi security.
Pojawiają się również pierwsze opracowania, jak wdrażać AI w Agile. W przyszłości możemy spodziewać się nowych narzędzi i zmian w procesach. Omówione zagadnienia dobrze podsumowuje jedno zdanie. Pamiętajmy, że tak jak w Agile powinniśmy uwzględniać ważnego interesariusza jakim jest security, tak bezpieczeństwo powinno brać pod uwagę kulturę Agile i dostosowywać się do sposobu prowadzenia projektów.
