안전 사용 참조

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

워크플로 작성

중요한 정보에 비밀 사용

비밀 값을 변환할 수 있는 여러 가지 방법이 있기 때문에 자동 수정이 보장되지는 않습니다. 비밀과 관련된 위험을 제한하려면 다음 모범 사례를 준수합니다.

• 최소 권한 원칙
  • 리포지토리에 대한 쓰기 권한이 있는 모든 사용자는 리포지토리에 구성된 모든 비밀에 대한 읽기 권한을 갖습니다. 따라서 워크플로 내에서 사용되는 자격 증명에 필요한 최소 권한이 있는지 확인해야 합니다.
  • 작업은 GITHUB_TOKEN 컨텍스트에서 github.token에 액세스하여 사용할 수 있습니다. 자세한 내용은 문맥 참조을(를) 참조하세요. 따라서 GITHUB_TOKEN에 필요한 최소 사용 권한이 부여되었는지 확인해야 합니다. GITHUB_TOKEN에 리포지토리 콘텐츠에 대해서만 읽기 액세스를 갖는 기본 권한을 설정하는 것이 좋습니다. 그런 다음 필요에 따라 워크플로 파일 내의 개별 작업에 대한 권한을 늘릴 수 있습니다. 자세한 내용은 워크플로에서 인증에 GITHUB_TOKEN 사용을(를) 참조하세요.
• 예민한 데이터를 마스킹하다
  • 중요한 데이터는 워크플로 파일에 일반 텍스트로 저장해서는 안 됩니다. 를 사용하여 GitHub비밀이 아닌 ::add-mask::VALUE 모든 중요한 정보를 마스킹합니다. 이렇게 하면 값이 비밀로 처리되고 로그에서 수정됩니다. 데이터 마스킹에 대한 자세한 내용은 GitHub Actions에 대한 워크플로 명령을(를) 참조하세요.
• 노출된 비밀 삭제 및 순환
  • 비밀 값의 편집은 워크플로 러너에서 수행됩니다. 즉, 비밀은 작업 내에서 사용되고 실행기에서 액세스할 수 있는 경우에만 수정됩니다. 수정되지 않은 비밀이 워크플로 실행 로그로 전송되는 경우 로그를 삭제하고 비밀을 회전해야 합니다. 로그 삭제에 대한 정보는 워크플로 실행 로그 사용을(를) 참조하세요.
• 정형 데이터를 비밀로 사용하지 마세요.
  • 정형 데이터로 인해 로그 내에서 비밀 편집이 실패할 수 있습니다. 편집은 주로 특정 비밀 값에 대한 정확한 일치 항목을 찾는 데 의존하기 때문입니다. BLOB예를 들어 JSON, XML 또는 YAML(또는 이와 유사한) BLOB을 사용하여 비밀 값을 캡슐화하지 마세요. 이렇게 하면 비밀이 제대로 수정될 확률이 크게 줄어듭니다. 대신 각 중요한 값에 대한 개별 비밀을 만듭니다.
• 워크플로 내에서 사용되는 모든 비밀 등록
  • 워크플로 내에서 다른 중요한 값을 생성하는 데 비밀을 사용하는 경우 생성된 값은 로그에 표시되는 경우 수정되도록 공식적으로 비밀로 등록되어야 합니다. 예를 들어 프라이빗 키를 사용하여 서명된 JWT를 생성하여 웹 API에 액세스하는 경우 해당 JWT를 비밀로 등록해야 합니다. 그렇지 않으면 로그 출력에 들어가면 수정되지 않습니다.
  • 비밀 등록은 모든 종류의 변환/인코딩에도 적용됩니다. 비밀이 어떤 방식으로든 변환되는 경우(예시: Base64 또는 URL 인코딩) 새 값도 비밀로 등록해야 합니다.
