이 글은 AWS Frontier Agents 시리즈의 두 번째 편입니다. 1편에서 다룬 배포 전 릴리스 검증에 이어, 이번 글은 배포된 애플리케이션의 보안을 검증하는 AWS Security Agent에 대한 내용을 다룹니다.

일반적으로 연 1~2회 수행하는 외주 침투 테스트만으로는 매일 배포되는 애플리케이션의 보안 변화를 따라가기 어렵습니다. AWS Security Agent는 이 문제를 해결하기 위해 소스 코드와 문서를 사전에 분석한 뒤, 다단계 공격 체인을 자동으로 실행합니다. 이를 통해 검증된 취약점을 재현 가능한 공격 경로 및 수정 PR과 함께 보고하며, 이 글에서는 해당 과정을 단계별로 살펴봅니다. 아울러 STRIDE 위협 모델링과 CI/CD 파이프라인에 상시 보안을 통합하는 방법도 함께 다룹니다.

들어가며: 침투 테스트의 병목

1편에서 AnyCompany는 AWS DevOps Agent로 배포 전 릴리스 관문을 세웠습니다. 이제 그 관문을 통과해 배포된 주문 서비스가 실제로 안전한지 검증할 차례입니다. 릴리스 리스크가 없는 코드가 곧 보안 취약점이 없는 코드는 아니기 때문입니다.

전통적인 침투 테스트에는 구조적인 한계가 있습니다. 대부분의 경우 연 1~2회만 수행되어 그 사이 매일 배포되는 변경은 검증 없이 올라가고, 전문 인력의 수동 테스트는 비싸서 일부 애플리케이션에만 제한적으로 적용됩니다. 자동화 스캐너는 애플리케이션 맥락을 모른 채 패턴만 매칭해 오탐을 쏟아내고, 비즈니스 로직 결함 같은 중요한 위험은 놓치게 됩니다.

그리하여 AWS Security Agent는 이 한계를 개선하고자 합니다. 소스 코드와 애플리케이션 문서를 분석해 깊은 애플리케이션 이해를 형성한 뒤, 스캐너가 찾지 못하는 취약점을 다단계 공격 시나리오로 발견하고 검증합니다. 특히 발견한 취약점을 실제 익스플로잇으로 증명(proof-based exploitation)하므로 재현되지 않는 오탐이 걸러진 상태로 보고됩니다.

Security Agent의 4가지 기능과 개발 라이프사이클

AWS Security Agent는 설계부터 배포까지 개발 라이프사이클 전반에 걸친 네 가지 기능을 제공합니다. 조직의 보안 요구사항(approved authorization libraries, logging standards, data access policies 등)을 콘솔에 한 번 정의하면, 이후 모든 설계 리뷰와 코드 리뷰에서 이 기준이 자동으로 적용됩니다.

각 기능은 독립적으로 사용할 수 있지만, 함께 쓰면 “왼쪽으로 이동(shift-left)”과 “배포 후 검증”이 하나의 연속된 흐름을 이룹니다. 이 글에서는 이 중 가장 성숙한 침투 테스트를 중심으로, 위협 모델링과 PR 자동 분석을 함께 다룹니다.

AWS Continuum에 대한 참고: 2026년 6월 AWS는 “머신 속도의 보안(security at machine speed)”을 표방하는 AWS Continuum을 발표했습니다. Security Agent의 침투 테스트와 코드 스캐닝 기능은 Continuum 침투 테스트·코드 스캐닝이라는 이름으로도 제공됩니다. 전환기 동안 AWS 자료에서 동일 기능이 두 이름으로 나타날 수 있으니 참고하시기 바랍니다.

핸즈온 1: 온디맨드 침투 테스트

AnyCompany 주문 서비스를 대상으로 침투 테스트를 실행해 보겠습니다. 이번 실습에 사용한 애플리케이션 코드는 anycompany-order-pentest 리포지토리에서 확인할 수 있습니다. 의도적으로 취약점을 포함한 데모 전용 애플리케이션이므로, 격리된 자사 소유 환경에만 배포하고 시연이 끝나면 삭제하세요.

