AI 보안 테스트가 SAST, DAST, 침투 테스트를 대체할 수 있을까요?

중요한 질문은 에이전트가 어디에서 신뢰를 얻느냐입니다. 저는 에이전트가 검토 범위를 넓히고, 여러 파일의 단서를 연결하고, 목표가 분명한 테스트를 만들고, 난해한 스캐너 추적 결과를 개발자가 이해할 수정안으로 바꾸는 일은 신뢰합니다. 반면 경로 이름만 보고 회사의 권한 규칙을 추론하거나, 모든 테넌트 경계가 지켜진다고 증명하거나, 사람이 규칙을 밝히지 않았는데도 이상한 금융 흐름을 악용으로 판단하는 일은 신뢰하지 않습니다. 에이전트는 계층형 테스트 프로그램 안에서 능동적으로 검토하는 역할로 다뤄야지, 프로그램 자체로 보면 안 됩니다.

에이전트 검토는 새로운 테스트 종류가 아니라 해석 방식입니다

AI 에이전트는 증거를 수집하고 이해하는 방식을 바꾸지만, 새로운 종류의 증거를 만들지는 않습니다. 애플리케이션을 실행하지 않고 소스를 읽으면 유연한 정적 검토를 하는 것입니다. 실행 중인 대상에 요청을 보내면 동적 테스트를 하는 것입니다. 목표를 탐색하고, 전술을 바꾸며, 예기치 않은 동작을 따라가면 침투 테스터와 비슷해집니다. 하지만 비슷하다고 해서 테스터의 권한이나 비즈니스 맥락까지 갖는 것은 아닙니다.

벤더가 자기 에이전트가 “스캐너를 대체한다”고 말할 때 이 구분이 중요합니다. 시스템이 실제로 무엇을 볼 수 있는지 물어보세요. 전체 저장소, 생성된 코드, 빌드 플래그, 인프라 정책, 의존성 잠금 파일을 받나요? 여러 사용자로 인증하고 요청마다 데이터베이스 상태를 검증할 수 있나요? 인터페이스에 없을 뿐 아니라 정책상 금지된 작업이 무엇인지 알고 있나요? 입력이 빠져 있으면 그럴듯한 설명으로도 보완할 수 없습니다.

에이전트는 약한 신호를 연결하는 데 정말 강합니다. 기존 규칙은 요청 매개변수가 쿼리 빌더에 도달한다고 표시할 수 있습니다. 에이전트는 래퍼를 살펴보고, 한 호출 위치만 테넌트 조건을 빠뜨렸음을 알아채고, 테스트 요청을 작성한 뒤, 안전해 보이던 도우미가 그 경로에서는 왜 안전하지 않은지 설명할 수 있습니다. 값이 실제 매개변수화 API를 거친다면 후보를 제외할 수도 있습니다. 이는 더 나은 분류이지, 정적 분석이나 동적 분석이 쓸모없어졌다는 증거는 아닙니다.

분명한 경계는 검토와 검증 사이에 있습니다. 검토는 “내가 볼 수 있는 자료를 기준으로 이 구현은 위험해 보이는가?”를 묻습니다. 검증은 “정해진 조건에서 이 행위자가 금지된 결과를 만들 수 있는가?”를 묻습니다. AI는 둘 다 도울 수 있지만, 보안 게이트는 어떤 주장을 하는지 기록해야 합니다. 설득력 있는 검토 관찰을 검증된 익스플로잇으로 올려버리거나, 익스플로잇 시도가 한 번 실패했다고 안전하다고 결론 내리면 팀은 피해를 봅니다.

모델 동작에는 또 다른 구분이 있습니다. 능력과 재현성은 다릅니다. 에이전트는 한 번의 실행에서 미묘한 경로를 찾고도 모델, 프롬프트, 검색 색인, 도구 정책이 바뀐 뒤에는 놓칠 수 있습니다. 결과가 중요하다면 프롬프트, 도구 권한, 검색한 파일, 생성한 요청, 모델 식별자를 보존하세요. 확인된 발견은 모델이 스스로의 아이디어를 다시 떠올려야만 통과하는 테스트가 아니라, 명확한 통과 조건을 가진 테스트로 바꾸세요.

SAST는 반복 가능한 소스 범위를 계속 맡습니다

