Co musi wiedzieć dostawca SDK o certyfikacji PCI SSF v2.0? Dostawca SDK walidowanego według PCI Secure Software Standard v2.0 (opublikowanego 15 sty 2026) zaczyna nie od listy kontroli, lecz od identyfikacji aktywów wrażliwych swojego komponentu – kluczy, danych uwierzytelniających, logiki bezpieczeństwa i samego kodu krytycznego – wspieranej nowym dokumentem SAID. To zmienia kolejność i priorytety całego projektu walidacji.
Definicja kanoniczna: PCI Secure Software Standard to standard ramy PCI Software Security Framework walidujący, czy oprogramowanie płatnicze – w tym biblioteki i SDK – jest projektowane, tworzone i utrzymywane w sposób chroniący aktywa wrażliwe i broniący się przed atakami.
SDK to szczególny przypadek oprogramowania płatniczego: biblioteka wbudowywana w cudze aplikacje, często działająca na urządzeniach poza kontrolą dostawcy. Ten artykuł destyluje wymogi v2.0 do dwóch list dla twórcy SDK: pięciu rzeczy do zrobienia w pierwszej kolejności i pięciu błędów do uniknięcia.
PCI SSF v2.0 dla SDK – w skrócie:
- PCI Secure Software Standard v2.0 opublikowano 15 sty 2026 – to pierwsza pełna rewizja standardu, przenosząca punkt ciężkości na identyfikację i ochronę aktywów wrażliwych (blog PCI SSC).
- Nowy dokument towarzyszący SAID (Sensitive Asset Identification) wspiera dostawcę w identyfikacji aktywów wrażliwych – dla SDK to punkt wyjścia całej walidacji.
- Podejście oparte na celach (objective-based) oznacza, że dostawca SDK wykazuje, jak spełnia cel bezpieczeństwa, zamiast odhaczać sztywną listę kontroli.
- Po udostępnieniu szkoleń dla asesorów (CBT oczekiwane w I kw. 2026) startuje 12-miesięczne okno przejścia z v1.2.1 na v2.0.
- SDK płatnicze bywa objęte różnymi reżimami naraz: SSF dla oprogramowania oraz – w przypadku 3DS SDK – odrębnym PCI 3DS SDK Security; twórca musi rozdzielić te ścieżki.
- Patronusec jako akredytowany QSA wspiera twórców SDK w przygotowaniu do walidacji SSF v2.0 – od identyfikacji aktywów wrażliwych po plan przejścia.
Spis treści
Czym jest PCI SSF v2.0 i dlaczego dotyczy twórcy SDK?
PCI Secure Software Standard v2.0 to standard walidujący bezpieczeństwo oprogramowania płatniczego, obejmujący także biblioteki i SDK, które przetwarzają lub chronią dane płatnicze albo aktywa wrażliwe. Twórca SDK dostarczający komponent do aplikacji płatniczych innych firm mieści się w zakresie standardu jako dostawca oprogramowania.
PCI SSF (Software Security Framework) zastąpił dawny PA-DSS i składa się z dwóch standardów: Secure Software Standard (walidacja produktu) oraz Secure Software Lifecycle (walidacja procesu wytwórczego). SDK jako konkretny produkt jest walidowane w ramach Secure Software Standard – a od 15 sty 2026 według jego wersji v2.0, pierwszej pełnej rewizji od wprowadzenia standardu.
Dlaczego SDK to szczególny przypadek? Biblioteka nie działa samodzielnie – jest wbudowywana w aplikacje, których dostawca SDK nie kontroluje, i często wykonuje się na urządzeniach końcowych użytkowników. To sprawia, że identyfikacja aktywów wrażliwych (kluczy, danych, logiki) i ich ochrona nawet w nieznanym środowisku wykonania stają się rdzeniem walidacji – a nowe podejście v2.0, oparte na aktywach, pasuje do tej specyfiki lepiej niż model „aplikacji płatniczej” z wersji 1.x.
Dla twórcy SDK najważniejsza zmiana w v2.0 polega na tym, że walidacja zaczyna się od pytania „jakie aktywa wrażliwe niesie moja biblioteka i jak chronię każde z nich”, a nie od listy kontroli przypisanej z góry do aplikacji.
Co zmienia wersja 2.0 z perspektywy dostawcy SDK?
Wersja 2.0 przenosi punkt ciężkości z aplikacji płatniczej na aktywa wrażliwe, przebudowuje strukturę standardu, redukuje nakładanie się z SLC i modernizuje proces zmian delta. Dla dostawcy SDK najważniejsze jest pierwsze – bo determinuje, od czego zaczyna się projekt.
Najważniejsze zmiany według bloga PCI SSC:
- Nacisk na aktywa wrażliwe. Standard nie skupia się już przede wszystkim na aplikacji płatniczej, lecz na identyfikacji i ochronie aktywów wrażliwych – dowolnych elementów produktu, których nieuprawniony dostęp, użycie lub modyfikacja mogą naruszyć bezpieczeństwo. Wspiera to nowy dokument SAID.
- Przebudowana struktura i terminologia. Wymogi zreorganizowano dla łatwiejszej nawigacji; zredukowano też nakładanie się z drugim standardem ramy (SLC).
- Zmodernizowany proces zmian. Nowy szablon Change Impact i wildcardy dla zmian niewpływających na bezpieczeństwo – istotne dla SDK, które wydaje się często i w wielu wersjach.
- Usprawnienia portalu i listingu. Portal do składania rocznych atestacji i zmian administracyjnych przez dostawcę.
Dla SDK ma to konkretne przełożenie. Biblioteka bywa aktualizowana szybko – nowy proces zmian delta i wildcardy pozwalają odróżnić zmiany istotne dla bezpieczeństwa od czysto funkcjonalnych, co upraszcza utrzymanie listingu przy częstych wydaniach. Z kolei podejście oparte na aktywach nagradza zespoły, które i tak myślą o kluczach i danych w kategoriach ochrony, a nie zgodności z listą.
Wersja 2.0 wynagradza dostawcę SDK, który zna każde wrażliwe aktywo w swojej bibliotece – a obnaża tego, który wcześniej „przechodził walidację”, nie mając pełnej mapy tego, co jego kod chroni.
Top 5 rzeczy, które twórca SDK musi zrobić w pierwszej kolejności
Pięć zadań poniżej wyznacza właściwą kolejność projektu walidacji SDK według v2.0. Ich wspólny mianownik: zacznij od zrozumienia, co Twoja biblioteka chroni, zanim zaczniesz dowodzić, jak to chroni.
- Zidentyfikuj aktywa wrażliwe według SAID. To fundament v2.0 i pierwszy krok, nie ostatni. Dla SDK aktywami wrażliwymi są zwykle: klucze i materiał kryptograficzny, dane uwierzytelniające, logika bezpieczeństwa (np. wykrywanie manipulacji), przetwarzane dane płatnicze i sam krytyczny kod. Udokumentuj każde z nich.
- Wyznacz granice tego, co dostarczasz, względem środowiska hosta. SDK działa w cudzej aplikacji. Ustal wprost, za co odpowiada biblioteka, a co jest odpowiedzialnością integratora – to determinuje zakres Twojej walidacji i treść wytycznych dla klientów.
- Zmapuj cele bezpieczeństwa na dowody. Podejście objective-based wymaga wykazania, jak spełniasz cel, a nie odhaczenia kontroli. Dla każdego aktywa wrażliwego przygotuj dowód: projekt, konfigurację, wynik testu, procedurę.
- Uporządkuj proces zmian pod nowy model delta. Dostosuj wersjonowanie i dokumentację wydań do szablonu Change Impact i wildcardów, tak by częste wydania SDK nie generowały pełnej rewalidacji przy zmianach niewpływających na bezpieczeństwo.
- Rozdziel ścieżki, jeśli Twój SDK to 3DS SDK. Bezpieczeństwo 3DS SDK ocenia odrębny standard PCI 3DS SDK Security, a zgodność funkcjonalną z protokołem – aprobata EMVCo. To inne dokumenty i inne laboratoria niż SSF. Zaplanuj je jako osobne strumienie.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że twórcy SDK najczęściej odkładają identyfikację aktywów wrażliwych na koniec, traktując ją jak formalność do uzupełnienia przed audytem. W v2.0 to odwrócenie właściwej kolejności: bez rzetelnej mapy aktywów nie da się ani wyznaczyć zakresu, ani dobrać dowodów, ani oszacować kosztu walidacji. Rekomendujemy poświęcić pierwsze dni projektu wyłącznie na SAID – to inwestycja, która zwraca się w każdej kolejnej fazie.
Top 5 rzeczy, których twórca SDK musi unikać
Poniższe pięć błędów najczęściej wydłuża lub blokuje walidację SDK według v2.0. Wspólny mianownik: myślenie kategoriami starego modelu „aplikacji płatniczej” zamiast nowego, opartego na aktywach.
❌ Traktowanie SAID jako formalności na koniec. Identyfikacja aktywów wrażliwych to punkt wyjścia walidacji, nie dokument do dopięcia przed audytem. Pominięcie któregoś aktywa na tym etapie propaguje się na cały projekt.
❌ Zakładanie, że aprobata EMVCo załatwia bezpieczeństwo. Dla 3DS SDK aprobata EMVCo potwierdza zgodność z protokołem, a nie odporność biblioteki – tę ocenia odrębny standard PCI 3DS SDK Security. Mylenie tych ścieżek to najczęstsza przyczyna poślizgów.
❌ Ignorowanie środowiska wykonania. SDK działa na urządzeniach, których stanu nie kontrolujesz. Projekt zakładający „zaufane środowisko” nie przejdzie – ochrona aktywów musi działać także wtedy, gdy host jest wrogi.
❌ Brak jasnych wytycznych integracyjnych dla klientów. Jeśli bezpieczne użycie SDK zależy od poprawnej integracji, a Ty tego nie udokumentujesz, aktywa wrażliwe realnie chroni ktoś, kto nie wie jak. Wytyczne dla integratora są częścią bezpieczeństwa produktu.
❌ Zwlekanie z decyzją o oknie przejściowym. Zwłoka z wyborem, czy walidować się jeszcze na v1.2.1, czy od razu na v2.0, spycha projekt na koniec 12-miesięcznego okna – gdzie kolejka u asesorów i presja czasu podnoszą ryzyko.
Najczęstszą przyczyną porażki w walidacji SDK nie jest słaba kryptografia, lecz nieuporządkowana mapa tego, co biblioteka chroni i w jakim środowisku – v2.0 nie wybaczy tego braku tak łatwo jak model z wersji 1.x.
Jak zaplanować przejście na v2.0 w oknie przejściowym?
Twórca SDK powinien zdecydować o momencie przejścia na podstawie cyklu wydań biblioteki i terminu następnej walidacji, a nie odkładać decyzji do końca okna. Okno 12-miesięczne startuje po udostępnieniu szkoleń dla asesorów, a materiały wspierające udostępniano etapami w I-II kw. 2026.
Harmonogram według komunikatów PCI SSC:
- 15 sty 2026 – publikacja PCI Secure Software Standard v2.0.
- początek lutego 2026 – oczekiwane szablony v2.x (ROV, AOV, Change Impact).
- I kw. 2026 – oczekiwane szkolenie CBT dla dotychczasowych asesorów; ILT dla nowych w II kw.
- start okna przejściowego – 12 miesięcy na przejście z v1.2.1 na v2.0 po udostępnieniu szkoleń.
Praktyczna decyzja dla twórcy SDK zależy od cyklu wydań. Biblioteka wydawana bardzo często zyskuje na wcześniejszym przejściu na v2.0, bo nowy proces zmian delta lepiej obsługuje jej rytm. Z kolei SDK tuż przed dużą walidacją na v1.2.1 może dokończyć bieżący cykl i przejść na v2.0 przy następnej walidacji. Kluczowe jest zderzenie tego z mapą aktywów – jeśli SAID ujawni braki, przejście trzeba zaplanować z zapasem na remediację.
Patronusec wspiera twórców SDK w tym przejściu w ramach usługi audytu i przygotowania do PCI SSF – od identyfikacji aktywów wrażliwych po plan dopasowany do cyklu wydań biblioteki.
FAQ – PCI SSF v2.0 dla SDK
Czy każdy SDK płatniczy podlega PCI SSF?
Podlega, jeśli jest oprogramowaniem płatniczym dostarczanym innym organizacjom, które przetwarza lub chroni dane płatnicze albo aktywa wrażliwe. Konkretne wymogi walidacji zależą od typu SDK i oczekiwań partnerów oraz sieci płatniczych. SDK tworzone wyłącznie na wewnętrzny użytek nie podlega walidacji SSF, choć środowisko przetwarzania danych kartowych nadal podlega PCI DSS.
Czym różni się walidacja SDK w SSF od aprobaty EMVCo dla 3DS SDK?
To dwie odrębne ścieżki. PCI SSF (Secure Software Standard) waliduje bezpieczeństwo oprogramowania płatniczego. Dla 3DS SDK dodatkowo obowiązuje aprobata EMVCo (zgodność z protokołem) oraz PCI 3DS SDK Security (odporność biblioteki). Twórca 3DS SDK planuje te strumienie osobno, bo mają różne dokumenty, laboratoria i harmonogramy.
Czym jest SAID i dlaczego jest kluczowy dla SDK?
SAID (Sensitive Asset Identification) to nowy dokument towarzyszący v2.0, wspierający identyfikację i dokumentowanie aktywów wrażliwych. Dla SDK jest kluczowy, bo biblioteka niesie skoncentrowane aktywa (klucze, dane, logikę bezpieczeństwa), a walidacja v2.0 zaczyna się właśnie od ich mapy – nie od listy kontroli.
Kiedy muszę przejść z v1.2.1 na v2.0?
W ciągu 12-miesięcznego okna przejściowego, które startuje po udostępnieniu szkoleń dla asesorów v2.0 (CBT oczekiwane w I kw. 2026). Produkt walidowany na v1.2.1 zachowuje ważność zgodnie z zasadami programu przez okno; na v2.0 przechodzisz przy kolejnej walidacji. Moment warto dobrać do cyklu wydań SDK.
Czy podejście oparte na aktywach jest trudniejsze dla małego zespołu SDK?
Niekoniecznie – dla zespołu, który już myśli o kluczach i danych w kategoriach ochrony, jest bardziej naturalne niż odhaczanie listy. Trudność pojawia się przy improwizacji: gdy nikt nie ma pełnej mapy tego, co biblioteka chroni. SAID porządkuje to raz, a mapa aktywów służy potem przy każdej kolejnej walidacji.
Ile trwa przygotowanie SDK do walidacji SSF v2.0 z Patronusec?
Czas zależy od złożoności SDK, liczby aktywów wrażliwych, stanu dokumentacji i tego, czy walidujesz się pierwszy raz, czy przechodzisz z v1.2.1. Po bezpłatnej rozmowie scope-assessment przedstawiamy stałą wycenę obejmującą identyfikację aktywów, analizę luk i przygotowanie do walidacji.
Warto przeczytać
Ścieżka lektury dla tematu bezpieczeństwa oprogramowania płatniczego:
- PCI SSF v2.0 a v1.2.1 – co zmienia się dla dostawcy oprogramowania płatniczego – fundament: pełen zakres zmian wersji 2.0.
- Proces developerski zgodny ze standardem PCI Secure SLC – drugi standard ramy SSF, walidujący proces wytwórczy.
- Czym jest 3DS SDK – wymogi i zastosowania – jeśli Twój SDK realizuje uwierzytelnianie 3DS.
- PCI Secure Software Framework (SSF) – kluczowy standard dla bezpieczeństwa oprogramowania płatniczego – szerszy kontekst ramy.
PCI SSF v2.0 dla twórców SDK – bezpłatna konsultacja
Patronusec jako akredytowany QSA wspiera dostawców oprogramowania płatniczego, w tym twórców SDK, w walidacji PCI SSF. W bezpłatnej 30-minutowej konsultacji pomożemy Ci zidentyfikować aktywa wrażliwe biblioteki i zaplanować przejście na v2.0.
