Executive Summary

주요 수치

출처: Sudaroli Dhananjeyan, Kumaran U, The Exclusion Ratchet: False-Positive Suppression Accumulates and Persists in Detection Rule Repositories, arXiv:2608.31062(2026-08-31)

논문이 통계보다 먼저 보여 주는 것은 규칙 하나의 이력입니다. image_load_dll_vss_ps_susp_load.yml은 어떤 프로세스가 볼륨 섀도 복사본 서비스의 프록시 라이브러리를 불러올 때 알람을 울립니다. 그 라이브러리를 부르는 것은 섀도 복사본을 다루는 프로그램의 특징입니다. 백업과 서비싱 소프트웨어가 늘 하는 일이고, 랜섬웨어가 암호화 직전에 하는 일이기도 합니다. 정상 동작과 공격 동작이 같은 신호를 냅니다.

그래서 이 규칙에는 예외가 계속 붙었습니다. 논문이 복원한 이력에 예외가 27개 있고, 그중 24개가 스냅숏 시점까지 그대로 살아 있습니다. 사라진 3개도 재검토의 결과가 아니었습니다. 2021년 7월에 dismhost.exe와 taskhostw.exe로 적혀 있던 예외가 2022년 6월에 없어지는데, 같은 날 앞에 역슬래시가 하나 붙은 같은 이름으로 다시 들어옵니다. 나머지 하나도 포함 조건이 시작 조건으로 바뀐 것뿐입니다. 저자들은 이 대목을 자기 방법의 한계로 먼저 적어 둡니다. 탐지기는 여기서 완화 3건을 보았지만, 실제로 완화된 것은 하나도 없었습니다.

예외의 폭도 그대로 있지 않았습니다. 처음 15개월 동안은 모든 예외가 실행파일 하나를 지목했습니다. 2022년 10월 31일 수정 한 번으로 디렉터리 트리 세 개가 한꺼번에 들어옵니다. C:\Windows\와 C:\Program Files\, C:\Program Files (x86)\입니다. 첫 번째는 이미 윈도 경로를 요구하던 블록에 들어가 실질적 변화가 크지 않았습니다. 새로 열린 것은 뒤의 둘입니다. 공격자가 Program Files에 파일을 쓰려면 권한을 먼저 올려야 하지만, 일단 올린 다음에는 그 트리 전체가 이 탐지에서 빠집니다.

이 예외를 넣은 사람은 그 점을 알고 있었습니다. 규칙 본문에 배포하는 쪽을 향해 남긴 주석이 함께 있습니다.

이 주석은 3년 반째 그대로 붙어 있습니다. 예외가 잠정 조치라는 것도, 어떻게 좁혀야 하는지도 적혀 있는데, 좁힌 사람이 없었을 뿐입니다. 그동안 이 규칙을 그대로 내려받아 쓴 조직은 그 예외까지 함께 받았습니다. 논문이 이 사례를 든 이유가 여기 있습니다. 개별 결정은 건전했고, 알고 내렸고, 해법까지 스스로 적어 두었습니다. 그런데도 그 예외는 영구적이었습니다.

분석 대상은 SigmaHQ 주 규칙 세트의 파일 3,110개와 그 버전 이력 4,204갈래입니다. 그 가운데 탐지 논리를 실제로 바꾼 수정이 한 번이라도 있는 2,355갈래가 연구 모집단이고, 그 안의 수정 8,234건이 분석 단위입니다. 가장 오래된 버전이 2016년 12월 27일, 마지막 수정이 2026년 4월 1일이니 관측 기간은 9.3년입니다.

여기서 먼저 풀어야 할 문제가 있었습니다. 규칙이 좁아졌다는 것을 어떻게 알아내느냐입니다. 기존 연구는 규칙의 구조를 버전끼리 비교했습니다. 술어가 몇 개인지, 블록이 몇 개인지, 조건문이 어떻게 생겼는지를 봅니다. 그런데 예외를 다는 방법에는 두 가지가 있습니다. 하나는 새 예외 술어를 만드는 것이고, 다른 하나는 이미 있는 예외 목록에 값을 하나 더 넣는 것입니다. 뒤엣것은 술어 개수도, 블록 개수도, 조건문 한 줄도 건드리지 않습니다.