SAST는 대규모 코드베이스의 모든 변경에 안정적인 검사를 적용하는 가장 저렴한 방법입니다. 소스와 싱크를 열거하고, 금지된 API를 강제하며, 데이터 흐름을 살피고, 분석한 정확한 리비전을 보고할 수 있습니다. 결정적인 규칙은 내일도 같은 결과를 내므로, 출시 게이트가 통과나 실패의 감사 가능한 근거를 제시해야 할 때 중요합니다.

에이전트는 규칙 엔진에 자주 부족한 맥락을 더합니다. 프로젝트별 래퍼를 따라가고, 주석을 비판적으로 읽고, 핸들러를 이웃한 핸들러와 비교하며, 새로운 패턴의 쿼리를 제안할 수 있습니다. 아홉 개 엔드포인트는 authorizeProject()를 호출하는데 열 번째 엔드포인트는 레코드를 직접 불러오는 식의 수상한 누락도 찾습니다. 생성된 코드나 낯선 프레임워크 때문에 표준 규칙 팩이 통하지 않을 때도 유용합니다.

하지만 에이전트의 소스 범위는 대체로 증명하기 어렵습니다. 컨텍스트 창, 검색 순위, 무시된 파일, 생성 산출물, 도구 시간 초과 때문에 읽지 못한 코드가 생길 수 있습니다. “이 저장소에서 인젝션을 검토해”라고 요청했다고 모든 싱크에 도달했다는 뜻은 아닙니다. SAST 보고서는 적어도 어떤 파일, 규칙, 리비전을 분석했는지 밝힐 수 있습니다. 에이전트가 필수 게이트를 맡으려면 그에 맞는 범위 원장이 필요합니다.

NIST SP 800-218은 여기서 합리적인 권고를 합니다. 코드 분석을 일찍 사용하고, 보안 기능과 완화 조치는 사람이 검증하라는 것입니다. 가치는 결합에 있습니다. 안정적인 규칙은 모든 커밋에서 알려진 결함 형태를 잡고, 에이전트는 예외를 조사하며, 집중된 회귀 테스트를 작성하고, 같은 패턴이 반복되면 규칙 튜닝을 돕습니다. 에이전트가 영리한 버그를 몇 개 찾았다고 SAST를 없애면, 측정 가능한 폭넓은 범위를 인상적인 일화와 맞바꾸게 됩니다.

SAST는 실행 중인 테스트가 절대 닿지 못할 코드도 봅니다. 오류 경로, 기능 플래그, 마이그레이션 유틸리티, 비활성 관리자 엔드포인트, 플랫폼별 분기가 그 예입니다. 배포 환경에서 그 경로가 활성화됐는지는 알 수 없습니다. 이는 런타임 증거를 더할 이유이지 정적 범위를 버릴 이유는 아닙니다.

차단하는 SAST 규칙에 넣을 수 있는 내용에는 한계가 있습니다. 금지된 암호화 프리미티브의 정확한 패턴은 즉시 차단할 수 있습니다. 권한 검사가 “충분히 가까워 보이는지”를 묻는 넓은 휴리스틱은 팀이 정확도를 측정할 때까지 대체로 검토 작업을 만들어야 합니다. 에이전트는 실제 사례, 반례, 그 코드베이스의 일반적인 래퍼 함수를 모아 휴리스틱을 규칙으로 승격하는 일을 도울 수 있습니다. 이렇게 하면 개발자에게 게이트를 무시하는 습관을 들이지 않고도 엄격함을 지킬 수 있습니다.

생성된 수정안도 발견 사항만큼 면밀히 봐야 합니다. 모델은 잘못된 계층에 유효성 검사를 추가해 테인트 추적을 잠재우거나, 예외를 잡아 실패 시 열어 두거나, 위험한 호출을 바꾸면서 동작을 바꿀 수 있습니다. 패치에 원래의 증명을 실행하고, 일반 기능 테스트를 실행하고, 신뢰가 형성되는 지점의 새 통제를 검토하세요. 깨끗한 재스캔은 원래 규칙이 더 이상 일치하지 않는다는 것만 증명합니다.

DAST는 저장소가 보여 주지 못하는 동작을 증명합니다

DAST는 프록시 규칙, 헤더, 직렬화, 인증 미들웨어, 프레임워크 기본값, 배포 실수를 포함해 실제 실행되는 애플리케이션을 관찰합니다. 소스 검토는 엔드포인트가 보호되는 것처럼 보인다고 말할 수 있습니다. 동적 테스트는 게이트웨이가 경로를 다시 쓰기 때문에 운영 경로가 미들웨어를 우회함을 보여 줄 수 있습니다.

