Amazon Inspector로 EC2 AMI 취약점 스캔하기 – 인스턴스 안 띄우고 배포 전에 잡아 보기

작성자 조 길상 작성일 11월 3, 2026 조회수 23

안녕하세요. GS Neotek 조 길상 입니다.
2026년 11월 2일, AWS가 Amazon Inspector의 EC2 AMI 취약점 스캔을 공개했습니다.

전에도 Inspector로 AMI를 점검하려면 그 AMI로 인스턴스를 띄우고 에이전트를 설치해 스캔하는 방식이었습니다.
이번 기능은 인스턴스를 띄우지 않고 AMI를 뒷받침하는 EBS 스냅샷을 직접 읽어 취약점을 찾습니다.

골든 AMI를 쓰는 환경에서 “배포하기 전에” 이미지의 취약점을 잡을 수 있다는 점이 핵심이어서, 서울 리전 테스트 계정에서 직접 켜 보고 어디까지 되는지 확인했습니다.

한눈에 보기

참고: 발표, EC2 사용 설명서, Inspector 사용 설명서, 요금

1. 테스트 준비 – 취약한 AMI와 패치된 AMI

스캔이 실제로 취약점을 잡는지 보려면 비교 대상이 있어야 합니다.
같은 Amazon Linux 2023을 베이스로, 패치 여부만 다른 AMI 두 개를 만들었습니다.

두 AMI를 만들 때만 인스턴스를 잠깐 띄웠고, AMI를 구운 뒤에는 바로 종료했습니다.
이후 스캔하는 동안에는 실행 중인 인스턴스가 한 대도 없었습니다.

2. AMI 스캔 켜기

Inspector에서 AMI 스캔을 활성화하면, 계정이 소유한 AMI를 자동으로 찾아 스캔을 시작합니다.
활성화 직후 우리 AMI 두 개가 발견되어 인벤토리를 수집했고(PENDING_INITIAL_SCAN), 약 7분 30초 뒤 두 AMI 모두 ACTIVE(스캔 완료) 상태가 되었습니다.
참고로 생성한 지 오래된 기존 AMI는 스캔 대상 기간을 벗어나 자동으로 제외(SCAN_ELIGIBILITY_EXPIRED)되었습니다.

처음 켜면 머신 이미지 스캔 15일 무료 체험이 적용된다는 안내도 함께 표시됩니다.

3. 결과 – 취약 AMI 21건, 패치 AMI 0건

취약 AMI에서 21건의 취약점이 나왔습니다.
같은 베이스에 패치만 적용한 AMI에서는 0건이 나왔습니다.
패치 여부 하나로 결과가 이렇게 갈린다는 점이 분명하게 보였습니다.

각 취약점은 OS 패키지뿐 아니라 Java의 log4j, Python의 pip·setuptools 같은 언어 패키지까지 짚어 주었습니다.
대표적으로 Log4Shell(CVE-2021-44228)은 설치된 버전 2.14.1과 올려야 할 버전 2.15.0을 함께 알려 주었고, Inspector 점수 10점에 EPSS(악용 가능성 예측 점수)도 0.99999로 매우 높게 표시되었습니다.

각 finding의 Resource type은 MACHINE_IMAGE였고, 영향받은 인스턴스 수(affected instances)는 0이었습니다.
인스턴스를 띄우지 않고 AMI만으로 점검한다는 설명이 결과에서도 그대로 확인되었습니다.

4. 좋았던 점 / 아쉬웠던 점

좋았던 점입니다.

• 1. 인스턴스를 띄우지 않아도 됩니다.
  AMI를 굽는 순간만 인스턴스가 필요했고, 스캔 내내 실행 중인 인스턴스는 0대였습니다.
• 2. 언어 패키지까지 봅니다.
  OS 패키지뿐 아니라 log4j(Java)·pip·setuptools(Python)처럼 애플리케이션 의존성에 숨은 취약점까지 짚어 주었습니다.
• 3. 올려야 할 버전을 알려 줍니다.
  Log4Shell에 “2.14.1 → 2.15.0″처럼 수정 버전을 바로 제시해, 조치로 이어가기 쉬웠습니다.
• 4. 패치 효과가 숫자로 보입니다.
  같은 베이스에서 패치 AMI는 0건, 취약 AMI는 21건이라, “패치하면 깨끗해진다”가 결과로 증명되었습니다.

아쉬웠던 점입니다.

• 오래된 AMI는 스캔 대상 기간을 벗어나 자동으로 제외될 수 있었습니다. 오래 방치된 골든 AMI를 점검하려면 스캔 대상 설정을 함께 확인하는 것이 필요할 수 있습니다.
• 신규 기능이라 로컬에 설치된 CLI 버전에 따라 일부 옵션이 아직 안 보일 수 있었습니다. 실제 API는 동작했지만, 콘솔이나 최신 도구로 확인하는 것이 안전해 보였습니다.
• 이번 소요 시간(약 7분 30초)은 8GB AMI 한 개 기준의 1회 측정값입니다. 더 큰 AMI나 여러 개를 함께 스캔하면 달라질 수 있습니다.

5. 정리

AMI 스캔은 취약점을 “인스턴스가 떠 있는 운영 단계”가 아니라 “배포 전 이미지 단계”에서 잡게 해 주는 기능이었습니다.
골든 AMI로 오토 스케일링을 돌리는 환경이라면, 취약한 이미지가 플릿 전체로 퍼지기 전에 한 번 걸러 주는 장치로 쓸 수 있겠습니다.

스캔 결과를 바탕으로 Allowed AMIs 설정과 묶으면, 기준 심각도를 넘는 AMI는 아예 인스턴스로 못 뜨게 막는 것도 가능합니다.
운영 관점에서는 AWS 계정의 AMI 보안 상태를 배포 전에 일관되게 점검하는 흐름을 만들 수 있는 기능으로 보입니다.