내부 원본 권고 관리

내부 원본 권고의 작동 방식과 이를 만들 수 있는 사용자에 대한 배경 정보는 Innersource advisories을 참조하세요.

사전 요구 사항

내부 원본 권고는 활성 GitHub Code Security 또는 GitHub Advanced Security 라이선스가 있는 기업에서만 만들 수 있습니다.

InnerSource 권고문 만들기

내부 원본 권고를 만들려면 다음을 수행합니다.

enterprise_innersource_vulnerabilities 권한으로 GitHub App를 만들고 설치합니다.
이 권한에 대한 액세스 권한이 있는 write 앱과 연결된 토큰을 생성합니다.
OSV 형식을 사용하여 취약점에 대한 설명을 만들고, 이를 REST API 엔드포인트 /enterprises/{enterprise}/innersource-vulnerabilities/sync에 POST합니다.

이러한 각 단계는 아래에 자세히 설명되어 있습니다.

1단계: GitHub App 생성

조직이 소유한 GitHub App을(를) 등록하고, read and write 액세스 권한이 있는 enterprise_innersource_vulnerabilities 권한을 부여합니다. GitHub 앱 등록을(를) 참조하세요.

앱을 등록한 후 엔터프라이즈를 대신하여 작동할 수 있도록 엔터프라이즈에 설치합니다.

2단계: 액세스 토큰 생성

GitHub App 설치로 인증하여 설치 액세스 토큰을 생성하려면. 이 토큰은 enterprise_innersource_vulnerabilities 사용 권한을 전달하며 REST API에 대한 요청을 인증하는 데 사용됩니다. GitHub 앱에 대한 설치 액세스 토큰 생성을(를) 참조하세요.

OSV 형식으로 취약성을 설명한 다음, 설치 액세스 토큰으로 인증하여 페이로드를 /enterprises/{enterprise}/innersource-vulnerabilities/sync에 POST합니다. 페이로드는 영향을 받는 패키지와 취약한 버전 범위를 식별합니다. 고정 버전을 사용할 수 있는 경우 영향을 받는 리포지토리를 업데이트하기 위한 끌어오기 요청을 열 수 있도록 fixed 버전 번호가 있는 필드를 포함합니다Dependabot.

권고 스키마에 대한 자세한 내용은 보안 권고에 대한 REST API 엔드포인트을 참조하세요.

InnerSource 권고 사항 사용

내부 원본 권고를 만든 후 영향을 받는 구성 요소를 사용하는 엔터프라이즈의 리포지토리는 경고 및 업데이트를 받습니다.

엔터프라이즈의 리포지토리에서 Dependabot alerts 및 업데이트가 사용 설정되어 있는지 확인하세요. 보안 구성을 사용하여 대규모로 적용할 수 있습니다. 사용자 정의 보안 구성 생성하기을(를) 참조하세요.
영향을 받는 구성 요소에 대한 새 경고는 종속 리포지토리 페이지를 Dependabot alerts 참조하세요. 경고에는 오픈 소스 권고 경고와 구분하기 위해 고유한 "Innersource" 레이블이 있습니다.
권고 페이로드에 사용 가능한 패키지와 일치하는 버전 번호가 있는 필드가 포함된 fixed 경우 패키지 Dependabot 관리자의 매니페스트 파일을 업데이트하는 끌어오기 요청도 생성됩니다. Dependabot 버전 업데이트 구성을(를) 참조하세요.

InnerSource 권고 사항 철회

영향을 받는 구성 요소의 취약한 버전이 더 이상 없거나 권고가 대체된 경우 이를 철회하는 것이 도움이 될 수 있습니다.

권고를 철회하려면 생성 단계와 동일한 REST API 엔드포인트를 사용하되, 값이 취약점이 철회된 시점을 나타내는 date-time 필드인 withdrawn 키를 포함하도록 페이로드를 조정합니다.

OSV 형식 지원 및 제한 사항

GitHub 는 내부 원본 취약성 동기화 API를 통해 OSV(오픈 소스 취약성) 형식 의 취약성을 허용합니다. OSV 사양과의 호환성을 위해 노력하는 동안 GitHub 표준 OSV 스키마와 필요하거나 지원하는 항목 GitHub 간에는 차이가 있습니다.

지원되는 OSV 스키마 버전

GitHub는 ~> 1.0와 호환되는 OSV 스키마 버전(즉, 1.0.0부터 1.x.x까지)을 지원합니다. 권장되는 스키마 버전은 1.4.0.

영향을 받는 항목 서식

OSV 사양을 사용하면 단일 affected 항목에 동일한 패키지에 대해 여러 ranges 항목과 다중 versions 항목이 포함될 수 있습니다. GitHub 를 별도의 항목으로 분할하여 내부적으로 정규화합니다.