에이전트는 여기서 동적 테스트의 둔함을 크게 줄일 수 있습니다. API 설명, 테스트 신원, 허용 범위, 일회용 환경을 제공하면 일반 페이로드를 마구 뿌리는 대신 요청 순서를 만들 수 있습니다. 한 응답의 리소스 식별자를 다음 요청으로 넘기고, 세션을 갱신하고, 두 역할을 비교하고, 쓰기가 이후 읽기를 바꿨는지 살필 수 있습니다. 기존 DAST는 이런 상태 기반 흐름에서 자주 어려움을 겪습니다.

그래도 에이전트에는 엄격한 운영 한계가 필요합니다. 크롤러는 이메일 발송, 배송 생성, 유료 통합 호출이 안전한지 모릅니다. 테스트 환경도 실제 서비스에 연결될 수 있습니다. 허용 호스트, 계정, 요청 속도, 파괴적 작업, 중단 조건을 모델 프롬프트 밖에서 정하고 실행기에서 강제하세요. “위험한 작업을 피하라”는 문장은 통제가 아닙니다.

보안 헤더, 노출된 파일, 반사 입력, 일반적인 인젝션 탐색, TLS 설정처럼 잘 알려진 검사는 기존 동적 기준선을 유지하세요. 이런 검사는 저렴하고, 릴리스 간 비교와 추세 파악이 쉽습니다. 에이전트의 자원은 인증된 경로와 연결된 동작에 쓰게 하세요. 두 시스템이 같은 단순 탐색을 다룬다면, 증거가 더 명확하고 편차가 작은 쪽을 유지하세요.

DAST도 도달한 것만 보고하므로 완전하다는 잘못된 인상을 줄 수 있습니다. 결과와 함께 경로 범위, 사용한 신원, 기능 플래그, 시드 데이터를 기록하세요. 거의 비어 있는 계정으로 깨끗한 스캔을 했다고 승인, 초대, 청구, 데이터 가져오기 뒤에만 나타나는 위험한 분기가 있는 애플리케이션을 잘 검증한 것은 아닙니다.

인증 설정에는 별도 증거가 필요합니다. 각 세션을 어떻게 얻었는지, 테스트 환경에서 어떤 2차 인증이나 기기 검사를 우회했는지, 토큰이 운영 토큰과 같은 클레임과 수명을 가졌는지 기록하세요. 직접 만든 관리자 토큰은 유용한 범위를 열 수 있지만, 정확히 테스트해야 할 세션과 권한 전환을 건너뜁니다. 이런 지름길은 보고서에서 분명히 드러내야 합니다.

동적 재테스트는 새 자율 크롤링이 아니라 저장된 요청 순서로 시작해야 합니다. 패치된 빌드에서 확인된 증명을 재생하고, 금지된 효과가 멈췄는지 확인한 뒤, 인접한 입력을 바꿔 좁은 필터를 탐지하세요. 그다음에 에이전트가 탐색하게 하세요. 이 순서는 “수정이 알려진 익스플로잇을 막는다”는 주장과 결함 종류 전체가 제거됐다는 더 넓은 주장을 구분합니다.

권한 테스트에는 신원과 금지된 결과가 필요합니다

권한 부여는 “엔드포인트가 한 번 403을 반환했다”가 아닙니다. 좋은 테스트는 누가 행동하는지, 어떤 객체를 대상으로 하는지, 어떤 작업을 시도하는지, 어떤 결과가 계속 불가능해야 하는지를 밝힙니다. 에이전트는 조합을 만들 수 있지만, 제품 책임자와 보안 검토자가 정책을 제공해야 합니다.

OWASP ASVS는 애플리케이션이 신뢰할 수 있는 서비스 계층에서 접근 제어를 강제하고, 기능과 데이터에 최소 권한을 적용해야 한다고 말합니다. 서비스 계층 요구에는 동의하지만, 팀은 이를 너무 좁게 검증하곤 합니다. 눈에 보이는 HTTP 핸들러만 테스트하고 백그라운드 작업, 내보내기, 검색 색인, 웹소켓 구독, 직접 객체 스토리지 URL을 잊습니다. 객체로 가는 모든 경로에서 같은 정책이 유지돼야 합니다.

