리포지토리 보안 공지 작성 모범 사례

보안 공지를 만들거나 편집하는 경우 표준 형식을 사용하여 에코시스템, 패키지 이름 및 영향을 받는 버전을 지정하면 제공받는 정보를 다른 사용자가 더 쉽게 이해할 수 있습니다.

누가 이 기능을 사용할 수 있나요?

리포지토리 소유자, 조직 소유자, 보안 관리자 및 관리자 역할이 있는 사용자

이 문서의 내용

참고 항목

보안 연구원인 경우 관리자에게 직접 연락하여 관리하지 않는 리포지토리에서 보안 권고를 만들거나 CVE를 대신 발급하도록 요청해야 합니다. 그러나 리포지토리에 대해 프라이빗 취약성 보고를 사용하도록 설정한 경우 취약성을 비공개로 직접 보고할 수 있습니다. 자세한 내용은 보안 취약성 비공개 보고을(를) 참조하세요.

리포지토리에 대한 보안 공지 정보

리포지토리 보안 권고를 통해 퍼블릭 리포지토리 유지 관리자가 프로젝트의 보안 취약성을 비공개로 논의하고 수정할 수 있습니다. 수정 사항을 공동으로 수행한 후 리포지토리 관리자는 보안 공지를 게시하여 보안 취약성을 프로젝트 커뮤니티에 공개적으로 공개할 수 있습니다. 리포지토리 관리자는 보안 공지를 게시하여 커뮤니티가 더 쉽게 패키지 종속성을 업데이트하고 보안 취약성의 영향을 조사할 수 있습니다. 자세한 내용은 리포지토리 보안 공지 정보을(를) 참조하세요.

리포지토리 보안 공지를 작성하거나 글로벌 보안 공지에 커뮤니티 기여를 할 때 GitHub Advisory Database에 사용되는 구문, 특히 버전 서식을 사용하는 것이 좋습니다.

특히 영향을 받는 버전을 정의할 때 GitHub Advisory Database에 대한 구문을 따르는 경우:

  • 리포지토리 공지를 게시할 때 추가 정보를 요청하지 않고도 GitHub Advisory Database에 공지를 "GitHub-검토 완료" 공지로 추가할 수 있습니다.

  • Dependabot에는 영향을 받는 리포지토리를 정확하게 식별하고 Dependabot alerts을(를) 보내 알림을 보내는 정보가 있습니다.

  • 커뮤니티 구성원은 누락되거나 잘못된 정보를 수정하기 위해 공지 대한 편집을 제안할 가능성이 적습니다.

            _보안 공지 초안_ 양식을 사용하여 리포지토리 공지를 추가하거나 편집합니다. 자세한 내용은 [AUTOTITLE](/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory)을(를) 참조하세요.

        _보안 공지 개선_ 양식을 사용하여 기존 글로벌 공지를 개선할 것을 제안합니다. 자세한 내용은 [AUTOTITLE](/code-security/security-advisories/working-with-global-security-advisories-from-the-github-advisory-database/editing-security-advisories-in-the-github-advisory-database)을(를) 참조하세요.