그림 1. AWS Security Agent 온디맨드 침투 테스트 워크플로우 — 스코프 정의 → 소스 코드·문서 분석으로 애플리케이션 이해 → 다단계 공격 체인 실행 → proof-based 검증 → 리포트 및 수정 PR 생성

사전 준비: Agent Space 생성과 환경 설정

핸즈온에 앞서, 처음 사용하는 경우 Security Agent 콘솔에서 최초 설정을 한 번 완료합니다. 이 설정은 조직 단위로 한 번만 수행하며, 이후 애플리케이션마다 Agent Space를 이름·설명만으로 간단히 추가할 수 있습니다.

[1] Agent Space 생성: Agent Space는 하나의 애플리케이션을 검증하는 전용 작업 공간으로, 소스 코드 연결·침투 테스트 구성·발견 사항이 모두 이 단위에 담깁니다(애플리케이션 하나당 하나 권장). 콘솔에서 Security Agent 설정(Set up Security Agent)을 선택하고 이름과 설명을 입력합니다.

그림 2. AWS Security Agent 최초 설정 화면 — Agent Space 이름을 입력하고 웹 애플리케이션 접근 방식(IAM Identity Center SSO 또는 IAM 전용 액세스)을 선택하는 화면

[2] 접근 방식 선택: 웹 애플리케이션 접근 방식으로 IAM Identity Center(SSO) 또는 IAM 전용 액세스(IAM-only access)를 고릅니다. 후자는 콘솔 관리자 링크로 접근하는 간단한 방식으로, 이 핸즈온의 기준입니다. (단, IAM 전용에서 SSO로 전환하려면 설정을 삭제하고 다시 해야 하므로 조직 방침을 미리 정하세요.)

[3] 권한 구성: 웹 애플리케이션이 AWS 서비스에 접근할 때 사용할 IAM 역할을 지정하고 설정을 완료합니다. 이 시점에 Agent Space와 웹 애플리케이션이 생성됩니다.

[4] 소스 코드·문서 제공자 등록(권장): 필수는 아니지만, 소스 코드나 문서를 연결하면 스캐너가 흉내 낼 수 없는 컨텍스트 인지 테스트가 가능해집니다. 침투 테스트 구성의 소스 코드 또는 문서 제공자 등록에서 추가를 눌러, 코드 제공자(GitHub·GitLab·Bitbucket·GitHub Enterprise Server·S3) 또는 문서 제공자(Confluence)를 연결합니다. GitHub는 AWS Security Agent GitHub App을 설치·인증하고 리포지토리 범위를 지정하는데, 이 인증은 브라우저를 닫지 말고 한 번에 끝내야 합니다. AnyCompany는 주문 서비스 리포지토리를 등록합니다.

그림 3. 연결한 리포지토리의 기능 관리 화면 — 침투 테스트 대상 리포지토리(비공개)에 코드 리뷰 코멘트와 코드 수정을 모두 활성화한 화면. 두 쓰기 기능은 프라이빗 리포지토리에서만 사용할 수 있는 화면

[5] 침투 테스트 활성화: 다른 세 기능과 달리 침투 테스트는 별도 활성화가 필요합니다(카드에 “설정이 필요함”으로 표시). Agent Space 개요에서 침투 테스트 활성화를 누른 뒤, 대상 도메인의 소유권을 검증합니다 — Security Agent는 검증된 도메인에만 테스트를 수행하므로, 남의 시스템을 대상 삼는 것을 원천 차단하는 안전장치입니다. 라이브 도메인을 입력하고 검증 방식(DNS_TXT, HTTP_ROUTE, 프라이빗 VPC용 PRIVATE_VPC)을 선택합니다. Route 53 같은 계정이면 원클릭, 다른 DNS 사업자면 발급 토큰을 TXT 레코드로 등록 후 검증합니다. VPC·CloudWatch 로그·자격 증명 저장은 선택 구성이며, 서비스 역할은 자동 생성됩니다. 스테이징이 사내망에만 있어 퍼블릭 도메인이 없다면 PRIVATE_VPC 검증을 선택하고, 테스트 생성 시 해당 VPC를 지정하면 퍼블릭 노출 없이 테스트할 수 있습니다.