| OSV 표준 | GitHub 동작 | |---|---| | 단일 affected 항목에는 여러 항목이 포함될 수 있습니다. ranges | Accepted. 각 범위는 별도의 취약한 버전 범위로 처리됩니다. | | 단일 affected 항목에는 여러 항목이 포함될 수 있습니다. versions | Accepted. 각 버전은 정확한 일치(= x.y.z)로 처리되고 별도의 취약한 버전 범위로 처리됩니다. | | 단일 affected 항목에는 ranges 및 versions가 혼합될 수 있습니다. | Accepted. 범위와 버전은 내부적으로 별도의 항목으로 분할됩니다. | | SEMVER 범위에 여러 introduced/fixed 쌍이 포함될 수 있습니다. | Accepted. 단일 범위 내의 여러 비연속 간격(예: [1.0.0, 1.0.2) 및 [3.0.0, 3.2.5))이 지원됩니다. |

지원되는 범위 유형

범위 유형	Support
`ECOSYSTEM`
완전히 지원됨.
`introduced`, `fixed` 및 `last_affected` 이벤트를 지원합니다.
`SEMVER`
완전히 지원됨.
`introduced`, `fixed` 및 `last_affected` 이벤트를 지원합니다.
`last_affected` 이벤트는 `<=` 상한 비교자로 구문 분석됩니다.
`GIT`
지원되지 않습니다. Git 커밋 기반 범위는 처리되지 않습니다.

참고

ECOSYSTEM 범위의 경우 각 범위당 introduced 이벤트 1개와 fixed(또는 last_affected) 이벤트 1개만 지원됩니다. 동일한 패키지에 대해 여러 개의 비연속 버전 범위를 표현해야 하는 경우 별도의 affected 항목 또는 별도의 범위를 사용합니다.

- SEMVER 범위는 단일 범위 내의 여러 introduced/fixed 쌍(예: [1.0.0, 1.0.2)``[3.0.0, 3.2.5) 하나의 이벤트 배열)을 지원합니다.

fixed 및 last_affected같은 범위에는 같이 나타날 수 없습니다. 둘 중 하나를 사용하되, fixed를 우선합니다.

필수 필드

OSV 사양은 여러 필드를 선택 사항으로 처리하지만 GitHub 필수입니다. 이러한 필드가 누락된 요청은 422 오류로 거부됩니다.

| Field | OSV 사양 | GitHub 요구 사항 | |---|---|---| | id | 필수 | 필수입니다. 취약성의 외부 식별자로 사용됩니다. | | severity 배열 | Optional | 필수입니다. 비어 있지 않은 score 문자열(예: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)이 있는 CVSS_V3 또는 CVSS_V4 항목을 하나 이상 포함해야 합니다. 유효한 CVSS 항목이 없는 요청은 거부됩니다. | | affected[].package.ecosystem | 필수 | 지원되는 에코시스템이어야 합니다. | | affected[].ranges 또는 affected[].versions | 하나 이상 필요 | 경고 일치를 위해 하나 이상의 범위 또는 버전이 있어야 합니다. |

자동 파생이 있는 선택적 필드

Field	작동 방식
`database_specific.severity`	제공된 경우 정성적 심각도 레이블(`critical`, `high`, `moderate`또는 `low`)로 사용됩니다. 심각도가 지정되지 않은 경우 CVSS 벡터 점수를 기준으로 자동으로 결정됩니다.
`summary`	없으면 `id` 필드를 대신 사용합니다.
`details`	없는 경우 `summary` 또는 `id`로 대체됩니다.

지원되는 심각도 유형

심각도 유형	Support
`CVSS_V3`
지원. 유효한 CVSS 3.1 벡터 문자열이어야 합니다.
`CVSS_V4`
지원. 유효한 CVSS 4.0 벡터 문자열이어야 합니다.
기타 형식
지원되지 않습니다. 구문 분석 오류가 발생합니다.

지원되는 참조 형식

참조 형식	Support
`ADVISORY`	지원됨
`WEB`	지원됨
`FIX`	지원됨
`ARTICLE`	지원됨
`REPORT`	지원됨
`PACKAGE`	지원됨(소스 코드 위치에 매핑됨)
`EVIDENCE`	지원됨(처리 중 무시됨)
`DETECTION`
지원되지 않습니다. 처리 중에 제거되었습니다.

별칭 지원

별칭 형식	Support
`CVE-YYYY-NNNNN`
지원. CVE 식별자로 추출됩니다. 첫 번째 CVE 별칭만 사용됩니다.
기타 형식(GHSA, PYSEC 등)
지원되지 않습니다. 처리 중에 제거되었습니다.

참고

취약성 id 필드가 GHSA-시작되면 GHSA 식별자로 인식됩니다. 그러나 배열의 GHSA 항목 aliases 은 제거되고 유지되지 않습니다.

필드 크기 제약 조건

OSV 사양은 모든 필드에 대한 최대 문자열 길이를 정의하지 않습니다. 모든 문자열은 바인딩되지 않습니다. 그러나 GitHub 내부 데이터베이스 스키마에 따라 필드 크기 제한을 적용합니다. GitHub Enterprise Server는 자체적으로 호환되는 스키마를 유지하므로, GitHub Enterprise Server와의 동기화를 깨뜨리지 않고서는 이러한 제한을 완화할 수 없습니다.

