서론

GitHub Actions 주변의 2026년 6월 변경 사항을 보았을 때, 솔직히 말해서 처음부터 강한 위기감을 느꼈던 것은 아닙니다.

pull_request_target

, actions/checkout

, Actions cache, workflow trigger. 모두 GitHub Actions를 사용하고 있다면 흔히 접하는 용어들입니다. 다만, 외부로부터 리포지토리가 공격받는다거나, CI/CD의 입구가 악용된다는 이야기를 들어도 어디선가 "유명한 OSS나 큰 조직의 이야기겠지"라고 생각했습니다.

저는 누군가의 pull request를 대량으로 리뷰하기보다는, GitHub Actions로 CI/CD를 구축하거나 GitHub flow를 원활하게 돌리는 맥락에서 GitHub를 접하는 경우가 많습니다. 최근에는 그 영역에 AI도 들어와 있어서, "이 프로젝트용으로 Actions의 YAML을 작성해줘", "push 시에 테스트하고, main에 머지되면 빌드해줘"와 같은 초안을 AI에게 만들어 달라고 하는 상황도 늘어났습니다.

이것은 상당히 편리합니다. YAML의 세세한 구문이나 인덴트(indent)를 매번 찾아보지 않아도 되고, 처음부터 쓰는 것보다 빠른 경우도 많습니다.

하지만 이번 변경 사항을 추적해 보면서, 저는 GitHub Actions를 조금 "돌아가기만 하면 되는 자동화"로 너무 과하게 보고 있었다는 생각이 들었습니다. AI가 만든 YAML이 작동하는지 여부뿐만 아니라, 누가 실행할 수 있는지, 어떤 코드를 checkout 하는지, 어떤 권한으로 실행되는지를 살펴볼 필요가 있습니다.

이 기사는 AI에게 GitHub Actions를 쓰게 하는 것 자체를 피하기 위한 것이 아닙니다. 오히려 AI에게 초안을 만들어 달라는 전제하에, 인간이 어디를 확인해야 하는지를 정리하기 위한 메모입니다.

실제로 GitHub Actions의 YAML을 AI에게 만들어 달라고 하는 상황은 늘어나고 있습니다.

예를 들어, 다음과 같은 요청입니다.

• push 시에 테스트를 실행한다
• pull request 생성 시에 Lint와 빌드를 돌린다
• main으로 머지되면 배포한다
• 릴리스 태그 생성 시에 패키지를 공개한다
• Dependabot이나 외부 PR에 대해 자동 댓글을 남긴다

AI는 이러한 종류의 초안을 상당히 자연스럽게 만들 수 있습니다. 구문이나 인덴트를 찾아보는 수고도 줄어듭니다.

하지만 GitHub Actions의 YAML은 단순한 설정 파일이 아닙니다. 실행 권한, 시크릿 (secret), 캐시 (cache), 아티팩트 (artifact), 릴리스, 배포와 관련되어 있기 때문에, 작성 방법을 틀리면 리포지토리 전체의 보안에 영향을 미칩니다.

이 기사에서는 2026년 6월의 GitHub Actions 관련 업데이트를 바탕으로, AI가 생성한 Actions YAML을 볼 때 확인하고 싶은 포인트를 정리합니다.

배경: 2026년 6월의 GitHub Actions 관련 변경 사항

GitHub는 2026년 6월에 Actions의 신뢰 경계(trust boundary)에 관한 변경 사항을 여러 개 발표했습니다.

• pull_request_target과 actions/checkout의 조합을 더 안전한 기본값으로 가져가는 변경
• untrusted triggers로부터의 Actions cache를 읽기 전용으로 만드는 변경
• 누가, 무엇을 계기로 workflow를 실행할 수 있는지를 제어하는 방향의 업데이트

이것들은 개별적으로는 작은 변경처럼 보이지만, 공통점은 "외부에서 온 입력을 어떤 권한으로 실행해도 되는가"라는 문제입니다.

GitHub Actions에서는 이벤트, checkout 대상, 토큰 권한, 시크릿, 캐시, 아티팩트가 조합되어 작동합니다. AI가 생성한 YAML을 볼 때도 "작동 여부"뿐만 아니라, 이 신뢰 경계를 확인해야 합니다.

pull_request_target을 사용하고 있지 않은가

체크 1: 우선 먼저 봐야 할 것은 트리거(trigger)입니다.

on:
  pull_request_target:

pull_request_target은 pull request에 반응하여 작동하는 이벤트이지만, 베이스 리포지토리 측의 문맥에서 실행됩니다. 일반적인 pull_request보다 더 강력한 권한을 다룰 수 있기 때문에, 라벨링, 댓글, 권한이 필요한 처리 등에는 편리합니다.

하지만 외부 PR 측의 코드를 checkout하여 실행하는 용도로는 주의가 필요합니다.

위험해지기 쉬운 형태는 다음과 같은 조합입니다.

