2026년 10월은 마치 패치 마녀가 활동한 듯한 달이었습니다.
최종 주만 잘라내어도 CISA는 PHP의 취약점 2건(통칭 “PHP2Shell”)을 악용 확인済み 카탈로그(KEV)에 추가했습니다. Firefox 159는 하나의 권고문으로 167개의 CVE(공개된 취약점에 부여되는 식별 번호)를 공개했습니다. WordPress 7.1.4에서는 22개의 취약점이 수정되었습니다. 월 초반에는 Microsoft의 Patch Tuesday가 1,400건을 넘어섰습니다. Oracle의 분기 업데이트 역시 1,295개에 달하는 패치를 배포했습니다.
제목만 나열해 보면 “소프트웨어가 고장나기 시작했다”고 읽힙니다. 하지만 이 숫자를 나란히 놓고 보니 다른 모습이 보입니다.
본 기사의 가설은 이렇습니다. 증가한 것은 버그 그 자체라기보다, 버그를 발견하는 능력과 **셈법(측정 방식)**이었습니다. 그리고 진정으로 질문받고 있는 것은, 이러한 변화를 수용하는 프로세스 측면입니다.
참고로 이 글은 영어로 작성된 Medium 버전을 기반으로 Qiita에 맞게 재구성되었습니다.
우선 규모부터 살펴보겠습니다. CVE Program의 분기 데이터를 사용하여 1월부터 9월까지 같은 기간을 비교했습니다.
증가 자체가 2026년에 시작된 것은 아닙니다. 2024년과 2025년에도 두 자릿수의 성장이 있었습니다. 그럼에도 불구하고 2026년은 차원이 다릅니다. 9월 말 기준으로 이미 2025년 연간(48,244건)을 초과했습니다.
여기서 한 가지 주의할 점이 있습니다. 이 수치는 공개일로 계산된 숫자입니다. 2026년 10월에 공개된 CVE가 몇 년 전에 출시된 코드의 버그를 지적하는 것이 이상하지 않습니다.
공개일은 버그가 혼입된 날짜가 아닙니다. “이번 달에 발견된 버그”와 “이번 달에 만들어진 버그”는 별개의 숫자입니다.
가장 이해하기 쉬운 예시는 Firefox입니다.
Mozilla는 2025년 동안 매월 약 20~30건의 보안 버그를 수정했습니다. 하지만 이것이 2026년 4월에는 423건으로 늘어났습니다. 이 중 271건은 Anthropic의 Claude Mythos Preview를 사용하여 발견된 것입니다.
Mozilla는 이를 출하된 코드에 잠재되어 있던 버그라고 설명합니다. 새로 만들어진 것이 아니라, 예전부터 집에 살고 있던 유령 같은 존재입니다.
Mozilla Hacks의 해설 기사를 읽어보면, 단순히 “AI가 버그를 발견했다”로 끝나는 이야기가 아님을 알 수 있습니다. Firefox 팀은 기존의 Fuzzing 기반 위에 에이전트형 파이프라인을 결합했습니다. 재현 가능한 테스트 케이스를 필수화하고, 중복 제거와 Triage(분류) 과정을 거친 후에 수정에 반영합니다. 성과를 실용적인 것으로 만든 것은 모델의 성능뿐만 아니라, 그 주위의 검증 시스템이었습니다.
여기서 도출할 수 있는 가설은 단순합니다. 탐지 메커니즘이 바뀌면, 제품이 같더라도 버그 건수는 급증한다는 것입니다. 그래프의 상승세만으로는 품질 저하인지, 아니면 단순히 불빛이 밝아진 것인지를 구분할 수 없습니다.
두 번째 함정은 측정 방법 자체의 변화입니다.
Firefox 159의 권고문에 따르면, 사내에서 발견된 메모리 안전성 버그는 하나의 CVE로 묶지 않고, 버그별 CVE로 공개하는 방침으로 변경되었습니다. 작업량이 같더라도 제목상의 숫자는 커집니다.
CVE 시스템 전체도 바뀌었습니다. CVE를 부여할 수 있는 조직(CNA)은 2022년 말의 263개에서 2026년 3분기 말에는 563개까지 늘어났습니다. 발행처가 늘어나면, 기록물도 늘어납니다. 이는 소프트웨어의 안전성과는 관계없이 발생하는 현상입니다.
Microsoft의 10월 Patch Tuesday에 이르러서는, 집계하는 사람에 따라 합계가 1,407건에서 1,416건까지 오차가 발생했습니다. 알려진 문제나 서드파티 컴포넌트를 포함할지 여부에 따라 숫자가 달라지는 것입니다.
품질 지표에서도 같은 일이 벌어집니다. 이슈 생성 규칙을 바꿨다거나, 티켓의 분할 단위를 바꿨다거나, 심각도 정의를 재검토했다는 것 모두 대시보드 상에서는 “품질의 변화”로 보이게 만듭니다.
그래프가 급등하면, 가장 먼저 측정 방법이 바뀌지 않았는지 확인해야 합니다. 10월은 그 당연한 것을 대규모로 보여준 달이었습니다.
발견하는 능력이 높아지면, 다음은 받아들이는 측(수용하는 시스템)이 막힙니다. 이 부분이 보안 영역을 넘어 가장 외부로 가져가기 쉬운 부분입니다.
WordPress의 HackerOne(취약점 보고를 받는 플랫폼)에는 약 10년 동안 매월 20~30건의 보고서가 도착했습니다. 하지만 2026년 7월에는 450건, 8월에는 773건이었습니다.
보안 팀의 보고에 따르면, 2026년의 보고 건수는 3,000건을 넘어서며 과거 12년간의 합계를 넘어섰습니다. 이는 스팸이나 대상 외 보고를 제외한 수치입니다.
GitHub도 같은 파도를 겪었습니다. Advisory Database는 2026년 5월에 검토된 취약점 공지(advisory) 1,560건을 공개했습니다. 이는 평소 월 평균의 5배가 넘는 양입니다. 그럼에도 불구하고 유입량에는 따라가지 못했고, 일부 검토 건은 몇 주를 기다려야 했습니다.
발견이 쉬워졌다고 해서 병목 현상이 사라지는 것은 아닙니다. 단지 검증, 중복 제거, 조정, 수정, 공개의 단계로 이동했을 뿐입니다.
그렇다면 넘쳐나는 티켓들에는 어떻게 대처했을까요? 양 팀의 대응책을 나열해 보면 의외로 간단했습니다.
| 대응책 | WordPress 사례 | Mozilla 사례 |
|---|
| 진입점에서 대상 좁히기 | 9월 1일에 버그 바운티(bug bounty) 대상 범위를 재검토하여 영향이 명확한 문제에 집중함 | 탐색 대상을 소스 파일 단위로 지정하고 AI에게 조사하도록 함 |
| ... | | |
| 결과적으로, WordPress의 트리아지 대기 건수는 359건에서 두 자릿수까지 줄었습니다. 하지만 이것으로 끝난 것은 아닙니다. 이는 양적인 문제에 대한 운영상의 해답일 뿐, 모든 보고서를 지연 없이 처리할 수 있다는 증거는 아닙니다. 이 점은 구분해 둘 필요가 있습니다. | | |
그렇다면 취약점이 두 배로 늘어난 만큼 공격도 증가했을까요?
단서로 CISA의 KEV 카탈로그를 집계했습니다. KEV는 실제로 악용된 증거가 있는 취약점만을 모은 목록입니다.
출처: CISA KEV 공식 데이터 집계 (2026년 10월 30일 기준 스냅샷). dateAdded는 카탈로그에 추가된 날짜이며, 악용이 시작된 날짜가 아닙니다.
CVE 공개 건수는 KEV 추가 건수보다 훨씬 빠르게 늘고 있습니다. 하지만 두 숫자를 나누어 '악용률'이라고 부를 수는 없습니다. KEV에 추가된 것 중에는 몇 년 전의 CVE도 포함되어 있어, 비교하는 모집단 자체가 다르기 때문입니다.
악용률을 측정하려면, 특정 기간에 공개된 CVE를 코호트(cohort)로 추적하고, 나중에 악용 증거가 발견된 건수를 세어야 합니다.
반면, 절대 수치를 보면 낙관할 수도 없습니다. 1월부터 10월까지 비교했을 때, 2025년의 214건 대비 2026년은 282건으로 약 32% 증가했습니다. PHP2Shell의 경우, PHP가 긴급 수정(emergency patch)을 내놓은 10월 21일보다 4일 전인 10월 17일에 이미 악용 시도가 관측되었습니다 (AWS 보고).
품질이라는 단어로 바꾸자면, '접수된 버그의 수'가 아니라 '실제 운영 환경에서 발생한 장애'나 '사용자에게 도달한 영향'으로 봐야 한다는 이야기입니다. 다만 분모와 분자의 모집단을 맞추지 않으면, 아무리 깨끗한 비율이라도 거짓말을 할 수 있습니다.
이 한 달 동안 정말 커진 리스크가 있다면, 그것은 버그의 수가 아닙니다. 수정된 코드가 들어가서 사용자 손에 도달하기까지 걸리는 시간, 이른바 패치 갭(patch gap)입니다.
버그를 찾아내는 모델은 패치도 읽을 수 있습니다. Anthropic의 Frontier Red Team 보고서에 따르면, Mythos Preview는 Firefox의 수정 사항이 공개 소스에 올라온 지 1시간 만에 작동하는 익스플로잇(exploit)을 만들었습니다. 이 수정이 포함된 릴리스는 당시 아직 18일이나 남아 있었습니다.
Mozilla는 이에 대응하여 새로운 빌드를 매주 사용자에게 전달하는 체제로 전환했습니다. 또한, 수정 사항이 릴리스될 때까지 일부 회귀 테스트(regression test)를 공개하지 않겠다는 대책도 발표했습니다.
품질 현장에 비유하자면, '수정이 병합되었다'와 '수정이 운영 환경에 배포되었다' 사이의 시간입니다. DORA 지표에서 말하는 변경 리드 타임(Change Lead Time, 변경 사항이 운영 환경에 도달하기까지 걸리는 시간)과 유사한 생각입니다. 발견 속도가 빨라질수록, 이 간격의 느림이 더욱 두드러지게 나타납니다.
10월의 패치 산을 통해 보안 외적으로도 얻을 수 있는 교훈 3가지를 제시합니다.
그래프가 급등하면, 먼저 측정 방법을 의심하라. 탐지 도구 도입, 접수 규칙 변경, 집계 범위 차이는 모두 품질 변화처럼 보일 수 있습니다. 그래프에는 측정 방법이 바뀐 날짜를 주석으로 남겨두세요.
유입량이 급증하면, 입구와 출구부터 손대라. 대상 범위를 좁히고, 재현을 게이트로 삼으며, 릴리스 과정을 자동화하세요. 재현 절차 없는 보고서는 라벨을 붙여 반송 처리하세요. 사람의 판단은 마지막 판정에 집중시키세요.
건수(件数)가 아니라, 도달하는 시간(時間)을 보라. 수정이 병합되었는지 여부가 아니라, 운영 환경에 도달했는지를 추적하세요. 병합일과 배포일을 티켓 단위로 기록하면, 그 차이가 그대로 지표가 됩니다.
밝은 빛 덕분에 계속 집 안에 있던 유령들이 마침내 보이게 되었습니다. 늘어난 것은 유령이 아니라, 찾아내는 힘과 세는 방식입니다.
그리고 무서운 것은 10월에 몇 마리가 발견되었느냐가 아닙니다. 위치를 알게 된 후에도 문을 열어두고 있는 시간 그 자체입니다.
- CVE 프로그램 지표(CVE Program Metrics)
- Mozilla Hacks에 실린 내용: Claude Mythos Preview를 사용한 Firefox 강화 작업 비하인드 스토리
- 자동화된 공격자로부터 패치 격차 방어하기 (Mozilla)
- Mozilla 재단 보안 권고 2026-118
- 코어 보안 이니셔티브(Core Security Initiative): 두 달 차 (WordPress)
- 권고 데이터베이스 내부와 취약점 볼륨이 기록을 경신할 때 발생하는 일 (GitHub)
- CISA 알려진 악용 취약점 (Known Exploited Vulnerabilities) (cisagov/kev-data)
- N일(N-days) 보고서 (Anthropic Frontier Red Team)
- AWS: Amazon 위협 인텔리전스가 공개 전 PHP2Shell 악용 탐지
- 패치의 마녀의 달, 2026년 10월 (Medium 버전)
