GitHub Actions 공급망 보안 2026, CI/CD 권한·의존성·시크릿 방어 기준

GitHub Actions 공급망 보안 점검을 위한 보안 운영 회의와 CI/CD 파이프라인 검토 장면 — GitHub Actions 공급망 보안은 workflow 권한, 타사 action, 의존성 변경, 배포 자격 증명을 같은 표에서 봐야 한다.

GitHub Actions 공급망 보안을 검색한 팀은 단순히 workflow 문법을 고치려는 것이 아니다.

문제는 PR 하나, 타사 action 하나, 오래된 PAT 하나가 빌드 권한과 패키지 배포 권한으로 번지는 순간이다.

Wiz가 분석한 AsyncAPI 사례는 pull_request_target과 공격자 제어 코드가 만나면 저장소 비밀과 배포 토큰이 노출될 수 있음을 보여준다.

그래서 이 글의 결론은 간단하다.

CI/CD 보안은 secret scanning 한 줄이 아니라 workflow trigger, GITHUB_TOKEN 권한, action 고정, dependency review, artifact provenance를 한 번에 묶어야 한다.

핵심 요약

pull_request_target은 untrusted PR 코드를 실행하지 않는 구조일 때만 제한적으로 써야 한다.
GITHUB_TOKEN은 repository 기본값을 read 중심으로 두고 job별 permissions에서 필요한 권한만 올린다.
타사 action은 owner, 태그, commit, release 신뢰도, 유지보수 상태, Scorecard 신호를 같이 본다.
패키지 배포 저장소는 dependency review, SBOM, provenance, secret rotation runbook을 release gate로 묶는다.

이 글이 필요한 사람

GitHub Actions로 npm, PyPI, container image, internal package를 배포하는 DevOps 담당자
pull_request_target, workflow_run, self-hosted runner를 쓰지만 보안 기준이 문서화되지 않은 플랫폼팀
개발 속도와 공급망 보안 통제를 같이 맞춰야 하는 보안팀과 AppSec 담당자
Secret Scanning과 Dependabot은 켰지만 release artifact 신뢰성까지 보지 못한 조직
오픈소스 저장소 또는 외부 PR을 받는 서비스에서 CI/CD 권한 분리를 다시 설계해야 하는 관리자

GitHub Actions 공급망 보안의 공격면을 먼저 나눈다

공급망 공격은 보통 하나의 큰 취약점보다 작은 권한 연결에서 시작한다.

workflow가 PR 코드를 실행하고, 그 job이 write 권한 token을 받고, 배포 secret까지 읽으면 공격자는 빌드 서버를 우회 배포 경로로 쓸 수 있다.

GitHub 공식 문서는 secrets, GITHUB_TOKEN 최소 권한, 타사 action 사용, untrusted input 처리 같은 항목을 Actions 보안 기준으로 분리한다.

이 분리를 그대로 내부 점검표로 바꾸면 무엇을 먼저 막을지 보인다.

