자동 수정(Auto-Fix)이 문제가 아니라, 시그널(Signal)이 문제입니다
요약
취약점 자동 수정(Auto-fix)의 리스크와 오탐 문제를 분석하며, 단순한 자동화 개선보다 탐지 시그널의 정확도와 맥락(Context) 확보가 중요함을 강조합니다. 오탐을 해결하기 위해 스캐너의 탐지 성능 개선과 구성 그래프를 통한 맥락 파악이라는 두 가지 접근법을 제시합니다.
핵심 포인트
- 높은 오탐율을 가진 상태에서의 자동 수정은 보안 이득 없이 리스크만 초래함
- 오탐 문제는 스캐너 자체의 오류와 맥락 결여로 인한 무해한 발견으로 구분됨
- 단순한 AI 조사를 넘어 리소스 간 관계를 파악하는 구성 그래프(Configuration Graph)가 핵심임
- 문제의 본질은 수정 단계가 아닌 탐지 시그널(Signal)의 품질에 있음
✓ 사람이 작성한 분석; AI는 서식 지정 및 교정(proofreading)에 사용되었습니다.
Harry Wetherald (Maze)는 취약점 자동 수정(auto-fixing)에 반대하는 논거를 제시합니다. 대부분의 탐지 결과는 오탐(false positives)이며, 모든 코드 또는 클라우드 변경은 리스크를 동반하기 때문입니다. 따라서 모든 것을 자동 수정하는 것은 보안상의 이점 없이 리스크만 도입하는 것을 의미합니다. 그가 제안하는 경로는 다음과 같습니다: 먼저 이해도를 높이고(AI가 문맥 속에서 탐지 결과를 조사), 그다음 인간을 위한 수정 제안을 생성하며, 최종적으로 수정 사항이 신뢰할 수 있게 되면 자동화를 구현하는 것입니다.
문제 식별은 정확합니다. 하지만 해결책은 잘못된 계층(layer)을 다루고 있습니다.
그가 옳게 짚은 점
-
오탐(false positive) 비율은 실재합니다. 그 수치는 80%에서 99%에 달합니다. 대부분의 탐지 결과는 특정 환경의 문맥(context) 내에서 조사할 때 중요하지 않은 것들입니다.
-
오탐을 자동 수정하는 것은 이를 무시하는 것보다 더 나쁩니다. 클라우드나 코드에 가해지는 모든 변경은 다운타임, 새로운 공격 표면(attack surface), 회귀(regression)와 같은 리스크를 수반합니다. 만약 탐지 결과의 90%가 오탐이라면, 이를 모두 자동 수정하는 것은 90%의 변경 사항이 이득 없이 리스크만 초래함을 의미합니다.
-
문맥(context)이 없는 AI 생성 수정 제안은 도움이 되지 않습니다. 탐지 결과에 조직적 문맥이 결여되어 있다면, 수정 제안 또한 문맥이 결여될 것입니다. 결과적으로 검토해야 할 탐지 결과의 더미 대신, 검토해야 할 자동 수정 사항의 더미를 마주하게 됩니다. 문제의 형태가 변할 뿐, 규모는 변하지 않습니다.
이러한 관찰은 정확합니다.
해결책이 놓치고 있는 점
제안된 진행 단계: 더 나은 AI 조사 → 수정 제안 → 인간의 검토 → 최종적인 완전 자동화.
이 경로는 스캐너의 출력물, 즉 탐지 결과(finding)나 시그널(signal)을 시작점으로 받아들이고 그 이후에 일어나는 일을 개선하려고 시도합니다. 출력물 자체에 대해서는 결코 의문을 제기하지 않습니다.
오탐 문제는 두 가지 문제입니다
Wetherald가 언급한 "80-99%의 오탐"은 서로 다른 두 가지를 결합하고 있습니다:
첫 번째는 오탐(False Positives)입니다. 스캐너가 설정에 대해 잘못 판단한 경우입니다. 버킷에 버전 관리(Versioning)가 설정되어 있음에도 스캐너가 이를 놓쳤거나, 역할(Role)에 해당 권한이 있음에도 없다고 판단하는 식입니다. 이 문제에 대한 해결책은 간단합니다. 스캐너를 고치는 것입니다. 더 나은 규칙(Rules), 파싱(Parsing) 및 커버리지(Coverage)를 확보하면 됩니다. 이는 엔지니어링 문제이며 엔지니어링 솔루션으로 해결할 수 있습니다.
두 번째는 실제 발견 사항(True Findings)이지만 악용이 불가능한 경우입니다. 스캐너의 진단이 맞습니다. 버킷에 버전 관리가 없는 것도 사실입니다. 하지만 맥락(Context) 때문에 악용이 불가능합니다. 예를 들어 버킷이 비어 있거나, 내부 전용(Internal-only)이거나, VPC 엔드포인트 정책(VPC endpoint policy) 뒤에 있거나, SCP(Service Control Policy)에 의해 보호되고 있는 경우입니다. 발견 사항은 사실이지만, 리스크는 제로입니다.
이 두 가지는 서로 다른 솔루션을 필요로 합니다. 첫 번째는 더 나은 탐지(Detection)가 필요하지만, 두 번째는 완전히 다른 무언가가 필요합니다.
맥락(Context)은 AI의 문제가 아닙니다
실제 발견 사항을 악용 불가능하게 만드는 맥락은 구성 그래프(Configuration Graph)입니다. 리소스 간의 관계, 조직 정책(Organizational policies), 권한 경계(Permission boundaries), 네트워크 토폴로지(Network topology) 등이 이에 해당합니다. 이러한 맥락은 정적(Static)이며 결정론적(Deterministic)입니다. 이는 이미 클라우드 제공업체의 API 응답에 포함되어 있습니다.
Wetherald는 "사용자의 환경 맥락에서 발견 사항을 조사하는" AI를 제안합니다. 하지만 그가 설명하는 맥락은 모호하지 않습니다. SCP는 동작을 차단하거나 차단하지 않거나 둘 중 하나입니다. VPC 엔드포인트 정책은 경로를 제한하거나 제한하지 않거나 둘 중 하나입니다. 권한 경계는 역할을 제한하거나 제한하지 않거나 둘 중 하나입니다.
이것들은 AI의 조사가 필요한 판단(Judgment calls)의 영역이 아닙니다. 이는 구성 스냅샷(Configuration snapshot)을 통해 평가 가능한 술어(Predicates)입니다. 답은 참(True) 또는 거짓(False)입니다. 동일한 스냅샷, 술어, 그리고 답이 매번 동일하게 도출됩니다.
스캐너가 이러한 컨텍스트 없이 탐지 결과(findings)를 생성하는 이유는 스캐너가 리소스 간의 관계가 아닌 개별 리소스를 평가하기 때문입니다. 스캐너는 "이 버킷에 버전 관리(versioning)가 설정되어 있는가?"를 확인합니다. 이는 단일 리소스의 속성입니다. 해당 버킷에 버전 관리가 설정되어 있지 않은 것이 문제가 될지 여부는 무엇이 그곳에 쓰기 작업을 하는지, 누가 접근할 수 있는지, 어떤 정책이 보호하고 있는지, 그리고 공격 경로(attack path)에 참여하는지 여부에 달려 있습니다. 이것들은 관계(relationships)입니다. 즉, 노드(nodes)의 속성이 아니라 그래프의 에지(edges)입니다.
오탐(False positive)은 아키텍처의 실패입니다. 도구는 노드를 평가하지만, 리스크는 에지에 존재합니다.
출력 유형(output type)이 근본 원인입니다
스캐너는 "이 버킷은 버전 관리가 누락되었습니다"라는 탐지 결과(finding)를 생성합니다. 이것은 시그널(signal)입니다. 기계가 이에 따라 조치를 취하기 전에 인간의 해석이 필요합니다. 이 탐지 결과가 실제인가? 이것이 중요한가? 우리가 수정해야 하는가? 이러한 질문들이 존재하는 이유는 출력이 시그널이기 때문입니다.
다른 유형의 출력인 판결(verdict)을 생각해 보십시오. "이 구성은 스냅샷 Z로부터 술어(predicate) Y에 따라 평가되었을 때, 통제 항목 X에 대해 비준수(NON_COMPLIANT) 상태입니다. 종료 코드(Exit code) 3." 이것은 결정(decision)입니다. 파이프라인은 종료 코드를 읽습니다. 해석이나 분류(triage), 또는 "이것이 실제인가?"라는 질문이 필요 없습니다.
Wetherald가 설명하는 오탐(false positive) 문제는 보안 평가의 속성이 아니라 시그널의 속성입니다. 시그널은 불완전하기 때문에 조사가 필요합니다. 시그널은 그래프 없이 단일 리소스만을 설명합니다. 판결은 그래프를 평가하고 결정론적인(deterministic) 결과를 생성하기 때문에 조사가 필요하지 않습니다.
시그널을 더 잘 조사하는 AI라 할지라도, 그것은 여전히 시그널을 해석하는 AI일 뿐입니다. 출력은 여전히 확률적(probabilistic)입니다. "이것이 중요하다고 95% 확신합니다." 이것은 여전히 시그널입니다. 더 빠르고 더 똑똑한 시그널이라 할지라도 여전히 시그널입니다.
누락된 단계: 검증(verification)
Wetherald의 경로는 다음과 같습니다: 발견(find) → 조사(investigate) → 수정 제안(suggest fix) → 인간이 수정 실행(human executes fix). 수정은 이루어집니다. 그다음은 무엇입니까?
방어자는 수정이 제대로 작동했는지 어떻게 알 수 있습니까? 자동 수정 도구(auto-fixer)는 수정이 다른 취약점을 유발하는 대신 해당 취약점을 해결했다는 것을 어떻게 알 수 있습니까?
그의 발전 과정에는 수정 검증(fix-verification) 루프가 결여되어 있습니다. 검증이 없다면, "자동 수정 (auto-fix)"은 "자동으로 변경하고 기도하기"를 의미합니다. 검증이 있다면 다음과 같습니다:
- 탐지됨 (판정 결과가 NON_COMPLIANT임)
- 수정 적용 (사람 또는 자동화에 의해)
- 재평가 (새로운 스냅샷을 캡처하고, 평가를 재실행)
- 판정 변경 (NON_COMPLIANT → COMPLIANT, 또는 변경되지 않음)
- 변경되지 않는다면: 수정이 잘못되었습니다. 다시 시도하십시오.
검증이 자동 수정을 안전하게 만듭니다. 더 나은 AI 조사나 수정 제안이 아닙니다. 검증입니다. 수정이 적용된 후 금지된 상태가 사라졌음을 확인할 수 있는 결정론적 판정 엔진(deterministic verdict engine) 말입니다.
자기 치유(Self-healing)는 잘못된 종착점입니다
Wetherald의 비전은 이렇습니다: AI 에이전트가 인간의 개입 없이 문제를 찾아내고, 조사하고, 수정하는 것입니다. 자기 치유(Self-healing) 환경 말이죠.
이는 병목 현상이 인간의 노동력에 있다고 가정합니다. 인간이 검토하기에는 탐지 결과가 너무 많으니, 인간을 자동화로 대체하자는 것입니다.
실제 병목 현상은 시그널(signal)의 품질입니다. 만약 탐지 결과의 90%가 오탐(false positives)이라면, 문제는 인간이 느리다는 것이 아닙니다. 도구가 1 단위의 시그널을 생성할 때마다 9 단위의 노이즈를 생성하고 있다는 것이 문제입니다. 더 빠른 인간(또는 인간을 대체하는 AI)이 동일한 노이즈를 처리한다고 해서 문제가 해결되지는 않습니다. 단지 노이즈를 더 빨리 처리할 뿐입니다.
대안은 "이것이 진짜인가?"라는 질문이 생기지 않도록 출력을 변경하는 것입니다:
-
결정론적 판정(deterministic verdict)은 조사가 필요하지 않습니다. 서술어(predicate)가 구성(configuration)과 일치하거나 일치하지 않거나 둘 중 하나입니다.
-
취약점 악용 가능성 분류(exploitability classification: 악용 가능 / 한 단계 차이 / 도달 가능함)는 분류(triage)가 필요하지 않습니다. 그래프 평가(graph evaluation)가 이미 어떤 탐지 결과가 공격을 위한 모든 전제 조건을 갖추고 있는지 식별했기 때문입니다.
-
수정 검증 루프(fix-verification loop)는 요행을 바랄 필요가 없습니다. 판정 엔진이 금지된 상태가 사라졌음을 확인합니다.
이 중 어느 것도 AI를 필요로 하지 않습니다. 이들은 다른 도구 아키텍처를 필요로 합니다. 즉, 구성 그래프(configuration graph)를 결정론적으로 평가하고, 시그널 대신 판정(verdicts)을 생성하며, 수정이 탐지 결과를 해결했음을 검증할 수 있는 아키텍처 말입니다.
계층 오류 (The layer error)
Wetherald는 더 나은 시그널 소비자 (consumer of signals)를 구축하고 있습니다. 이는 도구가 시그널을 생성하고, 이를 해석할 무언가가 필요하며, 대규모 환경에서 AI 해석이 인간의 해석보다 더 나은 경우에 유용합니다.
하지만 더 나은 시그널 소비자를 구축한다고 해서 시그널 자체가 잘못된 출력 유형 (output type)이라는 사실이 해결되지는 않습니다. 이는 문제가 존재하는 계층을 고치는 대신, 문제 바로 위의 계층을 최적화하는 것에 불과합니다.
문제가 존재하는 계층은 도구의 기본 기능 (primary function)입니다. 노드 (nodes)를 평가하는 스캐너는 항상 그래프 컨텍스트 (graph context)가 결여된 결과 (findings)를 생성할 것입니다. 사후적인 AI 조사 (post-hoc AI investigation)가 아무리 이루어진다 해도 스캐너가 무엇을 평가했는지 자체를 바꿀 수는 없습니다. 조사는 스캐너가 애초에 평가했어야 할 그래프를 — 비용이 많이 들고, 확률적이며, 매번 다르게 — 재구성하는 과정일 뿐입니다.
처음부터 그래프를 평가하는 도구는 조사할 필요가 있는 오탐 (false positive)을 생성하지 않습니다. "80-99%의 오탐률"은 노드를 평가한 결과입니다. 엣지 (edges)를 평가하면 그 비율은 달라집니다.
올바른 경로 (The right path)
Wetherald의 경로: 찾기 (시그널) → 조사 (AI) → 수정 제안 → 인간 검토 → 자동 수정 (auto-fix) → 자가 치유 (self-healing).
대안적인 경로: 평가 (판정) → 분류 (exploitable / one-away / reachable) → 수정 → 검증 (재평가, 판정 변경) → 검증된 수정 사항 자동화.
차이점:
-
조사(investigation) 단계가 없습니다. 판정(verdict) 자체가 조사입니다. 술어(predicate)가 그래프를 평가하여 결정론적(deterministic)인 결과를 생성합니다.
-
분류(triage) 단계가 없습니다. 취약성(exploitability) 분류가 곧 분류입니다. 취약한(exploitable) 결과물을 최우선으로 처리합니다. 그다음은 One-away 결과물(상태가 바뀌기 전에 전제 조건을 보호)입니다. 도달 가능한(reachable) 결과물은 마지막입니다.
-
검증(verification)이 내장되어 있습니다. 모든 수정 사항은 재평가됩니다. 판정이 바뀌거나(수정 성공), 바뀌지 않거나(수정 실패) 둘 중 하나입니다. "자동 수정하고 기도하기(auto-fix and hope)"는 없습니다.
-
자동 수정(auto-fix)은 수정 사항이 검증 가능할 때 안전해집니다. AI가 조사(investigation)를 더 잘하게 될 때가 아닙니다. 결정론적인 판정이 자동 수정 도구에 무엇을 변경해야 하는지 알려주고, 재평가가 그 변경이 제대로 작동했는지 확인합니다.
이 경로는 AI의 성능 향상을 요구하지 않습니다. 도구가 다른 종류의 출력을 생성할 것을 요구합니다. 보안 분야에서 AI 시대의 기여는 시그널(signals)에 대한 더 나은 조사가 아닙니다. 조사는 잘못된 출력 유형을 해결하기 위한 임시방편(workaround)임을 인식하는 것입니다.
Stave는 시그널이 아닌 판정(verdicts)을 생성합니다. 제어 카탈로그(control catalog)에 대비하여 구성 스냅샷(configuration snapshots)을 결정론적으로 평가합니다. 모든 결과물에 대해 취약성(exploitability)을 분류합니다. 스냅샷 차이(snapshot diff)를 통해 수정을 검증합니다. Wetherald가 설명하는 오탐(false positives)은 발생하지 않는데, 그 이유는 그래프를 평가하기 때문입니다. stave apply --observations ./your-snapshot/
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기