이러한 제한을 초과하는 제출은 제한을 초과한 필드와 제공된 실제 길이(예: affected[0].first_patched_version is 63 characters (max 50))를 나타내는 설명이 포함된 422 오류와 함께 거부됩니다.

| OSV 필드 | 에 매핑 | OSV 표준 제한 | GitHub 제한 | 단위 | |---|---|---|---|---| | summary | vulnerabilities.summary | 제한 없음(권장 ≤120자) | 1,024 | bytes | | id | vulnerabilities.external_id | 제한 없음 | 2,048 | 문자 | | aliases[] (CVE 항목) | vulnerabilities.cve_id | 제한 없음 | 20 | 문자 | | severity[].score (CVSS v3) | vulnerabilities.cvss_v3 | 제한 없음 | 255 | bytes | | severity[].score (CVSS v4) | vulnerabilities.cvss_v4 | 제한 없음 | 255 | 문자 | | affected[].package.ecosystem | vulnerable_version_ranges.ecosystem | 제한 없음 | 20 | 문자 | | affected[].package.name | vulnerable_version_ranges.affects | 제한 없음 | 255 | 문자 | | affected[].ranges[].events[].fixed | vulnerable_version_ranges.fixed_in | 제한 없음 | 50 | 문자 | | 계산된 취약한 버전 범위 | vulnerable_version_ranges.requirements | 제한 없음 | 65,535 | bytes |

참고

fixed_in 50자의 (첫 번째 패치 버전) 제한은 가장 일반적으로 발생하는 제약 조건입니다. 일부 에코시스템은 이 제한을 초과하는 긴 시험판 버전 문자열(예: 1.0.0-alpha.gamma.delta.epsilon.zeta.eta.theta)을 사용합니다.

- varchar 열은 문자 수로 유효성을 검사합니다. varbinary 열은 text 바이트 크기로 유효성을 검사합니다(멀티 바이트 UTF-8 문자와 관련됨).

이러한 제한은 스키마 호환성에 의해 GitHub Enterprise Server 제한됩니다. GHES 변경 내용과 GitHub 일치하지 않고 열을 확장하면 환경 간에 권고 동기화 오류가 발생합니다.

에코시스템 매핑

GitHub 는 OSV 에코시스템 이름을 내부 에코시스템 식별자에 매핑합니다. 지원되는 에코시스템은 다음과 같습니다.

| OSV 에코시스템 | GitHub 에코시스템 | |---|---| | npm | npm | | PyPI | pip | | RubyGems | RubyGems | | Maven | Maven | | NuGet | 누겟 | | Packagist | 작성기 | | Go | Go | | crates.io | 러스트 | | Hex | Erlang | | Pub | Pub | | SwiftURL | Swift | | GitHub Actions | GitHub Actions (GitHub 액션) |

예: 경고 생성을 위한 최소 OSV 페이로드

다음은 GitHubDependabot 알림을 생성하는 데 필요한 모든 필드를 포함하는 최소 OSV 페이로드입니다:

{
  "schema_version": "1.4.0",
  "id": "EXAMPLE-2024-001",
  "modified": "2024-01-15T10:00:00Z",
  "summary": "Example vulnerability in example-package",
  "details": "A detailed description of the vulnerability.",
  "aliases": ["CVE-2024-12345"],
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "example-package"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "0" },
            { "fixed": "1.2.3" }
          ]
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "references": [
    { "type": "ADVISORY", "url": "https://example.com/advisory" }
  ],
  "published": "2024-01-15T10:00:00Z"
}

알려진 제한 사항

요청당 최대 100개 취약성 동기화 API는 단일 요청에서 최대 100개의 취약성을 허용합니다.
범위 유형이 없습니다 GIT . Git 커밋 기반 버전 범위는 지원되지 않습니다.
ECOSYSTEM 범위당 단일 이벤트 유형입니다. 각 ECOSYSTEM 범위는 introduced 1개와 상한 이벤트 1개(fixed 또는 last_affected)를 지원합니다. 단일 introduced 범위의 여러/fixed``ECOSYSTEM 쌍은 지원되지 않습니다. 대신 별도의 범위 또는 별도의 affected 항목을 사용합니다. (이 제한은 여러 이벤트 쌍을 지원하는 SEMVER 범위에는 적용되지 않습니다.)
fixed 는 last_affected 상호 배타적입니다. 단일 범위에는 fixed 이벤트와 last_affected 이벤트를 모두 포함할 수 없습니다. 하나 또는 다른 하나를 사용합니다.
GHES 동기화 호환성 필드 크기 제한(예: fixed_in 50자)은 스키마 호환성 요구 사항에 의해 GitHub Enterprise Server 제한됩니다.

이 기사에서