Compliance by design w R&D dla sektora defence – od kontraktu po pipeline CI/CD

Materiał sponsorowany

Organizacje muszą dziś wykazać zarówno to, że system spełnia wymagania bezpieczeństwa, jak i to, w jaki sposób osiągnięto ten stan – jakie decyzje projektowe do tego doprowadziły, czy cały proces rozwoju systemu pozostaje pod kontrolą i czy można go zweryfikować w ramach audytu, oceny klienta lub działań Government Quality Assurance.

Właśnie na takich założeniach opiera się podejście compliance by design. Oznacza ono, że wymagania bezpieczeństwa, jakości i zgodności są uwzględniane od początku projektu: od analizy kontraktu, klasyfikacji systemu i architektury, przez rozwój oprogramowania, zarządzanie zmianami i pipeline CI/CD, czyli continuous integration/continuous delivery lub continuous deployment, aż po utrzymanie rozwiązania.

Dlaczego compliance by design ma znaczenie w projektach defence

Liczba wymagań regulacyjnych dotyczących cyberbezpieczeństwa i odporności organizacji stale rośnie. Obejmują one zarówno krajowe wymagania związane z Krajowym Systemem Cyberbezpieczeństwa (KSC), jak i przepisy europejskie, takie jak NIS2 czy CER. Jeśli zastanawiasz się, które z nich dotyczą Twojej organizacji, więcej informacji z perspektywy różnych sektorów znajdziesz w praktycznym przewodniku „Cyberbezpieczeństwo w małych, średnich i dużych przedsiębiorstwach”.

W projektach defence wymagania związane ze zgodnością mogą jednak wykraczać poza samo cyberbezpieczeństwo. W zależności od charakteru kontraktu, rodzaju dostarczanego rozwiązania oraz zakresu działalności organizacje mogą podlegać jednocześnie różnym wymaganiom jakościowym, regulacyjnym i dotyczącym bezpieczeństwa – takim jak AQAP, AS/EN 9100, AS/EN 9115, Wewnętrzny System Kontroli (WSK), koncesje, przepisy dotyczące informacji niejawnych, kontroli eksportu lub transferu technologii.

Wymagania bezpieczeństwa i jakości coraz częściej wpływają bezpośrednio na architekturę systemu, sposób organizacji środowiska wytwórczego, zarządzanie zależnościami, proces rozwoju oprogramowania oraz kontrolę zmian i testów. W projektach w sektorze defence staje się to szczególnie ważne, ponieważ problemy ze zgodnością mogą prowadzić nie tylko do ryzyka technicznego, ale także do opóźnień odbiorowych, trudności podczas audytu lub certyfikacji albo większego ryzyka w łańcuchu dostaw.

Punkt wyjścia: kontrakt, klasyfikacja systemu i wymagania zgodności

W projektach defence zgodność trzeba uwzględnić znacznie wcześniej niż na etapie implementacji oprogramowania. Punktem startowym są wymagania kontraktowe, regulacje, kontekst operacyjny systemu oraz charakter działalności organizacji.

Już na początku projektu należy ustalić, które z potencjalnych wymagań rzeczywiście dotyczą danego rozwiązania. Obejmuje to między innymi określenie:

• jakie dane będzie przetwarzał system,
• czy pojawią się informacje niejawne,
• jakie regulacje mają zastosowanie,
• jakie wymagania jakościowe wynikają z kontraktu, w tym:

o   czy zastosowanie mają AQAP 2110, AQAP 2310 lub AQAP 2210, o   czy projekt wymaga zgodności z AS/EN 9100 lub AS/EN 9115, o   czy działalność może wymagać WSK lub koncesji,

• gdzie mogą być przechowywane dane,
• kto może uczestniczyć w pracach nad projektem,
• czy występuje transfer technologii, kontrola eksportu lub współpraca z podmiotami zagranicznymi.

Wymagania compliance obejmują często również poświadczenia bezpieczeństwa, zasady dostępu do środowisk projektowych, ograniczenia dotyczące infrastruktury oraz sposób zarządzania dostępem do kodu, dokumentacji i artefaktów projektowych.

Na tym etapie ważna jest także analiza krytyczności systemu. Pozwala ona określić konsekwencje niepoprawnego działania konkretnych funkcji, a w dalszej perspektywie wpływa na poziom rygoru projektowego, zakres wymaganych testów, sposób dokumentowania zmian oraz poziom kontroli nad komponentami systemu.

