서비스를 Docker 이미지로 묶고 보안 스캔을 돌리면 보고서가 온통 빨간색인 경우가 많다. 베이스 이미지에 알려진 취약점이 있고, 패키지 버전이 낡았고, Dockerfile 작성 방식에 문제가 있고, 컨테이너 권한이 너무 넓다. 오픈소스 도구 DockSec은 바로 이런 보고서를 다루려고 만든 도구로, 2026년 5월 보도에 따르면 OWASP(웹 애플리케이션 보안을 다루는 국제 오픈 프로젝트)의 인큐베이터 프로젝트로 채택됐다. 로컬에서 Trivy, Hadolint, Docker Scout 같은 스캐너를 돌리고, 중복 경고를 합치고, 심각도와 악용 가능성으로 순서를 매긴 뒤, AI로 문제마다 설명하고 고치는 방법을 내놓는다.
이 도구에서 가장 참고할 만한 것은 스스로 그은 선이다. 프로젝트 설명에 따르면 자동 수정은 Dockerfile의 기계적인 수정만 적용하고, 먼저 백업을 남기고, 고친 뒤 다시 스캔한다. 베이스 이미지 버전을 고르지 않고, 비밀 값을 옮기지 않고, 배포용 설정 파일을 고치지 않는다. 커밋하지 않은 변경이 있는 파일은 강제하지 않는 한 고치기를 거부한다.
팀도 같은 선을 쓸 수 있다. 잘못돼도 알아채기 쉽고 되돌리기 쉬운 기계적인 수정은 AI에게 맡겨도 된다. 베이스 이미지를 바꾸거나, 실행 권한을 바꾸거나, 배포 설정을 바꾸는 것처럼 컨테이너의 동작을 바꾸는 결정은 사람이 시험하고 승인한다.
한 줄 수정이라도 영향은 그 한 줄보다 넓을 때가 많다
AI는 취약점 설명을 쉬운 말로 풀고, 한 줄짜리 업그레이드 명령까지 붙여 준다. 수고를 덜어 주는 것처럼 보인다. 하지만 컨테이너 안의 변경은 그 한 줄보다 훨씬 넓게 영향을 미치는 경우가 많다. 베이스 이미지 버전을 바꾸면 수십 개의 시스템 패키지가 한꺼번에 바뀌어 이미 검증한 동작이 달라질 수 있다. 컨테이너를 root가 아닌 사용자로 실행하게 바꾸면 서비스가 어떤 디렉터리를 읽지 못해 시작에 실패할 수 있다.
이런 문제는 스캔 보고서에 나오지 않는다. 실제로 돌려 봐야 안다. DockSec이 베이스 이미지 버전을 대신 고르지 않는 것도 그 선택에는 서비스에 대한 이해와 시험이 필요하기 때문이다.
먼저 나누고, 누가 손댈지 정한다
기계적인 수정: 예를 들어 Dockerfile 작성 방식 제안, 불필요한 패키지 캐시 삭제, 버전 태그 고정. 잘못되면 빌드 실패나 변경 내역에서 쉽게 보이므로 AI에게 고치게 해도 된다. 단 변경 내역이 보이고 되돌릴 수 있어야 한다.
동작을 바꾸는 수정: 베이스 이미지 교체, 주요 시스템 패키지 업그레이드, 컨테이너 실행 사용자 변경, 외부에 여는 포트 변경. 이런 것은 테스트 환경에서 돌려 보고 서비스 담당자가 승인한다.
데이터 경계: AI 설명을 켜기 전에 무엇이 나가는지 알아 둔다. DockSec 설명에 따르면 AI 모드에서는 Dockerfile이나 배포 설정 파일의 내용과 취약점 개수 요약이 모델로 간다. 비밀 값처럼 보이는 것은 기본적으로 가려진다. Dockerfile에 밖으로 나가면 안 되는 내부 주소나 설정이 있다면, AI를 부르지 않는 스캔 전용 모드나 로컬에서 도는 모델을 쓴다.
경고가 많다면 먼저 실제로 닿는지 본다
스캔 결과에 있는 취약점이 서비스 실행 중에 쓰인다는 보장은 없다. 순서를 정할 때는 밖에서 이미 악용되고 있는지, 서비스가 그 코드를 실행하는지, 외부 입력이 닿는지를 먼저 묻는다. 취약점 순서는 점수만 보지 말고 실행 경로와 외부 입력부터 확인한다를 참고하자. 순서를 정한 뒤 AI가 만든 수정을 배포해도 되는지는 문제가 생겼을 때 되돌릴 수 있느냐에 달렸다. AI는 취약점 패치를 쓸 수 있다, 배포할 수 있는지는 문제가 생겼을 때 되돌릴 수 있느냐에 달렸다를 참고하자.
도구가 그은 선도 자기 서비스에 맞춰 다시 판단한다
DockSec은 개인이 만든, 아직 인큐베이션 단계의 오픈소스 프로젝트라서 기능과 기본값이 바뀔 수 있다. 이 글이 인용한 것은 지금 공개된 설명이니, 도입 전에는 프로젝트의 최신 문서를 확인한다. 도구가 그은 선은 참고가 되지만, 무엇을 “기계적"으로 볼지는 여전히 자기 서비스를 기준으로 판단해야 한다. 같은 한 줄 수정도 서비스에 따라 위험이 완전히 다를 수 있다.
AI 정리 카드
Docker 이미지 스캔에서 경고가 대량으로 나왔다. AI의 도움을 받아 정리하되, AI에게 고치게 해도 되는 수정과 사람이 승인해야 하는 수정의 선을 분명히 하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/docker-ai-security-scanner-human-fix-gate/
글의 관점은 이렇다. 잘못돼도 알아채기 쉽고 되돌리기 쉬운 기계적인 수정은 AI에게 맡겨도 된다. 베이스 이미지 교체, 실행 권한 변경, 배포 설정 변경처럼 컨테이너의 동작을 바꾸는 결정은 사람이 시험하고 승인한다. AI 설명을 켜기 전에 어떤 파일 내용이 모델로 가는지 알아 둔다.
내가 허락한 Dockerfile, 배포 설정, 스캔 보고서만 읽기 전용으로 살펴 달라. 파일을 고치거나 빌드를 돌리지 말 것.
1. 경고를 출처별로 나눌 것. 베이스 이미지, 패키지, Dockerfile 작성 방식, 실행 권한이나 외부 포트;
2. 각 수정 제안을 "기계적인 수정"과 "동작을 바꾸는 수정"으로 나누고 이유를 적을 것;
3. Dockerfile과 설정에 내부 주소나 비밀 값처럼 외부 모델로 보내면 안 되는 내용이 있는지 확인하고, 스캔 전용 모드와 로컬 모델 중 무엇을 쓸지 권할 것;
4. 동작을 바꾸는 수정에 대해 테스트 환경에서 확인할 항목과 승인자를 적을 것.
베이스 이미지 버전은 나 대신 고르지 말 것. 후보와 시험할 점만 적을 것.
참고 자료
- GitHub (official OWASP project): OWASP/DockSec — https://github.com/OWASP/DockSec [accessed: 2026-10-11]
- Open Source For You: OWASP-Backed Open Source DockSec Uses LLMs To Fix Docker Vulnerabilities Faster — https://www.opensourceforu.com/2026/05/owasp-backed-open-source-docksec-uses-llms-to-fix-docker-vulnerabilities-faster/ (2026-05-27)
- Docker Docs (official): Docker Scout — https://docs.docker.com/scout/ [accessed: 2026-10-11]