설정을 마치면 Agent Space 개요의 웹 애플리케이션 실행(또는 콘솔 웹 앱 탭 → 관리자 액세스)으로 웹 애플리케이션을 엽니다. 침투 테스트와 위협 모델링은 여기서 생성·실행합니다.

1단계: 테스트 대상 준비

침투 테스트를 만들 때 Security Agent에게 제공하는 정보는 세 가지입니다. 타깃 URL(0단계에서 검증한 도메인 범위 안의 엔드포인트, 예: 스테이징), 인증 경로 테스트용 자격 증명(로그인 방식은 Agent Space 로그인 프롬프트로 지정), 그리고 0단계에서 등록한 소스 코드·문서입니다. API 명세·아키텍처 설명 같은 문서는 테스트 생성 시 파일로 업로드할 수도 있습니다.

주의: 침투 테스트는 반드시 본인이 소유하거나 명시적으로 테스트 권한을 가진 시스템에만 수행해야 합니다. 실행 전 사내 보안 정책에 따른 승인을 거치고, 프로덕션이 아닌 격리 환경을 대상으로 삼으세요. 이 부분은 글 후반의 국내 규정 고려사항에서 다시 다룹니다.

2단계: 테스트 스코프 설정

웹 애플리케이션의 침투 테스트에서 첫 번째 침투 테스트 생성을 선택해 테스트를 정의합니다. 대상은 0단계에서 검증한 도메인 중에서 고르며, 그 안에서 테스트할 경로와 제외할 경로를 지정해 Agent의 활동 범위를 통제합니다.
예를 들어 AnyCompany는 주문 조회·생성 API를 대상에 포함하고, 외부 결제 게이트웨이 연동 엔드포인트는 제3자 시스템이므로 제외합니다. 대상 도메인 밖에 있지만 로그인·탐색에 필요한 URL(예: Okta, Auth0, Stripe 같은 제3자 인증 서비스)은 액세스 가능한 URL(Accessible URLs)에 추가합니다 — 이 URL들은 접근 용도로만 쓰이며 침투 테스트 대상은 아닙니다.

그림 4. 침투 테스트 생성 1단계(테스트 상세) — 테스트 이름과 검증된 타깃 URL을 지정하고, 제외할 위험 유형·경로와 공격하지 않을 도메인을 함께 설정하는 화면

로그를 저장할 IAM 역할과 로그 그룹을 지정합니다(지정하지 않으면 테스트 시작 시 자동 생성됩니다). 앱이 실제로 호출하는 도메인을 손으로 정리하기 어렵다면, 콘솔이 안내하는 Security Agent Recorder 브라우저 확장(Chrome·Firefox)으로 URL 목록을 자동 수집해 Accessible URLs에 채울 수 있습니다.

이어지는 단계는 모두 선택 사항입니다. 대상이 퍼블릭 인터넷에서 접근할 수 없는 프라이빗 네트워크에 있으면 2단계에서 VPC를 지정하고, 로그인 뒤 영역까지 테스트하려면 3단계에서 자격증명을 등록합니다. 4단계에서는 소스 코드 리포지토리를 연결해 애플리케이션 컨텍스트를 제공하고, 자동 코드 수정 활성화(Enable automatic code remediation)를 켜면 발견된 모든 취약점에 대해 바로 적용 가능한 수정 PR을 자동으로 받을 수 있습니다.

그림 5. 침투 테스트 생성 4단계(추가 구성) — 침투 테스트 대상 애플리케이션의 소스 코드 리포지토리를 연결하고 자동 코드 수정(Automatic code remediation)을 활성화한 화면

3단계: 침투 테스트 실행

