컨테이너 보안 알림이 많다고 해서 모두 같은 위험은 아니다. Docker와 Black Duck의 통합은 Docker Hardened Images(DHI), VEX, Black Duck 분석 엔진을 묶어 “베이스 이미지에 존재하지만 실제 영향이 낮은 취약점”과 “애플리케이션 레이어에서 조치해야 할 위험”을 분리하려는 접근이다.
핵심 요약
- Docker 발표의 핵심은 Black Duck이 DHI 기반 이미지를 스캔할 때 Docker의 VEX(Vulnerability Exploitability eXchange) 판단과 Black Duck Security Advisories(BDSA)를 함께 활용한다는 점이다.
- 목표는 취약점 개수를 단순히 줄이는 것이 아니라, Docker가
not_affected로 판단한 베이스 이미지 항목과 애플리케이션 코드/의존성에서 발생한 위험을 구분하는 것이다. - Black Duck Binary Analysis(BDBA)는 컴파일된 바이너리와 컨테이너 내부 자산을 기준으로 DHI 구성요소를 식별하고, Black Duck SCA 연동은 같은 인텔리전스를 소스 의존성 관리 쪽으로 확장하는 로드맵으로 제시됐다.
- 실무 도입 전에는 “자동 무시” 정책을 바로 켜기보다 이미지 다이제스트, SBOM/VEX 근거, 예외 만료일, CI/CD 차단 기준을 먼저 정해야 한다.
무엇이 바뀌었나
일반적인 컨테이너 스캐너는 파일 시스템 안의 패키지와 취약점 데이터베이스를 대조한다. 이 방식은 빠르지만, 해당 취약 코드가 실제 런타임에서 호출되는지, 공급자가 하드닝 과정에서 이미 비영향으로 판단했는지까지는 충분히 설명하지 못할 수 있다.
Docker 글은 Black Duck 통합이 이 문제를 줄이기 위해 세 가지 신호를 결합한다고 설명한다. 첫째, DHI가 제공하는 보안 강화 베이스 이미지다. 둘째, Docker가 제공하는 VEX 문서로, 특정 이미지와 취약점 조합이 실제로 영향받는지 여부를 기계가 읽을 수 있게 전달한다. 셋째, Black Duck의 BDBA/SCA와 BDSA 인텔리전스다.
따라서 이 통합의 가치는 “CVE 목록을 덜 보여준다”가 아니라, 보안팀과 개발팀이 같은 근거로 우선순위를 정할 수 있게 만드는 데 있다. 베이스 이미지의 비영향 항목은 정책적으로 낮은 우선순위로 두고, 애플리케이션 레이어에서 들어온 취약 의존성이나 도달 가능한 위험은 더 강하게 차단하는 식이다.
소음을 줄이는 작동 방식
| 구성 요소 | 역할 | 운영에서 확인할 점 |
|---|---|---|
| Docker Hardened Images | 보안 기준을 강화한 베이스 이미지로, 베이스 레이어의 위험을 줄이는 출발점이다. | 현재 서비스가 쓰는 런타임/패키지와 호환되는 DHI가 있는지 확인한다. |
| VEX | 특정 취약점이 특정 제품 구성에서 영향받는지 여부를 전달한다. | not_affected 판단의 대상 이미지, 버전, 플랫폼 범위가 배포 환경과 맞는지 확인한다. |
| BDBA | 소스 코드 없이도 컨테이너 내부 바이너리와 컴파일된 자산을 분석한다. | 패키지 메타데이터가 빠진 이미지에서도 식별이 안정적인지 샘플로 검증한다. |
| Black Duck SCA | 애플리케이션 의존성과 SBOM 관리를 SDLC 전반으로 확장한다. | 기존 SCA 정책, PR 체크, 릴리스 승인 흐름과 충돌하지 않는지 본다. |
| BDSA | NVD 외의 취약점 분석과 조치 정보를 제공한다. | NVD 심각도와 BDSA 판단이 다를 때 어떤 기준을 우선할지 정한다. |
운영에서 의미하는 변화
- 트리아지 기준이 바뀐다. “심각도 높음” 하나로 빌드를 막기보다, 레이어 위치, 도달 가능성, 악용 가능성, 패치 가능성을 함께 본다.
- 베이스 레이어와 앱 레이어를 나눠 본다. 공급자가 비영향으로 판단한 DHI 항목과 개발자가 추가한 의존성 문제를 같은 큐에 넣지 않는다.
- CI/CD 게이트를 더 세밀하게 만들 수 있다. Black Duck Detect CLI 같은 흐름에서 도달 가능하거나 조치되지 않은 앱 레이어 위험만 차단하고, 근거 있는 베이스 이미지 항목은 경고나 예외로 처리할 수 있다.
- 감사 대응 자료가 남는다. SBOM, VEX 상태, 정책 버전, 예외 승인 기록이 함께 남으면 나중에 “왜 배포를 허용했는가”를 설명하기 쉽다.
주의할 점: 자동 무시는 안전과 같지 않다
VEX 기반 예외는 유용하지만, 자동 무시 정책을 넓게 켜면 실제 조치가 필요한 위험까지 묻힐 수 있다. 특히 베이스 이미지가 DHI라고 해도 애플리케이션 레이어에서 추가한 패키지, 빌드 스크립트가 가져온 바이너리, 런타임에 내려받는 플러그인은 별도로 봐야 한다.
또한 VEX 판단은 이미지와 버전, 아키텍처, 배포 방식에 묶여 있다. 운영 환경이 원문에서 가정한 구성과 다르거나, 내부에서 이미지를 재패키징했다면 “비영향” 판단을 그대로 적용하기 어렵다. 예외는 반드시 만료일과 재검토 조건을 가져야 한다.
도입 전 체크리스트
- 이미지 기준선: 현재 운영 이미지의 다이제스트, 베이스 이미지, SBOM을 먼저 보관한다.
- 정책 분리: 베이스 레이어 경고, 앱 레이어 취약점, 도달 가능한 취약점, 패치 가능한 취약점을 서로 다른 규칙으로 나눈다.
- 예외 만료:
not_affected나 수동 예외를 영구 무시로 두지 말고 만료일과 재검토 담당자를 둔다. - 실패 시 복구: CI/CD 차단 정책이 잘못 동작했을 때 이전 정책으로 되돌리는 절차를 문서화한다.
- 비용과 권한: DHI, Black Duck, 조직 단위 정책, Jira/이메일 연동이 어떤 플랜과 권한을 요구하는지 확인한다.
작게 테스트하는 방법
- 운영 서비스가 아닌 내부 API나 배치 잡 하나를 고르고, 현재 컨테이너 이미지의 스캔 결과를 기준선으로 저장한다.
- 가능하다면 같은 애플리케이션을 DHI 기반 이미지로 다시 빌드하고, 기존 베이스 이미지와 취약점 수·레이어 위치·조치 가능 항목을 비교한다.
- Black Duck 정책을 “차단”, “경고”, “예외”로 나누어 PR 또는 CI에서 개발자에게 어떤 신호가 보이는지 확인한다.
- 대표 CVE 몇 개를 골라 VEX 상태, BDSA 판단, 패치 이미지 여부, 릴리스 노트 링크가 감사 로그에 충분히 남는지 검증한다.
- 일주일 정도 운영한 뒤 실제로 줄어든 알림 수보다 “개발자가 조치한 항목의 품질”과 “예외 재검토 누락 여부”를 먼저 평가한다.
결론
Docker·Black Duck 통합은 컨테이너 보안에서 흔한 경보 피로를 줄이는 실용적인 방향이다. 특히 DHI와 VEX를 이미 쓰고 있거나, Black Duck으로 SCA/컨테이너 분석을 운영하는 팀이라면 베이스 이미지 소음과 애플리케이션 위험을 분리하는 효과를 기대할 수 있다.
다만 이 통합을 “취약점이 자동으로 사라지는 기능”으로 보면 위험하다. 좋은 도입 방식은 자동 예외를 최소 범위에서 시작하고, 근거·만료일·정책 버전·롤백 절차를 함께 남기는 것이다. 소음을 줄이는 목적은 보안 신호를 숨기는 것이 아니라, 실제로 고쳐야 할 위험을 더 빠르게 보이게 만드는 데 있다.