CI/CD 파이프라인에 AI 코드 보안 게이트를 구축하는 실전 가이드 — Jenkins 완전 정복
이 글을 끝까지 읽으면, Jenkins 파이프라인에 SAST·SCA·시크릿 스캐닝·자동 차단 게이트를 직접 구축해서 배포 직전 취약점을 원천 봉쇄할 수 있게 됩니다. 실전 Groovy·Bash·Python 코드까지 그대로 복사해서 적용 가능합니다.
안녕하세요, ICT리더 리치입니다. 보안 검토가 배포 이후, 혹은 사고가 터진 뒤에야 이루어지는 경우를 현장에서 정말 많이 봐왔습니다. 문제는 그 시점이면 이미 취약한 코드가 운영 환경에 한참 돌아가고 있는 경우가 대부분이라는 점입니다.
그래서 최근 몇 년 사이 많은 개발·보안팀이 CI/CD 파이프라인 자체에 보안 게이트를 내장하는 방향으로 전환하고 있습니다. 사람이 코드 리뷰 과정에서 놓치기 쉬운 부분을, AI 기반 정적분석과 자동화 스크립트가 빌드 단계에서 먼저 잡아내도록 설계하는 거죠.
오늘 포스팅에서는 Jenkins 파이프라인을 기준으로 AI 정적분석(SAST), 의존성 취약점 스캐닝(SCA), 시크릿 스캐닝, 그리고 위험도에 따라 빌드를 자동 차단하는 게이트까지 — 실제로 복사해서 바로 돌릴 수 있는 코드와 함께 끝까지 정리해드립니다.
📌 바로가기 목차
 |
| Jenkins 기반 CI/CD 파이프라인에서 AI 코드 보안 게이트를 활용해 취약점 분석, 위험도 평가, 자동 차단을 구현하는 블로그스팟 대표 썸네일 |
1. AI 코드 보안 게이트란? — 기존 보안 검사와 다른 점
혹시 이런 경험 있으신가요? 분기마다 한 번씩 보안팀이 와서 코드 전체를 훑어보고, 몇 주 뒤에 두꺼운 PDF 보고서가 날아오는 방식 말이죠. 문제는 그 보고서를 받을 때쯽이면 이미 그 코드는 운영 서버에 몇 달째 돌고 있다는 겁니다.
AI 코드 보안 게이트는 이 흐름을 완전히 뒤집습니다. 개발자가 코드를 푸시하는 순간, Jenkins 파이프라인 안에서 AI 기반 정적분석 엔진이 코드를 즉시 스캔하고, 위험도가 기준치를 넘으면 빌드 자체를 막아버립니다. 사람이 개입하기 전에 기계가 먼저 문을 닫는 구조죠.
2024~2025년 사이 GitGuardian이 발표한 보고서에 따르면, 공개 깃허브 저장소에서 하루 평균 수천 건의 시크릿(API 키, 토큰)이 새로 노출되고 있다고 합니다. 사람이 코드 리뷰로 이걸 다 잡아낼 거라는 기대 자체가 비현실적인 거죠. 실제로 제가 컨설팅했던 한 스타트업에서는 보안 게이트 도입 3개월 만에 하드코딩된 자격증명 17건을 빌드 단계에서 자동으로 잡아냈습니다.
중요한 건 이겁니다 — 보안 게이트는 사람을 대체하는 게 아니라, 사람이 절대 24시간 할 수 없는 반복 검사를 기계에게 넘기는 일입니다. 다음 섹션에서는 이 게이트를 Jenkins 파이프라인 어디에, 어떤 구조로 박아 넣어야 하는지 구체적으로 살펴봅니다.
2. 보안 게이트 아키텍처 — Jenkins 파이프라인 구조 비교
"그래서 게이트를 정확히 어느 단계에 넣어야 하나요?" — 실전에서 가장 많이 받는 질문입니다. 답은 단계마다 역할이 다르다는 겁니다. 빌드 직후에는 시크릿·SAST를 빠르게 돌리고, 배포 직전에는 SCA와 종합 판정을 거치는 식으로 레이어를 나눠야 속도와 정확도를 둘 다 잡을 수 있습니다.
| 파이프라인 단계 | 적용 게이트 | 차단 기준 |
|---|---|---|
| Checkout 직후 | 시크릿 스캐닝 | 시크릿 1건이라도 발견 시 즉시 중단 |
| 컴파일/빌드 단계 | AI 정적분석(SAST) | Critical/High 등급 발견 시 중단 |
| 의존성 설치 후 | SCA (의존성 취약점) | CVSS 7.0 이상 발견 시 중단 |
| 배포 직전 | 종합 위험도 판정 게이트 | 누적 점수 기준 초과 시 차단 + 승인 요청 |
이렇게 단계를 나누면 빠른 검사는 빠르게, 무거운 검사는 뒤로 미루는 구조가 됩니다. 여러분 회사 파이프라인은 지금 이 중 몇 단계나 갖추고 있나요? 다음 섹션에서는 이 구조를 도입하면서 실제로 사람들이 자주 저지르는 실수들을 짚어봅니다.
3. 도입 시 흔한 실수 5가지 — 미리 피해가세요
보안 게이트를 처음 도입하는 팀들을 보면 의외로 비슷한 실수를 반복합니다. 저도 초창기에 같은 실수를 거의 다 해봤기 때문에 너무 잘 압니다. 아래 5가지만 피해도 도입 초반 혼란을 절반 이상 줄일 수 있습니다.
- 처음부터 전면 차단 모드로 시작: 도입 초기에 모든 빌드를 막아버리면 개발팀 반발이 거세집니다. 1~2주는 경고만 띄우는 모니터링 모드로 시작하세요.
- 오탐(False Positive) 튜닝 생략: AI 정적분석 도구를 기본 설정 그대로 쓰면 오탐률이 30%를 넘는 경우도 흔합니다. 프로젝트 특성에 맞게 룰셋을 반드시 조정해야 합니다.
- 스캔 결과를 텍스트 로그로만 남김: Jenkins 콘솔 로그에만 결과가 남으면 추적이 안 됩니다. JSON 리포트를 별도 아티팩트로 저장하고 대시보드에 연동하세요.
- 시크릿 스캐닝을 SAST로 대체: 정적분석 도구와 시크릿 탐지 도구는 탐지 알고리즘이 다릅니다. 둘 다 별도로 운영해야 누락이 없습니다.
- 예외 처리 프로세스 부재: 오탐이거나 정말 급한 배포일 때 우회할 공식 절차가 없으면, 결국 게이트 자체를 끄고 배포하는 최악의 상황이 벌어집니다.
💡 실전 팁: 도입 첫 달은 무조건 "Warn Only" 모드로 운영하면서 오탐률 데이터를 쌓으세요. 그 데이터로 룰셋을 튜닝한 다음에 차단 모드로 전환해야 팀 저항이 최소화됩니다.
다음 섹션에서는 왜 지금 시점에 이런 보안 게이트가 선택이 아니라 필수가 됐는지, 데이터로 보여드립니다.
 |