스코프가 준비되면 생성 및 실행(Create and execute)으로 테스트를 실행합니다. (즉시 실행하지 않고 구성만 저장하려면 침투 테스트 생성(Create penetration test)을 선택) Security Agent는 전용 AI 에이전트들을 배포해 애플리케이션의 컨텍스트를 이해한 뒤, 맞춤형 다단계 공격 시나리오로 취약점을 발견·검증·보고·수정합니다. 실행은 타깃 도달 여부와 로깅 구성을 검사하는 Preflight 단계로 시작하며(실패 시 테스트 전에 중단), 이후 대부분 16시간 안에 완료됩니다.

이번 시연을 위해 AnyCompany 주문 서비스에는 두 가지 취약점을 심어 두었습니다. 주문 조회·환불 API를 제공하고 Bearer 토큰으로 호출자를 인증하는 서비스이며, 리포지토리 README에 “주문 조회는 해당 주문의 소유 고객만 가능”, “환불은 주문당 한 번만”이라는 비즈니스 규칙을 명시해 두었습니다.

• IDOR (Insecure Direct Object Reference): 주문 조회 API가 요청한 사용자의 소유 여부를 검증하지 않아, orderId만 바꾸면 타인의 주문을 조회할 수 있음.
• 비즈니스 로직 결함: 반품 요청 API가 이미 환불된 주문에 대한 중복 환불을 막지 않아, 동일 주문을 여러 번 환불받을 수 있음.

첫 번째는 일부 스캐너가 부분적으로 탐지할 수 있지만, 두 번째는 애플리케이션의 비즈니스 흐름을 이해해야만 발견할 수 있는 유형입니다.

컨텍스트가 결과를 가른다: 소스 코드 연결 전후 비교

이 데모를 준비하며 컨텍스트의 중요성을 실증하는 결과를 얻었습니다. 처음에는 소스 코드를 연결하지 않고 타깃 URL만으로 침투 테스트를 실행했는데, 검증된 조사 결과가 3건(중간 1·정보 2, 높음 0)에 그쳤고, IDOR와 중복 환불 어느 쪽도 잡히지 않았습니다. 대신 접근 제어 누락이 일반적인 보안 구성 오류(Security Misconfiguration)로, 부하 관련 서비스 거부(Denial of Service)로만 분류되었습니다.

그림 6a. 소스 코드 연결 전 — 검증된 조사 결과 3건(중간 1·정보 2, 높음 0). 위험 유형이 서비스 거부·보안 구성 오류로만 분류된 화면

이는 Agent의 한계가 아니라 오히려 컨텍스트가 왜 필요한지를 보여줍니다.

• IDOR: “A 사용자가 B 사용자의 주문에 접근”이 취약점이 되려면 누가 무엇을 소유하는가라는 소유권 모델을 알아야 합니다. URL만 보면 Agent에게 이 API는 그저 “인가 검증이 부실한 엔드포인트”일 뿐입니다.
• 중복 환불: 환불이 세 번 성공하는 것이 버그인지 정상 동작인지는 “환불은 주문당 한 번”이라는 비즈니스 규칙을 알아야만 판단할 수 있습니다. 이 규칙은 HTTP 응답이 아니라 코드와 문서에 있습니다.

소스 코드와 README를 리포지토리로 연결하고 다시 실행했더니 검출 건수와 심각도가 확연히 높아졌습니다. 검증된 조사 결과가 7건(높음 3·중간 3·정보 1)으로 늘었고, 위험 유형 최상단에 Insecure Direct Object Reference(IDOR), 그리고 Business Logic Vulnerabilities(중복 환불)가 검출되었습니다. Privilege Escalation, Authentication Bypass 같은 인가 관련 결함도 함께 드러났습니다. 같은 애플리케이션·같은 URL인데 소스 컨텍스트 유무만으로 검출 건수와 심각도가 크게 벌어진 것입니다.

그림 6b. 소스 코드 연결 후 — 검증된 조사 결과 7건(높음 3·중간 3·정보 1). 위험 유형 최상단에 IDOR, 이어서 권한 상승·인증 우회·비즈니스 로직 취약점이 검출된 화면

