Ten artykuł powstał częściowo z pomocą sztucznej inteligencji.
W skrócie: SZBI, czyli system zarządzania bezpieczeństwem informacji, to główny obowiązek podmiotów kluczowych i ważnych według znowelizowanej ustawy o KSC; trzeba go wdrożyć do 3 kwietnia 2027 r. SZBI obejmuje także bezpieczeństwo łańcucha dostaw, a więc firmy, które piszą, utrzymują i hostują oprogramowanie. W praktyce oznacza to ocenę dostawców według ich krytyczności, zapisy bezpieczeństwa w umowach i regularny przegląd. Ten tekst pokazuje, jak to zrobić w odniesieniu do software house’ów i freelancerów, bez tworzenia papierowej fikcji.
Wpis jest częścią naszego przewodnika NIS2 i CRA dla firm, które mają własne aplikacje.
Najważniejsze fakty:
System zarządzania bezpieczeństwem informacji to zestaw zasad, procesów i środków, przez które firma zarządza ryzykiem dla swoich systemów i danych. Znowelizowana ustawa o KSC wymaga go od podmiotów kluczowych i ważnych. SZBI często buduje się w oparciu o normę ISO/IEC 27001, ale sam certyfikat nie jest wymagany i nie zastępuje wdrożenia przepisów ustawy.
SZBI to nie tylko polityki. Obejmuje inwentarz aktywów, analizę ryzyka, kontrolę dostępu, obsługę incydentów, ciągłość działania i bezpieczeństwo przy wytwarzaniu i utrzymaniu oprogramowania. Terminy wdrożenia i pozostałe obowiązki opisujemy w tekście o tym, jakie są terminy z ustawy o KSC dla aplikacji firmy.
Dostawca oprogramowania ma często dostęp, którego nie ma nikt inny: do kodu źródłowego, serwerów produkcyjnych, baz danych i kont administracyjnych. Jeśli jego bezpieczeństwo zawiedzie, zawodzi bezpieczeństwo firmy. Dlatego bezpieczeństwo łańcucha dostaw w SZBI obejmuje nie tylko dostawców sprzętu i chmury, ale też software house’y, freelancerów i agencje, które utrzymują strony i aplikacje.
Według wytycznych technicznych ENISA do środków NIS2 firma powinna mieć politykę bezpieczeństwa łańcucha dostaw, która określa wymagania wobec dostawców, wpływa na ich wybór i przekłada się na zapisy w umowach.
Ocena bez umowy niewiele daje. Umowa z krytycznym dostawcą oprogramowania powinna zawierać: wymagania bezpieczeństwa wobec wytwarzania i utrzymania, czasy reakcji na podatności i incydenty, obowiązek zgłaszania incydentów, prawo do audytu lub do otrzymania raportów z testów, zasady korzystania z podwykonawców, przekazanie kodu źródłowego i dokumentacji oraz plan wyjścia, czyli sposób przekazania systemu innemu wykonawcy. Ostatni punkt jest często pomijany, a to on decyduje, czy firma nie zostanie z aplikacją, której nikt nie potrafi utrzymać.
Audytor zapyta nie tylko o politykę, ale o dowody: listę dostawców z oceną krytyczności, wypełnione kwestionariusze, raporty z przeglądów, umowy z zapisami bezpieczeństwa i historię działań po znalezionych problemach. Najmocniejszym dowodem jest niezależny przegląd techniczny aplikacji dostarczonej przez dostawcę, bo pokazuje, jak jest naprawdę, a nie jak dostawca to opisał. Do takiego przeglądu można użyć listy kontrolnej opartej na OWASP Top 10.
Nie każdy dostawca wymaga takiej samej uwagi. Podział na trzy poziomy pozwala skupić wysiłek tam, gdzie ryzyko jest największe.
Poziom przypisuje się na podstawie dostępu i wpływu na działanie firmy, a nie wartości umowy. Mały freelancer z hasłem administratora do bazy klientów jest dostawcą krytycznym, nawet jeśli jego faktura wynosi kilka tysięcy złotych miesięcznie.
Dobrze prowadzona ocena dostawców nie musi być ciężka. Zaczyna się od listy i podziału na poziomy, a pogłębioną pracę wykonuje się tylko dla kilku najważniejszych relacji. Dla wielu średnich firm to kilku dostawców, a nie kilkudziesięciu, i właśnie od nich warto zacząć przygotowania do terminu z ustawy o KSC.
Dobry dostawca oprogramowania nie traktuje kwestionariusza bezpieczeństwa jak przeszkody. Firmy, które poważnie podchodzą do bezpieczeństwa, mają gotowe odpowiedzi: opis procesu wytwarzania, politykę obsługi podatności, przykładowy raport z testów, wzór SBOM i listę podwykonawców. Jeśli dostawca prosi o kilka tygodni na odpowiedź na podstawowe pytania albo odpowiada ogólnikami, to także jest informacja.
Warto zwrócić uwagę na to, jak dostawca reaguje na prośbę o dostęp do kodu źródłowego i dokumentacji. Odmowa albo zapis, że kod pozostaje własnością dostawcy bez możliwości przekazania, oznacza, że po zakończeniu współpracy firma zostanie z systemem, którego nikt inny nie utrzyma. Z perspektywy ustawy o KSC to ryzyko dla ciągłości działania, które powinno trafić do analizy ryzyka w SZBI.
Nowych dostawców najlepiej oceniać przed podpisaniem umowy, kiedy firma ma największy wpływ na warunki. Przy obecnych dostawcach dobrym momentem jest najbliższe przedłużenie umowy albo zmiana zakresu prac. Dostawcy, z którymi współpraca trwa od lat bez żadnych zapisów dotyczących bezpieczeństwa, powinni trafić na początek kolejki, bo zwykle mają najszerszy dostęp i najmniej udokumentowane zasady.
Sanddev jest software house’em, więc zna te pytania z obu stron. Pomagamy firmom ocenić dostawców technicznie: przeglądamy kod i infrastrukturę dostarczonych aplikacji, oceniamy proces wytwarzania i przygotowujemy wnioski do SZBI. Opisujemy to na stronie o tym, jak wygląda niezależna ocena techniczna dostawców oprogramowania.
SZBI to system zarządzania bezpieczeństwem informacji, który podmioty kluczowe i ważne muszą wdrożyć według znowelizowanej ustawy o KSC do 3 kwietnia 2027 r. Obejmuje m.in. analizę ryzyka, kontrolę dostępu, obsługę incydentów i bezpieczeństwo łańcucha dostaw.
Tak. SZBI według ustawy o KSC obejmuje bezpieczeństwo łańcucha dostaw, czyli także software house’y, freelancerów i firmy hostingowe, które piszą, utrzymują lub hostują oprogramowanie firmy.
Nie. Ustawa o KSC nie wymaga certyfikatu ISO/IEC 27001. Norma ułatwia zbudowanie SZBI, ale certyfikat nie zastępuje wdrożenia obowiązków z ustawy ani sprawdzenia, jak działają systemy i dostawcy.
Krytycznych dostawców warto przeglądać co najmniej raz w roku i po każdym poważnym incydencie po ich stronie. Częstotliwość dla pozostałych dostawców zależy od ich znaczenia dla firmy i wyników analizy ryzyka.
Umowa z krytycznym dostawcą oprogramowania powinna określać wymagania bezpieczeństwa, czasy reakcji na podatności i incydenty, obowiązek zgłaszania incydentów, prawo do audytu, zasady podwykonawstwa, dostęp do kodu źródłowego i plan przekazania systemu innemu wykonawcy.
OWASP Top 10 to lista najpoważniejszych kategorii ryzyka w aplikacjach webowych, publikowana przez fundację OWASP i używana jako punkt odniesienia przez zespoły bezpieczeństwa i audytorów. Aplikacje zbudowane z pomocą AI, na przykład w Lovable z bazą Supabase, najczęściej zawodzą w tych samych miejscach, co opisuje OWASP Top 10, przede wszystkim w kontroli dostępu.
SBOM (software bill of materials) to wykaz komponentów oprogramowania, czyli lista bibliotek, modułów i ich wersji, z których zbudowano produkt. Od 11 grudnia 2027 r. Cyber Resilience Act wymaga od producentów produktów z elementami cyfrowymi sporządzenia SBOM w powszechnie używanym formacie odczytywalnym maszynowo, obejmującym co najmniej zależności najwyższego poziomu.
Cyber Resilience Act (CRA, po polsku akt o cyberodporności) od 11 września 2026 r. nakłada na producentów produktów z elementami cyfrowymi obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.
