GitHub Secret Scanning Supabase·Lovable 키 탐지｜유출 경고 대응법
먼저 결론: GitHub는 2026년 10월 5일 Secret Scanning에 Lovable·Pydantic·Supabase 관련 비밀 유형 5종 탐지를 추가했습니다. 실제 키 유출이 확인되면 코드에서 지우는 것에 그치지 말고, 발급 서비스에서 기존 키를 폐기하고 새 키로 CI·배포 환경을 갱신해야 합니다.
API 키와 토큰은 프로그램이 서비스에 접근할 때 사용하는 인증 정보입니다. 비밀번호처럼 보호해야 하며, 저장소에 넣으면 다른 사람이 해당 권한을 사용할 수 있습니다. 이 글은 새로 추가된 탐지 유형, 설정 확인, 유출 경고 대응을 처음 사용하는 사람도 따라갈 수 있도록 정리했습니다.
발표일: 2026년 10월 5일 · 문서 확인 기준: 2026년 10월 6일 · GitHub.com 공식 문서 기준
목차
1. Lovable·Pydantic·Supabase 탐지 유형 5종
공식 Changelog에 명시된 식별자는 다음과 같습니다. 경고 화면이나 API 결과의 비밀 유형을 이 이름과 대조하면 발급 서비스를 구분하기 쉽습니다.
| 제공자 | 탐지 유형 | 이름을 이해하는 방법 |
|---|---|---|
| Lovable Labs | lovable_api_key |
Lovable API 키 |
| Pydantic Services Inc. | logfire_token |
Logfire 토큰 |
| Pydantic Services Inc. | pydantic_ai_gateway_api_key |
Pydantic AI Gateway API 키 |
| Supabase | supabase_oauth_access_token |
Supabase OAuth 액세스 토큰 |
| Supabase | supabase_scoped_personal_access_token |
권한 범위가 지정된 Supabase 개인 액세스 토큰 |
확인된 추가 사항: Lovable Labs는 이번 발표에서 새 Secret Scanning 파트너로 소개됐습니다. Supabase의 모든 키나 모든 형태의 비밀이 탐지된다는 의미는 아닙니다. 발표가 확인해 주는 범위는 위 5종입니다.
2. Secret Scanning 활성화는 어디서 확인하나요?
공개 저장소에서는 Secret Scanning이 무료로 자동 실행됩니다. 조직 소유 비공개·내부 저장소는 GitHub Team 또는 Enterprise Cloud에서 GitHub Secret Protection 이용 조건과 활성화 상태를 확인해야 합니다. 개인 소유 비공개 저장소에 공개 저장소와 동일한 조건이 적용된다고 가정하지 마세요.
- 대상 저장소를 열고 Settings로 이동합니다.
- 사이드바의 Security and quality → Advanced Security를 엽니다.
- Secret Protection 상태를 확인합니다. 비활성 상태라면 이용 조건·비용·적용 영향을 검토한 뒤 Enable → Enable Secret Protection으로 활성화합니다.
- 저장소의 Security and quality → Secret scanning에서 사용자 경고를 확인합니다.
메뉴가 보이지 않으면 저장소 관리자 권한과 조직 정책을 확인하세요. 화면에 별도의 Secret scanning 활성화 항목이 표시되면 그 상태도 점검합니다. 경고가 0개라는 사실만으로 탐지 기능 활성화나 유출 부재를 판단할 수는 없습니다.
3. 공개 저장소 파트너 통보와 사용자 경고의 차이
| 구분 | 전달 대상·처리 경로 | 사용자가 할 일 |
|---|---|---|
| Partner 통보 | 공개 저장소에서 파트너 패턴을 발견하면 발급 서비스에 직접 전달. 서비스가 검증 후 폐기·재발급·연락 여부를 결정 | 발급 서비스에서 기존 키 상태와 통지를 확인하고 의존 서비스 갱신 |
| User 경고 | 지원되는 공개·비공개 저장소에서 탐지되면 저장소 보안 화면에 표시 | 소유자 확인, 키 폐기·교체, 영향 조사, 조치 후 경고 종료 |
파트너 통보 자체는 저장소의 사용자 경고 목록에 표시되지 않습니다. 같은 비밀 유형이 User 경고도 지원하면 별도의 사용자 경고가 생길 수 있습니다. 파트너에게 전달됐다는 사실은 내 서비스의 키 교체와 재배포까지 완료됐다는 뜻이 아닙니다.
공개 저장소 파트너 패턴 스캔은 사용자가 설정을 변경할 수 없습니다. 비공개 저장소의 사용자 경고를 공개 저장소와 동일한 자동 파트너 통보로 해석하지 마세요.
4. 유출 경고가 발생했을 때 대응 순서
- 대상 확인: 발급 서비스, 키 소유자, 파일·커밋, 노출 시점과 사용처를 확인합니다. 키 원문을 공개 이슈나 메신저에 복사하지 마세요.
- 기존 키 폐기: 실제 유출된 키는 침해된 것으로 취급하고 발급 서비스에서 폐기합니다. 권한이 없다면 키 소유자에게 즉시 조치를 요청합니다.
- 새 인증 정보 발급: 필요한 경우 새 키를 발급하거나 해당 서비스의 재인증 절차를 진행합니다. 서비스 중단을 줄이기 위해 교체 후 폐기하는 방식이 필요해도 기존 키를 계속 활성 상태로 방치하지 마세요.
- 사용처 갱신·검증: CI, 배포 플랫폼, 서버의 비밀 설정을 교체하고 정상 동작을 확인합니다.
- 영향 확인·정리: 발급 서비스 사용 기록과 감사 로그에서 비정상 접근을 확인합니다. 코드와 다른 노출 위치를 정리하고, Git 이력 정리는 협업 영향을 검토해 진행합니다.
- 경고 종료: 실제 폐기를 확인한 뒤 해당 사용자 경고를 Close as → Revoked로 종료하고 조치 내용을 기록합니다.
파일 삭제만으로 끝나지 않습니다. 코드에서 키를 지우거나 저장소를 삭제해도 이미 복사된 인증 정보의 효력은 없어지지 않습니다. 인증을 차단하는 핵심 조치는 발급 서비스에서의 폐기입니다. 폐기 메뉴와 재발급 방식은 서비스·토큰 종류별 공식 안내를 확인하세요.
키 대응 후 코드 취약점 수정과 검증 절차도 확인하세요
Secret Scanning의 인증 정보 유출 대응과 Agentic Autofix의 코드 취약점 수정은 역할이 다릅니다. 코드 수정 PR을 적용했다고 외부 서비스의 유출 키가 폐기되는 것은 아닙니다.
5. CI 환경변수와 GitHub Actions 점검
CI는 코드를 올릴 때 테스트·빌드·배포를 자동 실행하는 과정입니다. 새 키를 발급해도 자동화가 이전 키를 계속 사용하면 인증 오류가 발생합니다. 다음은 키 교체 시 사용할 실무 점검 목록입니다.
- 저장 위치: Settings → Secrets and variables → Actions의 저장소·환경 비밀과 조직 비밀 적용 범위를 확인합니다.
- Variables와 구분: API 키는 일반 Variables 대신 Secrets 또는 전용 비밀 관리 도구에 저장합니다.
- 참조 이름: 워크플로의 secrets 이름과 등록 이름이 일치하는지 확인합니다. 개발·스테이징·운영의 같은 이름도 각각 점검합니다.
- 배포 환경: 호스팅 플랫폼·서버 설정을 갱신하고, 재배포나 프로세스 재시작이 필요한지 확인합니다.
- 로그·산출물: 키 원문을 출력하지 않습니다. 실패 로그, 빌드 산출물, 첨부 파일에 노출됐는지 확인하고 접근을 제한합니다.
- 재검증: CI와 배포를 실행해 인증·필수 기능을 확인하고 기존 키의 폐기를 발급 서비스에서 확인합니다.
아래는 GitHub Actions의 키 참조 방식 예시입니다. 환경변수 이름은 이 글의 예시이며, 탐지 유형 식별자와는 별개입니다. 실제 실행 명령은 프로젝트에 맞게 작성하세요.
# 작업(job) 또는 단계(step)의 env 설정 예시
env:
APP_SERVICE_TOKEN: ${{ secrets.APP_SERVICE_TOKEN }}Secrets를 환경변수로 전달해도 브라우저용 빌드에 포함되거나 로그에 출력되면 노출될 수 있습니다. 관리자용 키와 토큰이 최종 공개 파일에 들어가지 않는지도 확인하세요.
출처: GitHub Actions에서 Secrets 사용하기
키 교체 뒤 빌드 실패가 이어지면 실행 환경도 점검하세요
6. 자주 묻는 질문
Supabase의 모든 키가 새로 탐지되나요?
이번 발표에 적힌 Supabase 유형은 OAuth 액세스 토큰과 권한 범위가 지정된 개인 액세스 토큰입니다. 다른 Supabase 키의 지원 여부는 최신 지원 패턴 목록에서 별도로 확인해야 합니다.
탐지 추가는 Push Protection도 모두 지원한다는 뜻인가요?
탐지, 푸시 차단, 유효성 검사는 지원 항목이 구분됩니다. 이번 발표만으로 5종 모두의 Push Protection·유효성 검사 지원을 단정할 수 없습니다. 공식 지원 패턴 표의 해당 열을 확인하세요.
경고가 Unknown이면 사용하지 않는 키인가요?
Unknown은 비활성 확인을 뜻하지 않습니다. 모든 유형에서 유효성 검사를 지원하는 것도 아닙니다. 키 상태는 발급 서비스에서 확인하세요.
키를 코드에서 지웠는데 경고가 남아 있나요?
GitHub는 저장소에서 키를 제거했다고 경고를 자동 종료하지 않습니다. 실제 대응 후 적절한 사유로 종료해야 합니다. 공식 경고 종료 안내를 참고하세요.
7. 확인된 사실과 추가 확인할 항목
공식 확인: 2026년 10월 5일 비밀 유형 5종 탐지 추가, Lovable 파트너 참여, 공개 저장소 파트너 통보와 사용자 경고의 처리 경로 차이입니다.
내 저장소에서 확인: Secret Protection 활성화·이용 조건, 실제 경고, 키 유효 상태, CI 사용처, 유형별 Push Protection·유효성 검사 지원 여부입니다. 이 글은 독자의 저장소와 서비스 계정 상태를 확인한 결과가 아닙니다.
대응 핵심: 탐지·설정 확인 → 발급 서비스에서 키 폐기·교체 → CI·배포 갱신 → 비정상 사용 조사 → 사용자 경고 종료. 파트너 통보를 받았어도 새 키 적용과 정상 동작은 직접 확인해야 합니다.
발표 내용은 GitHub Changelog 원문, 기능별 지원 범위는 지원 패턴 목록을 기준으로 확인하세요.
