AI 익스플로잇의 비밀: AI 지원 취약점 관리를 위한 청사진

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

작성자: 줄스 차르니악

소개 

Mandiant M-Trends 2026 보고서에서 강조한 바와 같이, 평균 익스플로잇 시간 (TTE)이 -7일로 단축되어 패치가 출시되기도 전에 취약점이 익스플로잇되는 경우가 많습니다. 

이에 발맞추기 위해 많은 보안팀이 자동화된 취약점 발견 및 해결을 위해 대규모 언어 모델 (LLM) 에이전트를 코드베이스, 개발 환경, 지속적 통합 및 지속적 배포 (CI/CD) 파이프라인에 통합하는 방법을 모색하고 있습니다. 그러나 성숙한 통합 프로세스 없이 권한이 있는 AI 에이전트를 배포하면 새로운 아키텍처 위험이 발생합니다. 

이 블로그에서는 취약점 관리 워크플로에 AI 기능을 안전하게 통합하는 방법에 대한 고객 문의에 대한 답변으로, Mandiant Consulting에서 AI 지원 취약점 관리를 위한 운영 가드레일을 설정하는 방법에 대한 실행 가능한 안내를 제공하며, 몇 가지 상세한 시나리오도 포함되어 있습니다. 이러한 예시를 통해 보안팀이 AI로 워크플로를 가속화하면서도 환경의 구조적 무결성을 유지할 수 있음을 알 수 있습니다. AI 기능과 결정적 제어, 인간의 지능을 전략적인 방식으로 결합하면 이점을 극대화하고 위험을 줄일 수 있습니다. 

AI 에이전트를 안전하게 배포하기 위한 운영 가드레일 설정

조직은 배포 파이프라인에 예측할 수 없는 오류를 도입하지 않고도 고급 AI 기능을 안전하게 도입하기 위해 확립된 업계 표준에 접근방식을 기반으로 해야 합니다. NIST AI 위험 관리 프레임워크 (RMF) 및 LLM용 OWASP 상위 10개과 같은 가이드라인은 위험을 식별하기 위한 포괄적인 기준을 제공하지만, 이러한 제어를 운영하려면 구조적 청사진이 필요합니다.

Google의 안전한 AI 프레임워크 (SAIF) 및 Google의 안전한 AI 에이전트 접근 방식과 같은 프레임워크는 조직이 기존의 결정적 제어를 AI 실행 환경으로 직접 확장하도록 요구하는 실용적인 경로를 제공합니다. AI 에이전트를 배포할 때 보안팀은 다음과 같은 특정 운영 및 구조적 위험을 탐색해야 합니다.

• 에이전트 사전 데이터 보안 및 심층 방어: 에이전트는 개인 식별 정보 (PII), 보호 건강 정보 (PHI) 또는 기타 민감한 정보에 액세스할 수 없어야 합니다. 조직은 프롬프트가 모델에 도달하기 전에 데이터 보안을 적용해야 합니다. 여기에는 테스트를 위해 합성 데이터로 채워진 비프로덕션 환경을 엄격하게 사용하는 것이 포함됩니다. 프로덕션의 경우 보안팀은 하이브리드 심층 방어 모델을 배포해야 합니다. 여기에는 Model Armor 또는 유사한 공급업체에 구애받지 않는 안전 장치와 같은 특수 가드 모델과 같은 레이어 2 추론 기반 방어와 함께 병목 지점 역할을 하는 레이어 1 결정적 정책 엔진이 포함됩니다. 이러한 엔진은 에이전트 레이어에 도달하기 전에 민감한 정보를 필터링하고 악의적인 프롬프트 삽입을 차단합니다. 취약점 발견에 있어 중요한 점은 보안팀이 코드베이스 자체를 신뢰할 수 없는 입력으로 취급해야 한다는 것입니다. 위협 행위자는 소스 코드 주석이나 서드 파티 종속 항목 (예: 에이전트에 취약점을 무시하거나 환경 변수를 무단 반출하라고 지시하는 숨겨진 명령어) 내에 간접적인 프롬프트 삽입을 삽입할 수 있으므로 내부 스캔에도 입력 정리가 필요합니다.

• 클라우드 제공업체 제한 및 데이터 보관 기간 0 (ZDR): 많은 클라우드 및 LLM 제공업체는 남용을 방지하기 위해 기본적으로 자동화된 공격 보안 프로빙을 차단하거나 제한합니다. 조직은 허용 가능한 사용 정책을 탐색하기 위해 명확한 참여 규칙과 승인된 테스트 계약을 수립해야 합니다. 또한 조직은 LLM 제공업체와 엄격한 제로 데이터 보관 (ZDR) 계약을 체결하여 독점 코드와 발견된 취약점이 외부 모델을 학습시키는 데 절대 사용되지 않도록 보장해야 합니다.

• 워크로드 격리: 에이전트 워크로드는 엄격하게 격리된 권한 없는 컨테이너에서 동적으로 제한된 권한으로 실행되어야 합니다. 권한 에스컬레이션을 방지하기 위해 강력한 샌드박싱에 의존함으로써 에이전트가 파괴적인 명령을 할루시네이션하거나 프롬프트 인젝션을 통해 하이재킹되더라도 영향 범위는 제한됩니다.

• 레드팀 구성: 조직은 샌드박스를 동적으로 가동하고 코드를 실행할 수 있는 자율적인 취약점 스캐너를 배포하기 전에 포괄적인 보증 노력의 일환으로 AI 에이전트 자체를 인간 주도의 레드팀 구성에 적용해야 합니다. 이는 탈옥, 순환 논리 루프, 복잡한 프롬프트 인젝션에 대한 에이전트의 복원력을 검증하여 보안 도구가 공격 벡터가 되지 않도록 합니다.