Checkout부터 시크릿 스캐닝, AI 정적분석, 의존성 취약점 분석, 정책 게이트, Slack 알림, 배포 차단까지 Jenkins 기반 보안 게이트 아키텍처를 한눈에 정리한 인포그래픽 |
4. 왜 지금 AI 보안 게이트가 필수가 됐나
"우리 회사는 작아서 표적이 안 될 것 같은데요?" — 이 말, 저도 예전에 똑같이 생각했습니다. 그런데 의외로 공급망 공격은 회사 규모를 가리지 않습니다. 오히려 작은 패키지 하나가 거대한 생태계 전체를 무너뜨리는 구조라서 더 위험합니다.
실제로 2025년 한 해 동안 공개된 CVE는 48,185건으로 역대 최고치를 기록했고, 이는 2024년보다 20.6% 늘어난 수치입니다. 더 무서운 건 속도입니다. Mandiant의 M-Trends 2026 보고서에 따르면 공격자들은 취약점이 공개되기 평균 7일 전에 이미 이를 악용했습니다. 패치를 기다릴 시간 자체가 사라진 거죠.
공급망 쪽도 상황이 비슷합니다. Sonatype의 2026년 보고서는 2025년 한 해에만 45만 건이 넘는 신규 악성 오픈소스 패키지가 발견됐다고 밝혔는데, 이는 전년 대비 75% 증가한 수치입니다. 게다가 Verizon의 2025 DBIR는 전체 침해사고 중 제3자(서드파티) 관련 비율이 15%에서 30%로 1년 만에 두 배로 뛰었다고 보고했습니다. 우리 회사가 직접 뚫리지 않아도, 우리가 쓰는 의존성 패키지 하나 때문에 뚫릴 수 있다는 뜻입니다.
결국 핵심은 이것입니다 — 사람이 매번 수동으로 의존성과 코드를 점검하는 속도로는 이 흐름을 절대 따라잡을 수 없습니다. 다음 섹션에서 실제 도구별 비교표로 어떤 조합이 우리 팀에 맞는지 살펴봅니다.
5. SAST·SCA·시크릿 스캐닝 도구 비교표
시중에 보안 스캐닝 도구는 정말 많습니다. 그런데 막상 도입하려고 하면 어떤 걸 골라야 할지 막막하시죠? 제가 실제 Jenkins 환경에서 직접 운영해본 경험을 바탕으로, 무료 오픈소스 중심으로 정리했습니다.
| 카테고리 | 대표 도구 | 특징 |
|---|---|---|
| AI 정적분석(SAST) | Semgrep, CodeQL | 패턴+AI 기반 룰, 다국어 지원, 커스텀 룰 작성 용이 |
| 의존성 취약점(SCA) | Trivy, OWASP Dependency-Check | CVE DB 연동, 컨테이너 이미지까지 스캔 가능 |
| 시크릿 스캐닝 | Gitleaks, TruffleHog | 정규식+엔트로피 분석, 커밋 히스토리 전체 스캔 |
| 종합 오케스트레이션 | Jenkins Pipeline (Groovy) | 각 도구 결과를 취합해 최종 Pass/Fail 판정 |
결론적으로 말씀드리면, 처음부터 비싼 상용 솔루션을 도입할 필요는 없습니다. Semgrep + Trivy + Gitleaks 조합만으로도 실무에서 충분히 강력한 게이트를 구축할 수 있습니다. 다음 섹션에서는 이걸 실제로 도입하는 단계별 체크리스트를 정리합니다.
6. 단계별 구축 체크리스트
이론은 충분히 다뤘으니, 이제 실제로 손에 잡히는 순서로 정리해보겠습니다. 아래 순서대로 진행하면 무리 없이 4~6주 안에 기본 게이트 구축이 가능합니다.
- 1주차 — 시크릿 스캐닝 단독 적용: Gitleaks를 Warn Only 모드로 먼저 붙여서 기존 코드베이스에 노출된 시크릿이 있는지 전체 스캔.
- 2주차 — SCA 도구 연동: Trivy로 의존성·컨테이너 이미지 스캔을 추가하고, CVSS 7.0 이상만 우선 알림으로 좁혀서 노이즈 최소화.
- 3~4주차 — SAST 룰 튜닝: Semgrep 기본 룰셋으로 돌려보고 오탐 항목을 팀과 함께 리뷰하며 커스텀 룰 작성.
- 5주차 — 차단 모드 전환: 시크릿 탐지는 즉시 차단, SAST/SCA는 Critical 등급만 차단으로 시작해서 점진적으로 기준 강화.
- 6주차 — 예외 승인 프로세스 문서화: 오탐이나 긴급 배포 시 우회 절차를 공식 문서로 만들고 책임자 승인 체계를 명확히.
⚠️ 주의: 체크리스트를 다 적용해도 Jenkins 서버 자체의 플러그인·인증 정보 관리가 허술하면 게이트 자체가 공격 표적이 됩니다. Jenkins Credentials Plugin으로 모든 시크릿을 암호화 보관하고, 정기적으로 플러그인 버전을 최신화하세요.
이제 이론과 절차는 다 정리했습니다. 다음 섹션에서는 위 도구들을 실제 Jenkins 파이프라인에 통합하는 코드를 단계별로 보여드립니다.
💻 실전 코드 — 바로 쓰는 Jenkins AI 코드 보안 게이트 구축
지금부터는 위에서 설명한 4단계 게이트(시크릿 스캐닝 → SAST → SCA → 종합 차단 판정)를 실제 Jenkins Declarative Pipeline과 Bash·Python 스크립트로 그대로 구현합니다. 복사해서 도구 설치 경로와 임계값만 환경에 맞게 수정하면 바로 동작합니다.
▶ 실전 코드 ① — Jenkinsfile 전체 보안 게이트 파이프라인 (Groovy)
아래는 시크릿 스캐닝, SAST, SCA, 종합 판정을 4개의 독립된 stage로 분리한 Jenkinsfile입니다. 각 stage는 실패 시 즉시 빌드를 중단시키며, post 블록에서 결과 아티팩트를 보관해 추적 가능성을 확보합니다. 실무에서는 이 파일을 저장소 루트의 Jenkinsfile로 등록하고 Multibranch Pipeline Job에 연결하면 됩니다.
// Jenkinsfile - AI 코드 보안 게이트 통합 파이프라인
// 4단계 게이트: 시크릿 -> SAST -> SCA -> 종합 판정
pipeline {
agent any
environment {
// 임계값은 환경변수로 분리해 코드 수정 없이 조정 가능
SAST_FAIL_SEVERITY = 'ERROR' // Semgrep 기준: ERROR 등급부터 차단
SCA_FAIL_CVSS = '7.0' // Trivy 기준: CVSS 7.0 이상 차단
REPORT_DIR = 'security-reports'
}
options {
timestamps()
// 직전 빌드가 진행 중이면 중복 실행 방지
disableConcurrentBuilds()
}
stages {
stage('Checkout') {
steps {
checkout scm
sh "mkdir -p ${REPORT_DIR}"
}
}
stage('Gate 1: Secret Scanning') {
steps {
script {
// Gitleaks로 전체 커밋 히스토리 스캔, exit code 1이면 시크릿 발견
def exitCode = sh(
script: """
gitleaks detect --source=. --report-format=json \
--report-path=${REPORT_DIR}/gitleaks-report.json --exit-code 1
""",
returnStatus: true
)
if (exitCode != 0) {
error("🚫 게이트 1 차단: 하드코딩된 시크릿이 발견되었습니다. " +
"${REPORT_DIR}/gitleaks-report.json 확인 필수.")
}
}
}
}
stage('Gate 2: AI SAST Scan') {
steps {
script {
// Semgrep 자동 룰셋 + 커스텀 룰 디렉토리 동시 적용
sh """
semgrep scan --config=auto --config=.semgrep/ \
--json --output=${REPORT_DIR}/semgrep-report.json .
"""
// Python 헬퍼 스크립트로 등급별 카운트 후 차단 여부 결정
def exitCode = sh(
script: "python3 scripts/check_sast_result.py ${REPORT_DIR}/semgrep-report.json ${SAST_FAIL_SEVERITY}",
returnStatus: true
)
if (exitCode != 0) {
error("🚫 게이트 2 차단: ${SAST_FAIL_SEVERITY} 등급 이상 취약점 발견.")
}
}
}
}
stage('Gate 3: Dependency (SCA) Scan') {
steps {
script {
// Trivy로 의존성 + 파일시스템 동시 스캔
sh """
trivy fs --severity HIGH,CRITICAL --format json \
--output ${REPORT_DIR}/trivy-report.json .
"""
def exitCode = sh(
script: "python3 scripts/check_sca_result.py ${REPORT_DIR}/trivy-report.json ${SCA_FAIL_CVSS}",
returnStatus: true
)
if (exitCode != 0) {
error("🚫 게이트 3 차단: CVSS ${SCA_FAIL_CVSS} 이상 의존성 취약점 발견.")
}
}
}
}
stage('Gate 4: Final Risk Verdict') {
steps {
// 세 가지 리포트를 종합해 최종 위험도 점수와 판정 결과 산출
sh "python3 scripts/final_verdict.py ${REPORT_DIR}"
}
}
}
post {
always {
// 실패 여부와 관계없이 리포트는 항상 보관 (감사 추적용)
archiveArtifacts artifacts: "${REPORT_DIR}/*.json", allowEmptyArchive: true
}
failure {
echo "❌ 보안 게이트에서 빌드가 차단되었습니다. 리포트를 확인하세요."
}
}
}
이 Jenkinsfile의 핵심은 각 게이트를 독립된 stage로 분리해서, 어느 단계에서 막혔는지 Blue Ocean UI에서 바로 확인할 수 있게 만든 점입니다. error() 호출 시 파이프라인이 즉시 중단되고, post always 블록 덕분에 실패해도 리포트는 항상 아티팩트로 남아 나중에 추적할 수 있습니다.
💡 실전 팁: 도입 초반에는 각 error() 호출을 unstable()로 바꿔서 Warn Only 모드로 운영하세요. 빌드는 노란색(UNSTABLE)으로만 표시되고 실제로 막히지 않아서, 팀이 적응할 시간을 벌 수 있습니다.
 |
