CNCF는 2026년 9월 7일 «취약점 제보 처리»(Handling vulnerability reports: Recipe card)라는 제목의 지침 카드를 발표했다. 이 자료는 보안을 주된 초점으로 삼지 않는 소규모 및 중간 규모 오픈 소스 프로젝트를 대상으로 한다. 자료는 Edera의 Marina Moore와 Red Hat의 Sherine Khoury가 작성했다. Marina Moore는 TAG Security의 공동 의장이고, Sherine Khoury는 TAG Security의 리드다.
이 지침의 핵심은 관리자와 사용자의 추가 작업을 줄이는 동시에, 수정 사항이 준비되기 전에 보안 제보가 공개적인 논의로 변하는 것을 막는 것이다. CNCF는 보안 취약점을 시스템의 기밀성, 무결성 또는 가용성에 영향을 주기 위해 악용될 수 있는 결함으로 설명한다. 그러나 모든 소프트웨어 결함이 악용 가능하거나 취약점으로 분류되는 것은 아니다.
명확하고 비공개인 제보 채널부터 마련하기
지침은 README.md 파일에 쉽게 찾을 수 있는 명확한 보안 섹션을 포함하고, 지침을 파일에 직접 작성하거나 저장소 루트의 SECURITY.md 파일로 연결할 것을 권고한다. 목표는 연구자들이 누구나 읽을 수 있는 공개 issue에 문제의 세부 사항을 게시하지 않고 비공개 경로를 이용하도록 안내하는 것이다.
제보 지침에는 위협 모델 또는 제보를 취약점으로 인정하기 위한 최소 기준, 제출 위치, 제보 형식, 검토까지 예상되는 기간, 공개까지의 대략적인 기간 등 여러 요소가 명시되어야 한다. GitHub의 비공개 취약점 제보 기능이나 비공개 메일링 리스트를 사용할 수 있다. 보상 프로그램은 운영할 역량이 없다면 소규모 및 중간 규모 프로젝트에 의무 사항이 아니다.
제보를 취약점으로 처리하기 전에 성격 확인하기
제보가 접수되면 먼저 실제로 악용 가능한 취약점을 가리키는지, 악용할 수 없는 결함인지, 예상된 동작에 대한 오해인지, 아니면 문서 오류인지를 판단해야 한다. CNCF는 제보자 및 프로젝트의 적절한 전문가들과 제보를 논의하되, 참여자 수를 제한하고 제보가 공개될 때까지 모두가 기밀을 준수할 것을 제안한다.
실무적으로 제기할 수 있는 질문은 다음과 같다. 사용자에게 이용 가능한 완화 조치가 있는가? 결함이 침해나 데이터 유출 또는 다른 악의적 활동으로 이어질 수 있는가? 문제는 문서에만 있는가? 제보가 취약점이 아닌 것으로 확인되면 제보자에게 공개 issue를 만들도록 안내할 수 있으며, 필요한 경우 사용자에게 알리기 위해 적절한 공개 절차를 사용해야 한다.
확실하지 않은 경우 지침은 TAG Security and Compliance 또는 CNCF 직원에게 지침을 요청할 수 있다고 설명한다. 이때 제보 세부 사항은 공개 채널 밖에 두어야 한다. 또한 비밀 유지 기간에 참여할 사람을 신중하게 선택하고, 해결에 실제로 도움이 필요한 사람만 참여시켜 수정 사항이 제공되기 전에 정보가 공격자에게 유출되지 않도록 해야 한다.
공개되지 않은 상태에서 수정 사항을 개발하고 테스트하기
CNCF는 공개 pull request에서 수정 사항을 게시하거나 논의하면 사용자가 업데이트할 기회를 갖기 전에 취약점의 성격이 드러날 수 있다고 경고한다. GitHub의 비공개 제보 기능을 사용하는 경우 제보에서 시작하는 비공개 브랜치를 만들 수 있다. 그 밖의 경우에는 비공개 채널을 통해 수정 사항을 개발하고 검토할 수 있다.
일반적인 지속적 통합 환경이 비공개 브랜치에서 작동하지 않더라도 수정 사항을 테스트해야 한다. 이 경우 관리자의 판단과 변경 범위에 따라 로컬에서 테스트를 수행할 수 있다. 수정 사항이 문제를 해결하고 테스트가 충분하다는 것을 확인한 뒤, 지침은 이를 신속하게 병합하고 충분한 수의 관리자가 작성과 테스트에 참여하도록 권고한다. 공개하기 전에 코드를 다시 검토하고 취약점이 실제로 차단되었는지 확인해야 한다.
릴리스와 CVE 공개 조정하기
수정 사항이 완료된 후 CNCF는 제보를 받은 날로부터 90일 이내에 이를 공개하는 것을 일반적인 관행으로 본다. 프로젝트의 자원이 허용한다면 사용자로 구성된 비공개 목록에 미리 알릴 수 있지만, 최신 연락처 목록을 유지하는 일은 대부분의 소규모 프로젝트가 감당할 수 없는 부담이다.
따라서 이 카드는 더 간단한 접근 방식을 제안한다. 수정 사항이 포함된 릴리스를 제공하고 취약점을 동시에 발표해 사용자가 문제가 공개될 때 수정 사항을 받을 수 있도록 하는 것이다. 이를 위해서는 수정 사항이 반영되는 즉시 새 릴리스를 빌드한 다음 CVE를 공개해야 한다. GitHub의 비공개 기능을 사용하는 경우 GitHub 인터페이스에서 이를 수행할 수 있다.
CVE 번호는 CNA, 즉 CVE 번호 부여 기관에서 할당해야 한다. GitHub도 이러한 기관 중 하나이며 이 절차를 수행할 수 있다. 프로젝트와 연구자는 등록된 CNA 중 한 기관과 직접 연락할 수도 있다. CVE 심각도는 일련의 질문을 통해 결정하며, 프로젝트는 연구자와 협력해 답변의 정확성을 확인하고 부여되는 심각도에 합의해야 한다.
이 지침이 중요한 이유
실질적으로 이 카드는 취약점 관리를 무작위적인 대응에서 실행 가능한 절차로 전환한다. 즉, 비공개 채널, 제한적인 확인, 비공개 수정, 그리고 조정된 릴리스와 공개의 순서다. CVE가 공개되면 정보는 OSV와 다른 취약점 데이터베이스에 나타나며, 사용자의 검사 도구가 업데이트가 필요한지 확인하는 데 도움을 준다.
그러나 이 레시피의 범위에는 분명한 한계가 있다. 보안을 전문으로 하지 않는 소규모 및 중간 규모 프로젝트를 대상으로 하며, 위험도가 높거나 보안에 민감한 프로젝트를 위한 더 복잡한 프로그램을 대체하지 않는다. 또한 CNCF는 수정 사항을 제공한 뒤 일정 시간이 지나면 개념 증명을 공개하는 방안을 검토하라고 제안한다. 이는 사용자에게 업데이트할 추가 기회를 주기 위한 것이지만, 비공개 제보를 사용할 때는 실행이 어려울 수 있다는 점도 인정한다.