• 비밀 처리 방식 감사
  • 비밀이 예상대로 처리되고 있는지 확인하기 위해 비밀 사용 방식을 감사하십시오. 워크플로를 실행하는 리포지토리의 소스 코드를 검토하고 워크플로에 사용된 작업을 확인하여 이 작업을 수행할 수 있습니다. 예를 들어 의도하지 않은 호스트로 보내지거나 로그 출력에 명시적으로 인쇄되지 않는지 확인합니다.
  • 유효한 입력 및 유효하지 않은 입력을 테스트한 후 워크플로에 대한 실행 로그를 보고 비밀이 제대로 수정되었거나 표시되지 않는지 확인합니다. 호출하는 명령이나 도구가 STDOUT 및 STDERR로 오류를 전송하는 방법이 항상 분명하지 않으며, 그 결과 비밀이 오류 로그에 기록될 수 있습니다. 따라서 유효한 입력 및 유효하지 않은 입력을 테스트한 후 워크플로 로그를 수동으로 검토하는 것이 좋습니다. 의도치 않게 중요한 데이터를 포함할 수 있는 워크플로 로그를 정리하는 방법에 대한 자세한 내용은 워크플로 실행 로그 사용을(를) 참조하세요.
• 등록된 비밀 감사 및 교체
  • 등록된 비밀을 주기적으로 검토하여 여전히 필요한지 확인합니다. 더 이상 필요하지 않은 것은 제거합니다.
  • 비밀을 주기적으로 회전하여 손상된 비밀이 유효한 기간을 줄입니다.
• 비밀 액세스에 대한 검토 요구 고려
  • 필요한 검토자를 사용하여 환경 비밀을 보호할 수 있습니다. 즉, 검토자가 승인할 때까지 워크플로 작업이 환경 비밀에 액세스할 수 없습니다. 환경에 비밀을 저장하거나 환경에 대한 검토를 요구하는 방법에 대한 자세한 내용은 GitHub Actions에서 비밀 사용 and 배포 환경 관리을(를) 참조하세요.

스크립트 삽입 공격을 완화하기 위한 모범 사례

워크플로에서 스크립트 삽입의 위험을 완화하기 위한 권장 방법은 다음과 같습니다.

인라인 스크립트 대신 작업 사용

컨텍스트 값을 인수로 처리하는 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 }} 이 메모리에 저장되고 변수로 사용되며 스크립트 생성 프로세스와 상호 작용하지 않습니다. 또한 단어 분할을 방지하기 위해 큰따옴표 셸 변수를 사용하는 것이 좋지만 이는 셸 스크립트를 작성하기 위한 많은 일반적인 권장 사항 GitHub Actions 관련이 없습니다.

토큰에 대한 권한 제한

노출된 토큰의 위험을 완화하려면 할당된 권한을 제한하는 것이 좋습니다. 자세한 내용은 워크플로에서 인증에 GITHUB_TOKEN 사용을(를) 참조하세요.

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

스크립트 삽입 공격과 마찬가지로 작업 처리를 자동으로 트리거하는 신뢰할 수 없는 끌어오기 요청 콘텐츠도 보안 위험을 초래할 수 있습니다. pull_request_target 및 workflow_run 워크플로 트리거는 신뢰할 수 없는 끌어오기 요청의 체크 아웃과 함께 사용될 때 리포지토리를 보안 위협에 노출시킬 수 있습니다. 이러한 워크플로에는 권한이 부여되어 있습니다. 이는 다른 권한이 있는 워크플로 트리거와 메인 분기의 동일한 캐시를 공유하고, 리포지토리 쓰기 권한과 참조된 비밀에 대한 액세스 권한을 가질 수 있음을 의미합니다. 이러한 취약성은 리포지토리를 장악하는 데 악용될 수 있습니다.

이러한 트리거에 대한 더 많은 정보, 사용 방법, 그리고 관련된 위험에 대해서는 워크플로를 트리거하는 이벤트 및 워크플로를 트리거하는 이벤트을(를) 참조하세요.

신뢰할 수 없는 코드 체크 아웃의 위험에 대한 추가 예제 및 지침은 Pwn 요청GitHub Security Lab 방지 및 OpenSSF 성과 기록표의 위험한 워크플로 설명서를 참조하세요.

모범 사례

