안녕하세요. GS Neotek 조 길상 입니다.2026년 11월 2일, AWS가 Amazon Inspector의 EC2 AMI 취약점 스캔을 공개했습니다. 전에도 Inspector로 AMI를 점검하려면 그 AMI로 인스턴스를 띄우고 에이전트를 설치해 스캔하는 방식이었습니다.이번 기능은 인스턴스를 띄우지 않고 AMI를 뒷받침하는 EBS 스냅샷을 직접 읽어 취약점을 찾습니다. 골든 AMI를 쓰는 환경에서 “배포하기 전에” 이미지의 취약점을 잡을 수 있다는 점이 핵심이어서, 서울 리전 테스트 계정에서 직접 켜 보고 어디까지 되는지 확인했습니다. 한눈에 보기 항목내용기능Amazon Inspector EC2 AMI 취약점 스캔(인스턴스 실행·에이전트 설치 불필요)동작 방식AMI를 뒷받침하는 EBS 스냅샷에서 소프트웨어 인벤토리를 읽어 취약점 데이터와 대조두 가지 방식1. 연속 평가(계정에 활성화, 콘솔에서 결과 조회)2. 온디맨드 1회 스캔(활성화 불필요, 결과는 EventBridge)리전상용 리전 전체(서울 포함). GovCloud·중국 미지원전제본인 계정이 소유한 AMI만. EBS 기반·단일 OS·ext3/ext4/ntfs/xfs(LVM 미지원)결과 시점활성화 후 자동 발견·스캔. 이번 측정은 ACTIVE까지 약 7분 30초 참고: 발표, EC2 사용 설명서, Inspector 사용 설명서, 요금 1. 테스트 준비 – 취약한 AMI와 패치된 AMI 스캔이 실제로 취약점을 잡는지 보려면 비교 대상이 있어야 합니다.같은 Amazon Linux 2023을 베이스로, 패치 여부만 다른 AMI 두 개를 만들었습니다. AMI구성취약 AMI구버전 언어 패키지(log4j-core 2.14.1, pip·setuptools 구버전) 설치, dnf update 생략패치 AMI같은 베이스에 dnf update -y로 전부 최신화 두 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건이 나왔습니다.패치 여부 하나로 결과가 이렇게 갈린다는 점이 분명하게 보였습니다. 심각도건수대표 CVECritical2CVE-2021-44228(Log4Shell), CVE-2021-45046High4log4j-core, setuptools 취약점Medium12log4j, pip, setuptoolsLow3pip, setuptools 각 취약점은 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 보안 상태를 배포 전에 일관되게 점검하는 흐름을 만들 수 있는 기능으로...