Tag: NIST

Wprowadzenie do problemu / definicja „luki” w polityce

Zmiana ogłoszona przez Office of Management and Budget (OMB) dotyczy nie klasycznej podatności technicznej, lecz „luki” na poziomie governance: sposobu, w jaki administracja federalna narzuca (lub nie narzuca) minimalne wymagania bezpieczeństwa dostawcom oprogramowania.

W styczniu 2026 r. OMB opublikowało memorandum M-26-05, które formalnie unieważnia wcześniejsze wytyczne z czasów administracji Joe Biden: M-22-18 oraz jego aktualizację M-23-16. Uzasadnienie: poprzednie wymagania miały być „nieudowodnione i uciążliwe” oraz skupione na biurokratycznej zgodności zamiast realnych inwestycji w bezpieczeństwo.

---

W skrócie

• Co wycofano? Dwa kluczowe dokumenty polityki: M-22-18 i M-23-16 zostały „rescinded” (uchylone).
• Co wchodzi w zamian? Podejście risk-based: większa odpowiedzialność po stronie kierownictwa każdej agencji za dobór metod weryfikacji bezpieczeństwa software i hardware w zależności od misji i profilu ryzyka.
• Czy SBOM i atestacje znikają całkowicie? Nie. OMB wskazuje, że agencje mogą nadal korzystać z zasobów wypracowanych wcześniej (np. formularza atestacji praktyk wytwarzania) oraz mogą wpisywać do umów obowiązek dostarczenia SBOM „na żądanie”.
• Nowy akcent: silniejsze uwzględnienie ryzyk sprzętowych (hardware supply chain) i odniesienia do HBOM.

---

Kontekst / historia / powiązania

M-23-16 (2023) było aktualizacją M-22-18 i wynikało z kierunku wyznaczonego przez Executive Order 14028 (poprawa cyberbezpieczeństwa państwa i bezpieczeństwa łańcucha dostaw). W praktyce te dokumenty miały doprowadzić do tego, aby agencje federalne używały wyłącznie takiego oprogramowania, którego producenci są w stanie poświadczyć spełnianie minimalnych praktyk bezpiecznego wytwarzania.

Mechanika wdrożenia była mocno „procesowa”: terminy, zakres oprogramowania, a także wspólny formularz (common form) przygotowywany z udziałem Cybersecurity and Infrastructure Security Agency (CISA). M-23-16 precyzowało m.in. harmonogram zbierania atestacji w zależności od zatwierdzenia formularza w reżimie Paperwork Reduction Act (PRA).

W 2026 r. OMB przechodzi na narrację: „mniej uniwersalnej checklisty, więcej dopasowania do ryzyka”, podkreślając, że nie ma jednego, „one-size-fits-all” modelu zapewnienia bezpieczeństwa dla wszystkich agencji.

---

Analiza techniczna / szczegóły zmiany

1. Co wymuszały M-22-18 / M-23-16 (w praktyce)

Z punktu widzenia inżynierii bezpieczeństwa i zakupów IT, sednem była atestacja praktyk SDLC przez producenta oprogramowania. M-23-16 opisywało, że agencje mają zbierać atestacje od producentów (w tym dla „critical software”) w określonych terminach po zatwierdzeniu wspólnego formularza.

Istotne było też doprecyzowanie, że odpowiedzialność za zgodność praktyk rozciąga się na sposób zarządzania komponentami third-party (w tym open source) na poziomie producenta produktu końcowego – a nie na poziomie każdej agencji.

2. Co mówi M-26-05: „risk-based” zamiast „universal compliance”

Nowe memorandum M-26-05:

• stwierdza, że wcześniejsze wymagania narzucały „burdensome software accounting processes” i odciągały agencje od tworzenia dopasowanych wymagań assurance,
• unieważnia M-22-18 i M-23-16,
• utrzymuje oczekiwanie posiadania kompletnego inwentarza software i hardware, ale przenosi ciężar doboru mechanizmów weryfikacji na agencje.

3. Co zostaje jako narzędzia opcjonalne: atestacja, SBOM, HBOM

M-26-05 wprost wskazuje, że agencje:

• mogą nadal używać zasobów „government-wide secure software development resources” (w tym formularza atestacji praktyk bezpiecznego wytwarzania),
• mogą wprowadzać do kontraktów zapis o dostarczeniu SBOM na żądanie (w tym szczególna uwaga dla środowisk chmurowych – SBOM środowiska runtime/production),
• mają też brać pod uwagę ryzyka sprzętowe oraz odwołania do HBOM.

4. Gdzie w tym wszystkim jest SSDF (NIST SP 800-218)

Nawet jeśli obowiązek „federalnej checklisty” zostaje cofnięty, sam rdzeń dobrych praktyk bezpiecznego wytwarzania nie znika. National Institute of Standards and Technology (NIST) opisuje SSDF jako zestaw fundamentalnych praktyk bezpiecznego wytwarzania, zorganizowany w cztery grupy (przygotowanie organizacji, ochrona software, wytwarzanie bezpiecznego software, reakcja na podatności). SSDF ma być „wspólnym językiem” dla producentów i nabywców, a nie wyłącznie checklistą do odhaczania.

W praktyce oznacza to, że SSDF nadal jest sensowną bazą do programów assurance — tylko presja regulacyjna może się przenieść z „musisz użyć dokładnie tego formularza” na „udowodnij adekwatność kontroli do ryzyka”.

---