• 필요하지 않은 경우에는 pull_request_target 워크플로 트리거 사용을 피하세요. 워크플로 간의 권한 분리를 위해서는 workflow_run이 더 나은 트리거입니다. 워크플로에 실제로 권한 있는 컨텍스트가 필요한 경우에만 이러한 워크플로 트리거를 사용합니다.

• 신뢰할 수 없는 끌어오기 요청 또는 코드 콘텐츠에서는 pull_request_target 및 workflow_run 워크플로 트리거 사용을 피하세요. 이러한 트리거를 사용하는 워크플로는 끌어오기 요청 포크 또는 사용자가 제어하지 않는 리포지토리에서 가져온 것을 포함하여 신뢰할 수 없는 코드를 명시적으로 체크 아웃해서는 안 됩니다. workflow_run에서 트리거된 워크플로는 다른 워크플로에서 업로드된 아티팩트를 주의해서 처리해야 합니다.

• CodeQL는 잠재적으로 취약할 수 있는 GitHub Actions 워크플로우를 검사하고 탐지할 수 있습니다. 리포지토리의 기본 설정을 구성하고 GitHub Actions 스캔이 사용 설정되어 있는지 확인할 수 있습니다. 자세한 내용은 코드 검사에 대한 기본 설정 구성을(를) 참조하세요.

• OpenSSF 성과 기록표를 사용하면 잠재적으로 취약한 워크플로를 식별하고 사용할 GitHub Actions때 다른 보안 위험을 식별할 수 있습니다. 이 문서의 뒷부분에서 OpenSSF Scorecards를 사용하여 워크플로 종속성 보호를 참조하세요.

타사 작업 사용

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

즉, 손상된 작업이 리포지토리에 구성된 모든 비밀에 액세스할 수 있고 리포지토리에 쓰는 데 GITHUB_TOKEN을 사용할 수 있기 때문에 워크플로 내에서 단일 작업의 손상이 매우 중요할 수 있습니다. 따라서 타사 리포지토리에서 작업을 소싱하는 데 상당한 위험이 있습니다 GitHub. 공격자가 수행할 수 있는 몇 가지 단계에 대한 자세한 내용은 안전 사용 참조을(를) 참조하세요.

다음 모범 사례를 따라하여 이 위험을 완화할 수 있습니다.

• 작업을 전체 커밋 SHA에 고정

  작업을 전체 길이 커밋 SHA에 고정하는 것은 현재 변경할 수 없는 릴리스로 작업을 사용하는 유일한 방법입니다. 특정 SHA에 고정하면 유효한 Git 개체 페이로드에 대한 SHA-1 충돌을 생성해야 하므로 잘못된 행위자가 작업 리포지토리에 백도어를 추가하는 위험을 완화할 수 있습니다. SHA를 선택할 때는 해당 SHA가 리포지토리 포크가 아닌 작업의 리포지토리에서 온 것인지 확인해야 합니다.

  워크플로에서 전체 길이 커밋 SHA를 사용하는 예는 워크플로에서 미리 작성된 구성 요소 사용을(를) 참조하세요.

GitHub는 리포지토리, 조직 및 엔터프라이즈 수준의 정책을 제공하여 액션을 전체 길이의 커밋 SHA에 고정하도록 요구합니다. * 리포지토리 수준에서 정책을 구성하려면 리포지토리에 대한 GitHub Actions 설정 관리을(를) 참조하세요. * 조직 수준에서 정책을 구성하려면 조직에 대한 GitHub Actions 사용하지 않도록 설정 또는 제한을(를) 참조하세요. * 엔터프라이즈 수준에서 정책을 구성하려면 엔터프라이즈에서 GitHub Actions 대한 정책 적용을(를) 참조하세요.

• 작업의 소스 코드 감사

  작업이 리포지토리의 콘텐츠 및 비밀을 예상대로 처리하는지 확인합니다. 예를 들어 비밀이 의도하지 않은 호스트로 전송되거나 실수로 기록되지 않는지 확인합니다.

