대상 URL을 등록하는 것만으로, AI가 자율적으로 취약점을 찾아 실제로 공격 페이로드(Payload)를 보내고, 악용이 성립되는 단계까지 실증해 준다.

그런 홍보 문구를 내세운 서비스가 2026년 3월에 GA(General Availability, 일반 제공 시작)되었습니다.

AWS Security Agent입니다.

정말로 그 정도까지 한다면, 어디까지 찾아내고 어디서부터는 찾아내지 못하는 것일까.

그 경계가 궁금해졌습니다.

그래서 정답이 공개되어 있는 테스트용 앱을 대상으로 하여, 검출력을 실측해 보겠습니다.

소스 코드를 보여주지 않는 「블랙박스(Black Box)」와 보여주는 「화이트박스(White Box)」의 두 단계로 실행하여 결과를 대조했습니다.

실측을 통해 알게 된 점은 세 가지가 있습니다.

• 블랙박스(대상 URL만 전달)에서는 채점 대상 9개 카테고리 중 4개 카테고리만 나타났습니다. 확정된 지적 사항은 19건입니다.
• 소스까지 전달하면 7개 카테고리로 늘어나며, 확정 사항은 50건이 되었습니다. 늘어난 부분은 암호, 설계, 인증 세 가지입니다.
• 그리고 어떤 방식으로 실행해도 끝까지 채워지지 않는 카테고리가 두 개 남았습니다.

보안 테스트 자동화에 관심이 있는 분, 혹은 「AI가 자율적으로 펜테스트(Pentest)를 한다」라는 말의 실체를 알고 싶은 분을 독자로 상정하고 있습니다.

AWS Security Agent는 테스트 대상 URL을 등록하면 자율적으로 취약점을 찾고, 실제로 공격 페이로드(Payload)를 보내 악용이 성립되는지 여부까지 검증하는 서비스입니다.

출력물은 일반적인 페네트레이션 테스트(Penetration Test, 시스템에 실제로 침입을 시도하여 안전성을 평가하는 기법. 이하 펜테스트)의 보고서와 유사한 형태가 됩니다.

발견 건마다 취약점의 유형, 설명, CVSS(Common Vulnerability Scoring System, 취약점의 심각도를 수치화하는 표준) 점수, 재현 절차, 검증용 스크립트가 첨부됩니다.

요금은 작업 시간에 따라 과금됩니다.

가동된 1시간당 과금되며, 작업을 실행하지 않는 대기 중에는 과금되지 않습니다.

신규 이용자에게는 일정 수준의 무료 할당량이 있으며, 이번 검증은 해당 범위 내에서 실비 0원으로 마무리되었습니다.

검출력을 측정하려면 정답을 알고 있는 과녁이 필요합니다.

OWASP Juice Shop은 학습용으로 일부러 취약점을 심어놓은 웹 애플리케이션입니다1.

SQL 인젝션(SQL Injection), 크로스 사이트 스크립팅(Cross-Site Scripting), 권한 우회 등 실제 공격에서 다뤄지는 결함들이 골고루 포함되어 있습니다.

docker run

한 번에 실행할 수 있고 취약점 목록도 공식적으로 공개되어 있기 때문에, 검출 도구의 정답을 맞히는 용도로 적합합니다.

이 「정답이 공개되어 있다」는 점이 나중에 평가 설계에 영향을 미칩니다.

정답이 공개되어 있다는 장점에는 이면이 있습니다.

Juice Shop의 리포지토리(Repository)에는 모든 챌린지의 정답과 힌트가 담긴 공식 파일이 동봉되어 있습니다.

이를 그대로 AWS Security Agent에 읽히게 하면, 답안지를 준 상태에서 검출률을 측정하는 것이 되어 그 수치는 순수한 검출력을 반영하지 못합니다.

그래서 평가를 두 단계로 나누었습니다.

블랙박스(Black Box): 대상 URL만 등록하고 소스 코드는 일절 전달하지 않는다. 이를 주 지표로 삼는다.

화이트박스(White Box): 소스 코드도 전달한다. 「소스를 보여주었을 때 몇 건이 추가되는가」라는 차이의 참고값으로 취급한다.

블랙박스를 주인공으로 삼은 이유는, 답을 숨겼을 때 어디까지 스스로 찾아낼 수 있는지가 실제 운영에 가장 가깝기 때문입니다.

대상 앱은 취약점이 가득하여 디딤돌(Stepping Stone) 등으로 악용될 가능성도 있으므로, 외부에서 누구나 접속할 수 있는 상태로 인터넷에 두고 싶지 않았습니다.

