8.28 Bezpieczne programowanie ★
W skrócie: programiści stosują zasady bezpiecznego kodowania, a kod — własny i zewnętrzny — jest przeglądany i testowany pod kątem podatności.
Cel: zapewnienie, że oprogramowanie jest pisane bezpiecznie, co zmniejsza liczbę potencjalnych podatności.
★ Zabezpieczenie nowe w wydaniu 2022 — nie ma odpowiednika w ISO/IEC 27002:2013.
Atrybuty
| Typ atrybutu | Wartości |
|---|---|
| Typ zabezpieczenia | #Preventive (prewencyjne) |
| Właściwości bezpieczeństwa informacji | #Confidentiality (poufność), #Integrity (integralność), #Availability (dostępność) |
| Koncepcje cyberbezpieczeństwa | #Protect (ochrona) |
| Zdolności operacyjne | #System_and_network_security (bezpieczeństwo systemów i sieci), #Application_security (bezpieczeństwo aplikacji) |
| Domeny bezpieczeństwa | #Protection (ochrona) |
Znaczenie atrybutów opisuje 4.2 Tematy i atrybuty.
Wytyczne
- Organizacja ustanawia procesy zarządzania bezpiecznym programowaniem i minimalny standard dla organizacji — także dla kodu od stron trzecich i open source.
- Śledzi rzeczywiste zagrożenia i informacje o podatnościach w oprogramowaniu, by doskonalić zasady.
- Przed kodowaniem: oczekiwania wobec bezpiecznego kodowania dla każdego języka, typowe błędy prowadzące do podatności, konfiguracja narzędzi (IDE) wspierających bezpieczny kod, wskazówki dostawców narzędzi, utrzymanie aktualnych narzędzi, kwalifikacje programistów, bezpieczny projekt i architektura, modelowanie zagrożeń.
- Podczas kodowania: praktyki specyficzne dla języka i technik, techniki takie jak programowanie w parach, refaktoryzacja, przegląd kodu, testy jednostkowe; unikanie niebezpiecznych technik (np. zakodowanych na stałe haseł, niezatwierdzonego kodu z zewnątrz).
- Po napisaniu: bezpieczne aktualizowanie, ocena zgłoszonych podatności, rejestrowanie błędów i podejrzanych ataków, ochrona kodu przed manipulacją.
- Kod zewnętrzny i biblioteki: zarządzanie bibliotekami zewnętrznymi, w tym aktualizacjami i podatnościami; inwentarz wykorzystywanych komponentów.
- Przy oprogramowaniu modyfikowanym ocenia się ryzyko zmian, wpływ na wsparcie dostawcy i licencje.
- Testy statyczne (SAST) i przeglądy kodu wspierają wykrywanie podatności.
W praktyce
Przykłady i narzędzia poniżej to praktyka branżowa, nie treść normy.
- OWASP Top 10 i CWE Top 25 jako lista typowych błędów do szkoleń i reguł przeglądu kodu.
- Narzędzia SAST (Semgrep, SonarQube, CodeQL) i SCA (Dependabot, Renovate, OWASP Dependency-Check) w potoku CI.
- Zasady dla kodu generowanego przez asystentów AI: przegląd jak każdego innego kodu, sprawdzenie zależności, które asystent sugeruje.
Powiązania
- ISO/IEC 27001:2022: Załącznik A, A.8.28 — wykaz zabezpieczeń technologicznych.
- Pokrewne zabezpieczenia: 8.25 Bezpieczny cykl życia wytwarzania, 8.4 Dostęp do kodu źródłowego, 8.29 Testy bezpieczeństwa w wytwarzaniu i odbiorze, 8.8 Zarządzanie podatnościami technicznymi, 6.3 Świadomość, edukacja i szkolenia w zakresie bezpieczeństwa informacji.
- ISO/IEC 27002:2013: brak odpowiednika — zabezpieczenie nowe.