GitHub Actions 리드·아키텍트 보안 면접

Fork된 레포지토리의 PR에서는 기본적으로 secrets 접근을 차단해야 합니다. pull_request 이벤트는 fork에서 secrets에 접근할 수 없지만, pull_request_target은 base 레포지토리 컨텍스트로 실행되어 위험합니다. 따라서 민감한 작업은 Environment Protection Rules를 활용해 승인 프로세스를 거치도록 설계하고, secrets는 가능한 짧은 수명의 토큰(OIDC)으로 대체해야 합니다. 또한 workflow에서 secrets를 echo하거나 로그에 출력하지 않도록 정적 분석 도구를 CI에 통합하고, 조직 수준에서 secrets 사용을 모니터링하는 거버넌스 체계를 구축해야 합니다. 마지막으로 least privilege 원칙에 따라 각 workflow별로 필요한 최소한의 권한만 부여하는 GITHUB_TOKEN 스코프 전략을 수립해야 합니다.

서드파티 액션은 SHA 해시로 버전을 고정해야 하며, 태그나 브랜치 참조는 공격자가 악의적 코드로 교체할 수 있어 위험합니다. 조직 수준에서는 허용된 액션만 사용할 수 있도록 화이트리스트 정책을 적용하고, GitHub의 'Allow select actions' 기능을 활용해야 합니다. 또한 Dependabot을 통해 액션 버전 업데이트를 자동 모니터링하고, 각 업데이트마다 diff 리뷰를 의무화해야 합니다. 중요한 workflow에는 검증된 퍼블리셔의 액션만 사용하거나, 내부적으로 fork하여 보안 감사를 거친 후 사용하는 전략이 필요합니다. 마지막으로 SBOM(Software Bill of Materials)을 생성하여 모든 액션 의존성을 추적하고, 정기적인 보안 감사를 수행해야 합니다.

github.event.pull_request.title 같은 사용자 제어 가능한 값을 직접 run 스크립트에 삽입하면 악의적인 명령어가 실행될 수 있습니다. 예를 들어 PR 제목에 백틱이나 세미콜론을 포함시켜 임의의 명령을 실행할 수 있습니다. 이를 방지하려면 사용자 입력을 환경변수로 먼저 설정하고, 스크립트에서는 환경변수를 참조해야 합니다. 또한 입력값에 대한 검증과 sanitization을 수행하고, 가능하면 actions/github-script 같은 안전한 방식으로 처리해야 합니다. 조직 차원에서는 workflow 코드에 대한 정적 분석 도구를 도입하여 위험한 패턴을 자동 탐지하고, 코드 리뷰 시 보안 체크리스트를 의무화해야 합니다. 또한 최소 권한 원칙에 따라 GITHUB_TOKEN의 권한을 제한하여 피해 범위를 최소화해야 합니다.

조직 수준에서 GITHUB_TOKEN의 기본 권한을 read-only로 설정하고, 각 workflow에서 필요한 권한만 명시적으로 선언하도록 강제해야 합니다. permissions 키를 workflow 파일 최상위 또는 job 레벨에 명시하여 최소 권한 원칙을 적용하고, contents: write나 packages: write 같은 민감한 권한은 정당한 사유가 있을 때만 허용해야 합니다. 조직 정책으로 'Restrict permissions for GITHUB_TOKEN'을 활성화하고, 정기적으로 권한 사용 현황을 감사하여 과도한 권한을 사용하는 workflow를 식별해야 합니다. 또한 branch protection rules와 결합하여 특정 브랜치에 대한 쓰기 권한을 제한하고, 중요한 작업은 Environment를 통해 추가 승인을 요구하도록 설계해야 합니다.

add-mask 명령어를 사용하여 동적으로 생성된 민감한 값을 자동으로 마스킹하고, secrets는 자동으로 마스킹되지만 base64 인코딩 등으로 변형된 값은 노출될 수 있으므로 주의해야 합니다. 조직 수준에서는 GitHub Enterprise의 audit log API를 활용하여 모든 workflow 실행, secrets 접근, 설정 변경 등을 중앙에서 수집하고 SIEM(Splunk, DataDog 등)과 통합해야 합니다. workflow 실행 로그는 최소 90일 이상 보관하고, 민감한 작업에 대해서는 누가, 언제, 무엇을 실행했는지 추적 가능하도록 메타데이터를 기록해야 합니다. 또한 정기적으로 로그를 분석하여 비정상적인 패턴(예: 실패율 급증, 비정상 시간대 실행)을 탐지하고, 알림을 설정해야 합니다. 규제 준수가 필요한 경우 변조 방지를 위해 로그를 immutable storage에 보관하는 것도 고려해야 합니다.

