AI로 가속화되는 사이버 공격에 맞서는 보안 체계 강화 전략

이번 주 초, 저희는 Project Glasswing을 발표했습니다. 최신 프론티어 모델인 Claude Mythos Preview의 강력한 사이버 보안 역량을 방어 목적에 활용하려는 시도입니다. 발표문과 함께 공개된 기술 블로그 포스트에서는 AI 모델이 소프트웨어 취약점을 탐지하고 악용하는 데 필요한 자원, 시간, 전문 지식의 진입 장벽을 얼마나 빠르게 낮추고 있는지 설명했습니다.

AI의 눈부신 발전 속도를 고려하면, 유사한 수준의 모델이 광범위하게 보급되는 것은 시간문제입니다. 앞으로 24개월 안에, 코드 속에 수년간 발견되지 않았던 수많은 버그들이 AI 모델에 의해 찾아내지고, 실제로 작동하는 익스플로잇으로 연결될 것입니다. 실제로 현재 공개된 Mythos 이하 수준의 모델들도 이미 기존 전통적인 리뷰 방식이 오랫동안 놓쳐온 심각한 취약점을 발견하고 있습니다.

다행히 이는 양방향으로 작용합니다. 공격자가 AI를 활용해 더 빠르게 움직일 수 있는 것처럼, AI 도구를 도입해 스스로를 방어하는 보안 담당자들도 마찬가지입니다. 이 글에서는 실제 코드베이스와 시스템 보안에 프론티어 AI 모델을 활용하면서 저희 보안 팀과 연구진이 직접 관찰하고 체득한 내용을 바탕으로 보안 권고 사항과 실용적인 팁을 소개합니다. AI 기반 사이버 보안 시대에 접어드는 지금, 보안 팀과 관계자 모두에게 도움이 되기를 바랍니다.

아래 권고 사항 중 다수는 이미 보안 업계의 공통된 합의에 포함된 내용입니다. 저희는 실제로 효과가 유지되는 통제와 약화되는 통제를 직접 확인한 경험을 바탕으로 우선순위를 정했습니다. SOC 2나 ISO 27001 기준으로 보고하는 조직이라면, 이 내용들이 현재 추적 중인 통제 항목과 직접 연결될 것입니다.

Project Glasswing 파트너들과 사이버 보안 작업을 계속해 나가면서 이 가이드를 지속적으로 업데이트할 예정입니다.

지금 당장 해야 할 일

1. 패치 공백을 줄이세요

AI 모델은 패치가 적용되지 않은 시스템에서 이미 알려진 취약점의 특징을 매우 효과적으로 식별합니다. 패치를 역분석해 실제로 작동하는 익스플로잇으로 만드는 작업은 AI 모델이 특히 뛰어난 기계적 분석 영역에 해당합니다. 이는 패치가 공개된 후 익스플로잇이 출현하기까지의 시간 간격이 점점 좁아지고 있음을 의미합니다.

• CISA 알려진 악용 취약점(KEV) 카탈로그에 등재된 모든 항목을 즉시 패치하세요. 이 카탈로그에는 실제 공격에 활용되고 있음이 확인된 취약점들이 수록되어 있습니다. 목록에 포함된 항목 중 네트워크에서 접근 가능한 것은 무엇이든 긴급 사안으로 처리해야 합니다.
• 나머지는 EPSS를 활용해 우선순위를 정하세요. 익스플로잇 예측 점수 시스템(EPSS, Exploit Prediction Scoring System)은 특정 공통 취약점 및 노출(CVE, Common Vulnerability and Exposure)이 향후 30일 내에 악용될 확률을 매일 업데이트합니다. KEV 목록을 먼저 패치한 뒤, 설정한 EPSS 임계값 이상의 항목을 순차적으로 처리하면 수천 개에 달하는 미해결 CVE를 체계적으로 관리할 수 있습니다.
• 인터넷에 노출된 시스템의 패치 소요 시간을 단축하세요. 인터넷과 직접 연결된 애플리케이션은 익스플로잇 공개 후 24시간 이내에, 그 외 취약점은 수일 이내에 패치할 것을 권장합니다.
• 자동화된 업데이트로 인한 서비스 중단 위험이 허용 가능한 수준이라면, 패치 배포와 재시작을 자동화하세요. 수동 승인 절차는 지연을 유발하고, 현재 가장 큰 위험 요소는 바로 이 지연입니다.