컨텍스트가 주어지면 Agent가 사람 전문가가 코드를 읽고 찾아내는 유형의 결함까지 도달한다는 뜻입니다. 실무에서도 테스트 대상의 소스 코드와 설계 문서를 반드시 연결하는 것을 권장합니다.

4단계: 결과 분석

테스트가 완료되면 발견된 취약점이 콘솔에 정리됩니다. 각 항목은 에이전트 신뢰도·위험 점수와 함께, 영향 분석과 재현 가능한 공격 경로를 포함합니다.

그림 7. 발견된 취약점 목록과 상세 — 조사 결과 탭에 IDOR(조회/환불)·중복 환불·인증 우회 등이 심각도·신뢰도와 함께 나열되고, 우측 상세 패널에 영향 분석·근본 원인(src/auth.py의 caller_id 미비교)·재현 단계가 표시되는 화면

각 취약점은 실제 익스플로잇으로 검증됩니다. 예를 들어, 환불 API의 IDOR 항목은 “두 고객의 주문을 시드하고, 한 사용자의 토큰으로 타인 주문에 환불을 실행”한 재현 과정과 함께, Agent가 소스를 읽었기에 “src/auth.py가 caller_id는 확립하지만 주문의 customerId와 비교하지 않는다”는 근본 원인을 파일·필드 단위로 적시합니다. 검증된 취약점만 남으므로 보안팀은 오탐 선별 대신 실제 고위험 항목에 집중할 수 있습니다.

주목할 점은 Agent가 의도적으로 심은 취약점 이상을 찾아냈다는 것입니다. IDOR·중복 환불 외에도, X-HTTP-Method-Override 헤더로 읽기 전용 GET을 상태 변경 POST(환불)로 우회 실행하는 권한 상승(위험 점수 8.2), 인증 우회, 인증 없는 /seed 노출까지 검출했습니다. API Gateway 라우팅과 Lambda 핸들러 구조를 이해했기에 가능한 발견으로, 컨텍스트를 갖춘 Agent가 사람 리뷰어가 놓치기 쉬운 공격 체인까지 스스로 조합해냅니다. 실제로 이 권한 상승에 코드 수정을 요청하자 메서드 오버라이드를 탐지·차단하는 validate_http_method()를 추가하는 수정안까지 생성했습니다.

5단계: 수정 PR 검토

각 조사 결과 상세 화면의 코드 수정 버튼을 누르면, Security Agent가 확인된 취약점에 대해 바로 적용 가능한 코드 수정 PR을 개발자 친화적 언어로 생성해 연결된 소스 리포지토리에 제출합니다.

팁: 수정 PR을 받으려면 대상 리포지토리에 자동 수정(Automatic remediation)이 활성화되어 있어야 합니다. Agent Space의 침투 테스트(또는 코드 리뷰) 탭에서 리포 구성 마법사를 열어 리포지토리를 Enabled로 저장하세요. 꺼져 있으면 “코드 수정”을 눌러도 쓰기 권한 오류가 발생합니다.

이번 사례에서 IDOR(주문 조회) 취약점에 대해 Agent가 생성한 수정안은 주문을 조회한 뒤 호출자가 그 주문의 소유자인지 검증하는 코드를 추가합니다. 소유자가 아니면 403 Forbidden으로 응답해 타인 주문 접근을 차단합니다.

# src/get_order.py — Agent가 추가한 소유권 검증 (수정 diff)
    caller_id = get_caller_id(event)
    ...
    item = response.get("Item")
    if not item:
        return {"statusCode": 404, "body": json.dumps({"message": "Order not found"})}

    # Ownership check: ensure the authenticated caller owns this order.
    if item.get("customerId") != caller_id:
        return {
            "statusCode": 403,
            "body": json.dumps({"message": "Forbidden"}),
        }

    return { ... }  # 소유자 확인 후에만 주문 데이터 반환