on:
  pull_request_target:
jobs:
...

이 예시에서는 pull_request_target

의 강력한 문맥에서 PR 측의 코드를 checkout하여 실행합니다. 외부에서 들어온 PR에 악의적인 코드가 포함되어 있을 경우, 해당 코드를 강력한 권한을 가진 환경에서 실행하게 됩니다.

확인 관점은 다음과 같습니다.

• 정말로 pull_request_target이 필요한가
• 일반적인 pull_request로 충분하지 않은가
• pull_request_target 내에서 PR 측의 코드를 checkout하고 있지 않은가
• checkout한 코드를 npm test, python script.py, bash script.sh 등으로 실행하고 있지 않은가
• 권한이 필요한 처리와 PR 측 코드를 실행하는 처리를 분리할 수 없는가

GitHub Security Lab의 「Preventing pwn requests」는 이 문제를 이해하기 위해 읽어둘 가치가 있습니다.

체크 2: permissions가 최소한으로 설정되어 있는가

AI가 생성한 YAML에서는 permissions가 생략되는 경우가 있습니다.

생략 시의 동작은 리포지토리나 조직(Organization)의 설정에 따라 다르기 때문에, workflow 측에서 명시해 두는 것이 가독성이 높고 보안 측면에서 안전하게 가져가기 쉽습니다.

테스트나 Lint 작업만 수행한다면, 우선 읽기 전용(read-only)을 기본으로 합니다.

permissions:
  contents: read

Pull request에 댓글을 작성하는 경우에는 필요한 권한을 명시합니다.

permissions:
  contents: read
  pull-requests: write

패키지 공개나 릴리스(Release) 생성이 필요한 workflow에서는 contents: write나 packages: write가 필요할 수 있습니다. 다만, 필요한 job에만 한정하여 적용하는 것을 검토해야 합니다.

확인 관점은 다음과 같습니다.

• permissions가 명시되어 있는가
• 테스트 전용 workflow에 쓰기 권한(write permission)이 부여되어 있지 않은가
• job 단위로 권한을 제한할 수 있는가
• 배포(Deploy)나 릴리스용 권한이 PR 유래의 workflow에서 사용되고 있지 않은가
• id-token: write를 사용하는 경우, OIDC의 조건이 적절한가

AI가 '실행하기 위해' 강력한 권한을 제시할 경우, 사람이 이를 덜어내는(subtraction) 작업이 필요합니다.

체크 3: checkout하고 있는 코드가 어디에서 유래했는가

Actions에서는 무엇을 checkout하고 있는지가 중요합니다.

특히 PR 이벤트에서는 다음의 차이를 의식해야 합니다.

• 베이스 리포지토리(Base repository) 측의 코드
• PR 머지(Merge) 결과
• PR 헤드(Head) 측의 코드
• 포크(Fork) 원본에서 온 코드

AI가 생성한 YAML에서는 ref:에 github.event.pull_request.head.sha나 github.head_ref를 사용하는 경우가 있습니다.

그 자체로 항상 나쁜 것은 아닙니다. 다만, 어떤 권한으로 해당 코드를 실행할지와 세트로 확인해야 합니다.

확인 관점은 다음과 같습니다.

• actions/checkout의 ref가 무엇을 가리키고 있는가
• 포크 원본 PR의 코드를 checkout하고 있지 않은가
• checkout한 코드를 강력한 권한으로 실행하고 있지 않은가
• 권한이 필요한 처리 이전에 외부 유래 코드를 실행하고 있지 않은가

pull_request_target과 PR head의 checkout이 결합되어 있는 경우에는 특히 주의 깊게 살펴봐야 합니다.

체크 4: cache와 artifact를 쓰게 해도 괜찮은가

Actions cache는 빌드 속도를 높이는 데 유용합니다.

하지만 캐시는 다음 실행에 영향을 미칩니다. 신뢰할 수 없는 트리거(Trigger)로부터 캐시를 쓸 수 있게 되면, 후속되는 신뢰할 수 있는 workflow가 오염된 캐시를 읽을 가능성이 있습니다.

GitHub는 2026년 6월, 신뢰할 수 없는 트리거(untrusted triggers)로부터의 Actions cache를 읽기 전용으로 만드는 변경 사항을 발표했습니다. 이는 캐시 또한 신뢰 경계(Trust boundary)의 일부로 취급하려는 흐름입니다.

확인 관점은 다음과 같습니다.

• 외부 PR이나 자동 생성 PR로부터 cache를 쓰게 하고 있지 않은가
• cache key에 PR 유래의 값을 사용하고 있는 경우, 의도한 대로 분리되어 있는가
• artifact를 후속 job이나 별도의 workflow에서 지나치게 신뢰하고 있지 않은가
• 배포용 workflow가 신뢰할 수 없는 입력 유래의 cache나 artifact를 사용하고 있지 않은가

