Wprowadzenie do problemu / definicja luki
Kontener jest tak bezpieczny, jak jego fundament — a fundamentem najczęściej jest obraz bazowy (base image). To właśnie na nim budujesz swoje aplikacje, dziedziczysz pakiety, konfigurację, użytkowników, a nierzadko także „historyczne” decyzje o tym, co w obrazie w ogóle powinno się znaleźć.
Docker Hardened Images (DHI) to zestaw „utwardzonych” obrazów bazowych i aplikacyjnych utrzymywanych przez Docker, projektowanych tak, by minimalizować powierzchnię ataku i ograniczać ryzyko na poziomie supply chain (łańcucha dostaw oprogramowania). Teraz — i to jest clou wiadomości — katalog ponad 1000 obrazów DHI jest dostępny za darmo i jako open source na licencji Apache 2.0.
W skrócie
- Docker udostępnił 1000+ utwardzonych obrazów jako darmowe i open source (Apache 2.0).
- DHI są projektowane jako minimalne, „rootless” i publikowane z naciskiem na brak znanych podatności w momencie wydania (oraz stałe utrzymanie).
- Wokół DHI zbudowano warstwę weryfikowalności: SBOM, VEX, raporty CVE, skany sekretów oraz SLSA Build Level 3 i podpisane attestations.
- Nadal istnieje podział na Free i Enterprise — m.in. SLA na krytyczne łatki (7 dni) pozostaje po stronie wersji komercyjnej.
Kontekst / historia / powiązania
Docker Hardened Images zostały uruchomione w maju 2025 r. jako oferta ukierunkowana na bezpieczeństwo obrazów i ograniczanie ryzyk na warstwie kontenerów.
W grudniu 2025 temat wraca z mocnym akcentem: 21 grudnia 2025 BleepingComputer opisuje decyzję o udostępnieniu DHI „subscription-free” (bez subskrypcji) oraz przeniesieniu ciężaru monetyzacji na wariant Enterprise.
Warto też zauważyć, iż projekt nie powstał w próżni — SecurityWeek wskazuje, iż katalog DHI był budowany we współpracy z firmami i projektami z ekosystemu (m.in. Cloudsmith, GitLab, Microsoft, NGINX, Sonatype, Sysdig, Wiz).
Analiza techniczna / szczegóły luki
1) „Hardened” w praktyce: minimalizm + rootless + utrzymanie
DHI są opisywane jako obrazy:
- rootless (uruchamiane bez uprawnień roota),
- odchudzone (bez zbędnych komponentów),
- publikowane z założeniem „zero-known CVEs” (brak znanych podatności w momencie publikacji) oraz z ciągłym utrzymaniem.
2) Warstwa „dowodów”: SBOM, VEX, CVE i SLSA
Najciekawsza (i najbardziej praktyczna) część DHI to nie tylko „co jest w obrazie”, ale co da się udowodnić na temat jego pochodzenia i zawartości.
Docker dokumentuje, iż DHI wykorzystują podpisane attestations: to „podpisane oświadczenia” o obrazie (jak powstał, co zawiera i jakie kontrole przeszedł), zwykle podpisywane narzędziami Sigstore (np. Cosign).
Wśród typowych metadanych/attestations pojawiają się m.in.:
- SBOM (CycloneDX oraz SPDX),
- VEX (wskazanie podatności, które nie dotyczą obrazu wraz z uzasadnieniem),
- listy/raporty CVE (różne formaty),
- skany sekretów, testy, skany antywirusowe,
- SLSA provenance i SLSA verification summary,
- informacje o źródłach materiałów użytych do budowy obrazu.
Dodatkowo Docker podkreśla, iż obrazy i chart-y są budowane zgodnie z SLSA Build Level 3 i publikowane z kompletem podpisanych attestations, możliwych do inspekcji m.in. przez Docker Scout lub Cosign.
3) Open source „na serio”: Apache 2.0 i publiczny katalog
Po stronie GitHub projekt jest udostępniony jako Docker Hardened Images z jasną informacją o licencji Apache 2.0 oraz publicznymi repozytoriami (m.in. katalog definicji, advisories, keyring, changelog/log).
Przykładowe użycie (z dokumentacji w README projektu):
docker login dhi.io docker pull dhi.io/node:24-debian13 docker pull dhi.io/python:3.12-alpine3.22 docker pull dhi.io/postgres:17-debian13To ważne: w praktyce oznacza to, iż „bezpieczny start” może być równie prosty jak zmiana obrazu bazowego w Dockerfile — ale z dodatkową możliwością walidacji SBOM/VEX/provenance w pipeline.
Praktyczne konsekwencje / ryzyko
Co realnie zyskujesz, jeżeli przejdziesz na utwardzone obrazy w stylu DHI?
- Mniej niepotrzebnych komponentów → mniejsza powierzchnia ataku i mniej „szumu” w skanerach.
- Lepsza weryfikowalność supply chain: SBOM, VEX i podpisane attestations ułatwiają audyt, dochodzenie po incydencie i budowę polityk bezpieczeństwa w CI/CD.
- Czytelniejszy model utrzymania: Docker opisuje dwa poziomy DHI (Free i Enterprise) i rozdziela „darmowy dostęp” od „gwarantowanych czasów reakcji / compliance”.
Ryzyko / pułapki wdrożeniowe:
- Jeśli liczysz na twarde czasy łatania: SLA 7 dni na krytyczne CVE dotyczy Enterprise, a nie darmowego tieru (Free przez cały czas dostaje łatki, ale bez gwarantowanego okna czasowego).
- Migracja na minimalne, rootless obrazy bywa „bolesna” dla aplikacji, które po cichu zakładają obecność narzędzi systemowych, shella, pakiet managera albo uprawnień roota.
Rekomendacje operacyjne / co zrobić teraz
- Zrób inwentaryzację obrazów bazowych
Wypisz, jakie obrazy bazowe masz w organizacji (prod i build) i gdzie są używane (repo, pipeline, runtime). - Wybierz kandydatów do migracji „low risk”
Na początek: serwisy stateless i obrazy, które i tak regularnie przebudowujesz. - Wprowadź twarde zasady w CI/CD
- pinowanie obrazu po digest, nie po „pływającym” tagu,
- walidacja metadanych supply chain: SBOM, VEX, provenance i skany jako bramki jakości.
- Ustal politykę aktualizacji
- Jeśli potrzebujesz przewidywalności: rozważ Enterprise (SLA, compliance warianty, ELS), bo Free nie gwarantuje okna na krytyczne łatki.
- Testy kompatybilności
Dla każdej aplikacji sprawdź:
- czy działa bez roota,
- czy nie wymaga „narzędzi z obrazu” (curl, bash, package manager),
- czy logika healthchecków i startu nie polega na brakujących binarkach.
Różnice / porównania z innymi przypadkami
DHI vs „zwykłe” obrazy bazowe (np. standardowe obrazy dystrybucyjne / obrazy z Docker Hub):
- w praktyce różnica rzadko polega na tym, iż „tamte są niebezpieczne”, tylko iż trudniej jest udowodnić ich pochodzenie i stan (SBOM/VEX/provenance/attestations jako standard),
- DHI kładą nacisk na rootless + minimalizm + transparentne metadane oraz konsekwentny model utrzymania.
DHI Free vs DHI Enterprise:
- Free: dostęp do katalogu i core funkcji,
- Enterprise: elementy „enterprise-readiness” (SLA, warianty compliance, customizacja, Extended Lifecycle Support).
Podsumowanie / najważniejsze wnioski
Udostępnienie Docker Hardened Images jako darmowych i open source to realny krok w stronę podniesienia bazowego poziomu bezpieczeństwa kontenerów — szczególnie tam, gdzie organizacje chcą przestać „ręcznie” składać bezpieczne base image’y i zamiast tego weryfikować supply chain na podstawie podpisanych dowodów (SBOM/VEX/SLSA).
Najważniejszy niuans: darmowe nie znaczy „z SLA” — jeżeli Twoje ryzyko wymaga gwarantowanego czasu w krytyczne łatki, ten element przez cały czas jest po stronie komercyjnej.
Źródła / bibliografia
- BleepingComputer — „Docker Hardened Images now open source and available for free” (21 grudnia 2025). (BleepingComputer)
- Docker Hardened Images (GitHub) — projekt i README (Apache 2.0, katalog, przykłady użycia). (GitHub)
- Docker Docs — „Docker Hardened Images” (podział Free/Enterprise i opis produktu). (Docker Documentation)
- Docker Docs — „Attestations” (SBOM/VEX/CVE/SLSA i podpisane metadane). (Docker Documentation)
- SecurityWeek — „Docker Makes 1,000 Hardened Images Free and Open Source” (19 grudnia 2025). (SecurityWeek)