AWS Security Hub의 Inventory → SBOM에서 프로그램명과 버전을 검색하면, 해당 패키지가 발견된 자원으로 이동할 수 있다. 이 기능은 전체 서버를 실시간으로 뒤지는 것이 아니라, Inspector가 만든 최신 소프트웨어 목록을 모아 보여준다. 전제는 해당 계정·리전의 Security Hub 활성화와 자원 유형별 Amazon Inspector 스캔이다.[1][2]
M1은 2026년 11월 6일 개인정보 유출을 밝혔다.[4] Doctor Anywhere도 같은 날 개인정보 유출을 밝혔다고 스트레이츠타임스가 회사 발표를 인용해 보도했다.[5]
두 사고의 상세 원인은 해당 공개 자료에서 확인되지 않으며, 아래 기능과의 인과관계도 확인되지 않았다.[4][5] 이 글은 사고 분석이 아니라, AWS 공식 문서에 나온 ‘어떤 프로그램과 버전이 어느 자원에 있는지’ 확인하는 경로를 다룬다.
검색 전에 계정·리전에서 무엇을 확인해야 할까?
확인할 계정과 리전에서 Security Hub가 켜져 있고, 찾으려는 자원 유형에 Inspector 스캔이 활성화돼 있어야 한다. 문서의 ‘추가 설정 불필요’는 이 전제가 충족되면 SBOM 인벤토리를 위해 별도 수집 설정을 할 필요가 없다는 뜻이다. Security Hub만 켜면 모든 프로그램이 자동으로 잡힌다는 의미는 아니다.[2]
먼저 조회하려는 계정·리전과 스캔 대상이 맞는지 확인한다. EC2만 스캔하고 Lambda는 스캔하지 않는다면 인벤토리에는 EC2에서 수집된 소프트웨어만 나타난다. 검색창에 이름을 넣기 전에, 찾으려는 자원이 수집 범위 안에 있는지부터 맞추는 순서다.[2]
계정의 가시성도 다르다. 관리자 계정은 조직에서 활성화된 계정들의 소프트웨어를 볼 수 있지만, 멤버 계정은 자기 계정 자원의 소프트웨어만 볼 수 있다. 따라서 한 멤버 계정의 검색 결과를 조직 전체 설치 현황으로 읽으면 안 된다.[2]
서버와 컨테이너를 모두 같은 대상으로 보면 될까?
EC2 인스턴스, ECR에 저장된 컨테이너 이미지, Lambda 함수는 구분해서 봐야 한다. AWS 공지는 이 자원들에 대해 Inspector가 생성한 SBOM을 Security Hub가 집계한다고 설명한다. 여기서 SBOM은 소프트웨어 구성 목록, 즉 자원에 어떤 프로그램과 버전이 있는지 정리한 목록이다.[1][2]
| 확인 기준 | EC2 | ECR | Lambda |
|---|---|---|---|
| AWS 측 대상 | 인스턴스 | 저장된 컨테이너 이미지 | 함수 |
| 수집 전제 | 해당 유형 Inspector 스캔 | 해당 이미지 Inspector 스캔 | 해당 유형 Inspector 스캔 |
| 결과의 기준 | Inspector가 생성한 자원별 최신 SBOM | ||
표의 대상과 수집 기준은 AWS 공식 문서에 따른다.[1][2][6] 특히 ECR 이미지 목록은 실행 중인 모든 컨테이너 내부의 현재 상태 목록이 아니다. Inspector 문서도 ECR에 저장된 이미지 스캔과 ECS·EKS 실행 컨테이너 매핑을 별도로 설명한다. 이미지를 찾았다는 사실과 현재 실행 환경을 확인했다는 판단을 섞지 않아야 한다.[6]
프로그램명과 버전은 어디에서 검색할까?
Security Hub 콘솔의 Inventory 아래에서 SBOM을 열고 패키지명과 버전으로 필터링한다. 패키지 표에는 Package, Version, Package type, Resources 열이 있으며, 패키지와 버전 조합별로 행이 만들어진다. 문서가 제공하는 검색 단위는 막연한 서버 이름이 아니라 이 패키지 정보다.[2]
예를 들어 확인할 프로그램의 패키지명을 Package 조건에 넣고, 특정 버전의 위치가 필요하면 Version 조건을 함께 지정한다. 이후 Account, Region, Resource type 조건으로 확인 범위를 좁힌다. 이는 문서에 있는 필터를 적용하는 설명이며, 특정 계정에서 얻은 검색 결과를 제시하는 것은 아니다.[2]
프로그램명만으로 범위를 잡았다면 표의 Version 열을 함께 읽는다. 같은 이름이라도 버전이 다르면 다른 행으로 나타나므로, 원하는 버전의 행에서 다음 단계로 이동해야 한다. 계정·리전·자원 유형별로 묶어 볼 수도 있고, 반복해서 쓰는 필터 조합은 필터 세트로 저장할 수 있다.[2]
상단 요약 차트의 숫자와 표의 행 수는 뜻이 다르다. 문서의 예시에서 openssl 3.1.4가 세 자원에 설치돼 있으면 표에는 한 행으로 표시되지만, 차트에서는 세 번의 설치로 계산한다. Resources는 그 패키지가 발견된 자원 수이므로 프로그램 종류 수와도 구분해야 한다.[2]
검색한 버전이 어느 자원에 있는지는 어떻게 찾을까?
해당 행의 패키지명 또는 Resources 수를 선택하면 그 패키지를 포함한 자원 목록으로 이동한다. 그 목록에서 자원을 선택해 상세 패널을 열면 자원의 중요도, 관련 findings, 설치 소프트웨어를 확인할 수 있다. 이름과 버전을 찾은 뒤 설치 위치로 연결되는 경로다.[2]
여기서는 패키지 행의 버전과 이동한 자원을 함께 확인한다. 패키지 표는 같은 패키지가 얼마나 넓게 배포돼 있는지 보는 화면이고, 자원 상세는 특정 자원에 무엇이 들어 있는지 보는 화면이다. 검색 결과의 숫자만 적어 두기보다 어느 계정·리전의 어떤 자원인지까지 연결해 확인하는 편이 목적에 맞다.[2]
자원 상세의 Installed software 탭에서는 해당 자원의 패키지 목록과 각 버전, 패키지 유형을 볼 수 있다. 목록 안에서 특정 패키지를 다시 필터링할 수 있으므로, 검색한 프로그램뿐 아니라 같은 자원에 포함된 다른 소프트웨어를 확인하는 데도 사용할 수 있다.[2]
반대 방향도 가능하다. Resources 페이지나 finding에서 컴퓨팅 자원을 연 뒤 Installed software를 선택하면 된다. 특정 버전이 있는 자원을 찾을 때는 SBOM에서 시작하고, 이미 조사 중인 자원의 구성부터 볼 때는 자원 상세에서 시작하면 된다.[2]
프로그램이 검색되면 바로 취약하다고 판단해도 될까?
패키지 존재와 버전만으로 취약 여부를 확정하면 안 된다. 자원 상세에서 관련 findings를 확인한 다음, 해당 벤더와 배포판의 보안 공지 및 패키지 릴리스를 대조해야 한다. 설치 목록 확인과 취약 판정은 구분할 단계다.[2][7]
일반적인 운영 원칙으로, 배포판의 보안 백포트도 봐야 한다. Red Hat은 최신 상위 버전의 보안 수정을 기존에 배포하던 구버전 패키지에 적용하는 방식을 설명하며, 버전 번호만으로 취약 여부를 알 수 없다고 명시한다. 숫자가 낮아 보인다는 이유만으로 보안 수정이 없다고 단정할 수는 없다.[7]
따라서 확인 순서는 ‘검색한 패키지·버전 → 해당 자원 → 관련 finding → 벤더·배포판 공지’로 이어진다. 인벤토리는 대상 자원을 찾는 근거이고, 공지는 그 패키지 릴리스에 필요한 조치를 판단하는 근거다. 변경이나 패치는 조회 작업과 분리해 조직의 별도 승인 절차로 진행해야 한다.
검색 결과가 없거나 늦게 바뀌면 무엇을 봐야 할까?
계정·리전·권한과 Inspector 스캔 범위, SBOM 반영 지연을 먼저 확인해야 한다. Inspector가 새 SBOM을 생성한 뒤에도 Security Hub 인벤토리에 변경이 나타나기까지 수시간 걸릴 수 있다. 방금 설치하거나 바꾼 버전이 즉시 표시된다고 기대할 수 없다.[2]
검색되지 않는다는 사실만으로 해당 프로그램이 조직 어디에도 없다고 결론 내리면 안 된다. 조회할 수 없는 계정, 스캔하지 않는 자원 유형, 수집 범위 밖 자원은 그 결과로 판단할 수 없다. 인벤토리가 보여주는 것은 조회 범위에서 Inspector가 수집한 최신 목록이지 전체 서버의 전수검색 결과가 아니다.[2]
자원이 종료·삭제되거나 Inspector 스캔 범위를 벗어나면 해당 소프트웨어는 인벤토리에서 제거된다. 따라서 목록에서 사라졌다는 사실만으로 프로그램 제거 또는 패치 완료를 증명할 수도 없다. 자원 상태와 수집 범위가 달라졌는지 함께 확인해야 한다.[2]
추가비용 없음과 공지 날짜는 어떻게 읽어야 할까?
추가비용 없음은 SBOM 인벤토리가 Security Hub Essentials에 포함된다는 뜻이며, Security Hub와 Inspector 전체가 무료라는 의미는 아니다. 이번 공지의 포함 범위와 서비스 전체 비용을 같은 말로 읽지 않는 것이 중요하다.[1]
AWS 공지 게시일은 2026년 11월 6일이고, 공식 문서 변경 이력의 SBOM inventory 항목은 2026년 11월 3일이다. 공지일과 문서 변경일은 구별해야 한다. 두 날짜만으로 실제 최초 배포 시각을 확정할 수는 없다.[1][3]
이 기능으로 할 일은 프로그램·버전과 자원의 연결을 확인하는 것이다. 전체 서버 실시간 검색, 자동 패치, 개인정보 유출 방지 기능으로 확대해서 이해하면 안 된다. 계정·리전과 스캔 범위를 맞추고, SBOM에서 패키지를 찾고, Installed software와 findings를 확인한 뒤 벤더 공지에 따라 조치를 검토하는 순서가 핵심이다.[1][2][7]