고정 헤더 영역
상세 컨텐츠
본문
반응형
Java 애플리케이션을 컨테이너 환경에서 안전하게 실행하려면 올바른 베이스 이미지를 선택하는 것이 중요
오늘날의 클라우드 네이티브 환경에서 Java 애플리케이션 보안
Java 애플리케이션을 보호하는 것은 단순히 우리가 작성하는 코드에만 국한되지 않는다. 컨테이너 전체 스택이 보안의 대상이 되어야 한다. Java는 오랫동안 강력한 보안성을 유지해 왔지만, Log4Shell과 같은 보안 사고는 지속적인 경계가 필요함을 보여주었다. 따라서 Java JRE 기반 컨테이너 이미지, Java 애플리케이션 종속성, 그리고 응용 프로그램 코드 자체까지 종합적인 취약점 예방 전략이 필요하다.
Java 컨테이너 이미지의 현황
작년에 한 클라이언트가 Node.js 컨테이너 베이스 이미지에서 발견된 보안 취약점에 대해 불만을 제기한 적이 있다. 이를 계기로 Java를 포함한 베이스 이미지 보안 연구를 시작하게 되었다.
오픈 소스 취약점 스캐너인 grype 를 활용해 인기 있는 Java 컨테이너 이미지를 분석한 결과는 충격적이었다.
✅ 대부분의 주요 공급업체의 베이스 이미지에는 다수의 취약점이 존재했다.
✅ 취약점 개수는 몇 개에서 수백 개까지 다양했다.
✅ 단 하나의 베이스 이미지만이 취약점이 없었다: "Chainguard의 JRE 베이스 이미지"
🔎 2025년 2월 7일 기준, 조사 결과는 다음과 같다. (이하 상세 결과 제공)
취약점 없는 Java 컨테이너: 실용 가이드
Java 애플리케이션을 컨테이너화할 때, 적절한 베이스 이미지 선택은 보안을 유지하는 데 핵심적인 역할을 한다.
1. Chainguard Java JRE 이미지 사용하기
현재 Chainguard의 JRE 베이스 이미지는 유일하게 취약점이 없는 Java 컨테이너 이미지라는 점을 감안하여 되도록이면, Chainguard Java JRE 이미지를 사용하는 것이 좋다.
✅ 최신 버전(23)은 무료로 제공되지만, 특정 Java 버전용 태그는 Chainguard 구독이 필요하다.
✅ 최신 Java JRE 버전을 사용할 수 있다면 Chainguard 이미지가 최적의 선택이다.
🔹만약 특정 Java 버전을 사용해야 하거나, Chainguard를 도입하기 어려운 경우, Amazon Corretto를 추천한다.
2년 이상 사용해본 결과 취약점이 적고 안정적인 베이스 이미지이고,
Chainguard와 동일한 방식으로 베이스 이미지로 사용 가능하다.
2. Java 컨테이너 빌드 옵션
Java 애플리케이션을 컨테이너화하는 방법에는 여러 가지가 있다.
1️⃣ 전통적인 Dockerfile
- 간단하지만 이미지 레이어가 비효율적이며, Docker 데몬 필요
2️⃣ Cloud Native Buildpacks
- 빌드팩을 통한 편리한 컨테이너화
- 하지만 베이스 이미지 커스텀화가 어려움
3️⃣ Google의 Jib (추천)
- Docker 데몬 없이 빌드 가능
- 효율적인 이미지 레이어링
- 유연한 베이스 이미지 선택 가능
📌 내 GitHub 데모 애플리케이션에서는 Jib을 기본 빌드 방법으로 사용하고,
📌 Dockerfile도 제공하여 필요 시 선택적으로 사용할 수 있다.
Jib의 이미지 레이어링이 어떻게 작동하는지 이해하려면 Dive를 사용하여, 컨테이너 이미지의 레이어를 검사하는 방법을 Demo 응용 프로그램의 README에서 참고하면 된다.
3. 취약점 없는 Java 컨테이너 빌드하기
🛠 Chainguard JRE 베이스 이미지 + Google Jib Maven 플러그인을 활용하여 Zero-Vulnerability Java 컨테이너를 만들자.
✅ Gradle 사용 시, Jib Gradle 플러그인도 동일하게 활용 가능
1️⃣ Jib 설정 (Maven 프로젝트 기준)
데모 애플리케이션에서 수행 한대로 Pom.xml에 다음 Jib Maven 플러그인 구성을 추가하여, Chainguard JRE를 베이스 이미지로 설정한다.
<from> <image>chainguard/jre:latest</image> </from>
📌 Dockerfile을 사용할 경우, 제공된 샘플 Dockerfile을 참고하면 된다.
2️⃣ 컨테이너 이미지 빌드
터미널에서 Maven Jib 명령어 실행하여 데모 응용 프로그램을위한 로컬 컨테이너 이미지를 작성 (Docker 필요)
./mvnw jib:dockerBuild
📌 Dockerfile을 사용할 경우, docker build 명령어를 실행하면 된다.
Jib 대신 Dockerfile을 사용하는 경우 Docker 빌드를 사용하여 컨테이너 이미지를 빌드하는 방법에 대한 추가 지침은 Demo Application의 ReadMe를 참조하십시오.
3️⃣ 취약점 검사 (Zero Vulnerability 확인)
📌 이제 이미지를 구축하면 grype를 사용하여 빌드된 이미지의 취약점을 스캔할 수 있습니다:
grype docker.io/your-id/your-image:latest
🔍 결과 예시: 최신 Chainguard Base 이미지와 모든 Maven 의존성이 업데이트되면 다음 결과가 표시됩니다.
✔ 패키지 74개 스캔 완료
✔ 파일 메타데이터 1,186개 확인
✔ 실행 파일 121개 검사
✅ 취약점 0개 발견 (No vulnerabilities found)
4. SBOM을 활용한 사전 취약점 탐지
컨테이너 빌드 후 검사하는 것보다, 개발 초기에 취약점을 탐지하면 더욱 효과적이다.
이를 위해 SBOM (Software Bill of Materials)을 생성하고 이를 스캔하면 애플리케이션 종속성의 보안 상태를 사전에 점검 가능하다.
✅ Maven 플러그인 추가 (SBOM 생성용): pom.xml에 다음 플러그인을 추가하십시오.
<plugin> <groupId>org.cyclonedx</groupId> <artifactId>cyclonedx-maven-plugin</artifactId> </plugin>
📌 CycloneDX는 응용 프로그램의 종속성 트리를 기반으로 SBOM을 구축하기위한 Maven 플러그인 (또는 Gradle 플러그인)을 제공합니다.
✅ Grype를 사용하여 컨테이너화 전에 응용 프로그램 종속성을 스캔 (SBOM을 활용한 취약점 검사)
grype target/classes/META-INF/sbom/application.cdx.json
🔍 결과 예시: SBOM과 Grype는 두 가지 고위험 취약점으로 Spring Boot 3.4.0에서 구식 Tomcat 버전을 발견했습니다.
✔ 취약점 4개 발견 (2 High, 1 Medium, 1 Low)
🔹 Tomcat 10.1.33 → 10.1.34 업데이트 필요
📌 SBOM 방식의 장점:
✔ 컨테이너 빌드 전에도 애플리케이션 종속성을 검사 가능
✔ 동일한 grype 도구를 활용하여 SBOM + 컨테이너 이미지 취약점 통합 검사 가능
SBOM 접근법의 멋진 점은 SBOM 및 이미지 모두에 대한 단일 취약점 스캔 도구를 표준화 할 수 있다는 것입니다. 일반적으로 Java의 경우 취약점 검사 도구가 컨테이너 이미지 스캔 도구와 분리되므로 단일 취약성 스캔 도구로의 통합이 유리할 수 있습니다.
결론
현재 Chainguard JRE는 유일한 Zero-Vulnerability Java 베이스 이미지이지만,
다른 이미지 제공업체들도 취약점 감소를 위해 지속적으로 개선 중이다.
✅ 안전한 Java 컨테이너를 만들기 위해 다음 전략을 따르자:
🔹 신중한 베이스 이미지 선택 (Chainguard JRE or Amazon Corretto)
🔹 정기적인 컨테이너 이미지 취약점 검사 (grype)
🔹 SBOM을 활용한 종속성 사전 검사
🔹 자동화된 종속성 업데이트 (예: Dependabot 사용)
🔹 최신 보안 취약점을 지속적으로 확인하고, 애플리케이션의 보안 상태를 점검하는 것이 중요하다.
원문출처: https://thenewstack.io/vulnerability-free-java-containers-a-practical-guide/
728x90
반응형