에코시스템

          **에코시스템** 필드를 사용하여 지원되는 에코시스템 중 하나에 공지를 할당해야 합니다. 지원하는 에코시스템에 대한 자세한 내용은 [AUTOTITLE](/code-security/security-advisories/working-with-global-security-advisories-from-the-github-advisory-database/browsing-security-advisories-in-the-github-advisory-database#github-reviewed-advisories)을(를) 참조하세요.

보안 공지 양식에 있는 "영향을 받는 제품" 영역의 스크린샷. "에코 시스템" 필드는 진한 주황색 윤곽선으로 강조 표시됩니다.

패키지 이름

GitHub Advisory Database의 "GitHub-검토 완료" 공지에 패키지 정보가 필요하기 때문에 패키지 이름 필드를 사용하여 영향을 받는 패키지를 지정하는 것이 좋습니다. 패키지 정보는 리포지토리 수준 보안 공지에서 선택 사항이지만 이 정보를 조기에 포함하면 보안 공지를 게시할 때 검토 프로세스가 간소화됩니다.

영향을 받는 버전

이 정보는 GitHub Advisory Database의 "GitHub-검토 완료" 공지에 필요하기 때문에 영향을 받는 버전 필드를 사용하여 영향을 받는 버전을 지정하는 것이 좋습니다. 버전 정보는 리포지토리 수준 보안 공지에서 선택 사항이지만 이 정보를 조기에 포함하면 보안 공지를 게시할 때 검토 프로세스가 간소화됩니다.

GitHub Advisory Database에 대한 자세한 내용은 https://github.com/github/advisory-database을(를) 참조하세요.

Glossary

  •         **VVR(약점이 있는 버전 범위)**: 특정 소프트웨어 버그에 약점이 있는 버전 범위입니다.

  •         **연산자**: 약점이 있는 버전 범위의 경계를 나타내는 기호입니다.

  •         **OSV(오픈 소스 약점 형식):** GitHub Advisory Database 데이터와 호환되도록 노력하는 형식입니다.

버전 구문

  • 숫자가 작을수록 더 큰 숫자보다 이전 버전입니다. 예를 들어 1.0.0은 2.0.0보다 낮은 버전입니다.
  • 알파벳의 이전 문자는 알파벳의 이후 문자보다 이전 버전입니다. 예를 들어 2.0.0-a는 2.0.0-b보다 이전 버전입니다.
  • 숫자 뒤에 오는 모든 문자는 시험판의 일부로 간주되므로 문자가 숫자 뒤에 있는 모든 버전은 문자가 버전 번호에 없는 숫자보다 이전 버전입니다. 예를 들어 2.0.0-alpha, 2.0.0-beta 및 2.0.0-rc는 2.0.0보다 이전 버전입니다.
  • 최종 버전은 VVR에서 가장 큰 숫자보다 작을 수 없습니다. 예를 들어 약점이 있는 버전이 릴리스되고 유지 관리자가 다운그레이드를 권장합니다. 해당 버전이 취약한 버전보다 작기 때문에 유지 관리자는 해당 하위 버전을 Fixed 필드에서 고정 또는 패치된 버전으로 레이블을 지정할 수 없습니다.

지원되는 연산자

  •         `>=`는 "이 버전보다 크거나 같음"입니다.

  •         `>`는 "이 버전보다 큼"입니다.

    경고

    GitHub은(는) > 연산자 사용을 지원하지만 OSV 형식에서 지원되지 않으므로 이 연산자를 사용하지 않는 것이 좋습니다.

  •         `=`는 "이 버전과 같음"입니다.

  •         `<=`는"이 버전보다 작거나 같음"입니다.

  •         `<`는"이 버전보다 작음"입니다.

GitHub에서 영향을 받는 버전 지정

권고에 대해 영향을 받는 버전을 명확하게 정의하는 것이 중요합니다. GitHub은(는) 영향을 받는 버전 필드에서 취약한 버전 범위를 지정할 수 있는 몇 가지 옵션을 제공합니다.

영향을 받는 버전이 일부 기존 권고에서 정의되는 방법을 보여 주는 예제는 예제를 참조하세요.

  • 영향을 받는 버전에 대한 유효한 문자열은 다음 중 하나로 구성됩니다.

    • 하한 연산자 시퀀스

    • 상한 연산자 시퀀스

    • 상한 및 하한 연산자 시퀀스 하한이 먼저 와야 하고, 그 다음에는 쉼표와 단일 공백, 상한이 와야 합니다.

    • 같음(=) 연산자를 사용하는 특정 버전 시퀀스

    • 각 연산자 시퀀스를 연산자, 단일 공백 및 버전으로 지정해야 합니다. 유효한 연산자에 대한 자세한 내용은 지원되는 연산자를 참조하세요.

    • 버전은 숫자로 시작해야 하며, 그 뒤에 숫자, 문자, 점, 대시 또는 밑줄(공백 또는 쉼표 제외)이 와야 합니다. 버전 서식을 지정하는 방법에 대한 자세한 내용은 위의 버전 구문을 참조하세요.

    참고 항목

    영향을 받는 버전 문자열은 선행 공백이나 후행 공백을 포함할 수 없습니다.

  • 상한 연산자는 각각 포함 또는 배타적(예: <= 또는 <)일 수 있습니다.

  • 하한 연산자는 각각 포함 또는 배타적(예: >= 또는 >)일 수 있습니다. 그러나 리포지토리 공지를 게시하고 해당 리포지토리 공지를 글로벌 공지로 사용하는 경우 다른 규칙이 적용됩니다. 하한 문자열은 포함적(예: >=)일 수만 있습니다. 배타적 하한 연산자(>)는 버전이 0일 때만 가능합니다(예 > 0).

  • 적절한 공백 사용

    • 공백을 연산자와 버전 번호 사이에 사용합니다.

    • 공백을 >= 또는 <=에 사용하지 않습니다.

    •      `>= lower bound, <= upper bound`에서 공백을 숫자와 쉼표 사이에 사용하지 않습니다.

    • 공백을 쉼표와 상한 연산자 사이에 사용합니다.

    참고 항목

    하한 제한:

    • OSV 스키마와의 비호환성 때문에 사용합니다.
    • GitHub Advisory Database의 기존 공지에 대한 제안을 할 때만 적용됩니다.
  •         `> 2.0, < 2.3, > 3.0, < 3.2`과(와) 같이 동일한 필드에 영향을 받는 버전 범위를 여러 개 지정할 수 없습니다. 둘 이상의 범위를 지정하려면 **+ 영향을 받는 다른 제품 추가** 단추를 클릭하여 각 범위에 대해 **영향을 받는 제품** 섹션을 새로 만들어야 합니다.

    보안 공지 양식에 있는 "영향을 받는 제품" 영역의 스크린샷. "영향을 받는 다른 제품 추가" 링크는 진한 주황색 윤곽선으로 표시됩니다.

  • 영향을 받는 버전 범위에 상한 또는 하한이 하나만 포함된 경우:

    • 하한이 명시적으로 지정되지 않은 경우 암시적 값은 항상 > 0입니다.
    • 상한이 명시적으로 지정되지 않은 경우 암시적 값은 항상 무한대입니다.

VVR에서 상한만 설정

  • 상한만 설정하는 경우 <= 또는 <를 사용합니다.
  • GitHub Advisory Database은(는) PyPA 데이터베이스를 해당 데이터 원본 중 하나로 사용합니다. 그러나 GitHub은(는) PyPA VVR 형식과 정확히 일치하지 않습니다(PyPa 보안 권고는 상한만 있는 버전 범위를 참조하기 위해 >= 0, <= n 또는 >= 0, < n을 사용하는 경우가 많음).
  • 상한만 있는 범위에 >= 0을 포함할 필요가 없습니다.

VVR에서 하한만 설정

  • 자문 큐레이션 팀은 맬웨어 이외의 권고에서만 하한을 설정하는 것을 권장하지 않습니다. 이는 최종 버전이 릴리스되면 권고가 수동으로 업데이트될 때까지 최종 버전의 사용자가 불필요한 Dependabot alerts을(를) 계속 받기 때문입니다.
  • 모든 버전의 경우 >= 0 사용
  •         `> 0`은 일반적으로 사용되지 않습니다.

영향을 받는 하나의 버전만 지정

  •         `= n`(영향을 받는 단일 버전의 경우)

  •         `=`는 퍼블릭 또는 프라이빗 미리 보기를 자동으로 포함하지 않고 _지정된 버전만_ 포함합니다.

일반 오류

  •         `< n` 약점이 있는 버전 범위를 사용한 다음, `n+1`이 패치되었다고 하지 않습니다.

    * < n이 약점이 있는 버전이 아닌 경우에만 n을 사용해야 합니다.

    • 이 경우 VVR은 <= n 또는 < n+1이어야 합니다.

  • 문자가 공식 버전 번호에 있는 최종 버전을 설명하는 경우 숫자만 사용하지 않습니다. linux와 windows의 두 개 분기가 소프트웨어에 있다고 가정해 보겠습니다. 2.0.0-linux와 2.0.0-windows를 릴리스할 때 < 2.0.0을 약점이 있는 버전으로 사용하면 버전 논리에서 2.0.0-linux와 2.0.0-windows를 시험판으로 해석하므로 -linux와 -windows가 약점이 있는 버전으로 표시됩니다. 2.0.0-linux와 2.0.0-linux가 약점이 있는 버전으로 간주되지 않도록 방지하기 위해 알파벳에서 가장 빠른 분기인 2.0.0-windows를 첫 번째 패치 버전으로 표시해야 합니다.

예시

여러 VVR과 여러 연산자가 있는 권고

          [etcd 게이트웨이 TLS 인증은 DNS SRV 레코드에서 검색된 엔드포인트에만 적용(GHSA-wr2v-9rpq-c35q)](https://github.com/advisories/GHSA-wr2v-9rpq-c35q)에는 2개의 약점이 있는 버전 범위가 있습니다.

* < 3.3.23 - 상한은 있지만 하한이 없고 < 연산자를 사용합니다. * >= 3.4.0-rc.0, <= 3.4.9 - 상한과 하한이 모두 있고 >= 및 <= 연산자를 사용합니다.

시험판과 일반 릴리스 간의 관계를 보여주는 권고

          [XWiki 플랫폼은 문자열 속성에서 XClass 이름을 통해 XSS를 허용(GHSA-wcg9-pgqv-xm5v)](https://github.com/advisories/GHSA-wcg9-pgqv-xm5v)에는 4개의 약점이 있는 버전 범위가 있습니다.
  • >= 1.1.2, < 14.10.21
  • >= 15.0-rc-1, < 15.5.5
  • >= 15.6-rc-1, < 15.10.6
  • = 16.0.0-rc-1

이러한 VVR 중 3개는 시험판을 약점이 있는 버전의 범위에 포함합니다. 마지막 VVR인 = 16.0.0-rc-1에서는 16.0.0-rc-1만 약점이 있는 버전이고, 그 뒤에 있는 일반 릴리스인 16.0.0은 약점이 있는 버전이 아닌 버전임을 보여줍니다. 이 논리는 16.0.0-rc-1과 16.0.0을 별도의 버전으로 간주하며, 16.0.0-rc-1은 16.0.0보다 이전 버전의 릴리스입니다.

이 약점에 대한 패치는 버전 16.0.0에 대해 2024년 1월 24일에 게시되었습니다. 자세한 내용은 리포지토리의 xwiki/xwiki-platform 를 참조하세요. MVN Repository 사이트의 XWiki Platform Old Core 페이지에 따르면, 16.0.0-rc-1는 수정 사항이 XWiki에 추가되기 전인 2024년 1월 22일에 게시되었고, 16.0.0은 수정 사항이 커밋된 후인 2024년 1월 29일에 게시되었습니다.

분기 이름이 버전 번호에 있는 권고

          [Google Guava](https://mvnrepository.com/artifact/com.google.guava/guava)의 해당 버전 릴리스에는 `android`와 `jre`의 두 개 분기가 있습니다. 
          [Guava가 임시 디렉터리의 안전하지 않은 사용에 약점이 있음(GHSA-7g45-4rm6-3mm3)](https://github.com/advisories/GHSA-7g45-4rm6-3mm3) 및 [Guava의 정보 공개(GHSA-5mg8-w23w-74h3)](https://github.com/advisories/GHSA-5mg8-w23w-74h3)는 Guava에 영향을 주는 약점에 대한 권고입니다. 두 권고는 모두 `32.0.0-android`를 패치된 버전으로 설정합니다.

* 32.0.0 뒤의 문자를 시험판으로 해석하는 버전 범위 논리로 인해 패치된 버전을 32.0.0으로 설정하면 32.0.0-android 및 32.0.0-jre는 모두 약점이 있는 버전으로 잘못 표시됩니다.

  • 알파벳의 뒤에 있는 문자를 알파벳의 앞에 있는 문자보다 이후 버전으로 해석하는 버전 범위 논리로 인해 패치된 버전을 32.0.0-jre로 설정하면 32.0.0-android는 약점이 있는 버전으로 잘못 표시됩니다.

            `32.0.0-android`와 `32.0.0-jre`가 모두 패치된 버전임을 나타내는 가장 좋은 방법은 `32.0.0-android`를 패치된 버전으로 사용하는 것입니다. 그러면 논리에서 알파벳의 `32.0.0-android` 뒤에 있는 모든 문자를 패치된 버전으로 해석합니다.