• 최소 권한 머신 ID 및 인간 컨트롤러: 워크로드는 격리되어야 하지만 에이전트는 풀 요청을 생성하고 코드를 커밋하기 위해 본질적으로 권한이 필요합니다. 보안팀은 이러한 에이전트가 인간 컨트롤러와 연결되어 책임 소재와 사용자 동의를 보장하는 고유하고 엄격하게 범위가 지정된 머신 ID로 작동하는지 확인해야 합니다. 조직은 검토 중인 특정 저장소 및 브랜치에만 바인딩된 수명이 짧은 JIT (Just-In-Time) 토큰을 사용해야 합니다. 이는 에이전트 권한 제한 원칙을 적용하며, 프롬프트 인젝션을 통해 에이전트의 컨테이너가 보안 침해되더라도 공격자가 피벗하여 인접한 엔터프라이즈 코드베이스를 수정할 수 없도록 합니다.

• 기술 공급망 복원력: 개발자가 서드 파티 기술과 모델 컨텍스트 프로토콜 (MCP) 서버로 AI를 보강할 때 보안팀은 이러한 통합을 신뢰할 수 없는 공급망 구성요소로 취급해야 합니다. MCP 플러그인은 이전에 양성이었던 통합이 악성 종속 항목으로 자동 업데이트되는 공급망 포이즈닝의 위험을 야기합니다. 또한 보안팀은 세션 메모리 포이즈닝 또는 순환 루프 하이재킹과 같은 고유한 취약점에 대해 기본 에이전트 조정 프레임워크 (예: LangChain, AutoGen) 자체를 평가해야 합니다.

• 유해 흐름 분석 (TFA) 및 관찰 가능한 작업: TFA의 목표는 런타임 시 데이터 경로를 모니터링하여 에이전트가 민감한 내부 컨텍스트를 검증되지 않은 외부 엔드포인트로 무단 반출하지 않도록 하는 것입니다. 에이전트의 작업, 입력, 추론, 출력은 완전히 관찰 가능해야 하며 투명하게 기록되어야 합니다. LLM에 대한 동적 taint 추적을 구현하는 것은 여전히 복잡한 아키텍처 과제이지만, 조직은 이 런타임 관측 가능성을 정적 공급망 제어와 명확하게 분리해야 합니다. 위협 인텔리전스를 통합하여 수신되는 에이전트 도구를 해싱하고 검증하면 배포 전에 무결성을 검증하는 데 필요한 기준을 제공할 수 있습니다. 그러나 정적 제어는 배포 후 동작을 해결할 수 없기 때문에 데이터 무단 반출을 완화하려면 궁극적으로 실제 데이터 흐름을 추적하고 제한하기 위한 안전한 중앙 집중식 로깅과 활성 런타임 모니터링이 필요합니다.

조직은 검증 가능한 무결성과 구조적 복원력을 요구하는 프레임워크 내에서 이러한 도구를 운영함으로써 AI 속도와 엔터프라이즈 방어 사이의 격차를 안전하게 해소할 수 있습니다.

인간 주도 위협 모델링의 필요성

LLM은 문법 패턴을 식별하는 데 탁월하지만 소스 코드 자체에는 작성되지 않은 비즈니스 의도의 전체 그림이 거의 포함되어 있지 않습니다. 일부 조직에서는 검색 증강 생성 (RAG)을 사용하여 LLM 에이전트를 내부 위키, 설계 문서, 이슈 트래커에 연결하여 이 문제를 해결하려고 시도합니다.

RAG는 모델에 외부 비즈니스 컨텍스트에 대한 액세스 권한을 제공하지만 완벽한 해결책은 아닙니다. 기업 문서가 오래되었거나, 모순되거나, 불완전한 경우가 많습니다. AI 에이전트가 오래된 아키텍처 다이어그램을 검색하고 프로덕션에 더 이상 존재하지 않는 안전한 경로를 자신 있게 할루시네이션할 수 있습니다. LLM 에이전트는 상충되는 문서화되지 않은 인간의 가정을 해결하는 데 어려움을 겪기 때문에 인간이 주도하는 위협 모델링은 레거시 애플리케이션과 최신 에이전트 워크플로 모두에서 중요한 보안 제어 장치로 남아 있습니다.

보안팀은 빌드 전 시스템 설계 단계에서 위협 모델링을 적용하여 안전한 기반을 구축하고 빌드 후 아키텍처 검토 단계에서도 위협 모델링을 적용해야 합니다. AI 에이전트는 로컬에서 잘못 구성된 내부 엔드포인트를 성공적으로 식별할 수 있지만, 인간 위협 모델러는 왜 해당 마이크로서비스가 광범위한 데이터베이스 읽기 권한을 가지고 있는가?라는 구조적인 질문을 던집니다. 

아키텍처 취약점을 식별하려면 비즈니스 위험, 데이터 민감도, 운영 제약 조건에 대해 추론해야 합니다. 이 프로세스를 체계화하기 위해 조직은 PASTA (Process for Attack Simulation and Threat Analysis)와 같은 업계 프레임워크 또는 Mandiant Threat Modeling Security Service와 같은 서비스 제품을 사용하여 신뢰 경계를 매핑하고, 구조적 설계 결함을 발견하고, 보정 제어의 우선순위를 정할 수 있습니다. 자동화된 에이전트에 의존하여 잘못 설계된 시스템에서 버그를 찾을 때는 인간의 감독을 통해 기본 아키텍처를 보호하는 것이 필수적인 구성요소입니다.

