보안 사용 참조(Secure use reference)

워크플로를 작성하고 GitHub Actions 기능을 사용할 때 지켜야 할 보안 관행을 알려드릴게요. 스크립트 인젝션 공격이나 시크릿 노출 같은 위험을 피하는 핵심 내용이에요.

출처: 문서

본문

워크플로를 작성하고 GitHub Actions 보안 기능을 사용할 때의 보안 모범 사례에 대한 정보를 확인할 수 있습니다.

워크플로 작성하기

민감한 정보에는 시크릿 사용하기

시크릿 값이 변환될 수 있는 방법이 여러 가지이므로 자동 가림이 보장되지 않습니다. 시크릿과 관련된 위험을 제한하려면 다음 모범 사례를 따르세요.

최소 권한 원칙(Principle of least privilege)
- 저장소에 write 접근 권한이 있는 모든 사용자는 저장소에 구성된 모든 시크릿에 대한 읽기 접근 권한을 가집니다. 따라서 워크플로에서 사용되는 자격 증명이 필요한 가장 적은 권한을 가지도록 해야 합니다.
- 액션은 github.token 컨텍스트에서 접근해서 GITHUB_TOKEN을 사용할 수 있습니다. 자세한 내용은 Contexts reference를 참고하세요. 따라서 GITHUB_TOKEN에 최소한의 필요한 권한만 부여해야 합니다. GITHUB_TOKEN의 기본 권한을 저장소 콘텐츠에 대한 읽기 전용으로 설정하는 것이 좋은 보안 관행입니다. 그런 다음 워크플로 파일 내의 개별 잡에 대해 필요에 따라 권한을 높일 수 있습니다. 자세한 내용은 Use GITHUB_TOKEN for authentication in workflows을 참고하세요.
민감한 데이터 마스킹
- 민감한 데이터는 워크플로 파일에 절대 평문으로 저장하면 안 됩니다. GitHub 시크릿이 아닌 모든 민감한 정보는 ::add-mask::VALUE를 사용해서 마스킹하세요. 이렇게 하면 해당 값이 시크릿으로 취급되어 로그에서 가려집니다. 데이터 마스킹에 대한 자세한 내용은 Workflow commands for GitHub Actions를 참고하세요.
노출된 시크릿 삭제 및 회전
- 시크릿 가림은 워크플로 러너가 수행합니다. 즉 시크릿은 잡 안에서 사용되고 러너가 접근할 수 있을 때만 가려집니다. 가려지지 않은 시크릿이 워크플로 실행 로그로 보내졌다면 로그를 삭제하고 시크릿을 회전해야 합니다. 로그 삭제에 대한 정보는 Using workflow run logs를 참고하세요.
시크릿으로 구조화된 데이터를 사용하지 않기
- 구조화된 데이터는 가림이 특정 시크릿 값에 대한 정확한 일치를 찾는 데 크게 의존하기 때문에 로그 내 시크릿 가림이 실패하게 만들 수 있습니다. 예를 들어 JSON, XML, YAML(또는 유사한) blob으로 시크릿 값을 캡슐화하지 마세요. 그렇게 하면 시크릿이 제대로 가려질 확률이 크게 줄어듭니다. 대신 각 민감한 값에 대해 개별 시크릿을 만드세요.
워크플로에서 사용되는 모든 시크릿 등록하기
- 시크릿이 워크플로 내에서 다른 민감한 값을 생성하는 데 사용된다면, 그 생성된 값은 로그에 나타날 때 가려지도록 공식적으로 시크릿으로 등록되어야 합니다. 예를 들어 웹 API에 접근하기 위해 개인 키로 서명된 JWT를 생성하는 경우, 로그 출력에 들어가더라도 가려지도록 해당 JWT를 시크릿으로 등록해야 합니다.
- 시크릿 등록은 모든 종류의 변환/인코딩에도 적용됩니다. 시크릿이 어떤 식으로든(Base64나 URL 인코딩 등) 변환된다면 새 값을 시크릿으로 등록해야 합니다.
시크릿 처리 방식 감사하기
- 시크릿이 예상대로 처리되고 있는지 확인하기 위해 시크릿 사용 방식을 감사하세요. 워크플로를 실행하는 저장소의 소스 코드를 검토하고 워크플로에서 사용되는 모든 액션을 확인해서 이를 수행할 수 있습니다. 예를 들어 의도하지 않은 호스트로 전송되거나 로그 출력에 명시적으로 인쇄되지 않는지 확인하세요.
- 유효/무효 입력을 테스트한 후 워크플로의 실행 로그를 보고 시크릿이 제대로 가려졌는지, 표시되지 않는지 확인하세요. 호출하는 명령이나 도구가 오류를 STDOUT와 STDERR로 어떻게 보낼지 항상 명확하지 않으며, 시크릿이 나중에 오류 로그에 포함될 수 있습니다. 따라서 유효 및 무효 입력을 테스트한 후 워크플로 로그를 수동으로 검토하는 것이 좋습니다. 의도치 않게 민감한 데이터를 포함할 수 있는 워크플로 로그를 정리하는 방법에 대한 정보는 Using workflow run logs를 참고하세요.
등록된 시크릿 감사 및 회전
- 등록된 시크릿을 주기적으로 검토해서 여전히 필요한지 확인하세요. 더 이상 필요하지 않은 시크릿은 제거하세요.
- 손상된 시크릿이 유효한 시간 창을 줄이기 위해 시크릿을 주기적으로 회전하세요.
시크릿 접근에 대한 리뷰 요구 고려하기
- 필수 리뷰어를 사용해서 환경 시크릿을 보호할 수 있습니다. 워크플로 잡은 리뷰어가 승인할 때까지 환경 시크릿에 접근할 수 없습니다. 환경에 시크릿을 저장하거나 환경에 리뷰를 요구하는 방법에 대한 자세한 내용은 Using secrets in GitHub Actions와 Managing environments for deployment를 참고하세요.