위 코드는 조사 결과 상세의 “코드 수정” 버튼으로 Agent가 생성한 수정안(diff)입니다. 자동 수정이 활성화된 프라이빗 리포지토리에는 GitHub 풀 리퀘스트로 제출됩니다. 퍼블릭 리포지토리는 쓰기 동작이 지원되지 않으므로, 이 경우 콘솔에서 수정안을 diff로 확인한 뒤 직접 반영해야 합니다. Agent가 수정을 실제로 제출하는 화면은 글 후반의 PR 자동 분석에서 확인할 수 있습니다.

수정안은 인증된 사용자라도 자신이 소유한 주문에만 접근하도록 소유권 검증(customerId와 caller_id 비교)을 핸들러에 삽입합니다. Agent는 이 변경이 왜 필요한지 — 어떤 필드 비교가 빠져 있었고 그로 인해 어떤 접근이 가능했는지 — 를 함께 설명하므로, 보안 전문 지식이 깊지 않은 개발자도 맥락을 이해하고 병합할 수 있습니다. 침투 테스트가 “취약점 목록을 넘기고 끝”이 아니라 “수정까지 이어지는 워크플로우”가 되는 지점입니다.

핸즈온 2: STRIDE 위협 모델링 (Preview)

침투 테스트가 배포된 애플리케이션을 검증한다면, 위협 모델링은 그보다 앞선 설계 단계에서 “이 애플리케이션이 어떻게 공격당할 수 있는가”를 체계적으로 도출합니다. Security Agent에 기술 설계 문서(scope doc)와 소스 코드를 입력하면, Agent는 애플리케이션의 아키텍처·구성 요소·신뢰 경계(trust boundary)·데이터 흐름·보안 태세를 서술한 시스템 개요를 생성합니다.

그림 8. 위협 모델 생성 화면 — 소스 코드 리포지토리와 별도로 기능 문서(Feature documents)를 지정하며, Agent는 위협 모델을 생성할 때 일반 소스 코드보다 이 문서를 우선하는 화면

팁: 신뢰 경계란? 서로 다른 신뢰 수준을 가진 영역 사이의 경계입니다. 인터넷과 내부 VPC 사이, 인증 전과 후, 애플리케이션과 데이터베이스 사이가 각각 해당합니다. 대부분의 심각한 취약점은 이 경계에서 검증이 누락될 때 발생하므로, 위협 모델링은 경계 식별에서 출발합니다.

이어서 STRIDE 카테고리별로 위협 목록을 심각도 및 실행 가능한 권고사항과 함께 생성합니다. STRIDE는 위협을 여섯 범주로 분류하는 프레임워크입니다. 이번 실행에서 Agent는 주문 서비스에 대해 12개의 위협(높음 10·중간 2)을 여섯 범주 전반에 걸쳐 도출했습니다.

STRIDE 범주	의미	Agent가 도출한 위협 (예)
Spoofing (위장)	신원 위장	API Gateway 인증기 부재로 인한 인증 우회
Tampering (변조)	데이터·코드 무단 변경	무제한 쓰기로 인한 환불 테이블 무결성 훼손
Repudiation (부인)	행위 부인	비인가 작업에 대한 감사 로깅 부재
Information Disclosure (정보 노출)	민감 정보 유출	소유권 미검증으로 타 고객 주문 정보 노출
Denial of Service (서비스 거부)	가용성 침해	조회 API 대량 호출로 부하 유발
Elevation of Privilege (권한 상승)	권한 획득	정제되지 않은 orderId 입력이 DynamoDB 키로 사용

각 위협은 상세 패널에서 문(Statement)·소스·사전 조건·공격 작업·영향으로 구조화되어, 어떤 조건에서 어떻게 성립하고 무엇에 영향을 주는지 추적할 수 있습니다.

그림 9a. 생성된 위협 모델 개요 — 총 12개 위협(높음 10·중간 2)이 STRIDE 6범주 전반에 분포하는 화면

그림 9b. STRIDE 범주별 위협 목록과 선택한 위협의 상세 — 문(Statement)·소스·사전 조건·공격 작업·영향으로 구조화되어 표시되는 화면