실용 팁: 대부분의 클라우드 및 OS 벤더는 이미 패치 자동화 기능을 제공하고 있으며, 활성화하는 것은 대개 간단한 설정 변경으로 충분합니다. 컨테이너 이미지와 의존성 매니페스트의 경우, 오픈소스 스캐너 여러 개가 단일 CI(지속적 통합) 단계에서 실행되면서 KEV 카탈로그와 EPSS 데이터를 기반으로 CVE에 주석을 달아 우선순위를 자동으로 반영합니다.

2. 대폭 늘어날 취약점 보고에 대비하세요

앞으로 약 2년에 걸쳐, 취약점을 접수·우선순위 분류·수정하는 현재의 프로세스(자체 코드와 벤더에서 구매한 소프트웨어 모두 포함)는 지금보다 훨씬 큰 압박을 받게 됩니다. 취약점 관리 프로세스는 벤더와 업스트림에서 훨씬 많은 패치가 쏟아지는 상황을 감당할 수 있도록 준비해야 합니다.

• 발견 건수가 수십 배 증가할 것을 대비해 계획하세요. 접수, 분류, 조치 추적 등 각 단계가 늘어나는 취약점 수에 발맞춰 처리할 수 있어야 합니다. 보안 회의가 여전히 스프레드시트와 주간 미팅 중심으로 운영된다면, 이 속도를 따라가기는 어렵습니다. 물론 사람이 의사결정에 참여하되, 방대한 처리량을 감당하기 위한 자동화 도입을 충분히 검토할 필요가 있습니다.
• 오픈소스 의존성의 보안 수준을 점검하세요. 대부분의 소프트웨어 공급망은 대부분 오픈소스로 구성되어 있습니다. 그러나 오픈소스 프로젝트의 대다수는 SLA(서비스 수준 협약)나 높은 보안 수준 유지에 대한 약속이 없습니다. OpenSSF Scorecard는 브랜치 보호, 퍼징 커버리지, 서명된 릴리스, 유지관리자 활동 등의 신호를 기반으로 모든 의존성을 자동으로 평가합니다. CI에서 실행되며, 관리되지 않는 패키지를 식별하는 데 도움이 됩니다.
• 벤더에도 동일한 기준을 적용하세요. 서드파티 리스크 관리 프로세스에서 공급업체가 익스플로잇 가속화에 어떻게 대비하고 있는지, 자체 코드 스캔을 수행하고 있는지 직접 확인해야 합니다.

‍실용 팁: 취약한 코드의 도달 가능성을 평가하는 오픈소스 소프트웨어와 서드파티 서비스를 검토해 보세요. IT 및 프로덕션 인프라에 새로운 소프트웨어 업데이트를 지속적으로 제공하는 자동화 프로세스를 구축하고, 업데이트에 대한 회귀 테스트를 수행해 신속하게 배포할 수 있다는 확신을 얻으세요.

앞서 언급한 프로세스 자동화와 관련해, AI가 도움이 될 수 있는 몇 가지 중요한 영역이 있습니다.

