Secure by design w umowie IT. Kiedy bezpieczeństwo jest częścią odbioru?

„System zostanie wykonany zgodnie z dobrymi praktykami bezpieczeństwa”.

To zdanie wygląda dobrze w umowie. Do czasu, gdy klient uznaje brak MFA za wadę, a software house za nową funkcję. Albo gdy audyt przed uruchomieniem wykazuje brak rejestrowania zdarzeń, zbyt szerokie uprawnienia i podatne biblioteki, których nie było w makietach ani na liście zadań.

Secure by design powinno wpływać na architekturę i kod, ale w projekcie komercyjnym musi też mieć przełożenie na zakres prac, kryteria odbioru, proces zmian i dokumentację.

30 lipca 2026 r. ENISA opublikowała Secure by Design and Default Playbook. To zestaw praktycznych wskazówek dla mniejszych organizacji. Dla stron umowy jest również dobrą listą pytań o to, kto ma wykonać, sprawdzić i później utrzymywać poszczególne zabezpieczenia.

Czego dowiesz się z tego tekstu?

W skrócie

• Secure by Design oznacza uwzględnianie bezpieczeństwa od pierwszych decyzji o produkcie aż do zakończenia jego utrzymania.
• Secure by Default dotyczy bezpiecznych ustawień początkowych, które nie wymagają od użytkownika samodzielnego naprawiania konfiguracji.
• Umowa powinna wskazywać minimalny poziom zabezpieczeń, odpowiedzialne osoby, kryteria odbioru i dowody wykonania.
• Wymaganie ustalone przed rozpoczęciem prac może być częścią zakresu. Nowe oczekiwanie klienta może wymagać dodatkowego budżetu i terminu.
• Release gate powinien mówić, kiedy problem zatrzymuje wydanie, a kiedy może zostać czasowo zaakceptowany przez wskazaną osobę.

Co oznaczają Secure by Design i Secure by Default?

Secure by Design oznacza projektowanie produktu z uwzględnieniem zagrożeń, zamiast dokładania zabezpieczeń dopiero przed wdrożeniem. Zespół analizuje dane, role użytkowników, miejsca dostępu i możliwe nadużycia już podczas ustalania wymagań oraz architektury.

Secure by Default oznacza, że produkt trafia do klienta z możliwie bezpiecznymi ustawieniami początkowymi. Nie powinien domyślnie udostępniać zbędnych usług, wspólnych haseł ani zbyt szerokich uprawnień tylko dlatego, że tak jest wygodniej podczas wdrożenia.

Repozytorium ENISA zawiera 22 playbooki dotyczące projektowania, rozwoju, wdrożenia, utrzymania i wycofania produktu. Obejmują między innymi:

• granice zaufania i analizę zagrożeń;
• minimalne uprawnienia;
• logowanie, monitoring i alerty;
• bezpieczne kodowanie i testy;
• zarządzanie konfiguracją;
• obsługę incydentów, podatności i poprawek;
• kontrolę bibliotek oraz innych elementów łańcucha dostaw;
• restrykcyjny dostęp początkowy i bezpieczną komunikację.

Każdy playbook ma zasadę, cel, checklistę, minimalny dowód i release gate. Ten ostatni element jest szczególnie ciekawy dla umowy, bo pomaga ustalić, co musi być gotowe przed wydaniem wersji.

ENISA przedstawia playbooki jako praktyczny punkt wyjścia, nie kompletny standard pasujący do każdego produktu. Zakres trzeba dopasować do przeznaczenia systemu, jego użytkowników i ryzyka.

Dlaczego „dobre praktyki bezpieczeństwa” nie wystarczą?

Ogólna klauzula nie mówi, jakie zabezpieczenia strony uznały za wymagane, kto ma je wdrożyć ani jak wykazać ich wykonanie. Najważniejsze ustalenia zostają więc odłożone do odbioru, audytu albo incydentu. Wtedy każda strona czyta to samo zdanie przez pryzmat własnego budżetu.

Klient może zakładać, że dobra praktyka obejmuje:

• MFA, czyli dodatkowe potwierdzenie logowania, dla kont administracyjnych;
• szyfrowanie danych podczas przesyłania i przechowywania;
• podział ról i minimalne uprawnienia;
• rejestrowanie zdarzeń bezpieczeństwa;
• skanowanie bibliotek i obrazów kontenerów;
• testy bezpieczeństwa;
• proces obsługi podatności;
• przygotowanie listy komponentów użytych w produkcie.