그래서 AWS의 VPC(Virtual Private Cloud, AWS 상에 구축하는 격리된 가상 네트워크) 안에 Juice Shop을 가두어 외부에서 도달할 수 없는 구성으로 만들었습니다.

구축은 AWS CDK(Cloud Development Kit, 인프라를 코드로 정의하는 도구)의 Python 버전을 사용하여 작성하였으며, 나중에 동일한 환경을 재현할 수 있도록 했습니다.

[VPC]
├ 프라이빗 서브넷(Private Subnet)
│ ├ EC2 상에서 docker run bkimminich/juice-shop (Juice Shop 본체)
...

대상 앱 자체는 외부에서 도달할 수 없는 상태를 유지하면서, 에이전트(Agent)만 NAT(Network Address Translation, 내부에서 외부로의 통신을 중계하는 메커니즘) 게이트웨이를 통해 외부로 나갈 수 있는 구성입니다.

결과를 보기 전에, 무엇을 1건으로 셀 것인지를 정해 두겠습니다.

AWS Security Agent는 스캐너가 먼저 의심스러운 부분을 찾아내고, 후속 검증 단계에서 검증역이 실제로 시도하여 진짜인지 여부를 판정합니다.

판정 결과, 툴 스스로가 오탐 (False Positive, 실제로는 문제가 아닌 탐지)이라고 결론짓고 취소하는 항목이 있습니다.

본 기사에서는 이 취소분을 제외한 확정 건수를 주로 사용하며, 보고된 총수와 병기합니다2.

채점은 OWASP Top 10의 10개 카테고리 중 9개 카테고리로 진행합니다3.

A08 (소프트웨어 및 데이터 무결성 실패)은 Juice Shop을 Docker로 구동할 경우 해당 문항이 앱 측의 안전 메커니즘에 의해 무효화되어 측정 자체가 불가능하므로 제외했습니다.

대상 URL만 전달했을 때, 어디까지 찾아낼 수 있을까요?

보고는 23건이었으며, 그중 4건을 툴 스스로가 오탐으로 판단하여 취소했습니다.

남은 확정 건수는 19건으로, 심각도는 Critical이 4건, High가 4건, Medium이 9건, 기타가 2건입니다.

확정된 유형을 보면, 동적으로 호출하면 표면화되는 것들이 나열되었습니다.

• SQL 인젝션 (SQL Injection, 데이터베이스에 질의문을 주입하는 공격)이 3건
• IDOR (Insecure Direct Object Reference, 타인의 데이터를 식별자 변경만으로 참조하거나 변조할 수 있는 결함)가 3건
• 크로스 사이트 스크립팅 (Cross-Site Scripting, 타인의 브라우저에서 임의의 스크립트를 실행시키는 공격)이 2건

게다가 보고는 단순히 지적하는 데 그치지 않았습니다.

"인증된 사용자라면 누구나 타인의 상품 리뷰를 변조할 수 있다"는 IDOR의 경우, 실제로 요청을 보내 변조가 성립함을 보여준 뒤 보고했습니다.

파일 취득 엔드포인트에 대해서는, 널 바이트 주입 (Null Byte Injection)으로 확장자 체크를 우회하여 민감한 파일을 읽어내는 절차까지 재현했습니다.

다만, 카테고리 단위로 채점하면 양상이 달라집니다.

확정 건수가 발생한 것은 9개 카테고리 중 4개 카테고리 (액세스 제어, 인젝션, 설정 오류, SSRF)였으며, 커버리지(Coverage)는 44.4%였습니다.

절반에도 미치지 못합니다.

외부에서 호출하는 것만으로는 닿지 않는 영역이 있는 듯합니다.

그렇다면, 그 닿지 않는 영역은 소스 코드를 보여주면 채워질까요?

소스 코드도 전달한 화이트박스 (White-box) 테스트에서는 59건이 보고되었고, 9건이 취소되어 확정 50건이 남았습니다.

Critical만 12건, High가 15건입니다.

새롭게 발견된 것은 암호, 설계, 인증 카테고리였습니다.

이 표는 위 9개 카테고리로 분류 가능한 확정 건수를 집계한 것입니다.

화이트박스의 확정 50건 중 3건은 세션 관리나 객체 권한과 같이 이 9가지 분류에 바로 포함되지 않는 유형이기에 표에서 제외했습니다.

채워진 카테고리의 내용은 이번 검증에서 가장 볼만한 부분이었습니다.