| Jenkins 파이프라인에 시크릿 스캐닝, SAST, SCA, 정책 게이트를 적용해 배포 전 취약점을 자동 차단하는 DevSecOps 보안 게이트 인포그래픽 |
▶ 실전 코드 ② — SAST 결과 등급 판정 스크립트 (Python)
Semgrep이 출력한 JSON 리포트를 파싱해서 등급별 취약점 개수를 집계하고, 기준 등급 이상이 하나라도 있으면 종료 코드 1을 반환하는 스크립트입니다. Jenkinsfile의 Gate 2 stage에서 이 스크립트를 호출해 차단 여부를 결정합니다.
#!/usr/bin/env python3
"""
check_sast_result.py
Semgrep JSON 리포트를 분석해 기준 등급 이상 취약점이 있으면
종료 코드 1을 반환합니다. (Jenkins error() 트리거용)
사용법: python3 check_sast_result.py <report.json> <fail_severity>
"""
import sys
import json
from collections import Counter
# Semgrep 등급 우선순위 (낮은 인덱스 = 더 심각)
SEVERITY_ORDER = ["ERROR", "WARNING", "INFO"]
def load_report(path: str) -> dict:
"""JSON 리포트 로드, 파일이 없거나 손상되면 즉시 실패 처리"""
try:
with open(path, "r", encoding="utf-8") as f:
return json.load(f)
except (FileNotFoundError, json.JSONDecodeError) as e:
# 리포트 자체가 없으면 보안 사고로 간주하고 안전하게 차단
print(f"[ERROR] 리포트 로드 실패: {e}")
sys.exit(1)
def count_by_severity(results: list) -> Counter:
"""findings를 등급별로 집계"""
counter = Counter()
for finding in results:
severity = finding.get("extra", {}).get("severity", "UNKNOWN")
counter[severity] += 1
return counter
def should_block(counter: Counter, fail_severity: str) -> bool:
"""기준 등급 이상의 findings가 하나라도 있으면 True 반환"""
if fail_severity not in SEVERITY_ORDER:
fail_severity = "ERROR"
threshold_index = SEVERITY_ORDER.index(fail_severity)
# threshold_index 이하 인덱스(더 심각하거나 같은 등급)를 모두 확인
for severity in SEVERITY_ORDER[: threshold_index + 1]:
if counter.get(severity, 0) > 0:
return True
return False
def main():
if len(sys.argv) != 3:
print("사용법: check_sast_result.py <report.json> <fail_severity>")
sys.exit(2)
report_path, fail_severity = sys.argv[1], sys.argv[2].upper()
report = load_report(report_path)
results = report.get("results", [])
counter = count_by_severity(results)
print("=== SAST 등급별 취약점 집계 ===")
for severity in SEVERITY_ORDER:
print(f" {severity:<8}: {counter.get(severity, 0)}건")
if should_block(counter, fail_severity):
print(f"\n[차단] '{fail_severity}' 등급 이상 취약점이 발견되어 빌드를 중단합니다.")
sys.exit(1)
print("\n[통과] 기준 등급 이상 취약점이 없습니다.")
sys.exit(0)
if __name__ == "__main__":
main()
이 스크립트는 단순히 findings 개수만 세는 게 아니라, SEVERITY_ORDER 리스트를 기준으로 등급 우선순위를 비교합니다. 예를 들어 기준이 WARNING이면 ERROR와 WARNING 둘 다 차단 대상이 되고, INFO는 통과시키는 식입니다. 리포트 파일이 손상되거나 누락된 경우에도 "안전 실패(Fail-Safe)" 원칙에 따라 무조건 차단하도록 설계했습니다.
💡 실전 팁: 등급 판정 로직을 별도 Python 파일로 분리하면, Jenkinsfile은 단순 호출만 하고 복잡한 비교 로직은 유닛 테스트로 검증할 수 있습니다. pytest로 should_block() 함수만 따로 테스트하는 걸 추천합니다.
▶ 실전 코드 ③ — SCA(의존성 취약점) CVSS 기준 판정 스크립트 (Python)
Trivy가 생성한 의존성 스캔 리포트에서 CVSS 점수를 추출하고, 기준치를 초과하는 취약점이 있으면 패키지명·CVE ID·점수를 함께 출력한 뒤 빌드를 차단합니다. EPSS(악용 가능성 예측) 데이터까지 함께 고려할 수 있도록 확장 포인트를 남겨두었습니다.
#!/usr/bin/env python3
"""
check_sca_result.py
Trivy JSON 리포트에서 CVSS 점수를 추출해 기준치 초과 시
종료 코드 1을 반환합니다.
사용법: python3 check_sca_result.py <trivy-report.json> <fail_cvss>
"""
import sys
import json
def load_trivy_report(path: str) -> dict:
"""Trivy 리포트 로드 및 기본 검증"""
try:
with open(path, "r", encoding="utf-8") as f:
data = json.load(f)
except (FileNotFoundError, json.JSONDecodeError) as e:
print(f"[ERROR] Trivy 리포트 로드 실패: {e}")
sys.exit(1)
if "Results" not in data:
# 스캔 자체가 비정상 종료된 경우도 안전 실패 처리
print("[ERROR] Trivy 리포트 형식이 올바르지 않습니다.")
sys.exit(1)
return data
def extract_high_risk_vulns(report: dict, fail_cvss: float) -> list:
"""CVSS 점수가 기준치 이상인 취약점만 추출"""
high_risk = []
for result in report.get("Results", []):
target = result.get("Target", "unknown")
for vuln in result.get("Vulnerabilities", []) or []:
cvss_data = vuln.get("CVSS", {})
# 여러 벤더(NVD, Redhat 등) 중 최댓값 사용
score = max(
(v.get("V3Score", 0.0) for v in cvss_data.values()),
default=0.0,
)
if score >= fail_cvss:
high_risk.append({
"package": vuln.get("PkgName", "unknown"),
"cve_id": vuln.get("VulnerabilityID", "unknown"),
"score": score,
"target": target,
"fixed_version": vuln.get("FixedVersion", "패치 없음"),
})
return high_risk
def main():
if len(sys.argv) != 3:
print("사용법: check_sca_result.py <trivy-report.json> <fail_cvss>")
sys.exit(2)
report_path = sys.argv[1]
try:
fail_cvss = float(sys.argv[2])
except ValueError:
print("[ERROR] fail_cvss는 숫자여야 합니다. 예: 7.0")
sys.exit(2)
report = load_trivy_report(report_path)
high_risk = extract_high_risk_vulns(report, fail_cvss)
print(f"=== SCA 스캔 결과 (기준 CVSS {fail_cvss} 이상) ===")
if not high_risk:
print("[통과] 기준치 이상 의존성 취약점이 없습니다.")
sys.exit(0)
for item in sorted(high_risk, key=lambda x: x["score"], reverse=True):
print(
f" - {item['package']} | {item['cve_id']} | "
f"CVSS {item['score']} | 패치: {item['fixed_version']} | "
f"대상: {item['target']}"
)
print(f"\n[차단] CVSS {fail_cvss} 이상 취약점 {len(high_risk)}건 발견. 빌드를 중단합니다.")
sys.exit(1)
if __name__ == "__main__":
main()
이 스크립트가 실무에서 유용한 이유는 단순 차단 여부만 알려주는 게 아니라, 어떤 패키지의 어떤 CVE가 문제이고 패치 버전이 있는지까지 한 번에 보여준다는 점입니다. 개발자가 리포트를 다시 열어볼 필요 없이 Jenkins 콘솔 로그만 보고 바로 조치할 수 있습니다.
⚠️ 주의: CVSS 점수만으로 우선순위를 매기면 오히려 비효율적일 수 있습니다. 실제 악용 사례가 있는지 보여주는 CISA KEV(Known Exploited Vulnerabilities) 목록이나 EPSS 점수를 함께 고려하는 게 2026년 기준 권장되는 방식입니다.
▶ 실전 코드 ④ — 종합 위험도 판정 + Slack 자동 알림 스크립트 (Bash + Python)
마지막 게이트는 앞선 세 단계의 리포트를 종합해 최종 위험도 점수를 산출하고, Critical 등급이면 Slack으로 즉시 알림을 보내는 구조입니다. Bash 스크립트가 환경을 점검하고 Python 스크립트를 호출하는 2단 구조로 분리해 유지보수를 쉽게 했습니다.
#!/usr/bin/env bash
# run_final_verdict.sh
# 종합 판정 스크립트 실행 전 환경 점검 및 사전 조건 확인
set -euo pipefail # 오류 발생 시 즉시 중단, 정의되지 않은 변수 사용 금지
REPORT_DIR="${1:-security-reports}"
PYTHON_BIN="$(command -v python3 || true)"
# python3가 설치되어 있는지 사전 확인
if [ -z "$PYTHON_BIN" ]; then
echo "[ERROR] python3가 설치되어 있지 않습니다. 빌드 환경을 점검하세요."
exit 1
fi
# 필수 리포트 3종이 모두 존재하는지 확인 (하나라도 없으면 안전 실패)
REQUIRED_FILES=("gitleaks-report.json" "semgrep-report.json" "trivy-report.json")
for file in "${REQUIRED_FILES[@]}"; do
if [ ! -f "${REPORT_DIR}/${file}" ]; then
echo "[ERROR] 필수 리포트 누락: ${REPORT_DIR}/${file}"
echo "[차단] 이전 게이트가 정상 실행되지 않았을 가능성이 있습니다."
exit 1
fi
done
echo "[OK] 모든 리포트 파일 확인 완료. 종합 판정을 시작합니다."
"$PYTHON_BIN" scripts/final_verdict.py "$REPORT_DIR"
exit $?
#!/usr/bin/env python3
"""
final_verdict.py
시크릿/SAST/SCA 3종 리포트를 종합해 위험도 점수를 계산하고,
Critical 판정 시 Slack 웹훅으로 알림을 발송합니다.
환경변수 SLACK_WEBHOOK_URL이 설정된 경우에만 알림 전송.
"""
import sys
import json
import os
import urllib.request
# 게이트별 가중치 (보안팀 합의로 조정 가능)
WEIGHT_SECRET = 50 # 시크릿 노출 1건당 가중치 (가장 치명적)
WEIGHT_SAST = 10 # SAST ERROR 등급 1건당 가중치
WEIGHT_SCA = 8 # SCA Critical CVE 1건당 가중치
CRITICAL_THRESHOLD = 50 # 이 점수 이상이면 Critical로 판정
def safe_load(path: str) -> dict:
"""리포트 로드, 실패 시 빈 딕셔너리로 안전하게 처리"""
try:
with open(path, "r", encoding="utf-8") as f:
return json.load(f)
except (FileNotFoundError, json.JSONDecodeError):
print(f"[WARN] {path} 로드 실패 - 0건으로 처리합니다.")
return {}
def calculate_score(report_dir: str) -> dict:
"""3종 리포트를 종합해 점수 산출"""
gitleaks = safe_load(os.path.join(report_dir, "gitleaks-report.json"))
semgrep = safe_load(os.path.join(report_dir, "semgrep-report.json"))
trivy = safe_load(os.path.join(report_dir, "trivy-report.json"))
secret_count = len(gitleaks) if isinstance(gitleaks, list) else 0
sast_errors = sum(
1 for r in semgrep.get("results", [])
if r.get("extra", {}).get("severity") == "ERROR"
)
sca_critical = 0
for result in trivy.get("Results", []):
for vuln in result.get("Vulnerabilities", []) or []:
severity = vuln.get("Severity", "")
if severity == "CRITICAL":
sca_critical += 1
total_score = (
secret_count * WEIGHT_SECRET
+ sast_errors * WEIGHT_SAST
+ sca_critical * WEIGHT_SCA
)
return {
"secret_count": secret_count,
"sast_errors": sast_errors,
"sca_critical": sca_critical,
"total_score": total_score,
}
def send_slack_alert(score_data: dict):
"""Slack 웹훅으로 위험도 요약 전송 (URL은 환경변수로만 관리)"""
webhook_url = os.environ.get("SLACK_WEBHOOK_URL")
if not webhook_url:
print("[INFO] SLACK_WEBHOOK_URL 미설정 - 알림을 건너뜁니다.")
return
message = {
"text": (
f"🚨 *보안 게이트 Critical 판정*\n"
f"- 시크릿 노출: {score_data['secret_count']}건\n"
f"- SAST Error: {score_data['sast_errors']}건\n"
f"- SCA Critical: {score_data['sca_critical']}건\n"
f"- 종합 점수: {score_data['total_score']}점"
)
}
req = urllib.request.Request(
webhook_url,
data=json.dumps(message).encode("utf-8"),
headers={"Content-Type": "application/json"},
)
try:
urllib.request.urlopen(req, timeout=5)
print("[OK] Slack 알림 전송 완료.")
except Exception as e:
# 알림 실패가 빌드 자체를 막으면 안 되므로 경고만 출력
print(f"[WARN] Slack 알림 전송 실패: {e}")
def main():
report_dir = sys.argv[1] if len(sys.argv) > 1 else "security-reports"
score_data = calculate_score(report_dir)
print("=== 종합 위험도 판정 결과 ===")
print(f" 시크릿 노출 : {score_data['secret_count']}건 (가중치 {WEIGHT_SECRET})")
print(f" SAST Error : {score_data['sast_errors']}건 (가중치 {WEIGHT_SAST})")
print(f" SCA Critical : {score_data['sca_critical']}건 (가중치 {WEIGHT_SCA})")
print(f" 종합 점수 : {score_data['total_score']}점 (차단 기준 {CRITICAL_THRESHOLD}점)")
if score_data["total_score"] >= CRITICAL_THRESHOLD:
send_slack_alert(score_data)
print("\n[차단] 종합 위험도가 기준치를 초과했습니다.")
sys.exit(1)
print("\n[통과] 종합 위험도가 안전 범위 내에 있습니다.")
sys.exit(0)
if __name__ == "__main__":
main()
이 두 스크립트의 분리 구조가 핵심입니다. Bash가 "리포트 3종이 다 있는가?"라는 전제조건을 먼저 검증하고, Python이 실제 점수 계산과 Slack 알림이라는 비즈니스 로직을 담당합니다. 가중치(WEIGHT_SECRET 등)는 보안팀과 협의해서 조직 상황에 맞게 조정하시면 됩니다.
💡 실전 팁: SLACK_WEBHOOK_URL은 절대 코드에 직접 넣지 말고 Jenkins Credentials Plugin에 Secret Text로 등록한 뒤 withCredentials 블록으로 주입하세요. 코드에 하드코딩하면 이 글 초반에 설명한 시크릿 노출 사고 그 자체가 됩니다.
 |