구조를 보는 도구가 앞엣것마저 제대로 보지 못한다는 점도 논문은 함께 셉니다. 예외를 부정으로 묶으면 그 안의 모든 연산이 극성을 뒤집고, 목록에 값을 더하면 구조가 아예 안 움직입니다. 수정 8,234건 중 부정 아래 술어를 가진 것이 3,231건, 술어의 값이 바뀐 것이 4,174건이고, 둘 중 하나라도 걸리는 것이 5,927건으로 72%입니다. 저자들이 처음에 만든 구조 분류기가 유일 커버리지 규칙에서 찾아낸 사건들은 막상 열어 보니 대부분 폐기된 해시 필드 문법 정리나 하위 기법 재태깅, 파일 이름 변경 같은 정비 작업이었습니다. 잘 만든 분류기였는데 틀렸다고 저자들은 적습니다.

논문이 찾아낸 예외 추가 1,642건 가운데 1,139건이 앞의 방식이고 503건이 뒤의 방식입니다. 뒤의 몫이 31%입니다. 구조를 비교하는 도구는 이 31%를 원리상 볼 수 없으므로, 규칙 진화에 관한 기존 집계는 좁아짐을 약 3분의 1만큼 적게 세어 왔다는 것이 논문의 결론입니다. 이 사각지대는 Sigma만의 것이 아닙니다. 값이 목록인 필드는 항목이 몇 개든 표현식에서 항 하나로 세어지고, 그건 대부분의 탐지 규칙 형식과 설정 언어가 공유하는 성질입니다. 논문은 Splunk Security Content, Elastic 탐지 규칙, YARA 문자열 집합, 방화벽 오브젝트 그룹을 그대로 이름을 들어 놓습니다. 값의 집합까지 세든지, 아니면 얼마나 적게 세고 있는지를 알고 그렇게 말하든지 둘 중 하나라는 것입니다.

그렇게 두 층위를 모두 세었더니 예외를 넣은 일이 1,642번, 걷어낸 일이 304번이었습니다. 5.4대 1입니다. 이 숫자가 유난히 시끄러운 소수 규칙 때문에 부풀었을 가능성도 확인했습니다. 예외 집합이 한 번이라도 수정된 559갈래만 놓고 보면 481갈래, 86.0%가 관측 종료 시점에 처음보다 좁아진 상태로 끝났고, 넓어진 것이 37갈래, 변화 없는 것이 41갈래였습니다. 규칙 단위로는 13대 1입니다. 좁히는 규칙은 반복해서 좁히고, 넓히는 규칙은 한 번 넓히고 마는 비대칭이 이 차이를 만듭니다.

그 비대칭이 어디서 오는지도 형식 안에 적혀 있습니다. 예외 블록에 이름을 하나씩 붙이면 조건문이 그 이름을 다 불러야 해서, 예외를 하나 더할 때마다 조건문을 고쳐야 합니다. 그런데 오래된 규칙은 대개 와일드카드 묶음으로 갈아탑니다. not 1 of filter_main_*처럼 써 두면 그다음부터는 블록 하나를 새로 쓰기만 하면 되고 다른 데는 손댈 일이 없습니다. 넣는 값이 사실상 0으로 떨어집니다. 빼는 값은 같이 떨어지지 않습니다. 빼려면 그 예외가 무엇 때문에 들어왔는지, 그 사정이 아직 유효한지, 그사이 무엇이 그 예외에 기대게 됐는지를 알아야 합니다. 소음이 나는 순간에 넣는 일은 누군가의 업무입니다. 빼는 일은 누구의 업무도 아닙니다.

2.1이 숫자를 얼마나 믿을 수 있나

가장 바쁜 20일이 예외 추가 전체의 20%인 326건을 차지하지만, 그 날들은 2022년부터 2025년까지 흩어져 있고 524갈래에서 나왔습니다. 그 20일을 통째로 빼도 비율은 4.9대 1로 남습니다. 저장소에 템플릿으로 놓인 자리표시 규칙들도 따로 확인했는데, 예외 추가 2건에 철회 0건이라 비율에 영향이 없었습니다.

