# Czy da się wyjść z wiecznego łatania? Secure by design i pytania, które warto zadać dostawcy oprogramowania Od pół wieku wiemy, jak projektować bezpieczne systemy, a wciąż kupujemy produkty, które sami łatamy. Co daje secure by design i jak wymagać go przy zakupie? - Adres: - Autor: [Paweł Rosół](https://pelnomocnikcyber.pl/autor/pawel-rosol/) - Data publikacji: 26.10.2026 - Kategoria: [Zarządzanie ryzykiem](https://pelnomocnikcyber.pl/kategorie/zarzadzanie-ryzykiem/) - Stan prawny sprawdzony: 26.10.2026 - Licencja: [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/deed.pl) Do końca nie. Żaden system nie jest wolny od błędów, więc poprawki będą potrzebne zawsze. Da się za to przestać dokładać do kołowrotu, w którym producent sprzedaje podatny produkt, a klient płaci za jego łatanie, monitorowanie i sprzątanie po incydentach. Agencje cyberbezpieczeństwa kilkunastu państw, w tym USA, Wielkiej Brytanii i Niemiec, opisują to podejście jako secure by design i wskazują trzy poziomy zmiany: ciężar bezpieczeństwa przechodzi na producenta, całe klasy błędów znikają u źródła, a architektura ogranicza skutki tego, co i tak pęknie. Organizacja, która oprogramowania nie pisze, tylko je kupuje, ma realny wpływ przede wszystkim na pierwszy z nich, i to przez zakupy. Ten tekst jest mniej o prawie, a bardziej o tym, dlaczego bezpieczeństwo wygląda dziś tak, jak wygląda, i co z tego wynika dla zarządu, który podpisuje umowy z dostawcami. Ustawa o krajowym systemie cyberbezpieczeństwa pojawia się w nim pod koniec, bo w tej sprawie akurat ma coś do powiedzenia. ## Skąd się wziął kołowrót łatania? Najprostsze wyjaśnienie, jakie znam, pochodzi z 2001 r. Ross Anderson z Uniwersytetu w Cambridge napisał wtedy esej „Why Information Security is Hard”, w którym postawił tezę, że brak bezpieczeństwa wynika co najmniej w tym samym stopniu ze złych bodźców ekonomicznych, co z braków technicznych. Jego przykład pochodził z bankomatów. W USA, gdy klient kwestionował transakcję, to bank musiał udowodnić, że klient się myli, więc banki dbały o swoje systemy. W Wielkiej Brytanii, Norwegii i Holandii ciężar dowodu spoczywał na kliencie i tamtejsze banki zaniedbały zabezpieczenia, aż przyszła fala oszustw. Amerykańskie wydawały na bezpieczeństwo mniej, ale skuteczniej. Anderson streścił to w zdaniu, które warto zapamiętać: tam, gdzie strona zdolna chronić system nie jest stroną, która poniesie skutki jego awarii, należy spodziewać się problemów. Wyjaśniał też, skąd pośpiech: na rynkach, na których zwycięzca bierze prawie wszystko, opłaca się wypuścić produkt szybko i poprawiać go później. Przywołał powiedzenie „wypuścimy we wtorek, a dopracujemy w wersji trzeciej” i podkreślał, że to zachowanie racjonalne, a nie wada charakteru. **Dopóki producent decyduje o jakości produktu, a koszt jego podatności ponosi klient, łatanie się nie skończy.** Ponad dwadzieścia lat później to samo napisały wprost agencje rządowe. W dokumencie „Shifting the Balance of Cybersecurity Risk” z października 2023 r. amerykańskie CISA, NSA i FBI oraz kilkanaście instytucji partnerskich, w tym niemiecki BSI, holenderskie NCSC i czeski NÚKIB, piszą (tłum. własne): „Historycznie producenci oprogramowania polegali na naprawianiu podatności znalezionych już po wdrożeniu produktów przez klientów, którzy musieli instalować te poprawki na własny koszt. Tylko wprowadzając praktyki secure by design przerwiemy błędne koło ciągłego tworzenia i instalowania poprawek”. Polskiej instytucji wśród sygnatariuszy tej wersji nie ma. Dokument przywołuje za to unijny Cyber Resilience Act jako europejski głos w tym samym kierunku: bezpieczeństwo produktu przez cały cykl jego życia. ## Co znaczy secure by design, a co secure by default? Według tego dokumentu produkt secure by design jest zbudowany tak, żeby w rozsądnym stopniu chronił przed uzyskaniem przez atakującego dostępu do urządzeń, danych i połączonej infrastruktury. Producent szacuje ryzyko i buduje model zagrożeń, zanim zacznie pisać kod, a bezpieczeństwo klienta traktuje jako cel biznesowy, nie jako jedną z funkcji. Secure by default to jego część: produkt jest bezpieczny „po wyjęciu z pudełka”, bez dodatkowej konfiguracji i bez dopłaty. Autorzy porównują to do pasów bezpieczeństwa, które są w każdym nowym samochodzie, a nie w pakiecie premium. Producentom stawiają trzy zasady. Pierwsza: przejąć odpowiedzialność za to, jak bezpieczni są ich klienci, zamiast przerzucać na nich cały ciężar. Druga: radykalna przejrzystość, czyli kompletne komunikaty o podatnościach i rzetelne rekordy CVE. Trzecia: o bezpieczeństwie produktu decyduje kierownictwo producenta, bo wiedza techniczna jest niezbędna, ale zmiany w organizacji wprowadzają ci, którzy nią kierują. Z całego dokumentu najbardziej przydają mi się dwa konkretne pomysły. Pierwszy to tak zwany podatek od SSO: dopłata za podpięcie produktu do firmowego logowania jednokrotnego albo za włączenie uwierzytelniania wieloskładnikowego. Autorzy piszą, że bezpieczeństwo nie powinno być wyceniane jak towar luksusowy, i to samo odnoszą do logów bezpieczeństwa, które mają być dostępne bez dodatkowej opłaty. Drugi to odwrócenie instrukcji utwardzania (hardening guide). Dziś producent dostarcza produkt w wygodnej, luźnej konfiguracji i długą instrukcję, którą każdy klient wdraża sam, na własny koszt i często wcale, bo o niej nie wie. Dokument proponuje odwrotnie: produkt jest domyślnie bezpieczny, a producent dostarcza „instrukcję luzowania” (loosening guide), która prostym językiem mówi, co zmienić, jeśli biznes tego wymaga, i jakie ryzyko się wtedy przyjmuje. Decyzję o takim kompromisie ma podejmować kierownictwo klienta. **Długa instrukcja utwardzania to często znak, że bezpieczną konfigurację producent zostawił klientowi.** CISA prowadzi też dobrowolne, prawnie niewiążące zobowiązanie dla producentów oprogramowania dla firm (Secure by Design Pledge). Ma siedem celów, z których postęp producent pokazuje w ciągu roku od podpisania: więcej MFA, mniej haseł domyślnych, ograniczenie co najmniej jednej klasy podatności, łatwiejsze instalowanie poprawek, opublikowana polityka ujawniania podatności, przejrzystość przy zgłaszaniu CVE i lepszy dostęp klienta do dowodów włamania. Lista sygnatariuszy jest publiczna, więc można sprawdzić, czy jest na niej twój dostawca, i poprosić o jego raport z postępów. ## Czy całe klasy podatności da się wyeliminować? Da się, i najlepiej to widać na błędach bezpieczeństwa pamięci. W dokumencie „The Case for Memory Safe Roadmaps” z grudnia 2023 r. agencje z USA, Australii, Kanady, Wielkiej Brytanii i Nowej Zelandii tłumaczą je metaforą listy z dziesięcioma pozycjami, od której program może zażądać pozycji jedenastej albo minus pierwszej. Jeśli język albo programista tego nie zablokuje, system odda dane z zupełnie innego miejsca w pamięci, a atakujący może w ten sposób czytać cudze dane, uszkadzać je albo wykonać własny kod. Dokument przytacza dane z branży: około 70 % podatności z numerami CVE w produktach Microsoftu (lata 2006 do 2018) i około 70 % podatności w projekcie Chromium to błędy pamięci, a według zespołu Google Project Zero były nimi 67 % podatności zero-day z 2021 r. Branża walczy z tym od dekad szkoleniami, testami, fuzzingiem i zabezpieczeniami w rodzaju ASLR. Dokument opisuje te narzędzia i ich granice: szkolenie nie zatrzyma błędów, które popełniają też najbardziej doświadczeni programiści, a obejścia ASLR są powszechne. Rozwiązaniem u źródła są języki programowania, które takich błędów nie dopuszczają. Dokument z 2023 r. o secure by design wymienia jako przykłady C#, Rust, Ruby, Java, Go i Swift. Najmocniejszy dowód, że to działa, opublikował Google we wrześniu 2024 r. Zespół Androida od około 2019 r. pisze nowy kod przede wszystkim w językach bezpiecznych pod względem pamięci, a starego kodu w C i C++ w większości nie przepisywał. Udział błędów pamięci wśród podatności Androida spadł z 76 % w 2019 r. do 24 % w 2024 r., choć większość kodu nadal jest w językach podatnych na te błędy. Google tłumaczy to tym, że podatności siedzą głównie w kodzie nowym i niedawno zmienianym, a stary kod z czasem dojrzewa. Według wyliczeń Google kod sprzed pięciu lat ma od 3,4 do 7,4 raza mniejszą gęstość podatności niż nowy. **Żeby było bezpieczniej, nie trzeba przepisywać starego kodu, wystarczy przestać dopisywać nowy z tymi samymi błędami.** Ta sama logika działa przy innych klasach. CISA podaje jako przykłady zapytania parametryzowane, które usuwają SQL injection, i szablony stron, które automatycznie zabezpieczają dane od użytkownika przed XSS. Dla kupującego wynika z tego jedno pytanie do producenta: które klasy podatności wyeliminował systemowo, a dla których ma plan. Wynika też ostrzeżenie dla zarządu: sama liczba CVE nie jest miarą jakości produktu. Autorzy dokumentu z 2023 r. przestrzegają przed liczeniem CVE jako wskaźnika negatywnego, bo duża liczba zgłoszeń bywa też znakiem, że ktoś produkt rzetelnie testuje. CISA dodaje, że producent, który poważnie zabiera się za klasę podatności, może przez pewien czas publikować ich więcej. ## Co z tym, co i tak pęknie? Pół wieku temu, w 1975 r., Jerome Saltzer i Michael Schroeder opublikowali „The Protection of Information in Computer Systems”, a w podsumowaniu pierwszej części napisali (tłum. własne): „Ponieważ nikt nie wie, jak zbudować system bez wad, alternatywą jest oparcie się na ośmiu zasadach projektowych, które zmniejszają zarówno liczbę, jak i powagę wad”. Te zasady to: - oszczędność mechanizmu: zabezpieczenie ma być tak proste i małe, jak się da, bo tylko takie można dokładnie sprawdzić; - bezpieczne ustawienia domyślne: domyślnie dostępu nie ma, a system określa warunki, pod którymi go przyznaje; - pełne pośrednictwo: każdy dostęp do każdego zasobu jest sprawdzany, a nie zapamiętywany na zawsze; - jawny projekt: bezpieczeństwo nie zależy od tego, że atakujący nie zna konstrukcji, tylko od kluczy i haseł; - rozdzielenie uprawnień: tam, gdzie się da, do otwarcia potrzebne są dwa klucze w rękach dwóch osób; - najmniejsze uprawnienia: każdy program i każdy użytkownik ma tylko te uprawnienia, których potrzebuje do pracy; - najmniej wspólnych mechanizmów: każdy mechanizm współdzielony przez wielu użytkowników jest potencjalną drogą przecieku między nimi; - akceptowalność psychologiczna: zabezpieczenie ma być tak wygodne, żeby ludzie używali go odruchowo i poprawnie. Autorzy sami zastrzegli, że to nie są reguły absolutne, tylko ostrzeżenia: jeśli projekt łamie którąś zasadę, trzeba sprawdzić, czy ktoś świadomie przyjął wynikający z tego problem. Zero trust to te same zasady przyłożone do całej sieci firmowej. NIST w publikacji SP 800-207 z sierpnia 2020 r. opisuje architekturę, w której nikt nie dostaje zaufania tylko dlatego, że jest w sieci lokalnej albo korzysta z firmowego komputera. Uwierzytelnienie i autoryzacja (użytkownika i urządzenia) następują przed każdą sesją z zasobem. Zero trust nie usuwa podatności, ale sprawia, że przejęcie jednego komputera nie daje atakującemu reszty firmy. Google przechodził na taki model (BeyondCorp) latami i w 2023 r. opisał w magazynie USENIX ;login: najtrudniejszą część, czyli „długi ogon”. Wyjątki przyznane na czas migracji trwały znacznie dłużej, niż zakładano, i trudno było przypisać je do jednego właściciela na poziomie kierownictwa. Po pierwszym sukcesie wsparcie kierownictwa osłabło, a dokończenie migracji zostało bez finansowania. Wnioski autorów przydadzą się każdemu zarządowi: wyjątek wygasa i wymaga odnowienia, ma zespół, który za niego odpowiada, a strategia „przeczekamy, aż zespoły same się dostosują” nie działa. ## Co może zrobić organizacja, która oprogramowanie tylko kupuje? Agencje piszą wprost, że oprócz producentów, którzy mają projektować bezpiecznie, potrzebni są klienci, którzy będą tego wymagać („secure by demand”). W dokumencie z 2023 r. zalecają, żeby kierownictwo uczyniło zakup produktów secure by design priorytetem, dało działowi IT prawo do ustalania kryteriów zakupu i do sprzeciwu, a decyzje o akceptacji ryzyka związanego z konkretnym produktem dokumentowało, zatwierdzało na poziomie członka kierownictwa i regularnie przedstawiało radzie nadzorczej albo zarządowi. W sierpniu 2024 r. CISA i FBI wydały do tego przewodnik dla kupujących, „Secure by Demand Guide”, z pytaniami do producenta. Wybrałbym z niego te, które przy zakupie albo odnowieniu umowy da się zadać każdemu dostawcy: 1. Czy uwierzytelnianie wieloskładnikowe, najlepiej odporne na phishing (np. klucze dostępu), jest włączone domyślnie i bez dopłaty? 2. Czy produkt ma hasła domyślne wspólne dla wszystkich egzemplarzy, a jeśli tak, to jak producent je wycofuje? 3. Czy logowanie jednokrotne w otwartym standardzie (SAML, OpenID Connect) jest w wersji podstawowej, a nie w droższym pakiecie? 4. Czy logi bezpieczeństwa są w wersji podstawowej i co obejmują: zmiany konfiguracji, logowania i tworzenie tokenów, dostęp do danych? W usłudze chmurowej przewodnik oczekuje co najmniej sześciu miesięcy przechowywania bez dodatkowej opłaty. 5. Czy producent ma publiczną politykę ujawniania podatności i czy jego rekordy CVE podają przyczynę błędu (pole CWE)? 6. Czy dostarcza SBOM, czyli wykaz komponentów oprogramowania, w formacie do odczytu maszynowego, z bibliotekami open source włącznie? 7. Które klasy podatności wyeliminował systemowo i czy ma plan dla pozostałych, na przykład plan przejścia na języki bezpieczne pod względem pamięci? 8. Jak ułatwia instalowanie poprawek, czy oferuje aktualizacje automatyczne i kiedy oraz jak informuje o końcu wsparcia produktu? Odpowiedzi nie trzeba od razu wpisywać do umowy. Już same pokażą, czy dostawca o tych sprawach myśli, czy pierwszy raz o nich słyszy. Od strony prawa umów i zamówień publicznych pisałem o tym przy [łańcuchu dostaw w ustawie o KSC](https://pelnomocnikcyber.pl/artykuly/lancuch-dostaw-w-ustawie-o-ksc-czego-wymagac-od-dostawcow-i-co-wpisac-do-umowy/) i przy [dostawcach spółek wod-kan](https://pelnomocnikcyber.pl/artykuly/dostawcy-spolki-wod-kan-jak-sprawdzac-co-wpisac-do-aneksu-i-jak-pogodzic-z-pzp/). **Odpowiedzi dostawcy na kilka pytań przed podpisaniem umowy mówią o jego produkcie więcej niż liczba opublikowanych CVE.** ## Co na to ustawa o KSC? Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa nie używa pojęcia secure by design, ale wymaga od podmiotu kluczowego i ważnego obu stron tej sprawy. Z jednej strony art. 8 ust. 1 pkt 5 lit. b nakazuje „regularne przeprowadzanie aktualizacji oprogramowania, stosownie do zaleceń producenta”, więc łatania nikt nie znosi. Z drugiej strony art. 8 ust. 1 pkt 2 lit. b wymaga, żeby system zarządzania bezpieczeństwem informacji obejmował „bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego”, a art. 8 ust. 2 pkt 2 nakazuje przy środkach dotyczących łańcucha dostaw uwzględniać „ogólną jakość produktów ICT, usług ICT i procesów ICT pochodzących od dostawcy sprzętu lub oprogramowania”. Ustawa nie mówi, jak tę jakość oceniać. Osiem pytań z poprzedniej sekcji jest jednym ze sposobów, i to takim, po którym zostaje ślad do pokazania audytorowi. Na początek zrobiłbym jedno: przy najbliższym zakupie albo odnowieniu licencji systemu, od którego zależy świadczenie usługi, wysłałbym dostawcy te pytania przed negocjacją ceny, a odpowiedzi dołączył do szacowania ryzyka. Odpowiedź „MFA jest w pakiecie Enterprise” też coś mówi: ile kosztuje u tego dostawcy bezpieczeństwo, które i tak trzeba będzie kupić. ## Pojęcia w tym tekście - [Incydent](https://pelnomocnikcyber.pl/slownik/incydent/): Zdarzenie, które szkodzi albo może zaszkodzić bezpieczeństwu systemów informacyjnych. Zgłaszać trzeba nie każdy incydent, tylko incydent poważny. - [Secure by design](https://pelnomocnikcyber.pl/slownik/secure-by-design/): Podejście, w którym producent projektuje produkt tak, by był bezpieczny od początku i domyślnie, zamiast zostawiać klientowi łatanie i utwardzanie konfiguracji. - [Ustawa o KSC](https://pelnomocnikcyber.pl/slownik/ustawa-o-ksc/): Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych. - [Podatność](https://pelnomocnikcyber.pl/slownik/podatnosc/): Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV. - [CISA](https://pelnomocnikcyber.pl/slownik/cisa/): Cybersecurity and Infrastructure Security Agency, amerykańska agencja ds. cyberbezpieczeństwa i infrastruktury. Prowadzi katalog KEV; nie jest organem w rozumieniu ustawy o KSC. - [CVE](https://pelnomocnikcyber.pl/slownik/cve/): Common Vulnerabilities and Exposures: publiczny katalog znanych podatności. Każda dostaje identyfikator w postaci CVE-rok-numer, po którym szuka się poprawek i ostrzeżeń. - [Logowanie jednokrotne](https://pelnomocnikcyber.pl/slownik/logowanie-jednokrotne/): Single sign-on: jedno konto i jedno uwierzytelnienie, zwykle u firmowego dostawcy tożsamości, dają dostęp do wielu aplikacji bez osobnych haseł do każdej z nich. - [Uwierzytelnianie wieloskładnikowe](https://pelnomocnikcyber.pl/slownik/uwierzytelnianie-wieloskladnikowe/): Logowanie, które wymaga więcej niż jednego składnika, na przykład hasła i kodu z aplikacji. Ustawa o KSC wymienia je wśród środków bezpieczeństwa. - [Bezpieczeństwo pamięci](https://pelnomocnikcyber.pl/slownik/bezpieczenstwo-pamieci/): Ochrona programu przed odczytem, zapisem albo zwalnianiem pamięci w niezamierzony sposób. Według CISA i NSA błędy pamięci to najczęstszy typ ujawnianych podatności. - [Zero-day](https://pelnomocnikcyber.pl/slownik/zero-day/): Podatność wykorzystywana przez napastników, zanim producent ją ujawnił i udostępnił poprawkę. - [Losowe rozmieszczenie przestrzeni adresowej](https://pelnomocnikcyber.pl/slownik/aslr/): Address space layout randomization: zabezpieczenie systemu operacyjnego, które losowo rozmieszcza w pamięci kluczowe obszary procesu, przez co błąd pamięci trudniej zamienić w działający exploit. - [SQL injection](https://pelnomocnikcyber.pl/slownik/sql-injection/): Podatność, która pozwala wstrzyknąć do bazy danych własne zapytania, w opisanym przypadku bez uwierzytelnienia. - [XSS](https://pelnomocnikcyber.pl/slownik/xss/): Atak, w którym aplikacja internetowa odsyła przeglądarce użytkownika skrypt wstawiony przez atakującego. Skrypt działa jak część zaufanej strony i może odczytać na przykład pliki cookie sesji. - [Zero trust](https://pelnomocnikcyber.pl/slownik/zero-trust/): Model bezpieczeństwa, w którym nikt nie dostaje zaufania z samego faktu bycia w sieci firmowej: każdy dostęp do zasobu wymaga uwierzytelnienia i autoryzacji użytkownika i urządzenia. - [CWE](https://pelnomocnikcyber.pl/slownik/cwe/): Common Weakness Enumeration: katalog typów słabości w oprogramowaniu i sprzęcie, z których biorą się podatności. CVE mówi, która podatność, CWE mówi, jaki rodzaj błędu ją spowodował. - [Wykaz komponentów oprogramowania](https://pelnomocnikcyber.pl/slownik/sbom/): Software bill of materials: formalny spis bibliotek i komponentów, z których zbudowano program, razem z ich pochodzeniem. Pozwala szybko sprawdzić, czy produkt zawiera podatny komponent. - [Podmiot kluczowy](https://pelnomocnikcyber.pl/slownik/podmiot-kluczowy/): Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata. - [System zarządzania bezpieczeństwem informacji](https://pelnomocnikcyber.pl/slownik/szbi/): Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów. - [Łańcuch dostaw](https://pelnomocnikcyber.pl/slownik/lancuch-dostaw/): Dostawcy sprzętu, oprogramowania i usług ICT, od których zależy świadczenie usługi. Ich bezpieczeństwo podmiot uwzględnia w swoim zarządzaniu ryzykiem. - [Szacowanie ryzyka](https://pelnomocnikcyber.pl/slownik/szacowanie-ryzyka/): Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”. ## Najczęściej zadawane pytania ### Czy ustawa o KSC wymaga kupowania oprogramowania „secure by design”? Ustawa nie używa tego pojęcia. Art. 8 ust. 1 pkt 2 lit. b ustawy o KSC wymaga jednak, żeby system zarządzania bezpieczeństwem informacji obejmował bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, a art. 8 ust. 2 pkt 2 nakazuje przy środkach dotyczących łańcucha dostaw uwzględniać ogólną jakość produktów ICT pochodzących od dostawcy. Pytania o domyślne MFA, logi czy politykę ujawniania podatności są jednym ze sposobów, żeby tę ocenę przeprowadzić i udokumentować. ### Czy to znaczy, że mogę przestać instalować poprawki? Nie. Art. 8 ust. 1 pkt 5 lit. b ustawy o KSC nadal wymaga regularnych aktualizacji oprogramowania, stosownie do zaleceń producenta. Secure by design zmniejsza liczbę poprawek, które trzeba będzie instalować w przyszłości, i ułatwia ich instalowanie, ale nie usuwa podatności już obecnych w używanych dziś systemach. ## Źródła 1. [Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, tekst jednolity Dz.U. 2026 poz. 20, ze zmianami](https://eli.gov.pl/eli/DU/2026/20/ogl) 2. [CISA i in., Shifting the Balance of Cybersecurity Risk. Principles and Approaches for Secure by Design Software (październik 2023 r.)](https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf) 3. [CISA i FBI, Secure by Demand Guide. How Software Customers Can Drive a Secure Technology Ecosystem (sierpień 2024 r.)](https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf) 4. [CISA, Secure by Design Pledge](https://www.cisa.gov/securebydesign/pledge) 5. [CISA, NSA, FBI i in., The Case for Memory Safe Roadmaps (grudzień 2023 r.)](https://www.cisa.gov/resources-tools/resources/case-memory-safe-roadmaps) 6. [Google Security Blog, Eliminating Memory Safety Vulnerabilities at the Source (25 września 2024 r.)](https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html) 7. [J. H. Saltzer, M. D. Schroeder, The Protection of Information in Computer Systems (1975)](https://www.cs.virginia.edu/~evans/cs551/saltzer/) 8. [R. Anderson, Why Information Security is Hard. An Economic Perspective (2001)](https://www.cl.cam.ac.uk/~rja14/Papers/econ.pdf) 9. [NIST SP 800-207, Zero Trust Architecture (sierpień 2020 r.)](https://csrc.nist.gov/pubs/sp/800/207/final) 10. [USENIX ;login:, BeyondCorp and the Long Tail of Zero Trust (czerwiec 2023 r.)](https://www.usenix.org/publications/loginonline/beyondcorp-and-long-tail-zero-trust) Stan prawny sprawdzony: 26.10.2026. Wpis jest informacją ogólną, nie poradą prawną ([zasady publikacji](https://pelnomocnikcyber.pl/zasady-publikacji/)).