SAIF의 안내에 따라 이러한 AI 에이전트를 안전하게 샌드박싱하고 위협 모델링을 통해 아키텍처를 검증한 후에는 일반적으로 두 가지 문제 영역에 적용할 수 있습니다. 하나는 엔터프라이즈 취약점 관리 (상용 기성품 (COTS) 소프트웨어 및 인프라에서 알려진 CVE의 양을 관리하는 데 도움을 줌)이고, 다른 하나는 제품 보안 (퍼스트 파티 (1P) 코드의 취약점을 식별함)입니다.

트랙 1: 엔터프라이즈 취약점 관리

기본적인 보안 및 검색 

이 게시물의 두 번째 트랙에서는 AI 에이전트가 커스텀 코드에서 복잡한 제로데이 취약점을 어떻게 찾아낼 수 있는지 살펴봅니다. 조직은 이러한 AI 배포와 함께 엔터프라이즈 인프라의 규모를 관리해야 합니다. 새로운 AI 기능이 헤드라인을 장식하고 있지만 조직은 여전히 보안 비밀 확산, 관리되지 않는 서비스 계정, FIDO2 MFA 누락, 기존 VPN 집중 장치와 같은 기본적인 보안 문제를 해결해야 합니다. 취약점 익스플로잇은 Mandiant가 작년에 조사한 침입의 주요 초기 감염 벡터였지만, 공격자는 취약점을 익스플로잇한 후 발판을 확보하고 확대하기 위해 누락된 기본 제어와 패치되지 않은 에지 기기에 지속적으로 의존합니다.

또한 AI는 기본적인 가시성을 대체할 수 없습니다. 보안팀은 AI 에이전트를 배포하는 동시에 외부 공격 표면 관리 (EASM), 클라우드 보안 상황 관리 (CSPM), 지속적인 위협 노출 관리 (CTEM)와 같은 동적 탐색 기능을 극대화하여 이러한 전술적 진입점을 닫아야 합니다. 하이브리드 및 클라우드 환경에서는 Wiz와 같은 도구를 사용하여 이 초기 설치 공간을 매핑할 수 있습니다.

위험 기반 취약점 관리 

취약점 관리팀은 이미 기존 스캐너에서 생성되는 발견 항목의 양에 압도되어 있습니다. 조직에서 자동화된 AI 에이전트와 함께 EASM, CSPM, CTEM과 같은 동적 탐색 도구를 확장하면 이러한 발견의 유입이 문제를 더욱 복잡하게 만들 것입니다. 이러한 유입을 관리하려면 먼저 다양한 검색 방법의 원격 분석을 정규화하고 중복 제거해야 합니다. 이 정규화된 데이터는 두 가지 목적으로 사용됩니다. 하나는 위험 엔진에 직접 공급되는 것이고, 다른 하나는 구성 관리 데이터베이스 (CMDB)의 오래된 레코드를 수정하는 라이브 오버레이 역할을 하는 것입니다. RBVM 엔진은 새로 업데이트된 애셋 컨텍스트 및 일선 위협 인텔리전스와 함께 중복 제거된 취약점을 평가하여 보안팀이 문제 해결의 우선순위를 동적으로 지정할 수 있는 맞춤 위험 점수를 계산합니다.

성숙한 RBVM 방법론은 가중 평균을 사용하여 0~100점 척도로 맞춤화된 위험 점수를 계산합니다. 이 위험 기반 점수를 계산하는 샘플 공식은 다음과 같습니다.

최종 점수 = (W_1 * S_vuln) + (W_2 * S_asset) + (W_3 * S_threat)

변수와 가중치 (W)는 조직의 위험 감수 성향에 맞게 맞춤설정됩니다 (예: 취약점 0.20, 애셋 0.40, 위협 0.40, 합계 1.0). 기본 변수 (S)는 0~100점 척도로 점수가 매겨지며 다음과 같이 정의됩니다.

• 취약점 심각도 (S_vuln): 결함의 고유한 기술적 심각도입니다. CVSS 기본 점수 (기밀성, 무결성, 가용성 영향을 기본적으로 고려함)에 10을 곱하여 계산합니다.

• 애셋 컨텍스트 (S_asset): 노출 및 데이터 민감도의 결합된 측정항목입니다. 점수는 고객 데이터를 보유한 인터넷 연결 애셋의 경우 100점, 민감한 정보가 없는 내부 전용 애셋의 경우 25점입니다. 이러한 영향을 비기술적 이해관계자를 위한 금전적 용어로 변환하기 위해 조직은 정보 위험 요소 분석 (FAIR) 원칙을 이 측정항목에 통합할 수 있습니다. 그러나 이 접근방식에는 매우 정확하고 지속적으로 업데이트되는 재무 데이터가 필요하며, 많은 기업이 이를 대규모로 유지하는 데 어려움을 겪고 있습니다.

• 위협 컨텍스트 (S_threat): 취약점의 실제 긴급성 조직의 프로필과 관련된 위협 행위자가 활발하게 악용하는 경우 100점, 개념 증명(PoC)이 존재하거나 자율 AI 에이전트가 쉽게 악용할 수 있는 취약점 클래스인 경우 75점, 악용이 이론적이고 매우 복잡한 경우 25점입니다. 조직은 또한 Exploit Prediction Scoring System (EPSS) 확률 백분율을 이 변수에 직접 매핑해야 합니다. 이를 통해 실제 익스플로잇 텔레메트리가 이동함에 따라 위협 점수를 자동으로 확장 또는 축소하여 정적 취약점 데이터를 활성 위협 인텔리전스와 정렬할 수 있습니다.

