--- title: "AI 때문에 흔들리는 취약점 공개 문화 두 가지" published: 2026-05-08T17:55:08.000Z canonical: https://jeff.news/article/2478 --- # AI 때문에 흔들리는 취약점 공개 문화 두 가지 AI가 취약점 분석 속도를 끌어올리면서 기존 보안 업계의 두 공개 문화가 동시에 압박을 받고 있다는 글이다. 몰래 고치는 방식도, 90일 엠바고를 두는 조정 공개도 예전만큼 안전하지 않다는 게 핵심이다. - AI가 취약점 공개 문화를 양쪽에서 동시에 흔들고 있음 - 하나는 보안 업계에서 흔한 조정 공개(Coordinated Disclosure) 문화임. 취약점을 찾으면 유지보수자에게 비공개로 알리고, 보통 90일 정도 고칠 시간을 준 뒤 공개하는 방식임 - 다른 하나는 리눅스 쪽에서 자주 보이는 ‘버그는 그냥 버그’ 문화임. 보안 이슈라고 크게 표시하지 않고 빠르게 고치면, 수많은 커밋 사이에 묻혀 공격자가 눈치채기 전에 패치가 퍼질 수 있다는 접근임 - 그런데 AI가 좋아지면서 ‘조용히 고치면 못 알아보겠지’가 점점 안 통하게 됨 - 보안 수정 커밋이 많아질수록 커밋을 뒤져보는 쪽의 신호 대 잡음비가 좋아짐. 예전엔 바늘 찾기였는데, 이제는 바늘이 꽤 자주 나오는 더미가 된 셈임 - 각 커밋을 AI에게 던져서 “이거 보안 패치 같아?”라고 묻는 비용도 계속 내려가고 있음 > [!IMPORTANT] > 글쓴이가 Gemini 3.1 Pro, ChatGPT-Thinking 5.5, Claude Opus 4.7에 특정 커밋을 줬더니 세 모델 모두 바로 보안 패치 성격을 알아봤다고 함. 엄밀한 벤치마크는 아니지만, 가능한 미래를 보여주는 데는 충분히 세다. - 긴 엠바고도 예전만큼 안전하지 않음 - 과거에는 누군가 취약점을 찾아서 90일 엠바고로 신고하면, 그 사이 다른 사람이 같은 버그를 발견할 확률이 상대적으로 낮았음 - 지금은 AI 보조 취약점 탐색 그룹이 많아지면서 그 가정이 깨지고 있음 - 실제 사례에서도 Kim이 ESP 취약점을 신고한 지 9시간 뒤 Kuan-Ting Chen이 독립적으로 같은 취약점을 신고했다고 함. 90일은커녕 반나절도 안 걸린 것 - 엠바고는 방어 시간을 벌어주는 장치이면서, 동시에 위험한 착각을 만들 수 있음 - “아직 비공개니까 급하지 않다”는 분위기가 생기면 패치와 배포가 늦어질 수 있음 - 게다가 정보를 아는 사람이 제한되면, 실제로 고칠 수 있는 사람과 검증할 수 있는 사람도 줄어듦 - 글쓴이의 결론은 긴 엠바고보다 아주 짧은 엠바고 쪽에 가까움 - AI가 공격자만 빠르게 만드는 건 아니고, 방어자도 패치 분석, 영향 범위 확인, 테스트 자동화에 AI를 쓸 수 있음 - 예전에는 너무 짧아서 의미 없던 엠바고 기간도, AI 보조 방어 체계에서는 실제로 쓸 만해질 수 있다는 얘기임 --- ## 기술 맥락 - 여기서 핵심은 취약점 공개 정책이 ‘정보가 퍼지는 속도’를 전제로 만들어졌다는 점이에요. 조정 공개는 공격자가 모르는 시간이 충분히 길다고 가정하고, 리눅스식 조용한 수정은 커밋 흐름이 너무 많아서 공격자가 못 찾을 거라고 기대하거든요. - AI가 바꾼 건 취약점 자체보다 탐색 비용이에요. 공개 diff, 커밋 메시지, 코드 변경 패턴만 보고도 보안 수정 냄새를 잡아내면, 유지보수자가 보안 라벨을 숨겨도 의미가 줄어들어요. - 그래서 앞으로 중요한 건 ‘얼마나 오래 숨길까’보다 ‘얼마나 빨리 고치고 배포할까’에 가까워져요. 방어팀도 AI로 패치 영향 분석, 회귀 테스트, 익스플로잇 가능성 검토를 빠르게 돌릴 수 있어야 짧은 엠바고가 현실적인 선택지가 돼요. ## 핵심 포인트 - 커밋만 보고 보안 패치인지 판별하는 일이 AI 덕분에 훨씬 쉬워지고 있음 - 90일 엠바고는 다른 AI 보조 연구자가 같은 취약점을 먼저 찾을 가능성 때문에 위험해질 수 있음 - 방어자도 AI를 쓰기 때문에 엠바고는 더 짧아지고 대응 속도는 더 빨라져야 한다는 주장 ## 인사이트 취약점 공개의 룰은 결국 ‘공격자가 언제 알게 되느냐’에 맞춰 설계됐는데, AI가 그 시계를 확 당겨버린 셈이다. 앞으로 보안 조직은 공개 정책보다 패치 속도와 검증 자동화에 더 많이 투자하게 될 가능성이 큼.