취약점 공개 기한 90일→30일, 구글 2028년까지 단계 적용

취약점 신고 후 공개까지 걸리는 기한이 현재 90일에서 2028년 30일로 단계적으로 단축된다. 구글 보안 연구팀 프로젝트 제로(Project Zero)는 AI를 이용한 취약점 발견과 악용이 빨라졌다는 판단에 따라 공개 정책을 바꿨다.

프로젝트 제로는 13일 발표한 ‘Full X’ 정책에서 공급사에 취약점을 통보한 날부터 X일 뒤 기술 세부 내용을 공개한다고 밝혔다. X는 신고부터 공개까지의 일수를 뜻하며, 현재 기본 기한은 90일이다.

기한은 2027년 2월 2일 60일로 줄고, 2028년 1월 3일 30일로 단축될 예정이다. 따라서 지금부터 모든 취약점에 30일 기한이 적용되는 것은 아니다.

프로젝트 제로는 2021년부터 ‘90+30일’ 정책을 운영했다. 공급사에 최대 90일의 수정 기간을 준 뒤, 수정판이 이용자에게 배포될 시간을 확보하기 위해 30일을 더 기다리는 구조였다.

새 정책에서는 수정판 배포 뒤의 추가 대기 기간이 사라진다. ‘패치 격차’는 수정판이 나온 뒤 이용자가 관련 업데이트를 설치하기까지 걸리는 시간으로, 프로젝트 제로는 공급사가 수정과 배포 속도를 함께 높여야 한다고 설명했다.

프로젝트 제로는 대규모언어모델(LLM)이 공격자의 취약점 발견과 악용을 빠르게 만들었다고 밝혔다. 악의적인 공격자를 포함해 여러 주체가 같은 취약점을 먼저 발견할 가능성도 커졌다는 설명이다.

수정판을 분석해 취약점의 작동 방식을 역으로 알아내는 데 걸리는 시간도 줄었다. 프로젝트 제로는 공격자가 패치에서 결함 정보를 거의 즉시 파악할 수 있는 환경에서는 배포 뒤 30일을 기다리는 관행이 보안상 의미를 잃을 수 있다고 봤다.

취약점 신고 건수도 늘었다. 프로젝트 제로는 과거 한 해에 몇 건을 발견하던 일부 조사 대상에서 이제는 매주 여러 건을 찾고 있다고 밝혔다.

기존 정책은 취약점이 수정됐는지, 추가 유예 기간을 적용할지를 공급사와 협의해야 했다. 프로젝트 제로는 이런 협의 절차가 늘면서 정책을 계속 운영하기 어려워졌다고 설명했다.

정책 변경 과정에서 주요 공급사들은 기한을 갑자기 줄이면 수정되지 않은 취약점이 공개돼 이용자 위험이 커질 수 있다고 우려했다. 공급사가 수정 절차와 기술을 바꾸는 동안 공격자에게 취약점 정보가 먼저 공개될 수 있다는 지적이다.

공급사들은 짧은 기한이 심각도가 낮은 결함을 더 심각한 문제보다 먼저 처리하게 만들 수 있다는 우려도 제기했다. 현실적으로 기한을 지키기 어렵다고 판단한 공급사가 취약점 수정 시도 자체를 포기할 가능성도 언급됐다.

프로젝트 제로는 이런 의견을 반영해 기한을 한 번에 30일로 줄이지 않고 단계적으로 단축하기로 했다. 공급사에 대응 절차를 개선할 시간을 주면서도 수정 속도를 높이도록 유도하는 일정이라고 설명했다.

취약점 심각도는 새 정책의 공개 기한을 바꾸지 않는다. 프로젝트 제로는 추적기에 상당한 심각도와 입증된 보안 영향을 갖춘 취약점을 보고한다며, 심각도는 공격자가 결함을 발견할 가능성보다 이용자에게 미치는 피해 정도를 나타낸다고 밝혔다.

예정보다 일찍 공개할 수 있는 경우는 △실제 이용자를 대상으로 악용 중인 취약점 △제3자가 세부 내용을 이미 공개한 취약점 △공급사가 공개를 요청한 취약점이다. 실제 악용이 확인된 취약점은 구글의 앱 보안 공개 정책에 따라 7일 뒤 공개되며, 이미 공개된 취약점은 즉시 공개할 수 있다.

이와 별도로 공개가 광범위한 이용자 피해를 낳고 공개를 미루는 것이 피해 방지에 도움이 될 때는 드물게 예외를 둘 수 있다. 세부 공개 정책은 이런 예외를 공개 기록에 남기며, 지난 12년간 다섯 차례 허용했다고 밝혔다.

프로젝트 제로는 취약점이 수정됐는지 계속 추적하고 공급사와 소통할 방침이다. 다만 수정 완료 여부는 공개일을 정하는 기준으로 삼지 않으며, 신고된 취약점의 공급사·제품·신고일도 투명성 페이지에 공개할 예정이다.