캐시(cache)나 아티팩트(artifact)는 단순한 속도 향상용이나 중간 파일이 아닙니다. 다음 실행으로 전달되는 것으로 취급해야 합니다.

체크 5: 서드파티 Action을 무비판적으로 수용하고 있지 않은가

AI는 편리한 서드파티 Action을 제안할 수 있습니다.

steps:
- uses: some-user/some-action@v1

이때, 적어도 다음 사항을 확인합니다.

• 해당 Action이 실제로 존재하는가
• 작성자나 조직을 신뢰할 수 있는가
• README, 업데이트 이력, Issue 상태가 적절한가
• 공식 Action으로 대체할 수 없는가
• 태그(tag) 고정으로 충분한가, 커밋 SHA(commit SHA) 고정이 필요한가

GitHub의 보안 가이드에서는 서드파티 Action의 취급과 신뢰할 수 있는 Action을 사용하는 것의 중요성을 설명하고 있습니다.

모든 Action을 매번 SHA로 고정할지는 팀의 운영 방식이나 리스크에 따라 다릅니다. 하지만 적어도 AI가 제시한 uses:를 확인하지 않고 그대로 통과시키는 것은 피하는 것이 좋습니다.

체크 6: workflow를 누가 실행할 수 있는가

GitHub Actions에서는 workflow가 어떤 이벤트로 실행되는지도 중요합니다.

on:
pull_request:
workflow_dispatch:
...

단순히 이벤트의 종류만 봐서는 안 됩니다.

• fork로부터의 PR(Pull Request)에서 동작하는가
• 첫 기여자의 PR에서 자동 실행되는가
• workflow_dispatch를 누가 실행할 수 있는가
• push 대상 브랜치가 적절하게 제한되어 있는가
• 배포(deploy) workflow가 PR 이벤트로부터 실행되지 않는가

특히 배포, 릴리스(release), 패키지 공개, 클라우드 조작을 포함하는 workflow는 실행 조건을 좁게 설정해야 합니다.

on:
push:
tags:
...

또는 환경 보호 규칙(environment protection rules)이나 수동 승인(manual approval)을 조합하는 것도 검토합니다.

AI 생성 YAML을 검토하기 위한 짧은 체크리스트

AI가 GitHub Actions YAML을 생성했다면, 우선 다음을 확인합니다.

• pull_request_target을 사용하고 있는가 - PR 측의 코드를 checkout하여 실행하고 있지는 않은가
• permissions가 명시되어 있으며 최소한으로 설정되어 있는가 - GITHUB_TOKEN이나 secrets가 PR 유래의 프로세스로 전달되지 않는가 - 캐시(cache)나 아티팩트(artifact)를 신뢰할 수 없는 실행 주체가 작성하게 하고 있지는 않은가
• uses:의 Action이 신뢰할 수 있는 것인가 - 배포나 릴리스가 PR 이벤트로부터 실행되지 않는가
• workflow_dispatch나 branch/tag 조건이 너무 넓지는 않은가

이 체크는 AI를 사용하지 않기 위한 것이 아닙니다.

AI에게 초안을 작성하게 하고, 인간이 신뢰 경계(trust boundary)를 확인하기 위한 것입니다.

요약

GitHub Actions의 YAML은 겉보기에는 작은 설정 파일입니다.

하지만 실제로는 코드를 checkout하고, 셸(shell)을 실행하며, 시크릿(secret)이나 토큰(token)에 접근하고, 릴리스나 배포로 이어지는 실행 환경입니다.

AI는 그 YAML을 짧은 시간 안에 만들 수 있습니다. 이는 매우 편리합니다.

다만, AI가 생성한 YAML을 확인할 때는 '동작 여부'뿐만 아니라 다음을 확인해야 합니다.

• 누가 실행하는가
• 무엇을 checkout하는가
• 어떤 권한으로 동작하는가
• 무엇을 작성할 수 있는가
• 그 결과가 어디로 전달되는가

GitHub Actions의 2026년 6월 변경 사항은 CI/CD의 입구를 보안 측면으로 강화하려는 흐름으로 읽힙니다.

AI에게 YAML 작성을 맡기는 시대이기에 더욱, 인간은 YAML의 구문(syntax)보다 신뢰 경계를 바라보는 능력을 갖추어야 합니다.

참고

• GitHub Changelog: Safer pull_request_target defaults for GitHub Actions checkout

https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/ - GitHub Changelog: Read-only Actions cache for untrusted triggers

https://github.blog/changelog/2026-06-26-read-only-actions-cache-for-untrusted-triggers/ - GitHub Changelog: 신뢰할 수 없는 트리거에 대한 읽기 전용 Actions 캐시

https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/ - GitHub Changelog: 누가 무엇을 GitHub Actions 워크플로우를 트리거하는지 제어하기

https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/ - GitHub Docs: GitHub Actions 보안 강화 (Security hardening)

토론