스크립트 인젝션 공격 완화를 위한 좋은 관행

워크플로에서 스크립트 인젝션의 위험을 완화하기 위한 권장 접근 방식:

인라인 스크립트 대신 액션 사용하기

권장 접근 방식은 컨텍스트 값을 인자로 처리하는 JavaScript 액션을 만드는 것입니다. 이 접근 방식은 컨텍스트 값이 셸 스크립트를 생성하는 데 사용되지 않고 대신 액션에 인자로 전달되므로 인젝션 공격에 취약하지 않습니다:

uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}

중간 환경 변수 사용하기

인라인 스크립트의 경우 신뢰할 수 없는 입력을 처리하는 선호 방법은 표현식의 값을 중간 환경 변수로 설정하는 것입니다. 다음 예시는 Bash를 사용해서 github.event.pull_request.title 값을 환경 변수로 처리합니다:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

이 예시에서 시도된 스크립트 인젝션은 실패하며, 이는 로그의 다음 줄에 반영됩니다:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

이 접근 방식에서는 ${{ github.event.pull_request.title }} 표현식의 값이 메모리에 저장되어 변수로 사용되며 스크립트 생성 과정과 상호 작용하지 않습니다. 또한 단어 분리(word splitting)를 피하기 위해 이중 따옴표 셸 변수를 사용하는 것을 고려하세요. 하지만 이는 셸 스크립트 작성에 대한 일반적인 권장 사항 중 하나이며 GitHub Actions에만 특정된 것은 아닙니다.

코드 스캐닝용 워크플로 템플릿 사용하기

코드 스캐닝을 사용하면 보안 취약점이 프로덕션에 도달하기 전에 찾을 수 있습니다. GitHub는 코드 스캐닝용 워크플로 템플릿을 제공합니다. 처음부터 시작하는 대신 이러한 제안된 워크플로를 사용해서 코드 스캐닝 워크플로를 구성할 수 있습니다. GitHub의 워크플로인 CodeQL 분석 워크플로는 CodeQL로 구동됩니다. 제3자 워크플로 템플릿도 제공됩니다.

자세한 내용은 Code scanning과 Configuring advanced setup for code scanning을 참고하세요.

토큰의 권한 제한하기

노출된 토큰의 위험을 완화하려면 할당된 권한을 제한하는 것을 고려하세요. 자세한 내용은 Use GITHUB_TOKEN for authentication in workflows을 참고하세요.

신뢰할 수 없는 코드 체크아웃의 위험 완화하기

스크립트 인젝션 공격과 유사하게, 액션 처리를 자동으로 트리거하는 신뢰할 수 없는 풀 리퀘스트 콘텐츠도 보안 위험을 초래할 수 있습니다. pull_request_target과 workflow_run 워크플로 트리거는 신뢰할 수 없는 풀 리퀘스트의 체크아웃과 함께 사용될 때 저장소를 보안 침해에 노출시킵니다. 이러한 워크플로는 권한이 높아서 다른 권한 있는 워크플로 트리거와 같은 main 브랜치 캐시를 공유하고, 저장소 write 접근과 참조된 시크릿에 대한 접근을 가질 수 있습니다. 이러한 취약점은 저장소를 탈취하는 데 악용될 수 있습니다.

이러한 트리거, 사용 방법, 관련 위험에 대한 자세한 내용은 Events that trigger workflows와 Events that trigger workflows를 참고하세요.