CISA Binding Operational Directives (BOD)와 같은 외부 규정 준수 기반 명령 또는 관련 동급 명령이 내부 우선순위를 재정의하지 않는 한 애셋의 맞춤설정된 위험 점수는 내부 해결 서비스 수준 계약 (SLA)에 직접적인 영향을 미쳐야 합니다. 위험 및 Threat Intelligence 기반 취약점 우선순위 지정 방법론은 조직이 가장 중요한 보안 취약점을 먼저 관리하고 완화하는 데 리소스를 집중하는 데 도움이 됩니다. 이러한 영역에서 LLM은 취약점 관리 프로세스를 지원할 수 있습니다. 특히 팀이 비정형 위협 인텔리전스를 종합하여 관련 위험 컨텍스트를 보다 효율적으로 파악할 수 있도록 지원합니다. 패치에 대한 엄격한 SLO를 적용하고 패치 예외에 대한 공식적인 위험 수용 문서를 요구하면 위협 행위자가 사용할 수 있는 취약점의 수를 줄이고 조직 전반의 미해결 위험에 대한 가시성을 높이는 데 도움이 됩니다. 또한 조직은 자동화된 알림 보강을 위해 RBVM 데이터를 보안 조정, 자동화, 응답 (SOAR) 플랫폼에 직접 통합해야 합니다.

격리 및 관측 가능성

최신 아키텍처 청사진은 취약점이 불가피하게 악용될 것이라는 가정하에 공격 표면 축소를 우선시해야 합니다. 조직은 기존의 경계 방어에서 벗어나 제로 트러스트 원칙에 따라 모든 애셋, 워크로드, ID 주변에 보안 경계를 설정해야 합니다.

이러한 조정의 한 구성요소는 강력한 인증 원칙을 구현하는 것입니다. 조직은 지속적인 컨텍스트 인식 인증 및 승인을 적용하여 암시적 신뢰를 제거해야 합니다. IAP (Identity-Aware Proxy)와 같은 ZTNA (제로 트러스트 네트워크 액세스) 솔루션을 활용하면 중요한 관리 인터페이스 (예: SSH, RDP)와 내부 시스템을 인터넷에 직접 노출되지 않도록 보호하여 검증된 ID와 규정을 준수하는 기기에만 액세스 권한을 부여할 수 있습니다.

공개 애플리케이션 및 API의 경우 공격 표면 축소에는 부하 분산기 또는 API 게이트웨이 수준에서 레이어 7 검사를 배포하는 것이 포함됩니다. 이 강화 레이어는 엄격한 스키마 검증을 적용하여 내부 애플리케이션 로직과 상호작용하기 전에 잘못된 형식의 인바운드 트래픽과 잠재적인 취약점을 가로채고 무력화합니다.

소프트웨어 공급망 보호는 최신 청사진에서 똑같이 중요한 부분이며, 조직은 종속 항목과 빌드 트랙 모두에서 SLSA (Supply-chain Levels for Software Artifacts)와 같은 프레임워크에 맞춰야 합니다. 보안 정책은 서드 파티 종속 항목이 Google Assured Open Source Software (OSS) 또는 이와 동등한 솔루션과 같은 자동 선별 서비스가 갖춰진 중앙 집중식 아티팩트 저장소를 통해 라우팅되도록 의무화하여 신뢰할 수 없는 코드가 개발 수명 주기에 들어가지 못하도록 해야 합니다. 또한 CI/CD 실행기를 위한 임시 컴퓨팅 인프라를 통해 격리, 임시성, 재현 가능성 요구사항을 구현하여 고급 SLSA 빌드 수준 (예: SLSA 레벨 3)으로 성숙해지면 환경이 수명이 짧고 자동으로 순환되도록 보장하여 공격자 지속성의 가능성을 줄일 수 있습니다.

이러한 사전 빌드 제어를 보완하기 위해 모든 프로덕션 워크로드에서 런타임 관측 가능성을 확립해야 합니다. 이를 위해서는 인프라 수준의 동작과 프로덕션에서 활발하게 실행 중인 특정 런타임 라이브러리를 모두 모니터링해야 하며, 이를 통해 정적 소프트웨어 자재 명세서(SBOM)를 훨씬 뛰어넘는 진정한 익스플로잇 가능 위험을 파악할 수 있습니다. 조직은 워크로드 모니터링과 함께 워크로드 아이덴티티 제휴를 구현하여 인증 방식을 보호해야 합니다. 조직은 정적 사용자 인증 정보를 삭제하고 강력한 암호화 ID 확인을 기반으로 하는 단기 토큰을 대신 사용함으로써 사용자 인증 정보 도용 및 무단 측면 이동의 위험을 줄일 수 있습니다.

내부 환경에서는 마이크로세분화를 적용하여 플랫 네트워크를 세분화된 보안 영역으로 분할해야 합니다. Secure Access Service Edge (SASE) 아키텍처를 통해 애플리케이션 트래픽을 라우팅하면 네트워크 라우팅이 강력한 ID 제어와 직접 통합되어 인증되지 않은 사용자에게 내부 서비스가 완전히 표시되지 않으며 위협이 초기 진입점으로 제한됩니다.