• 작성자를 신뢰하는 경우에만 태그에 작업 고정

  커밋 SHA에 고정하는 것이 가장 안전한 옵션이지만 태그를 지정하는 것이 더 편리하며 널리 사용됩니다. 태그를 지정하려면 작업의 작성자를 신뢰해야 합니다. '확인된 작성자' 배지 GitHub Marketplace 는 ID가 확인된 GitHub팀에서 작업을 작성했음을 나타내는 유용한 신호입니다. 잘못된 행위자가 작업을 저장하는 리포지토리에 대한 액세스 권한을 얻게 되면 태그를 이동하거나 삭제할 수 있으므로 작성자를 신뢰하더라도 이 접근 방식에는 위험이 있습니다.

타사 워크플로 다시 사용

타사 작업 사용에 대해 위에서 설명한 것과 동일한 원칙이 타사 워크플로 사용에도 적용됩니다. 위에서 설명한 것과 동일한 모범 사례를 따라하여 워크플로 재사용과 관련된 위험을 완화할 수 있습니다. 자세한 내용은 워크플로 재사용을(를) 참조하세요.

GitHub'의 보안 기능

GitHub 에서는 코드를 보다 안전하게 만들 수 있는 많은 기능을 제공합니다. 기본 제공 기능을 사용하여 GitHub워크플로가 의존하는 작업을 이해하거나, 사용하는 작업의 취약성에 대한 알림을 받거나, 워크플로의 작업을 최신 상태로 유지하는 프로세스를 자동화할 수 있습니다. 작업을 게시하고 유지 관리하는 경우 취약성 및 해결 방법에 대해 커뮤니티와 통신하는 데 사용할 GitHub 수 있습니다. 제공하는 보안 기능에 GitHub 대한 자세한 내용은 GitHub 보안 기능을 참조하세요.

변경 내용을 모니터링하는 데 CODEOWNERS 사용

CODEOWNERS 기능을 사용하여 워크플로 파일을 변경하는 방법을 제어할 수 있습니다. 예를 들어 .github/workflows에 모든 워크플로 파일이 저장되어 있는 경우 이 디렉터리를 코드 소유자 목록에 추가할 수 있으므로 해당 파일에 대한 제안된 변경 내용은 먼저 지정된 검토자의 승인이 필요합니다.

자세한 내용은 코드 소유자 정보을(를) 참조하세요.

조직의 GitHub Actions 설정에 대한 권한 관리

사용자 지정 조직 역할을 관리하여 조직의 CI/CD 파이프라인 GitHub Actions 에 대한 최소 권한 원칙을 연습할 수 있습니다. 사용자 지정 조직 역할은 조직의 개인 또는 팀에 조직 및 해당 리포지토리에 대한 전체 관리 제어 권한을 부여하지 않고 특정 설정의 하위 집합을 제어할 수 있는 권한을 부여하는 방법입니다.

GitHub Actions의 경우 조직의 개인 또는 팀에 대해 다음 사용 권한을 사용하도록 설정할 수 있습니다.

• 조직 Actions 정책 관리: 자체 호스트형 실행기 설정을 제외한 "Actions 일반" 설정 페이지에서 모든 설정을 관리할 수 있는 액세스 권한.
• 조직 실행기 및 실행기 그룹 관리: GitHub 호스트형 실행기, 자체 호스트형 실행기, 실행기 그룹을 만들고 관리할 수 있으며 자체 호스트형 실행기를 만들 수 있는 위치를 제어할 수 있는 액세스 권한.
• 조직 Actions 비밀 관리: Actions 조직 비밀을 만들고 관리할 수 있는 액세스 권한.
• 조직 Actions 변수 관리: Actions 조직 변수를 만들고 관리할 수 있는 액세스 권한.

자세한 내용은 사용자 지정 조직 역할의 권한을(를) 참조하세요.

OpenID Connect를 사용하여 클라우드 리소스 액세스

GitHub Actions 워크플로가 OIDC(OpenID Connect)를 지원하는 클라우드 공급자의 리소스에 액세스해야 하는 경우 클라우드 공급자에게 직접 인증하도록 워크플로를 구성할 수 있습니다. 이렇게 하면 이러한 자격 증명을 수명이 긴 비밀로 저장하지 않을 수 있고 다른 보안 이점을 제공할 수 있습니다. 자세한 내용은 OpenID Connect을(를) 참조하세요.