Software house może natomiast zakładać, że odpowiada za poprawne wykonanie opisanych funkcji, a projekt zabezpieczeń, testy i późniejsze utrzymanie pozostają po stronie klienta. Oba podejścia mogą mieć sens, ale nie mogą jednocześnie sterować tym samym projektem.

Ogólna klauzula może wyznaczyć kierunek. Nie odpowie jednak, czy MFA mieściło się w wycenie ani czy podatna biblioteka blokuje odbiór.

Czym jest baseline bezpieczeństwa?

Baseline to minimalny zestaw wymagań bezpieczeństwa uzgodniony dla danego produktu. Nie musi mieć stu stron. Powinien jednak pozwalać zespołowi ustalić, co trzeba zbudować, a osobie odbierającej sprawdzić, czy rzeczywiście zostało zbudowane.

Punktem wyjścia mogą być:

• sposób używania produktu i rodzaj danych;
• wyniki analizy ryzyka;
• wymagania klienta enterprise;
• standardy branżowe lub wewnętrzne polityki klienta;
• architektura i środowisko wdrożenia;
• obowiązki, które dotyczą konkretnego produktu.

Baseline może wskazywać na przykład:

• dostęp administracyjny: MFA i osobne konta, potwierdzone testem konfiguracji;
• uprawnienia: role zgodne z zasadą minimalnego dostępu, sprawdzone scenariuszami testowymi;
• biblioteki: brak znanych podatności ponad uzgodniony poziom, potwierdzony raportem ze skanowania;
• logowanie: zapis określonych zdarzeń oraz test działania alertu;
• sekrety: brak haseł i kluczy w repozytorium, potwierdzony automatycznym skanem;
• konfiguracja: uzgodniony wzorzec ustawień produkcyjnych;
• aktualizacje: opisany proces reakcji na krytyczne podatności.

Nie każdy projekt potrzebuje wszystkich tych elementów. Jeżeli jednak wymaganie jest ważne, nie powinno istnieć wyłącznie w głowie specjalisty bezpieczeństwa po stronie klienta.

Kto odpowiada za analizę ryzyka i threat model?

Threat model to uporządkowany opis tego, co chronimy, kto może próbować to naruszyć i którędy może zaatakować system. W typowym projekcie nie da się go sensownie przygotować bez współpracy obu stron.

Klient zna użytkowników, dane, procesy biznesowe i skutki awarii. Powinien przekazać:

• przeznaczenie produktu i grupy użytkowników;
• rodzaje danych;
• ważne wymagania branżowe;
• planowane integracje;
• środowisko wdrożenia;
• procesy, których przerwanie byłoby szczególnie dotkliwe.

Software house zna architekturę, komponenty i ograniczenia techniczne. Może odpowiadać za:

• zaznaczenie miejsc, w których dane lub użytkownik przechodzą między strefami o różnym poziomie zaufania;
• analizę miejsc dostępnych dla atakującego;
• opis najważniejszych scenariuszy nadużyć;
• propozycję zabezpieczeń;
• aktualizację modelu po większej zmianie architektury.

Trzeba też wskazać, kto może zaakceptować ryzyko, którego zespół nie usuwa. Deweloper może opisać skutki techniczne, ale decyzja o przyjęciu ryzyka biznesowego powinna należeć do uprawnionej osoby po stronie klienta lub właściciela produktu.

Kiedy luka jest wadą, a kiedy zmianą zakresu?

Jeżeli zabezpieczenie wynika z uzgodnionej specyfikacji, baseline’u, kryteriów odbioru albo jasno wskazanego standardu, jego brak może być wadą. Jeżeli klient po rozpoczęciu projektu dodaje wymaganie, które zmienia architekturę, integracje lub pracochłonność, może to być zmiana zakresu.

Typowy spór wygląda tak:

• klient: „brak MFA jest oczywistą luką”;
• software house: „MFA nie było na liście funkcji”;
• klient: „umowa wymaga dobrych praktyk”;
• software house: „to nowa integracja i dodatkowy sprint”.

Umowa powinna rozróżniać:

• obowiązkowy baseline;
• ryzyko ujawnione dopiero podczas prac;
• zmianę wymagań klienta;
• zmianę prawa albo wskazanego standardu;
• podatność w bibliotece zewnętrznej;
• błąd w kodzie wykonawcy;
• ulepszenie, którego strony wcześniej nie uzgodniły.

