CI/CD 파이프라인은 이제 공격 표면이다
Novee Security가 공개한 Cordyceps 취약점 패턴은 CI/CD 파이프라인에 인증 없이 접근할 수 있는 구조적 약점을 드러낸 사례다. 많은 팀이 CI/CD를 "빌드와 배포를 자동화하는 내부 도구" 정도로 인식하지만, 이 사례는 파이프라인 자체가 독립적인 공격 경로가 될 수 있다는 점을 명확히 보여준다. 프로덕션 코드에 아무리 철저한 보안을 적용하더라도, 배포 인프라에 허점이 있다면 의미가 크게 퇴색된다.
백엔드 개발자 입장에서 이 문제가 중요한 이유는 간단하다. CI/CD 파이프라인은 소스 코드, 시크릿, 클라우드 자격 증명, 프로덕션 배포 권한까지 모두 접근할 수 있는 위치에 있다. 파이프라인이 탈취되면 단순한 서버 침해가 아니라 공급망 전체가 위협받는 시나리오로 이어진다.
실무에서 놓치기 쉬운 파이프라인 접근 제어
CI/CD 환경에서 인증 및 접근 정책이 느슨해지는 데는 현실적인 이유가 있다. 초기에는 빠른 개발 속도를 위해 접근 제한을 최소화하고, 이후에도 "내부망이니까 괜찮겠지"라는 암묵적인 가정이 이어지는 경우가 많다. 그러나 클라우드 네이티브 환경에서는 내부망이라는 경계가 사실상 무의미해진 지 오래다.
특히 주의해야 할 설정들은 다음과 같다.
- 익명 트리거 허용: Webhook이나 API 엔드포인트에 인증 없이 파이프라인을 실행할 수 있는 구조
- 과도한 권한의 서비스 계정: 파이프라인 실행 계정이 프로덕션 리소스에 직접 접근 가능한 경우
- 시크릿의 평문 노출: 환경 변수나 로그에 노출된 API 키, DB 패스워드
- PR 기반 파이프라인의 외부 기여자 실행 허용: 공개 저장소에서 포크된 PR이 시크릿에 접근 가능한 파이프라인을 트리거하는 경우
# GitHub Actions 예시 - 외부 PR에서 시크릿 접근을 막는 설정
on:
pull_request_target:
# pull_request_target은 base 브랜치 컨텍스트에서 실행되므로
# 외부 기여자 PR에서는 시크릿 노출에 주의 필요
types: [opened, synchronize]
jobs:
build:
if: github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
파이프라인 보안을 설계에 포함시켜야 하는 이유
Cordyceps 패턴이 시사하는 핵심은 "발견되기 전까지는 문제없다"는 사고방식의 위험성이다. 접근 제어가 없는 파이프라인은 내부에서는 편리하지만, 동시에 외부 공격자에게도 동등하게 열려 있다. 특히 Jenkins, GitLab CI, GitHub Actions 같은 도구들은 설정 복잡도가 높아, 의도치 않은 개방이 발생하기 쉽다.
실무적으로 적용할 수 있는 방향은 다음과 같다.
# 파이프라인 실행 계정의 실제 권한 확인 (AWS 예시)
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::ACCOUNT_ID:role/ci-pipeline-role \
--action-names s3:PutObject ec2:DescribeInstances \
--resource-arns "*"
- 파이프라인 실행 계정은 최소 권한 원칙(Least Privilege) 을 철저히 적용한다
- 시크릿은 파이프라인 내 환경 변수가 아닌 Vault, AWS Secrets Manager 같은 전용 도구로 관리한다
- 파이프라인 설정 파일(
.yml)도 코드 리뷰 대상에 포함시켜 보안 관점의 검토를 정례화한다 - 주기적으로 파이프라인의 트리거 조건과 접근 권한을 감사(Audit)한다
정리
- CI/CD 파이프라인은 코드·시크릿·배포 권한을 모두 쥔 고가치 공격 표면이며, 인증 정책 부재는 심각한 보안 위협으로 직결된다
- 익명 트리거, 과도한 서비스 계정 권한, 시크릿 평문 노출 등 실무에서 흔히 묵인되는 설정이 주요 취약 지점이다
- 파이프라인 보안은 운영팀만의 영역이 아니라, 백엔드 개발자가 설계 단계부터 함께 검토해야 할 개발 문화의 문제다