암호 (A02)에서는 모든 사용자의 비밀번호가 솔트 (Salt) 없는 MD5로 해싱되어 있어, 레인보우 테이블 (Rainbow Table)을 통해 평문으로 되돌릴 수 있다는 지적이 나왔습니다.

HMAC의 비밀키가 소스에 하드코딩되어 있어 보안 질문의 답을 사전 계산할 수 있다는 발견도 있었습니다.

설계 (A04)에서는 수량에 마이너스 값을 넣으면 잔액이 늘어난다거나, 현재 비밀번호 확인 없이 비밀번호를 변경할 수 있다는 등의 비즈니스 로직 결함이 보고되었습니다.

인증 (A07)에서는 JWT (JSON Web Token, 서명된 토큰)의 서명 알고리즘을 alg:none으로 교체하여 임의의 사용자로 사칭하는 고전적인 우회 기법이 확정 건수로 올라왔습니다.

이것들이 블랙박스에서는 제로였던 영역입니다.

사실 블랙박스에서도 인증 관련 지적이 2건 있었습니다.

하지만 둘 다 "403 우회처럼 보이지만 실제로는 싱글 페이지 애플리케이션 (SPA)이 동일한 화면을 반환하는 것뿐이다"라며 툴 스스로가 취소했습니다.

확정된 인증 결함은 블랙박스에서 제로였습니다.

즉, 블랙박스가 놓친 것은 암호, 설계, 인증과 같이 코드를 보지 않으면 확신하기 어려운 영역입니다.

외부에서 통신을 호출하는 것만으로는 그곳에 존재한다고 확신할 수 있는 지점까지 도달하지 못합니다.

소스를 전달하자 그 벽이 허물어졌습니다.

여기까지는 카테고리의 폭을 통해 살펴보았습니다.

다른 척도도 적용해 보겠습니다.

Juice Shop의 알려진 정답 자체를 몇 건이나 공략할 수 있었는가.

분모는 이 Docker 환경에서 실제로 발생하는 OWASP Top 10 챌린지 67건입니다(공식 정답 중 환경에서 무효화되는 17건을 제외한 수치).

공략 가능한 67건 중 블랙박스(Black-box) 방식으로 14건(21%), 화이트박스(White-box) 방식으로 30건(45%)을 공략했습니다.

여기서 21%라는 숫자를 44.4%보다 "나쁘다"고 해석하지 마십시오.

두 지표는 측정하는 대상이 다릅니다.

전자는 정답을 하나씩 풀어낸 완정률(Completion rate)이고, 후자는 종류의 망라성(Coverage)입니다. 종류가 넓더라도 개별적인 완정은 남을 수 있기 때문입니다.

완정률의 내역을 살펴보면, 마지막까지 미흡했던 영역이 두 가지 있었습니다.

의존 라이브러리의 알려진 취약점: 오래된 버전의 라이브러리에 알려진 취약점이 있는 종류의 리스크.

로그와 모니터링이 충분한가: 공격 기록이나 탐지가 충분한가라는 운영 측면의 질문.

첫 번째가 채워지지 않는 이유는 서로 다른 종류의 도구가 필요하기 때문입니다.

의존 라이브러리의 버전을 알려진 취약점 목록과 대조하는 것은 SCA(Software Composition Analysis, 소프트웨어 구성 분석)의 영역이며, 동적인 공격이나 범용적인 코드 분석과는 별개의 계통입니다.

두 번째는, 로그 파일이 노출되어 있는 것과 같은 "보여지는" 문제라면 잡아낼 수 있습니다.

하지만 로그가 탐지에 충분한가라는 설계의 타당성은 외부에서 두드려보는 것만으로는 판정하기 어렵습니다.

자율 펜테스트 AI는 동적으로 두드릴 수 있는 범위와 코드로 확신할 수 있는 범위를 폭넓게 커버합니다.

그럼에도 불구하고, 이 두 가지는 영역 밖에 남습니다.

의존 라이브러리 진단과 로그 설계의 타당성 확인은 별도의 수단으로 보완한다는 전제하에 도입하는 것이 좋습니다.

취소된 오탐(False Positive)은 블랙박스에서 4건, 화이트박스에서 9건이었습니다.

보고 총수 대비 비율은 각각 17.4%와 15.3%가 됩니다.

대표적인 사례는, 싱글 페이지 애플리케이션(SPA)이 어떤 URL에도 동일한 화면을 반환하는 동작을 스캐너가 "접근 제어 우회"로 오인한 경우였습니다.

첫 번째 스캐너는 의심스럽다고 소란을 피웠지만, 후속 검증 역할이 실제로 시도해보고 오류라고 결론지었습니다.