• 분류 속도 향상 분류(triage)는 전문가의 검토와 판단이 필요하기 때문에 병목 구간이 되기 쉽습니다. 프론티어 모델은 기존 백로그와 중복된 발견 사항을 제거하고, 자산에 대한 지식을 활용해 노출 수준을 추정하며, 영향을 받는 코드 경로가 사전에 식별된 경우 조치 티켓 초안을 작성할 수 있습니다.
• 의존성 중복을 점검하세요. 대규모 코드베이스에는 동일한 기능을 수행하는 라이브러리가 여러 개(HTTP 클라이언트 여러 개, JSON 파서 여러 개)씩 쌓이는 경향이 있습니다. 이는 기능적 이점은 전혀 없으면서 공격자에게 더 많은 기회를 제공합니다. LLM에게 락파일을 제공하고 어떤 의존성이 중복되는지, 마이그레이션과 통합이 어떤 모습이 될지 물어보는 것은 한 시간 남짓이면 충분한 작업이지만 효과는 상당합니다.
• AI 업그레이드 자동화. 프론티어 모델은 취약점 보고서와 함께 패치를 생성하는 능력이 점점 높아지고 있습니다. 보고서가 명확하고 상세하게 작성되고 개념 증명(PoC)이 포함된 경우, 모델이 직접 패치를 테스트해 익스플로잇 경로가 차단되었는지 확인할 수 있습니다. 또한 업스트림 패치를 수락하고, 업그레이드가 테스트나 내부 시스템을 깨뜨리지 않는지 검증하는 과정 전체를 자동화할 수도 있습니다.
• AI 내재화(vendoring). OpenSSF Scorecard에서 낮은 점수를 받는 소규모 의존성이 있을 수 있습니다. 유지관리가 중단된 경우가 대표적입니다. 이런 의존성에 계속 의존하지 말고, LLM으로 실제 사용하는 기능을 직접 구현하는 코드를 작성하는 방안을 검토해 보세요.

3. 배포 전에 버그를 찾으세요

예방이 언제나 치료보다 낫습니다. 프로덕션에 배포된 버그는 결국 발견된다고 가정하고, 보안 테스트는 그 훨씬 이전에 이루어져야 합니다.

• 정적 분석과 AI 지원 코드 리뷰를 CI(지속적 통합) 파이프라인에 통합하고, 높은 신뢰도의 발견 사항에 대해서는 병합을 차단하세요. 오탐(false positive)이 너무 많아 현실적으로 어렵다면, 검사 자체는 유지하되 툴링 문제를 해결하세요. OWASP 애플리케이션 보안 검증 표준(ASVS)은 세 가지 수준의 엄격함으로 테스트 통과 기준을 정의합니다.
• 자동화된 침투 테스트를 CD(지속적 배포) 파이프라인에 추가하세요. 공격자가 프로덕션 시스템에 적용하는 것과 동일한 스캐닝을 스테이징 환경에서 직접 실행할 수 있습니다.
• 빌드 파이프라인을 보호하세요. 커밋과 배포 사이 어딘가에 코드를 주입할 수 있는 공격자는 취약점을 굳이 찾을 필요가 없습니다. SLSA 보안 프레임워크는 단계적 이행 경로를 제공합니다. 낮은 수준에서는 어떤 커밋이 어떤 아티팩트를 생성했는지 추적하고, 높은 수준에서는 빌드 자체를 검증할 수 있게 합니다.
• Secure by Design 원칙을 채택하세요. CISA의 서약 항목(기본 다중 인증, 기본 비밀번호 금지, 투명한 취약점 보고)은 합리적인 최소 기준입니다.
• 새로운 코드에는 메모리 안전 언어를 선택하세요. 심각한 취약점의 상당 부분은 Rust, Go, 또는 관리형 런타임에서는 발생하지 않는 메모리 안전 버그입니다. CISA, NSA, NCSC는 이에 관한 유용한 로드맵을 발표했습니다. 기존 C/C++ 코드를 전면 재작성할 필요는 없지만, 새로 작성하는 C/C++ 코드에는 정당한 이유가 필요해야 합니다. AI 지원 재작성도 점점 현실적인 선택지가 되고 있습니다.

실용 팁: OWASP Top 10 및 언어별 규칙 세트를 포함해 CI 액션으로 실행되는 SAST(정적 애플리케이션 보안 테스팅) 도구는 오픈소스부터 코드 호스팅 플랫폼 내장 기능까지 폭넓게 제공됩니다(GitHub의 CodeQL이 가장 일반적인 출발점입니다). 빌드 출처(provenance) 검증을 위해서는 OpenSSF가 GitHub Actions에서 SLSA Level 3 증명을 생성하는 재사용 가능한 워크플로우를 제공하고 있으며, SLSA 사양이 시사하는 것보다 훨씬 적은 노력으로 도입할 수 있습니다.