신뢰할 수 없는 코드 체크아웃의 위험에 대한 추가 예시와 지침은 GitHub Security Lab의 Preventing pwn requests와 OpenSSF Scorecard의 Dangerous-Workflow 문서를 참고하세요.

pull_request_target을 사용할지 결정, 이러한 워크플로 강화, actions/checkout 보호에서 제외하는 방법에 대한 자세한 지침은 Securely using pull_request_target을 참고하세요.

좋은 관행

필요하지 않다면 pull_request_target 워크플로 트리거를 사용하지 마세요. 워크플로 간 권한 분리를 위해서는 workflow_run이 더 나은 트리거입니다. 워크플로가 실제로 권한 있는 컨텍스트를 필요로 할 때만 이러한 워크플로 트리거를 사용하세요.
pull_request_target과 workflow_run 워크플로 트리거를 신뢰할 수 없는 풀 리퀘스트나 코드 콘텐츠와 함께 사용하지 마세요. 이러한 트리거를 사용하는 워크플로는 풀 리퀘스트 포크나 사용자가 제어하지 않는 저장소를 포함한 신뢰할 수 없는 코드를 명시적으로 체크아웃하면 안 됩니다. workflow_run에서 트리거된 워크플로는 다른 워크플로에서 업로드한 아티팩트를 주의해서 취급해야 합니다.
CodeQL은 잠재적으로 취약한 GitHub Actions 워크플로를 스캔하고 감지할 수 있습니다. 저장소에 대해 기본 설정(default setup)을 구성하고 GitHub Actions 스캐닝이 활성화되어 있는지 확인할 수 있습니다. 자세한 내용은 Configuring default setup for code scanning을 참고하세요.
OpenSSF Scorecards는 GitHub Actions 사용 시 기타 보안 위험과 함께 잠재적으로 취약한 워크플로를 식별하는 데 도움이 될 수 있습니다. 이 문서의 뒷부분에 있는 Using OpenSSF Scorecards to secure workflow dependencies를 참고하세요.

제3자 액션 사용하기

워크플로의 개별 잡은 다른 잡과 상호 작용하고(손상시킬 수도) 있습니다. 예를 들어 잡이 이후 잡에서 사용하는 환경 변수를 조회하거나, 이후 잡이 처리하는 공유 디렉터리에 파일을 쓰거나, 더 직접적으로 Docker 소켓과 상호 작용해서 실행 중인 다른 컨테이너를 검사하고 그 안에서 명령을 실행할 수도 있습니다.

이는 워크플로 내의 단일 액션 손상이 매우 심각해질 수 있음을 의미합니다. 손상된 액션은 저장소에 구성된 모든 시크릿에 접근할 수 있고 GITHUB_TOKEN을 사용해서 저장소에 쓸 수도 있기 때문입니다. 결과적으로 GitHub의 제3자 저장소에서 액션을 소싱하는 데는 상당한 위험이 있습니다. 공격자가 취할 수 있는 단계 중 일부에 대한 정보는 Secure use reference를 참고하세요.

다음 좋은 관행을 따르면 이 위험을 완화할 수 있습니다:

액션을 전체 길이 커밋 SHA에 고정(pin)하기

액션을 전체 길이 커밋 SHA에 고정하는 것은 현재 액션을 불변 릴리스로 사용할 수 있는 유일한 방법입니다. 특정 SHA에 고정하면 악의적인 행위자가 액션의 저장소에 백도어를 추가하는 위험을 완화하는 데 도움이 됩니다. 유효한 Git 객체 페이로드에 대한 SHA-1 충돌을 생성해야 하기 때문입니다. SHA를 선택할 때는 액션 저장소에서 온 것인지 포크 저장소가 아닌지 확인해야 합니다.

워크플로에서 전체 길이 커밋 SHA를 사용하는 예시는 Using pre-written building blocks in your workflow를 참고하세요.

GitHub는 액션이 전체 길이 커밋 SHA에 고정되도록 요구하는 저장소 및 조직 레벨 정책을 제공합니다:
- 저장소 레벨에서 정책을 구성하려면 Managing GitHub Actions settings for a repository를 참고하세요.
- 조직 레벨에서 정책을 구성하려면 Disabling or limiting GitHub Actions for your organization을 참고하세요.
액션의 소스 코드 감사하기

액션이 저장소의 콘텐츠와 시크릿을 예상대로 처리하는지 확인하세요. 예를 들어 시크릿이 의도하지 않은 호스트로 전송되거나 실수로 기록되지 않는지 확인하세요.
작성자를 신뢰하는 경우에만 태그에 고정하기

