176. 컨테이너 이미지 취약점 스캐닝 (Container Image Vulnerability Scanning)

핵심 인사이트 (3줄 요약)

본질: 컨테이너 이미지 취약점 스캐닝은 이미지 레이어와 Software Bill of Materials (SBOM)을 Common Vulnerabilities and Exposures (CVE) 데이터와 대조해, 배포 전에 알려진 약한 구성요소를 찾아내는 공급망 보안 게이트다.

가치: 취약점은 런타임보다 빌드·레지스트리 단계에서 제거할수록 비용이 낮고 파급 범위가 작다. 특히 베이스 이미지 한 번의 교체가 여러 서비스의 위험을 함께 줄인다.

판단 포인트: Trivy냐 Clair냐보다 더 중요한 것은 언제 스캔할지와 어떤 심각도에서 차단할지다. 빌드 시 1회 스캔만으로는 부족하며, 레지스트리 재스캔과 예외 승인 절차가 함께 있어야 운영 가능한 체계가 된다.

Ⅰ. 개요 및 필요성

컨테이너 이미지 취약점 스캐닝은 컨테이너 이미지 안에 포함된 운영체제 패키지, 언어 런타임, 애플리케이션 라이브러리를 분석해 알려진 취약점을 식별하는 활동이다. 이미지가 불변 배포 단위라는 점 때문에, 한 번 취약한 이미지가 표준 베이스로 자리 잡으면 동일 위험이 여러 서비스로 빠르게 복제된다. 즉 "코드는 안전한데 운영환경은 위험한" 상태가 쉽게 만들어진다.

문제가 더 커지는 이유는 취약점이 이미지 빌드 시점에만 존재하는 것이 아니기 때문이다. 오늘은 안전했던 이미지라도 내일 새 CVE가 공개되면 즉시 위험 자산으로 바뀐다. 그래서 스캐닝은 단발성 검사보다 지속적인 재평가에 가깝다.

예를 들어 ubuntu:22.04 기반 이미지 하나에 OpenSSL, glibc, Python 패키지가 함께 들어 있으면, 애플리케이션을 수정하지 않아도 베이스 레이어의 취약점만으로 공격면이 열린다. 이때 운영자가 런타임에서 뒤늦게 대응하면 이미 여러 클러스터와 리전에 동일 이미지가 퍼진 뒤일 수 있다.

┌──────────────────────────────────────────────────────────────┐
│      왜 이미지 단계에서 막아야 하는가: 취약점의 복제 속도     │
├──────────────────────────────────────────────────────────────┤
│ Base Image ─▶ Service A Image ─▶ Pod A1, A2, A3             │
│            ├▶ Service B Image ─▶ Pod B1, B2                 │
│            └▶ Service C Image ─▶ Batch Job C1               │
│                                                              │
│ 베이스 레이어 1곳의 취약점이 여러 서비스 배포본으로 증식됨    │
└──────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 이미지 스캐닝은 식당에 재료가 들어올 때 하는 검수와 같다. 요리가 식탁에 오른 뒤에 상한 재료를 찾는 것보다, 창고 입고 시점에 막는 편이 훨씬 싸고 안전하다.

Ⅱ. 아키텍처 및 핵심 원리

이미지 스캐너는 단순히 파일 이름만 보는 것이 아니라, 이미지 매니페스트와 각 레이어의 패키지 메타데이터를 추출해 취약점 데이터베이스와 매칭한다. 운영체제 패키지는 apk, apt, rpm 정보로, 애플리케이션 의존성은 package-lock.json, requirements.txt, pom.xml 혹은 바이너리 메타데이터로 식별한다. 최근에는 SBOM을 먼저 생성한 뒤 스캐너가 SBOM을 읽는 방식도 널리 쓰인다.

스캐닝 파이프라인의 핵심은 식별 → 매칭 → 정책 판정의 3단계다. 식별 단계에서 어떤 패키지가 몇 버전인지 정확히 알아내고, 매칭 단계에서 National Vulnerability Database (NVD)나 배포판 보안 어드바이저리와 대조한다. 마지막 정책 판정 단계에서 CRITICAL/HIGH 차단, fix available 있을 때만 차단, waiver ticket 없으면 배포 불가 같은 규칙을 적용한다.

단계	하는 일	실무 판단 포인트
식별	레이어, 패키지, 라이브러리, SBOM 추출	distroless 이미지라도 언어 의존성은 별도 식별 필요
매칭	CVE, 배포판 패치 정보, 고정 버전 비교	배포판 백포트로 인한 오탐 여부 확인
판정	심각도, exploit 가능성, fix 여부로 게이트	운영환경과 개발환경의 차등 정책 필요
조치	베이스 이미지 교체, 패키지 업그레이드, 예외 승인	"무시"보다 만료일 있는 예외 관리가 중요

아래 흐름은 빌드와 레지스트리 양쪽에서 스캐닝이 필요한 이유를 보여준다.

