[AWS re:Inforce 2025] Scale vulnerability management using Amazon Inspector

들어가며

클라우드 환경이 복잡해질수록 취약점의 수는 기하급수적으로 증가하며, 단순히 CVSS 점수에만 의존하는 우선순위 결정 방식은 한계에 부딪히고 있습니다. 저는 이번 Amazon Inspector 세션을 통해, 단순한 취약점 스캐너를 넘어, 네트워크 연결성, 실제 공격 가능성 등 컨텍스트를 이해하는 지능형 위험 평가 도구로 어떻게 진화하고 있는지 확인하고자 했습니다. 또한, 에이전트와 에이전트리스 방식의 유연한 결합, 그리고 CI/CD 파이프라인에 통합되어 개발 초기 단계부터 보안을 강화하는 ‘Shift Left’ 전략의 구체적인 구현 방안에 대한 깊이 있는 인사이트를 얻기를 기대했습니다.

진정한 위험 우선순위화 – CVSS를 넘어서는 컨텍스트 기반의 Inspector 점수

이번 세션의 첫 번째 핵심은 ‘우선순위화의 어려움’이라는 현실적인 문제에서 시작되었습니다. 수많은 취약점 알림 속에서 “이 취약점이 정말 우리 환경에서 공격 가능한가?”라는 질문에 답하는 것이 얼마나 어려운지를 지적하며, Amazon Inspector가 이를 어떻게 해결하는지에 집중했습니다. AWS는 단순한 취약점 목록이 아닌, 실제 위험에 기반한 실행 가능한 인사이트를 제공하는 것을 목표로 하고 있습니다.

“As a security professional, you do ask yourself these questions… Is the vulnerability exploitable? Is there a known exploit out in the wild for the vulnerability that I have in my environment?… This comes through into a set of Amazon Inspector risk scores, and that’s calculated for each finding by correlating vulnerability information with environmental context, such as the network exposure of that instance.”

(보안 전문가로서 당신은 이런 질문을 던집니다… 이 취약점이 공격 가능한가? 내 환경에 있는 이 취약점에 대해 실제로 알려진 공격 코드가 있는가? … 이러한 질문에 대한 답은 인스턴스의 네트워크 노출과 같은 환경적 컨텍스트와 취약점 정보를 상호 연관시켜 각 탐지에 대해 계산되는 ‘아마존 인스펙터 위험 점수’로 나타납니다.)

Inspector의 가장 큰 차별점은 바로 이 컨텍스트 기반의 위험 점수입니다. 세션에서는 이 점수가 어떻게 계산되는지 상세히 설명했습니다. Inspector는 단순히 CVE의 심각도 점수(CVSS)만을 보여주는 것이 아니라, 자동화된 추론(automated reasoning) 기술을 활용하여 해당 리소스의 네트워크 연결성을 분석합니다. 즉, 취약점이 존재하는 EC2 인스턴스가 실제로 인터넷이나 다른 VPC로부터 접근 가능한 경로를 가지고 있는지를 판단합니다.

여기에 더해, CISA의 알려진 악용 취약점 카탈로그(KEV), 악성코드 키트 정보, 파트너사의 위협 인텔리전스 등을 종합하여 실제 공격에 악용되고 있는지(exploitability)에 대한 정보를 결합합니다. 예를 들어, CVSS 점수가 9.8점으로 매우 높은 취약점이라도, 해당 인스턴스가 외부로부터 완전히 격리되어 네트워크 경로가 없다면 Inspector의 위험 점수는 이보다 낮게 조정될 수 있습니다. 반대로, CVSS 점수는 중간 수준이라도 현재 널리 악용되는 공격 코드가 존재하고 네트워크에 노출되어 있다면, Inspector는 이를 더 높은 위험으로 평가하여 우선적으로 처리하도록 안내합니다. 이는 보안팀이 수많은 경고 속에서 ‘가로등 효과(Streetlight Effect)’에 빠지지 않고, 정말 중요한 비즈니스 위험에 집중할 수 있도록 돕는 매우 실질적인 기능입니다.

‘항상 켜져 있는’ 자동화된 보안 – 하이브리드 스캔과 지속적인 모니터링