커밋 SHA에 고정하는 것이 가장 안전한 옵션이지만, 태그를 지정하는 것이 더 편리하고 널리 사용됩니다. 태그를 지정하고 싶다면 액션의 작성자를 확실히 신뢰해야 합니다. GitHub Marketplace의 'Verified creator' 배지는 유용한 신호인데, 액션이 GitHub가 신원을 검증한 팀에 의해 작성되었음을 나타내기 때문입니다. 작성자를 신뢰하더라도 이 접근 방식에는 위험이 있습니다. 악의적인 행위자가 액션을 저장하는 저장소에 접근하면 태그를 이동하거나 삭제할 수 있기 때문입니다.

제3자 워크플로 재사용하기

제3자 액션 사용에 대해 위에서 설명한 것과 동일한 원칙이 제3자 워크플로 사용에도 적용됩니다. 위에서 설명한 것과 동일한 좋은 관행을 따르면 워크플로를 재사용할 때 발생하는 위험을 완화할 수 있습니다. 자세한 내용은 Reuse workflows를 참고하세요.

GitHub의 보안 기능

GitHub는 코드를 더 안전하게 만들기 위한 많은 기능을 제공합니다. GitHub의 내장 기능을 사용해서 워크플로가 의존하는 액션을 이해하고, 사용하는 액션의 취약점에 대한 알림을 받고, 워크플로의 액션을 최신 상태로 유지하는 과정을 자동화할 수 있습니다. 액션을 게시하고 유지 관리한다면 GitHub를 사용해서 커뮤니티와 취약점 및 해결 방법에 대해 소통할 수 있습니다. GitHub가 제공하는 보안 기능에 대한 자세한 내용은 GitHub security features를 참고하세요.

`CODEOWNERS`를 사용해서 변경 사항 모니터링하기

CODEOWNERS 기능을 사용해서 워크플로 파일에 대한 변경이 이루어지는 방식을 제어할 수 있습니다. 예를 들어 모든 워크플로 파일이 .github/workflows에 저장되어 있다면 이 디렉터리를 코드 소유자 목록에 추가해서, 이 파일들에 대한 제안된 변경이 먼저 지정된 리뷰어의 승인을 받도록 할 수 있습니다.

자세한 내용은 About code owners를 참고하세요.

OpenID Connect를 사용해서 클라우드 리소스에 접근하기

GitHub Actions 워크플로가 OpenID Connect(OIDC)를 지원하는 클라우드 공급자의 리소스에 접근해야 한다면, 워크플로가 클라우드 공급자에 직접 인증하도록 구성할 수 있습니다. 이렇게 하면 이러한 자격 증명을 장기 유효 시크릿으로 저장하지 않아도 되고 다른 보안상 이점도 얻을 수 있습니다. 자세한 내용은 OpenID Connect를 참고하세요.

[!NOTE] OIDC에 대한 사용자 지정 클레임 지원은 AWS에서 사용할 수 없습니다.

Dependabot 버전 업데이트를 사용해서 액션을 최신 상태로 유지하기

Dependabot을 사용해서 저장소에서 사용되는 액션과 재사용 가능한 워크플로에 대한 참조를 최신 상태로 유지할 수 있습니다. 액션은 자동화 과정을 더 빠르고, 안전하고, 더 신뢰할 수 있게 만드는 버그 수정과 새 기능으로 자주 업데이트됩니다. Dependabot은 의존성 유지 관리를 자동으로 처리하므로 수고를 덜어줍니다. 자세한 내용은 Keeping your actions up to date with Dependabot과 Dependabot security updates을 참고하세요.

GitHub Actions가 풀 리퀘스트를 만들거나 승인하지 못하도록 방지하기

GitHub Actions 워크플로가 풀 리퀘스트를 만들거나 승인하도록 허용할지 방지할지 선택할 수 있습니다. 적절한 감독 없이 풀 리퀘스트가 머지된다면 워크플로나 다른 자동화가 풀 리퀘스트를 만들거나 승인하도록 허용하는 것은 보안 위험이 될 수 있습니다.

이 설정을 구성하는 방법에 대한 자세한 내용은 Disabling or limiting GitHub Actions for your organization과 Managing GitHub Actions settings for a repository을 참고하세요.

코드 스캐닝을 사용해서 워크플로 보호하기

코드 스캐닝은 GitHub Actions 워크플로에서 사용되는 일반적인 취약 패턴을 자동으로 감지하고 개선 사항을 제안할 수 있습니다. 코드 스캐닝을 활성화하는 방법에 대한 자세한 내용은 Configuring default setup for code scanning을 참고하세요.

OpenSSF Scorecards를 사용해서 워크플로 의존성 보호하기

