N4C SAGO: N-Day 취약점 공개 데이터베이스 출시와 소개
SAGO: N-DAY OPEN DATABASE 소개
안녕하세요, TeamH4C 리드 김주한 입니다.
SAGO는 공개된 취약점을 역분석하여 취약점의 Root-Cause 분석부터 재현 가능한 PoC, 그리고 Exploit Code까지 하나의 완성된 상세 1-day 보고서로 제공하는 공개 데이터베이스 입니다. TeamH4C 내부 N-Day 연구팀인 N4C에서 heegong님이 리드하고 계십니다.
상세한 1-Day 분석 정보의 공개는 여러가지 우려를 동반할 수 있음을 알고 있습니다.
이에 우리가 왜 이 길을 선택했는지 그리고 우리의 공개가 어떠한 원칙과 책임감 위에서 작동하는지 명확히 밝히고자 합니다.
SAGO의 소개는 위의 짧은 소개로 일단락하고 자세히는 후술하겠습니다.
SAGO 접속 링크는 본문 끝에서 제공합니다.
1. 서론: 프로젝트의 위험성에 대해
이 프로젝트를 공개하며 가장 먼저 답해야 할 질문이 무엇인지 알고 있습니다.
“Exploit Code의 공개가 오히려 공격을 돕는 것은 아닌가?”
단, 위의 질문은 하나의 대전제를 깔고 있습니다. 누군가 공개하기 전까지는 그 취약점이 안전하게 감춰져 있었다는 전제입니다. 하지만 당연히도 그 전제는 사실이 아닙니다.
벤더가 배포하는 패치 업데이트 그 자체가 수정 전 버전과 나란히 놓이는 순간, 무엇이 어디서 왜 깨졌는지를 상당한 정밀도로 복원할 수 있습니다. 게다가 이 속도는 LLM의 등장으로 기하급수적으로 빨라졌습니다.
무엇보다 매일 수많은 CVE가 쏟아지지만, 대다수의 보안 담당자와 연구자들은 단 몇 줄의 불친절한 Advisory 문구와 파편화된 정보에 의존해 방어선을 구축해야 합니다.
그사이 악의적인 공격자들과 블랙마켓 해커들은 취약점의 무기화를 이미 끝마친 상태입니다.
우리는 이 치명적인 능력의 비대칭성을 좁히고자 합니다.
그리고 한 가지를 미리 밝혀둡니다. 이것이 양날의 검이라는 점을 알고 있습니다.
그래서 PoC와 Exploit 공개 시점을 분리헸습니다.
또한, 우리가 공개할 PoC는 단순 취약점 증명이며 크래쉬 발생 수준입니다.
Exploit Code는 cmd, calc를 실행하는 수준에 그치게 제한할 것이며 90일의 유예를 두었고, 무기화 구성요소는 완전히 배제했습니다.
이후 소개할 공개 정책은 이 위험을 부정한 결과가 아니라 인정한 결과물입니다.
양날의 검이지만 한 쪽 면은 최대한 무디게 만들고자 했습니다.
2. 공개 이유1: 침묵은 취약점을 제거하지 않습니다.
2년에서 13시간.
이 말도 안 되는 숫자는 2018년부터 2026년 현재까지, 취약점이 익스플로잇까지 개발되는데에 소요된 평균 시간이며 이는 큰 폭으로 단축되고 있습니다. (Zeroday Clock)
Google Project Zero의 Mateusz Jurczyk는 2017년 글에서 이렇게 썼습니다.
"역분석이 가능한 소프트웨어에서 패치 이후의 취약점 악용 위험은 불가피하며, 생태계의 자연스러운 일부로 받아들여진다." 이 글의 결론에서 그는 자신이 수행한 디핑이 저수준 전문성이나 OS 내부 지식을 크게 요구하지 않는 의사코드 수준의 작업이었고 숙련되지 않은 공격자도 아주 적은 노력으로 세 건의 취약점을 식별하는 데 쓸 수 있었을 것이라고 덧붙이기도 했습니다 (Jurczyk).
같은 P0 팀의 Maddie Stone은 2020년에
"패치 디핑은 영속적인 취약점 공개 논쟁에서 자주 간과되는 부분이며, 취약점은 릴리스 노트에 발표될 때가 아니라 소프트웨어 업데이트가 배포되는 순간 이미 공개 지식이 된다는 것입니다."라고 했습니다. 그는 패치가 공개될 때 취약점 상세가 함께 공개되지 않으면 패치 디핑을 수행하는 연구자가 패치를 적용하는 방어자보다 더 많은 정보를 갖게 될 수 있다고 지적합니다 (Stone).
마지막으로 미국 CERT/CC는 자체 공개 정책에서 "업데이트본이 없다면 조용히 덮어두는 편이 낫지 않은가"라는 질문을 직접 다루면서, 취약점은 벤더가 수정할 기회를 갖기 전에도 일상적으로 발견·공개되고 있으며 그 공개에는 동작하는 익스플로잇이 포함되는 경우가 많다는 현실을 지적합니다 (CERT Coordination Center).
위 네 예시는 이 프로젝트 추진 이유의 사실적 토대입니다.
패치가 배포되는 순간 패치 정보는 이미 공개된 채로 있고, 그것을 읽어내는 일은 큰 전문성을 요구하지 않으며, 걸리는 시간은 급속도로 짧아지고 있습니다.
악의적 공격자는 우리가 아니어도 이미 도달해 있습니다. 그들은 패치를 기다리지도 않습니다(Project Zero).
우리가 패치 후 90일에 공개하는 분석이 그들에게 새로 주는 것은 거의 없습니다. 반면 그 분석이 없으면 아무것도 할 수 없는 쪽은 분명히 존재합니다.
오펜시브 해킹 능력이 뛰어난 사람들이 기업의 개발자나 담당자로 취업하는 경우는 극히 드물 것이기 때문입니다.
오픈소스라면 커밋을 읽으면 되지만, closed-sourced 바이너리라면 취약 버전과 패치 버전을 모두 확보해 디핑해야 합니다.
이 역량을 갖춘 조직은 공격 진영에 압도적으로 편중되어 있습니다. 방어 진영에서 이 역량을 보유한 곳은 대형 보안기업과 극소수 대기업 SOC뿐입니다. 국내 중견 제조업체의 2인 보안팀, 지방 의료기관의 겸직 전산 담당자, 지자체 정보화 부서 등에선 사실상 할 수 없습니다.
여기서 장벽은 접근이 아니라 능력입니다. 그리고 공개하지 않는다는 선택은 능력을 갖춘 쪽에게 아무것도 감추지 못합니다. 오직 능력이 없는 쪽에만 감춥니다.
이 양극화는 LLM의 등장으로 한 층 더 심각해졌습니다.
공격자가 패치로부터 익스플로잇을 만드는 데 걸리는 시간은 수 시간 단위로 짧아졌습니다. Mandiant가 수행한 한 분석에서 n-day의 12%는 패치 하루 안에, 29%는 일주일 안에 악용됐습니다. 반면 기업이 패치를 실제로 적용하는 데 걸리는 시간은 주에서 달 단위입니다 (Charrier and Weiner).
위 사이의 구간이 오늘날 침해사고의 상당 부분이 발생하는 지점입니다.
이 구간에서 방어자가 가장 필요로 하는 것은 익스플로잇보다는 판단 근거입니다.
벤더 권고문은 종종 이렇게 씁니다. "특정 조건에서 원격 코드 실행이 가능할 수 있음." 이 문장으로는 아무것도 결정할 수 없습니다. 우리 환경이 그 "특정 조건"에 해당하는지, 지금 당장 야간 긴급 패치를 해야 하는지, 다음 정기 점검까지 미뤄도 되는지 판단이 어렵습니다.
그래서 SAGO의 Root-Cause Analysis는 이 불친절한 Advisory 문장을 예를 들어,
"인증 우회 후 특정 파라미터가 활성화된 구성에서만 성립하며, 해당 설정은 기본값이 아니다"로 바꿉니다.
이때 방어자는 비로소 우선순위가 생기며 고비용 무차별 전수 패치가 표적 대응으로 바뀔 수 있는 기회를 얻습니다.
한 가지 중요한 사실을 더 짚자면, 비공개가 소멸을 의미하지 않습니다.
공개되지 않은 익스플로잇은 사라지는 것이 아니라 국가 지원 조직, 익스플로잇 브로커, 초기 접근 판매자, 소수의 사설 연구팀에 독점됩니다. 침묵이 만들어내는 것은 취약점의 부재가 아니라 소유의 편중입니다. 공개 연구가 그 독점을 완전히 해체하지는 못하지만, 최소한 방어자와 교육자, 연구자에게도 같은 기술을 검증하고 대응할 기반을 제공합니다.
패치 후에도 우회가 가능했던 사례, 벤더가 같은 취약점을 여러 번 수정했던 사례는 드물지 않습니다.
이미 공격자들은 패치가 공개된 순간부터 디핑 그리고 AI라는 증폭기로 익스플로잇 무기들을 찍어내고 있습니다.
이때 검증 수단을 방어자에게 주지 않는 것은, 방어자에게 계측기 없이 방어하라고 요구하는 것과 같습니다.
그래서 저희는 질문을 아래와 같이 바꿨습니다.
"취약점 지도를 읽을 수 있는 쪽에만 계속 맡겨둘 것인가?"
SAGO는 이 질문에 답하기 위해 만들어졌습니다.
3. 공개 이유2: LLM은 공격자만 빠르게 만들지 않았습니다.
앞서 저는 패치에서 취약점을 복원하는 속도가 LLM의 등장으로 기하급수적으로 빨라졌다고 썼습니다.
그것은 절반만 한 이야기인데요, LLM은 방어자도 빠르게 만들고 있습니다.
그리고 이 프로젝트를 실제로 시작하게 만든 것은 후자입니다.
방어 측에서 실제로 벌어진 일을 한 번 보겠습니다.
AI를 응용 도구로써 수용하고, AI 역량 내재화를 위해 세계는 이미 문을 열었습니다.
2025년 8월, 미국 조달청(GSA)은 3주 사이에 세 건의 정부 전체 계약을 연달아 체결했습니다(GSA). OpenAI의 ChatGPT Enterprise를 기관당 연 1달러에, Anthropic의 Claude를 행정·입법·사법 3부 전체에 1달러에, Google의 Gemini for Government를 기관당 47센트에 공급하는 계약입니다.
민간도 마찬가지 입니다. JPMorgan Chase는 사내 LLM Suite를 20만 명 이상에게 배포했고, Goldman Sachs는 1만 명 파일럿을 거쳐 2025년 약 4만 6천 명 전 직원에게 AI 어시스턴트를 열었습니다.
한국도 예외가 아닙니다. 오히려 제도가 앞서 움직이고 있습니다.
-2026년 4월*, 금융위원회와 금융감독원이 전자금융감독규정 시행세칙을 개정해, 금융회사가 별도 심사 없이 내부 업무망에서 SaaS를 이용할 수 있도록 했습니다.
-2026년 5~6월, 망분리 긴급 완화조치가 시행되고 AI 보안 테스트가 시작됐습니다.
-2026년 5월, 금융위원회가 5대 금융지주 회장단을 소집했습니다. 이 간담회는 앤트로픽의 클로드 미토스를 비롯한 최상위 프론티어 AI가 촉발할 수 있는 보안 침해 위협에 대한 위기의식을 공유하기 위해 마련된 자리였습니다.
-2026년 7월, 금융보안원 주최 행사에서 위원장은 이렇게 말했습니다.*
"기존처럼 망을 닫고, 접속을 제한하는 사후 대응으로는 진화하는 AI 공격을 따라갈 수 없다. 'AI 공격은 AI로 방어하는' 체계가 마련되어야 한다(FSC)."
세계 탑티어 보안 회사인 티오리(Theori)의 AI 취약점 탐지 솔루션 Xint가 삼성, 포스코, 우리금융그룹 등 세계적 대기업 및 1금융권 은행에 도입 됐습니다.
방어자 손에도 쥐어진 AI는 모델에 따라 자체 성능으로 취약점을 찾을 수도 있지만 그렇지 못한 대부분의 경우에는 레퍼런스 자료가 큰 역할을 하게될 수밖에 없습니다.
실제로 CTF에서도 1-day 문제가 출제될 때 온라인 검색으로 1-day 정보를 찾아 푸는 경우들이 종종 있습니다.
4. N4C가 공개하는 것
SAGO는 이미 벤더 패치가 배포된 CVE만을 대상으로 하는 공개 데이터베이스입니다. 미공개 취약점(0-day)은 다루지 않습니다.
즉, 패치가 없는 취약점은 다루지 않습니다.
SAGO 보고서는 한글과 영어 버전으로 제공됩니다.
각 보고서는 SG-2026-0001과 같은 ID를 기준으로 관리됩니다.
보고서에는 취약점 종류, 심각도, 공개 여부, PoC 존재 여부, exploit 존재 여부, 태그, 공개 정보, 분석 본문 등이 함께 기록됩니다.
현재 SAGO에서 취약점 종류는 다음 범위로 관리합니다.
- RCE
- LPE
- Info leak
- DOS
- Escape
SAGO에서는 PoC와 Exploit을 구분해서 관리합니다.
PoC는 취약점의 존재와 재현 가능성을 확인하기 위한 코드입니다. 따라서 SAGO에서는 공개 보고서에 포함되는 PoC를 보고서 공개 시점에 함께 공개하는 것을 원칙으로 합니다.
이는 방어자와 연구자가 취약점의 조건과 영향을 더 명확히 이해할 수 있도록 하기 위함입니다.
반면 Exploit은 실제 공격 가능성을 더 직접적으로 높일 수 있습니다. 따라서 N4C는 Exploit 코드에 대해 공개일 기준 90일 뒤 공개하는 것을 원칙으로 합니다.
즉 SAGO의 공개 정책은 다음과 같습니다.
PoC: 보고서 공개 시 공개
Exploit: 공개일 기준 90일 뒤 공개
Exploit Code 공개 여부
SAGO는 Exploit 공개 여부를 결정할 때 단순히 취약점 유형이나 패치 후 경과 기간만을 기준으로 하지 않습니다.
공개 전 내부 검토를 통해 실제 악용 가능성과 예상 피해 범위를 평가하며 위험성이 높다고 판단되는 경우 Exploit의 공개를 제한하거나 보류합니다.
주요 검토 기준은 다음과 같습니다.
1. 공격 전제조건: 사전 인증, 로컬 계정, 특정 권한, 네트워크 접근 위치 등 공격에 필요한 조건2. 사용자 상호작용 여부: 파일 실행, 링크 클릭, 문서 열기 등 피해자의 추가 행동이 필요한지 여부3. 공격 복잡도 및 재현 용이성: 공개된 Exploit을 별도의 분석이나 수정 없이 쉽게 사용할 수 있는지 여부4. 원격 악용 가능성: 인터넷 또는 일반 네트워크 환경에서 직접 공격 가능한지 여부5. 영향 범위: 기본 설정에서 영향을 받는 제품 및 시스템의 규모와 보급 정도6. 피해 수준: 원격 코드 실행, 권한 상승, 격리 환경 탈출, 서비스 중단, 정보 유출 등 예상 가능한 피해 수준7. 공격 안정성: 높은 성공률로 반복적인 악용이 가능한지 여부8. 추가 취약점과의 결합 가능성: 다른 취약점과 연계될 경우 공격 체인의 핵심 요소로 활용될 가능성9. 패치 적용 가능성: 지원되는 주요 제품과 버전에 보안 업데이트가 실제로 제공되고 있는지 여부10. 실제 악용 정황: 동일 또는 유사 취약점이 실제 공격에 활용되고 있거나 적극적으로 악용되고 있다는 정황이 존재하는지 여부
위 검토 기준에 결합하여 다음과 같은 내부 관리 규칙 하에 최종 공개 됩니다.
1. 2인 이상 공개 승인제: 최소 2명 이상의 내부 리뷰를 통과해야 게시
2. 단계적 공개: 처음에는 원인 분석과 제한된 PoC만 공개하고, exploit은 별도 유예기간 이후 다시 검토해서 공개
3. 긴급 비공개 전환 기능: 공개 후 실제 악용 정황, 패치 철회, 새로운 영향 범위 등이 확인되면 즉시 exploit 다운로드를 중단할 수 있도록 함
4. 외부 제보 절차: 실제 악용 사례나 예상치 못한 위험성을 발견한 제3자가 빠르게 신고할 수 있도록 abuse/security contact를 명확히 둠
특히 별도의 인증이나 사용자 상호작용 없이 원격에서 직접 악용할 수 있는 RCE, 보안 경계 또는 격리 환경을 직접 우회할 수 있는 Escape, 그리고 외부에서 반복적으로 서비스 장애를 유발할 수 있는 Remote DoS는 높은 위험성을 가진 것으로 간주합니다.
이러한 취약점은 패치 공개 후 정해진 유예 기간이 경과했더라도 Exploit을 공개하지 않을 수 있습니다.
필요한 경우 Exploit 전체 대신 취약점의 원인, 패치 분석, 제한된 재현 정보 등 방어 및 연구에 필요한 범위의 정보만 공개할 수 있습니다.
SAGO는 Exploit 공개가 보안 연구와 방어에 제공하는 기술적 가치가 예상되는 악용 위험보다 충분히 크다고 판단되는 경우에만 공개를 진행합니다.
4.1 90일이 향하는 곳
Google Project Zero의 90일이 존재하는 이유는 벤더를 압박하기 위해서 입니다(Project Zero).
공표된 데드라인이 없으면 아무도 서두르지 않습니다.
SAGO의 90일은 벤더가 아니라 패치 적용 주체를 향합니다.
"90일 뒤 Exploit이 공개된다"는 사실 자체만으로는 어떤 Advisory도 만들어내지 못하는 종류의 데드라인이기에 그 90일 동안 방어에 필요한 Root-Cause Analysis와 PoC를 선공개하는 것입니다.
P0는 조율 공개 모델을 10년 넘게 쓴 끝에 많은 수정이 6개월 이상 걸리고 일부는 아예 수정되지 않는 현실을 확인했고, 마감일이 올바른 인센티브 균형을 만든다고 판단했습니다. 한 벤더는 응답 시간이 40% 빨라졌고, 다른 벤더는 보안 업데이트 주기를 두 배로 늘렸습니다(Project Zero).
그리고 구글의, 벤더 패치 배포 90일 이후 별도로 적용되는 30일은 압박 대상이 다릅니다. P0는 이 구간에서 생태계의 패치 적용률을 높이는데에 인센티브가 되기를 바란다고 밝힙니다(Project Zero).
SAGO에 대응되는 구간이 바로 이 30일입니다. 우리는 같은 자리에 3배인 90일을 둡니다.
이 기준은 구글 P0, 미국 CERT/CC 등 원데이 보고서를 공개하는 실제 사례와 정책들로부터 상당 부분 참고하였습니다.
5. 마치며
처음에는 보고서 수가 많지 않을 수 있습니다. 하지만 중요한 것은 양보다 질 그리고 실제로 작동하는 시스템 입니다.
취약점 정보를 같은 기준으로 기록하고, 시간이 지나도 다시 찾을 수 있게 만들고, 공개 가능한 정보와 내부적으로 더 검토해야 하는 정보를 구분하는 것이 SAGO의 목적입니다.
앞으로 SAGO에는 N4C가 분석한 원데이 보고서들이 순차적으로 올라갈 예정입니다.
저희는 Exploit 공개가 절대적으로 안전하다는 주장을 하는 것이 아닙니다.
위험을 인정하면서도, 통제된 공개가 공격 기술의 영구적인 비공개와 소수 집단의 독점보다 더 큰 방어적 가치를 만들 수 있다는 주장입니다.
다만 우리도 틀릴 수 있습니다. 정책의 일부분이 잘못 설계되었다면 고칠 것이고
SAGO가 미치는 영향에 대해 지속적으로 모니터링하겠습니다.
버그나 이상 동작을 발견하면 아래 이메일로 제보해 주세요.
h4cish4c@gmail.com
우리는 SAGO가 공격자보다 방어자, 학습자와 선의의 연구자들에게 더 유용한 데이터베이스가 되기를 바랍니다.
SAGO: https://sago.h4c.team
TeamH4C N4C
6. 부록: 예상 질문들과 답변
여기까지가 우리의 설계이지만 그럼에도 남는 반론들이 있고, 그 반론들은 정당하기에 하나씩 답하겠습니다.
6.1 "쉽게 공격에 쓰일 수 있으므로 공개하면 안 된다"
이 원칙을 일관되게 적용하면 어디까지 가는지 먼저 보겠습니다.
Metasploit은 수천 개의 동작하는 익스플로잇 모듈을 담고 있습니다. 나스닥 상장사가 유지보수하고, 상용 버전까지 판매합니다. 심지어 Kali Linux는 공격용 도구들을 묶어서 배포합니다. OSCP를 비롯한 자격증은 이 도구들의 숙련도를 인증서로 발급합니다.
게다가 한국에서 이것들이 정보통신망법상으로 문제된 적은 없습니다.
세계의 보안 업계가 Metasploit을 일률적으로 금지하지 않는 이유는 위험이 없어서가 아닙니다.
공격자가 사용할 수 있다는 위험을 인정하면서도, 다음의 방어 효용을 함께 평가하기 때문입니다.
1. 스캐너가 보고한 취약점의 실제 악용 가능성 검증2. 패치 우선순위 결정3. 침투테스트와 레드팀 훈련4. 보안통제와 탐지체계 검증5. 취약점의 현실적인 영향 확인6. 보안 연구의 재현성과 표준화
공격 목적 사용 가능성을 이유로 공개를 전면 부정하려면, Metasploit, IDA, Ghidra, pwntools, Fuzzer, Github, Kali Linux까지 동일한 기준으로 부정해야 합니다. 보안 생태계가 실제로 채택한 원칙과 문화는 금지가 아니라 '책임 있는 공개'와 '사용 통제'입니다.
물론 이렇게 반문할 수 있습니다. Metasploit 모듈은 이미 공개된 취약점을 모아놓은 것이고, SAGO는 최초 공개자가 될 수 있다고.
절반은 맞는 지적입니다. 그리고 이 지적을 받아들이는 순간, 논쟁의 성격이 바뀝니다.
더 이상 '익스플로잇을 공개해도 되는가'의 문제가 아니라 '언제, 어떤 순서로 공개하는가'의 문제가 됩니다.
Metasploit 논거는 SAGO가 괜찮다는 것을 증명하지 않습니다. 논쟁이 정당성이 아니라 타이밍의 문제라는 것을 증명합니다.
그리고 타이밍은 우리가 이미 4장에서 자체 공개 정책으로 답한 부분입니다.
6.2 "공개하면 공격자가 늘어난다"
이 지적은 사실입니다. 그런데 계산에서 한쪽이 빠져 있습니다.
공개하면 방어 가능한 사람도 늘어납니다.
공개의 영향을 정확히 평가하려면 양쪽을 함께 계산해야 합니다. 질문은 이렇게 세워져야 합니다.
SAGO가 새롭게 증가시키는 공격 역량과 새롭게 증가시키는 방어 역량 중 어느 쪽이 더 크며, 공개 절차를 통해 그 차이를 어떻게 방어자에게 유리하게 만들 것인가?
공격자의 한계편익만 계산하고 방어자의 한계편익을 누락한 논증은 위험을 지적하는 데는 성공하지만 공개의 순효과를 입증하지는 못합니다.
그리고 늘어나는 공격자의 구성도 함께 보아야 합니다. 공개로 새로 추가되는 사람은 정의상 스스로 익스플로잇을 만들 수 없던 사람입니다. 국가 지원 조직과 랜섬웨어 조직은 이 집단에 추가되지 않습니다. 그들은 이미 갖고 있거나, 없어도 만듭니다.
여기에 한 가지 비대칭이 더 있습니다. 공개된 익스플로잇을 쓰는 공격자는 ASM 등의 공개된 탐지 규칙에 걸립니다. 반면 자체 개발한 정교한 공격자는 어떤 시그니처에도 맞지 않으며 그 사람은 공개와 무관하게 존재했습니다.
두 날은 같은 대상을 향하지 않습니다.
6.3 "90일이 지나도 패치하지 못한 곳은 어떻게 되는가"
여기서는 위험을 부정하지 않겠습니다.
SAGO 공개 이후, 90일 동안 패치하지 않은 일부 조직이 공격받을 가능성은 있습니다.
다만 이 사실로부터 다음 결론이 자동으로 나오지는 않습니다.
"미패치 시스템이 하나라도 남아 있는 한 취약점은 영구적으로 공개해서는 안 된다."
이 기준을 적용하면 공개 가능한 시점은 사실상 영원히 오지 않습니다.
취약점 공개 정책의 목적은 위험을 0으로 만드는 것이 아닙니다. 그것은 불가능합니다. 목적은 책임을 합리적으로 배분하는 것입니다.
즉 책임 있는 공개란 무위험 공개가 아니라, 방어자가 실질적으로 대응할 수 있는 선행 기회를 보장하는 절차입니다.
저희는 90일 이후 공개자에게 아무 책임이 없다는 과도한 주장을 하는 것이 아닙니다. 다만 반대로 미패치 조직이 존재한다는 이유만으로 공개자가 영구히 연구 결과를 봉인해야 한다는 주장 역시 과도합니다.
그리고 한 가지는 분명합니다. 그 조직들은 SAGO가 없었다면 갖지 못했을 90일간의 검증된 정보를 무료로 받았습니다.
한 가지 사실을 더 짚겠습니다. 완성도 높은 1-day 분석을 공개하는 블로그나 아카이브는 글로벌에 이미 많습니다.
게다가 고가에 판매하는 회사들이 국내외에 존재합니다. 오펜시브 보안을 공부해보신 분들이라면 대부분 아는 사실입니다.
여기에서 살펴볼 것은, 같은 분석이 유료로 유통되면 인텔리전스 사업이고, 무료로 공개되면 무책임한 행위가 되는가? 입니다.
취약점을 악용 가능하게 만드는 것은 가격표가 아니라 내용입니다. 유료 보고서에 담긴 익스플로잇이 무료 보고서에 담긴 것보다 덜 위험하지 않습니다.
유료 판매가 정당하다면, 우리에게 적용될 기준도 "공개해서는 안 된다"라기 보다는 "어떤 조건에서 공개하는가"여야 합니다. 그리고 그 조건에서 우리는 더 보수적입니다.
우리는 방어자가 먼저 대응할 수 있는 RCA, PoC를 먼저 제공하여 90일의 유예를 두고, 완성형 무기화를 배제하며, 공개 정책을 공표하고 그 기록을 남깁니다.
유료 판매는 구매자에게 이러한 보안 조치를 적용하는지 알 수 없습니다.
6.4 정리하면
Exploit의 공격 활용 가능성은 공개를 금지할 충분조건이 아닙니다. 그렇다면 Metasploit을 포함한 현대 보안 검증 생태계 자체가 성립할 수 없습니다.
핵심은 공개 여부가 아니라, 누가 먼저 대비할 수 있도록 어떤 순서와 수준으로, 어떤 안전한 정책 하에 관리하느냐입니다. SAGO는 방어자에게 Root Cause Analysis와, 제한적 PoC와 최소 90일의 선행 대응 기간을 제공한 뒤 Exploit을 후속 공개함으로써, 공격 역량의 확산보다 방어 역량의 확산이 먼저 발생하도록 설계합니다.
또한 위험성을 면밀하게 이중으로 검토해 Exploit 공개 여부를 결정합니다.
이것은 Exploit 공개가 무조건적으로 안전하다는 주장이 아닙니다.
책임은 도구가 아니라 행위자에게 있기에, 위험을 일부 인정하면서도, 통제된 공개가 영구 비공개보다 더 큰 방어적 가치를 만들 수 있다는 주장입니다.
6.5 SAGO의 의미
SAGO라는 이름에는 두 가지 의미를 담았습니다.
하나는 "사고가 났다"라고 할 때의 사고입니다. 보안에서 취약점은 단순한 코드 결함으로 끝나지 않습니다. 패치가 나오고, PoC가 공개되고, exploit이 등장하고, 실제 공격으로 이어질 수 있는 하나의 사건이 됩니다. SAGO는 이런 사건들을 흘려보내지 않고 기록하기 위한 공간입니다.
다른 하나는 "사고하다"라고 할 때의 사고입니다. 취약점 정보를 단순히 모으는 것에서 끝나는 것이 아니라, 왜 중요한지, 어떤 조건에서 재현되는지, 공개된 정보만으로 무엇을 판단할 수 있는지를 계속 생각하고 정리하겠다는 의미를 담고 있습니다.
즉 SAGO는 보안 사고를 기록하고, 그 사고에 대해 다시 사고하기 위한 플랫폼입니다.
감사합니다.
Works Cited
CERT Coordination Center. "Vulnerability Disclosure Policy." CERT Coordination Center, Carnegie Mellon University, certcc.github.io/certcc_disclosure_policy/. Accessed 3 Aug. 2026.
Charrier, Casey, and Robert Weiner. "How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends." Google Cloud Blog, Mandiant, 15 Oct. 2024, cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2023.
Collins, Georgia. "How JPMorgan Is Embedding AI into Employee Performance." AI Magazine, BizClik Media, 10 Nov. 2025, aimagazine.com/news/how-jpmorgan-is-embedding-ai-into-employee-performance.
"From Vulnerability to Exploitation." Zeroday Clock, zerodayclock.com. Accessed 3 Aug. 2026.
"Full-Scale AI Transformation in the Financial Sector: Easing Network Separation Regulations to Broaden Innovation and Strengthen Security — Roundtable on Financial Sector Security Threats Related to High-Performance AI." Financial Services Commission of Korea, 26 May 2026, fsc.go.kr/po010101/86972.
Google Project Zero. "Vulnerability Disclosure Policy." Project Zero, Google, projectzero.google/vulnerability-disclosure-policy.html. Accessed 3 Aug. 2026.
———. "Vulnerability Disclosure FAQ." Project Zero, Google, last updated 29 July 2025, projectzero.google/vulnerability-disclosure-faq.html.
"GSA, Google Announce Transformative 'Gemini for Government' OneGov Agreement." U.S. General Services Administration, 21 Aug. 2025, www.gsa.gov/about-gsa/newsroom/news-releases/gsa-google-announce-gemini-onegov-agreement-08212025.
"GSA Propels Government into AI Revolution with Addition of Leading Solutions to Multiple Award Schedules." U.S. General Services Administration, 5 Aug. 2025, www.gsa.gov/about-gsa/newsroom/news-releases/gsa-propels-government-into-ai-revolution-with-addition-of-leading-solutions-08052025.
Jurczyk, Mateusz. "Using Binary Diffing to Discover Windows Kernel Memory Disclosure Bugs." Project Zero, Google, 5 Oct. 2017, projectzero.google/2017/10/using-binary-diffing-to-discover.html.
Kang, Ryu-na. "Lee Eok-won: Full Lifting of Network Separation Rules for Financially Secure Firms." Yonhap News, 10 July 2026. Financial News, www.fnnews.com/news/202607100830241506.
Park, Mun-su. "Emergency Easing of Network Separation Rules for Mythos-Response AI: FSC Also Reviewing Full Lifting." Financial News, 24 May 2026, www.fnnews.com/news/202605241114438761.
Stone, Maddie. "TFW You-Get-Really-Excited-You-Patch-Diffed-a-0day-Used-in-the-Wild-but-Then-Find-Out-It-Is-the-Wrong-Vuln." Project Zero, Google, 2 Apr. 2020, projectzero.google/2020/04/tfw-you-get-really-excited-you-patch.html.