--- title: "보안 취약점 90일 공개 유예, 대규모 언어 모델 시대엔 이미 죽었다는 주장" published: 2026-05-09T21:42:50.000Z canonical: https://jeff.news/article/2536 --- # 보안 취약점 90일 공개 유예, 대규모 언어 모델 시대엔 이미 죽었다는 주장 글쓴이는 대규모 언어 모델(LLM)이 취약점 발견과 익스플로잇 제작 속도를 너무 빠르게 만들어 기존 90일 책임 공개 모델이 더 이상 안전망이 아니라고 주장해. 같은 버그를 6주 안에 11명이 찾고, 공개 패치가 30분 만에 동작하는 공격 코드로 바뀌는 사례를 들며 치명적 보안 이슈는 즉시 최우선 장애처럼 다뤄야 한다고 말해. ## 90일 유예가 전제로 삼던 세계가 사라졌다는 주장 - 글쓴이의 결론은 꽤 세게 나옴: 치명적 취약점에 90일 책임 공개 기간을 주는 모델은 끝났다는 것임 - 예전 모델은 “버그를 찾은 사람이 드물고, 공격 코드 제작은 느리다”는 전제 위에 있었음 - 그런데 대규모 언어 모델(LLM)이 취약점 탐색, 패치 diff 분석, 개념 증명 코드 작성 시간을 확 줄이면서 그 전제가 깨졌다는 주장임 - 2019년식 사고방식은 대략 이랬음 - 연구자가 버그를 찾고 공급자에게 보고함 - 공급자는 며칠 triage하고, 몇 주 안에 고치고, 한 달쯤 지나 배포함 - 공개까지 90일을 주면 사용자 보호와 공급자 대응 사이의 균형이 맞는다고 봤음 - 공격자는 패치가 나온 뒤에도 며칠에서 몇 주는 분석해야 할 거라고 믿었음 - 글쓴이는 이 모든 가정이 이제 틀렸다고 봄 - 같은 취약점을 여러 사람이 거의 동시에 찾을 수 있음 - 패치가 공개되는 순간 공격자가 diff를 읽고 바로 공격 코드를 만들 수 있음 - “아직 공개 안 됐으니 안전하다”는 말이 더 이상 사용자 보호가 아니라 노출 시간 연장에 가깝다는 것임 ```mermaid sequenceDiagram participant 연구자 participant 공급자 participant 공개저장소 participant 공격자 participant 운영팀 연구자->>공급자: 치명적 취약점 보고 공급자->>공개저장소: 패치 커밋 또는 보안 공지 공개 공격자->>공개저장소: diff와 설명 자동 분석 공격자->>공격자: 대규모 언어 모델로 공격 코드 생성 공격자->>운영팀: 미패치 시스템 공격 운영팀->>공급자: 뒤늦게 패치와 완화책 확인 ``` ## 사례 1: 같은 결제 버그를 6주 만에 11명이 찾음 - 글쓴이는 한 회사에 꽤 심각한 결제 관련 버그를 제보했다고 함 - 공격자가 웹사이트에서 상품을 구매한 뒤, 서버로 돌아가는 응답을 직접 조작할 수 있는 구조였음 - 서버가 응답 서명을 검증하지 않아, 5천 달러짜리 물건을 0달러로 산 것처럼 만들거나 결제를 완료 처리할 수 있었다고 설명함 - 그런데 triage 팀의 답변이 더 충격적이었음 - 이미 3월에 처음 보고된 버그였고, 글쓴이는 11번째 제보자였다고 함 - 약 6주 동안 11명이 같은 치명적 취약점을 찾은 셈임 - 글쓴이는 여기서 “정직하게 보고한 사람이 10명이라면, 보고하지 않은 사람은 몇 명일까?”라는 질문을 던짐 - 버그 바운티 구조도 문제를 더 키울 수 있음 - 같은 버그를 여러 명이 찾아도 보상과 크레딧은 보통 첫 제보자에게만 감 - 나머지 연구자는 중복 처리되고, 일부는 다음번엔 판매하거나 공개하지 않는 선택을 할 수도 있음 - 대규모 언어 모델은 선의의 연구자와 공격자를 구분하지 않음 > [!WARNING] > 같은 취약점을 여러 연구자가 며칠 간격으로 재발견하는 환경에서는 “공급자에게 90일을 줬으니 괜찮다”는 말이 거의 의미가 없어짐. 이미 누군가 공격에 쓰고 있을 가능성을 배제하기 어렵기 때문임. ## 사례 2: 패치에서 공격 코드까지 30분 - 글쓴이는 React 보안 패치 사례도 가져옴 - 공개 블로그 글과 패치를 읽고, 로컬 테스트 앱을 대상으로 동작하는 서비스 거부 공격 개념 증명 코드를 만드는 데 30분이 걸렸다고 함 - 대규모 언어 모델이 diff 이해, 취약 경로 파악, 개념 증명 코드 작성의 귀찮은 부분을 대부분 처리했다고 설명함 - 이건 엔데이 공격의 시간 감각을 바꿔버림 - 과거에는 공개 패치를 실제 공격 코드로 바꾸려면 숙련된 리버스 엔지니어가 며칠에서 몇 주를 써야 했음 - 이제 단순한 버그는 분 단위, 복잡한 버그도 시간 단위로 줄어들 수 있다는 게 글쓴이의 주장임 - 패치가 나왔으니 관리자가 며칠 안에 올리면 된다는 안전망이 사라졌다는 얘기임 ## 사례 3: 리눅스 커널 취약점 두 건이 보여준 새 현실 - Copy Fail은 리눅스 커널 암호화 서브시스템의 논리 오류로 설명됨 - 글쓴이에 따르면 2017년 이후 배포된 주요 리눅스 배포판에 영향을 줬고, 732바이트짜리 파이썬 스크립트로 루트 권한을 얻을 수 있었다고 함 - Ubuntu, RHEL, Amazon Linux, SUSE 등 주요 배포판이 언급됨 - Xint Code 쪽 연구자는 사람의 초기 통찰을 바탕으로 인공지능 지원 분석을 돌려, 보통 몇 주 걸릴 수 있는 커널 코드 감사를 약 1시간으로 줄였다고 설명됨 - 더 무서운 건 공개 이후 실제 공격으로 이어졌다는 점임 - Copy Fail은 메인라인 커밋으로 패치가 나왔고, algif_aead 모듈을 비활성화하는 완화책도 제시됨 - 이후 이란 계열 공격자들이 Ubuntu 서버를 침해하고 디도스 인프라 노드로 활용한 정황이 관찰됐다고 글은 전함 - 그리고 일주일도 안 돼 Dirty Frag가 나옴 - CVE-2026-43284와 CVE-2026-43500을 연결한 리눅스 커널 취약점으로, IPSec ESP와 RxRPC 네트워크 모듈 경로가 언급됨 - Copy Fail 완화책인 algif_aead 차단을 해도 이 공격은 다른 경로를 타기 때문에 막히지 않았다고 함 - Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 등 주요 배포판에서 결정적으로 루트 권한 상승이 가능했다고 설명됨 - Dirty Frag 공개 과정은 책임 공개 모델의 약점을 그대로 보여줌 - 연구자는 4월 29~30일 보안 메일로 보고했고, 5월 7일 배포판 메일링 리스트와 5일 embargo를 조율함 - 그런데 같은 날 몇 시간 안에 무관한 제3자가 ESP 취약점의 상세 익스플로잇 정보를 공개하면서 embargo가 깨짐 - 그 시점에 패치가 준비된 리눅스 배포판은 없었다고 글은 말함 - Microsoft Defender 팀은 공개 24시간 안에 제한적인 실제 악용을 확인했다고 함 ## 그래서 무엇을 바꿔야 하나 - 글쓴이의 요구는 단순함: 모든 치명적 보안 이슈를 최우선 장애처럼 다루라는 것임 - “내일”, “다음 스프린트”, “영향도 평가 후”가 아니라 보고가 들어온 순간부터 시계가 돈다고 봐야 한다는 주장임 - 누군가 보고했다면, 다른 10명도 이미 알고 있고 그중 한 명은 선의가 아닐 수 있다고 가정하라는 얘기임 - 연구자에게도 짧은 공개 창을 압박하라고 말함 - 예전에는 공급자에게 시간을 주는 관행이 사용자 보호에 도움이 됐음 - 하지만 같은 취약점이 여러 경로로 재발견되는 시대라면, 긴 유예는 사용자 보호가 아니라 공격 가능 기간일 수 있음 - 취약점 관리도 주간·월간 리듬에서 벗어나야 한다고 봄 - 주 1회 스캔, 스프린트 triage, 정기 패치 사이클은 공격자의 속도를 따라가지 못함 - 치명적 이슈의 최대 대응 시간은 “며칠”이 아니라 “몇 시간”이어야 한다는 쪽에 가까움 > [!TIP] > 운영팀 입장에서는 보안 패치 공지를 기다리는 것보다 upstream diff, 릴리스 노트, 의존성 변경을 자동으로 분석하는 쪽이 점점 중요해짐. 공격자도 같은 신호를 보고 움직이기 때문임. ## 방어 쪽도 대규모 언어 모델을 파이프라인에 넣어야 한다는 결론 - 글쓴이는 대규모 언어 모델을 보안 대응의 1급 시민으로 넣으라고 주장함 - pull request, merge, deploy 시점에 인공지능 지원 보안 리뷰를 돌리라는 것임 - linter와 unit test처럼 코드가 들어오는 순간 취약 패턴을 잡아야 한다는 얘기임 - upstream 패치 분석도 자동화 대상임 - 의존성이 보안 패치를 내면 pipeline이 diff를 가져와 변경 내용을 분석하고, 자사 코드가 영향을 받는지 판단해야 한다고 함 - 사람이 메일링 리스트를 읽고 티켓을 여는 흐름으로는 분 단위 공격 속도를 따라가기 어렵다는 주장임 - 의존성 스캔도 계속 돌아가야 함 - 전이 의존성까지 취약 버전 영향을 추적하고, 업그레이드 경로를 제안하는 수준이 필요하다고 봄 - 주간 스캔이 아니라 지속 스캔이 기본값이 돼야 한다는 이야기임 - 보안 패치를 내기 전에도 공격자처럼 테스트해야 함 - 글쓴이는 React 사례처럼 패치가 곧 공격 힌트가 될 수 있다고 봄 - 그래서 패치 공개 전에 인공지능으로 우회 가능성, 회귀 테스트, 동일 패턴의 다른 위치를 먼저 확인해야 한다고 말함 --- ## 기술 맥락 - 이 글에서 가장 중요한 선택은 공개 유예 기간을 길게 잡는 대신, 치명적 취약점을 즉시 대응 체계로 옮기자는 거예요. 예전에는 시간이 방어자 편이라고 봤지만, 이제는 같은 시간 동안 공격자도 대규모 언어 모델로 분석을 돌리거든요. - 패치 diff가 위험 신호가 되는 이유는 코드가 무엇을 고쳤는지 그대로 보여주기 때문이에요. 사람이 보면 시간이 걸리던 분석도 모델에게 맡기면 취약한 경로, 입력 조건, 개념 증명 코드 초안까지 빠르게 나올 수 있어요. - 그래서 보안팀의 자동화 위치가 중요해져요. 배포 뒤에 스캔하는 게 아니라 pull request, 의존성 업데이트, upstream 패치 감지 시점에 바로 분석해야 공격자와 같은 속도로 움직일 수 있거든요. - 운영팀 입장에서는 월간 패치 사이클이 편하지만, 커널이나 프레임워크의 치명적 취약점은 그 사이클을 기다려주지 않아요. 특히 공개 익스플로잇이 있는 이슈는 변경 관리 절차보다 침해 대응 절차에 가깝게 다루는 게 현실적이에요. - 이 주장은 모든 버그를 무조건 즉시 배포하자는 말과는 달라요. 글에서 겨냥하는 건 루트 권한 상승, 원격 코드 실행, 결제 우회처럼 영향이 큰 치명적 이슈이고, 이런 경우에는 느린 triage 자체가 리스크가 된다는 얘기예요. ## 핵심 포인트 - 대규모 언어 모델 덕분에 여러 연구자가 같은 취약점에 거의 동시에 도달하는 일이 늘고 있음 - 패치 diff를 읽고 동작하는 익스플로잇을 만드는 시간이 며칠·몇 주에서 분 단위로 줄었다는 사례가 제시됨 - Copy Fail과 Dirty Frag 같은 리눅스 커널 취약점은 공개 직후 실제 공격과 연결됐음 - 글쓴이는 치명적 취약점을 모두 최우선 등급으로 취급하고 보안 대응을 실시간 자동화해야 한다고 주장함 ## 인사이트 이 글의 핵심은 “공개까지 며칠 남았나”가 아니라 “공격자가 이미 같은 버그를 알고 있다고 가정하라”는 관점 전환이야. 한국 개발팀도 월간 패치, 스프린트 단위 보안 triage, 수동 의존성 확인에 기대고 있다면 이 논쟁을 그냥 해외 보안판 이야기로 넘기기 어렵다.