작은 실행 가능한 매트릭스는 “IDOR을 테스트해”라는 모호한 지시보다 더 많은 것을 드러냅니다. 다음 셸 조각은 일회용 환경, 두 개의 베어러 토큰, 사용자 A가 소유한 문서를 가정합니다. 상태와 B의 응답에 A의 비밀 표식이 없는지를 모두 확인합니다.

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

예상 출력은 아무것도 없고 종료 상태는 0입니다. CI 실패 시 상태, 정제된 본문, 행동한 신원, 대상 소유자, 경로, 빌드 리비전을 보관해야 합니다. 실제 자격 증명이나 관련 없는 응답 데이터는 보관하지 마세요.

이제 한 번에 한 차원씩 바꾸세요. 읽기와 업데이트, 직접 ID와 검색, 활성 멤버십과 취소된 멤버십, 일반 경로와 내보내기, 사용자 토큰과 서비스 토큰을 비교합니다. 에이전트는 이런 사례를 효율적으로 만들고 실행할 수 있습니다. 하지만 매트릭스가 정책과 맞는지, 404, 403, 빈 결과, 마스킹된 객체 중 무엇이 의도한 결과인지 사람이 검토해야 합니다. 그렇지 않으면 비즈니스가 침해로 보는 동작을 에이전트가 성공으로 평가할 수 있습니다.

부정적 증거도 신중히 다뤄야 합니다. 거부된 업데이트도 응답 시간, 오류 문구, 버전 카운터로 객체 존재를 드러낼 수 있습니다. 거부된 읽기가 조회 수를 늘리거나 비밀 메타데이터가 담긴 감사 기록을 쓸 수도 있습니다. 어떤 부수 효과가 허용되는지 정한 뒤 그것을 검증하세요. 응답만 보는 보안 테스트는 유용한 열거 채널이나 피해를 주는 쓰기를 놓칠 수 있습니다.

세션 중 정책 변경도 테스트하세요. 프로젝트에서 사용자를 제거하고, 소유권을 이전하고, 계정을 비활성화하거나 서비스 역할을 좁힌 뒤, 오래된 토큰과 연결을 다시 사용합니다. 기대하는 권한 취소 시간은 제품 정책에서 나와야 합니다. “언젠가”는 테스트할 수 없고 즉시 취소가 불필요할 수도 있지만, 팀은 한계를 정하고 API 요청, 큐 작업, 다운로드, 실시간 구독 전반에서 검증해야 합니다.

테넌트 격리는 뻔한 요청 경로 밖에서 무너집니다

테넌트 격리는 스토리지, 캐시, 큐, 검색, 파일, 분석, 관리 경계에서 테스트해야 합니다. 흔한 실패는 주 목록 엔드포인트에서 tenant_id가 빠지는 일이 아닙니다. 테넌트 맥락을 유지하지 않은 채 데이터를 복사, 색인화, 캐시, 내보내기하는 보조 경로입니다.

의도적으로 비슷한 레코드와 서로 분명한 표식 하나씩을 가진 두 테넌트로 시작하세요. 별도 사용자, 별도 세션, 아키텍처가 허용한다면 별도 서비스 자격 증명을 사용합니다. 생성, 읽기, 업데이트, 삭제, 목록, 검색, 내보내기, 가져오기, 첨부 파일 접근, 알림 전달, 백그라운드 처리를 실행하세요. 각 작업 후 사용자에게 보이는 응답과 지속 상태를 살핍니다. 거부된 요청이 테넌트 간 작업을 큐에 넣었다면 실패입니다.

에이전트는 식별자를 계층 사이로 추적하고 사람이 지루해하는 순열을 만들 수 있어 도움이 됩니다. 캐시 키는 document_id만 쓰는데 데이터베이스 쿼리는 tenant_id와 document_id를 함께 쓴다는 점을 알아챌 수 있습니다. 내보내기 워커와 대화형 핸들러를 비교해 한쪽만 행 수준 맥락을 설정하는 이유를 물을 수 있습니다. 이는 가치가 큰 검토 방식입니다.

하지만 위험한 가정도 합니다. 이름이 경계를 뜻한다고 여기는 것입니다. getTenantDocument라는 함수가 요청에서 임의의 테넌트 인수를 받을 수 있습니다. 데이터베이스 정책이 마이그레이션에는 있지만 새 테이블에는 없을 수 있습니다. 검색 필터가 결과 개수를 센 뒤 적용되어 다른 테넌트의 활동을 누출할 수 있습니다. 검증은 강제된 조건을 확인한 후 테넌트 간 읽기와 쓰기를 실제로 시도해야 합니다.

