Bezpieczeństwo obrazów kontenerowych to zestaw praktyk ograniczających ryzyko wynikające z zawartości obrazu: systemu bazowego, bibliotek aplikacji i sposobu budowania warstw. Skanowanie podatności jest jednym z elementów tej kontroli — wykrywa znane luki w składnikach obrazu, ale samo w sobie nie rozstrzyga, czy obraz jest bezpieczny do uruchomienia w środowisku produkcyjnym.
Na skróty
Czego dowiesz się z artykułu:
- Dlaczego skanowanie obrazów kontenerowych bywa kosztowne, a mimo to nieskuteczne
- Pięć błędów, które najczęściej unieważniają wynik skanowania
- Tabela warstw kontroli: co sprawdzać, czym i na jakim etapie
- Jak wpiąć skanowanie w pipeline, żeby zatrzymywało realne ryzyko
Dla kogo jest ten artykuł:
- Zespoły DevOps i platformowe odpowiedzialne za obrazy produkcyjne
- Inżynierowie bezpieczeństwa wdrażający kontrolę łańcucha dostaw
- Architekci i liderzy techniczni planujący standard budowy obrazów
Czas czytania: 7 minut
Bezpieczeństwo obrazów kontenerowych i skanowanie podatności
Obraz kontenerowy jest pakietem warstw: systemu bazowego, zależności systemowych, bibliotek języka i wreszcie kodu aplikacji. Każda z tych warstw wnosi własne składniki, a większość podatności w typowym obrazie pochodzi nie z kodu napisanego w firmie, lecz z tego, co przyszło razem z obrazem bazowym i menedżerem pakietów.
Standard NIST poświęcony bezpieczeństwu kontenerów porządkuje ryzyka wokół pięciu obszarów — obrazów, rejestrów, orkiestratora, kontenerów w czasie pracy i systemu hosta. Skanowanie podatności dotyka wyłącznie pierwszego z nich. To ważne, bo organizacje często traktują zielony wynik skanera jako dowód bezpieczeństwa całego wdrożenia, podczas gdy jest to dowód dotyczący jednej warstwy z pięciu.
Druga rzecz, którą warto rozumieć od początku: skaner porównuje listę składników obrazu z bazami znanych podatności. Nie wykrywa błędów logiki aplikacji, źle ustawionych uprawnień ani sekretów użytych w czasie działania. Wykrywa to, co ktoś wcześniej opisał i opublikował.
Pięć błędów, które kosztują najwięcej
Błąd pierwszy: skanowanie dopiero na produkcji. Obraz zbudowany tygodnie wcześniej, przetestowany i wdrożony, bywa skanowany dopiero w rejestrze produkcyjnym. Wynik przychodzi wtedy, gdy koszt zmiany jest najwyższy, a zespół ma najmniej czasu — więc podatności lądują na liście wyjątków.
Błąd drugi: brak progu, który cokolwiek zatrzymuje. Skaner raportujący setki znalezisk bez ustalonego progu blokowania staje się generatorem raportów. Jeśli pipeline przepuszcza wszystko niezależnie od wyniku, skanowanie nie jest kontrolą, tylko dokumentacją ryzyka.
Błąd trzeci: traktowanie wszystkich podatności jednakowo. Krytyczna luka w bibliotece, która w tym obrazie nigdy nie jest wywoływana, bywa mniej pilna niż średnia luka w komponencie wystawionym na ruch z internetu. Bez analizy kontekstu uruchomienia lista posortowana po samej ocenie CVSS prowadzi pracę w złą stronę.
Błąd czwarty: obrazy bazowe bez właściciela i bez odświeżania. Obraz bazowy sprzed roku nie dostaje poprawek sam z siebie. Jeśli nikt nie odpowiada za cykliczne przebudowanie obrazów na świeżej podstawie, liczba podatności rośnie nawet wtedy, gdy kod aplikacji w ogóle się nie zmienia.
Błąd piąty: pomijanie etapu budowania. Sekrety wklejone do warstw pośrednich, pakiety deweloperskie zostawione w obrazie produkcyjnym, uruchamianie procesu jako root — to klasa problemów, której skaner podatności zwykle nie zgłasza, a która realnie poszerza powierzchnię ataku. Rekomendacje CIS dla Dockera opisują ten etap osobno właśnie dlatego, że jest niezależny od listy CVE.
Warstwy kontroli: co, czym i kiedy
| Etap | Co sprawdzamy | Rodzaj kontroli |
|---|---|---|
| Budowanie obrazu | użytkownik procesu, zbędne pakiety, sekrety w warstwach | przegląd Dockerfile, reguły polityk |
| Po zbudowaniu | znane podatności w składnikach | skanowanie obrazu w CI |
| Rejestr | podpis i pochodzenie obrazu, retencja | kontrola dostępu, podpisywanie |
| Wdrożenie | uprawnienia, polityki dopuszczenia | reguły w orkiestratorze |
| Czas pracy | nietypowe zachowanie procesów | monitorowanie środowiska uruchomieniowego |
Tabela pokazuje coś, co przy wdrożeniach bywa zaskoczeniem: skanowanie zajmuje w niej jeden wiersz. Pozostałe cztery są tańsze we wdrożeniu niż się wydaje, a bez nich sam skaner zostaje kontrolą punktową.
Jak wpiąć skanowanie, żeby działało
- Przesuń kontrolę do momentu budowania — wynik ma przychodzić wtedy, gdy autor zmiany jeszcze pamięta, co zmienił, a wycofanie kosztuje minuty.
- Ustal próg blokujący i trzymaj go wąsko — lepiej zatrzymywać pipeline na niewielkiej, precyzyjnie zdefiniowanej klasie znalezisk niż ogłosić szeroką politykę, którą po tygodniu wszyscy obchodzą.
- Oddziel obraz bazowy od aplikacji — jeden kurowany zestaw obrazów bazowych, odświeżany cyklicznie, redukuje liczbę podatności w całym portfolio bez pracy po stronie zespołów produktowych.
- Opisz ścieżkę wyjątku — wyjątek z terminem ważności i właścicielem jest zarządzalny; wyjątek bezterminowy jest po prostu wyłączoną kontrolą.
- Dołóż kontrolę etapu budowania — reguły dotyczące użytkownika procesu, zawartości warstw i sekretów łapią klasę problemów, której skaner CVE nie widzi.
Czytaj także
- Bezpieczeństwo kontenerów: Docker i Kubernetes w praktyce — szersze ujęcie tematu, obejmujące orkiestrator i czas pracy kontenerów
- DevSecOps: bezpieczeństwo w cyklu DevOps — kontekst procesowy, czyli jak wpinać kontrole bezpieczeństwa bez zatrzymywania dostarczania
Rozwijaj kompetencje
Temat łączy się ze szkoleniami Bezpieczeństwo aplikacji: AppSec, DevSecOps, OWASP, SAST, DAST, SCA oraz Snyk: zabezpieczanie aplikacji i infrastruktury. Sprawdź program i skontaktuj się z nami, żeby dopasować zakres do Twojego środowiska.
Najczęściej zadawane pytania (FAQ)
Czy skanowanie obrazów zastępuje testy bezpieczeństwa aplikacji?
Nie. Skaner obrazu porównuje składniki z bazami znanych podatności i nie analizuje logiki aplikacji. Błędy autoryzacji, wstrzyknięcia czy wadliwa obsługa sesji wymagają innych narzędzi i innego etapu kontroli — skanowanie obrazu ich nie wykryje.
Jak często przebudowywać obrazy, jeśli kod się nie zmienia?
Regularnie, niezależnie od zmian w kodzie, bo poprawki trafiają do warstw bazowych i zależności systemowych. Cykliczna przebudowa na świeżym obrazie bazowym usuwa część podatności bez żadnej pracy po stronie zespołu produktowego.
Co zrobić z setkami znalezisk w istniejących obrazach?
Zacząć od zawężenia: najpierw obrazy wystawione na ruch zewnętrzny, w nich najpierw składniki faktycznie używane w czasie pracy. Próba uporządkowania całego portfolio naraz, sortowana wyłącznie po ocenie krytyczności, zwykle kończy się listą wyjątków zamiast realnej redukcji ryzyka.
Czy wystarczy skanowanie w rejestrze, bez skanowania w pipelinie?
Rejestr jest dobrym miejscem na kontrolę ciągłą, bo nowe podatności pojawiają się po zbudowaniu obrazu. Nie zastępuje jednak kontroli w pipelinie — bez niej wadliwy obraz powstaje i trafia do rejestru, a reakcja następuje dopiero po fakcie.