skanowanie obrazów kontenerów

Skanowanie obrazów kontenerów to automatyczne sprawdzanie obrazów Dockera i innych kontenerów pod kątem znanych podatności, przestarzałych pakietów, osadzonych sekretów, błędów konfiguracji i złośliwego oprogramowania, zanim obraz zostanie uruchomiony. NIST w wytycznych SP 800-190 zaleca narzędzia i procesy zarządzania podatnościami dostosowane do kontenerów, bo tradycyjne skanery często nie widzą podatności wewnątrz kontenerów i dają fałszywe poczucie bezpieczeństwa ^[1]. OWASP zaleca włączenie skanerów kontenerów do potoku CI/CD ^[2].

Jak działa

Obraz kontenera to w praktyce archiwum plików z systemem bazowym, bibliotekami i aplikacją. Skaner rozpakowuje go, rozpoznaje zainstalowane pakiety i porównuje ich wersje z bazami znanych podatności, czyli wpisów CVE.

Trivy wykrywa pakiety systemowe zainstalowane przez menedżery takie jak dpkg, yum i apk oraz pakiety języków programowania, w tym PHP, Pythona i Node.js ^[3]. Dla pakietów systemowych korzysta z biuletynów producentów dystrybucji, a nie z ogólnej bazy NVD, aby ograniczyć fałszywe alarmy (false positive) ^[3]. Dla bibliotek języków sięga do baz takich jak GitHub Advisory Database ^[3]. Przy skanowaniu obrazu Trivy domyślnie szuka podatności i sekretów ^[4], a wyniki zapisuje w pamięci podręcznej według identyfikatora obrazu i warstw ^[4].

Grype, drugie popularne narzędzie otwarte, skanuje obrazy, systemy plików i wykazy SBOM (wykaz komponentów oprogramowania) ^[6]. Obsługuje pakiety Alpine, Debiana, Ubuntu, RHEL i innych dystrybucji oraz ekosystemy języków, w tym PHP ^[6]. Do ustalania priorytetów używa między innymi EPSS i katalogu KEV ^[6].

NIST zaleca, aby skanowanie obejmowało cały cykl życia obrazu: od budowania, przez rejestr, do uruchomienia ^[1]. Schemat poniżej pokazuje to w uproszczeniu.

RYS. 1Skanowanie w cyklu życia obrazu

Co wykrywa skaner

NIST opisuje pięć głównych ryzyk samego obrazu ^[1]. Skanery pokrywają je w różnym stopniu.

NIST podkreśla, że obraz zbudowany z aktualnych składników po kilku dniach lub tygodniach przestaje być wolny od znanych podatności, bo odkrywane są nowe ^[1]. W kontenerach nie łata się działającego systemu, tylko buduje nowy obraz i wdraża go od nowa ^[1]. Dlatego skan obrazu jednorazowo przy budowaniu nie wystarcza.

W WordPressie

WordPress w kontenerach pojawia się w dwóch miejscach. Oficjalny obraz Dockera dla WordPressa jest utrzymywany w repozytorium docker-library i ma warianty z Apache, z PHP-FPM oraz z WP-CLI ^[7]. Narzędzie wp-env, służące do lokalnego budowania i testowania wtyczek i motywów, domyślnie działa na Dockerze i uruchamia kontenery wordpress i mariadb ^[8].

Skaner obrazu dobrze widzi warstwę systemową: wersję PHP, serwera WWW i bibliotek systemowych. Zależności PHP rozpoznaje przez pliki Composera; Trivy analizuje composer.lock oraz vendor/composer/installed.json ^[5]. Wtyczki i motywy zainstalowane z katalogu WordPress.org zwykle nie mają takiego pliku, więc ogólny skaner kontenerów ich nie rozpozna. Do nich potrzebne jest osobne skanowanie podatności pod kątem podatności we wtyczkach i motywach.

W obrazach WordPressa szczególnie ważne jest, aby nie umieszczać w nich pliku wp-config.php z hasłem do bazy i kluczami bezpieczeństwa i solami. NIST zaleca trzymanie sekretów poza obrazem i przekazywanie ich w chwili uruchomienia ^[1], a OWASP poleca w tym celu mechanizm Docker Secrets ^[2]; zob. zarządzanie sekretami.

Znaczenie

Skanowanie przesuwa wykrywanie podatności przed wdrożenie. NIST zaleca konfigurowanie reguł, które zatrzymują w procesie budowania obrazy z podatnościami o ocenie CVSS powyżej wybranego progu ^[1]. Taka bramka zamienia politykę bezpieczeństwa w automatyczną decyzję potoku.

Skaner nie zastępuje jednak innych środków. Wykrywa tylko znane problemy opisane w bazach. Nie wykryje podatności w autorskim kodzie aplikacji ani nowego zero-day. Nie chroni też przed ucieczką z kontenera (container escape) przez błąd w samym Dockerze; OWASP zaleca w tym celu aktualizowanie hosta i Dockera ^[2].

Dobre praktyki

• Skan w potoku CI/CD. OWASP wymienia darmowe skanery Clair, Grype i Trivy oraz narzędzia komercyjne, między innymi Snyk, Anchore i Docker Scout ^[2]. Do wykrywania sekretów poleca ggshield, Gitleaks i TruffleHog ^[2].
• Wszystkie warstwy. NIST wymaga widoczności podatności we wszystkich warstwach obrazu, nie tylko w warstwie bazowej, ale też w frameworkach i własnym oprogramowaniu ^[1].
• Minimalne i zaufane obrazy bazowe. NIST zaleca obrazy bazowe tylko z zaufanych źródeł, częste ich aktualizacje i wybór minimalistycznych dystrybucji, takich jak Alpine Linux, aby zmniejszyć powierzchnię ataku ^[1].
• Użytkownik bez uprawnień. OWASP uważa uruchamianie kontenera jako nieuprzywilejowany użytkownik za najlepszy sposób zapobiegania eskalacji uprawnień ^[2]. To zastosowanie zasady najmniejszych uprawnień.
• Ponowne skany. Obrazy w rejestrze trzeba skanować cyklicznie, bo nowe wpisy CVE pojawiają się po zbudowaniu obrazu ^[1]. Wyniki trafiają do procesu zarządzania podatnościami.
• Priorytety. Nie każda znaleziona podatność wymaga natychmiastowej reakcji. Wskaźniki EPSS i KEV w Grype pomagają wybrać te, które są realnie wykorzystywane ^[6].