마지막으로, 제로 트러스트 프레임워크 내의 자동화된 격리 및 사고 대응은 결정적이고 감사 가능한 도구를 기반으로 해야 합니다. 엔드포인트 감지 및 대응 (EDR) 플랫폼과 SOAR 플레이북은 하드코딩된 실행 로직을 통해 충실도가 높은 격리 작업을 처리해야 합니다. AI 도구는 분류 및 정책 추천을 가속화하지만, 전체적인 아키텍처 예측 가능성을 유지하려면 실제 실행 기능은 사전에 테스트된 잘 정의된 워크플로로 제한되어야 합니다.

트랙 2: 제품 보안 및 개발 (1P 코드)

결정론적 및 확률적 도구

LLM 에이전트를 취약점 관리 및 보안 워크플로에 통합하려면 결정론적 도구와 확률론적 도구의 차이점을 인식해야 합니다. 기존의 SAST 및 DAST 도구는 고정된 방법론을 활용하여 구조적 코드 파싱 또는 명확한 런타임 관찰을 통해 취약점을 평가합니다. 그러나 LLM은 결정적 실행 트랙을 추적하는 대신 토큰을 동시에 처리하여 통계적 관계와 의미적 관계를 계산함으로써 소스 코드를 평가합니다.

연쇄 사고 (CoT) 프롬프팅과 같은 기법을 사용하면 모델이 복잡한 코드 경로를 중간 추론 단계로 분해하여 이 격차를 해소할 수 있지만, 이 프로세스는 여전히 아키텍처의 한계에 묶여 있습니다. 모델이 전체 저장소를 수집할 수 있을 만큼 큰 컨텍스트 윈도우를 가지고 있더라도 긴 입력에 걸쳐 어텐션 저하가 발생할 수 있으며, 프롬프트 내에서 개입하는 검증 또는 삭제 로직에 올바르게 가중치를 부여하지 못하는 경우가 많습니다. 예를 들어 변수가 10번째 줄에서 오염되었지만 500번째 줄에서 정리된 경우, 어텐션 저하로 인해 모델이 정리 로직을 추적하지 못할 수 있습니다. 또한 엔터프라이즈 코드베이스가 컨텍스트 한도 내에 맞추기 위해 청킹을 필요로 하는 경우, 결과적으로 발생하는 단편화로 인해 모델이 엔드 투 엔드 데이터 흐름을 추적하지 못할 수 있습니다.

따라서 확률적 엔진은 하드 코딩된 사용자 인증 정보나 오래된 종속 항목과 같은 국소화된 정적 이상치를 발견하는 데 효과적이지만, 분할된 청크나 확장된 컨텍스트 윈도우에 걸쳐 분산된 복잡한 취약점을 잘못 판단하는 경우가 많습니다. 이러한 확률 모델이 결정적 피드백 루프와 결합될 때는 주목할 만한 예외가 발생합니다. 예를 들어 C++ 메모리 손상을 분석할 때 LLM에 테스트 하네스를 장착하여 코드를 반복적으로 실행하고 충돌을 확실하게 증명할 수 있습니다. 이러한 동적 검증 애플리케이션은 다음 섹션에서 자세히 설명하지만, 표준 엔터프라이즈 코드베이스 전반의 정적 분석에 대한 기준 제한사항은 여전히 모델이 분산된 로직을 일관되게 평가하는 데 어려움을 겪는다는 것입니다.

바이너리 및 아키텍처 오라클

많은 보안 프로그램이 에이전트 워크플로로 전환하고 있습니다. 에이전트는 자율적으로 테스트 환경을 스핀업하고 도구를 사용하여 페이로드를 실행하고 발견 항목을 검증합니다. 이 접근방식은 유망하지만, 어디에서 가장 효과적인지 이해하는 것이 중요합니다.

에이전트 워크플로는 바이너리 및 관찰 가능한 오라클이 있는 버그 클래스에 대해 우수한 성능을 발휘합니다. 즉, 시스템은 객관적인 '크래시 또는 노 크래시' 피드백 루프를 제공합니다. 예를 들어 모델이 C++ 커널에서 메모리 손상을 찾고 있는 경우 성공적인 취약점 공격은 부인할 수 없습니다. 페이로드가 실행되고 결과로 발생하는 충돌이 취약점을 확실하게 증명합니다. 이러한 이유로 업계에서는 현재 웹브라우저, 운영체제 등 메모리 안전성이 낮은 타겟 전반에서 AI가 발견한 취약점이 급증하고 있습니다.

그러나 엔터프라이즈 소프트웨어는 검증을 위해 아키텍처 오라클이 필요한 취약점이 지배적입니다. 권한 부여 우회, 복잡한 비즈니스 로직 결함, 간접 서버 측 요청 위조와 같은 취약점에는 비즈니스 컨텍스트와 서비스 간 신뢰 경계에 대한 이해가 필요합니다. 에이전트의 페이로드가 명확한 결과를 생성하지 못하면 취약점이 할루시네이션인지 아니면 페이로드를 잘못 구성한 것인지 신뢰할 수 있게 구별할 수 없습니다. 에이전트의 잘못된 형식의 페이로드는 관련 없는 백그라운드 프로세스를 충돌시키고 모델이 성공을 환각화하여 잘못된 확인을 보고하게 할 수도 있습니다. 복잡한 엔터프라이즈 아키텍처에는 확률적 엔진이 본질적으로 알 수 없는 비즈니스 의도가 포함되어 있습니다.

타겟팅된 배포 및 인간에 미치는 영향

