NIST SSDF (SP 800-218)

Cztery grupy praktyk

SSDF dzieli swoje praktyki na cztery grupy. Każda praktyka określa rezultat, a NIST wyraźnie zaznacza, że nie jest to checklista: to podstawa planowania opartego na ryzyku.

Grupa	Cel	Przykłady
Prepare the Organization (PO)	Ludzie, procesy i narzędzia są gotowe	Określenie wymagań bezpieczeństwa, przypisanie ról, zabezpieczenie środowiska programistycznego
Protect the Software (PS)	Kod i wydania są chronione przed manipulacją	Ochrona wszystkich form kodu, weryfikacja integralności wydań, archiwizacja każdego wydania
Produce Well-Secured Software (PW)	Mało podatności w tym, co Państwo wydają	Projektowanie z myślą o bezpieczeństwie, ponowne użycie dobrze zabezpieczonego oprogramowania, przegląd i testowanie kodu
Respond to Vulnerabilities (RV)	Znajdowanie pozostałych błędów i radzenie sobie z nimi	Ciągła identyfikacja podatności, ich priorytetyzacja i naprawa, analiza przyczyn źródłowych

Praktyki, które dotyczą Państwa łańcucha dostaw

• PO.3, wspierające łańcuchy narzędzi, i PO.5, bezpieczne środowiska. Państwa system CI jest częścią tego, co trzeba chronić. Zob. checklista bezpieczeństwa pipeline'u CI/CD.
• PS.3, archiwizacja i ochrona każdego wydania. Obejmuje to zbieranie danych o pochodzeniu komponentów każdego wydania, a SSDF wskazuje SBOM jako sposób, by to zrobić.
• PW.4, ponowne użycie dobrze zabezpieczonego oprogramowania. Komponenty zewnętrzne powinny być weryfikowane i aktualizowane, i tu właśnie przydaje się analiza składu oprogramowania.
• RV.1, ciągła identyfikacja podatności. To stały obowiązek, a nie bramka przed wydaniem, dlatego wymaga monitorowania tego, co już dostarczono.
• RV.2, ocena, priorytetyzacja i usuwanie. Zob. jak priorytetyzować podatności.

Czy SSDF jest obowiązkowy?

Sam w sobie nie. To publikacja NIST, a nie prawo. Przez kilka lat miał bezpośrednie znaczenie dla dostawców federalnych w USA, ponieważ memoranda OMB M-22-18 i M-23-16 wymagały od nich poświadczania praktyk z niego zaczerpniętych. Zmieniło się to 23 stycznia 2026 r.: memorandum OMB M-26-05 uchyliło oba i wprowadziło podejście oparte na ryzyku. Agencje nadal mogą korzystać ze wspólnego formularza poświadczenia i standardów NIST, ale nie mają już takiego obowiązku, więc dostawcy powinni się liczyć z tym, że wymagania będą się różnić w zależności od agencji.

Poza zamówieniami federalnymi SSDF pozostaje przydatny jako wspólny język. Klienci czerpią z niego w kwestionariuszach bezpieczeństwa, a sam framework daje się odwzorować na inne standardy.

Wersje SSDF

• Wersja 1.1, SP 800-218, opublikowana w lutym 2022 r., to obecna wersja ostateczna.
• Wersja 1.2, SP 800-218 Revision 1, została opublikowana jako projekt w grudniu 2025 r.
• SP 800-218A to profil społecznościowy rozszerzający SSDF na generatywną AI i modele bazowe podwójnego zastosowania.

Jak wdrożyć SSDF

1. Zmapować obecny stan. Przejść przez praktyki i zapisać, gdzie już są spełnione i jakimi dowodami to potwierdzić.
2. Uszeregować luki według ryzyka. SSDF zakłada stosowanie go zgodnie z własnym ryzykiem, więc nie każda praktyka wymaga tej samej głębokości.
3. Zautomatyzować dowody. Dowody pochodzące z pipeline'u pozostają aktualne bez dodatkowej pracy. Dowody pisane ręcznie się dezaktualizują.
4. Przypisać właścicieli. Każda praktyka potrzebuje osoby odpowiedzialnej. Większość będzie należeć do inżynierii, a nie do zespołu bezpieczeństwa.
5. Przeglądać w ustalonych odstępach. Aktualizować mapowanie w miarę zmian narzędzi i postępów prac nad wersją 1.2.

SSDF, SLSA i CRA

SSDF mówi, co powinien osiągnąć program bezpiecznego wytwarzania. SLSA dogłębnie zajmuje się jedną jego częścią, integralnością buildu. Unijny Cyber Resilience Act to prawo z własnymi obowiązkami. Praca wykonana dla jednego z nich przenosi się na pozostałe, ponieważ wszystkie oczekują, że wiedzą Państwo, co jest w Państwa oprogramowaniu, i że obsługują Państwo jego podatności.

Miejsce CRACI

SSDF to szeroki program i żadne narzędzie go nie obejmuje. CRACI dostarcza dowody dla praktyk zależnych od buildu i tego, co dostarczono: SBOM-y z każdego zadania GitHub Actions, izolowane zadania i kontrolę ruchu wychodzącego w środowisku buildu, ciągłe monitorowanie dostarczonego oprogramowania i triage tego, co znajdzie. CRACI nie zapewnia zgodności, a mapowanie i poświadczenie pozostają po Państwa stronie. Zob. bezpieczeństwo łańcucha dostaw oprogramowania z CRACI.

NIST SSDF: najczęściej zadawane pytania

Czym jest NIST SSDF?

To Secure Software Development Framework, opublikowany jako NIST SP 800-218. To zestaw praktyk budowania bezpiecznego oprogramowania, podzielony na cztery grupy: przygotowanie organizacji, ochrona oprogramowania, wytwarzanie dobrze zabezpieczonego oprogramowania i reagowanie na podatności.

Co oznacza skrót SSDF?

Secure Software Development Framework.

Czy SSDF jest obowiązkowy?

Nie. To wytyczne, a nie prawo. Dostawcy federalni w USA musieli kiedyś poświadczać stosowanie jego praktyk, ale memorandum OMB M-26-05 uchyliło ten wymóg w styczniu 2026 r. Agencje nadal mogą prosić o poświadczenia.

Jaka jest najnowsza wersja SSDF?

Wersja 1.1 (SP 800-218, luty 2022 r.) to obecna wersja ostateczna. Wersja 1.2 została opublikowana jako projekt w grudniu 2025 r., więc jej status warto sprawdzić na stronie NIST.

Jaka jest różnica między SSDF a SLSA?

SSDF obejmuje bezpieczne wytwarzanie jako całość: ludzi, procesy i technologię. SLSA dogłębnie zajmuje się integralnością buildu i danymi o pochodzeniu. Dobrze się uzupełniają.

Czy SSDF wymaga SBOM?

Wymaga zbierania i udostępniania danych o pochodzeniu komponentów każdego wydania, a SBOM wskazuje jako jeden ze sposobów. Opisuje rezultaty, a nie nakazuje konkretnego narzędzia.