┌──────────────┐    ┌──────────────┐    ┌────────────────────┐
│ Dockerfile   │──▶ │ Image Build  │──▶ │ SBOM / Package Map │
└──────────────┘    └──────────────┘    └──────────┬─────────┘
                                                   │
                                                   ▼
                                         ┌──────────────────┐
                                         │ Scanner Engine   │
                                         │ Trivy / Clair    │
                                         └────────┬─────────┘
                                                  │
                        ┌─────────────────────────┼─────────────────────────┐
                        ▼                         ▼                         ▼
              ┌────────────────┐       ┌────────────────┐       ┌────────────────┐
              │ CVE Database   │       │ Distro Advisory│       │ SBOM Metadata  │
              │ NVD / Vendor   │       │ Backport Info  │       │ package source │
              └────────────────┘       └────────────────┘       └────────────────┘
                                                  │
                                                  ▼
                                         ┌──────────────────┐
                                         │ Policy Gate      │
                                         │ pass / warn / deny│
                                         └────────┬─────────┘
                                                  │
                      ┌───────────────────────────┴──────────────────────────┐
                      ▼                                                      ▼
            ┌────────────────┐                                   ┌────────────────┐
            │ Registry Push  │                                   │ Deployment Hold│
            └────────────────┘                                   └────────────────┘

중요한 함정도 있다. 동일한 버전 문자열이라도 배포판이 보안 패치를 백포트했으면 실제로는 안전할 수 있어 단순 버전 비교만으로는 오탐이 생긴다. 반대로 패키지가 삭제되지 않고 남아 있는 디버그 도구나 셸은 CVE가 없어도 공격면을 넓힌다. 그래서 스캐닝은 "리스트를 읽는 작업"이 아니라 이미지 구성 최소화와 함께 가야 하는 설계 활동이다.

📢 섹션 요약 비유: 스캐너는 짐 검사용 X-ray이고, 정책 게이트는 출국 심사대다. X-ray에서 이상 물질을 봤더라도 심사 규칙이 없으면 결국 위험한 짐이 비행기에 실린다.

Ⅲ. 비교 및 연결

이미지 취약점 스캐닝은 다른 보안 검증을 대체하지 않는다. SAST (Static Application Security Testing)는 소스코드의 취약한 패턴을 찾고, SCA (Software Composition Analysis)는 라이브러리 종속성 자체의 취약점을 찾으며, 이미지 스캐닝은 배포 단위 안에 실제로 들어간 결과물을 검사한다. 런타임 보안은 배포 이후의 행위를 감시하므로 시점과 목적이 다르다.

통제 지점	보는 대상	잘 잡는 문제	놓치기 쉬운 문제
SAST	소스코드	하드코딩, 취약한 로직, 입력 검증 누락	베이스 이미지 취약점
SCA	오픈소스 의존성 선언	애플리케이션 라이브러리 CVE	실제 컨테이너에 포함된 OS 패키지
이미지 스캐닝	실제 이미지 레이어	운영체제 패키지, 런타임, 배포 산출물 CVE	제로데이, 런타임 행위
런타임 보안	실행 중 프로세스/시스템 호출	이상 행위, 권한 남용, 탈출 시도	배포 전 차단

도구 비교에서도 같은 원리가 적용된다. Trivy는 단일 바이너리와 광범위한 스캔 대상을 강점으로 하고, Clair는 레지스트리 연동형 운영에 익숙하며, Grype는 SBOM 친화성이 좋다. 하지만 어느 도구든 취약점 데이터 원천과 정책 연동이 약하면 실무 효과는 제한된다.

이미지 스캐닝은 DevSecOps (Development, Security, and Operations), SBOM, Cosign 서명, Admission Controller와 이어질 때 더 강력해진다. 예를 들어 scan=pass와 signature=verified 두 조건을 모두 만족한 이미지만 Kubernetes에 배포하게 만들면, "취약점이 적고 출처가 검증된 이미지"만 운영망에 들어가게 된다.

📢 섹션 요약 비유: 이미지 스캐닝은 건강검진표 한 장일 뿐이다. 진짜 안전한 입학 절차가 되려면 신원 확인(서명 검증), 생활기록부(SBOM), 입학 허가 기준(배포 정책)이 함께 붙어야 한다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 "취약점 0건"보다 "배포 가능한 수준으로 위험을 관리하는가"가 더 중요하다. 개발 환경까지 무조건 HIGH 이상 차단으로 묶으면 생산성이 급격히 떨어질 수 있고, 반대로 운영 환경까지 경고만 남기면 스캐닝은 보고서 생성기로 전락한다. 따라서 환경별 정책을 나누되, 운영 승격 경로는 더 엄격하게 설계해야 한다.