작업을 최신 상태로 유지하는 데 사용 Dependabot version updates

Dependabot를 사용하여 작업 및 리포지토리에 사용된 재사용 가능한 워크플로에 대한 참조를 최신 상태로 유지할 수 있습니다. 작업은 버그 수정 및 새로운 기능으로 수시로 업데이트되어 자동화된 프로세스의 속도, 안전, 신뢰성을 향상합니다. Dependabot는 자동으로 종속성을 유지 관리하는 작업을 수행하여 드는 노력을 줄여줍니다. 자세한 내용은 Dependabot을 사용하여 작업을 최신 상태로 유지 및 Dependabot 보안 업데이트 정보을(를) 참조하세요.

워크플로가 내부 및 프라이빗 리포지토리에 액세스하도록 허용

프라이빗 리포지토리를 다른 리포지토리의 GitHub Actions 워크플로에 액세스할 수 있도록 하는 경우 다른 리포지토리의 외부 협력자는 프라이빗 리포지토리에 직접 액세스할 수 없더라도 프라이빗 리포지토리에 간접적으로 액세스할 수 있습니다. 외부 협력자는 프라이빗 리포지토리의 작업 또는 워크플로를 사용할 때 워크플로 실행에 대한 로그를 볼 수 있습니다. 자세한 내용은 엔터프라이즈와 작업 및 워크플로 공유을 참조하세요.

GitHub은(는) 범위가 지정된 설치 토큰을 실행기에 전달하여 작업을 다운로드할 수 있도록 합니다. 설치 토큰은 리포지토리에 대한 읽기 액세스 권한을 가지며 1시간 후에 자동으로 만료됩니다.

GitHub Actions가 풀 리퀘스트를 생성하거나 승인하지 못하도록 방지

GitHub Actions 워크플로가 끌어오기 요청을 만들거나 승인하는 것을 허용하거나 차단하도록 선택할 수 있습니다. 끌어오기 요청이 적절한 감독 없이 병합되는 경우 워크플로 또는 다른 자동화에서 끌어오기 요청을 만들거나 승인하도록 허용하는 것은 보안 위험이 될 수 있습니다.

이 설정을 구성하는 방법에 대한 자세한 내용은 엔터프라이즈에서 GitHub Actions 대한 정책 적용, 조직에 대해 GitHub Actions를 사용하지 않도록 설정하거나 제한 및 리포지토리에 대한 GitHub Actions 설정 관리을(를) 참조하세요.

워크플로를 보호하는 데 사용 code scanning

Code scanning 는 워크플로에 GitHub Actions 사용되는 일반적인 취약한 패턴에 대한 향상된 기능을 자동으로 검색하고 제안할 수 있습니다. 사용하도록 설정하는 code scanning방법에 대한 자세한 내용은 코드 검사에 대한 기본 설정 구성을 참조하세요.

OpenSSF 성과 기록표를 사용하여 워크플로 종속성 보호

성과 기록표는 위험한 공급망 사례를 표시하는 자동화된 보안 도구입니다. 성과 기록표 작업 및 워크플로 템플릿을 사용하여 모범 보안 사례를 준수할 수 있습니다. 구성되면 성과 기록표 작업은 리포지토리 변경에 대해 자동으로 실행되며, 기본 제공 code scanning 환경을 사용하여 위험한 공급망 관행에 대해 개발자에게 경고합니다. 성과 기록표 프로젝트는 스크립트 삽입 공격, 토큰 사용 권한 및 고정된 작업을 비롯한 다양한 검사를 실행합니다.

GitHub호스팅된 러너 강화

자체 호스팅 실행기를 위한 강화

자체 호스팅 러너는 GitHub 일시적으로 생성되는 깨끗한 가상 머신에서 실행된다는 보장이 없으며, 워크플로의 신뢰할 수 없는 코드에 의해 지속적으로 침해될 수 있습니다.