탐지기 자체도 사람 손으로 검증했습니다. 눈가림 상태로 120건을 라벨링해 정밀도 0.828, 계층화 추정으로 재현율 0.911을 얻었습니다. 그 정밀도를 그대로 적용하면 탐지된 1,642건 뒤에 실제 좁아짐이 약 1,359건 있다는 계산이 나옵니다. 다만 분류 오차는 분자와 분모에 함께 걸리므로 절대 개수보다 비율 쪽이 더 튼튼하다고 논문은 적었습니다. 실패한 쪽도 그대로 보고합니다. 27건, 22.5%는 사람도 diff만 보고는 판단할 수 없었습니다. 좁아진 것과 그냥 다시 쓴 것의 경계가, 그 규칙이 도는 환경을 모르면 원래 가리기 어렵다는 뜻입니다. 라벨링할 때는 보여 주지 않았던 커밋 메시지를 나중에 맞춰 보니, 예외 추가 커밋의 30.9%에 오탐이나 정상이라는 이유 언어가 들어 있었습니다. 나머지 수정에서는 3.0%였으니 10.3배입니다. 여기서도 논문은 방어할 수 있는 것은 10.3배라는 배수이지 30.9%라는 값 자체가 아니라고 선을 긋습니다. 나머지 69%가 무엇이었는지는 이 데이터로 답할 수 없기 때문입니다.

이 연구는 선행 연구가 공개한 파이프라인 위에 얹혀 있습니다. 거기 오류가 있으면 조용히 상속되고 어떤 결과에서도 스스로 드러나지 않으므로, 저자들은 확장에 앞서 선행 연구의 표부터 다시 돌려 숫자가 맞는지 확인했습니다. 그 과정에서 불일치 4건이 나와 원저자들에게 보고됐습니다. 그중 하나는 데이터를 다뤄 본 사람에게 익숙한 종류입니다. 계보 메타데이터의 버전 목록과 커밋 목록에 서로 다른 필터가 걸려 있어서, 둘을 위치로 조인하면 올바른 커밋을 19.7%만 집어냅니다. 나머지는 엉뚱한 커밋을 그럴듯한 얼굴로 돌려줍니다. 조용히 실패하고 말이 되는 결과를 내놓는 조인이야말로 가장 보고할 값어치가 있는 오류라고 논문은 적었습니다. 이후의 커밋 대조는 위치가 아니라 커밋 날짜와 해시로 붙였습니다.

논문은 자기 수치를 추정값이 아니라 하한으로 부릅니다. 일반화나 복합 수정, 대소문자 변형을 정리한 경우처럼 탐지기가 놓치는 좁아짐이 아직 남아 있고, 그 세 가지가 모두 비율을 낮추는 쪽으로 작용하기 때문입니다. 제거 여부를 개수로 판정하는 방식도 제거를 실제보다 많게 셀 수 있어서, 86.7%라는 존속률 역시 하한이라고 적었습니다.

지속기간을 잴 수 있는 예외는 1,584건입니다. 그중 203건이 나중에 제거됐고 1,381건은 스냅숏 시점까지 그대로였습니다. 아직 살아 있는 것을 평균에서 빼 버리면 실제보다 짧은 수명이 나오므로, 논문은 그 1,381건을 우측 절단 관측으로 처리하는 생존분석을 썼습니다. 결과는 1개월 96.6%, 6개월 93.3%, 1년 89.9%, 3년 86.7%입니다.

생존분석에서 보통 먼저 찾는 값은 중앙 수명입니다. 절반이 사라지는 시점이 언제냐는 질문입니다. 논문은 그 값을 보고하지 않았는데, 없어서입니다. 곡선이 50%까지 내려간 적이 없습니다. 대신 3년 구간의 제한평균생존시간을 냈습니다. 1,095일 중 978일입니다. 예외 하나가 도입 이후 3년의 89%를 살아 있는 상태로 채운다는 뜻입니다. 관측이 짧아서 생긴 착시도 아닙니다. 역방향 추정으로 잰 추적기간 중앙값이 1,296일이라, 존속률을 보고한 3년 지평보다 깁니다.