앞서와 마찬가지로, 이 작업을 AI로 가속화할 수 있는 명확한 기회들도 있습니다:

• AI 취약점 스캐닝. 원리는 간단합니다. 공격자가 사용할 법한 모델로 먼저 자체 코드와 시스템을 스캔하는 것입니다. 격리된 에이전트와 노이즈를 걸러내는 검증 단계, 기존 분류 프로세스로의 연결만 있으면 됩니다. 지금 당장 LLM으로 실행할 수 있습니다. 이 섹션에서 한 가지만 실행한다면, 이것을 선택하세요.
• 패치 생성. SAST나 스캐너가 발견 사항을 도출하면, 프론티어 모델은 대개 패치 초안을 제안할 수 있습니다. 이것이 검토의 필요성을 없애주지는 않지만, 개발자의 역할이 "버그를 파악하고 수정 코드를 작성하는 것"에서 "제안된 수정 코드가 올바른지 검증하는 것"으로 바뀝니다. 후자가 훨씬 빠릅니다. 메모리 안전 언어로의 마이그레이션에도 동일한 접근법이 유효합니다. LLM이 독립적인 C 모듈을 테스트와 함께 Rust로 이식하면, 리뷰어는 처음부터 직접 작성하는 대신 동등성을 검증하는 역할을 맡으면 됩니다.

4. 기존 코드에 숨어 있는 취약점을 찾아내세요

패치는 의존하는 소프트웨어의 알려진 취약점에 대응하는 방법입니다. 하지만 자체 코드베이스에는 아직 알려지지 않은 취약점이 존재합니다. 오랫동안 운영된 프로덕션 코드는 사람이 여러 차례 검토했더라도 프론티어 모델의 분석을 거친 적은 없는 경우가 대부분이며, 그런 분석은 기존에 간과된 새로운 문제를 발견하는 경향이 있습니다. 선제적 스캐닝을 통해 공격자가 먼저 찾아내기 전에 현대 LLM이 탐지할 수 있는 취약점을 식별할 수 있습니다.

• 노출 범위를 기준으로 우선순위를 정하세요. 신뢰할 수 없는 입력을 파싱하거나, 인증·인가 결정을 처리하거나, 인터넷에서 접근 가능한 코드를 먼저 분석하세요. 이런 경로에서 발견된 취약점이 실제로 문제가 될 가능성이 가장 높습니다.
• 레거시 코드도 포함하세요. 현재 리뷰 관행이 정착되기 이전에 작성되거나 원래 작성자가 팀을 떠난 코드는 최근에 꼼꼼히 살펴본 경우가 가장 적습니다. 새로운 시각으로 다시 검토했을 때 얻을 것이 가장 많은 영역입니다.
• 수정 작업에 충분한 시간을 배정하세요. 오래된 코드에 대한 체계적인 모델 스캔은 SAST 롤아웃보다 발견 건수는 적지만, 실제 취약점의 비율이 더 높습니다. 버그 수정을 위한 엔지니어링 시간을 미리 계획하세요.

실용 팁: 현재 소유자가 적은 인터넷 연결 서비스 하나를 선택해 입력 처리와 인증 로직을 스캔해 보세요. 에이전트는 격리된 환경에서 실행하고, 검증 단계를 추가해 확인된 발견 사항에만 조치를 취하세요. 한 개의 서비스를 제대로 수행하면, 더 광범위한 프로그램에 드는 비용을 합리적으로 추정하는 기준이 됩니다.

5. 침해를 전제로 설계하세요

공격자는 어딘가에 발판을 마련하려 할 것입니다. 그 발판에서 접근할 수 있는 범위를 최소화해야 합니다.

단단한 장벽이 아니라 귀찮게 만드는 방식으로 효과를 내는 완화 조치들(피벗 경로 추가, 속도 제한, 비표준 포트, SMS 기반 MFA 등)은 번거로운 단계를 거리낌 없이 반복할 수 있는 공격자에게는 훨씬 효과가 떨어집니다. 아래 권고 사항은 공격자가 무한한 인내심을 가지고 있더라도 견딜 수 있는 통제를 우선합니다. 하드웨어 기반 자격증명, 만료 토큰, 그리고 단순히 불편한 경로가 아니라 아예 존재하지 않는 네트워크 경로가 그 예입니다.