실습 노트: 위협 모델은 설계 문서(scope doc)를 기준으로 위협을 도출하고, 소스 코드는 시스템 이해를 위한 컨텍스트로 활용합니다. 소스 코드만 제공하면 Agent가 정확한 시스템 개요(아키텍처·신뢰 경계)는 생성하지만 위협 목록은 비어 있을 수 있습니다. 검증하려는 설계·기능을 담은 scope doc을 함께 제공하는 것이 핵심입니다.

위협 모델은 재사용 가능한 구성으로 저장됩니다. 코드와 설계가 진화하면 같은 구성을 다시 실행해 변화를 반영한 위협 모델을 얻을 수 있어, 라이프사이클 전반에 걸친 반복적 보안 평가가 가능합니다.

CI/CD에 상시 보안 내장하기: PR 자동 분석

침투 테스트와 위협 모델링이 온디맨드 심층 검증이라면, PR 자동 분석은 일상적인 개발 흐름에 보안을 상시 배치합니다. 연결된 리포지토리에 PR이 올라올 때마다 Security Agent가 코드 변경을 리뷰해 보안 발견 사항을 PR/MR 코멘트로 직접 게시하고, 필요 시 수정 PR도 자동 생성합니다.

실제로 확인해 보면 리뷰 깊이가 정적 스캐너와 다릅니다. 주문 검색 API를 추가하는 PR을 올렸을 때 Agent는 4개 파일에서 5건(Critical 1·High 3·Medium 1)을 검출했습니다 — 하드코딩된 관리자 override 토큰, 소유권 필터 누락으로 인한 테넌트 격리 실패, IAM 와일드카드 정책, 응답의 고객 이메일 노출, CloudWatch 로그의 자격증명·개인정보 평문 기록입니다. 각 발견 사항에는 라우팅부터 데이터 반환까지의 실행 경로가 파일·라인 단위로 제시되고, 왜 문제인지와 어떻게 고칠지가 함께 적힙니다.

그림 10. PR에 게시된 코드 리뷰 요약 — 4개 파일에서 5건(Critical 1·High 3·Medium 1)을 검출하고, 발견 사항들을 관통하는 패턴과 우선 조치 순서를 함께 제시한 화면

그림 11. 개별 발견 사항 코멘트 — 하드코딩된 관리자 override 토큰(Critical)에 대해 라우팅부터 전체 주문 반환까지의 실행 경로를 파일·라인 단위로 제시하고 수정 방안을 제안한 화면

그림 12. PR 코멘트로 자동 수정을 요청한 결과 — @AWS-Security-Agent fix all findings 코멘트에 이어 Agent가 인증 우회 제거·테넌트 격리 적용·IAM 범위 축소를 담은 커밋을 같은 브랜치에 푸시한 화면

여기서 1편의 DevOps Agent Release Management PR 리뷰(Release Readiness Review)와 역할이 어떻게 나뉘는지 짚을 필요가 있습니다. 두 기능 모두 PR에 코멘트를 남기지만 보는 관점이 다릅니다.

발견 사항을 바로 고치게 하려면 PR 메인 대화에 @AWS-Security-Agent fix all findings를 코멘트로 남기면 됩니다. Agent가 리뷰 피드백을 반영한 수정을 작성해 제출하므로, 개발자는 콘솔에 들어가지 않고 PR 화면에서 리뷰와 수정을 모두 처리할 수 있습니다. 이 기능도 자동 수정이 활성화된 프라이빗 리포지토리에서만 동작합니다. 수정은 별도 PR이 아니라 같은 브랜치에 커밋으로 추가되며, CI 재실행을 막기 위해 커밋 메시지에 [skip ci]가 붙습니다.

그림 13. Agent가 푸시한 수정 커밋의 diff — 하드코딩된 관리자 override 토큰이 제거되고, 결과를 호출자의 customerId로 필터링하는 테넌트 격리가 적용된 화면

두 Agent를 함께 연결하면 하나의 PR이 릴리스 안정성과 보안 양쪽에서 자동 검증받게 됩니다. 관점이 다른 두 리뷰어가 상시 대기하는 셈입니다.

비용, 리전, 국내 규정 고려사항