Praktyczne konsekwencje / ryzyko

Dla agencji federalnych

• Większa swoboda, ale i większa odpowiedzialność: skoro nie ma jednego schematu, rośnie ryzyko nierównego poziomu wymagań między agencjami (fragmentacja) i trudniejszego porównywania dostawców.
• Ryzyko „wyścigu do dna” w zakupach: jeśli część jednostek potraktuje zmianę jako okazję do obniżenia wymagań, ucierpieć może spójność ochrony łańcucha dostaw. (To wniosek analityczny na podstawie kierunku polityki „opcjonalności” narzędzi).

Dla dostawców oprogramowania (software producers)

• Mniej jednolitego compliance, więcej odpowiedzi na RFP-y „szyte na miarę”: zamiast jednego pakietu atestacji dla całego rządu, mogą pojawić się różne zestawy wymagań assurance zależnie od agencji.
• SBOM „na żądanie” dalej ma znaczenie: to nie jest sygnał „SBOM niepotrzebny”, tylko „SBOM jako narzędzie kontraktowe i operacyjne, niekoniecznie jako twardy wymóg wszędzie”.

Dla bezpieczeństwa ekosystemu (systemowo)

• Plus: lepsze dopasowanie kontroli do realnego ryzyka (szczególnie dla systemów o specyficznej misji i ograniczeniach).
• Minus: utrata efektu skali i standaryzacji, który bywa kluczowy w łańcuchu dostaw (wspólny język wymagań, wspólny formularz, łatwiejszy due diligence).

---

Rekomendacje operacyjne / co zrobić teraz

Jeśli jesteś dostawcą (vendor / producent oprogramowania)

1. Utrzymaj SSDF jako kręgosłup programu secure SDLC – nawet jeśli formularz atestacji nie jest już „must-have” wszędzie, SSDF pozostaje najlepszą bazą do rozmowy z nabywcą o kontrolach i dojrzałości.
2. Przygotuj „pakiet dowodowy” (assurance evidence pack):
   • mapowanie praktyk SDLC do SSDF,
   • opis środowiska build i mechanizmów integralności,
   • procesy VDP/PSIRT, SLA na poprawki, polityka podpisywania artefaktów.
3. SBOM/HBOM jako produkt uboczny procesu, nie „excel na koniec”: skoro SBOM może być wymagany „upon request”, warto mieć pipeline do generowania i aktualizacji (dla chmury także dla runtime).

Jeśli jesteś po stronie kupującego / security w organizacji publicznej

1. Zdefiniuj minimalny baseline (nawet jeśli prawo nie narzuca jednego): bez niego risk-based łatwo przeradza się w ad-hoc. OMB podkreśla potrzebę inwentarza i dopasowania assurance do ryzyka – zacznij od klasyfikacji systemów i danych.
2. Zbuduj wymagania kontraktowe warstwowo:
   • baseline (SSDF-ish),
   • rozszerzenia dla systemów krytycznych,
   • wymagania SBOM na żądanie + format + częstotliwość aktualizacji.
3. Nie pomijaj hardware: M-26-05 wyraźnie rozszerza akcent na ryzyka sprzętowe – uwzględnij je w ocenie dostawców, logistyce, cyklu życia urządzeń i w monitoringu.

---

Różnice / porównania z innymi przypadkami

„Compliance-first” (M-22-18/M-23-16) vs „Risk-based” (M-26-05)

• Compliance-first: jednolita forma atestacji i harmonogramy → łatwiejsza standaryzacja i porównywanie dostawców, ale ryzyko przerostu papierologii.
• Risk-based: większa elastyczność i dopasowanie do misji → potencjalnie bardziej „inżynierskie” security, ale wyższe ryzyko niespójności wymagań i różnego poziomu dojrzałości w agencjach.

W praktyce dojrzałe organizacje kończą zwykle na modelu hybrydowym: baseline (SSDF) + risk-based rozszerzenia.

---

Podsumowanie / kluczowe wnioski

Memorandum M-26-05 to istotny zwrot w federalnym podejściu do bezpieczeństwa łańcucha dostaw: od centralnie standaryzowanych atestacji i terminów ku modelowi, w którym każda agencja ma sama dobrać mechanizmy assurance dla oprogramowania i sprzętu.

Najważniejsze: wycofanie wymogów nie oznacza, że SSDF, SBOM czy atestacje „przestają istnieć” — stają się narzędziami opcjonalnymi i kontraktowymi. Dla dostawców to sygnał, by budować dowody dojrzałości secure SDLC (SSDF), a dla kupujących — by nie gubić standaryzacji i utrzymać minimalny baseline w modelu risk-based.

---

Źródła / bibliografia

1. SecurityWeek — artykuł: „White House Scraps ‘Burdensome’ Software Security Rules” (30 stycznia 2026). (SecurityWeek)
2. Office of Management and Budget (OMB) — Memorandum M-26-05 „Adopting a Risk-based Approach to Software and Hardware Security” (23 stycznia 2026).
3. OMB — Memorandum M-23-16 „Update to Memorandum M-22-18…” (9 czerwca 2023).
4. National Institute of Standards and Technology (NIST) — strona projektu SSDF (SP 800-218) i opis struktury praktyk. (csrc.nist.gov)
5. Federal Register — ogłoszenie dot. konsultacji publicznych nt. „2025 Minimum Elements for a Software Bill of Materials (SBOM)” (kontekst SBOM). (Federal Register)