공격면	주요 위험	먼저 볼 파일	차단 기준
Trigger	untrusted PR 코드가 base 저장소 권한으로 실행	.github/workflows/*.yml	pull_request_target은 checkout과 실행 경로를 분리
Token	GITHUB_TOKEN 또는 PAT가 과한 write 권한 보유	permissions, secrets, env	기본 read, job별 write 허용
Third-party action	action owner 변경, tag 이동, 악성 release	uses: owner/repo@ref	allowlist와 pinning review
Dependency	lockfile 변경으로 취약 패키지 유입	manifest, lockfile	dependency review와 severity gate
Artifact	빌드 산출물 출처를 검증하지 못함	release, package registry	provenance, SBOM, attestation 검토

이 조건이면 보안팀이 먼저 개입해야 한다.

외부 PR을 받고, workflow가 secrets 또는 package publish 권한을 읽으며, runner가 production credential에 접근하는 저장소다.

이 경우는 개발팀 자체 점검으로 시작해도 된다.

내부 전용 저장소이고 release가 수동 승인되며, workflow 권한이 read 중심으로 이미 제한된 경우다.

pull_request_target은 기능보다 격리 기준으로 판단한다

pull_request_target은 base 저장소 컨텍스트에서 동작하기 때문에 일반 pull_request보다 민감하게 다뤄야 한다.

문제 자체는 trigger 이름이 아니라 attacker-controlled code를 같은 job에서 checkout하고 실행하는 구조다.

Wiz 분석의 핵심도 이 지점이다.

PR에서 온 코드를 실행하면서 base repository의 secret과 권한을 동시에 주면 공격자가 CI를 배포 권한 통로로 바꿀 수 있다.

상황	위험도	허용 판단	대체 구조
외부 PR 라벨링만 수행	낮음	읽기 작업이면 제한적으로 허용	base branch 코드만 checkout
PR 코드 테스트 실행	높음	secret 접근 job과 분리 필요	pull_request trigger로 격리 실행
preview 배포	높음	토큰과 untrusted code 분리 필요	승인 후 별도 workflow_dispatch
패키지 publish	매우 높음	외부 PR 경로에서 금지	protected branch merge 이후 배포
workflow_run 연계	중간 이상	artifact 신뢰성 검증 필요	source workflow와 권한 경계 명시

이 조건이면 pull_request_target을 유지할 수 있다.

job이 PR 코드와 스크립트를 실행하지 않고, label, comment, metadata 조회처럼 base 저장소의 안전한 동작만 수행하는 경우다.

이 조건이면 보류가 맞다.

checkout 대상이 PR head이고, npm install이나 shell script 실행이 있으며, secrets 또는 write token을 같은 job에서 읽는 경우다.

GITHUB_TOKEN은 저장소 기본값보다 job별 권한이 중요하다

GitHub 문서는 action이 명시적으로 전달받지 않아도 github.token 컨텍스트로 GITHUB_TOKEN에 접근할 수 있다고 설명한다.

그래서 workflow에서 token을 쓰지 않는다고 생각해도 permissions 설정을 비워 두면 안전하다고 볼 수 없다.

repository 기본 권한은 read 중심으로 낮추고, issue 작성, pull request comment, package publish 같은 job에서만 필요한 write 권한을 열어야 한다.

Job 유형	권장 permissions 출발점	열 수 있는 권한	검토 owner
lint/test	contents: read	없음	개발 리드
dependency review	contents: read, pull-requests: read	security-events: write	AppSec
comment bot	contents: read	issues 또는 pull-requests write	플랫폼팀
package publish	contents: read	packages write 또는 id-token write	릴리스 owner
deployment	contents: read	deployments write, id-token write	SRE와 보안팀

장기 cloud access key를 secret에 넣는 방식은 사고 때 회수 범위가 커진다.

가능한 환경에서는 OIDC 기반 단기 credential 전환을 검토하고, 불가피한 secret은 environment protection과 rotation 주기를 같이 둔다.

타사 action은 버전 고정만으로 끝나지 않는다

많은 팀이 action을 태그로 고정하면 충분하다고 생각한다.

하지만 태그 이동, owner 권한 변경, 유지보수 중단, build script 변경, release asset 교체 같은 운영 리스크는 여전히 남는다.

OpenSSF Scorecard는 repository의 보안 신호를 점검하는 도구로 쓸 수 있지만, 점수 하나가 구매 승인처럼 동작하면 위험하다.

검토 항목	확인 기준	통과 예시	보류 예시
Owner 신뢰	조직, maintainer, release 기록 확인	공식 vendor 또는 장기 유지 조직	개인 repo, maintainer 불명확
Ref 고정	tag 또는 SHA 정책 선택	release tag와 changelog 확인	main, master, latest 사용
권한 범위	action이 token, network, file system을 어떻게 쓰는지 확인	필요 권한 문서화	권한 설명 없음
Release 신호	최근 릴리스, issue 대응, security policy 확인	보안 공지와 patch 흐름 존재	장기 미관리
대체 가능성	내부 script로 바꿀 수 있는지 확인	간단한 shell로 대체 가능	복잡한 binary 실행만 제공

이 조건이면 third-party action을 쓸 수 있다.

권한이 낮고, owner가 명확하며, 장애 시 내부 script로 대체할 수 있고, release 변경을 code owner가 검토하는 경우다.

이 조건이면 내부 구현을 우선한다.

배포 credential을 다루거나, production artifact에 서명하거나, action 내부가 불투명한 binary를 내려받아 실행하는 경우다.

Dependency review는 개발자 경험을 해치지 않는 선에서 막는다

GitHub dependency review는 PR에서 추가, 삭제, 업데이트된 dependency와 취약점 영향을 보여준다.

이 기능은 보안팀만 보는 대시보드보다 PR gate에 붙을 때 효과가 크다.

다만 모든 minor update를 막으면 개발팀은 우회 경로를 찾는다.

차단 기준은 severity, license, package age, ecosystem, runtime exposure를 나눠야 한다.

변경 유형	자동 차단	수동 검토	허용
Critical CVE 포함	차단	보안 예외 승인 필요	불가
High CVE 포함	차단 또는 owner 승인	외부 노출 서비스면 차단	내부 dev dependency면 조건부
새 maintainer package	차단보다는 검토	다운로드, source, release 확인	위험 낮으면 허용
License 변경	정책 위반이면 차단	법무 또는 오픈소스 담당 검토	허용 license면 통과
Lockfile 대량 변경	차단보다는 diff review	transitive change 원인 확인	자동화 update면 통과

이 조건이면 dependency review를 blocking gate로 둔다.

외부 고객에게 배포되는 package, container, agent, SDK에 직접 들어가는 dependency 변경이다.

이 조건이면 warning gate부터 시작한다.

개발 전용 toolchain 변경이고 배포 산출물에 들어가지 않으며, 보안팀이 false positive 튜닝을 아직 하지 못한 경우다.

SLSA와 provenance는 릴리스 신뢰성을 설명하는 언어다

SLSA 요구사항은 artifact를 만드는 생산자와 build platform의 책임을 나눠서 본다.

핵심은 같은 소스에서 같은 절차로 빌드했고, provenance가 생성되고, 위조되기 어렵고, 빌드 환경이 격리되는지 확인하는 것이다.

작은 팀이 바로 높은 수준을 맞추기는 어렵다.

그래도 release artifact가 고객 환경에 설치된다면 provenance와 SBOM을 검토 항목으로 넣어야 한다.

릴리스 단계	최소 기준	강화 기준	보류 기준
Source	protected branch와 review 필수	signed commit 또는 verified author 검토	직접 push 배포
Build	clean runner와 고정된 workflow	reusable workflow와 권한 분리	개발자 PC 수동 빌드
Dependency	manifest와 lockfile review	SBOM 생성과 보관	lockfile 없는 배포
Artifact	checksum과 release note	provenance 또는 attestation	출처 불명 binary 첨부
Registry	최소 권한 publish token	OIDC 또는 short-lived credential	장기 PAT로 publish

이 조건이면 provenance를 우선 도입한다.

고객이 package, agent, CLI, container image를 내려받아 내부망에서 실행하는 제품이다.

이 조건이면 우선순위를 낮춰도 된다.

내부용 batch workflow이고 외부 배포 artifact가 없으며, 배포 경로가 별도 승인 시스템으로 이미 통제되는 경우다.

비용은 도구보다 false positive와 release 지연에서 나온다

GitHub Actions 공급망 보안은 라이선스 비용만으로 예산을 잡으면 실패한다.

실제 비용은 PR 지연, false positive triage, action allowlist 관리, self-hosted runner 격리, secret rotation 훈련에서 나온다.

보안팀이 모든 workflow 변경을 수동 승인하면 속도 비용이 크다.

반대로 개발팀이 권한을 마음대로 열면 사고 비용이 커진다.

비용 항목	낮게 잡으면 생기는 문제	실무 기준	owner
Workflow review	위험한 trigger가 merge됨	CODEOWNERS와 고위험 패턴 자동 탐지	플랫폼팀
Action inventory	오래된 action과 owner 변경 누락	월간 allowlist review	DevSecOps
Dependency gate	취약 dependency 유입	severity와 license 기준 분리	AppSec
Runner isolation	빌드 토큰과 내부망 접근 확대	repository별 runner group 분리	SRE
Secret rotation	노출 후 복구 지연	rotation runbook과 모의훈련	보안팀

이 조건이면 자동화에 더 투자할 만하다.

매주 수십 개의 workflow와 dependency PR이 생기고, 보안팀 승인 대기 때문에 release가 밀리는 조직이다.

이 조건이면 수동 checklist가 먼저다.

workflow 수가 적고 배포 빈도가 낮으며, 현재 사고면이 pull_request_target과 장기 secret 같은 명확한 항목에 집중된 경우다.

실무 시나리오 1: 오픈소스 저장소의 외부 PR

오픈소스 저장소는 기여자 경험 때문에 PR 자동 테스트를 끄기 어렵다.

이 경우 test job은 pull_request에서 read 권한으로 실행하고, comment, label, preview 배포처럼 권한이 필요한 작업은 base branch 코드만 실행해야 한다.

외부 PR에서 온 코드를 checkout한 뒤 secret을 읽는 구조는 보류가 맞다.

유지보수자는 preview 링크 생성과 package publish를 같은 workflow에 넣지 말고, 승인 후 별도 workflow_dispatch로 분리하는 편이 안전하다.

실무 시나리오 2: SaaS 회사의 npm 패키지 배포

SaaS 회사가 SDK나 CLI를 npm으로 배포한다면 GitHub Actions는 사실상 배포 시스템이다.

dependency review와 secret scanning만으로는 충분하지 않다.

package publish job은 protected branch, environment approval, 최소 권한 token, provenance, release artifact 검증을 함께 지나야 한다.

장기 npm token이 repository secret에 남아 있다면 OIDC 또는 짧은 수명의 배포 credential 전환을 우선 검토한다.

실무 시나리오 3: self-hosted runner를 쓰는 내부 플랫폼

Self-hosted runner는 내부망 접근성과 캐시 때문에 편하지만 공급망 공격의 충격 반경이 커질 수 있다.

외부 PR이 self-hosted runner에서 실행되면 내부 네트워크와 build secret에 접근할 위험이 커진다.

이 조건이면 runner group을 저장소와 신뢰 수준별로 나누고, untrusted PR은 hosted runner나 격리 runner에서만 실행한다.

runner 재사용 캐시는 빌드 속도를 높이지만 악성 파일 잔존과 credential 흔적을 만들 수 있어 clean policy를 문서화해야 한다.

실무 스켈레톤: 공급망 보안 gate workflow

아래 YAML은 바로 복붙해서 끝내는 정답이 아니라, repository별 권한과 gate 위치를 맞추기 위한 출발점이다.

# .github/workflows/supply-chain-guard.yml
# 목적: GitHub Actions 공급망 보안의 기본선을 repository 단위로 고정한다.
# 실제 action 이름, branch, registry, 권한은 조직 정책과 공식 문서 확인 후 조정한다.

name: supply-chain-guard

on:
  pull_request:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pull-requests: read
  security-events: write

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout base-safe code
        uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Dependency review gate
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high
          deny-licenses: GPL-3.0, AGPL-3.0

  action-inventory:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: List workflow action references
        shell: bash
        run: |
          set -euo pipefail
          grep -RhoE 'uses: [^ ]+' .github/workflows             | sed 's/uses: //'             | sort -u             | tee action-inventory.txt
          if grep -Ev '@[0-9a-f]{40}$|@v[0-9]+' action-inventory.txt; then
            echo 'review_unpinned_actions=true' >> "$GITHUB_STEP_SUMMARY"
          fi

핵심은 permissions를 workflow 전체에서 낮추고, dependency와 action inventory를 PR 초기에 보여주는 것이다.

운영 환경에서는 CODEOWNERS, branch protection, repository rules, package registry 권한과 같이 묶어야 한다.

정책 템플릿: workflow 권한과 secret 기준

보안팀과 플랫폼팀은 금지 목록보다 예외 승인 기준을 먼저 합의해야 한다.

{
  "github_actions_supply_chain_policy": {
    "default_token_permissions": "contents:read",
    "allowed_triggers_for_untrusted_code": ["pull_request"],
    "restricted_triggers": ["pull_request_target", "workflow_run"],
    "third_party_actions": {
      "allowlist_required": true,
      "pinning_rule": "tag_or_sha_with_owner_review",
      "exception_owner": "security-engineering"
    },
    "secret_rules": {
      "plain_text_in_workflow": "block",
      "long_lived_cloud_key": "replace_with_oidc_when_possible",
      "log_exposure": "delete_log_and_rotate_secret"
    },
    "release_rules": {
      "dependency_review": "required_for_manifest_or_lockfile_change",
      "provenance_or_attestation": "required_for_release_artifact",
      "sbom": "required_for_container_or_package_release"
    }
  }
}

정책 파일은 문서로만 두면 오래가지 않는다.

workflow lint, pull request template, repository audit script와 연결해야 실제 개발 흐름에서 보인다.

점검 스크립트: 위험한 workflow 패턴 찾기

아래 Python 예시는 GitHub API를 호출하지 않고 저장소 checkout 안에서 obvious pattern을 빠르게 찾는 로컬 점검용이다.

#!/usr/bin/env python3
# gha_supply_chain_audit.py
# 목적: workflow 파일에서 공급망 보안 검토가 필요한 패턴을 빠르게 찾는다.
# 실제 차단은 CODEOWNERS, branch protection, repository rules와 함께 운영한다.

from pathlib import Path
import re

WORKFLOWS = Path('.github/workflows')
RISK_PATTERNS = {
    'pull_request_target': re.compile(r'pull_request_target'),
    'workflow_run': re.compile(r'workflow_run'),
    'broad_token_write': re.compile(r'permissions:\s*write-all|contents:\s*write'),
    'direct_secret_echo': re.compile(r'echo\s+.*secrets\.'),
    'unpinned_action': re.compile(r'uses:\s+[^\s]+@(main|master|latest)'),
    'curl_pipe_shell': re.compile(r'curl\s+[^|]+\|\s*(sh|bash)'),
}

findings = []
for path in WORKFLOWS.glob('*.yml'):
    text = path.read_text(encoding='utf-8')
    for name, pattern in RISK_PATTERNS.items():
        if pattern.search(text):
            findings.append((str(path), name))

if findings:
    for file_name, finding in findings:
        print(f'{file_name}: {finding}')
    raise SystemExit(1)

print('no obvious high-risk workflow pattern found')

정규식 점검만으로 안전을 보장할 수는 없다.

그래도 pull_request_target, broad write token, curl pipe shell 같은 항목은 code review 전에 자동으로 보여줄 가치가 있다.

사고 runbook: 노출 후 30분 안에 할 일

공급망 사고는 탐지보다 회수 속도가 중요하다.

# GitHub Actions 공급망 사고 초동 runbook
# 전제: workflow, package registry, cloud credential, release artifact가 연결된 저장소를 대상으로 한다.

incident_scope:
  repository: service-api
  first_owner: security-engineering
  business_owner: service-owner
  severity_default: high

first_30_minutes:
  - disable_or_pause_suspicious_workflows
  - revoke_exposed_personal_access_tokens_and_cloud_keys
  - rotate_repository_and_environment_secrets
  - lock_release_publish_permissions
  - preserve_workflow_logs_and_runner_metadata

first_2_hours:
  - diff_changed_workflow_files
  - list_third_party_actions_and_versions
  - inspect_pull_request_target_and_workflow_run_paths
  - compare_published_packages_or_images_with_expected_build
  - notify_downstream_service_owners

exit_criteria:
  - no_untrusted_code_runs_with_write_token
  - all_exposed_secrets_rotated
  - release_artifacts_rebuilt_from_clean_branch
  - dependency_and_action_inventory_reviewed
  - post_incident_rule_added_to_repository_policy

초동 조치에서 가장 먼저 할 일은 workflow 중지와 credential 회수다.

그 다음에 악성 PR, 변경된 workflow, 배포된 package, downstream 사용자를 연결해 영향 범위를 줄여야 한다.

도입 전 체크리스트

모든 repository의 workflow trigger를 pull_request, pull_request_target, workflow_run, workflow_dispatch로 분류한다.
GITHUB_TOKEN 기본 권한을 read 중심으로 낮추고 job별 permissions override를 표로 만든다.
uses 항목을 inventory로 뽑아 owner, ref, pinning, 유지보수 상태, 대체 가능성을 검토한다.
외부 PR에서 self-hosted runner가 실행되는 경로를 찾아 차단하거나 격리한다.
dependency review를 manifest와 lockfile 변경 PR에 붙이고 severity와 license 기준을 분리한다.
package publish job은 protected branch, environment approval, OIDC 또는 최소 권한 token을 요구한다.
release artifact에는 checksum, SBOM, provenance 또는 attestation 검토 항목을 둔다.
secret 노출 시 log 삭제, secret rotation, package 재배포, downstream 공지를 포함한 runbook을 만든다.
월 1회 action allowlist와 workflow 권한 예외를 재검토한다.

보안팀과 개발팀이 합의할 운영 기준

공급망 보안은 개발팀을 멈추는 정책이 아니다.

위험한 경로만 빠르게 차단하고, 나머지는 자동 점검과 예외 승인으로 처리해야 지속된다.

합의 항목	개발팀 관점	보안팀 관점	권장 결정
PR 테스트	자동 실행이 필요	untrusted code 권한 제한 필요	read token과 격리 runner
타사 action	반복 작업을 줄임	owner와 release 위험 존재	allowlist와 pinning review
Dependency gate	PR 지연 우려	취약 패키지 유입 차단 필요	severity별 차등 적용
Secret 사용	배포 자동화에 필요	노출 시 registry 장악 가능	OIDC와 environment protection
Release attestation	초기 설정 부담	고객 신뢰와 감사 증거 필요	외부 배포 artifact부터 적용