• 과금: 침투 테스트는 task-hour당 $50(초 단위 계량, 병렬 태스크는 합산)이며 최소 사용량 제약이 없습니다. 2개월 무료 평가판 기간에는 월 최대 400 task-hour까지 사용할 수 있습니다. 자세한 내용은 요금 페이지를 참고하세요. 여러 태스크가 동시에 실행되므로 청구되는 task-hour는 체감 실행 시간보다 큽니다. AWS는 평균적인 애플리케이션 한 건을 약 24 task-hour(약 $1,200)로 안내합니다. 위협 모델링·코드 리뷰·디자인 리뷰는 프리뷰 기간 동안 과금되지 않습니다.
• 리전: 침투 테스트 GA 시점(2026년 3월)부터 미국 동부(버지니아 북부), 미국 서부(오레곤), 유럽(아일랜드), 유럽(프랑크푸르트), 아시아 태평양(시드니), 아시아 태평양(도쿄) 6개 리전에서 제공되었고, 2026년 7월 뭄바이·싱가포르·상파울루가 추가되어 총 9개 리전을 지원합니다. 서울 리전은 아직 지원되지 않습니다. 나중에 추가된 세 리전은 글로벌 리전 간 추론을 사용하므로 처리 과정에서 데이터가 다른 AWS 리전으로 전송될 수 있습니다. 데이터 위치 요건이 있는 조직은 이 점을 확인한 뒤 리전을 선택하세요.
• 국내 규정 및 승인 절차: 자율 침투 테스트는 강력한 만큼 신중하게 운용해야 합니다.
  • 테스트 대상 사전 승인: 자사 소유이거나 명시적 테스트 권한을 보유한 시스템만 대상으로 삼습니다. 제3자 서비스·공유 인프라 테스트는 법적·계약적 문제가 될 수 있습니다.
  • ISMS-P 등 인증 체계와의 정합: 정보보호 관리체계 인증 조직이라면 자율 침투 테스트를 정기 점검 프로세스에 어떻게 편입하고 발견·조치 이력을 어떻게 증적으로 남길지 미리 설계하는 것이 좋습니다.
  • AWS 침투 테스트 정책: AWS 환경 대상 테스트는 AWS의 침투 테스트 정책을 따르며, 허용 서비스 범위를 확인해야 합니다.

마무리

이 글에서는 AWS Security Agent로 AnyCompany 주문 서비스의 보안을 검증하는 과정을 살펴보았습니다. 컨텍스트를 이해한 온디맨드 침투 테스트가 IDOR와 비즈니스 로직 결함을 재현 가능한 공격 경로로 증명하고 수정 PR까지 생성하는 흐름, STRIDE 위협 모델링으로 설계 단계의 위협을 도출하는 방법, 그리고 PR 자동 분석으로 CI/CD에 상시 보안을 내장하는 구성을 확인했습니다. 검증된 취약점만 보고하는 proof-based 접근 덕분에 보안팀은 오탐 선별이 아닌 실제 위험 대응에 집중할 수 있습니다.

이제 AnyCompany의 주문 서비스는 릴리스 관문(1편)과 보안 검증(2편)을 모두 갖췄습니다. 안정적으로 배포되고 안전하게 운영되는 애플리케이션. 그런데 이 모든 것이 잘 돌아가는 동안, 비용은 누가 지켜보고 있을까요? 어느 날 갑자기 청구서가 급증한다면, 그 원인을 며칠씩 추적하는 대신 자동으로 근본 원인과 책임자를 찾을 수는 없을까요? 3편에서는 AWS FinOps Agent(Preview)로 비용 이상을 자동 조사하는 과정을 다룹니다.

지금 바로 시작해 보려면:

• AWS Security Agent 시작하기 — 2개월 무료 평가판 (월 400 task-hour)
• AWS Security Agent 온디맨드 침투 테스트 GA 발표 (2026-03)
• Inside AWS Security Agent: 침투 테스트 멀티 에이전트 아키텍처 (아키텍처 딥다이브)
• AWS Security Agent 사용자 가이드