XEIZE
/취약점 모음/Secret/Secret in CI/CD

Secret in CI/CD

배포 스크립트, GitHub Actions workflow, GitLab CI, Jenkinsfile에 Secret이 직접 들어가 있으면 저장소 유출뿐 아니라 빌드 로그를 통해서도 노출될 수 있습니다.

이런 경우에 참고

  • .github/workflows/*.yml에 토큰이 직접 들어간 경우
  • Jenkinsfile, .gitlab-ci.yml, 배포 쉘 스크립트에 자격 증명이 있는 경우
  • 빌드 시점 토큰을 환경 변수 대신 파일에 적어둔 경우

권장 방식

  • Secret은 CI/CD 플랫폼의 Secret 저장 기능을 사용합니다.
  • 워크플로 파일에는 참조 표현만 남깁니다.
  • 로그 마스킹, 권한 최소화, 회전 정책을 함께 점검합니다.
  • 클라우드 배포 용도라면 가능하면 장기 고정 Secret 대신 OIDC 같은 단기 자격 증명 연동을 우선 검토합니다.

예시

변경 전

yaml
steps:
  - name: Deploy
    run: |
      curl -H "Authorization: Bearer ghp_xxxxxxxxx" https://example.com/deploy

변경 후

yaml
steps:
  - name: Deploy
    env:
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    run: |
      curl -H "Authorization: Bearer ${DEPLOY_TOKEN}" https://example.com/deploy

담당자 조치 절차

  1. 노출된 기존 토큰은 먼저 폐기하고 새 값으로 교체합니다.
  2. workflow, Jenkinsfile, CI 설정 파일, 배포 스크립트에서 실제 Secret 값을 제거합니다.
  3. 새로 발급한 토큰 또는 비밀번호를 CI/CD Secret 저장소에 등록합니다.
  4. 파일에는 ${{ secrets.NAME }} 또는 플랫폼별 참조 문법만 남깁니다.
  5. 클라우드 제공자 접근이라면 OIDC 기반 federation으로 대체 가능한지 검토합니다.
  6. 최근 실행 로그에 값이 노출되었는지 확인합니다.

담당자에게 안내할 문구 예시

  • "워크플로 파일에 저장된 토큰은 제거하고 GitHub Actions Secrets 또는 사용 중인 CI 자격 증명 저장소로 이전하세요."
  • "CI/CD 설정 파일에는 Secret 원문 대신 참조 표현만 남겨야 합니다."
  • "기존 빌드 로그에 Secret 값이 남아 있을 수 있으니 최근 실행 내역도 함께 확인하세요."

추가 확인 사항

  • 로그 마스킹이 실제로 동작하는가
  • PR from fork 같은 외부 트리거에 Secret이 노출될 수 없는가
  • 배포 전용 토큰 권한이 과도하지 않은가
  • 장기 액세스 키 대신 OIDC 또는 workload identity로 대체할 수 있는가
XEIZE Documentation기술 지원