제거되는 예외들은 일찍 아니면 영영이라는 모양을 그립니다. 제거의 52%가 6개월 안에, 76%가 1년 안에 일어나고 그 뒤로는 제거 위험률이 0에 수렴합니다. 예외가 만들어진 직후에 누군가 알아채면 걷히고, 그 시기를 넘기면 그 뒤로는 아무도 손대지 않는다는 뜻입니다.

저자들은 그 까닭을 검토가 시작되는 시점에서 찾습니다. 규칙 검토는 그 규칙이 알람을 울릴 때 시작됩니다. 분석가는 알람을 보고 조사하고, 쓸모가 있었는지 판단하고, 규칙을 손봅니다. 그런데 예외는 자기가 덮은 영역에서 바로 그 알람을 없앱니다. 규칙은 나머지 영역에서 계속 울리므로 건강해 보이고, 덮인 영역은 아무 증거도 만들지 않습니다. 없다는 증거가 아니라 증거의 부재입니다. 예외는 자기를 재검토하게 만들 신호를 스스로 제거하고, 오래 서 있을수록 그것을 들출 계기는 줄어듭니다. 저자들은 이 대목에 인과를 주장하지 않는다는 단서를 붙여 두었습니다. 데이터가 그리는 모양과 어긋나지 않는 설명일 뿐입니다.

3.1그 규칙이 마지막 방어선인지는 아무 상관이 없었다

예외가 조금이라도 결과를 보고 관리되고 있다면, 그 공격 기법을 지키는 규칙이 그것 하나뿐일 때는 더 빨리 재검토돼야 합니다. 논문은 이 코퍼스에서 ATT&CK 기법 329개를 확인했고 그중 84개, 4분의 1이 규칙 단 하나로 커버되고 있었습니다. 여기에 붙은 예외를 따로 갈라 보니 71건이 유일 커버리지 규칙에, 1,268건이 대체 규칙이 있는 쪽에 있었습니다. 태그가 없어 어느 쪽으로도 배정할 수 없는 갈래는 기본값을 주지 않고 비교에서 아예 뺐고, 그렇게 남은 것이 1,339건입니다.

스냅숏 시점까지 살아남은 비율은 각각 88.7%와 86.2%였고, 어느 한 시점이 아니라 두 곡선 전체를 놓고 돌린 로그순위검정의 p값은 0.49였습니다. 두 곡선이 구별되지 않습니다. 표본을 늘려 가며 세 번 돌린 결과도 0.96, 0.31, 0.49로 같은 방향이었습니다. 저자들은 이것을 못 찾았다가 아니라 찾았다로 보고합니다. 예외를 걷을지 말지를 정하는 그 어떤 과정도, 그 규칙 뒤에 얼마나 많은 탐지가 서 있는지를 지금 전혀 보지 않는다는 뜻이기 때문입니다. 알람이 울리는 순서대로 만들어지는 대기열에는 어떤 침묵이 중요한지를 알 방법이 없습니다.

71건이라는 수 자체는 작습니다. 다만 그 71건 중 63건이 여전히 서 있고, 그 뒤에는 대체 탐지가 없습니다.

3.2새 규칙을 길들이는 과정이 아니다

저장소가 커졌으니 예외도 따라 늘어난 것 아니냐고 물을 수 있습니다. 논문은 그날그날 살아 있는 규칙 수로 나눠 봅니다. 규칙 하나당 순증 예외가 초기 몇 해에는 0.1개에 못 미치다가 2026년에는 0.57개쯤 됩니다. 평균적인 규칙 하나가 지고 있는 짐이 자릿수 하나만큼 늘었습니다.

남은 설명은 초기 튜닝입니다. 새로 쓴 규칙을 길들이는 동안 예외가 몰리는 것뿐일 수도 있습니다. 예외가 붙는 시점에 그 규칙의 나이 중앙값은 492일이었습니다. 작성 후 90일 안에 붙은 것이 24%, 1년 안이 44%라 초기 튜닝 봉우리는 분명히 있지만, 56%는 첫 해가 지난 뒤에 붙습니다. 앞의 존속 결과와 겹쳐 놓으면 논문이 한 줄로 요약한 생애가 나옵니다. 예외는 규칙이 태어난 지 열여섯 달쯤에 도착해서, 그 뒤에 오는 모든 것보다 오래 삽니다.

