Arm Metis 공개, SAST 오탐 50% 감소를 겨냥한 보안 에이전트

AI 요약

• 무슨 일: Arm이 2026년 5월 28일 Metis를 오픈소스 agentic AI security framework로 공개했습니다.
  • Arm은 Metis가 내부 130개 이상 software project에서 이미 사용 중이며, 2026년 말 Arm-wide adoption을 목표로 한다고 밝혔습니다.
• 숫자: Arm 내부 benchmark는 leading SAST 대비 최대 10배 true positive rate, 약 50% fewer false positives를 제시했습니다.
• 실무 쟁점: Metis의 핵심은 취약점 후보 생성보다 SARIF triage, evidence chain, deterministic gate입니다.
  • 보안팀은 "AI가 몇 건을 찾았나"보다 valid·invalid·inconclusive 판정 근거와 재현 비용을 봐야 합니다.

Arm이 2026년 5월 28일 Metis를 오픈소스로 공개했습니다. Arm은 Metis를 "agentic AI security framework"라고 부릅니다. 제품 범주는 보안 챗봇보다 코드 리뷰와 SAST triage에 가깝습니다. 도구는 source code, build file, documentation을 읽어 project-specific knowledge base를 만들고, LLM reasoning으로 설계 결함과 논리 취약점을 찾습니다.

이번 발표에서 가장 눈에 띄는 수치는 세 가지입니다. Arm은 Metis가 내부 130개 이상 software project에서 이미 실행 중이고, 2026년 말까지 Arm 전체 software adoption을 목표로 한다고 밝혔습니다. 내부 benchmark에서는 leading static analysis tools 대비 최대 10배 높은 true positive rate, 약 50% 적은 false positive를 냈다고 설명했습니다. Arm은 이 benchmark가 AI 학습에 사용되지 않았다고 덧붙였습니다.

Metis의 의미는 "AI가 보안 리뷰를 대신한다"가 아닙니다. 보안팀이 실제로 시간을 쓰는 지점은 finding 후보 생성 이후입니다. 이 finding이 실제 취약점인지, 어떤 코드 경로가 증거인지, 외부 SAST 결과를 그대로 닫아도 되는지, maintainer에게 보고할 정도의 근거가 있는지를 검증해야 합니다. Metis는 이 병목을 RAG, Tree-sitter 분석, SARIF triage, deterministic adjudication으로 줄이려는 도구입니다.

SAST의 약한 부분을 AI가 겨냥합니다

전통적인 SAST는 알려진 패턴을 빠르게 찾는 데 강합니다. buffer overflow, hardcoded secret, injection sink, unsafe API 사용처럼 rule로 잡히는 문제는 자동화 가치가 큽니다. 문제는 rule이 찾은 결과를 사람이 다시 걸러야 한다는 점입니다. 같은 함수 호출도 guard condition, sanitizer, macro expansion, caller contract, configuration에 따라 실제 위험도가 달라집니다.

Arm은 Metis가 고정 rule보다 code context를 더 많이 본다고 설명합니다. Metis는 repository를 index하고, 관련 source와 documentation을 retrieval한 뒤, LLM이 취약점 가능성을 reasoning하도록 구성됩니다. 2025년 Arm developer community 글은 Metis가 "source files and documentation"으로 코드가 의도한 동작을 파악한다고 설명했습니다. 2026년 Newsroom 글은 이 구조를 RAG architecture로 다시 정리했습니다.

이 접근이 필요한 취약점은 대개 한 줄에 갇히지 않습니다. authorization check가 다른 layer에 있거나, parser가 특정 state에서만 잘못된 길을 타거나, C/C++ macro가 위험한 allocation 경로로 확장되거나, Rust와 C FFI 경계에서 ownership 가정이 깨지는 식입니다. SAST rule은 후보를 만들 수 있지만, 근거 chain을 만들고 반례를 지우는 작업은 별도입니다.