취약점 발견을 위해 LLM을 도입하는 조직은 인력 확보에 큰 어려움을 겪고 있습니다. LLM은 인간 엔지니어가 분류할 수 있는 것보다 훨씬 빠르게 발견 항목을 생성할 수 있습니다. LLM이 생성한 모든 알림에 수동 검토가 필요한 경우 보안팀은 빠르게 번아웃되거나 알림 피로를 겪게 됩니다.

보안팀은 사용 가능한 모든 코드베이스에 에이전트를 무분별하게 지정하여 검증되지 않은 출력이 유입될 위험을 감수하는 대신 선별적인 배포 전략을 세워야 합니다. 성숙한 프로그램은 기준 위생 및 결정적 규칙 적용을 위해 SAST 및 DAST를 유지하고, 명확한 바이너리 오라클이 있는 영향력이 큰 구성요소에 대해 집중적인 에이전트 감사를 예약해야 합니다.

조직은 기술의 강점이 더 광범위한 위험 프로필과 일치하는 시스템에 대한 에이전트 감사를 우선시할 수 있습니다.

• 메모리 안전하지 않은 코드베이스: C, C++, 어셈블리와 같은 메모리 안전하지 않은 언어로 작성된 레거시 또는 고성능 구성요소는 LLM 감사의 강력한 후보입니다. 이러한 언어는 버퍼 오버플로 및 use-after-free 조건과 같은 메모리 손상 결함에 취약합니다. 이러한 취약점은 세그먼테이션 오류와 같은 명확한 실패 상태를 트리거하므로 에이전트가 메모리 위생 처리 도구로 코드를 컴파일하고 개념 증명 입력을 작성할 수 있는 자동화된 샌드박스에서 잘 작동합니다. 이 접근방식은 안전한 언어가 Python C 확장 프로그램이나 Java 네이티브 인터페이스 (JNI)와 같은 안전하지 않은 내부 라이브러리를 호출하는 네이티브 확장 프로그램을 감사하는 데도 효과적입니다.

• 외부 콘텐츠에 노출될 가능성이 높은 시스템: 퍼스트 파티 데이터 수집 파이프라인, 커스텀 API 게이트웨이 또는 독점 에지 프록시 여기서 전제 조건은 소스 코드에 직접 액세스할 수 있어야 한다는 것입니다. 이 전략은 조직이 로직을 검사할 수 있는 내부적으로 개발된 코드베이스 또는 완전한 오픈소스 코드베이스에만 적용됩니다. 이러한 시스템은 신뢰할 수 없는 인터넷 트래픽을 직접 파싱하므로 LLM 기반 감사를 위해 소스 코드를 타겟팅하면 위험 감소 ROI가 가장 높습니다.

• 공유 내부 라이브러리 및 유틸리티: 사내에서 유지관리되는 핵심 직렬화/역직렬화 패키지, 공통 유틸리티 함수, 커스텀 미들웨어 래퍼 (예: 내부 메시지 큐 파서) 엔터프라이즈가 이러한 공유 빌딩 블록의 소스 코드를 소유하고 있기 때문에 에이전트 도구는 자동화된 테스트 하니스 내에서 쉽게 연결하여 입력을 퍼징하고 충실도가 높은 하위 수준의 논리 또는 파싱 버그를 포착할 수 있습니다.

• 기본 보안 경계: 내부적으로 개발된 중앙 집중식 인증 서비스, 커스텀 OAuth 제공업체, 내부 사용자 인증 정보 브로커 복잡한 ID 경계를 테스트하면 논리 기반 노이즈가 더 많이 발생하지만, 소스 코드에 대한 전체 액세스 권한이 있으면 팀에서 에이전트를 결정적 검사와 페어링하여 인증 실패의 영향 범위가 사람의 노력을 정당화하는 경우 발견 항목을 안전하게 분류할 수 있습니다.

LLM에서 생성되는 노이즈를 필터링하려면 조직에서 라우팅 규칙을 설정해야 합니다. 에이전트가 익스플로잇을 증명하려고 시도하는 완전히 재현 가능한 결정적 테스트 하네스 (예: 컴파일된 바이너리 또는 Python 테스트 스크립트)를 생성하도록 요구합니다. 이 하네스는 격리된 모니터링되는 샌드박스에서 자동으로 실행되어야 합니다. 샌드박스 실행이 실패하면 (구문 오류 또는 익스플로잇 실패로 인해) 티켓이 폐기되어 인적 자원을 절약할 수 있습니다. 그러나 조직은 이러한 테스트 하네스에 실행 시간 제한과 반복 제한을 적용해야 합니다. 엄격한 제한이 없으면 취약점을 증명하려는 자율 에이전트가 스크립트를 작성하고, 실패하고, 다시 작성하고, 다시 실패하는 무한 루프에 빠질 수 있습니다. 단일한 막다른 골목 취약점에 대해 API 토큰 예산과 컴퓨팅 리소스를 소진하여 보안 검토를 진행하지 않고도 상당한 비용 초과를 발생시킬 수 있습니다. 이러한 비용을 관리하기 위해 조직은 FinOps 원칙을 통합하여 LLM 감사의 컴퓨팅 및 API 비용과 수동 분류의 기존 비용 간의 균형을 맞춰야 합니다.