유지보수라는 일의 구성 자체도 바뀌었습니다. 수정이 50건 이상 있는 달 77개를 앞뒤로 갈라 보면, 전체 수정 활동에서 예외 추가가 차지하는 몫이 3.3%에서 7.9%로 올랐습니다. 여기엔 그럴듯한 기계적 설명이 하나 붙을 수 있습니다. 값 수준 예외는 붙일 목록이 이미 있어야 가능하니, 규칙에 필터가 쌓일수록 기회가 저절로 늘어난다는 것입니다. 그 설명이 맞다면 상승분을 값 수준이 끌고 가야 하는데 그렇지 않았습니다. 값 수준은 1.5%에서 2.2%로 움직여 통계적으로 유의하지 않았고, 그런 의존성이 없는 술어 수준이 1.7%에서 5.7%로 세 배 넘게 뛰었습니다. 저장소가 성숙할수록 유지보수의 무게중심이 탐지를 새로 쓰는 쪽에서 이미 있는 탐지를 좁히는 쪽으로 옮겨 간 것입니다. 다만 달은 서로 독립인 관측이 아니어서 이 추세의 유의성은 낙관적으로 나오고, 읽어야 할 것은 효과 크기 쪽이라고 논문이 스스로 적어 두었습니다.

예외가 남아 있다는 것과 그 예외가 위험하다는 것은 다른 이야기입니다. 논문은 그 간격을 값 하나하나를 분류하는 방식으로 메웁니다. 예외에 적힌 경로값 5,336개를 놓고, 공격자가 이 조건을 충족시키려면 무엇을 해야 하는지로 나눴습니다. 58.2%는 파일명이나 확장자만 지정합니다. 33.0%는 보호된 시스템 경로라 권한 상승이 먼저 필요합니다. 5.9%는 사용자가 쓸 수 있는 위치입니다. 앞과 뒤를 합친 64.1%가 권한 없는 프로세스가 파일 이름을 고르는 것만으로 충족됩니다.

커맨드라인이나 레지스트리 데이터처럼 내용 필드에 적힌 예외 1,573개는 이 경로 분류에서 통째로 뺐습니다. 공격자가 자기 커맨드라인을 직접 쓰므로 권한 문제 자체가 성립하지 않기 때문입니다. 저자들은 앞선 작업에서 이것을 경로 분류에 섞었더니 자유 진입 몫이 부풀었다고 적고, 그 정정을 기록으로 남겼습니다.

여기에 축을 하나 더 겹치면 실행할 수 있는 기준이 나옵니다. 그 예외가 얼마나 넓게 그려졌는지입니다. 보호된 경로라 해도 파일 하나를 지목할 수도 있고 디렉터리 트리 전체를 열 수도 있습니다. 접근 비용과 폭을 교차해 5,336개를 다시 나눈 결과가 아래입니다.

이 표에서 두 가지가 반대 방향으로 드러납니다. 하나는 안전지대가 생각보다 좁다는 것입니다. 권한이 필요하니 괜찮다고 여겼던 33.0% 가운데 상당수가 실은 넓게 그려져 있습니다. 보호된 경로 예외 1,759개 중 708개, 40.3%가 파일 이름이 아니라 디렉터리 트리나 다중 와일드카드였습니다. 잠긴 문 뒤의 포괄 면제이지 정밀한 예외가 아닙니다. 정말로 방어자에게 비용이 없다고 말할 수 있는 몫은 33.0%가 아니라 18.4%입니다.

다른 하나는 그래서 무엇부터 보면 되는지가 나온다는 것입니다. 예외를 전부 검토하라는 지시는 실행할 수 없습니다. 수천 개가 있고 저마다 이유가 있고 그것들을 구별할 근거가 없습니다. 폭과 접근 비용 두 축으로 정렬하면 이 코퍼스에서 먼저 볼 것이 657개로 줄고, 그대로 두어도 되는 984개가 따로 갈립니다. 두 속성 모두 규칙을 배포하기 전에 텍스트만 보고 계산됩니다.

