[G1-Sync] Manual knowledge update
This commit is contained in:
@@ -2,152 +2,221 @@
|
||||
id: wiki-2026-0508-secrets-detection
|
||||
title: Secrets Detection
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Credential Scanning, Leaked Secrets, Git Secret Scanning]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [security, secrets, gitleaks, trufflehog, devsecops]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Go
|
||||
framework: gitleaks
|
||||
---
|
||||
|
||||
# [[비밀 키 탐지와 민감 정보 노출 방지 전략 (Secrets Detection)]]
|
||||
# Secrets Detection
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
비밀 키 탐지(Secrets Detection)는 애플리케이션의 소스 코드, CI/CD 파이프라인, 설정 파일 등에 하드코딩된 민감한 정보(API 키, 인증 토큰, 비밀번호 등)가 노출되는 것을 식별하고 방지하는 보안 프로세스입니다 [1-3]. 이는 정적 분석(SAST)이나 AI 코드 리뷰 도구를 통해 자동화되며, 개발 주기 초기에 민감한 데이터의 유출을 차단하여 보안 침해 및 컴플라이언스 위반을 예방하는 역할을 합니다 [3-5].
|
||||
## 매 한 줄
|
||||
> **"매 secret 의 leak 은 git history 의 forever — 매 prevention(pre-commit) > detection(CI) > remediation(rotate + rewrite history)"**. 매 origin 은 2014 GitHub 의 AWS key 대량 leak; 매 modern state 는 gitleaks/trufflehog v3 (entropy + verifier), GitHub Push Protection, AI-aided context analysis (Claude Opus 4.7 으로 매 false positive triage).
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **비밀 키 하드코딩의 위험성과 방지:** API 키나 데이터베이스 비밀번호를 코드에 직접 하드코딩한 채 버전 관리 시스템(예: GitHub)에 푸시하면, 누구나 해당 정보에 접근할 수 있는 심각한 보안 위험이 발생합니다 [1]. 이를 방지하기 위해서는 비밀 키를 `.env` 파일과 같은 환경 변수로 관리하고, 버전 관리 대상에서 제외하도록 `.gitignore`에 추가하는 것이 필수적인 개발 관행입니다 [1].
|
||||
* **탐지 도구의 활용과 기능:** Cycode, SonarQube, Semgrep, Spectral과 같은 코드 분석 플랫폼들은 비밀 키 탐지 기능을 주요 기능으로 제공합니다 [2, 3, 6, 7]. 예를 들어, Spectral은 비밀 키와 CI/CD 파이프라인의 민감 데이터 유출 및 구성 오류를 프로덕션 환경에 도달하기 전에 탐지하는 데 특화되어 있습니다 [3]. Semgrep과 같은 도구는 단순한 패턴 매칭을 넘어 엔트로피 검증(Entropy Validation)과 시맨틱 분석(Semantic Analysis)을 통해 비밀 키를 탐지합니다 [7].
|
||||
* **코드 리뷰 및 파이프라인 통합:** 안전한 코드베이스를 유지하기 위해서는 일상적인 코드 리뷰 및 CI/CD 워크플로우에 비밀 키 탐지를 자동화하여 통합해야 합니다 [5, 8]. 최신 AI 코드 리뷰 도구(예: Qodo, Traycer)를 활용할 때 "주입 위험(injection risks), 인증/인가 문제, 비밀 키 노출(secret exposure)" 등에 초점을 맞추도록 명시적인 프롬프트를 제공하여 하드코딩된 비밀 키를 조기에 잡아낼 수 있습니다 [9-11].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **위양성(False Positives)과 개발자 피로도:** 자동화된 비밀 키 스캐닝 도구는 실제 비밀 키가 아닌 문자열을 비밀 키로 오인하는 위양성 비율이 높을 수 있습니다. 이는 개발자의 신뢰를 떨어뜨리고 리소스 낭비와 알림 피로도(Alert Fatigue)를 유발할 수 있으므로, AI 기반의 우선순위 지정이나 엔트로피 분석 등을 통해 실제로 악용 가능한 문제를 선별하는 튜닝 작업이 필수적입니다 [7, 12, 13].
|
||||
* **단일 도구 커버리지의 한계:** Spectral과 같이 비밀 키 탐지에 강점을 가지는 도구라도 SAST(정적 애플리케이션 보안 테스트)의 전체적인 깊이 측면에서는 한계가 있을 수 있습니다. 따라서 완전한 보안 시야를 확보하기 위해서는 비밀 키 전용 탐지 도구를 다른 종합 보안 스캐너와 병행하여 사용해야 하는 구성의 복잡성(Trade-off)이 발생할 수 있습니다 [14].
|
||||
### 매 detection 의 3 layer
|
||||
- **Pre-commit (local)**: gitleaks pre-commit hook — 매 push 전 차단.
|
||||
- **CI (PR)**: gitleaks/trufflehog GitHub Action — 매 PR diff scan.
|
||||
- **Org-wide (continuous)**: GitHub Advanced Security secret scanning, GitGuardian, 매 historical scan.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[DevSecOps_Framework]]: 시크릿 탐지가 포함되는 전체 보안 프로세스.
|
||||
- [[Static_Application_Security_Testing]]: 비밀 키 탐지를 수행하는 기반 분석 기술.
|
||||
- [[Software_Composition_Analysis]]: 외부 종속성에 포함된 보안 위협 관리.
|
||||
### 매 detection 기법
|
||||
- **Regex patterns**: AWS `AKIA[0-9A-Z]{16}`, GitHub `ghp_[A-Za-z0-9]{36}`.
|
||||
- **Entropy analysis**: Shannon entropy > 4.5 base64-like.
|
||||
- **Verification**: 매 detected key 를 actual API call 로 verify (live or revoked).
|
||||
- **AI context analysis**: 매 LLM 으로 매 surrounding code + filename → false positive triage.
|
||||
|
||||
---
|
||||
### 매 응용
|
||||
1. Pre-commit gate (developer machine).
|
||||
2. CI/CD PR check.
|
||||
3. Org-wide historical audit.
|
||||
4. Incident response (breach detected → rotate all).
|
||||
|
||||
### Related Concepts
|
||||
## 💻 패턴
|
||||
|
||||
#### [보안 분석 아키텍처 및 방법론]
|
||||
* [[Static Application Security Testing (SAST)]]
|
||||
* 연결 이유: 비밀 키 탐지는 애플리케이션을 실행하지 않고 소스 코드 자체를 분석하여 보안 취약점을 식별하는 SAST 도구의 확장 또는 핵심 기능으로 자주 포함됩니다 [2, 8].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 정적 스캐닝 엔진이 어떻게 코드를 구문 분석하고 하드코딩된 취약점을 식별하는지 이해할 수 있습니다.
|
||||
* [[DevSecOps]]
|
||||
* 연결 이유: 개발 워크플로우(CI/CD) 내에 보안 검사를 통합하여, 비밀 키 노출과 같은 문제를 배포 전에 자동 차단하는 프로세스 철학입니다 [5, 8].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 자동화된 비밀 키 스캔이 릴리스 속도를 늦추지 않으면서 코드베이스 파이프라인에 어떻게 개입하는지 이해할 수 있습니다.
|
||||
|
||||
#### [구현 및 활용 도구]
|
||||
* [[Environment Variables (.env)]]
|
||||
* 연결 이유: 비밀 키 탐지 도구의 경고를 피하고, 민감 정보를 안전하게 관리하기 위해 코드베이스에 가장 보편적으로 적용되는 격리 및 구현 패턴입니다 [1].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 소스 코드와 구성(Configuration)/인증 정보의 분리 원칙을 배울 수 있습니다.
|
||||
* [[AI-Powered Code Review]]
|
||||
* 연결 이유: LLM 기반 도구를 사용하여 PR 단위에서 "비밀 키 노출(Secret Exposure)" 여부를 동적으로 묻고 검토받는 현대적인 코드 점검 방식입니다 [9, 10].
|
||||
* 이 개념을 통해 더 깊게 이해할 수 있는 부분: 정규식 기반 스캐너의 한계를 넘어, 문맥을 이해하는 AI가 어떻게 민감 정보를 식별하는지 파악할 수 있습니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
* Semgrep 등의 도구에서 지원하는 '엔트로피 검증(Entropy validation)' 메커니즘은 기존의 정규 표현식 기반 비밀 키 탐지와 비교해 어떻게 위양성(False Positives)을 줄이는가? [7]
|
||||
* 개발 프로세스에서 식별된 하드코딩된 비밀 키를 코드베이스 이력(Git History) 전체에서 안전하게 제거하고 파기(Revoke)하기 위한 최적의 전략은 무엇인가? (소스에 관련 정보가 부족합니다.)
|
||||
* AI 코드 리뷰 도구(예: Qodo, Sourcery)에 특정 보안 지침(예: 비밀 키 노출 방지)을 프롬프트로 제공했을 때, 전용 비밀 키 스캐닝 도구(예: Spectral)에 비해 탐지 일관성과 정확도에 어떠한 차이가 발생하는가? [3, 9, 15]
|
||||
* 다양한 언어와 프레임워크가 혼재된 모노레포(Monorepo) 환경에서 비밀 키 스캐닝 도구를 CI/CD 성능 저하 없이 효율적으로 통합하는 방법은 무엇인가? [13, 16]
|
||||
* 단순한 설정 파일 외에도, 소스 코드 로직 내에 분산되어 있는 동적 생성 민감 데이터를 찾아내기 위해 SAST 엔진의 데이터 흐름 분석(Data-flow analysis)은 어떻게 작동하는가? [17]
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
* **Implementation:** 코드 작성 시 API 키나 토큰을 파일에 하드코딩하지 않고, `.env`를 활용하여 로드하며, 버전 관리 시스템에 `.gitignore`로 제외 설정이 되었는지 최우선으로 점검합니다 [1].
|
||||
* **System Design:** 시스템 파이프라인 설계 시, PR이 병합(Merge)되기 전 단계에서 Semgrep이나 Spectral 같은 스캐너가 자동으로 코드를 검사하여 비밀 키 노출 시 빌드를 차단(Block)하도록 구성합니다 [3, 7, 18].
|
||||
* **Operation / Maintenance:** CI/CD 과정에서 발생한 스캔 결과를 중앙 관리 대시보드(예: Cycode, ASPM)에 모아, 오탐을 지속적으로 튜닝하고 실제 유출 위험이 있는 비밀 키 교체(Rotation) 대응을 수행합니다 [2, 13].
|
||||
* **Learning Path:** 환경 변수 관리 등 기초적인 코드 구성 분리 원칙을 먼저 학습한 뒤, 정적 보안 분석(SAST) 도구의 룰셋 작성 및 AI를 이용한 코드 리뷰 보안성 검사 기법으로 지식을 확장합니다 [1, 5, 9].
|
||||
* **My Project Relevance:** 현재 다루는 코드베이스의 리뷰 파이프라인에 AI 프롬프트를 추가하여 "이 PR 변경 사항 중에 인증 정보나 비밀 키 유출 위험(Secret exposure)이 있는가?"를 자동 점검하도록 적용할 수 있습니다 [9].
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
* [[Application Security Posture Management (ASPM)]]
|
||||
* 확장 방향: 소스 코드상의 비밀 키 탐지뿐만 아니라, 컨테이너, IaC(Infrastructure as Code), 클라우드 구성 요소 전반의 보안 가시성과 리스크를 중앙 집중적으로 관리하는 방향으로 이해를 넓힐 수 있습니다 [2, 19].
|
||||
* [[Software Composition Analysis (SCA)]]
|
||||
* 확장 방향: 내가 짠 코드(SAST, 비밀 키 탐지)를 넘어, 프로젝트가 의존하고 있는 외부 오픈소스 라이브러리의 보안 취약점과 라이선스 위험을 탐지하는 기법으로 지식을 확장할 수 있습니다 [2, 7, 17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
|
||||
## 1. 개요
|
||||
비밀 키 탐지(Secrets Detection)는 소스 코드, 설정 파일, CI/CD 파이프라인 등에 API 키, 비밀번호, 인증 토큰과 같은 민감 정보(Secrets)가 하드코딩되어 유출되는 것을 식별하고 차단하는 보안 프로세스다. 한 번 유출된 자격 증명은 시스템 전체의 권한 탈취로 이어질 수 있으므로, 버전 관리 시스템(VCS)에 노출되기 전 단계에서 방어하는 것이 핵심이다.
|
||||
|
||||
## 2. 주요 탐지 기술
|
||||
- **패턴 매칭 (Pattern Matching)**: 정규 표현식을 사용하여 알려진 API 키 형식(예: AWS Access Key, Stripe Token)을 탐지.
|
||||
- **엔트로피 분석 (Entropy Analysis)**: 무작위성이 높은 긴 문자열을 탐지하여, 정형화되지 않은 고유 비밀번호나 개인 키 등을 식별.
|
||||
- **시맨틱 분석 (Semantic Analysis)**: 코드의 문맥을 분석하여 단순한 문자열이 아닌 실제로 인증에 사용되는 변수나 값인지 판단.
|
||||
- **검증 기능 (Verification Check)**: 탐지된 키가 실제로 유효한지(Live check) 해당 벤더 API에 확인하여 오탐지(False Positive) 제거.
|
||||
|
||||
## 3. 예방 및 대응 모범 사례
|
||||
- **환경 변수 활용**: 민감 정보는 코드와 분리하여 `.env` 파일이나 시스템 환경 변수로 관리하고, 해당 파일은 `.gitignore`에 등록하여 제외.
|
||||
- **시크릿 관리 서비스 도입**: AWS Secrets Manager, HashiCorp Vault 등 전문 도구를 사용하여 자격 증명을 암호화하고 런타임에 동적으로 주입.
|
||||
- **Pre-commit Hook 적용**: 코드가 커밋되기 전 로컬 환경에서 스캔을 수행하여 유출 가능성이 있는 코드의 생성 자체를 차단.
|
||||
- **유출 시 즉각 대응**: 자격 증명이 이미 노출된 경우, 단순히 코드를 지우는 것(Git history 삭제 포함)을 넘어 즉시 해당 키를 무효화(Revocation)하고 재발급(Rotation) 수행.
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **오탐지(False Positive)로 인한 개발 방해**: 테스트용 문자열이나 더미 데이터가 비밀 키로 오인되어 빌드가 차단될 수 있음. 정교한 제외 규칙(Allowlist) 관리 필요.
|
||||
- **Git 이력의 영속성**: 한 번 커밋된 비밀 키는 파일에서 삭제하더라도 과거 이력에 남아있다. `git filter-repo` 등을 통한 이력 세탁이 필요하지만, 팀 전체의 리베이스가 수반되는 고비용 작업임.
|
||||
- **스캔 성능**: 방대한 저장소의 모든 커밋 이력을 전수 조사하는 'Deep Scan'은 시간이 오래 걸리므로, 평소에는 증분 스캔 위주로 운영.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 자격 증명 유출로 인한 치명적인 보안 사고를 예방하고 안전한 구성 관리 표준을 수립하기 위한 지식 표준화.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
### 매 gitleaks pre-commit hook
|
||||
```yaml
|
||||
# .pre-commit-config.yaml
|
||||
repos:
|
||||
- repo: https://github.com/gitleaks/gitleaks
|
||||
rev: v8.21.0
|
||||
hooks:
|
||||
- id: gitleaks
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
```bash
|
||||
$ pre-commit install
|
||||
$ git commit -m "feat: add api"
|
||||
# gitleaks........Failed
|
||||
# leak: aws-access-token at config/dev.env:3
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### 매 gitleaks custom config (매 corp tokens)
|
||||
```toml
|
||||
# .gitleaks.toml
|
||||
[extend]
|
||||
useDefault = true
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
[[rules]]
|
||||
id = "acme-internal-token"
|
||||
description = "Acme internal API token"
|
||||
regex = '''ACME_[A-Z0-9]{32}'''
|
||||
keywords = ["acme_"]
|
||||
entropy = 3.5
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
[[rules]]
|
||||
id = "anthropic-api-key"
|
||||
description = "Anthropic API key"
|
||||
regex = '''sk-ant-[a-zA-Z0-9-_]{95,}'''
|
||||
keywords = ["sk-ant-"]
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
[allowlist]
|
||||
description = "test fixtures"
|
||||
paths = [
|
||||
'''(.*?)tests/fixtures/.*''',
|
||||
'''(.*?)\.example\..*''',
|
||||
]
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### 매 GitHub Action (PR scan)
|
||||
```yaml
|
||||
# .github/workflows/secrets-scan.yml
|
||||
name: Secrets Scan
|
||||
on: [pull_request]
|
||||
|
||||
jobs:
|
||||
gitleaks:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0 # 매 full history 필요
|
||||
- uses: gitleaks/gitleaks-action@v2
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}
|
||||
```
|
||||
|
||||
### 매 trufflehog v3 (with verification, 매 live key 만 alert)
|
||||
```bash
|
||||
# 매 git history 전체 scan, 매 verified live key 만
|
||||
$ trufflehog git file://. --only-verified --json | jq .
|
||||
|
||||
# 매 GitHub org scan
|
||||
$ trufflehog github --org=acme --token=$GH_PAT --only-verified
|
||||
|
||||
# 매 Docker image scan
|
||||
$ trufflehog docker --image=acme/api:latest --only-verified
|
||||
```
|
||||
|
||||
### 매 leaked key remediation (매 4-step)
|
||||
```bash
|
||||
# 1. 매 ROTATE first (매 코드 수정 전!) — 매 leak 시 attacker timer 시작
|
||||
aws iam create-access-key --user-name svc-deploy
|
||||
aws iam delete-access-key --access-key-id AKIA... --user-name svc-deploy
|
||||
|
||||
# 2. 매 history rewrite (BFG, 매 git filter-repo 보다 빠름)
|
||||
bfg --replace-text passwords.txt repo.git
|
||||
cd repo.git && git reflog expire --expire=now --all && git gc --prune=now --aggressive
|
||||
|
||||
# 3. 매 force push (매 collaborator 들에게 reclone 공지)
|
||||
git push --force-with-lease
|
||||
|
||||
# 4. 매 audit logs — 매 attacker 가 이미 사용했는지
|
||||
aws cloudtrail lookup-events --lookup-attributes \
|
||||
AttributeKey=AccessKeyId,AttributeValue=AKIA...
|
||||
```
|
||||
|
||||
### 매 AI-aided false-positive triage (Claude Opus 4.7)
|
||||
```python
|
||||
import anthropic
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
def triage(finding):
|
||||
"""gitleaks finding -> {is_real_secret, severity, action}"""
|
||||
prompt = f"""You are a security engineer. Decide if this is a real secret leak.
|
||||
|
||||
Finding:
|
||||
File: {finding['file']}
|
||||
Line: {finding['line']}
|
||||
Match: {finding['match']}
|
||||
Context (5 lines before/after):
|
||||
{finding['context']}
|
||||
|
||||
Output JSON:
|
||||
is_real_secret: bool
|
||||
reason: str
|
||||
severity: low|medium|high|critical
|
||||
action: rotate|ignore|investigate
|
||||
"""
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=512,
|
||||
messages=[{"role": "user", "content": prompt}],
|
||||
)
|
||||
return msg.content[0].text
|
||||
```
|
||||
|
||||
### 매 GitHub Push Protection (매 enable, free for public)
|
||||
```bash
|
||||
# 매 org-level: Settings → Code security → Push protection: Enabled
|
||||
# 매 push 시 GitHub 가 server-side block — 매 partner pattern 매 200+ provider
|
||||
gh api -X PATCH orgs/acme \
|
||||
-F secret_scanning_push_protection_enabled_for_new_repositories=true
|
||||
```
|
||||
|
||||
### 매 Doppler/Infisical (매 secret manager — 매 prevention root cause)
|
||||
```bash
|
||||
# 매 .env 의 X — 매 secret manager 에서 inject
|
||||
$ doppler run -- python app.py
|
||||
# 매 process env 에 inject, 매 disk 에 닿지 않음
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 dev workstation | gitleaks pre-commit hook |
|
||||
| 매 PR gate | gitleaks/trufflehog Action |
|
||||
| 매 GitHub.com hosted | Push Protection enable |
|
||||
| 매 large org historical | trufflehog --only-verified org-scan |
|
||||
| 매 false-positive 많음 | Claude Opus 4.7 triage layer |
|
||||
| 매 root-cause prevention | Doppler/Infisical, 매 .env 폐기 |
|
||||
|
||||
**기본값**: pre-commit (gitleaks) + CI (gitleaks Action) + GitHub Push Protection + Doppler.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Application Security]] · [[DevSecOps]]
|
||||
- 변형: [[Gitleaks]] · [[TruffleHog]] · [[GitGuardian]]
|
||||
- 응용: [[Secret Manager]] · [[Pre-commit Hook]] · [[CI Security]]
|
||||
- Adjacent: [[Incident Response]] · [[Key Rotation]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 finding triage (매 false positive vs real). 매 git history 의 narrative incident report.
|
||||
**언제 X**: 매 detection 자체 — 매 deterministic regex/entropy 가 더 빠르고 cheap. 매 LLM 의 latency + cost 매 inline 부적절.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **".env in repo"**: 매 매 the most common leak vector. 매 secret manager.
|
||||
- **Commit-then-rotate skip**: 매 rotate skip — 매 history forever.
|
||||
- **`.gitignore` rely**: 매 already-committed file 은 ignore 영향 X.
|
||||
- **Force-push without coord**: 매 collaborator 의 reflog 에 leak 잔존.
|
||||
- **Public-key panic**: 매 pub key 는 leak 의 X — 매 알고 commit.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (gitleaks docs v8.21, GitHub secret scanning docs 2026, OWASP Secrets Management Cheat Sheet).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — gitleaks + trufflehog + Push Protection + Claude triage |
|
||||
|
||||
Reference in New Issue
Block a user