Container 환경에서는 Application 코드뿐만 아니라 Container Image 자체의 보안도 중요합니다.
많은 서버 운영자는 Container가 정상적으로 실행되는지만 확인하지만, 실제 공격은 Image 내부의 취약점을 통해 발생할 수 있습니다.
기본 구조:
Docker Image
↓
취약점 존재
↓
Container 실행
↓
공격 발생예:
오래된 OS Package
↓
CVE 취약점
↓
Container 공격이를 방지하기 위해 배포 전 Container Security Scan 과정이 필요합니다.
보안 구조:
Source Code
↓
Docker Build
↓
Security Scan
↓
Registry Push
↓
Production Deploy이번 글에서는 Docker Compose 환경에서 Container Security Scan 개념부터 Image 취약점 검사, CI/CD 자동화, Runtime 보안, Production 보안 운영 전략까지 알아보겠습니다.
Container Security Scan이란?
Container Security Scan은 Docker Image 내부의 취약점을 검사하는 과정입니다.
검사 대상:
OS Package
↓
Library
↓
Application Dependency
↓
Configuration확인:
- CVE 취약점
- 오래된 Package
- 위험한 설정
- 보안 권고사항
Docker Image 취약점이 발생하는 이유
Container Image는 여러 Layer로 구성됩니다.
구조:
Application Layer
↓
Library Layer
↓
OS Layer하나의 Layer라도 취약하면 전체 Image가 영향을 받을 수 있습니다.
예:
Ubuntu Base Image
↓
취약 Package 포함
↓
Container 위험Docker Compose Security Scan 흐름
안전한 배포 과정:
Developer
↓
Git Commit
↓
Docker Build
↓
Security Scan
↓
Pass
↓
Registry Push
↓
Deploy취약점 발견:
Scan Failed
↓
배포 차단대표적인 Container Security Scan 도구
대표 도구:
Trivy
가장 많이 사용하는 Container Scanner
검사:
- Docker Image
- Filesystem
- Repository
- Kubernetes
예:
trivy image nginx:latest결과:
CRITICAL
HIGH
MEDIUMDocker Compose Trivy 사용 방법
Image 검사:
trivy image my-app:v1.0확인:
취약점 이름
영향 Package
해결 Version예:
openssl 취약점
↓
업데이트 필요Docker Scout Security Scan
Docker 공식 보안 분석 도구입니다.
확인:
- Image 취약점
- Base Image 상태
- 권장 업데이트
구조:
Docker Image
↓
Docker Scout
↓
Security ReportDocker Compose CI/CD Security Scan 자동화
Production에서는 사람이 직접 검사하면 놓칠 수 있습니다.
자동화 구조:
Git Push
↓
CI Pipeline
↓
Docker Build
↓
Security Scan
↓
Deploy예:
취약점 발견
↓
Build 실패
↓
배포 중단GitHub Actions Container Scan 구성
흐름:
Code Push
↓
GitHub Actions
↓
Trivy Scan
↓
Result 확인조건:
Critical 취약점 존재
↓
Deploy 차단Docker Compose Image 보안 관리
안전한 Image 관리:
좋은 방식:
app:v1.0.0
app:v1.1.0나쁜 방식:
app:latest이유:
- Version 추적 어려움
- Rollback 어려움
Docker Compose Base Image 보안
Base Image 선택도 중요합니다.
비추천:
오래된 Ubuntu Image권장:
공식 최신 LTS Image또는:
Minimal Image
↓
Attack Surface 감소Docker Compose Dependency Scan
Application Library도 검사해야 합니다.
예:
Node.js:
npm PackagePython:
pip PackageJava:
Maven Dependency구조:
Application
↓
Dependency Scan
↓
취약점 확인Docker Compose Secret Scan
Image 내부에 Secret이 포함되면 위험합니다.
위험:
API Key
Password
Token검사:
- Git Secret Scan
- Image Secret Scan
구조:
Code
↓
Secret Scan
↓
배포 허용Docker Compose Runtime Security와 연결
Security Scan은 배포 전 검사입니다.
하지만 실행 후 보호도 필요합니다.
구조:
Before Deploy
↓
Security Scan
After Deploy
↓
Runtime SecurityRuntime:
- 비정상 Process 탐지
- 권한 상승 탐지
- 파일 변경 감지
Docker Compose Security Scan과 Registry 운영
Private Registry 환경:
구조:
Developer
↓
Build
↓
Scan
↓
Private Registry
↓
Production장점:
- 안전한 Image만 저장
- 접근 제어
- Version 관리
Docker Compose Production Security Pipeline
기업 환경:
Developer
↓
Git Repository
↓
CI/CD
↓
Docker Build
↓
Security Scan
↓
Registry
↓
Production Server
↓
Runtime MonitoringContainer Security Scan Best Practice
추천:
배포 전 검사
CI/CD 단계 자동화
Critical 취약점 차단
위험 Image 배포 금지
정기 검사
운영 Image 재검사
Base Image 관리
최신 보안 업데이트 유지
Secret 보호
민감 정보 제거
자주 묻는 질문
Security Scan은 언제 해야 하나요?
Docker Image Build 이후 배포 전에 실행하는 것이 좋습니다.
취약점이 있으면 무조건 사용하면 안 되나요?
위험 수준과 영향 범위를 확인해야 합니다.
Docker Compose에서도 자동 보안 검사가 가능한가요?
가능합니다.
CI/CD Pipeline에 연결할 수 있습니다.
Image Scan과 Runtime Security 차이는 무엇인가요?
Image Scan은 배포 전 검사, Runtime Security는 실행 중 보호입니다.
마무리
Docker Compose Container Security Scan은 안전한 Container 운영을 위한 필수 과정입니다.
최종 구조:
Code
↓
Docker Image
↓
Security Scan
↓
Registry
↓
Deploy
↓
Runtime ProtectionProduction 서버에서는 빠른 배포보다 안전한 배포 구조가 중요합니다.
Container Security Scan을 CI/CD에 연결하면 취약한 Image가 운영 환경으로 들어가는 것을 방지할 수 있습니다.
다음 글에서는 Database Password, API Key, Certificate 같은 민감 정보를 안전하게 관리하는 Docker Compose Secrets Manager 운영 방법을 알아보겠습니다.