4.1논문이 스스로 그은 경계

여기서 논문은 자기 주장의 범위를 좁혀 둡니다. 계산할 수 있는 것은 넓고, 권한 없이 점유할 수 있고, 오래 검토되지 않은 예외까지입니다. 계산할 수 없는 것은 그 예외가 틀렸는지입니다. 제외된 대상이 정말 정상인지는 그 규칙이 도는 환경에 달려 있고, 이 연구는 어떤 환경도 관측하지 않았습니다. 그 소프트웨어가 실제로 사방에서 도는 조직이라면 넓은 예외가 옳은 결정일 수 있고, 좁은 예외가 실수일 수 있습니다. 무엇을 먼저 볼지 정하는 방법이지, 본 것에 대한 판정이 아닙니다.

이 창이 실제로 악용됐다는 증거도 이 논문에는 없습니다. 공격자도 배포 환경도 관측하지 않았기 때문입니다. 다만 실현 가능성 자체는 별개 연구가 이미 보였습니다. Uetz 연구진은 실제 기업망에서 널리 쓰이는 SIEM 규칙의 절반 가까이에 대해 우회를 구성해 냈습니다. 그쪽이 가능성을 세웠고, 이쪽은 그런 창 하나가 좋은 이유로 열린 뒤 그대로 남는다는 것을 셌습니다.

해법으로 제시한 것은 셋인데 모두 새 연구를 요구하지 않습니다. 예외에 만료일이나 재검토일을 달아, 계속 서 있는 것이 기본값이 아니라 결정이 되게 하는 것이 첫째입니다. 예외를 제안하는 그 순간에 그것이 좁히는 규칙이 해당 기법의 유일한 커버리지인지를 계산해 풀 리퀘스트에 띄우는 것이 둘째입니다. 예외를 쓸 때 폭과 접근 비용을 검사해, 넓고 자유롭게 진입 가능한 예외는 그냥 병합되지 않고 근거를 대게 하는 것이 셋째입니다. 셋 중 가장 작은 것이 셋째이고, 그것만으로 12.3% 구간에 닿습니다. SigmaHQ 자신도 그 방향으로 한 걸음 옮긴 적이 있습니다. 2024년 8월 사양 v2.0에서 예외를 규칙 바깥의 독립 객체로 떼어 내, 여러 탐지 규칙에 한꺼번에 적용하는 필터 규칙을 들였습니다. 예외 관리가 실무에서 문제로 인식됐다는 독립적인 증거라고 논문은 읽습니다. 같은 사실이 한계이기도 합니다. 그 형태로 쓰인 예외는 여기서 분석한 규칙 이력 안에 나타나지 않을 수 있는데, 장치가 존재한 기간이 관측 창의 마지막 20개월 남짓이라 빠진 몫의 크기는 무한정이 아닙니다.

논문은 권고를 받을 쪽을 셋으로 나누는데, 가운데가 지금껏 아무도 말을 걸지 않은 쪽입니다. 한쪽 끝에는 결정을 내리고 기록에 남는 규칙 관리자가 있고, 다른 쪽 끝에는 규칙 진화를 재는 연구자와 도구 제작자가 있습니다. 그 사이에 규칙 세트를 받아 쓰는 조직이 있습니다. 저장소의 예외를 하나도 빠짐없이 물려받으면서 diff를 읽는 일은 거의 없고, 자기가 내린 결정이 아니라는 바로 그 이유로 손대기 가장 좋은 위치에 있습니다. 오늘 딸려 온 예외 하나는 기댓값으로 영구적이니 머지를 그 예외가 받게 될 마지막 리뷰로 취급하라는 것이, 논문이 이쪽에 준 한 줄입니다.

이런 일이 실제로 벌어진 적도 있습니다. 검증 과정에서 살펴본 어떤 수정에서, 한 관리자가 파일명으로만 적혀 있던 예외 다섯 개를 절대 경로 세 개로 바꾸고 둘은 아예 지웠습니다. 누가 시켜서 한 일이 아니고, 두 표기의 차이를 아는 사람이 한 일입니다. 관행은 이미 있습니다. 없는 것은 그렇게 하라고 요구하는 장치입니다.