오탐 자체는 일정 수 발생합니다.

다만, 툴 스스로가 이를 취소하기 때문에 이용자의 손에 남는 노이즈는 작아집니다.

작업 시간 단위로 과금된다고 하면, 비용이 너무 비싸지 않을까 하는 의문이 생길지도 모릅니다.

이번에는 과금 단위가 되는 작업 시간(여러 에이전트가 병렬로 동작하기 때문에 경과한 실제 시간과는 별개입니다)을 블랙박스에서 18.3시간분, 화이트박스에서 31.3시간분 소비했습니다.

무료 티어 범위 내였기에 실제 비용은 0원이지만, 범위가 없었다면 시간당 50달러로 총 약 2,481달러에 해당합니다.

정찰이나 정적 분석과 같은 공격의 전 단계에도 이 시간은 포함됩니다.

하지만 이는 인간에게 외주를 주었을 때와 동일한 구조입니다.

외주 펜테스트에서도 정찰, 환경 준비, 헛수고로 끝난 검증, 보고서 작성까지 모두 시간 단위로 청구됩니다.

확정된 취약점의 개수만큼만 지불하는 외주는 존재하지 않습니다.

따라서 작업 시간당 요금은 외주 인력의 Man-day 단가와 그대로 비교될 수 있습니다.

환경 구축 과정에서 한 곳에서 오래 막혔습니다.

에이전트의 통신 경로입니다.

AWS Security Agent는 검증을 위해 프라이빗 서브넷(Private Subnet) 내에 ENI(Elastic Network Interface, 가상 네트워크 인터페이스)를 생성하여 동작합니다.

해당 에이전트는 검증 결과를 외부로 보내기 위해 외부로 나가는 출구가 필요합니다.

프라이빗 서브넷에 외부 경로가 없으면 에이전트는 동작을 시작하지 못하고 타임아웃(Timeout)됩니다.

대상 애플리케이션은 외부에서 도달할 수 없게 유지하고 싶지만, 에이전트는 외부로 나가야 합니다.

이 두 가지를 양립시키는 답은 프라이빗 서브넷에 NAT 게이트웨이를 경유하는 출구를 마련하는 것이었습니다.

나머지는 한 번 이해하고 나면 절차로 만들 수 있는 것들뿐입니다.

• ENI를 생성하는 IAM(Identity and Access Management, AWS 권한 관리) 권한은 공식 문서대로 넓게 부여할 필요가 있었습니다. 범위를 좁히면 사전 체크 단계에서 멈춥니다.
• 대상 애플리케이션의 메모리가 작으면(1GB), 장시간 작업 도중에 애플리케이션 측이 한계에 도달하여 503 오류를 반환합니다. 2GB로 올려서 완화했습니다.
• 화이트박스 방식으로 소스를 전달할 때는 압축 형식에 지정이 있습니다. tar.gz는 받아들여지지 않아 ZIP으로 다시 업로드했습니다.

소스를 전달하자 암호·설계·인증 카테고리가 채워졌습니다.

그렇다면 문맥(Context)을 더 풍부하게 제공하면 성능이 더욱 향상되지 않을까.

그렇게 생각하여, 설계 문서(아키텍처 개요 및 API 사양)나 복수의 역할(Role)에 대한 인증 정보를 추가로 제공하는 재시험을 시도했습니다.

이 중 인증 정보는 조건으로서 순순히 수용되어, 인증을 포함한 펜테스트 (Pentest)로서 실행되었습니다.

반면 문서를 전달하는 방식은, 애초에 에이전트가 읽지 않는다는 함정에 빠졌습니다.

AWS Security Agent의 API에는 대상 앱의 문맥 (Context)을 제공하는 documents라는 입력 항목이 있으며, 공식적으로는 설계서나 API 사양을 전달할 수 있다고 설명하고 있습니다.

하지만 실제로 전달해도 에이전트가 그것을 읽은 흔적이 나타나지 않습니다.

만약을 위해 전달 방식을 세 가지로 바꾸어 시도했습니다.

1: S3에 ZIP 파일로 배치
2: S3에 개별 파일(.md / .yaml)로 배치
3: API의 업로드 기능으로 타입을 명시하여 등록

하지만 어떤 방식에서도 에이전트의 실행 로그에 전달한 문서 고유의 문구는 단 한 번도 나타나지 않았습니다.

소스 코드의 내용은 로그에 그대로 히트(Hit)되는데, 전달한 문서만 나오지 않는 것입니다.