, 비공개 또는 내부 리포지토리에서 자체 호스팅 실행기를 사용할 때는 주의하세요. 리포지토리를 포크하고 풀 요청을 열 수 있는 사람이라면 누구나(일반적으로 리포지토리에 대한 읽기 권한이 있는 사용자) 비밀과 GITHUB_TOKEN에 접근하는 것을 포함해 자체 호스팅 실행기 환경을 침해할 수 있으며, 이 GITHUB_TOKEN는 설정에 따라 리포지토리에 대한 쓰기 권한을 부여할 수 있습니다. 워크플로는 환경 및 필수 검토를 사용하여 환경 비밀에 대한 액세스를 제어할 수 있지만 워크플로는 격리된 환경에서 실행되지 않으며 자체 호스팅 실행기에서 실행될 때 동일한 위험에 여전히 취약합니다.

엔터프라이즈 소유자 및 조직 소유자는 리포지토리 수준의 자체 호스트형 실행기를 만들 수 있는 리포지토리를 선택할 수 있습니다. "조직 실행기 및 실행기 그룹 관리" 권한을 가진 사용자는 조직의 리포지토리에 대해 리포지토리 수준의 자체 호스트형 실행기를 만들 수 있는 리포지토리만 선택할 수 있습니다.

사용자 지정 조직 역할에 대한 자세한 내용은 사용자 지정 조직 역할의 권한을(를) 참조하세요.

자세한 내용은 엔터프라이즈에서 GitHub Actions 대한 정책 적용 및 조직에 대한 GitHub Actions 사용하지 않도록 설정 또는 제한을(를) 참조하세요.

자체 호스팅 실행기를 조직 또는 엔터프라이즈 수준에서 GitHub 정의한 경우 여러 리포지토리에서 동일한 실행기로 워크플로를 예약할 수 있습니다. 따라서 환경의 보안 손상으로 인해 광범위한 영향을 미칠 수 있습니다. 손상 범위를 줄이기 위해 자체 호스팅 실행기를 별도의 그룹으로 구성하여 경계를 만들 수 있습니다. 워크플로, 조직 및 리포지토리 중 어떤 항목이 러너 그룹에 액세스할 수 있는지 제한할 수 있습니다. 자세한 내용은 그룹을 사용하여 자체 호스팅 실행기에 대한 액세스 관리을(를) 참조하세요.

자체 호스팅 러너 머신의 환경도 고려해야 합니다.

• 자체 호스팅 실행기로 구성된 컴퓨터에 있는 중요한 정보는 무엇인가요? 예를 들어 프라이빗 SSH 키, API 액세스 토큰 등이 있습니다.
• 컴퓨터에 중요한 서비스에 대한 네트워크 액세스 권한이 있나요? 예를 들어 Azure 또는 AWS 메타데이터 서비스입니다. 이 환경에서 중요한 정보의 양을 최소한으로 유지해야 하며, 워크플로를 호출할 수 있는 모든 사용자가 이 환경에 액세스할 수 있다는 점을 항상 염두에 두어야 합니다.

일부 고객은 각 작업 실행 후 자체 호스팅 실행기를 자동으로 삭제하는 시스템을 구현하여 해당 위험을 부분적으로 완화하려고 시도할 수 있습니다. 그러나 자체 호스팅 실행기에서 하나의 작업만 실행하도록 보장할 방법이 없으므로 이 방법은 의도한 만큼 효과적이지 않을 수 있습니다. 일부 작업은 같은 실행기에서 실행되는 다른 작업에서 볼 수 있는 명령줄 인수(예시: ps x -w)로 비밀을 사용합니다. 이로 인해 비밀 누출이 발생할 수 있습니다.

즉시 실행 러너 사용

러너 등록 보안을 강화하기 위해 REST API를 사용하여 일시적 즉시 실행(JIT) 러너를 생성할 수 있습니다. 이러한 자체 호스팅 실행기는 리포지토리, 조직 또는 엔터프라이즈에서 자동으로 제거되기 전에 최대 하나의 작업을 수행합니다. JIT 실행기 구성에 대한 자세한 내용은 자체 호스트형 실행기에 대한 REST API 엔드포인트을(를) 참조하세요.