그러나 샌드박스에서 성공적으로 실행된다고 해서 조치 가능한 우선순위가 높은 위험이 보장되는 것은 아닙니다. 실제로 자율 에이전트는 궁극적으로 관련이 없는 진정한 기술적 결함에 대해 작동하는 PoC를 자주 생성하거나 시스템의 위협 모델 컨텍스트 내에서 낮은 수정 우선순위를 보장합니다. 예를 들어 에이전트는 도달할 수 없는 데드 코드 경로를 성공적으로 악용하거나 실행에 관리자 액세스가 필요하고 권한이 더 이상 에스컬레이션되지 않는 버그를 트리거할 수 있습니다. 따라서 샌드박스에서 성공적인 실행을 등록한 경우에만 인간 엔지니어를 배정하여 티켓을 검토하고 우선순위를 지정해야 하며, 검토의 일부로 환경 컨텍스트, 도달 가능성, 실제 비즈니스 영향을 검증해야 합니다.

이 워크플로는 알림 수를 줄여주지만 보안팀의 워크로드가 완전히 사라지는 것은 아니라는 점을 이해하는 것이 중요합니다. 엔지니어의 주요 업무는 초기 취약점을 수동으로 헌팅하는 것에서 LLM이 생성한 증명을 감사하여 악용할 수 없거나 맥락상 관련이 없는 발견 사항이 아닌 의미 있는 위험을 나타내는지 확인하는 것으로 바뀝니다. 경영진은 이 새로운 현실에 맞게 팀에 적절한 인력을 배치하고 교육해야 합니다. LLM 에이전트를 배포한다고 해서 숙련된 실무자의 필요성이 사라지는 것은 아닙니다. 오히려 복잡한 검증을 수행하는 방향으로 워크로드가 재조정됩니다. 팀이 거짓양성의 위험을 인식하도록 교육하는 것도 마찬가지로 중요합니다. AI 생성 노이즈를 필터링하는 데 지나치게 집중하면 잘못된 보안 의식을 갖게 될 수 있습니다. 익스플로잇이 모델의 학습 데이터에서 가중치가 높지 않았던 새로운 기법이나 제로데이 취약점에 의존하는 경우, 에이전트는 이를 무시하고 조용히 스캔을 통과할 가능성이 높습니다. LLM은 검색을 보강하지만 포괄적인 범위를 보장하지는 않습니다.

LLM을 SAST 분류 파이프라인에 통합할 때 엔지니어는 더 광범위한 아키텍처 무결성도 확인해야 합니다. 특정 SAST 경고로 LLM에 프롬프트를 작성하면 컨텍스트가 좁아질 수 있습니다. 즉, 에이전트가 로컬화된 문법 오류를 해결하는 데 지나치게 집중하여 동일한 파일에 존재하는 더 광범위한 아키텍처 결함을 놓칠 수 있습니다. 또한 에이전트의 역할이 발견을 넘어 자동화된 해결 (예: 코드 수정 작성 및 제안)까지 확장되는 경우, LLM이 의도치 않게 새로운 회귀를 도입하거나 의도된 비즈니스 로직을 우회하지 않도록 인간 참여형 검증이 중요해집니다.

수정 및 강화

LLM 지원 코드 수정

소프트웨어 개발 수명 주기에 대규모 언어 모델 (LLM)을 통합하는 주된 목표는 자동화된 해결입니다. 이를 위해 조직은 통합 개발 환경 (IDE) 내에서 직접 또는 중앙 집중식 파이프라인 실행기로 두 가지 주요 실행 방법을 통해 이러한 기능을 배포하고 있습니다. 예로는 CodeMender가 있지만 이 글을 쓰는 시점에는 공개적으로 제공되지 않습니다.

IDE 통합 방식 

이 메서드는 능동적인 페어 프로그래머 역할을 수행하여 가능한 한 왼쪽으로 수정 작업을 이동합니다. IDE의 백그라운드에서 지속적인 정적 분석을 실행하는 도구는 인라인 표시기 또는 호버 툴팁과 같은 편집기 진단을 통해 개발자에게 취약점을 직접 표시합니다.

• 로컬 범위: 개발자는 LLM 에이전트를 트리거하여 로컬 데이터 흐름을 분석하고 파라미터화된 SQL 쿼리 구현과 같은 타겟 패치를 생성할 수 있습니다. LLM을 로컬화된 구문 수준 수정사항으로 제한하면 변경 범위가 제한됩니다. 이렇게 하면 에이전트가 복잡한 아키텍처 논리를 자주 깨뜨리는 광범위한 다중 파일 리팩터링을 시도하지 않습니다.

• 인간 참여형: 개발자가 코드를 커밋하기 전에 AI가 생성한 패치를 검토합니다.

• 거짓양성 관리: 로컬 IDE 에이전트를 사용하면 개발자가 거짓양성을 동적으로 관리할 수 있습니다. 특정 줄 텍스트에 고정된 알림을 억제하면 알림 피로를 줄이고 개발자의 신뢰를 유지할 수 있습니다.

CI/CD runner method 

러너 메서드는 CI/CD 파이프라인 내에서 비동기적으로 실행되어 LLM을 사용하여 커밋된 코드를 검토하고 자동으로 해결 방법을 제안합니다.

• 제한된 실행 및 결정론적 검증: 중앙 집중식 실행기에 복잡한 다중 파일 권한 결함을 기본 브랜치에서 직접 자동으로 다시 작성하도록 요청하면 논리 오류가 발생할 위험이 높습니다. 이러한 위험을 완화하려면 에이전트가 pull 요청 (PR)을 생성하는 것으로 제한되어야 합니다. PR이 생성되면 결정적 테스트 하니스와 함께 표준 회귀 도구 모음을 자동으로 실행해야 합니다. 패치된 코드에 대해 초기 PoC를 다시 실행하면 워크플로가 취약점이 해결되었음을 증명하기 위해 익스플로잇 스크립트를 검증 오라클로 재사용합니다. 그런 다음 엔지니어가 PR을 검토하여 병합하기 전에 아키텍처 논리를 검증합니다.