self-hosted runner는 GitHub hosted runner와 달리 영구적인 환경에서 실행되어 이전 작업의 아티팩트나 악성 코드가 남을 수 있습니다. 따라서 ephemeral runner 패턴을 적용하여 매 작업마다 새로운 VM이나 컨테이너를 프로비저닝하고 작업 후 즉시 폐기해야 합니다. 네트워크 측면에서는 runner를 DMZ나 격리된 VLAN에 배치하고, 내부 네트워크로의 접근은 최소한으로 제한해야 합니다. 특히 public 레포지토리의 workflow는 절대 self-hosted runner에서 실행하지 않도록 정책을 수립하고, private 레포지토리만 허용해야 합니다. runner 그룹을 활용하여 민감도에 따라 runner를 분리하고, 각 그룹별로 접근 가능한 레포지토리를 제한해야 합니다. 또한 runner에서 외부로 나가는 트래픽을 프록시를 통해 모니터링하고, 의심스러운 연결을 차단하는 egress filtering을 구현해야 합니다.

규제 준수를 위해서는 먼저 데이터 레지던시 요구사항을 확인하고, 필요시 GitHub Enterprise Server(on-premise)나 특정 리전에 데이터를 보관하는 옵션을 고려해야 합니다. GitHub와 DPA(Data Processing Agreement)를 체결하고, GitHub의 SOC 2, ISO 27001 인증을 확인하여 데이터 처리자로서의 책임을 명확히 해야 합니다. 민감한 개인정보나 PHI, PCI 데이터는 절대 workflow나 로그에 노출되지 않도록 하고, 필요시 토큰화나 암호화를 거쳐 처리해야 합니다. 감사 로그는 변조 방지 스토리지에 최소 7년 보관하고, 접근 권한은 역할 기반으로 엄격히 제한해야 합니다. 또한 정기적인 보안 평가와 침투 테스트를 수행하고, 모든 workflow 변경사항에 대한 승인 프로세스를 구축해야 합니다. 마지막으로 incident response plan을 수립하여 보안 사고 발생 시 규제 기관에 적시에 보고할 수 있는 체계를 마련해야 합니다.

아티팩트의 무결성을 보장하기 위해 Sigstore의 Cosign을 활용하여 컨테이너 이미지에 서명하고, keyless signing을 통해 OIDC 기반으로 인증해야 합니다. SLSA(Supply-chain Levels for Software Artifacts) 프레임워크를 적용하여 빌드 프로세스의 provenance를 생성하고, 어떤 소스 코드에서 어떤 빌드 과정을 거쳐 아티팩트가 생성되었는지 검증 가능하게 만들어야 합니다. GitHub의 artifact attestation 기능을 활용하여 빌드 메타데이터를 아티팩트와 함께 저장하고, 배포 시점에 이를 검증하는 정책을 수립해야 합니다. 컨테이너 이미지는 SBOM을 함께 생성하여 모든 의존성을 추적하고, 취약점 스캔을 자동화해야 합니다. 또한 이미지 레지스트리에 admission control을 적용하여 서명되지 않은 이미지의 배포를 차단하고, OPA나 Kyverno 같은 정책 엔진으로 런타임 검증을 수행해야 합니다.

Dependabot을 활성화하여 workflow에서 사용하는 GitHub Actions와 의존성의 보안 업데이트를 자동으로 탐지하고 PR을 생성하도록 설정해야 합니다. CodeQL을 통해 workflow 파일 자체의 보안 취약점과 안티패턴을 정적 분석하고, 커스텀 쿼리로 조직 특화 보안 규칙을 검증해야 합니다. 모든 workflow에 보안 스캔 단계를 필수로 포함시켜 SAST, SCA, 컨테이너 스캔을 자동화하고, 임계값 이상의 취약점이 발견되면 빌드를 실패시켜야 합니다. 조직 차원에서는 Security Champions를 지정하여 각 팀의 workflow 보안을 책임지게 하고, 월간 보안 리뷰를 통해 전체 조직의 취약점 현황을 파악해야 합니다. 또한 취약점 SLA를 정의하여 Critical 취약점은 24시간 내, High는 7일 내 패치하도록 프로세스를 수립하고, 이를 추적하는 대시보드를 구축해야 합니다.

조직 수준에서 GitHub Enterprise 정책을 활용하여 기본 보안 설정을 강제하고, 모든 레포지토리에 자동 적용되도록 해야 합니다. 공통 보안 요구사항은 reusable workflow로 중앙화하여 각 팀이 재사용하도록 하고, 보안 업데이트 시 한 곳만 수정하면 모든 workflow에 반영되도록 설계해야 합니다. Policy as Code 접근으로 OPA나 Conftest를 활용하여 workflow 파일이 조직 보안 정책을 준수하는지 자동 검증하고, PR 단계에서 위반사항을 차단해야 합니다. 중앙 보안 팀은 GitHub API를 활용한 자동화 스크립트로 모든 레포지토리의 보안 설정(branch protection, secrets 사용, runner 설정 등)을 주기적으로 스캔하고, 비준수 항목을 식별하여 자동으로 티켓을 생성해야 합니다. 보안 메트릭 대시보드를 구축하여 조직 전체의 보안 posture를 가시화하고, 경영진에게 리스크를 보고할 수 있어야 합니다. 마지막으로 정기적인 보안 교육과 게임데이 훈련을 통해 개발자들의 보안 인식을 높여야 합니다.