Scorecards는 위험한 공급망 관행을 표시하는 자동화된 보안 도구입니다. Scorecards 액션과 워크플로 템플릿을 사용해서 모범 보안 관행을 따를 수 있습니다. 구성되면 Scorecards 액션이 저장소 변경 시 자동으로 실행되고 내장된 코드 스캐닝 경험을 사용해서 개발자에게 위험한 공급망 관행에 대해 경고합니다. Scorecards 프로젝트는 스크립트 인젝션 공격, 토큰 권한, 액션 고정을 포함한 여러 검사를 실행합니다.

GitHub 호스팅 러너 강화

GitHub 호스팅 러너는 보안 위험을 완화하는 데 도움이 되는 조치를 취합니다.

GitHub 호스팅 러너의 공급망 검토

GitHub가 유지 관리하는 이미지에서 생성된 GitHub 호스팅 러너의 경우 소프트웨어 판매 목록(SBOM)을 볼 수 있습니다. 사용자에게 SBOM을 제공하고 이를 취약점 스캐너로 실행해서 제품에 취약점이 있는지 확인할 수 있습니다. 아티팩트를 빌드한다면 소프트웨어를 만드는 데 들어간 모든 것을 포괄적으로 나열하기 위해 이 SBOM을 판매 목록에 포함할 수 있습니다.

SBOM은 GitHub가 유지 관리하는 Ubuntu, Windows, macOS 러너 이미지(ARM 지원 러너 포함)에 사용할 수 있습니다. 빌드용 SBOM은 릴리스 자산의 https://github.com/actions/runner-images/releases에서 찾을 수 있습니다. sbom.IMAGE-NAME.json.zip 형식의 파일 이름을 가진 SBOM은 각 릴리스의 첨부 파일에서 찾을 수 있습니다.

호스트 접근 거부

GitHub 호스팅 러너는 다양한 암호화폐 채굴 풀과 악성 사이트에 대한 네트워크 접근을 차단하는 etc/hosts 파일로 프로비저닝됩니다. MiningMadness.com과 cpu-pool.com 같은 호스트는 심각한 보안 위험이 되지 않도록 localhost로 리라우팅됩니다. 자세한 내용은 GitHub-hosted runners를 참고하세요.

셀프 호스팅 러너 강화

GitHub 호스팅 러너는 임시적이고 깨끗한 격리된 가상 머신 안에서 코드를 실행합니다. 즉 이 환경을 지속적으로 손상시키거나 부트스트랩 과정에서 이 환경에 배치된 것보다 더 많은 정보에 접근할 방법이 없습니다.

GitHub용 셀프 호스팅 러너는 임시적이고 깨끗한 가상 머신에서 실행된다는 보장이 없으며, 워크플로의 신뢰할 수 없는 코드에 의해 지속적으로 손상될 수 있습니다.

결과적으로 셀프 호스팅 러너는 GitHub의 공개 저장소에는 거의 사용해서는 안 됩니다. 누구나 저장소에 대해 풀 리퀘스트를 열고 환경을 손상시킬 수 있기 때문입니다. 마찬가지로 비공개 또는 내부 저장소에서 셀프 호스팅 러너를 사용할 때는 주의해야 합니다. 저장소를 포크하고 풀 리퀘스트를 열 수 있는 사람(일반적으로 저장소에 대한 읽기 접근 권한이 있는 사람)은 셀프 호스팅 러너 환경을 손상시킬 수 있으며, 시크릿과 설정에 따라 저장소에 write 접근 권한을 부여할 수 있는 GITHUB_TOKEN에 접근할 수 있습니다. 워크플로가 환경과 필수 리뷰를 사용해서 환경 시크릿에 대한 접근을 제어할 수 있지만, 이러한 워크플로는 격리된 환경에서 실행되지 않으며 셀프 호스팅 러너에서 실행될 때 여전히 동일한 위험에 노출됩니다.

조직 소유자는 저장소 레벨 셀프 호스팅 러너를 만들 수 있는 저장소를 선택할 수 있습니다.

자세한 내용은 Disabling or limiting GitHub Actions for your organization을 참고하세요.

셀프 호스팅 러너가 조직이나 엔터프라이즈 레벨에서 정의되면 GitHub는 여러 저장소의 워크플로를 같은 러너에 예약할 수 있습니다. 결과적으로 이러한 환경의 보안 침해는 광범위한 영향을 미칠 수 있습니다. 손상 범위를 줄이기 위해 셀프 호스팅 러너를 별도의 그룹으로 구성해서 경계를 만들 수 있습니다. 어떤 조직과 저장소가 러너 그룹에 접근할 수 있는지 제한할 수 있습니다. 자세한 내용은 Managing access to self-hosted runners using groups를 참고하세요.

