Saya Memindai 30 Image Docker Populer. 10 Masih Percaya Root CA yang Sudah Dicabut Chrome

(dev.to)

크롬과 모CA가 보안 취약성으로 인해 emSign Root CA를 폐기했음에도 불구하고, 조사 대상 Docker 이미지의 30%가 여전히 해당 인증서를 포함하고 있어 백엔드 시스템의 보안 위협이 되고 있습니다.

이 글의 핵심 포인트

1조사 대상 30개 Docker 이미지 중 10개(33%)가 폐기된 emSign G3 Root CA를 여전히 포함하고 있음
2Python:3.12-slim 이미지의 경우 시스템 번들은 깨끗하지만, pip의 certifi 패키지 내에 폐기된 인증서가 남아 있음
3Amazon Linux 2023 및 Amazon Corretto 21은 폐기 발표 이후 빌드되었음에도 여전히 해당 인증서를 포함함
4일부 이미지(Debian, Node-slim 등)는 CA 번들 자체가 없어, 설치 시점에 따라 보안 상태가 결정됨
5해결을 위해서는 시스템 번들, certifi, Java cacerts 등 모든 저장소를 확인하고 `--pull` 및 `--no-cache`로 재빌드해야 함

이 글에 대한 공공지능 분석

왜 중요한가?

브라우저는 인증서 폐기 목록(CRLSet, OneCRL)을 통해 자동으로 보안을 업데이트하지만, Docker 컨테이너 내부의 애플리케이션(curl, Python requests, Go, JVM 등)은 이를 자동으로 인지하지 못합니다. 이는 인증서가 폐기되었음에도 불구하고 백엔드 서비스가 여전히 신뢰할 수 없는 인증서 체인을 수용할 수 있는 심각한 보안 허점을 의미합니다.

어떤 배경과 맥락이 있나?

최근 eMudhra의 중간 CA 키 취약성 이슈로 인해 Mozilla와 Google은 emSign 관련 Root CA를 차례로 폐기했습니다. 하지만 컨테이너 환경은 운영체제 레벨의 업데이트뿐만 아니라 언어별 런타리(Runtime)가 자체적으로 관리하는 인증서 번들(Bundle)까지 포함하기 때문에, 단순한 OS 패치만으로는 해결되지 않는 복잡한 구조를 가지고 있습니다.

업계에 어떤 영향을 주나?

소프트웨어 공급망 보안(Software Supply Chain Security)의 중요성이 커지는 가운데, 개발자들은 '최신 이미지'나 '최근 빌드된 이미지'를 사용한다는 사실만으로 안전하다고 믿을 수 없게 되었습니다. 특히 Python의 certifi나 Java의 cacerts처럼 런타임에 내장된 인증서 저장소를 간과할 경우, 인프라 전체의 신뢰 체계가 무너질 위험이 있습니다.

한국 시장에 어떤 시사점이 있나?

클라우드 네이티브 환경과 컨테이너 기술을 적극 도입 중인 한국의 스타트업 및 IT 기업들은 CI/CD 파이프라인 내에 인증서 유효성을 검증하는 프로세스를 추가로 고려해야 합니다. 단순히 라이브러리 취약점 스캔을 넘어, 컨테이너 내부의 다양한 신뢰 저장소를 전수 조사하는 정교한 보안 감사 체계가 필요합니다.

이 글에 대한 큐레이터 의견

이번 사례는 '보안의 가시성'이 어디까지 미쳐야 하는지를 보여주는 전형적인 사례입니다. 많은 개발자가 OS 패치나 브라우저 업데이트만으로 보안이 유지될 것이라 믿지만, 실제로는 애플리케이션 런타임 내부의 숨겨진 인증서 저장소가 보안의 사각지대가 될 수 있음을 증명했습니다. 특히 Python의 `certifi`나 Java의 `cacerts`처럼 시스템 번들과 별개로 동작하는 저장소를 확인하지 않는 것은 치명적인 실수입니다.

물론, 모든 컨테이너 이미지의 인증서 저장소를 매번 전수 조사하고 재빌드하는 것은 CI/CD 파이프라인의 복잡성을 높이고 빌드 시간을 증가시키는 트레이드오프를 발생시킵니다. 하지만 인증서 폐기 이슈는 단순한 버그가 아닌 신뢰의 근간을 흔드는 문제이므로, 빌드 시 `--pull` 옵션을 사용하고 런타임 환경의 인증서 상태를 체크하는 자동화된 스크립트를 도입하는 비용은 보안 사고로 인한 손실에 비하면 매우 저렴한 투자라고 판단됩니다.

원문 보기 →