CRA, NIS2 i DORA-EU: unijne regulacje oprogramowania a zespoły z agentami
Oprogramowanie, które pomagają dostarczać agenci do kodowania, podlega trzem unijnym aktom, a dane widziane przez agentów dodatkowo RODO: Cyber Resilience Act (CRA) dla produktów z elementami cyfrowymi, NIS2 dla podmiotów kluczowych i ważnych oraz DORA-EU dla podmiotów finansowych. Zgłaszanie podatności i incydentów z CRA obowiązuje od 11 września 2026 r.; SBOM i pozostałe obowiązki od 11 grudnia 2027 r.
Dwa tygodnie po 11 września 2026 r. dział bezpieczeństwa klienta prosi o politykę ujawniania podatności, procedurę 24-godzinnego zgłoszenia z Cyber Resilience Act i SBOM dla wersji, której używa. Większość zeszłokwartalnych aktualizacji zależności przeszła przez Claude Code, Codex i Cursora, recenzent zatwierdził każdy pull request, a nikt nie potrafi powiedzieć, które nowe pakiety sprawdzono, kto to zrobił i względem czego.
Ta strona jest dla CTO, który odpowiada na tę ankietę, i dla członka zarządu, który podpisuje odpowiedź. To inżynierska lektura tekstów prawnych, a nie porada prawna. AI Act, który dotyczy samych agentów, a nie pisanego przez nich oprogramowania, ma osobną stronę.
Co ta strona daje CTO mierzącemu się z unijnymi regulacjami oprogramowania
Dział zatytułowany „Co ta strona daje CTO mierzącemu się z unijnymi regulacjami oprogramowania”- Tabelę decyzyjną: który akt cię dotyczy i w jakiej roli, oraz oś czasu CRA.
- Mapę od błędów agentów do przepisów CRA, kontroli, dowodów i metryk.
- Przetestowaną bramkę zależności w CI, polecenie generujące SBOM i ustawienia zatwierdzania dla agentów.
- Tabelę czterech zegarów incydentowych, runbook na 24 godziny, szablon rejestru, dwa prompty i pięć pytań dla zarządu.
Które unijne przepisy o oprogramowaniu dotyczą firmy używającej agentów do kodowania?
Dział zatytułowany „Które unijne przepisy o oprogramowaniu dotyczą firmy używającej agentów do kodowania?”Przepisy wiążą się z tym, co dostarczasz, i z twoim sektorem, a nie z tym, jak powstał kod. Przejdź tę tabelę dla każdego podmiotu prawnego i każdej linii produktów.
| Jeśli… | Akt | Twoja rola | Czego wymaga |
|---|---|---|---|
| Wprowadzasz na rynek UE oprogramowanie albo urządzenie z oprogramowaniem w ramach działalności handlowej, odpłatnie lub nie | CRA | Producent (art. 3 pkt 13) | Wymagania z załącznika I, należyta staranność wobec komponentów, SBOM, obsługa podatności, zgłoszenia z art. 14, oznakowanie CE |
| Utrzymujesz backend, bez którego produkt nie może wykonać jednej z funkcji | CRA | Backend to zdalne przetwarzanie danych produktu (art. 3 pkt 2) | Te same wymagania obejmują backend |
| Sprzedajesz wyłącznie usługę webową (SaaS) bez żadnego produktu | CRA co do zasady nie | Poza zakresem jako produkt (FAQ Eclipse ORC WG) | Sprawdź NIS2, DORA-EU i RODO |
| Jesteś co najmniej średnim podmiotem w sektorze z załącznika I lub II NIS2, np. usługi chmurowe lub zarządzane (art. 2 ust. 1) | NIS2 | Podmiot kluczowy lub ważny | Zarządzanie ryzykiem (art. 21), odpowiedzialność organu zarządzającego (art. 20), zgłaszanie incydentów (art. 23), według ustawy krajowej |
| Jesteś bankiem, instytucją płatniczą lub pieniądza elektronicznego, firmą inwestycyjną, ubezpieczycielem albo innym podmiotem z art. 2 | DORA-EU | Podmiot finansowy | Ryzyko ICT, zarządzanie zmianą, zgłaszanie incydentów i ryzyko dostawców, od 17 stycznia 2025 r. |
| Dostarczasz oprogramowanie lub usługi podmiotowi finansowemu | DORA-EU, przez umowę | Zewnętrzny dostawca usług ICT (art. 3 pkt 19) | Klient wpisuje umowę do rejestru i zawiera w niej postanowienia z art. 30 |
| Pozwalasz agentom czytać kod, zgłoszenia, logi lub bazy danych z danymi osobowymi | RODO | Administrator; dostawca agenta to zwykle twój podmiot przetwarzający | Umowa powierzenia (art. 28), minimalizacja (art. 5 ust. 1 lit. c), zgłaszanie naruszeń (art. 33), zgodne z prawem przekazywanie (rozdział V) |
Większość firm programistycznych trafia do dwóch lub trzech wierszy. Tam, gdzie DORA-EU pokrywa się z NIS2, pierwszeństwo ma DORA-EU (art. 4 NIS2).
Od kiedy obowiązują wymogi Cyber Resilience Act?
Dział zatytułowany „Od kiedy obowiązują wymogi Cyber Resilience Act?”CRA wszedł w życie 11 grudnia 2024 r. Terminy stosowania rozkłada art. 71, a art. 69 rozstrzyga, które produkty już obecne na rynku obejmuje.
| Data | Co obowiązuje | Których produktów dotyczy |
|---|---|---|
| 11 września 2026 r. | Art. 14: zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów | Każdego produktu w zakresie, również wprowadzonego do obrotu przed 11 grudnia 2027 r. (art. 69 ust. 3) |
| 11 grudnia 2027 r. | Cała reszta: zasadnicze wymagania z załącznika I, SBOM, obsługa podatności, ocena zgodności, oznakowanie CE | Produktów wprowadzanych do obrotu od tej daty; starszych tylko wtedy, gdy zostaną później istotnie zmienione (art. 69 ust. 2) |
Zgłaszanie dotyczy więc już oprogramowania wydanego lata temu, a pipeline wytwarzający dowody SBOM i należytej staranności musi działać przed grudniem 2027 r., a nie powstawać po nim.
Za naruszenie załącznika I oraz art. 13 i 14 grożą kary do 15 mln euro lub 2,5% całkowitego rocznego światowego obrotu, zależnie od tego, która kwota jest wyższa (art. 64). Mikro- i małe przedsiębiorstwa nie dostaną kary za spóźnione 24-godzinne wczesne ostrzeżenie, a zarządcy oprogramowania open source nie dostaną jej wcale (art. 64 ust. 10).
Czego wymaga art. 14 CRA od 11 września 2026 r.?
Dział zatytułowany „Czego wymaga art. 14 CRA od 11 września 2026 r.?”Art. 14 tworzy dwa obowiązki zgłoszeniowe o tej samej budowie. Zgłoszenia trafiają przez pojedynczą platformę zgłoszeń prowadzoną przez ENISA (art. 16) do CSIRT wyznaczonego jako koordynator w państwie członkowskim twojej głównej siedziby i jednocześnie do ENISA.
| Zdarzenie | Wczesne ostrzeżenie | Zgłoszenie | Raport końcowy |
|---|---|---|---|
| Aktywnie wykorzystywana podatność w twoim produkcie: wiarygodny dowód, że złośliwy podmiot wykorzystał ją bez zgody właściciela systemu (art. 3 pkt 42) | W ciągu 24 godzin od powzięcia wiadomości, ze wskazaniem państw członkowskich, w których produkt jest dostępny | W ciągu 72 godzin: exploit, podatność, środki naprawcze i to, co mogą zrobić użytkownicy | 14 dni od udostępnienia poprawki lub środka zaradczego |
| Poważny incydent mający wpływ na bezpieczeństwo produktu (art. 14 ust. 5) | W ciągu 24 godzin, z informacją, czy podejrzewa się działanie złośliwe | W ciągu 72 godzin: wstępna ocena i środki łagodzące | Miesiąc od zgłoszenia |
Musisz też poinformować dotkniętych użytkowników o środkach, które mogą wdrożyć (art. 14 ust. 8). Incydent jest poważny, gdy „doprowadził lub może doprowadzić do wprowadzenia lub wykonania złośliwego kodu w produkcie z elementami cyfrowymi lub w sieciach i systemach informatycznych użytkownika” (art. 14 ust. 5 lit. b, w naszym tłumaczeniu). Złośliwy pakiet, który agent wciągnął do wydania, jest dokładnie tym, a producent zgłasza go bez względu na to, czy dodał go człowiek, czy agent.
Jak slopsquatting i dryf zależności spotykają się z CRA?
Dział zatytułowany „Jak slopsquatting i dryf zależności spotykają się z CRA?”Agenci do kodowania często zmieniają zależności i dokładają błąd, który ludziom rzadko się zdarza: pewne siebie odwołanie do pakietu, który nie istnieje. OWASP GenAI LLM Top 10 2026 (LLM04 Supply Chain, opublikowane 4 sierpnia 2026 r.) nazywa ten atak: asystenci kodowania „masowo halucynują wiarygodne, ale nieistniejące nazwy pakietów”, które atakujący rejestrują zawczasu. To slopsquatting. Cytowane tam badanie, praca Spracklena i współautorów z USENIX Security 2025, wykazało, że mniej więcej co piąte odwołanie do pakietu w kodzie wygenerowanym przez LLM (19,7% w 16 modelach) wskazywało pakiet, który nie istnieje. To dane wtórne: pochodzą z omówień Aikido Security i Cloud Security Alliance, a samej pracy nie czytaliśmy.
Każdy błąd agenta trafia w konkretny przepis CRA:
| Błąd agenta | Przepis CRA | Kontrola | Dowód, który zostaje |
|---|---|---|---|
| Dodaje nieistniejący pakiet albo taki, który atakujący zarejestrował pod zmyśloną nazwą | Art. 13 ust. 5, należyta staranność; załącznik I część I pkt 2 lit. a; art. 14 ust. 5 lit. b, jeśli złośliwy kod trafi do wydania | Bramka CI: każda nowa bezpośrednia zależność istnieje w rejestrze i jest na liście zatwierdzonych | Log bramki dla każdego pull requesta; kto i kiedy zatwierdził wpis na liście |
| Dodaje prawdziwy, ale nowiutki, nieutrzymywany lub typosquattowany pakiet | Art. 13 ust. 5 | Bramka ostrzega o pakietach opublikowanych niedawno; zatwierdza wskazana osoba | Zapis zatwierdzenia z uzasadnieniem |
| Zostawia nieprzypięte wersje, więc następna instalacja rozwiązuje coś nowego (dryf zależności) | Załącznik I część II pkt 1: SBOM | Lockfile w repozytorium; CI instaluje wyłącznie z niego | SBOM z lockfile’a dla każdego wydania |
| Podbija podatny komponent w środku dużej zmiany funkcjonalnej | Załącznik I część II pkt 2: aktualizacje bezpieczeństwa oddzielnie od funkcjonalnych, gdy to wykonalne | Jeden pull request na poprawkę bezpieczeństwa, zapisany w instrukcjach agenta | Informacje o wydaniu z osobną listą poprawek bezpieczeństwa |
| Łata dołączony komponent open source i idzie dalej | Art. 13 ust. 6: zgłoś opiekunowi i udostępnij poprawkę | Krok zgłoszenia upstream w runbooku | Link do zgłoszenia upstream |
| Wydaje wersję, o której zawartości nikt nie wie | Załącznik I część II pkt 1 i 3: SBOM, testy bezpieczeństwa | SBOM i skan podatności przy każdym wydaniu | Oba zarchiwizowane z wydaniem |
Wbuduj kontrole zależności w pipeline
Dział zatytułowany „Wbuduj kontrole zależności w pipeline”Te kontrole wytwarzają dowody dla CRA bez czytania każdej zmiany zależności przez człowieka. Egzekwuje bramka CI, na każdej zmianie, bez względu na autora; ustawienia po stronie agenta tylko go spowalniają, bo agent może edytować manifest bez uruchamiania polecenia instalacji.
-
Trzymaj listę zatwierdzonych zależności w repozytorium. Jedna nazwa pakietu na wiersz w
docs/compliance/approved-dependencies.txt, zmieniana wyłącznie za zgodą code ownera z zespołu bezpieczeństwa lub platformy. Historia tego pliku jest twoim zapisem należytej staranności. -
Blokuj w CI niezatwierdzone i nieistniejące zależności. Ten skrypt kończy się błędem, gdy nowej bezpośredniej zależności nie ma na liście zatwierdzonych albo nie istnieje ona w rejestrze npm, i ostrzega, gdy pakiet po raz pierwszy opublikowano mniej niż 90 dni temu, co jest częstą cechą nazw ze slopsquattingu.
#!/usr/bin/env bash# scripts/check-new-deps.sh: run on pull requests (tested with npm 10.9 and jq)set -euo pipefailBASE="${BASE_REF:-origin/main}"deps() { jq -r '((.dependencies // {}) + (.devDependencies // {})) | keys[]' | sort -u; }comm -13 <(git show "$BASE:package.json" | deps) <(deps < package.json) > new-deps.txtstatus=0while read -r dep; doif ! grep -qxF "$dep" docs/compliance/approved-dependencies.txt; thenecho "::error::$dep is not in docs/compliance/approved-dependencies.txt"; status=1fiif ! created=$(npm view "$dep" time.created 2>/dev/null); thenecho "::error::$dep does not exist on the npm registry (possible hallucinated name)"; status=1; continuefiif [ "$(date -d "$created" +%s)" -gt "$(date -d '90 days ago' +%s)" ]; thenecho "::warning::$dep was first published on $created, less than 90 days ago"fidone < new-deps.txtexit "$status"Uruchamiaj go jako wymagane sprawdzenie na każdym pull requeście; plik workflow, wariant dla Pythona i reguły
CODEOWNERSopisuje strona kontrola zależności w zmianach agentów. -
Generuj SBOM dla każdego wydania. npm 10 ma wbudowany generator. Uruchom go w jobie wydania i zarchiwizuj plik razem z buildem:
Okno terminala # Release job: CycloneDX SBOM from the lockfile, production dependencies onlynpm sbom --sbom-format cyclonedx --package-lock-only --omit dev > sbom.cdx.jsonCRA wymaga „powszechnie stosowanego formatu nadającego się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu” (załącznik I część II pkt 1); CycloneDX i SPDX (
--sbom-format spdx) spełniają ten warunek. SBOM należy do dokumentacji technicznej (załącznik VII) i nie musi być publiczny. -
Skanuj każde wydanie pod kątem znanych podatności. Na przykład OSV-Scanner (
osv-scanner scan source -r .) sprawdza lockfile’e w drzewie katalogów względem bazy OSV. Zarchiwizuj raport obok SBOM. Znalezisko ze znanym wykorzystaniem uruchamia opisany niżej runbook z art. 14. -
Każ agentowi pytać przed instalacją. To próg zwalniający, ustawiany centralnie, żeby programiści nie mogli go wyłączyć. Ustawienia różnią się między narzędziami:
Dodaj regułę
askw ustawieniach zarządzanych (w Linuksie/etc/claude-code/managed-settings.json, w macOS/Library/Application Support/ClaudeCode/managed-settings.json). Claude Code ocenia regułyaskidenynawet wtedy, gdy hook zwróci „allow”, więc projekt nie może ich obejść.{"permissions": {"ask": ["Bash(npm install *)", "Bash(npm i *)", "Bash(pnpm add *)","Bash(pnpm install *)", "Bash(yarn add *)", "Bash(bun add *)","Bash(pip install *)", "Bash(uv add *)"]}}Lista jest przykładowa: poleceń instalacji da się zapisać więcej, niż obejmie jakakolwiek lista wzorców, i dlatego kontrolą jest bramka CI z kroku 2. Uruchom
/statusi sprawdź, czy wśród źródeł ustawień jest plik zarządzany.Dodaj regułę prefiksową w egzekwowanym przez administratora
requirements.toml(w Linuksie/etc/codex/requirements.toml). Codex stosuje najbardziej restrykcyjny wynik ze wszystkich warstw, arequirements.tomlprzyjmuje wyłączniepromptlubforbidden. Sprawdzone w kodzie źródłowym Codex 26 września 2026 r. (codex-cli 0.157.1).[[rules.prefix_rules]]pattern = [{ token = "npm" }, { any_of = ["install", "i", "add"] }]decision = "prompt"justification = "New dependencies need an approved-list entry (CRA Art. 13(5))"[[rules.prefix_rules]]pattern = [{ token = "pip" }, { token = "install" }]decision = "prompt"justification = "New dependencies need an approved-list entry (CRA Art. 13(5))"Zdarzeń hooków Cursora ani egzekwowania na poziomie zespołu nie dało się 26 września 2026 r. zweryfikować na cursor.com, więc nie podajemy konfiguracji. Oprzyj się na bramce CI i regule projektu, że nowa zależność wymaga wpisu w
docs/compliance/approved-dependencies.txt.
Stan zgodności psuje się z każdym scalonym pull requestem, jeśli nic go nie sprawdza ponownie. Śledź każdą kontrolę jedną metryką:
| Kontrola | Metryka i cel | Właściciel, częstotliwość |
|---|---|---|
| Bramka zależności | Pokrycie bramką: scalone pull requesty zmieniające manifest, które przeszły przez bramkę, 100% | Zespół platformy, każdy pull request |
| SBOM i skan | Wydania z zarchiwizowanym SBOM i raportem ze skanu, 100% | Właściciel wydania, każde wydanie |
| Ćwiczenie zgłoszenia | Czas do wczesnego ostrzeżenia, od zasymulowanego powzięcia wiadomości do gotowego projektu zgłoszenia, wyraźnie poniżej 24 godzin | Lider bezpieczeństwa, dwa razy w roku i po zmianie dyżurów |
| Rejestr i dostawcy | Każdy dystrybuowany artefakt przejrzany w tym kwartale; każdy dostawca agentów z aktualną umową powierzenia (a dla klientów finansowych z postanowieniami DORA-EU) | CTO z prawnikiem i działem zakupów, co kwartał |
Kogo obejmuje NIS2 i czego wymaga od pipeline’u?
Dział zatytułowany „Kogo obejmuje NIS2 i czego wymaga od pipeline’u?”NIS2 dotyczy co najmniej średnich podmiotów rodzaju wymienionego w załączniku I lub II oraz niektórych mniejszych bez względu na wielkość (art. 2). Dla firmy programistycznej typowe drogi wejścia to usługi chmurowe i usługi zarządzane, w tym obsługa lub utrzymanie aplikacji klientów (art. 6 pkt 39). Obowiązuje przez ustawy krajowe od 18 października 2024 r. (art. 41).
| Artykuł | Co mówi | Co to znaczy dla zmian pisanych przez agentów |
|---|---|---|
| Art. 20 | Organ zarządzający zatwierdza i nadzoruje środki zarządzania ryzykiem, może ponosić odpowiedzialność i musi przejść szkolenie | Zarząd zatwierdza politykę agentów i bramki zmian, nie tylko CTO |
| Art. 21 ust. 2 lit. d | Bezpieczeństwo łańcucha dostaw, w tym bezpośredni dostawcy i usługodawcy | Dostawcy agentów do kodowania i serwery MCP to dostawcy. Oceniaj ich jak każdych innych |
| Art. 21 ust. 2 lit. e | Bezpieczny rozwój i utrzymanie systemów, w tym obsługa podatności | Bramka zależności, SBOM i runbook są dowodem |
| Art. 23 | Poważne incydenty: wczesne ostrzeżenie po 24 godzinach, zgłoszenie po 72 godzinach, raport końcowy po miesiącu | Awaria spowodowana przez agenta może się kwalifikować; zegar rusza z chwilą powzięcia wiadomości |
Art. 21 ust. 2 wymienia też kontrolę dostępu, więc agent działający z pełnymi uprawnieniami programisty to uwaga audytowa; zobacz tożsamość, poświadczenia i sekrety agentów. Kary ustala prawo krajowe w granicach art. 34: maksimum wynosi co najmniej 10 mln euro lub 2% światowego obrotu dla podmiotów kluczowych i co najmniej 7 mln euro lub 1,4% dla podmiotów ważnych.
W Polsce NIS2 transponuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa; 26 września 2026 r. serwis ISAP był niedostępny, więc nie cytujemy jej przepisów.
Czego DORA-EU wymaga od podmiotów finansowych, których kod piszą agenci?
Dział zatytułowany „Czego DORA-EU wymaga od podmiotów finansowych, których kod piszą agenci?”DORA-EU obowiązuje bezpośrednio od 17 stycznia 2025 r. (art. 64) i nie ma związku z metrykami dostarczania DORA ani z modelem DORA AI Capabilities. O tym, jak podmiot finansowy może używać agentów do kodowania, decydują cztery przepisy:
- Ryzyko ICT należy do organu zarządzającego. Ponosi on „ostateczną odpowiedzialność za zarządzanie ryzykiem ICT podmiotu finansowego” (art. 5 ust. 2), więc wprowadzenie agentów to jego decyzja, a nie wybór narzędzia przez zespół.
- Zarządzanie zmianą musi być kontrolowane. Wszystkie zmiany w systemach ICT są rejestrowane, testowane, oceniane, zatwierdzane, wdrażane i weryfikowane w kontrolowany sposób (art. 9 ust. 4 lit. e). Zmiana napisana przez agenta potrzebuje tego samego zapisu co zmiana człowieka; takim zapisem ma być pakiet dowodów.
- Dostawcy agentów do kodowania to zewnętrzni dostawcy usług ICT (art. 3 pkt 19). Anthropic, OpenAI i Anysphere trafiają do rejestru informacji (art. 28 ust. 3) po weryfikacji należytej staranności (art. 28 ust. 4), z postanowieniami z art. 30 w umowie.
- Poważne incydenty związane z ICT zgłasza się właściwemu organowi (art. 19), w terminach określonych w aktach delegowanych i wykonawczych Komisji.
Jeśli sprzedajesz podmiotowi finansowemu, DORA-EU dosięga cię przez umowę: prawo do audytu, warunki wyjścia i pytania o to, jak zatwierdzasz zmiany pisane przez agentów. Rozdział obowiązków omawia strona branże regulowane.
Jak RODO dotyczy przepływów danych agentów?
Dział zatytułowany „Jak RODO dotyczy przepływów danych agentów?”RODO obowiązuje za każdym razem, gdy agent widzi dane osobowe, a agenci widzą ich więcej, niż się wydaje: fixtures testowe, wklejone fragmenty logów, produkcyjną bazę danych za serwerem MCP, zgłoszenie klienta. Zmapuj każdy przepływ, zanim poszerzysz dostęp agentów.
| Przepływ | Pytanie z RODO | Kontrola |
|---|---|---|
| Prompty, kod i wyniki narzędzi wysyłane do dostawcy modelu | Umowa powierzenia (art. 28)? Przekazanie poza EOG (rozdział V)? | Warunki enterprise z umową powierzenia; świadomy wybór, gdzie działa model |
| Agent czyta bazę danych lub system zgłoszeń przez serwer MCP | Czy dostęp jest ograniczony do potrzeb zadania (art. 5 ust. 1 lit. c) i zaprojektowany z myślą o ochronie danych (art. 25)? | Poświadczenia MCP tylko do odczytu na zanonimizowanej lub syntetycznej kopii |
| Transkrypcje na komputerach programistów | Retencja: Claude Code trzyma je w ~/.claude/projects/ domyślnie przez 30 dni (cleanupPeriodDays); Codex w ~/.codex/sessions/ (codex-cli 0.157.1) | Ustaw retencję centralnie; obejmij katalogi regułami DLP |
| Dane osobowe wyciekają przez agenta | Zgłoszenie organowi nadzorczemu w ciągu 72 godzin, jeżeli to wykonalne (art. 33) | Runbook poniżej; model zagrożeń agentów |
Tryby retencji u dostawców i wyłączenie trenowania na danych opisuje strona prywatność danych i polityki firmowe.
Jeden incydent agenta, cztery zegary zgłoszeń
Dział zatytułowany „Jeden incydent agenta, cztery zegary zgłoszeń”Załóżmy, że agent dodaje pakiet ze slopsquattingu, który trafia do twojej aplikacji desktopowej i wysyła tokeny klientów atakującemu. To poważny incydent w rozumieniu CRA, być może poważny incydent w rozumieniu NIS2, poważny incydent związany z ICT, jeśli jesteś podmiotem finansowym, i naruszenie ochrony danych osobowych w rozumieniu RODO.
| Akt | Komu zgłaszasz | Pierwszy termin | Dalej |
|---|---|---|---|
| CRA art. 14 | CSIRT koordynator i ENISA, przez pojedynczą platformę zgłoszeń | Wczesne ostrzeżenie, 24 godziny | Zgłoszenie po 72 godzinach; raport końcowy; informacja dla użytkowników |
| NIS2 art. 23 (ustawa krajowa) | Krajowy CSIRT lub właściwy organ | Wczesne ostrzeżenie, 24 godziny | Zgłoszenie po 72 godzinach; raport końcowy po miesiącu |
| DORA-EU art. 19 | Właściwy organ nadzoru finansowego | Według aktów delegowanych i wykonawczych | Raport pośredni i końcowy; informacja dla dotkniętych klientów |
| RODO art. 33 | Organ nadzorczy (w Polsce Prezes UODO) | 72 godziny, jeżeli to wykonalne | Zawiadomienie osób, których dane dotyczą, przy wysokim ryzyku (art. 34) |
Pierwsze 24 godziny, przy założeniu, że istnieje wyznaczony kierownik incydentu i dyżur bezpieczeństwa:
-
Godzina 0: zapisz moment powzięcia wiadomości wraz ze źródłem. Od niego ruszają wszystkie zegary.
-
Godziny 0–4: sklasyfikuj zdarzenie względem wszystkich czterech aktów, zapisując każdą odpowiedź z uzasadnieniem.
-
Godziny 4–12: ustal dotknięte wersje i państwa członkowskie na podstawie archiwum SBOM i danych sprzedażowych.
-
Godziny 12–24: wyślij każde wczesne ostrzeżenie, które ma zastosowanie. Wczesne ostrzeżenie z niepełnymi faktami jest zgodne z przepisami; spóźnione i kompletne nie jest.
-
Przed upływem 72 godzin: wyślij zgłoszenia i opublikuj komunikat dla użytkowników wymagany przez CRA.
-
Po poprawce: zgłoś upstream i zamknij sprawę. Udostępnij poprawkę opiekunowi komponentu (art. 13 ust. 6 CRA), złóż raporty końcowe i dodaj test regresyjny oraz zmianę bramki; analizę po incydencie opisuje strona gdy agent powoduje incydent.
Prowadź jeden rejestr stosowania przepisów
Dział zatytułowany „Prowadź jeden rejestr stosowania przepisów”Rejestr odpowiada na ankiety klientów i zapisuje, kto podjął każdą decyzję klasyfikacyjną, po jednym wpisie na produkt lub usługę:
- id: desktop-client owner: "team-client-platform" cra: role: manufacturer # manufacturer | importer | distributor | out-of-scope product_type: software # software | hardware | remote-data-processing support_period_until: 2032-12-31 # at least five years (Art. 13(8)) csirt_coordinator: "CSIRT of the main establishment's member state" sbom: "release artifacts: sbom.cdx.json" cvd_policy: "https://example.com/security/disclosure" nis2: { entity: important, national_law: "check transposing act" } dora_eu: { financial_entity: false, supplies_financial_entities: true } gdpr: { personal_data: true, processors: [Anthropic, OpenAI] } agent_controls: dependency_gate: "scripts/check-new-deps.sh" approved_list: "docs/compliance/approved-dependencies.txt" reviewed: 2026-09-26 reviewer: "cto"Prompty do skopiowania: mapa ekspozycji regulacyjnej
Dział zatytułowany „Prompty do skopiowania: mapa ekspozycji regulacyjnej”Uruchom je z katalogu głównego repozytorium w Claude Code, Codex lub Cursorze; są identyczne we wszystkich trzech narzędziach. Prompty są po angielsku, ale działają tak samo po polsku: możesz je przetłumaczyć, zostawiając bez zmian ścieżki plików i polecenia.
Traktuj oba wyniki jako szkice: każdą klasyfikację CTO podpisuje z prawnikiem, a każdy oznaczony pakiet dostaje zapis zatwierdzenia albo pull request, który go usuwa.
Co psuje zgodność z unijnymi regulacjami w zespołach pracujących z agentami?
Dział zatytułowany „Co psuje zgodność z unijnymi regulacjami w zespołach pracujących z agentami?”Traktowanie 11 grudnia 2027 r. jako daty startu. Zgłoszenia z art. 14 już dotyczą produktów obecnych na rynku. Wyjście: wyznacz dyżur bezpieczeństwa jako właściciela zgłoszeń z CRA już dziś i przeprowadź ćwiczenie w tym kwartale.
Agent dodaje zależność, edytując manifest. Reguły zatwierdzania poleceń się nie uruchamiają, bo żadne polecenie instalacji nie padło. Wyjście: kontrolą jest bramka CI; mierz pokrycie bramką, a nie liczbę monitów.
Agent „naprawia” czerwoną bramkę. Poproszony o zazielenienie pull requesta dopisuje pakiet do listy zatwierdzonych albo luzuje skrypt. Wyjście: recenzja właściciela kodu dla plików bramki; pull request zmieniający jednocześnie manifest i listę wymaga akceptacji kogoś z bezpieczeństwa.
Poprawki bezpieczeństwa zakopane w pull requestach funkcjonalnych agenta. Użytkownicy nie mogą wziąć poprawki bez nowej funkcji. Wyjście: zapisz w CLAUDE.md lub AGENTS.md, że poprawki bezpieczeństwa idą w osobnym pull requeście, i odrzucaj w review pull requesty mieszane.
„Jesteśmy SaaS, więc nas to nie dotyczy”. NIS2, umowy z DORA-EU i RODO prawdopodobnie tak, a klient desktopowy, aplikacja mobilna, SDK lub agent instalowany u klienta przywracają CRA. Wyjście: wypełnij rejestr dla każdego dystrybuowanego artefaktu.
Pięć pytań, które członek zarządu może zadać CTO
Dział zatytułowany „Pięć pytań, które członek zarządu może zadać CTO”- Które nasze produkty są „produktami z elementami cyfrowymi” w rozumieniu CRA i kto jest wskazany jako producent każdego z nich?
- Gdyby dziś w nocy ktoś wykorzystał podatność w naszym produkcie, kto złoży 24-godzinne wczesne ostrzeżenie i kiedy ostatnio to ćwiczyliśmy?
- Co powstrzymuje agenta przed dodaniem pakietu, który nie istnieje albo został zarejestrowany w zeszłym tygodniu, i jaki odsetek pull requestów przeszedł tę kontrolę w ostatnim kwartale?
- Czy potrafimy dziś, bez przebudowy, pokazać SBOM dla wersji, której używa konkretny klient?
- Którzy nasi klienci są podmiotami finansowymi i co im obiecaliśmy w sprawie zatwierdzania zmian?
Dokąd dalej z unijnymi regulacjami i agentami
Dział zatytułowany „Dokąd dalej z unijnymi regulacjami i agentami”Najczęstsze pytania
Od kiedy obowiązują wymogi Cyber Resilience Act?
Obowiązek zgłaszania podatności i incydentów z art. 14 obowiązuje od 11 września 2026 r., również dla produktów wprowadzonych do obrotu przed 11 grudnia 2027 r. Wszystko inne, w tym SBOM z załącznika I część II, obowiązuje od 11 grudnia 2027 r.
Czy ta strona dotyczy metryk DORA?
Nie. DORA-EU to akt o operacyjnej odporności cyfrowej, rozporządzenie (UE) 2022/2554, który wiąże podmioty finansowe od 17 stycznia 2025 r. Metryki DORA i model DORA AI Capabilities to programy badawcze opisane na osobnych stronach.
Czy dla CRA ma znaczenie, że kod napisał agent?
Nie. CRA wymaga od producenta tego samego bez względu na to, kto napisał kod. Agenci zwiększają liczbę zmian w zależnościach i dokładają nowy błąd, zmyślone nazwy pakietów rejestrowane potem przez atakujących, więc dowody należytej staranności i SBOM musi wytwarzać pipeline, a nie ludzie.
Czy czysty produkt SaaS podlega CRA?
Co do zasady nie jako produkt: CRA obejmuje backend jako zdalne przetwarzanie danych produktu z elementami cyfrowymi. Firmę SaaS częściej obejmie NIS2, DORA-EU, jeśli obsługuje podmioty finansowe, oraz RODO.