또한 셀프 호스팅 러너 머신의 환경을 고려해야 합니다:

셀프 호스팅 러너로 구성된 머신에는 어떤 민감한 정보가 있습니까? 예를 들어 비공개 SSH 키, API 액세스 토큰 등이 있습니다.
머신이 민감한 서비스에 네트워크 접근 권한이 있습니까? 예를 들어 Azure나 AWS 메타데이터 서비스가 있습니다. 이 환경의 민감한 정보 양은 최소한으로 유지해야 하며, 워크플로를 호출할 수 있는 모든 사용자가 이 환경에 접근할 수 있음을 항상 유의해야 합니다.

일부 고객은 각 잡 실행 후 셀프 호스팅 러너를 자동으로 파괴하는 시스템을 구현해서 이러한 위험을 부분적으로 완화하려고 시도할 수 있습니다. 그러나 셀프 호스팅 러너가 잡 하나만 실행한다는 보장이 없으므로 이 접근 방식은 의도한 것만큼 효과적이지 않을 수 있습니다. 일부 잡은 같은 러너에서 실행되는 다른 잡이 ps x -w 같은 커맨드로 볼 수 있는 명령줄 인자로 시크릿을 사용합니다. 이는 시크릿 유출로 이어질 수 있습니다.

just-in-time 러너 사용하기

러너 등록 보안을 개선하려면 REST API를 사용해서 임시 just-in-time(JIT) 러너를 만들 수 있습니다. 이 셀프 호스팅 러너는 최대 하나의 잡을 수행한 후 저장소, 조직, 엔터프라이즈에서 자동으로 제거됩니다. JIT 러너 구성에 대한 자세한 내용은 REST API endpoints for self-hosted runners를 참고하세요.

[!NOTE] JIT 러너를 호스팅하기 위해 하드웨어를 재사용하면 환경의 정보가 노출될 위험이 있습니다. 자동화를 사용해서 JIT 러너가 깨끗한 환경을 사용하도록 하세요. 자세한 내용은 Self-hosted runners reference를 참고하세요.

REST API 응답에서 구성 파일을 얻으면 시작 시 러너에 전달할 수 있습니다.

./run.sh --jitconfig ${encoded_jit_config}

셀프 호스팅 러너 관리 전략 계획하기

셀프 호스팅 러너는 GitHub 계층의 다양한 레벨(엔터프라이즈, 조직, 저장소 레벨)에 추가할 수 있습니다. 이 배치 위치에 따라 러너를 관리할 수 있는 사람이 결정됩니다:

중앙 집중식 관리:

중앙 팀이 셀프 호스팅 러너를 소유할 계획이라면 최상위 공통 조직이나 엔터프라이즈 레벨에 러너를 추가하는 것이 좋습니다. 이렇게 하면 팀이 러너를 보고 관리할 수 있는 단일 위치를 얻을 수 있습니다.
조직이 하나뿐이라면 조직 레벨에 러너를 추가하는 것은 사실상 같은 접근 방식이지만, 나중에 조직을 추가하면 어려움을 겪을 수 있습니다.

분산 관리:

각 팀이 자신의 셀프 호스팅 러너를 관리할 것이라면 팀 소유권의 최상위 레벨에 러너를 추가하는 것이 좋습니다. 예를 들어 각 팀이 자신의 조직을 소유한다면 러너도 조직 레벨에 추가하는 것이 가장 간단합니다.
저장소 레벨에 러너를 추가할 수도 있지만, 저장소 간에 러너를 공유할 수 없기 때문에 관리 오버헤드가 추가되고 필요한 러너 수가 늘어납니다.

클라우드 공급자에 인증하기

GitHub Actions를 사용해서 클라우드 공급자에 배포하거나 HashiCorp Vault를 시크릿 관리에 사용할 계획이라면, OpenID Connect를 사용해서 워크플로 실행을 위한 단기 유효하고 잘 스코프된 액세스 토큰을 만드는 것을 고려하는 것이 좋습니다. 자세한 내용은 OpenID Connect를 참고하세요.

GitHub Actions 이벤트 감사하기

보안 로그를 사용해서 사용자 계정의 활동을 모니터링하고 감사 로그를 사용해서 조직의 활동을 모니터링할 수 있습니다. 보안 및 감사 로그는 작업 유형, 실행 시점, 작업을 수행한 개인 계정을 기록합니다.

예를 들어 감사 로그를 사용해서 조직 시크릿의 변경을 추적하는 org.update_actions_secret 이벤트를 추적할 수 있습니다.

