보안 취약점 90일 공개 정책의 한계와 새로운 대안

[!IMPORTANT] 분야: IT/AI/Security
한 줄 요약: 전통적인 90일 보안 취약점 공개 정책의 실효성 상실 원인을 분석하고, 현대적인 취약점 관리(VDP) 및 협력적 대응 전략을 제시합니다.

핵심 요약 (Key Takeaways)

• 고정된 마감 기한의 한계: 90일이라는 일률적인 기간은 현대의 복잡한 클라우드 인프라와 상호 의존적인 소프트웨어 공급망 패치 속도를 따라잡지 못하고 있습니다.
• 협력적 공개(CVD)로의 전환: 일방적인 통보와 공개보다는 벤더와 제보자 간의 투명한 소통을 기반으로 한 협력적 보안 취약점 공개(Coordinated Vulnerability Disclosure)가 중요해지고 있습니다.
• 위험 기반 우선순위 산정: 모든 취약점에 동일한 기한을 부여하기보다, 실제 악용 가능성과 비즈니스 영향을 고려한 위험 기반 대응 체계로 진화해야 합니다.

상세 분석 및 가이드

1. 90일 공개 정책의 유산과 붕괴 배경

보안 업계에서 ‘90일 정책’은 2014년 Google Project Zero가 도입하며 대중화되었습니다. 보안 연구자가 발견한 취약점을 벤더에게 알린 뒤, 패치 제작을 위해 90일의 유예 기간을 주고 그 이후에는 패치 여부와 상관없이 정보를 공개하는 방식입니다. 초기에는 벤더들이 보안 패치를 차일피일 미루는 관행을 타파하는 데 큰 공을 세웠습니다.

그러나 현재 이 정책은 여러 도전에 직면해 있습니다.

• 공급망의 복잡성: 현대 소프트웨어는 수백 개의 오픈소스 라이브러리에 의존합니다. 단일 소프트웨어의 취약점이 발견되어도, 이를 활용하는 하위 종속성 시스템까지 모두 패치하는 데는 90일이 턱없이 부족할 수 있습니다.
• 클라우드와 SaaS의 부상: 온프레미스 소프트웨어와 달리 클라우드 환경에서는 패치 한 번으로 수백만 사용자에게 영향이 가며, 단순 패치가 아닌 인프라 전체의 가용성을 고려해야 합니다.
• 위협의 가속화: AI를 활용한 취약점 스캐닝 기술이 발전하면서, 취약점 정보가 공개되는 즉시 자동화된 공격 도구가 제작되는 ‘Zero-day to One-day’ 전환 시간이 급격히 짧아졌습니다.

2. 현대적 보안 관리를 위한 GitHub 키워드 및 도구

전통적인 정책의 대안을 찾기 위해 보안 담당자들은 GitHub의 오픈소스 생태계와 표준화된 프레임워크를 적극 활용해야 합니다.

• GitHub 검색 키워드:
  • GitHub Security Advisories (GHSA): GitHub에서 제공하는 공식 취약점 데이터베이스로, 오픈소스 프로젝트의 보안 공지를 실시간으로 추적할 수 있습니다.
  • Vulnerability Disclosure Policy (VDP): 기업이 외부 제보자와 소통하는 표준 가이드라인을 검색할 때 유용합니다.
  • Coordinated Vulnerability Disclosure (CVD): 협력적 공개 모델의 모범 사례와 프레임워크를 찾을 수 있습니다.
  • EPSS (Exploit Prediction Scoring System): CVSS 점수의 한계를 보완하여 실제 악용 가능성을 수치화하는 최신 도구입니다.

3. 핵심 기능 및 실무 활용 방안 (Use Cases)

단순히 날짜를 세는 것보다 더 중요한 것은 ‘어떻게(How)’ 대응하느냐입니다.

• SBOM(Software Bill of Materials) 도입: 본인이 운영하는 서비스가 어떤 오픈소스에 의존하는지 명확히 파악하십시오. syft나 grype 같은 도구를 활용해 빌드 시점에 SBOM을 생성하고 취약점을 스캔하는 파이프라인을 구축해야 합니다.
• 위험 기반 패치 관리: 모든 취약점을 90일 안에 고칠 수 없다면, EPSS 점수를 확인하십시오. 취약점의 기술적 심각도(CVSS)는 높더라도 실제 공격에 사용될 확률(EPSS)이 낮다면 패치 우선순위를 조정할 수 있습니다.
• GitHub Security Features 활용:
  • Dependabot: 종속성 패치를 자동화하여 취약한 버전을 즉시 탐지하고 Pull Request를 생성합니다.
  • CodeQL: 정적 분석 도구를 사용하여 코드 작성 단계에서 보안 결함을 조기에 발견(Shift-left)하십시오.

4. 기대 효과

유연한 취약점 공개 정책으로 전환할 경우 다음과 같은 효과를 기대할 수 있습니다.

1. 벤더-연구자 신뢰 회복: 과도한 압박 대신 실질적인 패치 완료를 목표로 소통함으로써 생태계 전체의 안전성이 강화됩니다.
2. 리소스 최적화: 중요도가 낮은 취약점에 매달리기보다, 비즈니스에 치명적인 영향을 줄 수 있는 핵심 보안 결함에 인력을 집중 투입할 수 있습니다.
3. 대응 속도 향상: 자동화 도구와 연계된 현대적 정책은 수동적인 90일 관리보다 훨씬 빠른 위협 제거가 가능합니다.

실천 제언 (Actionable Recommendations)

1. 보안 취약점 공개 정책(VDP) 재정립 기업 홈페이지나 GitHub 저장소에 SECURITY.md 파일을 생성하십시오. 단순히 “90일 뒤 공개”라고 명시하기보다, 취약점의 유형과 심각도에 따라 대응 일정을 유연하게 조정할 수 있는 조항을 포함하십시오. 벤더와 제보자가 합의할 경우 기간을 연장하거나, 반대로 시급한 경우 즉시 공개할 수 있는 체계를 갖추어야 합니다.

2. 자동화된 탐지 및 패치 워크플로우 구축 사람의 판단에만 의존하는 보안은 한계가 있습니다. GitHub의 Actions와 연계된 보안 스캐닝 도구를 CI/CD 파이프라인에 통합하십시오. 특히 오픈소스 의존성 취약점은 Dependabot이나 Snyk 같은 도구를 통해 발견 즉시 알림을 받고 자동 패치 제안을 받도록 설정하는 것이 필수적입니다.

3. 데이터 중심의 우선순위 결정 CVSS 점수(심각도) 하나만 보지 마십시오. 해당 취약점이 우리 서비스의 외부 노출 영역(Attack Surface)에 있는지, 그리고 실제로 악용 사례가 보고되었는지를 종합적으로 판단해야 합니다. GitHub 상위 랭크의 보안 도구들이 제공하는 위협 인텔리전스 데이터를 의사결정에 적극 반영하십시오.

전통적인 90일 정책의 시대는 저물고 있습니다. 이제는 ‘기간’이 아닌 ‘리스크’와 ‘협력’을 중심으로 보안 거버넌스를 다시 설계해야 할 때입니다.