Metodologia Agile stała się dominującym podejściem w komercyjnym tworzeniu oprogramowania z uzasadnionych powodów: zmniejsza ryzyko dostawy poprzez częstą integrację, ujawnia niezrozumienia na wczesnym etapie poprzez demonstracje działającego oprogramowania i pozwala na dostosowanie zakresu w miarę ewolucji rozumienia wymagań. Wyzwanie polega na tym, że programy obronne wprowadzają ograniczenia, dla których standardowe praktyki Agile nie są zaprojektowane — a ignorowanie tych ograniczeń nie sprawia, że znikają.
Niniejszy artykuł omawia, gdzie Agile w powszechnie stosowanej formie koliduje z wymaganiami obrony, jakie adaptacje okazały się skuteczne oraz gdzie tradycyjne poglądy na temat Agile w obronie wymagają aktualizacji na podstawie tego, co rzeczywiście działa w praktyce.
Gdzie Agile koliduje z wymaganiami obronnymi
Klasyfikacja bezpieczeństwa i kontrola dostępu. Standardowy Agile zakłada, że wszyscy członkowie zespołu mogą pracować nad wszystkimi częściami bazy kodu i uczestniczyć we wszystkich ceremoniach. Programy obronne z niejawnymi komponentami mogą ograniczać, kto może pracować nad którymi podsystemami, na podstawie poziomu poświadczenia bezpieczeństwa. Tworzy to struktury zespołów, których model zespołu wielofunkcyjnego Agile nie przewiduje.
ITAR i ograniczenia kontroli eksportu. Dla programów obejmujących technologię objętą Międzynarodowymi Przepisami Handlu Uzbrojeniem (ITAR), skład zespołu jest ograniczony wymogami obywatelstwa. Standardowe praktyki rekrutacji Agile mogą kolidować z wymaganiami ITAR ograniczającymi dostęp obcokrajowców do określonych danych technicznych.
Formalna akredytacja i zezwolenie na eksploatację (ATO). Systemy oprogramowania obronnego zwykle wymagają akredytacji bezpieczeństwa przed wdrożeniem w środowiskach operacyjnych. Procesy akredytacji nie są przyjazne dla sprintów: obejmują znaczną dokumentację, gromadzenie dowodów, ocenę przez stronę trzecią i formalne podejmowanie decyzji. Tworzy to strukturalną niezgodność: Agile stale produkuje działające oprogramowanie, ale wdrożenie jest uzależnione od harmonogramów akredytacji mogących opóźniać się w stosunku do rozwoju o miesiące.
Środowiska wytwarzania z izolacją powietrzną. Programy obronne obsługujące niejawne dane często wymagają, aby prace wytwórcze odbywały się w środowiskach izolowanych — systemach fizycznie odłączonych od sieci publicznych. Standardowe potoki CI/CD zależą od dostępnych w Internecie repozytoriów pakietów i infrastruktury budowania w chmurze. Środowisko izolowane wymaga wewnętrznej repliki wszystkich tych elementów.
Adaptacje: przeglądy bezpieczeństwa bramkowane sprintem i CI/CD z uwzględnieniem akredytacji
Przeglądy bezpieczeństwa bramkowane sprintem integrują działania oceny bezpieczeństwa w cykl sprintu zamiast traktować je jako jednorazową bramkę. Każdy sprint obejmuje działania przeglądu bezpieczeństwa proporcjonalne do istotnych dla bezpieczeństwa zmian wprowadzonych w danym sprincie. Rozdziela to obciążenie przeglądem bezpieczeństwa w całym programie i zapobiega gromadzeniu się długu bezpieczeństwa.
CI/CD z uwzględnieniem akredytacji rozwiązuje wyzwania izolacji i harmonogramów akredytacji. Potok jest projektowany z myślą o docelowym środowisku akredytacji: używa tylko komponentów, które mogą być dublowane w środowisku izolowanym; generuje typy artefaktów, których będą wymagać akredytatorzy (SBOM, raporty skanowania podatności, wyniki analizy statycznej).
Zaobserwowany wzorzec: Programy traktujące akredytację jako oddzielny strumień pracy równoległy do rozwoju Agile konsekwentnie osiągają lepsze wyniki niż programy próbujące odroczyć działania akredytacyjne do końca. Narzut utrzymywania świadomości akredytacji przez cały program jest niższy niż narzut próby odtworzenia dowodów i usunięcia ustaleń po nominalnym zakończeniu prac wytwórczych.
Wymagania dokumentacyjne a Manifest Agile
Manifest Agile deklaruje preferencję dla „działającego oprogramowania ponad wyczerpującą dokumentację". W programach obronnych dokumentacja pełni funkcje wykraczające poza opisywanie działania oprogramowania: jest prawnym zapisem tego, co zostało zakontraktowane, co dostarczono i jak to zweryfikowano; jest podstawą dowodową dla zgodności z przepisami; oraz artefaktem umożliwiającym długowiecznym systemom obronnym konserwację i modernizację przez przyszłe zespoły. Praktycznym rozwiązaniem nie jest wybór między działającym oprogramowaniem a dokumentacją, ale jawne zdefiniowanie, które artefakty dokumentacyjne są wymagane, kiedy muszą być wytworzone i jaki poziom szczegółowości jest niezbędny.
Co naprawdę działa w praktyce
Programy obronne skutecznie stosujące zasady Agile bez naruszania zgodności mają kilka wspólnych cech: używają skalowanego frameworku (SAFe lub adaptacji specyficznej dla programu); inwestują w bezpieczną, zgodną infrastrukturę wytwórczą przed rozpoczęciem programu; rozróżniają między działaniami zgodności, które mogą być zwinne, a tymi, które nie mogą; i szkolą cały zespół — nie tylko właścicieli procesów — w zakresie wymagań specyficznych dla obrony wpływających na codzienną pracę. Niepowodzenia zgodności w obronnych programach Agile najczęściej wynikają z tego, że członkowie zespołu stosują komercyjne instynkty Agile w kontekstach, gdzie te instynkty są błędne, a nie z umyślnego nieprzestrzegania zasad.