Screenshot showing a search for "action:org.update_actions_secret" in the audit log for an organization. Two results are shown.

각 계정 유형에 대해 감사 로그에서 찾을 수 있는 전체 이벤트 목록은 다음 문서를 참고하세요:

워크플로의 의존성 이해하기

의존성 그래프를 사용해서 저장소의 워크플로가 사용하는 액션을 탐색할 수 있습니다. 의존성 그래프는 저장소에 저장된 매니페스트 및 잠금 파일의 요약입니다. 또한 ./github/workflows/의 파일을 매니페스트로 인식하므로, jobs[*].steps[*].uses나 jobs.<job_id>.uses 구문으로 참조되는 모든 액션 또는 워크플로가 의존성으로 파싱됩니다.

의존성 그래프는 워크플로에서 사용되는 액션에 대해 다음 정보를 보여줍니다:

액션을 소유한 계정 또는 조직.
액션을 참조하는 워크플로 파일.
액션이 고정된 버전 또는 SHA.

의존성 그래프에서 의존성은 취약점 심각도에 따라 자동으로 정렬됩니다. 사용하는 액션 중 보안 권고(advisory)가 있는 것이 있다면 목록 맨 위에 표시됩니다. 의존성 그래프에서 권고로 이동해서 취약점 해결 지침에 접근할 수 있습니다.

의존성 그래프는 공개 저장소에서 활성화되며, 비공개 저장소에서는 활성화하도록 선택할 수 있습니다. 의존성 그래프 사용에 대한 자세한 내용은 Exploring the dependencies of a repository를 참고하세요.

사용하는 액션의 보안 취약점 인지하기

마켓플레이스에서 사용할 수 있는 액션의 경우 GitHub는 관련 보안 권고를 검토한 다음 해당 권고를 GitHub Advisory Database에 추가합니다. 데이터베이스에서 사용하는 액션을 검색해서 기존 취약점에 대한 정보와 해결 방법을 찾을 수 있습니다. 검색을 간소화하려면 GitHub Advisory Database에서 GitHub Actions 필터를 사용하세요.

다음을 할 수 있도록 저장소를 설정할 수 있습니다:

워크플로에서 사용되는 액션이 취약점 보고를 받으면 알림을 받습니다. 자세한 내용은 Monitoring the actions in your workflows를 참고하세요.
워크플로에서 액션을 추가하거나 업데이트할 때 기존 권고에 대해 경고를 받습니다. 자세한 내용은 Screening actions for vulnerabilities in new or updated workflows를 참고하세요.

워크플로의 액션 모니터링하기

Dependabot을 사용해서 워크플로의 액션을 모니터링하고, 사용하는 액션에 보고된 취약점이 있을 때 알려주도록 Dependabot 알림을 활성화할 수 있습니다. Dependabot은 활성화된 저장소의 기본 브랜치를 스캔해서 안전하지 않은 의존성을 감지합니다. GitHub Advisory Database에 새 권고가 추가되거나 사용하는 액션이 업데이트되면 Dependabot은 Dependabot 알림을 생성합니다.

[!NOTE] Dependabot은 시맨틱 버저닝을 사용하는 취약한 액션에 대해서만 알림을 만들며 SHA 값에 고정된 액션에 대해서는 알림을 만들지 않습니다.

개인 계정, 저장소, 조직에 대해 Dependabot 알림을 활성화할 수 있습니다. 자세한 내용은 Configuring Dependabot alerts를 참고하세요.

저장소의 Dependabot 탭에서 열린 및 닫힌 모든 Dependabot 알림과 해당 Dependabot 보안 업데이트를 볼 수 있습니다. 자세한 내용은 Viewing and updating Dependabot alerts를 참고하세요.

새 또는 업데이트된 워크플로에서 취약점 액션 선별하기

워크플로를 업데이트하기 위해 풀 리퀘스트를 열 때는 의존성 리뷰(dependency review)를 사용해서 사용하는 액션에 대한 변경 사항의 보안 영향을 이해하는 것이 좋습니다. 의존성 리뷰는 모든 풀 리퀘스트에서 의존성 변경 사항과 이러한 변경의 보안 영향을 이해하는 데 도움이 됩니다. 풀 리퀘스트의 "Files Changed" 탭에서 풍부한 diff와 함께 의존성 변경 사항을 쉽게 이해할 수 있는 시각화를 제공합니다. 의존성 리뷰는 다음과 같은 정보를 알려줍니다:

릴리스 날짜와 함께 추가, 제거, 업데이트된 의존성
이러한 구성 요소를 사용하는 프로젝트 수
이러한 의존성에 대한 취약점 데이터