Arm의 10배 true positive rate와 50% fewer false positives 주장은 이 지점에 붙습니다. 다만 이 수치는 Arm 내부 benchmark입니다. 공개 benchmark suite나 third-party 재현이 붙은 숫자는 아닙니다. 따라서 기사에서 이 숫자를 제품 성능 보장으로 읽으면 안 됩니다. 더 정확한 해석은 "Arm 내부 보안팀이 false positive 처리 비용을 줄이는 방향으로 Metis를 설계했고, 내부 배포에서 그 효용을 봤다고 주장한다"입니다.

Metis는 finding 생성기보다 triage 파이프라인에 가깝습니다

GitHub의 Metis README는 도구를 "AI-Powered Security Code Review"로 소개합니다. CLI에는 index, review_code, review_file, review_patch, triage, ask, update 명령이 있습니다. 전체 repository를 검토할 수도 있고, 단일 file이나 patch diff를 볼 수도 있으며, 기존 SAST가 만든 SARIF finding을 triage할 수도 있습니다.

README가 적은 feature도 이 방향을 뒷받침합니다. Deep reasoning, context-aware reviews, plugin-friendly extensibility, issue validation, provider flexibility가 핵심 feature로 나열됩니다. 특히 issue validation은 Metis 자신의 finding과 third-party SAST finding을 검증하고, evidence를 모아 false positive를 줄인다는 설명입니다.

Metis의 triage-flow 문서는 더 구체적입니다. 문서는 Metis triage를 "deterministic orchestration, not an agent loop"라고 규정합니다. SARIF finding을 읽고, vector index에서 repository context를 retrieval하고, Tree-sitter와 line-local sed·grep, C/C++ macro·include resolution으로 evidence pack을 만듭니다. 그 뒤 LLM에 structured decision을 요청하고, deterministic gate와 adjudication rule이 최종 상태를 붙입니다.

이 설계는 AI 보안 도구에서 중요한 안전장치입니다. LLM이 "valid"라고 답했다고 바로 finding을 확정하지 않습니다. evidence obligation이 부족하면 inconclusive로 내리고, contradiction signal이 있으면 invalid로 강제할 수 있습니다. valid·invalid 직접 upgrade도 invariant check로 막습니다. 보안팀 입장에서는 모델의 자신감보다 근거 수집 범위와 판정 규칙이 더 중요합니다.

지원 범위는 보안 코드 리뷰에 맞춰져 있습니다

Metis README의 supported languages 표는 C, C++, Python, Rust, TypeScript, Terraform, Go, Solidity, TableGen, Verilog를 나열합니다. C와 C++는 Tree-sitter와 flow analysis, Python·Rust·TypeScript·Go·Solidity·Verilog는 structural analysis와 tool 기반 triage를 사용한다고 설명합니다. pyproject.toml entry point에는 JavaScript, PHP, SystemVerilog, AArch64 assembly plugin도 보입니다.

언어 목록에서 Arm의 우선순위를 읽을 수 있습니다. C와 C++는 Arm ecosystem에서 runtime, compiler, firmware, driver, library에 깊게 들어갑니다. Verilog와 SystemVerilog는 hardware verification 쪽으로 확장할 수 있는 신호입니다. Solidity 지원은 smart contract security review를 염두에 둔 선택입니다. Terraform은 infrastructure-as-code policy와 misconfiguration finding을 triage하는 데 쓰일 수 있습니다.

Arm Newsroom은 Metis가 최근 Verilog support를 추가했고, hardware vulnerability verification으로 확장을 검토한다고 적었습니다. 이 대목은 단순히 language plugin이 하나 늘었다는 뜻보다 큽니다. AI 보안 리뷰가 application code만 다루는 것이 아니라 hardware description, firmware, system software, cloud configuration을 함께 보는 방향으로 넓어지고 있습니다.

Provider flexibility도 실무에서 중요한 항목입니다. README는 OpenAI 설정 예시를 먼저 보여주지만, vLLM, Ollama, LiteLLM 같은 provider도 언급합니다. 사내 코드와 보안 finding을 외부 모델에 보낼 수 없는 조직은 local model이나 self-hosted inference가 필요합니다. 반대로 Arm은 내부 deployment에서 OpenAI Daybreak의 GPT-5.5-Cyber를 defensive security workflow에 사용한다고 Newsroom 글에 적었습니다.

