액션 종속성에 lockfile 적용

잠금 파일을 요구하면 각 팀에게 자체적으로 이 방식을 채택하도록 요청하지 않고 모든 워크플로가 심사된 코드를 실행한다는 일관되고 감사 가능한 보증이 제공됩니다. 소개는 워크플로 종속성 락파일을(를) 참조하세요.

이 가이드는 선택한 리포지토리에서 파일럿을 실행하고 잠금 파일을 최신 상태로 유지하도록 자동화를 설정하는 데 도움이 됩니다. 잠금 파일이 의도한 대로 작동하고 개발자 마찰을 도입하지 않는다고 확신하는 경우 잠금 파일 필요 정책을 적용할 수 있습니다.

Prerequisites

워크플로 잠금 파일을 적용하고 프로세스를 만들어 최신 상태로 유지하려면 먼저 잠금 파일이 리포지토리에 있어야 합니다. 지침은 리포지토리의 워크플로에서 액션 종속성 잠금을(를) 참조하세요. 잠금 파일을 만들려면 관리자가 될 필요가 없습니다. 리포지토리에 대한 쓰기 권한이 있는 사용자는 누구나 이 작업을 수행할 수 있으므로 정책을 중앙에서 적용하기 전에 개별 팀에 온보딩을 위임할 수 있습니다.

워크플로가 다른 리포지토리에서 재사용 가능한 워크플로를 호출하는 경우 해당 원본 리포지토리도 온보딩되었는지 확인합니다. 호출 리포지토리의 lockfile은 해당 항목들을 포함하지 않습니다. 호출된 재사용 가능한 워크플로가 자체 리포지토리에 온보딩되지 않은 경우 잠금 파일 필요 정책은 호출 워크플로의 실행을 차단합니다.

1. "잠금 파일 필요" 정책 시범 적용

잠금 파일 필요 정책은 종속성이 없는 uses: 워크플로를 포함하여 리포지토리의 lockfile에 온보딩되지 않은 대상 워크플로의 실행을 차단합니다.

모든 리포지토리에서 이 정책을 적용하기 전에 파일럿을 실행하세요. 다음을 수행하라.

• 정책 범위를 lockfile에 온보딩된 특정 리포지토리로 지정합니다.
• 모든 워크플로가 온보딩되고 새 워크플로를 온보딩하는 자동화된 프로세스가 마련될 때까지 잠금 파일에 온보딩된 특정 워크플로에만 적용하세요.
• 평가 모드에서 정책으로 시작하고 정책 인사이트에서 결과를 분석합니다.

lockfile 요구는 작업을 전체 길이 커밋 SHA에 고정하도록 요구와는 별개의 정책입니다. 롤아웃하는 동안 둘 다 사용하도록 설정할 수 있습니다. 정책을 구성하고 두 가지가 상호 작용하는 방법을 확인하려면 워크플로 실행 관리을 참조하세요.

2. 잠금 파일을 최신 상태로 유지

강제 적용은 lockfile이 최신 상태로 유지된 경우에만 작동합니다. 개발자가 워크플로를 만들거나 편집할 때마다 잠금 명령을 실행할 필요가 없도록 자동화를 추가합니다.

다음 섹션에서는 개발 수명 주기의 여러 시점에서 오래된 lockfile을 방지하는 방법에 대한 예제를 제공합니다.

• Dependabot를 사용하도록 설정하여 파일을 최신 상태로 유지합니다.
• 잠금 명령을 실행하고 pull request 요구 사항의 일부로 이를 검증하는 워크플로를 만듭니다.

Dependabot 버전 업데이트

Dependabot가 작업 버전을 올리면 동일한 끌어오기 요청에서 일치하는 잠금 파일 항목을 다시 생성합니다.

GitHub Actions가 Dependabot 종속성을 관리하도록 하는 것 외에는 추가 구성이 필요하지 않습니다. Dependabot을 사용하여 작업을 최신 상태로 유지을(를) 참조하세요.

Dependabot 는 아직 lockfile 항목이 없는 워크플로를 온보딩 하지 않으므로 이 옵션은 범위를 확장하는 대신 적용 범위를 유지합니다.

전용 워크플로 또는 Copilot

워크플로를 추가하거나 편집하는 경우 잠금 명령을 실행하는 다른 워크플로를 실행합니다. action.yaml 및 모든 .github/workflows/** 또는 action.yml 파일의 변경 시 워크플로를 트리거한 다음, 여기에 두 개의 작업을 할당합니다.

• 푸시할 때 잠금 파일을 다시 생성하고 결과를 커밋하는 업데이트 작업입니다. 이 작업에는 contents: write 권한이 필요하며, 분기 보호 규칙 또는 규칙 집합은 GitHub Actions이(가) 워크플로가 실행되는 분기로 푸시할 수 있도록 허용해야 합니다. lockfile에 쓰려면 workflow OAuth 범위가 필요하므로 도구에 해당 범위가 있음을 확인합니다.
• 끌어오기 요청에서 gh actions-lock --verify**** 실행되는 작업입니다. 잠금 파일이 오래되었으면 오류와 함께 종료되므로 필요한 검사에 유용합니다.

즉시 사용할 수 있는 예제 워크플로는 저장소의 gh-actions-lock을(를) 참조하세요. Copilot를 사용해 워크플로를 편집하는 경우 동일한 변경 집합에서 잠금 파일을 다시 생성하도록 설정할 수도 있습니다. gh-actions-lock 기술 및 에이전트 기술을 참조하세요.

3. 잠금 파일 변경에 대한 검토 프로세스 설정

잠금 파일은 누군가가 diff를 읽는 경우에만 보안 컨트롤입니다. 특히 변경된 커밋 SHA는 워크플로가 실행하는 코드가 변경되었음을 알려줍니다.

1. 빌드 보안을 담당하는 팀에 자동으로 검토가 요청되도록 .github/workflows/actions.lock 파일에 CODEOWNERS를 추가합니다. 코드 소유자 정보을(를) 참조하세요.
2. 코드 소유자의 승인을 요구하도록 분기 보호 규칙 또는 리포지토리 규칙 집합을 구성합니다.
3. 검토자에게 무엇을 확인해야 하는지 알려줍니다. 지침은 리포지토리의 워크플로에서 액션 종속성 잠금을(를) 참조하세요.

4. 정책 시행

잠금 파일이 제자리에 있고 최신 상태를 유지한다고 확신하는 경우 잠금 파일 필요 정책의 적용 상태를 활성으로 변경합니다. 온보딩된 모든 리포지토리 및 워크플로가 대상으로 지정되었는지 확인합니다.

2단계의 검증을 그대로 둡니다. 정책은 유효한 잠금 파일이 없는 워크플로 실행을 차단합니다. 반면 확인 검사는 풀 리퀘스트에서 작업하는 동안 잠금 파일이 오래되었다는 것을 저자에게 알려줍니다.

확인 검사가 실패하면 gh-actions-lock 리포지토리의 gh-actions-lock 문제 해결 가이드를 참조하세요.