에이전트가 테스트하는 코드를 읽고 스스로 판정 기준까지 만들게 하면 안 됩니다. 제품 요구 사항과 함께 관리하는 독립적인 정책 표에서 예상 접근을 도출하세요. 구현과 테스트가 같은 규칙을 오해하면, 데이터가 노출된 채로 완벽하게 일치할 수 있습니다.

비동기 경로에는 지연된 단언이 필요합니다. 테넌트 A로 내보내기, 알림, 썸네일, 색인 작업을 시작하고 워커가 실행되기 전에 소유권이나 멤버십을 바꾼 뒤 결과가 어디에 도착하는지 확인하세요. 워커가 요청 시점의 권한을 사용해야 하는지, 실행 시점의 현재 권한을 다시 확인해야 하는지 결정하세요. 특정 작업에서는 어느 쪽이든 맞을 수 있지만, 우연히 섞이면 누출과 잘못된 감사 기록이 생깁니다.

관리 도구에는 별도 신원과 로깅 단언이 필요합니다. 지원 접근은 설계상 테넌트 경계를 넘는 경우가 많으므로 “다른 테넌트는 반드시 실패해야 한다”는 단순 규칙은 틀립니다. 운영자에게 필요한 역할과 사건 맥락이 있는지, 고객에게 보이는 정책을 따르는지, 접근이 만료되는지, 감사 이벤트가 고객을 가장하지 않고 운영자를 식별하는지 테스트하세요.

비즈니스 로직에는 악용에 대한 이야기가 필요합니다

비즈니스 로직 테스트는 금지된 이야기에서 시작합니다. 사용자가 유효한 작업을 잘못된 순서나 조합으로 수행해, 받아서는 안 될 가치, 권한, 상태를 얻는 이야기입니다. 일반적인 취약점 라벨만으로는 부족합니다. 테스터는 초대, 승인, 할당량, 환불, 크레딧, 소유권 이전, 취소가 어떻게 상호작용해야 하는지 알아야 합니다.

OWASP Web Security Testing Guide는 테스터에게 건너뛴 워크플로 단계, 반복 기능, 위조 요청, 타이밍 변경, 유효 기능의 오용을 시도하라고 합니다. 오래된 비즈니스 로직 소개는 스캐너 자동화가 애플리케이션별 지식이나 창의성을 제공할 수 없다고 단언합니다. 현대 에이전트는 자동화를 개선하지만 지식의 공백을 없애지는 못합니다. 모델은 쿠폰이 재사용될 수 있다고 제안할 수 있지만, 누군가 규칙을 알려 주기 전에는 재사용이 프로모션인지 사기인지 알 수 없습니다.

에이전트에 허용된 전이와 불변 조건이 있는 상태 모델을 제공하세요. 승인 흐름의 불변 조건은 “요청자는 소유권 이전 후를 포함해 자신의 결제를 승인할 수 없다”라고 할 수 있습니다. 그런 다음 역할 변경, 중복 요청, 취소, 재시도, 동시성, 오래된 세션이 포함된 순서를 만들도록 하세요. 에이전트는 사람이 직접 수행할 수 있는 것보다 훨씬 많은 순서를 탐색할 수 있습니다.

어려운 사례에는 HTTP 응답 밖의 결과가 포함됩니다. 동시의 두 상환 요청이 모두 성공을 반환했지만 나중의 조정에서 하나가 제거될 수 있습니다. 취소가 화면에 보이는 작업은 중단하지만 서명된 다운로드를 취소하지 못할 수 있습니다. 초대한 사람이 접근 권한을 잃은 뒤 수락된 초대는 고아 멤버십을 만들 수 있습니다. 테스트는 상태 코드만이 아니라 원장, 큐, 객체 권한, 이후 상태를 관찰해야 합니다.

사람 테스터는 명시된 모델에 도전하는 데서 가치를 만듭니다. 지원 직원이 무해한 기능을 조합할 수 있는지, 운영자가 자신의 감사 흔적에 영향을 줄 수 있는지, “만료된” 객체가 다른 채널에서는 여전히 사용 가능한지를 묻습니다. 에이전트는 주어진 목표와 도구 안에서 움직입니다. 사람은 목표에서 비즈니스의 위험한 부분이 빠졌음을 알아챌 수 있습니다.

