퍼블릭 리포지토리에 대한 관리자 권한이 있는 모든 사용자가 보안 권고를 생성할 수 있습니다.
퍼블릭 리포지토리에 대한 관리자 권한이 있는 모든 사용자에게는 해당 리포지토리의 모든 보안 권고에 대한 관리자 권한도 있습니다. 보안 권고에 대한 관리자 권한이 있는 사용자는 협력자를 추가할 수 있으며 협력자는 보안 권고에 대한 쓰기 권한을 갖습니다.
참고: 보안 연구원인 경우 관리자에게 직접 연락하여 관리하지 않는 리포지토리에서 보안 권고를 만들거나 CVE를 대신 발급하도록 요청해야 합니다. 그러나 리포지토리에 대해 프라이빗 취약성 보고를 사용하도록 설정한 경우 취약성을 비공개로 직접 보고할 수 있습니다. 자세한 내용은 "보안 취약성 비공개 보고"을(를) 참조하세요.
리포지토리 보안 공지 정보
취약성 공개는 보안 연구원과 프로젝트 유지 관리자와 같은 취약성 보고자 간의 협업이 매우 중요한 영역입니다. 두 당사자는 잠재적으로 유해한 보안 취약성이 발견되는 순간부터 취약성이 전 세계에 공개되고 이상적으로는 패치를 사용할 수 있게 되기까지 함께 작업해야 합니다. 일반적으로 누군가가 유지 관리자에게 비공개로 보안 취약성을 알리면 유지 관리자는 수정 사항을 개발하고, 유효성을 검사하며, 프로젝트 또는 패키지 사용자에게 알립니다. 자세한 내용은 "보안 취약성의 조정된 공개 정보"을 참조하세요.
리포지토리 보안 권고를 통해 퍼블릭 리포지토리 유지 관리자가 프로젝트의 보안 취약성을 비공개로 논의하고 수정할 수 있습니다. 수정 사항을 공동으로 수행한 후 리포지토리 관리자는 보안 공지를 게시하여 보안 취약성을 프로젝트 커뮤니티에 공개적으로 공개할 수 있습니다. 리포지토리 관리자는 보안 공지를 게시하여 커뮤니티가 더 쉽게 패키지 종속성을 업데이트하고 보안 취약성의 영향을 조사할 수 있습니다.
리포지토리 보안 공지를 사용하면 다음과 같이 할 수 있습니다.
- 초안 보안 공지를 만들고 초안을 사용하여 취약성이 프로젝트에 미치는 영향을 비공개로 논의합니다. 자세한 내용은 "리포지토리 보안 공지 만들기"을(를) 참조하세요.
- 프라이빗 협업을 통해 임시 프라이빗 포크의 취약성을 해결합니다.
- 패치가 릴리스되면 보안 공지를 게시하여 커뮤니티에 취약성을 경고합니다. 자세한 내용은 "리포지토리 보안 공지 게시"을(를) 참조하세요.
리포지토리 보안 공지를 사용하여 취약성의 세부 정보를 복사하여 새 보안 공지에 붙여 넣어 이미 다른 곳에서 공개한 보안 취약성의 세부 정보를 다시 게시할 수도 있습니다.
REST API를 사용하여 리포지토리 보안 공지를 만들고, 나열하고, 업데이트할 수도 있습니다. 자세한 정보는 "리포지토리 보안 권고에 대한 REST API 엔드포인트"을(를) 참조하세요.
보안 공지에 기여한 개인의 기여를 인정할 수 있습니다. 자세한 내용은 "리포지토리 보안 공지 편집"을(를) 참조하세요.
보안 정책을 만들어 프로젝트의 보안 취약성을 보고하는 지침을 사용자에게 제공할 수 있습니다. 자세한 내용은 "Adding a security policy to your repository(리포지토리에 보안 정책 추가)"을(를) 참조하세요.
리포지토리에서 보안 공지를 만든 경우 보안 공지는 리포지토리에 남아 있습니다. 종속성 그래프에서 지원하는 에코시스템에 대한 보안 공지를 github.com/advisories GitHub Advisory Database에 게시합니다. 누구나 GitHub Advisory Database에 게시된 공지에 변경 내용을 제출할 수 있습니다. 자세한 내용은 "GitHub Advisory Database에서 보안 권고 편집"을(를) 참조하세요.
특히 npm에 대한 보안 공지가 있는 경우 npm 보안 공지에 공지를 게시합니다. 자세한 내용은 npmjs.com/advisories를 참조하세요.
GitHub Security Lab에 참가하여 보안 관련 항목을 찾아보고 보안 도구 및 프로젝트에 기여할 수도 있습니다.
CVE ID 번호
GitHub Security Advisories는 CVE(Common Vulnerabilities and Exposures) 목록의 기초를 기반으로 합니다. GitHub의 보안 공지 양식은 CVE 설명 형식과 일치하는 표준화된 양식입니다.
GitHub는 CNA(CVE Numbering Authority)이며 CVE ID 번호를 할당할 권한이 있습니다. 자세한 내용은 CVE 웹 사이트의 “CVE 정보” 및 “CVE Numbering Authorities”를 참조하세요.
GitHub에서 퍼블릭 리포지토리에 대한 보안 공지를 만들 때 보안 취약성에 대한 기존 CVE ID 번호를 제공하는 옵션이 있습니다. 프로젝트의 보안 취약성에 대한 CVE 식별 번호를 원하지만 아직 보유하지 않은 경우 GitHub에서 CVE 식별 번호를 요청할 수 있습니다. GitHub는 일반적으로 72시간 이내에 요청을 검토합니다. CVE 식별 번호를 요청해도 보안 공지가 공개되지는 않습니다. 보안 공지가 CVE에 적합한 경우 GitHub는 공지에 CVE 식별 번호를 예약합니다. 그런 다음 보안 공지를 공개하면 CVE 세부 정보가 게시됩니다. 보안 공지에 대한 관리자 권한이 있는 사람은 누구나 CVE 식별 번호를 요청할 수 있습니다.
사용하려는 CVE가 이미 있는 경우(예: GitHub 이외의 CNA(CVE Numbering Authority)를 사용하는 경우) 보안 공지 양식에 CVE를 추가합니다. 예를 들어 게시 시 보낼 다른 통신과 일관된 권고를 원하는 경우 해당 상황이 발생할 수 있습니다. 다른 CNA에서 프로젝트를 다루는 경우 GitHub는 프로젝트에 CVE를 할당할 수 없습니다.
보안 공지를 게시하고 GitHub에서 취약성에 CVE ID 번호를 할당하면 GitHub는 CVE를 MITRE 데이터베이스에 게시합니다. 자세한 내용은 "리포지토리 보안 공지 게시"을(를) 참조하세요.
게시된 보안 공지에 대한 Dependabot alerts
GitHub은 게시된 각 보안 권고를 검토하고, GitHub Advisory Database에 추가하고, 보안 권고를 사용하여 영향을 받는 리포지토리에 Dependabot alerts를 보낼 수 있습니다. 보안 권고가 포크에서 제공되는 경우 포크가 퍼블릭 패키지 레지스트리에 고유한 이름으로 게시된 패키지를 소유하는 경우에만 경고를 보냅니다. 이 프로세스는 최대 72시간이 걸릴 수 있으며 GitHub에서 자세한 내용을 보려면 연락할 수 있습니다.
Dependabot alerts에 대한 자세한 내용은 "Dependabot 경고 정보" 및 "Dependabot 보안 업데이트 정보"을(를) 참조하세요. GitHub Advisory Database에 대한 자세한 내용은 “GitHub Advisory Database에서 보안 권고 탐색”을(를) 참조하세요.