즉, 문서는 수용 및 저장되지만, 펜테스트 실행 시에는 에이전트의 문맥 (Context)으로 공급되지 않고 있다는 뜻입니다.

설정 미스를 의심하여 교차 검증도 진행했습니다.

AWS가 직접 공개한 멀티 에이전트 구성 해설 기사에서도, 펜테스트 에이전트가 가져오는 것은 "발견된 엔드포인트", "검증된 지적 사항", "코드 분석이 생성한 문서"이며, 이용자가 전달한 문서를 읽는 메커니즘은 적혀 있지 않습니다.

GA 직후 서비스를 역분석한 제삼자의 기사에서도, 문맥의 원천은 CodeBuild 환경과 대상 앱의 응답 및 소스 코드이며, 문서 도입 기제는 보이지 않는다고 보고되어 있습니다.

공식 API 형식대로 지정해도 읽게 만들 수 없었다는 것이 실측과 교차 검증의 결론입니다.

따라서 펜테스트에서 문맥을 더하는 레버(Lever)는 현재로서는 "소스를 전달하는 것"과 "인증 정보를 전달하는 것" 두 가지로 사실상 좁혀집니다.

documents는 아마도 설계 리뷰 등 별도 모드용 입력이며, 펜테스트 측의 도입은 미구현 상태이거나 향후 대응을 기다리는 중인 것으로 보입니다.

이 부분이 채워진다면, 문맥을 두텁게 했을 때 어디까지 성능이 향상되는지를 다시 한번 제대로 측정해보고 싶습니다.

서두의 질문, 즉 어디까지 찾아내고 어디서부터는 찾지 못하는가에 대해서는 답이 나왔습니다.

그 답을 그대로 실제 프로덕트에 적용할 수 있을지는 별개의 문제입니다.

Juice Shop은 학습용으로 취약성을 과도하게 농축한 앱입니다.

여기서 일정 수준의 커버리지 (Coverage)가 나왔다고 하더라도, 실제 프로덕트에서의 탐지력을 그대로 보장하는 것은 아닙니다.

게다가 Docker로 구동하면 일부 챌린지는 앱 측의 안전 기제에 의해 처음부터 무효화되어 측정 자체가 불가능합니다.

명백히 보물찾기 같은 챌린지나, 실존 인물 또는 SNS 게시물에 의존하는 문항도 평가에서 제외했습니다.

그럼에도 두 단계의 비교를 통해 알 수 있는 점은 명확합니다.

소스를 전달하느냐에 따라 암호, 설계, 인증 카테고리가 생성되는지가 달라집니다.

그리고 의존 라이브러리와 로그라는 두 카테고리는 이 도구 외부에서 처리할 수밖에 없습니다.

자동화할 수 있는 범위는 생각보다 넓었습니다.

그 외부에 무엇이 남는지 조감도를 그린 상태에서 사용한다면, 유효한 도구라고 느낍니다.

남은 두 가지를 누가 어떻게 채울지는 이 도구를 도입하는 측에서 다음에 고민해야 할 과제가 될 것입니다.

--

• OWASP는 Open Worldwide Application Security Project의 약자로, 웹 애플리케이션 보안에 관한 표준과 도구를 공개하는 커뮤니티입니다. "OWASP Top 10"은 대표적인 10가지 카테고리의 리스크를 정리한 것입니다. ↩

• 도구는 악용이 성립되어 높은 신뢰도로 입증된 것과, 의심스럽지만 확증까지는 이르지 못한 것(저신뢰도 또는 미검증)을 구분합니다. 여기서 말하는 "확정"은 후자를 포함하여 철회되지 않은 모든 것을 가리킵니다. 고신뢰도 항목만 추리면 블랙박스 테스트에서 17건, 화이트박스 테스트에서 41건이 됩니다. 단, 후술하는 카테고리 단위의 커버리지는 고신뢰도 항목만 계산해도 동일한 결과가 나옵니다. ↩

Juice Shop 고유의 카테고리 명칭은 OWASP Top 10의 2017년 버전이나 2013년 버전의 명칭을 따르고 있기 때문에, 2021년 버전으로의 매핑은 공식 전환 대응표를 기준으로 삼았습니다. 다만 일부(입력 검증 미흡을 A04로 분류하는 등)는 공식 매핑이 존재하지 않아, 본 평가에서의 판단에 따라 적용했습니다. 다른 평가자라면 다른 분류 방식을 선택할 수도 있습니다. 수치의 절대값보다는 블랙박스(Black-box)에서 화이트박스(White-box)로의 증가 폭과 카테고리 간의 상대적 차이를 확인해 주시기 바랍니다. ↩