REST API 응답에 구성 파일이 있으면 시작할 때 실행기에 전달할 수 있습니다.

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

자체 호스팅 러너를 위한 관리 전략 세우기

자체 호스팅 실행기를 계층 구조의 GitHub 다양한 수준(엔터프라이즈, 조직 또는 리포지토리 수준)에 추가할 수 있습니다. 이 배치는 러너를 관리할 수 있는 사용자를 결정합니다.

중앙 집중식 관리

• 중앙 집중식 팀이 자체 호스트 실행기를 소유하도록 하려는 경우 가장 높은 상호 조직 또는 엔터프라이즈 수준에서 실행기를 추가하는 것이 좋습니다. 이를 통해 팀은 러너를 보고 관리할 수 있는 단일 위치를 제공합니다.
• 단일 조직만 있는 경우 조직 수준에서 실행기를 추가하는 것은 사실상 동일한 방법이지만 나중에 다른 조직을 추가하면 문제가 발생할 수 있습니다.

탈중앙 집중식 관리

• 각 팀이 셀프 호스팅 러너를 관리하는 경우, 팀 관리 권한의 최상위에서 러너를 추가하는 것이 좋습니다. 예를 들어 각 팀이 자체 조직을 소유하는 경우, 러너를 조직 수준에서 추가하면 가장 쉬워집니다.
• 리포지토리 수준에서 실행기를 추가할 수도 있지만 리포지토리 간에 실행기를 공유할 수 없으므로 관리 오버헤드가 추가되고 필요한 실행기 수도 증가합니다.

클라우드 공급자에 인증

클라우드 공급자에 배포하는 데 GitHub Actions를 사용하고 있거나 시크릿 관리를 위해 HashiCorp Vault를 사용할 예정이라면, 워크플로 실행에 사용할 수명이 짧고 범위가 잘 제한된 액세스 토큰을 생성하기 위해 OpenID Connect 사용을 고려하는 것이 좋습니다. 자세한 내용은 OpenID Connect을(를) 참조하세요.

GitHub Actions 이벤트 감사하기

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

예를 들어 감사 로그를 사용하여 조직 비밀에 대한 변경 내용을 추적하는 org.update_actions_secret 이벤트를 추적할 수 있습니다.

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

• 보안 로그 이벤트
• 조직의 감사 로그 이벤트
• 귀하의 엔터프라이즈를 위한 감사 로그 이벤트

워크플로의 종속성 이해

종속성 그래프를 사용하여 리포지토리의 워크플로에서 사용하는 작업을 탐색할 수 있습니다. 종속성 그래프는 리포지토리에 저장된 매니페스트와 파일 잠금에 대한 요약입니다. 또한 ./github/workflows/의 파일을 매니페스트로 인식합니다. 즉, jobs[*].steps[*].uses 또는 jobs.<job_id>.uses 구문을 사용하여 참조되는 모든 작업이나 워크플로가 종속성으로 구문 분석됩니다.

종속성 그래프에는 워크플로우에서 사용되는 작업에 대한 다음 정보가 표시됩니다.

• 작업을 소유하는 계정 또는 조직.
• 작업을 참조하는 워크플로 파일.
• 작업이 고정된 특정 버전 또는 SHA입니다.

종속성 그래프에서 종속성은 약점 심각도에 따라 자동으로 정렬됩니다. 사용하는 작업에 보안 권고가 있는 경우 목록 맨 위에 표시됩니다. 약점을 해결하기 위한 종속성 그래프 및 액세스 지침에서 권고로 이동할 수 있습니다.

엔터프라이즈 소유자는 종속성 그래프 및 Dependabot alerts 엔터프라이즈에 대해 구성할 수 있습니다. 자세한 내용은 엔터프라이즈용 종속성 그래프 활성화을 참조하세요.

사용하는 작업의 보안 약점 인식

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

리포지토리를 설정하여 다음 작업을 할 수 있도록 합니다.

• 워크플로에 사용된 작업이 약점 보고서를 받으면 경고 받기 자세한 내용은 워크플로의 작업 모니터링을 참조하세요.
• 워크플로에서 작업을 추가하거나 업데이트하면 기존 권고에 대한 경고 받기 자세한 내용은 신규 또는 업데이트된 워크플로의 약점에 대한 작업 차단을 참조하세요.