• 제로 트러스트 아키텍처를 도입하세요. 서비스 간 모든 요청을 인터넷에서 온 것처럼 인증·인가하세요. CISA의 제로 트러스트 성숙도 모델과 NCSC의 제로 트러스트 원칙은 모두 단계적 도입 경로를 제시합니다.
• 자격증명이 아닌 검증된 하드웨어에 접근 권한을 묶으세요. 프로덕션 시스템과 민감한 내부 도구는 하드웨어 신원이 증명된 관리형 직원 기기에서만, 그리고 피싱 방어가 가능한 2FA(FIDO2 또는 패스키)와 함께 접근 가능해야 합니다. 자격증명 탈취만으로는 절대 접근이 가능해서는 안 됩니다. 프로덕션 서비스 간 통신도 하드웨어 신원에 기반해야 합니다.
• 신원 기반으로 서비스를 격리하세요. 침해된 빌드 서버가 프로덕션 데이터베이스를 조회할 수 있어서는 안 됩니다. 침해된 노트북이 빌드 인프라에 접근할 수 있어서도 안 됩니다. 이를 수신 측에서 강제 적용하세요. 모든 워크로드는 고유한 암호화 신원을 가져야 하고, 각 서비스는 정책에 명시된 특정 호출자로부터의 연결만 허용해야 합니다. 네트워크 분리는 여전히 피해 범위를 줄이고 노이즈를 줄이는 데 유용하지만, 최후의 보루로 활용해야 합니다.
• 장기 유효 시크릿을 단기 토큰으로 교체하세요. 정적 API 키, 코드에 내장된 자격증명, 공유 서비스 계정 비밀번호는 모델 지원 코드 분석으로 무장한 공격자가 가장 먼저 찾아내는 것들입니다. ID 공급자가 발급하는 단기·최소 권한 토큰을 사용하세요.

실용 팁: 완전한 제로 트러스트는 수년에 걸친 프로그램이지만, ID 인식 접근 프록시(identity-aware access proxy)를 도입하면 내부 서비스의 아키텍처를 근본적으로 바꾸지 않고도 기기 인증과 MFA 기반 접근을 앞단에 적용할 수 있습니다. 주요 클라우드 공급자는 각각 네이티브 옵션을 제공하며, 온프레미스나 멀티클라우드 환경을 위한 오픈소스 및 상용 대안도 여럿 존재합니다. 시크릿 관리와 관련해서는 주요 클라우드 모두 관리형 시크릿 저장소를 제공합니다. 가장 널리 공유된 자격증명 하나를 여기로 이전하고 교체하는 것이 나머지 작업을 이어가는 강력한 출발점이 됩니다.

6. 노출 범위를 줄이고 목록화하세요

이 섹션은 두 가지 중요한 원칙에 바탕을 둡니다. 첫째, 파악하지 못한 시스템은 방어할 수 없습니다. 둘째, 노출 면적이 좁을수록 공격 대상도 줄어듭니다.

• 인터넷에 연결된 모든 호스트, 서비스, API 엔드포인트의 최신 목록을 유지하세요. 공격자는 자동화된 정찰을 수행할 수 있으므로, 목록의 정확도는 최소한 그에 준해야 합니다. 이 시스템들을 침투 테스트와 레드팀 훈련에 반드시 포함하세요.
• 사용하지 않는 시스템은 폐기하세요. 명확한 소유자가 없는 레거시 서비스는 대개 패치도 적용되지 않은 상태입니다.
• 각 서비스의 노출 범위를 최소화하세요. 네트워크 수신을 기본 차단으로 설정하고 API 표면을 실제로 필요한 것만으로 제한하세요.

실용 팁: 인터넷 전체 스캔 인덱스는 공개 검색이 가능합니다. 자사 IP 범위와 도메인으로 조회해 보면 공격자의 정찰에 무엇이 보이는지 확인할 수 있습니다. 클라우드 자산의 경우 네이티브 인벤토리 도구(AWS Config, Azure Resource Graph, GCP Asset Inventory)가 이미 존재합니다. 필요한 것은 이를 직접 조회하는 작업입니다.