상황	권장 판단	이유
개발 브랜치 빌드	경고 중심 + 티켓 발행	탐색 단계에서는 학습 비용 최소화
스테이징/릴리스 후보	`CRITICAL`, `HIGH` 차단	운영 전 위험 제거 비용이 가장 낮음
운영 중 저장소 재스캔	fix available 우선 조치	신규 CVE 공개는 빌드 이후에도 발생
규제·금융 서비스	예외 승인 만료일 강제	영구 예외는 통제 실패로 이어짐
경량 서비스	distroless/slim 베이스 우선	패키지 수 자체를 줄여 공격면 축소

실제 개선 순서도 중요하다. 일반적으로는 애플리케이션 코드 수정보다 베이스 이미지 교체가 더 빠르고 영향 범위가 넓다. 다음으로는 불필요 패키지 제거, 루트 권한 축소, 패키지 버전 업그레이드, 마지막으로 불가피한 예외 승인 순으로 접근하는 편이 효율적이다.

체크리스트

빌드 시 스캔과 레지스트리 주기 재스캔을 모두 수행하는가?
심각도뿐 아니라 fix available, runtime reachable 같은 추가 조건을 반영하는가?
예외는 만료일과 담당자, 근거 티켓을 포함하는가?
이미지 서명 검증과 배포 차단 정책이 연결되어 있는가?

안티패턴

스캔 결과를 쌓아두기만 하고 배포 게이트로 연결하지 않는 경우
베이스 이미지 갱신 없이 애플리케이션 라이브러리만 반복 패치하는 경우
예외 승인을 무기한으로 열어 두는 경우
운영 중 재스캔을 생략해 새 CVE를 놓치는 경우
📢 섹션 요약 비유: 좋은 스캐닝 정책은 병원 응급실 분류처럼 작동한다. 모두를 같은 속도로 처리하지 않고, 당장 위험한 환자부터 먼저 격리하고 치료해야 전체 시스템이 안정된다.

Ⅴ. 기대효과 및 결론

이미지 취약점 스캐닝이 제대로 자리 잡으면 배포 속도를 늦추는 대신, 취약한 배포의 재작업 비용을 크게 줄인다. 동일 베이스 이미지로 묶인 서비스 군을 식별할 수 있어, 새 CVE 공개 시 어느 팀이 무엇부터 고쳐야 하는지도 빨라진다. 이는 보안 대응을 사람의 기억이 아니라 파이프라인 규칙으로 옮기는 효과가 있다.

다만 이 방법은 알려진 취약점에 강할 뿐, 제로데이 공격이나 잘못된 권한 설정까지 모두 해결하지는 못한다. 오탐과 예외 승인 피로도도 반드시 관리해야 한다. 따라서 기억할 핵심은 "스캐너가 보안을 완성한다"가 아니라 스캐너가 배포 위험을 계량화하고 차단하는 첫 관문이라는 점이다.

앞으로는 Vulnerability Exploitability eXchange (VEX) 기반의 실제 exploit 가능성 판단, SBOM 기반 영향도 분석, 공급망 attestation 연계가 더 중요해질 것이다. 즉 이미지 스캐닝은 단독 기능이 아니라, 소프트웨어 공급망 보안 체계의 중심 축으로 진화하고 있다.

📢 섹션 요약 비유: 이미지 스캐닝은 건물 입구의 금속 탐지기다. 이것만으로 도시 전체가 안전해지지는 않지만, 입구에서 위험을 줄이면 그 뒤의 보안 체계가 훨씬 효율적으로 작동한다.

📌 관련 개념 맵

개념	연결 포인트
DevSecOps (Development, Security, and Operations)	배포 파이프라인 안에서 보안 검증을 자동화하는 운영 방식
SBOM (Software Bill of Materials)	이미지 구성요소를 구조적으로 설명해 재스캔과 영향 분석을 돕는 목록
CVE (Common Vulnerabilities and Exposures)	스캐너가 취약점 여부를 판정할 때 참조하는 표준 식별자
Cosign	이미지 출처와 무결성을 검증하는 서명 도구
Admission Controller	스캔 결과와 서명 상태를 바탕으로 Kubernetes 배포를 허용·차단하는 정책 계층
Distroless Image	패키지 수를 줄여 공격면과 스캔 건수를 동시에 낮추는 이미지 전략

📈 관련 키워드 및 발전 흐름도

수동 패치 중심 운영
    │
    ▼
이미지 빌드 시 취약점 스캔
    │
    ▼
SBOM 생성 · 레지스트리 재스캔
    │
    ▼
서명 검증 · Admission Policy 연계
    │
    ▼
VEX · 공급망 Attestation 기반 위험 판단

이 흐름은 "한 번 검사"에서 출발해 "지속 재평가와 배포 통제"로 무게중심이 이동하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

컨테이너 이미지는 여러 재료가 들어 있는 도시락이라서, 먹기 전에 상한 재료가 없는지 먼저 검사해야 해요.
검사기가 "이 재료는 위험해요"라고 알려주면, 도시락을 다시 만들거나 재료를 바꿔야 해요.
그래서 좋은 스캐닝은 도시락을 다 만든 뒤가 아니라, 가게에서 팔기 전에 안전문처럼 지켜 주는 거예요.