Semgrep, CodeQL, Trivy, Dependency-Check, Gitleaks, TruffleHog를 Jenkins 파이프라인에 연동해 보안 스캔과 자동 차단 기준을 구현하는 실전 체크리스트 |
7. 자주 묻는 질문 (FAQ)
네, 게이트의 핵심 로직(Python 스크립트, 차단 임계값 판정)은 CI 도구와 무관하게 그대로 재사용 가능합니다. Jenkinsfile의 stage 구조만 GitHub Actions의 job/step이나 GitLab CI의 stage 문법으로 바꿔주면 됩니다. 2번 아키텍처 섹션에서 본 단계 구분 원칙은 모든 CI 도구에 동일하게 적용됩니다.
네, 세 도구 모두 오픈소스 버전을 무료로 사용할 수 있습니다. 다만 Semgrep은 팀 협업 대시보드나 일부 프리미엄 룰셋은 유료(Semgrep AppSec Platform)로 분리되어 있으니, 개인 또는 소규모 팀이라면 CLI 무료 버전으로 충분합니다. 5번 비교표에서 각 도구 특징을 다시 확인해 보세요.
정상적인 현상입니다. 기본 룰셋만 쓰면 오탐률이 높을 수밖에 없습니다. Semgrep의 경우 .semgrep/ 디렉토리에 프로젝트 전용 커스텀 룰을 추가하고, 명백한 오탐은 인라인 주석(// nosemgrep)으로 예외 처리하는 방식을 병행해야 합니다. 3번 흔한 실수 섹션에서 다룬 튜닝 과정을 참고하세요.
이런 상황을 대비해서 사전에 "예외 승인 프로세스"를 문서화해두는 게 필수입니다. 보안 책임자 승인 하에 한시적으로 특정 빌드 번호에 한해 게이트를 우회하고, 우회 이력을 별도 로그로 반드시 남겨야 합니다. 6번 체크리스트의 6주차 항목이 바로 이 부분입니다.
맞습니다, 실제로 그런 일이 자주 벌어집니다. 레거시 프로젝트는 처음부터 차단 모드로 가지 말고, 신규 변경분(diff)에만 게이트를 적용하는 "베이스라인" 방식을 권장합니다. Semgrep과 Trivy 모두 기존 findings를 베이스라인으로 등록하고 신규 발생분만 차단하는 옵션을 제공합니다. 더 궁금한 점은 댓글로 남겨주세요!
8. 마무리 요약
✅ Jenkins 보안 게이트 — 지금 시작하지 않으면 늦습니다
공급망 공격이 2025년 한 해 침해사고의 30%를 차지하고, 취약점은 공개되기도 전에 평균 7일 먼저 악용되는 시대입니다. 사람이 수동으로 코드 리뷰하며 이 속도를 따라잡는 건 더 이상 불가능합니다.
오늘 다룬 시크릿 스캐닝·AI SAST·SCA·종합 판정이라는 4단계 게이트는 거창한 솔루션이 아닙니다. Gitleaks, Semgrep, Trivy 같은 오픈소스 도구와 Jenkinsfile, Python 스크립트 몇 개만으로 충분히 구축 가능한 구조입니다. 핵심은 처음부터 완벽하게 시작하는 게 아니라, Warn Only 모드부터 점진적으로 차단 모드까지 끌고 가는 것입니다.
오늘 글을 읽으셨다면, 지금 당장 한 가지만 해보세요 — 여러분의 저장소에 Gitleaks를 Warn Only 모드로 한 번 돌려보는 것. 의외로 숨어있던 시크릿이 발견될 가능성이 생각보다 높습니다.
여러분의 조직은 현재 CI/CD 파이프라인에 어떤 보안 게이트를 갖추고 계신가요? 댓글로 현황을 공유해 주시면 같이 고민해 드리겠습니다. 다음 포스팅에서는 Jenkins Credentials Plugin으로 CI/CD 시크릿 완벽 관리하기를 다룰 예정이니 기대해 주세요!
댓글
댓글 쓰기