여기서도 AI가 직접적으로 도움이 될 수 있습니다:

• 오래된 코드와 시스템 정리. 사용되지 않는 코드를 식별하는 작업은 지루하지만, 앞서 언급했듯이 AI 모델은 단조롭고 반복적인 작업에 강합니다. 코드베이스와 트래픽 로그에 읽기 접근 권한을 가진 모델은 호출자가 없고 트래픽도 없는 엔드포인트 목록을 만들어 낼 수 있으며, 각 항목을 제거했을 때 미치는 영향도 설명할 수 있습니다.
• 자율 외부 레드팀 훈련. AI 오펜시브 에이전트를 자격증명도, 소스 접근도 없이 외부에서 자체 경계를 향해 실행해 보세요. 그런 다음 공격자가 할 법한 행동을 수행하게 하세요. 접근 가능한 것을 파악하고, 핑거프린팅하고, 발견한 것을 연결해 발판을 마련하려 시도하는 것입니다. 이런 자동화된 레드팀 훈련은 소스 스캔에서 보이지 않는 것들을 잡아낼 수 있습니다. 잊혀진 호스트, 노출된 관리 인터페이스, 기본 자격증명, 잘못 구성된 스토리지가 그 예입니다. 인벤토리 갱신과 동일한 주기로 실행하세요.

7. 인시던트 대응 시간을 단축하세요

익스플로잇은 패치 공개 후 몇 시간 안에 등장할 수 있습니다. 며칠이 걸리는 대응 프로세스는 너무 느립니다. 인시던트 대응 시간을 줄이기 위한 방법을 소개합니다:

• 경보 큐 앞단에 모델을 배치하세요. 모든 수신 경보는 사람이 보기 전에 자동화된 1차 조사를 거쳐야 합니다. SIEM(보안 정보 및 이벤트 관리) 플랫폼에 읽기 전용으로 접근하고 잘 정의된 쿼리 도구를 갖춘 이런 "분류 에이전트"는 사람의 판단이 가장 필요한 경보에 주의를 집중시킬 수 있습니다.
• 무엇보다 체류 시간 측정과 커버리지 확보를 먼저 하세요. 이 두 지표는 AI 자동화가 가장 크게 개선할 수 있는 영역이며, 익스플로잇 시간 창이 좁아질수록 그 중요성은 더욱 커집니다.
• 인시던트 관련 행정 처리를 자동화하세요. 활성 인시던트 중에는 모델이 메모 작성, 아티팩트 수집, 병렬 조사 진행, 사후 분석 및 근본 원인 분석 초안 작성을 담당해야 합니다. 반면 사람은 격리 결정, 공개 여부 결정, 고객 커뮤니케이션 결정을 내려야 합니다. 인시던트 중 인간의 의사결정 속도가 증거 수집이나 기록 작성처럼 AI에게 맡기는 게 더 나은 작업들에 의해 지연되어서는 안 됩니다.
• 탐지 플라이휠을 모델이 주도하게 하세요. 위협 인텔리전스 수집, 탐지 후보 생성, 일치 항목 탐색, 경보 튜닝까지 이 모든 과정을 프론티어 모델이 처음부터 끝까지 실행할 수 있습니다.
• 동시 발생하는 인시던트 다섯 건을 가정한 탁상 훈련을 실시하세요. 일반적인 훈련은 월요일에 작동하는 익스플로잇을 가진 심각한 CVE 하나가 발생하는 상황을 가정합니다. AI 역량이 향상되고 있는 지금, 이는 지나치게 낙관적인 가정입니다. 대응 체계를 진정으로 검증하려면, 같은 주에 인시던트 다섯 건이 동시에 발생하는 시나리오로 훈련해야 합니다.
• 탐지 커버리지를 MITRE ATT&CK에 매핑하세요. ATT&CK는 대부분의 탐지 도구가 이미 활용하는 공격자 기법의 표준 어휘를 제공합니다. 어떤 기법을 탐지할 수 있고 어떤 기법은 탐지하지 못하는지 파악하는 것이, "탐지를 개선한다"는 막연한 목표보다 훨씬 유용합니다. 측면 이동(lateral movement)과 자격증명 접근에 대한 커버리지를 우선적으로 확보하세요.
• 긴급 변경 절차를 미리 수립하세요. 프로덕션 패치를 위한 2주짜리 변경 승인 절차 자체가 보안 위험입니다. 서비스 오프라인 전환, 자격증명 교체, 네트워크 경로 차단과 같은 긴급 격리 조치도 마찬가지입니다. 누가 이를 승인할 수 있고 얼마나 빠르게 실행될 수 있는지 미리 결정해 두어야 합니다.