여기까지는 보안 저장소 이야기입니다. 그런데 데이터를 다루는 쪽에서 읽으면 낯익은 구조가 보입니다. 정제 규칙이 정상 데이터를 걸러 내기 시작하면 거기에 제외 조항이 하나 붙습니다. 검증 규칙이 자꾸 실패를 뱉으면 화이트리스트에 값을 하나 더 넣습니다. 라벨링 가이드에는 이 경우는 예외로 둔다는 문장이 늘어납니다. 어느 것도 잘못된 결정이 아닙니다. 그 시점에는 그게 맞았습니다.

논문이 보안 저장소에서 잰 네 가지가 데이터 파이프라인에서도 같은 모양으로 성립하는지는 아직 아무도 세지 않았습니다. 아래 대응은 논문에 없습니다. 이 글이 옮겨 본 읽기입니다. 다만 옮겨 붙는 자리가 꽤 정확합니다.

마지막 줄이 실무에서 바로 써 볼 수 있는 대목입니다. 논문의 두 축을 데이터 규칙에 옮기면 질문이 이렇게 됩니다. 이 제외 조항은 얼마나 넓게 걸러 내는가. 그리고 그 조건은 얼마나 쉽게 충족되는가. 파일명 하나로 충족되는 예외가 보안 쪽에서 위험했던 이유는, 그것을 만족시키는 데 아무 대가가 들지 않기 때문입니다. 데이터 쪽에도 같은 종류의 예외가 있습니다. 특정 소스 이름이나 특정 필드값 하나로 검증을 건너뛰게 만든 조항이 그렇습니다.

지금 파이프라인을 굴리고 있다면 던져 볼 만한 질문은 셋입니다.

• 우리 정제 규칙과 검증 규칙, 라벨링 가이드에 붙은 제외 조항의 목록이 한곳에 있는가.
• 각 조항이 언제 왜 들어왔는지, 마지막으로 재검토된 시각이 언제인지가 적혀 있는가.
• 각 조항이 지금 이 데이터의 몇 %를 덮고 있는지를 다시 셀 수 있는가.

세 번째 질문이 이 논문이 새로 얹은 부분입니다. 목록과 이력을 잘 남겨도, 그 조항이 지금 무엇을 덮고 있는지를 다시 세지 않으면 목록은 과거 결정의 기록으로만 남습니다. 논문이 보여 준 대로, 그 조항이 덮은 영역은 아무 신호도 만들지 않습니다. 다시 세는 절차 없이는 아무 일도 없는 것과 구별되지 않습니다.

논문의 결론 문장은 짧습니다. 부족한 것은 성실함이 아니라 신호라는 것입니다. 그동안 그 저장소에서 예외를 단 사람들은 모두 실제 문제에 대한 숙고된 대응을 했습니다. 다만 자기가 단 예외 가운데 어느 것이 넓고, 공격자에게 싸고, 유일한 규칙 위에 서 있는지를 알려 주는 것이 아무것도 없었을 뿐입니다. 그중 둘은 배포 전에 계산됩니다.

1차 사료

• 1.Dhananjeyan, S., U, K. (2026). "The Exclusion Ratchet: False-Positive Suppression Accumulates and Persists in Detection Rule Repositories." arXiv:2608.31062. 이 글이 근거로 삼은 논문.

학술 논문

• 2.Long, M., Evans, D. (2026). "Evolution of Log-Based Detection Rules in Public Repositories." arXiv:2605.05383. 선행 연구 — 되돌려진 수정의 복원시간만 측정했고, 이 논문이 재현 후 확장한 대상.
• 3.Uetz, R., Herzog, M., Hackländer, L., Schwarz, S., Henze, M. (2024). "You Cannot Escape Me: Detecting Evasions of SIEM Rules in Enterprise Networks." Proceedings of the 33rd USENIX Security Symposium, pp. 5179–5196. 실제 기업망에서 SIEM 규칙 절반 가까이의 우회 가능성을 실증.

공식 문서

• 4.SigmaHQ. (2024). "Sigma Specification v2.0." 예외를 규칙 바깥의 독립 필터 객체로 분리한 사양.