8.4 Dostęp do kodu źródłowego
W skrócie: kto może czytać, a kto zmieniać kod źródłowy, jest kontrolowane — kod jest wartością i drogą do wprowadzenia niepożądanych funkcji.
Cel: zapobieganie wprowadzaniu nieuprawnionych funkcji, uniknięcie niezamierzonych lub złośliwych zmian i zachowanie poufności cennej własności intelektualnej.
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 | #Application_security (bezpieczeństwo aplikacji), #Secure_configuration (bezpieczna konfiguracja), #Identity_and_access_management (zarządzanie tożsamością i dostępem) |
| Domeny bezpieczeństwa | #Protection (ochrona) |
Znaczenie atrybutów opisuje 4.2 Tematy i atrybuty.
Wytyczne
- Dostęp do kodu źródłowego i elementów z nim związanych (projekty, specyfikacje, plany weryfikacji i walidacji) oraz narzędzi deweloperskich (kompilatory, narzędzia budowania, integracji, platformy testowe) jest ściśle kontrolowany.
- Odczyt i zapis kodu zarządza się różnie w zależności od roli: odczyt może być szerszy, zapis ograniczony do uprawnionych osób.
- Kod źródłowy zarządza się w systemie kontroli wersji, z uwzględnieniem procedur zarządzania zmianami (8.32).
- Dostęp do kodu i bibliotek nadaje się według wiedzy koniecznej, zgodnie z procedurami.
- Aktualizacja kodu i wydawanie go programistom odbywa się po autoryzacji.
- Programiści nie mają bezpośredniego dostępu do repozytorium kodu źródłowego, lecz korzystają z narzędzi deweloperskich, które kontrolują działania i uprawnienia.
- Listingi kodu przechowuje się w bezpiecznym miejscu. Dostęp do kodu i jego zmiany rejestruje się (dziennik audytu).
- Jeśli kod ma być publikowany, rozważa się dodatkowe zabezpieczenia jego integralności, np. podpis cyfrowy.
W praktyce
Przykłady i narzędzia poniżej to praktyka branżowa, nie treść normy.
- Ochrona gałęzi głównej: wymagany przegląd, podpisane commity, brak bezpośrednich zapisów.
- Skanowanie repozytoriów pod kątem sekretów (np. gitleaks, GitHub secret scanning) — sekret usunięty z kodu nadal zostaje w historii repozytorium i trzeba go unieważnić.
- SSO i MFA do platformy repozytoriów; odbieranie dostępu kontraktorom w dniu zakończenia współpracy.
Powiązania
- ISO/IEC 27001:2022: Załącznik A, A.8.4 — wykaz zabezpieczeń technologicznych.
- Pokrewne zabezpieczenia: 8.25 Bezpieczny cykl życia wytwarzania, 8.28 Bezpieczne programowanie, 8.32 Zarządzanie zmianami, 5.32 Prawa własności intelektualnej.
- ISO/IEC 27002:2013: 9.4.5.