Architektura i środowisko wytwórcze jako element compliance

Od decyzji dotyczących architektury systemu zależą bezpieczeństwo, możliwość wykazania zgodności oraz kontrola nad systemem w całym jego cyklu życia. Z tego powodu architektura powinna uwzględniać nie tylko wymagania funkcjonalne, ale również normy, standardy i wymagania kontraktowe właściwe dla danego projektu. Mogą one obejmować wspomniane wymagania AQAP, AS/EN 9100, AS/EN 9115, Normy Obronne, NATO STANAG lub specyficzne wymagania klienta, a w praktyce wpływać między innymi na przepływy danych, separację środowisk, mechanizmy kontroli dostępu, integrację komponentów, sposób dokumentowania decyzji projektowych oraz możliwość odtworzenia pełnego łańcucha dowodowego.

Coraz większe znaczenie ma również samo środowisko wytwórcze. W projektach związanych z bezpieczeństwem państwa częścią powierzchni ataku mogą być repozytoria kodu, pipeline’y CI/CD czy narzędzia programistyczne. Z tego powodu organizacje coraz częściej oczekują możliwości pełnego prześledzenia pochodzenia komponentów, historii zmian, wykorzystanych narzędzi oraz działań dostawców i podwykonawców.

Dotyczy to także komponentów open source oraz usług zewnętrznych wykorzystywanych podczas rozwoju systemu. Zagadnienia compliance obejmują więc również:

• bezpieczeństwo łańcucha dostaw,
• zarządzanie komponentami zewnętrznymi,
• nadzór nad komponentami off-the-shelf,
• procedury reagowania na incydenty,
• możliwość audytu dostawców i usług wykorzystywanych w projekcie,
• kontrolę dostępu do kodu, dokumentacji i artefaktów,
• zasady dokumentowania decyzji technicznych i jakościowych.

Implementacja, SBOM i kontrola zmian

Na etapie rozwoju i integracji oprogramowania wymagania compliance zaczynają bezpośrednio wpływać na codzienną pracę zespołów inżynieryjnych. Elementem wymagań projektowych staje się secure coding, czyli bezpieczne programowanie. Obejmuje ono między innymi kontrolę jakości kodu, analizę podatności, bezpieczne zarządzanie komunikacją i pamięcią oraz kontrolę zależności i bibliotek.

Ważna jest również możliwość identyfikacji komponentów wykorzystywanych w systemie. Dlatego coraz częściej standardowym elementem procesu rozwoju staje się SBOM (Software Bill of Materials), czyli uporządkowany wykaz komponentów oprogramowania, bibliotek, frameworków, wersji i zależności użytych podczas budowy rozwiązania.

W projektach z obszaru obronności kluczowa jest ponadto możliwość odtworzenia całego procesu rozwoju systemu: od wymagania, przez decyzję projektową, implementację i test, aż po zatwierdzenie zmiany i release. To właśnie ten spójny łańcuch dowodowy staje się jednym z najważniejszych elementów nowoczesnego compliance.

Jeżeli projekt obejmuje oprogramowanie, zastosowanie mogą mieć również wymagania AQAP 2210 lub AS/EN 9115. AQAP 2210 nie powinien być traktowany jako samodzielny system zarządzania jakością, ale jako nakładka na AQAP 2110 albo AQAP 2310 stosowana wtedy, gdy oprogramowanie jest istotnym elementem dostawy. AS/EN 9115 pełni natomiast rolę uzupełnienia AS/EN 9100 dla organizacji projektujących, rozwijających lub dostarczających oprogramowanie w sektorze aviation, space and defence.

Pipeline CI/CD jako mechanizm egzekwowania zgodności

W podejściu compliance by design pipeline CI/CD nie służy już wyłącznie automatyzacji budowania systemu i wdrożeń, lecz staje się mechanizmem egzekwowania zgodności. Pipeline może automatycznie:

• skanować podatności,
• weryfikować zależności,
• kontrolować jakość i bezpieczeństwo kodu,
• sprawdzać konfigurację środowisk,
• wymuszać wykonanie określonych testów i zatwierdzeń,
• generować artefakty dowodowe,
• kontrolować kompletność dokumentacji technicznej,
• wspierać identyfikowalność między wymaganiami, kodem, testami i releasem.