오픈소스 공개가 만드는 검증 압력

Metis repo는 Apache-2.0 license입니다. 2026년 5월 29일 19:00 UTC 전후 GitHub API 기준으로 563 stars, 89 forks, 15 open issues를 보였습니다. 언어 통계는 Python이 대부분이고, README는 uv pip install ., Docker build, PostgreSQL optional dependency, ChromaDB default backend를 설명합니다.

오픈소스 공개는 두 방향의 압력을 만듭니다. 첫째, 보안팀은 Metis가 어떻게 evidence를 수집하고 prompt를 구성하는지 직접 볼 수 있습니다. closed SOC copilot은 결과 화면만 보여주는 경우가 많지만, Metis는 plugin, prompt template, triage flow, vector backend 설정을 inspection할 수 있습니다. 둘째, 공격자도 도구의 가정과 약점을 볼 수 있습니다. security tool이 오픈소스라는 사실은 투명성과 공격면을 동시에 늘립니다.

이 지점에서 Metis의 deterministic triage 문서가 중요합니다. agent loop가 자율적으로 repository를 헤매며 결론을 내리는 구조라면 재현성과 감사가 어렵습니다. Metis는 SARIF finding, bounded evidence pack, structured decision, deterministic rule을 연결합니다. 보안 조직이 audit trail을 요구할 때 이 구조는 "왜 valid로 봤는가"를 파일과 line 기준으로 설명할 가능성을 높입니다.

그렇다고 Metis가 SAST를 대체한다고 보기는 어렵습니다. README 자체도 third-party SAST finding validation을 기능으로 둡니다. CodeQL, Semgrep, Snyk, Sonar 같은 기존 도구가 빠르게 후보를 만들고, Metis가 repository context와 evidence obligation으로 후보를 줄이는 조합이 더 현실적입니다. AI가 rule engine을 지우는 것이 아니라, rule engine이 만든 queue를 사람이 처리하기 전에 정렬하는 형태입니다.

최근 AI 보안 뉴스와 다른 지점

최근 AI 보안 뉴스는 두 갈래로 나뉩니다. 하나는 Anthropic Mythos처럼 exploit capability를 공개하는 쪽입니다. 모델이 패치된 V8 CVE나 smart contract vulnerability에서 exploit chain을 어디까지 만들 수 있는지 보여줍니다. 다른 하나는 Claroty Claire처럼 산업 현장의 보안 agent가 asset identity, 승인선, audit log를 갖춰야 한다는 쪽입니다.

Metis는 이 둘과 위치가 다릅니다. exploit 생성 능력을 과시하지 않고, cyber-physical system 운영 자동화를 전면에 내세우지도 않습니다. 대신 software product security team이 매일 처리하는 code review와 SAST triage queue에 들어갑니다. finding을 많이 만드는 도구보다 false positive를 줄이고, inconclusive를 명확히 남기고, patch 전후 diff를 더 빨리 검토하는 도구에 가깝습니다.

이 차이는 개발자 경험에도 영향을 줍니다. AI code review가 개발자에게 미움받는 이유는 틀린 지적을 자신 있게 남기기 때문입니다. 보안 리뷰에서는 그 비용이 더 큽니다. false positive가 많으면 개발자는 보안 도구를 mute하고, AppSec 팀은 실제 취약점을 놓칠 위험을 감수합니다. Metis가 주장하는 50% false positive 감소는 그래서 생산성 수치이면서 trust 수치입니다.

반대로 false negative는 더 위험합니다. Metis가 invalid로 닫은 finding이 실제 취약점이면 보안 사고로 이어질 수 있습니다. triage-flow 문서가 inconclusive를 강제하는 gate를 둔 이유도 여기에 있습니다. AI 보안 도구는 "더 많은 자동 확정"이 아니라 "확실하지 않을 때 멈추는 판정"을 제품 기능으로 가져야 합니다.

도입 전에 봐야 할 질문