두 번째 핵심 주제는 취약점 관리의 ‘지속성’과 ‘자동화’였습니다. 일회성 또는 정기적인 스캔만으로는 빠르게 변화하는 클라우드 환경의 모든 자산과 새로운 위협을 놓칠 수밖에 없습니다. AWS는 “보안 데이터는 여러분에게 자동으로 찾아가야 한다”는 철학을 바탕으로, Inspector의 지속적이고 자동화된 스캔 기능의 중요성을 강조했습니다.

“We strongly believe that the data should come to you automatically… Without you taking an action, we will automatically create a finding for the vulnerability that got published this morning in our database… you do not need to continuously keep coming back to run a scan. It’s very important for us to all anchor on this, the benefits of having continuous scanning.”

(우리는 데이터가 여러분에게 자동으로 전달되어야 한다고 강력히 믿습니다… 오늘 아침 우리 데이터베이스에 새로운 취약점이 공개되었을 때, 여러분이 아무런 조치를 취하지 않아도 우리는 자동으로 탐지 결과를 생성할 것입니다… 스캔을 실행하기 위해 계속해서 돌아올 필요가 없습니다. 지속적인 스캐닝의 이점에 우리 모두가 집중하는 것이 매우 중요합니다.)

Inspector의 강력한 기능 중 하나는 자동화된 리소스 발견(Automated Discovery)입니다. 새로운 EC2 인스턴스가 시작되거나, ECR에 새 컨테이너 이미지가 푸시되거나, 새로운 Lambda 함수가 배포되면 Inspector는 이를 자동으로 인지하고 스캔을 시작합니다. 이는 수동 작업으로 인한 관리 공백을 원천적으로 제거합니다.

특히 인상 깊었던 것은 하이브리드 스캔 모드(Hybrid Scan Mode)였습니다. 이는 에이전트(SSM Agent)와 에이전트리스(Agentless) 방식을 유연하게 결합한 것입니다. EC2 인스턴스에 SSM 에이전트가 설치되어 있다면, 에이전트를 통해 효율적으로 소프트웨어 인벤토리를 수집합니다. 만약 에이전트를 설치할 수 없거나, 아직 배포 중이거나, 지원되지 않는 OS인 경우에도 Inspector는 포기하지 않고, EBS 스냅샷을 활용한 에이전트리스 스캔 모드로 자동 전환하여 모든 EC2 인스턴스에 대한 커버리지를 보장합니다. 이 모든 과정은 고객 계정 내에서 안전하게 처리되며 데이터가 외부로 유출되지 않는다는 점도 강조되었습니다.

또한, Inspector의 스캔은 단순히 정해진 시간에만 수행되는 것이 아니라, 이벤트 기반 휴리스틱(Event-triggered Heuristics)에 따라 지능적으로 작동합니다. 새로운 소프트웨어 패키지가 설치되거나, 새로운 CVE가 공개되거나, 네트워크 구성이 변경되는 등 의미 있는 이벤트가 발생했을 때 스캔을 트리거하여 리소스를 효율적으로 사용하면서도 신속하게 위협을 탐지합니다. AWS Organizations와의 연동을 통한 원클릭 활성화 및 중앙 집중식 관리는 대규모 엔터프라이즈 환경에서 일관된 보안 정책을 적용하는 데 있어 필수적인 기능임이 분명해 보였습니다.

개발부터 운영까지 – 확장된 가시성과 Shift Left 보안

마지막으로 세션은 취약점 관리의 범위를 EC2를 넘어 Lambda, ECR(컨테이너), 그리고 CI/CD 파이프라인까지 확장하는 방법을 다루었습니다. 이는 보안을 개발 생명주기(SDLC)의 왼쪽, 즉 초기 단계로 이동시키는 ‘Shift Left’ 철학의 구체적인 구현 방안을 제시한 것입니다.

“In addition to identifying your software vulnerabilities in the operating system, we will also identify vulnerabilities in the application programming packages, such as Python, Java, JS, etc. … and it is at no additional cost.”

(운영체제의 소프트웨어 취약점을 식별하는 것 외에도, 우리는 Python, Java, JS 등과 같은 애플리케이션 프로그래밍 패키지의 취약점도 식별할 것입니다…
그리고 여기에는 추가 비용이 없습니다.)