의존성 위험은 취약한 버전보다 넓습니다

의존성 테스트에는 네 가지 별도 질문이 있습니다. 어떤 패키지가 있는지, 알려진 버전에 보고된 취약점이 있는지, 빌드가 의도한 산출물을 얻었는지, 애플리케이션이 실제로 취약한 동작을 노출하는지입니다. 소프트웨어 구성 분석(SCA)과 출처 제어는 대화형 검토만으로는 처음 세 질문에 더 신뢰성 있게 답합니다.

인벤토리가 마련된 후 에이전트가 유용합니다. 의존성을 어떻게 호출하는지 살피고, 영향받은 함수에 도달할 수 있는지 판단하고, 보완 통제를 찾고, 회귀 테스트가 포함된 업그레이드 패치를 작성할 수 있습니다. 설치 스크립트가 네트워크 접근을 얻거나 새 라이브러리가 환경에서 비밀 정보를 받는 것처럼 취약점 식별자가 없는 위험한 패키지 동작도 표시할 수 있습니다.

현재 취약점 데이터를 모델에게 기억해 달라고 하지 마세요. 시점이 기록된 권고 출처, 해결된 잠금 파일, 빌드된 산출물 인벤토리를 제공하세요. 모델의 기억은 취약점 데이터베이스가 아니며, 패키지 매니페스트는 실제로 배포된 것을 증명하지 않습니다. SLSA 출처도 비슷한 구분을 합니다. 출처는 산출물이 어디서, 언제, 어떻게 만들어졌는지 설명할 뿐, 안전하다고 선언하지는 않습니다.

도달 가능성은 분류 우선순위를 낮출 수 있지만 책임을 없애면 안 됩니다. 기능 플래그는 바뀌고, 죽은 코드는 돌아오며, 간접 의존성은 예상치 못한 방식으로 호출됩니다. 발견을 미룬 이유, 평가한 버전과 호출 경로, 다시 열어야 할 사건을 기록하세요. 에이전트는 이 추론을 유지하고, 결정적인 인벤토리는 그 사건을 감시할 수 있습니다.

패키지 이름도 신원 함정을 만듭니다. 기대한 이름의 의존성이 잘못된 레지스트리에서 올 수 있고, 잠금 파일이 변경 가능한 위치를 가리킬 수 있으며, 빌드 단계가 매니페스트에 없는 코드를 내려받을 수 있습니다. 해결된 출처, 해시, 생태계에서 지원하는 서명, 빌드 네트워크 접근을 확인하세요. 에이전트는 차이를 설명할 수 있지만, 빌드 시스템은 어떤 출처를 받을지 강제해야 합니다.

업그레이드가 자동으로 안전한 변경은 아닙니다. 보안 릴리스는 구문 분석, 권한 기본값, 직렬화를 바꿔 애플리케이션을 망가뜨릴 수 있습니다. 권고에 대한 최소 재현을 만들고, 격리된 브랜치에서 업그레이드를 적용한 다음, 보안 증명과 기능 테스트를 모두 실행하세요. 이렇게 얻은 증거가 결정을 뒷받침합니다. 새 버전이 “호환될 것”이라는 모델의 말은 근거가 아닙니다.

오탐은 증거 설계의 문제입니다

발견이 개발자의 시간을 쓸 가치가 있으려면 주장, 증거, 영향, 재현 경로가 있어야 합니다. AI가 만든 보고서는 이 중 하나가 빠져도 완성돼 보일 때가 많습니다. 유창한 수정 안내는 약한 증거를 더 알아보기 어렵게 만듭니다.

각 에이전트 발견에 분석한 리비전과 환경, 영향받은 구성 요소, 공격자 사전 조건, 넘은 보안 경계, 관찰되거나 추론된 결과, 재현 단계, 불확실성을 요구하세요. 실행한 익스플로잇과 추론한 소스 발견은 다르게 표시하세요. 에이전트가 애플리케이션을 실행할 수 없었다면, 발견 내에서 그 사실을 밝혀야지 스캔 수준의 메모에 한계를 묻어서는 안 됩니다.

그다음 간단한 처리 어휘를 적용하세요. 확인됨, 가능성 높음, 맥락 필요, 재현 불가, 수용된 위험, 수정됨입니다. “오탐”은 팀이 심각도를 싫어하거나 작업을 미루기로 한 것이 아니라 보안 주장이 틀렸다는 뜻이어야 합니다. 이 결정을 섞으면 피드백이 망가집니다. 원치 않는 티켓마다 같은 라벨을 붙이면 에이전트는 어느 규칙이 실패했는지 배울 수 없습니다.