W części projektów znaczenie mają również: podpisywanie artefaktów, kontrola ich integralności (w tym plików wykonywalnych), a także wymagania dotyczące mechanizmów kryptograficznych. Dzięki takiemu podejściu kontrola zgodności zostaje osadzona bezpośrednio w zautomatyzowanych procesach. Weryfikacja zgodności staje się częścią codziennej pracy, a nie dopiero elementem audytu.

##Compliance jako proces ciągły i co to oznacza dla zespołów R&D

Ta zmiana jest bardzo ważna, ponieważ jednym z najczęstszych błędów w projektach regulowanych jest traktowanie compliance jako jednorazowego etapu realizowanego przed odbiorem systemu. W rzeczywistości zgodność należy traktować jako proces ciągły, obejmujący cały cykl życia rozwiązania. Dotyczy to między innymi oceny ryzyka, zarządzania podatnościami, kontroli zmian, utrzymania dokumentacji oraz ponownej walidacji komponentów po modyfikacjach systemu.

W środowiskach defence nawet niewielka zmiana może wpływać na poziom ryzyka, zakres wymaganych testów, konieczność ponownej walidacji lub formalnej akceptacji wybranych elementów. Dlatego coraz większe znaczenie ma zachowanie ciągłej identyfikowalności i kontroli nad całym procesem rozwoju systemu.

Podejście compliance by design zmienia także codzienną pracę zespołów inżynieryjnych. Wymagania compliance stają się równie istotnym elementem pracy projektowej jak wymagania funkcjonalne, jakościowe czy wydajnościowe – trafiają bezpośrednio do backlogu projektu, kryteriów akceptacji oraz pipeline’ów testowych.

Zmienia się ponadto Definition of Done, czyli kryteria ukończenia zadania. Coraz częściej ukończenie zadania obejmuje:

• wykonanie testów bezpieczeństwa,
• przygotowanie artefaktów dowodowych,
• aktualizację dokumentacji,
• zachowanie pełnej identyfikowalności zmian,
• weryfikację wpływu zmiany na ryzyko,
• potwierdzenie zgodności z wymaganiami kontraktowymi.

Oznacza to, że compliance wpływa bezpośrednio na możliwość zamknięcia zadania, integracji zmian, wydania nowej wersji systemu oraz zatwierdzenia release’u.

Compliance by design to zmiana myślenia o rozwoju systemów

W sektorze defence rośnie świadomość, że compliance w projektach nie oznacza wyłącznie przygotowania dokumentacji na potrzeby audytu. Coraz częściej zapewnianie zgodności staje się sposobem prowadzenia całego procesu rozwoju systemu – od analizy kontraktu po utrzymanie środowiska produkcyjnego.

Compliance by design osadza wymagania bezpieczeństwa, jakości, zgodności i audytowalności w architekturze systemu, procesach wytwórczych oraz mechanizmach kontroli stosowanych na każdym etapie cyklu życia rozwiązania.

Korzyści z takiego podejścia wykraczają poza sprawniejszy przebieg audytu. Organizacje zyskują większą kontrolę nad systemem, procesem odbioru i zgodnością kontraktową, a także lepiej zarządzają ryzykami związanymi zarówno z cyberbezpieczeństwem oraz jakością, jak i złożonością współczesnych łańcuchów dostaw.

Autorami artykułu są specjaliści z grupy Spyrosoft, świadczącej usługi doradztwa i inżynierii oprogramowania m.in. dla branży obronnej, lotniczo-kosmicznej, motoryzacyjnej, robotyki, energii odnawialnej, Przemysłu 4.0 oraz sektora danych geoprzestrzennych. Kompetencje grupy obejmują enterprise i embedded software engineering, AI/ML, rozwiązania chmurowe, cyberbezpieczeństwo, HMI oraz platformy low-code i CRM.

Spyrosoft to polska firma działająca na skalę globalną – posiada 24 lokalizacje w 9 krajach i zatrudnia ponad 2000 specjalistów. Wysoką jakość usług potwierdzają międzynarodowe certyfikaty: AQAP 2110:2016, AS EN 9100:2018, AQAP 2310:2022, AQAP 2210:2022, WSK oraz PN-EN ISO 9001:2015. Firma posiada również koncesję MSWiA na prowadzenie działalności gospodarczej w zakresie usług na rzecz obronności i bezpieczeństwa.