어느 날 전 세계가 한 자바 로깅 라이브러리의 치명적 취약점(Log4Shell)으로 발칵 뒤집혔습니다. 보안팀이 묻습니다. "우리 이미지 중에 그거 들어간 게 어떤 거죠?" 아무도 답하지 못합니다 — 수백 개 이미지 안에 무엇이 들어 있는지 모르니까요. 옆 팀은 SBOM과 스캔으로 30분 만에 대상 12개를 찾아 패치했습니다. 컨테이너 보안은 '내 코드'가 아니라 '내가 가져다 쓴 것들'을 아는 데서 시작합니다.
- 1이미지 스캔이 의존성·OS 패키지의 알려진 취약점을 잡는 원리를 안다
- 2이미지 서명·검증으로 공급망 무결성을 지키는 법을 안다
- 3베이스 이미지 최소화가 공격 표면을 줄이는 이유를 안다
- 4SBOM으로 새 취약점 대응 범위를 빠르게 특정하는 법을 안다
- 5레지스트리·CI 파이프라인에 보안 게이트를 거는 위치를 안다
가져다 쓴 것들을 안다
이미지 스캔 — 내가 짠 게 아니라 가져온 것의 취약점
컨테이너 이미지에는 내 코드뿐 아니라 베이스 OS 패키지, 언어 런타임, 수많은 라이브러리가 들어갑니다. 보안 사고의 상당수는 내 코드가 아니라 가져다 쓴 의존성에 숨은 취약점에서 납니다(Log4Shell이 대표).
이미지 스캔(Trivy, ECR 스캔 등)은 이미지 레이어의 패키지·라이브러리를 취약점 DB(CVE)와 대조해, 알려진 취약점이 있는 버전을 찾습니다. CI 파이프라인(CI/CD 파이프라인)에 스캔을 넣어, 심각 취약점이 있으면 배포를 막는 게이트로 씁니다.
이미지 서명 — '바로 그 이미지'임을 보장
최소 이미지 + SBOM — 표면을 줄이고, 목록을 갖는다
베이스 이미지 최소화(distroless·alpine): 안 쓰는 패키지·셸·도구가 없을수록 취약점과 공격 도구가 줄어듭니다. 침해돼도 공격자가 셸·패키지매니저를 못 써 추가 침투가 어렵습니다(Docker의 멀티스테이지 빌드).
SBOM(부품 명세서): 이미지에 어떤 패키지·버전이 들어 있는지의 목록. 새 취약점이 터졌을 때 "우리 이미지 중 그게 든 게 무엇인지"를 즉시 검색해 대응 범위를 분 단위로 특정합니다. SBOM이 없으면 대응이 며칠 늦어집니다.
배포 전(또는 CI에서) 이미지를 스캔해 심각 취약점을 확인합니다.
trivy image --severity HIGH,CRITICAL myapp:1.4.2
# 또는 ECR 푸시 시 자동 스캔 결과 조회
aws ecr describe-image-scan-findings --repository-name myapp --image-id imageTag=1.4.2 \
--query "imageScanFindings.findingSeverityCounts"
{ "CRITICAL": 1, "HIGH": 4 } # CRITICAL 1건 → 배포 차단 대상
trivy image운영에서 실제 실행 중인 이미지의 불변 다이제스트를 확인해, 의도한 그 이미지가 맞는지 봅니다.
kubectl get pods -o jsonpath='{.items[*].status.containerStatuses[*].imageID}' | tr ' ' '\n' | sort -u
myapp@sha256:9f2b... # 가변 태그가 아니라 다이제스트로 고정돼 있는지 확인
kubectl/docker inspect- 스캔 결과 CRITICAL/HIGH 취약점이 있는 이미지가 운영에 떠 있는지 — CI 게이트를 통과한 경위 점검, 베이스 이미지 업데이트·패치
- 배포가 latest 등 가변 태그로 돼 있는지 — 태그가 가리키는 이미지가 바뀔 수 있음. 불변 다이제스트(@sha256)로 핀
- 이미지 서명 검증이 배포 단계에 적용돼 있는지 — 없으면 변조·악성 이미지 유입 가능. 서명 정책 도입
- SBOM이 이미지마다 생성·보관되는지 — 없으면 새 CVE 터질 때 영향 범위 파악이 며칠 지연
상황: 새 취약점 대응이 '영향 범위 파악' 단계에서 막혀 패치가 지연됨.
원인: 이미지에 무엇이 들어 있는지의 목록(SBOM)이 없고, 정기 스캔도 없어 일일이 이미지를 까보거나 추측으로 대응. 가변 태그라 어떤 이미지가 실제 실행 중인지도 불분명.
진단: SBOM 보관 여부 확인 → 레지스트리의 이미지별 스캔 결과 조회 → 운영 중 이미지의 실제 다이제스트 목록 확보.
해결: CI에서 이미지마다 SBOM 생성·보관 + 정기 재스캔을 표준화하면, 새 CVE에 SBOM을 검색해 영향 이미지를 분 단위로 특정합니다. 다이제스트 핀으로 '무엇이 실행 중인지'를 명확히. 근본적으로는 베이스 이미지 최소화로 애초에 취약점 수를 줄입니다. 이 대응 속도는 관측과 거버넌스의 사고 대응 체계와 한 묶음입니다.
소프트웨어 공급망 보안은 최근 가장 중요해진 영역입니다. "컨테이너 보안 어떻게 하나요?"에 "CI에서 스캔+SBOM, 푸시 시 서명, 배포 시 서명 검증+다이제스트 핀, 베이스 이미지 최소화, 새 CVE는 SBOM으로 즉시 영향 특정"이라 답하면 성숙합니다.
실무 핵심: ① 보안을 배포 직전이 아니라 CI 파이프라인 앞단에 게이트로 — 늦게 막을수록 비싸다(CI/CD 파이프라인), ② 이미지·비밀(시크릿·키 관리)·권한(계정과 IAM)을 함께 봐야 공급망이 닫힌다, ③ '한 번 스캔'이 아니라 새 CVE에 맞춰 재스캔하는 지속 프로세스. 이미지를 만드는 기초는 Docker, 운영은 매니지드 컨테이너·Kubernetes로 이어집니다.
다음으로는 이 모든 보안·운영을 코드로 선언(IaC와 Terraform)하고 Well-Architected 보안 기둥으로 점검하면 클라우드 보안의 큰 그림이 닫힙니다.