실용 팁: 오탐률이 높기로 알려진 경보 규칙 하나를 선택하세요. 해당 경보 스트림에 프론티어 모델을 읽기 전용 접근 권한으로 연결하고, 모든 발화에 대해 구조화된 처리 결과를 생성하게 하세요. 2주 동안 사람 리뷰어와의 일치율을 측정하고, 허용 가능한 수준이라면 다음 규칙으로 확장하세요. 전체 큐를 한꺼번에 자동화하려는 시도는 무리입니다. 별개로, Atomic Red Team은 ATT&CK 기법에 매핑된 소규모의 안전한 테스트 오픈소스 라이브러리입니다. 몇 가지를 실행하고 기존 로깅이 실제로 어떤 것을 탐지했는지 확인하는 것은 반나절이면 충분한 작업이며, 구체적인 커버리지 맵을 산출합니다.

대응 시간과 관련해 AI가 도움이 될 수 있는 방법은 다음과 같습니다:

• 100% 커버리지의 1차 분류.잘 정의된 분류 에이전트는 (사람은 특정 심각도 임계값 이상의 경보만 확인하는 경향이 있는 것과 달리) 모든 경보를 조사하고, 사람이 수락·거부·에스컬레이션할 수 있는 구조화된 처리 결과를 산출할 수 있습니다. 이를 가능하게 하는 핵심은 모델에게 최소한의 도구 세트(쿼리, 분석, 보고)를 제공하고, 자체 조사 전략을 선택하게 한 뒤, 결과를 운영 지표와 비교해 측정하는 것입니다.
• 인시던트 기록사와 병렬 조사자. 활성 인시던트 중 모델은 실시간으로 메모를 작성하고, 아티팩트가 수집되는 즉시 타임스탬프를 기록하고, 대응자가 아직 처리하지 못한 독립적인 조사 경로를 추적하며, 인시던트가 종료된 후 전체 기록을 바탕으로 사후 분석 초안을 작성할 수 있습니다. 이는 프론티어 모델을 보안 업무에 적용하는 방법 중 가장 화려하지는 않지만, 아마도 가장 임팩트가 큰 활용 사례일 것입니다.
• 자체 환경에 대한 선제적 헌팅. 소스 코드에서 취약점을 찾는 에이전트와 동일한 방식으로, 텔레메트리 전반에서 잘못된 설정과 침해 지표를 헌팅할 수 있습니다. 외부 공격 표면 스캔과 동일한 주기로 실행하세요.

외부에 취약점을 보고할 때 유의사항

의존성 코드, 오픈소스 프로젝트, 또는 벤더 제품을 스캔해 발견 사항을 업스트림에 보고하는 경우, 보고서의 품질이 실제 조치 여부를 결정합니다. 오픈소스 유지관리자들은 이미 대량의 저품질 자동화 보고서를 받고 있으며, AI가 생성한 것처럼 보이는 내용은 무시하기 시작한 경우도 많습니다. 신호 없이 양만 늘리면 모두에게, 보고자 자신에게도 상황을 악화시킵니다.

보고서는 사람이 직접 검증하고 자신의 이름을 걸 수 있을 때에만 발송해야 합니다. 구체적으로:

