CRA, czyli jak zarządzać podatnościami w oprogramowaniu

Michał Nowakowski · 9 października 2026

Jest sobie takie rozporządzenie 👩🏼‍⚖️ - CRA (Cyberresilience Act), którego odpowiedzialne stosowanie mogłoby nas uchronić przed wieloma incydentami.

Ignorantia iuris nocet. Nieznajomość prawa szkodzi. Co łączy incydenty mydr, eWuś, wakacjePL z tą łacińską paremią?

Jest sobie takie rozporządzenie 👩🏼‍⚖️ - CRA (Cyberresilience Act z numerkiem 2024/2847), którego odpowiedzialne stosowanie mogłoby nas uchronić przed wieloma incydentami. No bo, jeżeli przyjrzymy się temu co wydarzyło się w ostatnich miesiącach, to nie sposób nie stwierdzić, że "gdyby tylko CRA było w mocy, to byłoby lepiej". Potencjalnie.

O tym dużo ostatnio rozmawiamy z Andrzej P iotrowski.

Dzisiaj większość z nas unika poważnej rozmowy o CRA, a tymczasem:

✅ to rozporządzenie wprowadza wymóg projektowania, opracowywania i produkcji produktów z elementami cyfrowymi w sposób bezpieczny i zgodny z najlepszymi standardami i dobrymi praktykami - security by design (zagadnieniu poświęciłem dużo miejsca w newsletterze),

✅ produkty takie (np. oprogramowanie, fizyczne urządzenia z aplikacjami) będziemy mogli udostępniać na rynku tylko wtedy, gdy będą miały spełniony określony poziom cyberbezpieczeństwa adekwatny do generowanego ryzyka,

✅ producenci takich rozwiązań mają (już od września) obowiązek zgłaszania wszystkich aktywnie wykorzystywanych podatności zawarte w produkcie z elementami cyfrowymi, o których się dowiedział, do właściwych CSIRT'ów,

✅ producenci będą mieli szereg obowiązków w zakresie zarządzania ryzykiem, które dzisiaj są często albo wyłącznie papierowe, albo wręcz ignorowane czy informowania użytkowników (załącznik II określa te obowiązki)

Jest tego więcej, ale te powyżej dają pewien zarys tego co "daje" CRA. I teraz spójrzmy na ostatnie wydarzenio-incydenty. Czy gdyby CRA było pełni w mocy w czasie, gdy one nastąpiły?

Cóż, trudno jednoznacznie ocenić, ale przynajmniej byłyby kary, które niestety - nad czym ubolewam - stanowią ważny czynnik motywujący. Samo CRA ma dość proste założenie:

✅ jeżeli tworzysz produkt z elementem cyfrowym, to musisz zrobić to w sposób zapewniający wysoki poziom odporności i dodatkowo musisz na bieżąco monitorować potencjalne podatności ✅

W przypadku oprogramowania jest to między innymi podejście oparte o tzw. secure SDLC, czyli taki proces wytwarzania, który uwzględnia kwestie bezpieczeństwa zgodnie z zasadą SHIFT LEFT - im szybciej tym lepiej.

Ostatnie rekomendacje z wytycznych ENISA w zakresie wykorzystania asystentów i agentów AI do developmentu, które często i gęsto omawiałem, są przykładem takiej "strategii", choć nie jedyną.

To motywator, który ma zapewnić, że dostawcy rozwiązań nie będą odwalali ❌ fuszery ❌ i wezmą za to odpowiedzialność. I choć zasadniczo rozwiązania SaaS nie będą się pod to kwalifikowały (więcej w moich wyjaśnieniach), to nawet Polish Financial Supervision Authority podkreśla konieczność przeglądu tych rozwiązań pod kątem zbliżonym do CRA.

Dzisiaj może się nam wydawać, że CRA nas nie dotyczy, ale jeżeli zbyt późno przyjdzie otrzeźwienie i jednak staniemy przed koniecznością wdrożenia rozporządzenia, to możemy nie mieć wystarczająco dużo czasu.