첫째, private code 처리 방식을 확인해야 합니다. Metis는 source code, build file, documentation을 knowledge base로 넣습니다. 외부 LLM provider를 쓰는 경우 어떤 code fragment와 finding detail이 전송되는지, logging과 retention policy가 무엇인지, provider별 설정이 어떻게 분리되는지 확인해야 합니다. local model을 쓰는 경우에는 model quality와 inference cost가 새 병목이 됩니다.

둘째, SAST와 중복되는 영역을 정해야 합니다. 이미 CodeQL이나 Semgrep이 있는 조직은 Metis를 새 scanner로만 붙이면 alert가 늘어날 수 있습니다. 더 좋은 배치는 기존 SARIF를 Metis triage에 넣고, valid, invalid, inconclusive annotation을 review queue와 ticket system에 연결하는 방식입니다. 이렇게 해야 "AI 도구 하나 더"가 아니라 false positive 처리 비용 절감으로 평가할 수 있습니다.

셋째, evidence quality를 측정해야 합니다. Metis가 어떤 file:line을 근거로 삼았는지, macro/include resolution이 실패했는지, unresolved hop이 남았는지, model decision이 deterministic rule에서 downgraded됐는지 봐야 합니다. 단순 summary는 개발자를 설득하지 못합니다. security finding은 재현 가능한 path, 영향을 받는 asset, exploitability 조건, mitigation diff가 붙어야 닫힙니다.

넷째, language별 기대치를 다르게 잡아야 합니다. C/C++ flow analysis와 Python·TypeScript structural analysis는 같은 깊이가 아닙니다. Verilog나 Terraform은 취약점 정의와 review convention이 application code와 다릅니다. Metis의 plugin system은 확장 가능성을 주지만, 조직마다 prompt template과 rule, evidence obligation을 조정해야 합니다.

다섯째, metric을 finding count로 두면 안 됩니다. Metis 도입 KPI는 valid finding 수보다 false positive 처리 시간, inconclusive backlog, patch merge까지 걸린 시간, developer dispute 비율, reopened finding 수가 되어야 합니다. Arm이 발표에서 false positive와 true positive를 강조한 것도 보안 자동화의 실제 비용이 triage에 있기 때문입니다.

보안 에이전트의 경쟁 기준은 증거입니다

Arm Metis 공개는 AI 보안 도구 경쟁이 "챗봇이 답한다"에서 "증거를 모아 판정한다"로 이동하고 있음을 보여줍니다. 보안팀은 자연어 요약만으로 finding을 닫을 수 없습니다. 어떤 함수가 source인지, 어떤 guard가 sanitizer인지, macro가 어디서 확장되는지, caller contract가 왜 깨지는지, SAST rule이 왜 오탐인지가 필요합니다.

Metis가 좋은 선례를 남기는 부분은 LLM decision을 마지막 판정으로 두지 않는다는 점입니다. deterministic evidence collection과 adjudication이 앞뒤에 붙어 있습니다. 이것은 AI 보안 리뷰의 최소 조건에 가깝습니다. 모델이 reasoning을 잘해도, 보안 workflow는 재현 가능한 증거와 감사 가능한 상태 전이를 요구합니다.

남은 질문도 분명합니다. Arm 내부 benchmark 수치는 외부에서 재현되지 않았습니다. GPT-5.5-Cyber 같은 specialized model을 쓰는 deployment와 local model deployment의 성능 차이도 공개되어 있지 않습니다. 130개 내부 project에서 어떤 language와 codebase 규모가 주였는지, false positive 감소가 어떤 bug class에서 컸는지도 더 봐야 합니다.

그럼에도 Metis는 개발자와 AppSec 팀에게 실용적인 신호를 줍니다. AI가 취약점 후보를 더 많이 만들수록 병목은 triage로 이동합니다. finding queue를 줄이는 도구는 모델 이름보다 evidence chain, provider boundary, SARIF annotation, deterministic gate로 평가해야 합니다. Arm이 Metis를 공개한 이유도 그 지점에 있습니다. 보안 에이전트의 경쟁 기준은 답변 속도가 아니라 "왜 이 finding을 믿어도 되는가"입니다.