Pomaga w tym krótka procedura zmiany dotyczącej bezpieczeństwa. Zespół opisuje ryzyko, jego wpływ na produkt, proponowane rozwiązanie, koszt i termin. Klient lub właściciel produktu decyduje o wdrożeniu albo czasowym przyjęciu ryzyka, a decyzja trafia do dokumentacji projektu.

Jak opisać odbiór zabezpieczeń?

Jeżeli odbiór sprawdza wyłącznie, czy użytkownik może się zalogować, kupić usługę i pobrać raport, nie odpowiada na pytanie, czy system właściwie ogranicza dostęp oraz rejestruje próby nadużyć. Bezpieczeństwo potrzebuje własnych scenariuszy testowych i dowodów.

Kryteria odbioru mogą obejmować:

• brak podatności krytycznych i wysokich według uzgodnionego sposobu oceny;
• poprawne ograniczenie dostępu między rolami;
• brak domyślnych kont i wspólnych haseł;
• prawidłową zmianę kluczy i innych sekretów;
• rejestrowanie krytycznych zdarzeń;
• szyfrowanie transmisji;
• bezpieczne zachowanie przy błędnej konfiguracji;
• przekazanie dokumentacji architektury i bibliotek.

W umowie lub załączniku trzeba też wskazać narzędzie, środowisko i moment wykonania testu. Raport ze skanera uruchomionego na nieaktualnej wersji kodu nie jest dobrym dowodem odbiorowym.

Minimalny dowód nie musi być obszernym raportem. Może nim być wynik testu, fragment konfiguracji, raport ze skanowania, matryca ról albo zapis automatycznej kontroli wykonanej przed wydaniem.

Czym jest release gate?

Release gate to warunek, bez którego wersja nie trafia na produkcję albo wymaga formalnej zgody na przyjęcie ryzyka. Powinien być proporcjonalny i możliwy do sprawdzenia. Inaczej zamieni się w nieograniczone prawo do zatrzymania każdego wydania.

Release gate może dotyczyć:

• znanych podatności powyżej ustalonego poziomu;
• braku aktualnego threat modelu;
• niewykonanych testów kontroli dostępu;
• konfiguracji niezgodnej z baseline’em;
• braku wymaganej dokumentacji;
• otwartych wyjątków bezpieczeństwa.

Jeżeli ryzyko zostaje czasowo przyjęte, decyzja powinna wskazywać właściciela, uzasadnienie, termin ponownego przeglądu i plan poprawy. Wiadomość „możemy wdrażać” wysłana przez product ownera na komunikatorze nie jest dobrym systemem zarządzania takim wyjątkiem.

Secure by Default i odpowiedzialność za konfigurację

Bezpieczne ustawienia domyślne ograniczają ryzyko, że produkt po wdrożeniu będzie działał z nadmiernymi uprawnieniami, zbędnymi usługami albo wspólnymi hasłami. Umowa powinna określić, kto przygotowuje wzorzec konfiguracji, kto wdraża produkt i kto odpowiada za późniejsze zmiany.

Cyber Resilience Act wzmacnia kierunek, w którym bezpieczeństwo uwzględnia się podczas planowania, projektowania, rozwoju, dostarczania i utrzymywania produktu. Wskazuje też na bezpieczną konfigurację domyślną produktów objętych regulacją. Nie oznacza to jednak, że każdy software house automatycznie jest producentem w rozumieniu CRA. Znaczenie mają konkretny produkt, model współpracy i sposób wprowadzenia go na rynek.

Po przekazaniu systemu klient może:

• wyłączyć MFA;
• udostępnić usługę w publicznym Internecie;
• zwiększyć uprawnienia użytkowników;
• ograniczyć logowanie zdarzeń ze względu na koszty;
• odłożyć aktualizację biblioteki.

Dokumentacja powinna pokazywać stan przekazany przez dostawcę oraz późniejsze decyzje klienta. Bez tego po incydencie strony mogą długo ustalać, kto zmienił konfigurację.

Open source i ewidencja komponentów

Bezpieczeństwo produktu zależy również od bibliotek, obrazów, pakietów i usług zewnętrznych. Umowa powinna określać zasady ich wyboru, ewidencji, monitorowania podatności oraz aktualizacji po zakończeniu wdrożenia.

SBOM, czyli Software Bill of Materials, jest uporządkowaną listą komponentów użytych w produkcie. Raport ENISA o stosowaniu SBOM w 2026 r. pokazuje, że organizacje coraz częściej automatyzują tworzenie takich zestawień i łączą je z procesem rozwoju oprogramowania.