AI는 중복 추적을 묶고, 정화 처리를 확인하고, 수정 뒤 재테스트하여 소음을 줄일 수 있습니다. 반대로 약한 의심 하나를 설득력 있는 열 가지 변형으로 만들어 소음을 키울 수도 있습니다. URL이 아니라 근본 원인과 경계로 중복을 제거하세요. 여덟 개 엔드포인트가 쓰는 누락된 소유권 검사는 노출 지점이 여덟 개인 하나의 엔지니어링 결함입니다.

범주와 테스트 출처별로 정확도를 추적하세요. 에이전트가 만든 크로스 사이트 스크립팅 보고서는 대체로 유효하지만 경쟁 조건 주장은 거의 재현되지 않는다면 서로 다르게 처리하세요. 관련 없는 결함 유형을 하나의 점수로 줄이지 마세요. 게이트는 모델의 자신감 형용사가 아니라 증거와 정책으로 실패해야 합니다.

책임 소재가 순환을 마무리합니다. 수용된 모든 발견에는 수정 책임을 질 사람이나 팀, 예상 재테스트 방법, 다른 테스터가 실행할 수 있는 보존된 증명이 필요합니다. 보고서가 에이전트 대화 안에만 있으면 대화, 모델, 벤더가 바뀔 때 사라집니다. 보안 작업은 그것을 만든 도구보다 증거가 오래 남을 때 지속성을 갖습니다.

분류 중에도 개인정보는 중요합니다. 소스, 요청 본문, 로그, 데이터베이스 샘플에는 자격 증명이나 고객 데이터가 들어 있을 수 있습니다. 에이전트가 받는 자료를 최소화하고, 보존하는 기록을 가리고, 테스트 데이터와 운영 데이터를 분리하며, 모델 제공업체와 도구에 조직의 승인된 데이터 처리 규칙을 적용하세요. 더 잘 탐지한다는 이유로 운영 사고 전체를 통제되지 않은 프롬프트에 복사해도 되는 것은 아닙니다.

사람의 침투 테스트는 테스트 주변의 가정을 시험합니다

숙련된 침투 테스터는 애플리케이션이 의뢰 내용과 다를 때 계획을 바꿉니다. 에이전트가 대체하지 못한 부분이 바로 이것입니다. 사람은 책임자를 인터뷰하고, 모호한 규칙을 해결하고, 운영상 지름길을 알아차리고, 다른 신원을 요청하며, 이상한 동작이 더 긴 실험 사슬을 할 가치가 있는지 판단합니다.

사람은 불완전한 증거 아래에서 판단할 책임도 집니다. 기술적으로 가능한 행동과 그럴듯한 공격 경로를 구분하고, 복합적인 실패를 경영진과 엔지니어에게 설명하며, 악용이 데이터를 손상할 수 있을 때 안전한 증명을 협의할 수 있습니다. 자율 에이전트는 운영자가 설정한 경계에서 멈춰야 합니다. 그 경계를 조용히 넓힌다면 또 하나의 보안 위험이 됩니다.

그렇다고 모든 릴리스에 일주일짜리 외부 계약이 필요한 것은 아닙니다. 변화와 결과가 만나는 곳에 사람의 테스트를 쓰세요. 새 권한 모델, 테넌트 아키텍처, 결제나 크레딧 흐름, 관리 영역, 민감한 통합, 대규모 마이그레이션, 공개 출시가 그 대상입니다. 위험을 기준으로 더 넓은 정기 작업을 계획하고 심각한 수정은 재테스트하세요. 일상 릴리스에도 자동화된 범위는 계속 필요합니다.

테스터에게 에이전트 결과, SAST 추적, DAST 범위, 아키텍처 메모, 테스트 계정, 해결되지 않은 가정을 제공하세요. 에이전트는 정찰과 반복 변형을 맡고, 테스터는 예상 밖의 동작을 추적할 수 있습니다. 이는 사람의 시간을 더 생산적으로 쓰게 하지만 사람이 필요 없다는 뜻은 아닙니다.