• 버그와 그 영향을 평이한 언어로 기술하세요. 유지관리자는 아무것도 실행하지 않고도 첫 문단만 읽어 무엇이 잘못됐고 왜 중요한지 이해할 수 있어야 합니다.
• 코드 경로를 단계별로 설명하세요. 입력이 어디서 들어오고, 어디서 잘못 처리되며, 어떤 결과로 이어지는지 보여주세요. 이것이 단순한 패턴 매칭과 실제 발견을 구분하는 핵심입니다.
• 재현 가능한 증거를 제공하세요. 유지관리자가 직접 실행할 수 있는 개념 증명(PoC)이나 실패하는 테스트 케이스는 어떤 설명보다 신뢰도가 높습니다.
• 자신이 유지관리자라면 수락할 패치 초안을 포함하세요. 패치를 제시한다는 것은 보고자가 프로젝트 관행에 맞는 방식으로 문제를 수정할 만큼 코드베이스를 충분히 이해하고 있다는 증거입니다.
• AI 활용 여부를 처음부터 밝히세요. 모델이 버그를 발견하거나 보고서 초안을 작성했다면 첫 줄에 명시하세요. 유지관리자는 어차피 알게 됩니다. 숨기면 공개했을 때보다 더 많은 신뢰를 잃습니다.
• 유지관리자의 판단을 존중하세요. 보고를 거부하더라도 받아들이세요. 함께 일하기 편한 사람이라는 인상이 주는 신뢰는 버그 하나를 놓고 이기는 것보다 훨씬 가치 있습니다.

실용 팁: 취약점 보고서를 발송하기 전 유용한 자가 점검 방법이 있습니다. 편집기를 닫고 버그를 기억에 의존해 설명해 보세요. 모델 출력물을 다시 참조하지 않고 무엇이 잘못됐는지 설명하지 못한다면, 보고할 만큼 충분히 이해한 것이 아닙니다.

보안 팀이 없는 경우

위의 권고 사항 대부분은 전담 보안 조직이 있는 곳을 대상으로 합니다. 소규모 조직이나 개인 개발자, 오픈소스 유지관리자라면 동일한 위험이 존재하지만, 취해야 할 행동은 더 단순합니다:

• 운영 체제, 브라우저, 그리고 지원되는 모든 애플리케이션에서 자동 업데이트를 활성화하세요. 이것이 가장 효과적인 단일 조치이며, 별도의 지속적인 노력이 필요하지 않습니다.
• 직접 호스팅보다 관리형 서비스를 선택하세요. 보안 팀을 갖춘 공급자에게 데이터베이스, 인증, 이메일 운영을 맡기면 패치 부담이 그쪽으로 넘어갑니다. 이런 관리형 서비스의 비용은 거의 항상 인시던트 한 건의 비용보다 낮습니다.
• 지원되는 모든 계정에서 패스키 또는 하드웨어 보안 키를 사용하세요. SMS 인증 코드는 가로챌 수 있고 비밀번호는 재사용되지만, 하드웨어 키는 피싱이 불가능합니다.
• 코드 호스팅 플랫폼의 무료 보안 도구를 활성화하세요. GitHub의 Dependabot, 시크릿 스캐닝, CodeQL은 공개 저장소에 무료로 제공되며, 기업용 도구가 잡아내는 것의 상당 부분을 커버합니다. 활성화하는 데 몇 분이면 충분합니다.

오픈소스 프로젝트를 운영한다면, SECURITY.md 연락처와 연락 시 어떤 절차가 진행되는지를 명시한 문서를 공개하세요. AI 지원 스캐닝으로 인해 이전보다 더 많은 취약점 보고를 받게 될 것입니다. 일부는 가치 있는 내용이고, 일부는 자동화된 노이즈일 것입니다. 명확한 접수 절차가 있으면 이 둘을 구별하는 데 도움이 되고, 선의의 보고자에게 자신의 노력이 헛되지 않을 것임을 알려주는 신호가 됩니다.

감사의 말

이 글은 Anthropic 보안 엔지니어링 및 연구팀의 Donny Greenberg, Jason Clinton, Michael Moore, Abel Ribbink, Jackie Bow가 작성했으며, Jannet Park, Gabby Curtis, Stuart Ritchie가 기여했습니다.