Samo przygotowanie SBOM nie usuwa podatności. Trzeba jeszcze ustalić:

• kto monitoruje nowe informacje o lukach;
• kto ocenia ich znaczenie dla produktu;
• kto przygotowuje poprawkę lub obejście;
• jak długo trwa wsparcie;
• kto informuje klienta;
• co dzieje się po zakończeniu projektu.

Szerzej opisuję ten proces w analizie CVE w PAC4J i odpowiedzialności za obsługę podatności.

Kazus modelowy: audyt dzień przed produkcją

Przyjmijmy realistyczny przykład, który nie opisuje konkretnego klienta. Software house buduje platformę SaaS do obsługi zgłoszeń. Specyfikacja obejmuje role użytkowników, integrację z CRM i panel administracyjny. Umowa zawiera ogólne zobowiązanie do stosowania dobrych praktyk bezpieczeństwa.

Na tydzień przed uruchomieniem klient zleca test bezpieczeństwa. Raport wskazuje:

• brak MFA w panelu administratora;
• możliwość nadania pracownikowi zbyt szerokich uprawnień;
• brak alertu po wielu nieudanych logowaniach;
• bibliotekę ze znaną podatnością wysokiego poziomu;
• logi zawierające dane, które nie powinny się w nich znaleźć.

Klient odmawia odbioru. Software house uznaje MFA i nowy system alertów za dodatkowy zakres. Aktualizacja biblioteki wymaga zmiany innego komponentu, a projekt nie ma uzgodnionych zasad korzystania z bibliotek.

Lepszy proces przewidywałby:

• baseline bezpieczeństwa zatwierdzony przed rozpoczęciem kodowania;
• threat model po ustaleniu architektury;
• matrycę ról jako część specyfikacji;
• automatyczny skan bibliotek przed każdym wydaniem;
• test bezpieczeństwa przed końcowym etapem projektu;
• release gate dla krytycznych i wysokich podatności;
• procedurę oceny, czy nowe wymaganie jest wadą, czy zmianą zakresu.

Taki proces nie gwarantuje produktu bez błędów. Ogranicza jednak ryzyko, że pierwsza poważna rozmowa o bezpieczeństwie odbędzie się dzień przed uruchomieniem.

Co wpisać do umowy z software house’em?

Nie trzeba kopiować całego playbooka ENISA. Umowa i załączniki projektowe powinny jednak odpowiadać na pytania:

• jaki baseline bezpieczeństwa obowiązuje;
• kto dostarcza dane do analizy ryzyka;
• kto przygotowuje i aktualizuje threat model;
• jakie standardy i polityki mają zastosowanie;
• jakie są kryteria odbioru zabezpieczeń;
• jakie dowody trzeba przekazać;
• co zatrzymuje wydanie produkcyjne;
• kto może zaakceptować ryzyko i na jak długo;
• jak odróżniamy wadę od zmiany zakresu;
• kto odpowiada za biblioteki i inne komponenty zewnętrzne;
• kiedy kończy się wdrożenie, a zaczyna maintenance;
• jak dokumentujemy konfigurację przekazaną klientowi.

Model dojrzałości cyberbezpieczeństwa dla MŚP przygotowany przez ENISA może pomóc ocenić, które procesy organizacja już ma, a które istnieją tylko na papierze. Nie zastępuje jednak wymagań konkretnego projektu ani uzgodnień stron.

Bezpieczeństwo potrzebuje właściciela, dowodu i terminu

Secure by design jest procesem. W projekcie komercyjnym trzeba połączyć go z zakresem, budżetem, decyzjami i odbiorem.

Ogólna klauzula bezpieczeństwa może wyznaczyć kierunek. Zespół nadal musi wiedzieć, czy MFA mieściło się w wycenie, kto może przyjąć ryzyko oraz czy podatna biblioteka zatrzymuje produkcję.

Ten temat uzupełnia przewodnik o Cyber Resilience Act i aktualizacjach bezpieczeństwa oraz artykuł o SLA w umowie SaaS, który pokazuje, jak mierzyć jakość usługi po wdrożeniu.

Jeżeli przygotowujesz albo negocjujesz umowę wdrożeniową, w ramach wsparcia prawnego dla firm technologicznych pomagam przełożyć wymagania techniczne na zakres, odbiór i odpowiedzialność stron. Przy produktach usługowych łączę to również ze wsparciem prawnym dla SaaS.

Umów 30-minutową konsultację