발견 수로 측정한 “자율 침투 테스트” 주장은 경계하세요. 익숙한 인젝션 발견 열 건은 역할 할당, 오래된 권한, 내보내기 스토리지를 가로지르는 입증된 경로 하나와 같지 않습니다. 테스트한 경계, 증거의 품질, 도전한 중요한 가정으로 작업을 판단하세요.

계약 시작 전에 정리를 누가 맡는지 물어보세요. 테스트 계정, 업로드 파일, 대기 중인 메시지, 임시 역할, 변경한 기능 플래그는 스캔이 끝난 뒤에도 남을 수 있습니다. 사람 책임자는 파괴적인 증명을 승인하고, 운영팀과 연락을 유지하며, 복구를 확인해야 합니다. 에이전트는 정리 스크립트를 따를 수 있지만, 설명되지 않는 운영 상태를 지워도 안전한지 판단할 수는 없습니다.

좋은 테스터는 테스트할 수 없었던 것도 보고합니다. 누락된 모바일 빌드, 사용할 수 없는 역할, 속도 제한, 타사 콜백, 불안정한 환경은 보증 수준을 낮춥니다. 에이전트는 장애물을 피해 계속 작업하고 완료한 경로를 제시하는 경향이 있습니다. 최종 보고서에서는 제외 사항을 눈에 띄게 밝혀야 깨끗한 결과를 완전한 범위로 오해하지 않습니다.

여러 종류의 증거로 하나의 게이트를 만드세요

올바른 프로그램은 각 방법에 역할을 주고, 그 결과가 같은 보안 요구 사항에서 만나게 합니다. 결정적인 소스 패턴과 넓은 변경 범위에는 SAST를 사용하세요. 의존성과 빌드 사실에는 SCA와 출처 관리를 사용하세요. 배포된 동작과 기본 런타임 검사에는 DAST를 사용하세요. 에이전트는 증거를 연결하고, 인증된 흐름을 탐색하고, 테스트를 만들고, 분류를 개선하는 데 쓰세요. 사람은 정책을 정의하고, 비즈니스 가정에 도전하며, 결과가 큰 변경을 조사해야 합니다.

그러면 출시 정책을 구체적으로 만들 수 있습니다. 결정적인 고심각도 규칙이 승인되지 않은 경로와 일치할 때, 필수 권한 불변 조건이 실패할 때, 테넌트 간 표식이 나타날 때, 확인된 익스플로잇이 열려 있을 때 빌드를 차단하세요. 불확실한 에이전트 발견은 노출 정도에 따른 기한을 정해 검토로 보내세요. 모델이 스스로 보고한 자신감으로 운영 출시 여부를 결정하게 하지 마세요.

증거는 이동 가능하게 보관하세요. 팀이 에이전트 없이도 검사할 수 있는 형식으로 발견, 생성된 테스트, 요청 기록, 도구 버전, 리비전, 신원, 범위, 처리 결과를 내보내세요. 이는 감사, 사고 검토, 벤더 변경, 모델 업데이트가 동작을 바꾸는 평범한 날에 중요합니다.

채팅으로 만든 애플리케이션도 같은 분리가 적용됩니다. Koder.ai는 웹, 서버, 모바일 애플리케이션을 만들고 소스를 내보낼 수 있지만, 생성된 소프트웨어에도 명시적인 보안 요구 사항과 배포된 결과에 대한 독립적인 테스트가 필요합니다. 빠른 제작은 아키텍처와 코드가 빠르게 바뀔 수 있으므로 명확한 게이트를 더 유용하게 만듭니다.

에이전트는 계속 실행하되, 가장 좋은 발견은 결정적인 회귀 테스트로 승격하세요. 확인된 모든 권한 우회는 정책 사례가 되어야 합니다. 모든 테넌트 누출은 실패한 경계의 불변 조건을 하나 더해야 합니다. 소음이 컸던 모든 규칙에는 처리 결과를 기록해야 합니다. 시간이 갈수록 에이전트는 자신이 처음 만난 테스트 시스템보다 더 정확한 시스템을 남겨야 합니다.

어느 도구 하나가 이기는지 묻지 마세요. 중요한 주장마다 독립적인 증거가 있는지 물어보세요. 코드 경로를 검토했는지, 배포된 동작을 실행했는지, 비즈니스 규칙이 책임자에게서 나왔는지, 실패 시 피해가 큰 곳에서 사람이 가정에 도전했는지 말입니다. 이 중 한 줄이라도 비어 있다면 AI가 만든 “문제없음”은 그 빈자리를 채우지 못합니다.