어떤 경우든 보안팀은 단일 접근방식에 의존하기보다는 두 가지 방법 간에 명확한 경계를 정의해야 합니다. IDE 에이전트는 즉각적인 구문 수준 지원을 제공합니다. 개발자가 코드를 커밋하기 전에 복잡성이 낮은 오류를 로컬에서 포착하고 해결합니다. 중앙 집중식 CI/CD Runner는 더 광범위한 조직 기준을 처리합니다. 로컬 환경을 우회하는 취약점에 대한 복잡한 저장소 전체 수정 사항을 제안합니다.

배포 후 제어 

사람의 검토와 결정론적 테스트 하네스를 사용하더라도 AI가 생성한 패치로 인해 프로덕션에 논리 회귀가 발생할 수 있습니다. 조직은 배포 후 엄격한 제어를 구현해야 합니다.

• 자동 롤백: LLM이 생성한 코드를 주요 아키텍처 변경사항과 동일한 배포 후 검토를 거치도록 처리하면 예기치 않은 회귀가 CI/CD 파이프라인을 통과하는 경우 환경을 알려진 양호한 상태로 되돌릴 수 있습니다.

• 모델 드리프트 완화: 관리형 AI 서비스에 의존하면 모델 드리프트의 지속적인 위험이 발생합니다. 조용한 가중치 업데이트로 인해 테스트 하니스가 중단되는 것을 방지하려면 조직에서 특정 모델 API 버전을 고정된 출시 버전에 고정해야 합니다. 고정된 버전이 지원 종료에 도달하면 조직은 강제 이전의 대상이 됩니다. 이러한 파이프라인 취약점을 완화하려면 모델 고정을 결정적 회귀 모음과 결합해야 합니다.

• 규정 준수 및 감사 가능성: AI 에이전트가 보안 티켓을 자동으로 종료하거나 CI/CD 파이프라인에서 패치를 생성하는 경우 조직은 SOC 2, PCI-DSS, FedRAMP, CMMC와 같은 프레임워크를 충족하기 위해 변경 불가능한 감사 로그를 유지해야 합니다. 국가 안보 배포는 데이터 주권 요구사항도 고려해야 합니다. 이 로깅은 수정사항을 제안한 특정 모델 버전, 이를 검증한 결정적 테스트 결과, 병합을 승인한 엔지니어를 기록해야 합니다. 또한 EU AI 법과 같은 새로운 법률은 고위험 애플리케이션에 대한 인간의 감독을 강조하므로 보안팀은 자율적인 해결 워크플로가 이러한 진화하는 글로벌 규제 표준에 어떻게 부합하는지 신중하게 평가해야 합니다.

결론

취약점 관리에 LLM을 활용하는 것은 다층 솔루션입니다. 이를 통합하려면 워크플로를 계층별로 분리해야 합니다. 엔터프라이즈 인프라 수준에서는 발견 항목과 구성 드리프트의 양을 처리하기 위해 위험 기반 취약점 관리 (RBVM)와 노출 관리가 필요합니다. 제품 및 코드 보안 수준에서 LLM 기반 취약점 평가 및 해결은 SAST 및 DAST와 같은 기본적인 결정적 제어와 함께 작동하여 커스텀, 오픈소스 또는 서드 파티 코드를 감사해야 합니다.

LLM은 기술 부채를 관리하고 취약점 발견을 가속화하는 데 도움이 될 수 있지만, 설계 단계부터 보안을 고려하는 원칙을 대체하지는 않습니다. LLM 에이전트가 다른 기본 벡터와 함께 메모리 안전하지 않은 코드베이스에서 로컬화된 메모리 손상을 식별하고 악용하는 데 탁월한 능력을 발휘하고 있다는 사실은 경각심을 일깨워 줍니다. 

소프트웨어 메모리 안전에 관한 NSA 지침에 부합하는 장기 전략으로 조직은 메모리 안전 언어를 새로운 내부 개발에 단계적으로 도입해야 합니다. LLM은 코드 마이그레이션에 필요한 수작업을 줄여 이 분야에서 가능한 작업을 확장하기 시작했습니다. 기존 C 또는 C++ 코드베이스를 Rust로 변환하는 것은 필요한 엔지니어링 시간이 너무 많기 때문에 역사적으로 비현실적이었습니다. 완전 자동화된 번역이 턴키 솔루션은 아니지만, LLM을 사용하여 엔지니어가 대량의 변환 작업을 수행하도록 지원하면 이러한 장기적인 마이그레이션을 운영상 실현 가능하게 만들 수 있습니다. 조직은 내부 노력 외에도 조달 요구사항을 사용하여 공급업체가 메모리 안전성이 낮은 언어에 대한 의존도를 줄이고 시간이 지남에 따라 안전한 구성 기본값을 설정하도록 장려해야 합니다. AI 속도와 엔터프라이즈 방어 사이의 격차를 해소하려면 현재 백로그를 관리하기 위한 자동화된 파이프라인을 빌드하는 동시에 설계상 전체 취약점 클래스와 잘못된 구성을 제거하는 시스템을 설계해야 합니다.

감사의 말씀

이 분석은 Google Threat Intelligence Group (GTIG)과 기타 광범위한 Google팀의 지원이 없었다면 가능하지 않았을 것입니다.