아티팩트 증명 정보
아티팩트 증명을 사용하면 빌드한 소프트웨어에 대해 수정할 수 없는 출처 및 무결성 보장을 생성할 수 있습니다. 따라서 소프트웨어를 사용하는 사용자는 소프트웨어가 빌드된 위치와 방법을 확인할 수 있습니다.
소프트웨어를 사용하여 아티팩트 증명을 생성하는 경우 빌드의 출처를 설정하고 다음 정보가 포함된 암호화 서명된 클레임을 만듭니다.
- 아티팩트와 연결된 워크플로의 링크입니다.
- 아티팩트의 리포지토리, 조직, 환경, 커밋 SHA 및 트리거 이벤트입니다.
- 출처를 설정하는 데 사용되는 OIDC 토큰의 기타 정보입니다. 자세한 내용은 "OpenID Connect를 사용한 보안 강화 정보"을(를) 참조하세요.
관련 SBOM(소프트웨어 자료 청구서)을 포함하는 아티팩트 증명을 생성할 수도 있습니다. 빌드에 사용되는 오픈 소스 종속성 목록과 빌드를 연결하면 투명성을 보장하고 소비자가 데이터 보호 표준을 준수하도록 할 수 있습니다.
아티팩트 증명의 SLSA 수준 정보
SLSA 프레임워크는 공급망 보안을 평가하는 데 사용되는 업계 표준으로, 여러 수준으로 구성됩니다. 각 수준은 소프트웨어 공급망에 대한 보안과 신뢰성이 강화되는 정도를 나타냅니다. 아티팩트 증명은 스스로 SLSA v1.0 빌드 수준 2를 제공합니다.
이렇게 하면 아티팩트와 해당 빌드 지침 간의 링크가 제공되지만 빌드에서 알려진 검증된 빌드 지침을 사용하도록 요구하여 이 단계를 한 단계 더 발전시킬 수 있습니다. 이 작업을 수행하는 좋은 방법은 조직 전체의 많은 리포지토리가 공유하는 재사용 가능한 워크플로에서 빌드를 수행하는 것입니다. 재사용 가능한 워크플로는 SLSA v1.0 빌드 수준 3을 충족하기 위해 빌드 프로세스와 호출 워크플로 간에 격리를 제공할 수 있습니다. 자세한 내용은 "아티팩트 증명 및 재사용 가능한 워크플로를 사용하여 SLSA v1 빌드 수준 3 달성"을 참조하세요.
SLSA 수준에 대한 자세한 내용은 SLSA 보안 수준을 참조하세요.
아티팩트 증명에 Sigstore 사용 정보
아티팩트 증명을 생성하기 위해 GitHub은(는) 증명을 통해 소프트웨어 아티팩트에 서명하고 확인하기 위한 포괄적인 솔루션을 제공하는 오픈 소스 프로젝트인 Sigstore를 사용합니다.
아티팩트 증명을 생성하는 퍼블릭 리포지토리는 Sigstore Public Good Instance를 사용합니다. 생성된 Sigstore 번들의 복사본은 GitHub와 함께 저장되며 인터넷에서 공개적으로 읽을 수 있는 변경 불가능한 투명도 로그에도 기록됩니다.
아티팩트 증명을 생성하는 프라이빗 리포지토리는 GitHub의 Sigstore 인스턴스를 사용합니다. GitHub의 Sigstore 인스턴스는 Sigstore Public Good Instance와 동일한 코드베이스를 사용하지만 투명도 로그가 없으며 GitHub Actions만 페더레이션합니다.
증명할 내용
증명만 생성하면 보안 혜택이 제공되지 않으므로 증명을 확인하여 혜택을 실현해야 합니다. 서명할 항목과 빈도에 대해 생각하는 방법에 대한 몇 가지 지침은 다음과 같습니다.
다음에 서명해야 합니다.
- 사용자가
gh attestation verify ...
를 실행할 것으로 예상하는 릴리스 중인 소프트웨어. - 사용자가 실행하는 이진 파일, 사용자가 다운로드할 패키지 또는 자세한 내용의 해시가 포함된 매니페스트.
다음에 서명하지 않아야 합니다.
- 자동화된 테스트를 위한 빈번한 빌드.
- 소스 코드, 설명서 파일 또는 포함된 이미지와 같은 개별 파일.
아티팩트 증명 확인 정보
아티팩트 증명을 게시하는 소프트웨어를 사용하는 경우 GitHub CLI을(를) 사용하여 해당 증명을 확인할 수 있습니다. 증명은 소프트웨어가 빌드된 위치와 방법에 대한 정보를 제공하므로, 해당 정보를 사용하여 공급망 보안을 강화하는 보안 정책을 만들고 적용할 수 있습니다. 자세한 내용은 GitHub CLI를 사용하여 아티팩트 증명 확인을 참조하세요.
Warning
아티팩트 증명은 아티팩트가 안전하다는 보장이 아니라는 점을 기억해야 합니다. 대신, 아티팩트 증명은 소스 코드와 이를 생성한 빌드 지침에 연결해 줍니다. 소프트웨어를 사용할 때 정책 기준을 정의하고, 콘텐츠를 평가하여 해당 정책을 평가하고, 정보에 입각한 위험 결정을 내리는 것은 사용자의 몫입니다.
빌드의 아티팩트 증명 생성
GitHub Actions을(를) 사용하여 이진 파일 및 컨테이너 이미지와 같은 아티팩트에 대한 빌드 출처를 설정하는 아티팩트 증명을 생성할 수 있습니다.
아티팩트 증명을 생성하려면 다음을 수행해야 합니다.
- 워크플로에 적절한 권한이 구성되어 있는지 확인합니다.
attest-build-provenance
작업을 사용하는 단계를 워크플로에 포함합니다.
업데이트된 워크플로를 실행하면 아티팩트가 빌드되고 빌드 출처를 설정하는 아티팩트 증명이 생성됩니다. 리포지토리의 **작업 **탭에서 증명을 볼 수 있습니다. 자세한 내용은 attest-build-provenance
리포지토리를 참조하세요.
이진 파일의 빌드 출처 생성
-
증명할 이진 파일을 빌드하는 워크플로에서 다음 권한을 추가합니다.
permissions: id-token: write contents: read attestations: write
-
이진 파일이 빌드된 단계 뒤에 다음 단계를 추가합니다.
- name: Generate artifact attestation uses: actions/attest-build-provenance@v2 with: subject-path: 'PATH/TO/ARTIFACT'
subject-path
매개 변수의 값은 증명할 이진 파일 경로로 설정해야 합니다.
컨테이너 이미지의 빌드 출처 생성
-
증명할 컨테이너 이미지를 빌드하는 워크플로에서 다음 권한을 추가합니다.
permissions: id-token: write contents: read attestations: write packages: write
-
이미지가 빌드된 단계 뒤에 다음 단계를 추가합니다.
- name: Generate artifact attestation uses: actions/attest-build-provenance@v2 with: subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} subject-digest: 'sha256:fedcba0...' push-to-registry: true
subject-name
매개 변수의 값은 정규화된 이미지 이름을 지정해야 합니다. 예를 들어ghcr.io/user/app
또는acme.azurecr.io/user/app
입니다. 이미지 이름의 일부로 태그를 포함하지 마세요.subject-digest
매개 변수의 값은 증명 주체의 SHA256 요약(sha256:HEX_DIGEST
형식)으로 설정해야 합니다. 워크플로에서docker/build-push-action
을 사용하는 경우 해당 단계의digest
출력을 사용하여 값을 제공할 수 있습니다. 출력 사용에 대한 자세한 내용은 GitHub Actions에 대한 워크플로 구문을(를) 참조하세요.
SBOM(소프트웨어 자료 청구서)의 증명 생성
워크플로 아티팩트의 서명된 SBOM 증명을 생성할 수 있습니다.
SBOM의 증명을 생성하려면 다음을 수행해야 합니다.
- 워크플로에 적절한 권한이 구성되어 있는지 확인합니다.
- 아티팩트의 SBOM을 만듭니다. 자세한 내용은 GitHub Marketplace에서
anchore-sbom-action
을(를) 참조하세요. attest-sbom
작업을 사용하는 단계를 워크플로에 포함합니다.
업데이트된 워크플로를 실행하면 아티팩트가 빌드되고 SBOM 증명이 생성됩니다. 리포지토리의 작업 탭에서 증명을 볼 수 있습니다. 자세한 내용은 attest-sbom
작업 리포지토리를 참조하세요.
이진 파일의 SBOM 증명 생성
-
증명할 이진 파일을 빌드하는 워크플로에서 다음 권한을 추가합니다.
permissions: id-token: write contents: read attestations: write
-
이진 파일이 빌드된 단계 뒤에 다음 단계를 추가합니다.
- name: Generate SBOM attestation uses: actions/attest-sbom@v1 with: subject-path: 'PATH/TO/ARTIFACT' sbom-path: 'PATH/TO/SBOM'
subject-path
매개 변수의 값은 SBOM에서 설명하는 이진 파일의 경로로 설정해야 합니다.sbom-path
매개 변수의 값은 생성한 SBOM 파일의 경로로 설정해야 합니다.
컨테이너 이미지의 SBOM 증명 생성
-
증명할 컨테이너 이미지를 빌드하는 워크플로에서 다음 권한을 추가합니다.
permissions: id-token: write contents: read attestations: write packages: write
-
이미지가 빌드된 단계 뒤에 다음 단계를 추가합니다.
- name: Generate SBOM attestation uses: actions/attest-sbom@v1 with: subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE subject-digest: 'sha256:fedcba0...' sbom-path: 'sbom.json' push-to-registry: true
subject-name
매개 변수의 값은 정규화된 이미지 이름을 지정해야 합니다. 예를 들어ghcr.io/user/app
또는acme.azurecr.io/user/app
입니다. 이미지 이름의 일부로 태그를 포함하지 마세요.subject-digest
매개 변수의 값은 증명 주체의 SHA256 요약(sha256:HEX_DIGEST
형식)으로 설정해야 합니다. 워크플로에서docker/build-push-action
을 사용하는 경우 해당 단계의digest
출력을 사용하여 값을 제공할 수 있습니다. 출력 사용에 대한 자세한 내용은 GitHub Actions에 대한 워크플로 구문을(를) 참조하세요.sbom-path
매개 변수의 값은 증명할 JSON 형식의 SBOM 파일 경로로 설정해야 합니다.
GitHub CLI을(를) 사용하여 아티팩트 증명 확인
이진 파일의 아티팩트 증명을 확인하려면 다음 GitHub CLI 명령을 사용합니다.
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME
컨테이너 이미지의 아티팩트 증명을 확인하려면 이진 파일의 경로 대신 oci://
접두사가 있는 이미지의 FQDN을 제공해야 합니다. 다음 GitHub CLI 명령을 사용할 수 있습니다.
docker login ghcr.io gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME
docker login ghcr.io
gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME
Note
이러한 명령은 사용자가 온라인 환경에 있다고 가정합니다. 오프라인 또는 에어 갭 환경에 있는 경우 오프라인에서 증명 확인을(를) 참조하세요.
자세한 내용은 GitHub CLI 매뉴얼의 attestation
섹션을 참조하세요.