워크플로에 대한 변경 사항 중 취약한 것으로 표시된 것이 있다면 프로젝트에 추가하지 않거나 안전한 버전으로 업데이트할 수 있습니다.

의존성 리뷰에 대한 자세한 내용은 Dependency review를 참고하세요.

"dependency review action"은 GitHub Actions 컨텍스트 내에서 풀 리퀘스트의 차이를 보고할 수 있는 특정 액션을 말합니다. dependency-review-action을 참고하세요. 저장소에서 의존성 리뷰 액션을 사용해서 풀 리퀘스트에 대한 의존성 리뷰를 강제할 수 있습니다. 이 액션은 풀 리퀘스트의 패키지 버전 변경으로 도입된 의존성의 취약한 버전을 스캔하고 관련 보안 취약점에 대해 경고합니다. 이는 풀 리퀘스트에서 무엇이 변경되고 있는지 더 잘 파악하게 해주고 취약점이 저장소에 추가되는 것을 방지하는 데 도움이 됩니다. 자세한 내용은 Dependency review를 참고하세요.

워크플로의 액션을 안전하고 최신 상태로 유지하기

다음 기능은 워크플로의 액션을 자동으로 업데이트할 수 있습니다.

Dependabot 버전 업데이트는 새 버전이 릴리스될 때 액션을 최신 버전으로 업데이트하는 풀 리퀘스트를 엽니다.
Dependabot 보안 업데이트는 보고된 취약점이 있는 액션을 최소 패치 버전으로 업데이트하는 풀 리퀘스트를 엽니다.

[!NOTE]

Dependabot은 actions/checkout@v6나 actions/checkout@<commit> 같은 GitHub 저장소 구문을 사용하는 GitHub Actions 업데이트만 지원합니다. Dependabot은 로컬로 참조되는 액션이나 재사용 가능한 워크플로(예: ./.github/actions/foo.yml)는 무시합니다.

Dependabot은 주석이 같은 줄에 있을 때 GitHub Actions의 버전 문서를 업데이트합니다. 예: actions/checkout@<commit> #<tag or link> 또는 actions/checkout@<tag> #<tag or link>.

사용하는 커밋이 어떤 태그와도 연결되어 있지 않으면 Dependabot은 GitHub Actions를 최신 커밋(최신 릴리스와 다를 수 있음)으로 업데이트합니다.

Docker Hub와 GitHub Packages Container registry URL은 현재 지원되지 않습니다. 예를 들어 docker:// 구문을 사용하는 Docker 컨테이너 액션 참조는 지원되지 않습니다.

Dependabot은 GitHub Actions에 대해 공개 및 비공개 저장소를 모두 지원합니다. 비공개 레지스트리 구성 옵션은 Configuring access to private registries for Dependabot에서 "git"을 참고하세요.

Dependabot 버전 업데이트 구성 방법에 대한 정보는 Configuring Dependabot version updates를 참고하세요.

Dependabot 보안 업데이트 구성 방법에 대한 정보는 Configuring Dependabot security updates를 참고하세요.

만든 액션 보호하기

GitHub는 안전한 코딩을 촉진하기 위해 액션을 게시·유지 관리하는 사람과 취약점 신고자 사이의 협업을 가능하게 합니다. 저장소 보안 권고를 사용하면 공개 저장소의 관리자가 프로젝트의 보안 취약점을 비공개로 논의하고 수정할 수 있습니다. 수정에 대해 협업한 후 저장소 관리자는 보안 권고를 게시해서 프로젝트 커뮤니티에 보안 취약점을 공개할 수 있습니다. 보안 권고를 게시함으로써 저장소 관리자는 커뮤니티가 패키지 의존성을 업데이트하고 보안 취약점의 영향을 조사하기 쉽게 만듭니다.

다른 프로젝트에서 사용되는 액션을 유지 관리하는 사람이라면 다음 GitHub 기능을 사용해서 게시한 액션의 보안을 강화할 수 있습니다.

의존성 그래프의 dependants 보기를 사용해서 코드에 의존하는 프로젝트를 확인하세요. 취약점 보고를 받으면 누구와 취약점 및 해결 방법에 대해 소통해야 하는지 파악하는 데 도움이 됩니다. 자세한 내용은 Exploring the dependencies of a repository를 참고하세요.
저장소 보안 권고를 사용해서 보안 권고를 만들고, 임시 비공개 포크에서 취약점을 수정하기 위해 비공개로 협업하고, 패치가 릴리스되면 커뮤니티에 취약점을 알리기 위해 보안 권고를 게시하세요. 자세한 내용은 Configuring private vulnerability reporting for a repository와 Creating a repository security advisory를 참고하세요.

보안 사용 참조(Secure use reference)