워크플로의 작업 모니터링

Dependabot를 사용하여 워크플로 내 작업을 모니터링하고, Dependabot alerts를 활성화하여 사용 중인 작업에서 취약성이 보고되면 알림을 받을 수 있습니다. Dependabot 는 안전하지 않은 종속성을 검색하도록 설정된 리포지토리의 기본 분기를 검색합니다. Dependabot는 Dependabot alerts에 새 권고가 추가되거나 사용 중인 작업이 업데이트될 때 GitHub Advisory Database를 생성합니다.

리포지토리에 대한 Dependabot를 관리하려면 먼저 엔터프라이즈 소유자가 엔터프라이즈에 대해 Dependabot alerts를 설정해야 합니다. 자세한 내용은 엔터프라이즈에 Dependabot 사용을 참조하세요.

리포지토리의 Dependabot alerts 탭에서 모든 열린 Dependabot security updates과 닫힌 Dependabot 및 해당 항목들을 볼 수 있습니다. 자세한 내용은 Dependabot 경고 보기 및 업데이트을 참조하세요.

신규 또는 업데이트된 워크플로의 취약점에 대한 작업 검토

워크플로를 업데이트하기 위해 끌어오기 요청을 열 때 종속성 검토를 사용하여 사용하는 작업에 대한 변경 내용이 보안에 미치는 영향을 이해하는 것이 좋습니다. 종속성 검토는 모든 끌어오기 요청에서 종속성 변경 내용과 이러한 변경 내용의 보안 영향을 이해하는 데 도움이 됩니다. 끌어오기 요청의 “변경된 파일” 탭에서 서식 있는 Diff로 종속성 변경 내용을 쉽게 이해할 수 있습니다. 종속성 검토는 다음을 알려줍니다.

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

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

종속서 검토에 대한 자세한 내용은 종속성 검토 정보을(를) 참조하세요.

"종속성 검토 작업"은 GitHub Actions 컨텍스트 내에서 끌어오기 요청의 차이점을 보고할 수 있는 특정 작업을 나타냅니다. dependency-review-action을 참조하세요. 리포지토리에서 종속성 검토 작업을(를) 사용하여 끌어오기 요청에 대한 종속성 검토를 적용할 수 있습니다. 이 작업은 끌어오기 요청의 패키지 버전 변경에 의해 도입된 취약한 종속성 버전을 검사하고 관련 보안 취약성에 대해 경고합니다. 이를 통해 끌어오기 요청의 변경 내용을 보다 잘 파악할 수 있으며 취약성이 리포지토리에 추가되지 않도록 방지할 수 있습니다. 자세한 내용은 종속성 검토 정보을 참조하세요.

워크플로의 작업을 안전하고 최신 상태로 유지

Dependabot를 사용하여 작업 및 리포지토리에 사용된 재사용 가능한 워크플로에 대한 참조를 최신 상태로 유지할 수 있습니다. 작업은 버그 수정 및 새로운 기능으로 수시로 업데이트되어 자동화된 프로세스의 속도, 안전, 신뢰성을 향상합니다. Dependabot는 자동으로 종속성을 유지 관리하는 작업을 수행하여 드는 노력을 줄여줍니다. 자세한 내용은 Dependabot을 사용하여 작업을 최신 상태로 유지 및 Dependabot 보안 업데이트 정보을(를) 참조하세요.

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

• Dependabot version updates 끌어오기 요청을 열어 새 버전이 릴리스될 때 작업을 최신 버전으로 업데이트합니다.
• Dependabot security updates 끌어오기 요청을 열어 보고된 취약성이 있는 작업을 패치된 최소 버전으로 업데이트합니다.

구성하는 Dependabot version updates방법에 대한 자세한 내용은 Dependabot 버전 업데이트 구성을 참조하세요.

구성하는 Dependabot security updates방법에 대한 자세한 내용은 Dependabot 보안 업데이트 구성을 참조하세요.