오픈AI, 오픈소스 취약점 고치는 ‘패치 더 플래닛’ 시작

• 오픈AI가 오픈소스 보안 쪽으로 꽤 직접적인 프로젝트를 시작함 — 이름은 ‘패치 더 플래닛(Patch the Planet)’임

  • 트레일 오브 비츠(Trail of Bits)와 협력해서, 널리 쓰이는 오픈소스 프로젝트의 취약점을 AI로 찾고 실제 패치까지 이어가는 구조임
  • 단순히 취약점 리포트만 던지는 게 아니라, 유지관리자와 협의하고 검증하고 테스트하고 공개 절차까지 맞추는 쪽에 초점이 있음

• 초기 대상 프로젝트 라인업이 꽤 큼

  • 파이썬(Python), 고(Go), cURL, 시그스토어(Sigstore), NATS 서버, aiohttp, freenginx, pyca/cryptography, python.org 등이 포함됨
  • 개발 언어, 네트워킹, 암호화, 공급망 인프라까지 걸쳐 있어서 기업 애플리케이션 밑바닥에 깔린 것들이 많음

• 작업 방식은 ‘AI가 찾고, 사람이 걸러내고, 프로젝트 절차대로 고친다’에 가까움

  • 보안 연구원은 오픈AI 모델과 코덱스 시큐리티(Codex Security)를 써서 코드 분석과 수정 후보를 만듦
  • 트레일 오브 비츠 엔지니어가 유지관리자에게 전달하기 전에 결과를 검토함
  • 목적은 오탐과 중복 보고를 줄여서, 이미 바쁜 오픈소스 유지관리자에게 폭탄을 던지지 않겠다는 것임

sequenceDiagram
    participant 유지관리자
    participant 보안연구원
    participant AI모델
    participant 검토엔지니어
    participant 공개절차
    유지관리자->>보안연구원: 보안 지원이 필요한 영역 공유
    보안연구원->>AI모델: 코드 분석과 취약점 후보 탐색
    AI모델-->>보안연구원: 취약점 후보와 패치 초안 제안
    보안연구원->>검토엔지니어: 검증 결과와 수정안 전달
    검토엔지니어->>검토엔지니어: 오탐·중복 보고 필터링
    검토엔지니어->>공개절차: 패치와 공개 일정 조율

• 이미 결과도 일부 나왔다고 함
  • 오픈AI는 지금까지 수백 건의 보안 문제를 발견했고, 수십 건의 패치가 병합됐다고 밝힘
  • 더 많은 사례는 조정된 공개 절차에 따라 처리 중이라고 함
  • 퍼징(fuzzing), 과거 CVE 분석, 차등 테스트(differential testing) 도구도 개발됐고, 패치 생성 전에 부정확한 결과를 거르는 시스템도 만들었다고 함

• 왜 지금 이걸 하냐면, 오픈소스 공급망 사고의 충격을 다들 봤기 때문임

  • 로그4셸(Log4Shell)은 공유 라이브러리 하나가 얼마나 넓게 터질 수 있는지 보여줬음
  • XZ 유틸리티(XZ Utils) 백도어 사건은 유지관리 체계와 공급망 신뢰가 얼마나 취약한지도 보여줌

• 분석가들은 AI 취약점 연구를 ‘기존 보안 체계 대체재’로 보면 안 된다고 선을 긋고 있음

  • 포레스터의 비스와지트 마하파트라는 가장 큰 변화가 속도라고 봄
  • 대신 전문 인력 의존이 사라지는 건 아니고, 역할이 취약점 분류, 악용 가능성 판단, 패치 안전성 검토, 공개 시점 결정, 운영 배포 관리로 이동한다고 설명함

• 기업이 바로 가져다 쓰려면 거버넌스가 먼저 필요함

  • 오픈소스 보안 아키텍트 데바슈리 다타는 AI 결과가 인간 분석가에게 가기 전에 자동 검증을 통과해야 한다고 말함
  • 동적 개념증명(PoC) 검증, 강한 오탐 필터링, 감사 가능한 추적 체계가 필요하다는 얘기임
  • 특히 제3자 오픈소스에서 결함이 발견됐을 때 누가 통지하고, 언제 공개하고, 어떤 팀이 대응할지 미리 정해둬야 함

• 취약점 관리 방식도 정기 패치에서 지속적인 노출 관리로 바뀔 가능성이 큼

  • 변형 분석과 차등 테스트가 수주에서 수일로 줄면, 보안팀은 ‘우리 환경에서 진짜 중요한 취약점’을 훨씬 빨리 골라야 함
  • 일반적인 CVSS 점수만으로는 부족하고, 영향받는 시스템, 비즈니스 역할, 운영 노출도, 실제 악용 가능성을 같이 봐야 함

• 그래서 SBOM과 VEX의 역할이 커짐

  • SBOM은 단순한 규정 준수 스프레드시트가 아니라, 운영 환경 노출도와 공급업체 대응 상태가 반영된 살아 있는 자산 목록이어야 함
  • VEX는 해당 취약점이 실제로 악용 가능한지 기계가 읽을 수 있게 표현하는 데이터인데, AI 기반 파이프라인에서는 이 모델도 확장돼야 한다는 지적이 나옴

기술 맥락

• 이번 선택의 핵심은 취약점 탐지를 AI에게 맡기는 게 아니라, 취약점 처리 파이프라인을 더 짧게 만드는 데 있어요. 오픈소스 보안에서 진짜 병목은 “찾았다” 다음에 검증하고, 패치를 만들고, 유지관리자와 공개 일정을 맞추는 부분이거든요.

• 트레일 오브 비츠 같은 보안 전문가가 중간에 들어가는 이유도 여기 있어요. AI가 취약점 후보를 많이 만들수록 오탐도 늘 수밖에 없고, 그걸 그대로 오픈소스 프로젝트에 보내면 유지관리자 입장에서는 보안 지원이 아니라 업무 폭탄이 돼요.

• 기업 입장에서는 SBOM과 VEX가 갑자기 더 중요해져요. AI가 취약점을 빨리 찾아도, 우리 서비스가 그 라이브러리를 어디서 어떻게 쓰는지 모르면 우선순위를 못 정하거든요.

• 그래서 이 흐름은 보안팀만의 문제가 아니에요. 개발팀, 플랫폼팀, 공급업체 관리, 배포 승인 프로세스까지 연결돼야 실제 운영 환경에서 패치 속도가 빨라져요.