GitHub Actions 로그 secret scanning 탐지 설정은 엔터프라이즈 소유자가 enterprise settings의 Policies > Advanced Security에서 정책을 켜는 방식으로 진행한다. 이 정책은 GitHub Enterprise Cloud에서 GitHub Secret Protection 또는 GitHub Advanced Security 라이선스로 secret scanning이 켜진 저장소에만 적용된다.
2026-11-09 공개된 이 기능은 public preview 단계다. 활성화 이후 완료된 워크플로 실행의 로그만 provider 패턴으로 스캔하고, preview 동안에는 탐지 결과가 notification으로 오지 않는다. 결과는 저장소의 secret scanning 알림 목록에서 직접 확인한다.
적용 대상과 사전 조건
Secret scanning이 Actions 워크플로 로그를 탐지한다는 GitHub Changelog에 따르면 preview 대상은 GitHub Secret Protection 또는 GitHub Advanced Security를 쓰는 GitHub Enterprise Cloud 엔터프라이즈다. GHE.com 데이터 레지던시를 쓰는 엔터프라이즈도 여기에 포함된다.
정책의 기본값은 꺼짐이다. 켜더라도 모든 저장소가 스캔되지는 않는다. Changelog 원문은 적용 범위를 "repositories with secret scanning enabled under those licenses"로 한정한다.
이 조건은 공개 저장소에서 구분이 필요하다. GitHub Enterprise Cloud의 secret scanning 개념 문서에 따르면 공개 저장소에서는 secret scanning이 무료로 자동 실행된다. 반면 로그 스캔 정책의 조건은 Secret Protection 또는 GHAS 라이선스로 secret scanning이 켜진 저장소다. 조직 소유 private·internal 저장소에서 secret scanning을 쓰려면 GitHub Team 또는 GitHub Enterprise Cloud에서 Secret Protection을 켜야 한다.
| 항목 | 조건 |
|---|---|
| 플랫폼 | GitHub Enterprise Cloud (GHE.com 데이터 레지던시 포함) |
| 라이선스 | GitHub Secret Protection 또는 GitHub Advanced Security |
| 정책 활성화 권한 | 엔터프라이즈 소유자 |
| 대상 저장소 | 위 라이선스로 secret scanning이 켜진 저장소 |
| 알림 상세 열람 권한 | 유출 시크릿이 있는 저장소의 admin 권한자 |
| 정책 기본값 | 꺼짐(disabled) |
권한 조건은 두 곳에서 나뉜다. 정책을 켜는 사람은 엔터프라이즈 소유자다. 알림의 상세 정보와 토큰 메타데이터는 유출된 시크릿이 들어 있는 저장소의 admin 권한자만 볼 수 있다. 엔터프라이즈 소유자가 정책을 켜도 저장소 admin 권한이 없으면 알림 상세를 열 수 없다는 뜻이다. 작업 전에 결과 확인 담당자의 저장소 권한을 함께 점검해 둔다.
개념 문서는 Actions 워크플로 로그의 시크릿 탐지를 “public preview이며 변경될 수 있다”고 명시한다. Changelog와 개념 문서 어디에도 GA 일정은 나와 있지 않다. 이 글의 메뉴 경로와 동작은 2026-11-15 기준이다.
전체 흐름은 저장소 수준의 Secret Protection 활성화, 엔터프라이즈 정책 활성화, 실행 완료 후 자동 스캔의 세 단계다. 정책을 먼저 켜도 저장소에 secret scanning이 없으면 스캔 대상이 되지 않는다. 저장소 쪽 조건부터 맞추는 순서가 확인하기 쉽다.
flowchart LR
A[저장소 Secret Protection 활성화] --> B[엔터프라이즈 정책 Enabled]
B --> C[워크플로 실행 완료]
C --> D[provider 패턴으로 로그 스캔]
D --> E[저장소 secret scanning 알림 목록]단계 1: 대상 저장소에서 Secret Protection 켜기
저장소에서 secret scanning을 활성화하는 공식 절차는 다섯 단계다.
- GitHub에서 대상 저장소의 메인 페이지로 이동한다.
- 저장소 이름 아래의 Settings를 누른다.
- 사이드바 "Security and quality" 섹션에서 Advanced Security를 선택한다.
- "Secret Protection" 오른쪽의 Enable 버튼을 누른다.
- 활성화 영향을 검토하고 Enable Secret Protection으로 확정한다.
저장소가 많으면 하나씩 켜는 대신 일괄 활성화 경로를 쓴다. 조직 소유자는 security configurations로 여러 저장소의 secret scanning을 한 번에 켠다. 조직이 엔터프라이즈 계정에 속해 있다면 엔터프라이즈 소유자가 엔터프라이즈 수준에서 켜는 방법도 있다.
확인 방법: 같은 Settings > Advanced Security 화면에서 Secret Protection 항목이 더 이상 Enable 버튼 상태가 아닌지 본다. 이 단계 문서는 Actions 로그 스캔 설정 자체를 다루지 않으므로, 로그 스캔 정책은 다음 단계에서 별도로 켠다.
단계 2: 엔터프라이즈 정책에서 로그 스캔 활성화
이 단계는 엔터프라이즈 소유자만 수행한다. Changelog에 적힌 경로는 다음과 같다.
- enterprise settings를 연다.
- Policies를 선택한 뒤 Advanced Security로 이동한다.
- "Secret scanning for Actions workflow logs" 정책에서 All repositories 드롭다운을 Enabled로 바꾼다.
Changelog와 개념 문서가 설명하는 활성화 방법은 엔터프라이즈 소유자가 All repositories 단위로 켜는 방식뿐이다. 두 문서에는 조직·저장소 단위의 개별 활성화나 REST API 경로가 나와 있지 않다. 일부 저장소만 대상으로 삼으려면 단계 1의 Secret Protection 적용 범위로 조절하는 구조가 된다.
확인 방법: Policies > Advanced Security 화면을 다시 열어 All repositories 드롭다운 값이 Enabled로 남아 있는지 본다.
단계 3: 워크플로 실행과 자동 스캔
정책을 켠 뒤에는 별도 워크플로 설정이 필요 없다. 개념 문서 원문은 "Once enabled, GitHub scans the logs of each new workflow run after the run completes"다. 실행이 끝나야 스캔이 시작되므로 진행 중인 실행의 로그는 아직 대상이 아니다.
활성화 이전에 끝난 실행은 백필되지 않는다. 정책을 켠 직후 알림 목록이 비어 있는 상태는 정상이다. 동작을 확인하려면 활성화 이후 새 실행이 한 번 이상 완료될 때까지 기다린다.
확인 방법: 대상 저장소의 Actions 탭에서 활성화 시점 이후 완료 상태가 된 실행이 있는지 먼저 본다. 그다음 아래 절의 알림 목록을 확인한다.
secret scanning 알림 확인 절차
탐지 결과는 별도 화면이 아니라 기존 secret scanning 알림 목록에 들어간다. Changelog는 로그에서 나온 결과가 코드 등 다른 콘텐츠의 알림과 함께 표시되고, Actions 워크플로 로그로 돌아가는 링크가 붙는다고 설명한다.
secret scanning 알림 조회·필터링 문서의 저장소 단위 절차는 다음과 같다.
- 저장소 메인 페이지로 이동한다.
- 저장소 이름 아래의 Security and quality 탭을 연다.
- 왼쪽 사이드바 "Vulnerability alerts" 아래의 Secret scanning을 선택한다.
- 목록에서 확인할 알림을 클릭한다.
목록에는 "Generic" 토글도 있다. 이 토글은 generic 패턴이나 AI로 탐지된 시크릿의 알림을 보는 용도다. 로그 스캔은 generic 패턴과 AI 탐지를 대상으로 하지 않는다는 점을 함께 알아 두면 목록을 해석하기 쉽다.
Actions 로그 알림만 따로 골라내는 필터는 Changelog에 소개되어 있지 않다. 알림 상세에 포함된 워크플로 로그 링크가 다른 출처의 알림과 구분하는 단서다.
지원되는 시크릿 유형이면 validity check도 실행된다. 노출된 값이 아직 유효한지를 알림에서 함께 볼 수 있으므로, 폐기·교체 우선순위를 정할 때 참고 자료가 된다.
Actions 워크플로 로그에서 나온 알림은 public preview 동안 notification을 생성하지 않는다. 메일이나 알림 센터만 보고 있으면 노출 사실을 놓친다. 정책을 켠 저장소는 secret scanning 알림 목록을 주기적으로 직접 열어 확인한다.
탐지하지 않는 값과 ::add-mask:: 관계
워크플로 로그에서 secret scanning은 provider 패턴만 탐지한다. 개념 문서와 Changelog가 탐지 제외로 명시한 항목은 네 가지다.
| 탐지 제외 항목 | 근거 원문 |
|---|---|
| generic 패턴 | "Generic patterns … aren’t detected." |
| custom 패턴 | "custom patterns … aren’t detected." |
| AI 탐지 시크릿 | "AI-detected secrets … aren’t detected." |
| Actions가 마스킹한 값 | "secrets already masked by Actions aren’t detected." |
조직에서 custom 패턴으로 사내 토큰 형식을 관리하고 있다면 그 패턴은 로그 스캔에 쓰이지 않는다. 코드 저장소의 custom 패턴 알림과 로그 스캔 결과는 탐지 범위가 다르다.
마스킹된 값이 제외 대상이라는 점에서 ::add-mask::와의 관계가 정리된다. GitHub Actions 워크플로 명령 레퍼런스에 따르면 문법은 ::add-mask::{value}이고, 공백으로 구분된 각 단어가 * 문자로 치환된다. 마스킹은 출력 시점에 값을 가리는 장치이고, 로그 스캔은 마스킹되지 않은 채 남은 provider 시크릿을 실행 완료 후 찾아내는 장치다.
공식 문서의 예제는 런타임에 만든 값을 출력 변수로 넘기기 전에 마스크로 등록한다.
on: push
jobs:
generate-a-secret-output:
runs-on: ubuntu-latest
steps:
- id: sets-a-secret
name: Generate, mask, and output a secret
run: |
the_secret=$((RANDOM))
echo "::add-mask::$the_secret"
echo "secret-number=$the_secret" >> "$GITHUB_OUTPUT"
- name: Use that secret output (protected by a mask)
run: |
echo "the secret number is ${{ steps.sets-a-secret.outputs.secret-number }}"순서가 관건이다. echo "::add-mask::$the_secret"가 $GITHUB_OUTPUT에 쓰는 줄보다 앞에 있고, 두 번째 step의 출력은 마스크로 보호된다.
워크플로 명령 문서는 빌드 로그에 출력하거나 다른 워크플로 명령에 쓰기 전에 `add-mask`로 먼저 등록하라고 경고한다. 등록보다 출력이 먼저 일어나면 그 줄은 마스킹되지 않은 채 로그에 남는다. 이런 값이 provider 패턴에 해당하면 로그 스캔 알림으로 드러나고, 해당하지 않으면 로그 스캔으로도 잡히지 않는다.
제약은 대부분 시점과 범위에 관한 것이다. 운영 체크 항목으로 바꾸면 다음과 같다.
- 백필 없음: 활성화 이후 완료된 실행만 스캔한다. 과거 로그에 남은 노출은 이 기능으로 확인되지 않는다.
- notification 미생성: preview 동안 알림 목록을 직접 확인하는 절차를 운영 루틴에 넣어 둔다.
- 탐지 범위 한정: provider 패턴만 대상이며 generic·custom·AI 탐지와 마스킹 값은 제외된다.
- 알림 보존: 로그를 삭제해도 알림은 남으므로, 대응 완료 처리는 시크릿 교체 후에 한다.
- 변경 가능성: public preview라 동작과 메뉴가 바뀔 수 있다.
공개 대상도 범위를 좁혀 읽어야 한다. Changelog가 명시한 대상은 GitHub Enterprise Cloud이며 GHE.com 데이터 레지던시를 포함한다. 그 밖의 배포 형태는 Changelog의 공개 대상 문장에 들어 있지 않다.
마스킹을 우회하는 노출 경로에 대한 보완은 GitHub Actions 보안 사용 레퍼런스가 다루는 영역이다. 로그 스캔은 노출 이후의 탐지 수단이므로, 시크릿 주입 방식과 마스킹 위치 점검이 앞단에 놓인다.
관련 글
- GitHub Actions Docker 자동 배포 구축 7단계 — 푸시 한 번으로 서버 배포하는 CI/CD 실전 회고 – 데이터 파이프라인 프로젝트에 GitHub Actions와 Docker로 자동 배포를 붙인 회고록. 기술 선택 이유, 실제 워크플로우 설정,…
- AWS GitHub Actions로 ECR·ECS 자동 배포 파이프라인 구축하는 7단계 실전 가이드 – Jenkins에서 GitHub Actions로 CI/CD를 옮기면서 겪은 삽질과 해결 과정. AWS ECR에 이미지 푸시하고 ECS Far…
- TypeScript 7 베타 벤치마크 실측 5가지 — CI 환경 성능 병목 완전 분석 – TypeScript 7의 Go 네이티브 컴파일러가 10배 빠르다고 알려졌지만, GitHub Actions CI 환경에서는 28%에 그치는 …
자주 묻는 질문
공개 저장소에도 Actions 로그 스캔이 적용되나?
공개 저장소는 secret scanning이 무료로 자동 실행된다. 다만 로그 스캔 정책의 적용 조건은 GitHub Secret Protection 또는 GHAS 라이선스로 secret scanning이 켜진 저장소로 적혀 있다. 대상 여부는 이 라이선스 조건으로 판단한다.
정책을 켰는데 알림이 하나도 없으면 실패한 것인가?
그렇게 단정할 수 없다. 활성화 이전에 끝난 실행은 백필되지 않고, 활성화 이후 완료된 실행만 스캔된다. 탐지 대상도 provider 패턴으로 한정되므로, 새 실행 완료 여부와 저장소의 Secret Protection 상태를 먼저 확인한다.
로그를 삭제하면 알림도 없어지나?
없어지지 않는다. Changelog는 로그가 삭제된 뒤에도 알림이 유지된다고 명시한다. 노출된 시크릿은 로그 삭제와 무관하게 폐기·교체 대상이다.
custom 패턴으로 등록한 사내 토큰도 로그에서 잡히나?
Actions 워크플로 로그에서는 custom 패턴을 탐지하지 않는다. generic 패턴과 AI 탐지 시크릿도 마찬가지로 제외된다. 사내 토큰은 출력 전 ::add-mask:: 등록으로 노출 자체를 막는 쪽이 기본 대책이다.
연관 설정과 확장 주제
로그 스캔은 저장소 수준의 GitHub secret scanning 설정 위에서만 동작하므로, 조직 단위로 security configurations를 설계하는 방법이 자연스러운 다음 주제다. GitHub Advanced Security 엔터프라이즈 정책 전반과 GitHub Secret Protection 라이선스 범위를 정리해 두면 어떤 저장소가 스캔 대상인지 한눈에 관리된다. 커밋 단계에서 시크릿 유입을 막는 push protection, 그리고 GitHub Actions 시크릿 마스킹을 워크플로 전반에 일관되게 적용하는 패턴도 로그 스캔과 함께 다룰 영역이다.