주목할 만한 기능 중 하나는 심층 검사(Deep Inspection)입니다. 이는 Linux 기반 EC2 인스턴스에 대해 OS 패키지뿐만 아니라 Python, Java, Node.js 등 애플리케이션 프로그래밍 패키지의 취약점까지 추가 비용 없이 스캔하는 기능입니다. 이는 소프트웨어 공급망 보안의 가시성을 크게 향상시킵니다. 이와 더불어, Inspector는 스캔된 리소스의 소프트웨어 자재 명세서(SBOM)를 Cyclone DX, SPDX 등 표준 형식으로 내보내는 기능을 제공합니다. 이를 통해 조직은 소프트웨어 구성 요소를 투명하게 관리하고 규제 요구사항에 대응할 수 있습니다.

또한, Jenkins, TeamCity, GitHub Actions 등 주요 CI/CD 도구와의 네이티브 플러그인 연동을 통해 개발자가 컨테이너 이미지를 빌드하는 단계에서부터 취약점을 스캔하고, 기준을 충족하지 못하면 빌드를 중단시키는 ‘보안 게이트’ 역할을 수행할 수 있습니다. Lambda에 대해서도 서드파티 패키지 취약점을 스캔하는 ‘표준 스캐닝’을 넘어, 개발자가 작성한 코드 자체의 보안 취약점(예: 인젝션 결함, 데이터 유출)을 탐지하고 수정 코드 스니펫까지 제안하는 ‘코드 스캐닝’ 기능을 제공하는 점도 인상 깊었습니다.

마지막으로, 최근에 추가된 가장 강력한 기능 중 하나는 ECR 이미지와 EKS 파드 간의 자동 매핑입니다. ECR에서 취약한 컨테이너 이미지가 발견되었을 때, 클릭 한 번으로 해당 이미지가 현재 어느 EKS 클러스터의 어떤 파드에서 실행되고 있는지 즉시 확인할 수 있게 된 것입니다. 이는 운영팀이 취약점의 영향을 신속하게 파악하고, 교체 배포를 진행하는 데 걸리는 시간을 획기적으로 단축시켜주는 매우 실용적인 기능입니다.

결론

이번 Amazon Inspector 세션은 현대적인 클라우드 취약점 관리가 나아가야 할 방향을 명확하게 보여주었습니다. 제가 얻은 가장 큰 인사이트는 취약점 관리가 더 이상 ‘발견’의 영역에 머무르지 않고, ‘컨텍스트 기반의 위험 평가’와 ‘자동화된 라이프사이클 관리’로 진화하고 있다는 점입니다. 단순히 많은 취약점을 찾는 것이 중요한 것이 아니라, 그중에서 정말로 우리 비즈니스에 위협이 되는 것을 식별하고, 개발 초기부터 운영까지 전 단계에 걸쳐 이를 효율적으로 관리하는 것이 핵심입니다.

Inspector의 컨텍스트 기반 위험 점수, 하이브리드 스캔 모드, 그리고 CI/CD 및 EKS와의 긴밀한 통합은 이러한 진화의 구체적인 결과물입니다. 특히, 개발자들이 보안을 ‘장애물’이 아닌, ‘더 나은 코드를 작성하기 위한 도구’로 인식하게 만드는 Shift Left 접근 방식과, ECR-EKS 매핑처럼 운영팀의 실질적인 고충을 해결해 주는 기능들은 매우 인상 깊었습니다.

결론적으로, Amazon Inspector는 이제 단순한 스캐너를 넘어, 조직의 전체 클라우드 환경에 대한 지속적인 가시성을 제공하고, 리소스의 전 생애에 걸쳐 보안을 내재화하며, AI와 자동화된 추론을 통해 보안팀이 가장 중요한 위협에 집중할 수 있도록 지원하는 지능형 보안 형상 관리 플랫폼으로 자리매김하고 있다고 생각합니다. 이번 세션은 우리와 같은 보안 전문가들이 고객에게 어떻게 더 높은 수준의 가치를 제공할 수 있을지에 대한 깊은 영감과 실질적인 방법론을 얻을 수 있는 귀중한 시간이었습니다.

글 │메가존클라우드, HALO, Cloud Security, 김진호 Unit Leader

AWS re:inforce 테크 블로그│모두 보기 👀

이번 AWS re:inforce 테크 블로그는 총 3 편으로 준비하였으니 다른 콘텐츠도 함께 즐겨보세요!