Michael Johnson@v3 같은 태그로 action을 참조하는 워크플로를 신뢰할 수 있을까요? 잠금 파일은 태그가 나중에 이동하더라도 실행될 action의 commit을 명시합니다. 팀은 diff에서 의존성 업데이트를 검토하고 CI에서 사용하는 action의 검증 가능한 목록을 관리할 수 있습니다. 다만 잠금 파일은 단계에서 호출되는 action을 다루며, job 수준에서 호출하는 재사용 워크플로는 별도로 고정해야 합니다. 설명된 기능은 GitHub Enterprise Cloud에서 사용할 수 있습니다.
잠금 파일은 정확히 무엇을 고정하나요?
브랜치와 태그를 참조하면 편리하지만, 그에 해당하는 버전은 바뀔 수 있습니다. uses: octo-org/deploy-action@v3 같은 항목은 태그 이름을 가리키며, GitHub는 실행 시 이 참조를 commit으로 해석합니다. 프로젝트 소유자가 태그를 이동하면 의존성을 고정하지 않은 다음 실행에서 다른 코드가 사용될 수 있습니다.
GitHub의 잠금 파일 문서에 따르면 .github/workflows/actions.lock 파일에는 의존성 참조와 이에 해당하는 commit SHA가 저장되며, 다른 action이 사용하는 action인 전이 의존성도 포함됩니다. 이 파일은 GitHub CLI 확장 프로그램 gh actions-lock이 생성하며, 수동으로 편집하지 않습니다.
생성기는 워크플로 파일의 uses 참조도 구체화할 수 있습니다. 예를 들어 유동 태그 참조를 잠금 파일 생성 시점에 해석된 commit을 유지하는 더 구체적인 참조로 바꿀 수 있습니다. 따라서 도입할 때는 워크플로와 잠금 파일의 변경 사항을 포함해 전체 diff를 검토하고, 고정된 버전이 팀이 실행하려는 버전인지 확인해야 합니다.
이렇게 하면 의존성 업데이트가 저장소에서 확인할 수 있는 변경 사항이 됩니다. 팀은 commit 변경을 검토하고 논의한 뒤 일반적인 리뷰 절차를 거쳐 승인할 수 있습니다. 잠금 파일은 action 코드를 감사하고 의존성을 일관되게 유지하는 데 도움이 되지만, 선택한 코드가 안전하다는 것을 그 자체로 증명하지는 않습니다.
고정 범위는 어디까지인가요?
jobs.<job_id>.uses 안에서 호출하는 재사용 워크플로는 이를 호출하는 저장소의 잠금 파일에 고정되지 않습니다. 재사용 워크플로의 의존성은 해당 워크플로가 정의된 저장소에 속합니다. 호출 자체를 고정하려면 전체 commit SHA를 지정하고, 원본 저장소에서 해당 워크플로의 action을 고정하려면 그 저장소에 별도의 잠금 파일이 필요합니다.
잠금 파일은 action 코드를 관리하지만, action에 전달되는 매개변수, 비밀 정보 또는 runner 이미지 같은 빌드의 다른 입력은 관리하지 않습니다. 잠금 파일이 답하는 질문은 구체적으로 “어떤 action 코드 commit이 실행되는가?”입니다. 나머지 요소에는 각자 별도의 관리 규칙이 필요합니다.
경로가 uses: ./처럼 지정된 로컬 action도 예외입니다. GitHub 안내에 따르면 gh actions-lock 확장 프로그램은 로컬 경로의 action을 고정하거나 분석하지 않습니다. 이런 action이 다른 action을 사용한다면 의존성을 별도로 관리해야 합니다. 문서에는 로컬 action 참조를 $/ 형식으로 마이그레이션하는 방법도 안내되어 있습니다.
따라서 잠금 파일의 한 항목이 의존성 체인의 일부가 될 수는 있지만, 체인의 모든 요소를 관리하는 일을 대신하지는 않습니다. 외부 재사용 워크플로는 호출을 고정했는지와 원본 저장소의 상태를 확인하고, 로컬 action은 의존성을 어떻게 반영했는지 점검해야 합니다.
CI를 갑자기 중단하지 않고 통제를 도입하는 방법
GitHub는 선정한 저장소와 워크플로에서 먼저 시범 운영할 것을 권장합니다. Require lockfile 정책은 uses: 의존성이 없는 워크플로를 포함해 올바른 잠금 파일이 없는 대상 워크플로의 실행을 차단합니다. 정책의 Evaluate 모드는 GitHub Enterprise Cloud에서만 사용할 수 있습니다. 따라서 적용 범위와 자동 업데이트를 먼저 준비한 다음 의무 규칙을 활성화하세요.
- 기존 참조를 확인합니다. 잠금 파일을 만들기 전에 action 참조가 팀이 실제로 고정하려는 버전을 가리키는지 확인합니다. 생성기는 현재 참조에서 해석된 commit을 고정합니다.
- 잠금 파일을 만들고 검토합니다.
gh-actions-lock확장 프로그램을 설치하고 저장소 루트에서gh actions-lock을 실행한 다음, 다시 작성된uses참조를 포함해 전체 diff를 검토합니다. - 업데이트와 검증을 설정합니다. Dependabot은 이미 연결된 워크플로의 해당 항목을 업데이트할 수 있습니다. CI에서는 pull request 검증 작업을
gh actions-lock --verify로 설정해 본 빌드 전에 잠금 파일이 오래된 상태인지 확인할 수 있습니다. - 리뷰어를 지정합니다. CODEOWNERS에
.github/workflows/actions.lock을 추가하고 빌드 보안 담당자가 변경 사항을 검토하도록 합니다. - 정책을 시범 적용합니다. 연결된 저장소와 워크플로부터 시작합니다. Evaluate 모드에서 결과를 분석하고, Active 모드로 전환하기 전에 모든 대상 워크플로가 준비되었고 잠금 파일이 최신 상태인지 확인합니다.
Require lockfile과 별도의 Require actions to be pinned to a full-length commit SHA 정책은 서로 다른 규칙이며, GitHub는 두 정책을 동시에 유지할 수 있다고 안내합니다. CI 검증과 의무 정책도 역할이 다릅니다. 전자는 pull request 작업 중 오래된 파일을 감지하고, 후자는 요구 사항을 충족하지 않는 워크플로의 실행을 차단합니다.
예시: 배포 action 업데이트
워크플로에서 octo-org/deploy-action@v3를 통해 애플리케이션을 게시한다고 가정해 보겠습니다. 먼저 팀은 이 참조가 어떤 버전으로 해석되는지 확인한 다음 gh actions-lock을 실행하고, 잠금 파일의 commit 항목과 함께 워크플로 diff를 검토합니다. action을 업데이트할 때 검토자는 참조와 고정된 commit의 변경 사항을 확인할 수 있습니다. 덕분에 변동될 수 있는 태그가 항상 이전 코드와 연결되어 있을 것이라고 믿는 대신 구체적인 업데이트를 평가할 수 있습니다.
배포에 다른 저장소의 재사용 워크플로가 사용된다면 로컬 잠금 파일은 그 의존성을 포함하지 않습니다. 재사용 워크플로 참조를 전체 SHA로 고정하고 원본 저장소에서도 자체 action 의존성을 관리하는지 확인하세요. 대규모 조직에서는 이 방법으로 제각각인 규칙을 검증 가능한 절차로 만들 수 있으며, 매개변수, 비밀 정보와 runner는 계속 별도로 관리할 수 있습니다.
잠금 파일은 action 코드 관리의 한 계층으로 유용합니다. 전이 의존성을 포함해 버전과 업데이트를 파악할 수 있게 해줍니다. 범위를 충분히 관리하려면 재사용 워크플로와 로컬 action도 확인하고, 업데이트를 자동화하며, 시범 운영을 마친 뒤에만 의무 정책을 도입하세요.
