DevSecOps란
DevSecOps는 개발(Dev), 보안(Sec), 운영(Ops)을 통합해 소프트웨어 개발 전 단계에 보안을 내재화하는 방법론입니다. "Shift Left Security"라고도 불립니다.
CI/CD 파이프라인 보안 통합 구조
코드 → SAST → SCA → 빌드 → 이미지 스캔 → DAST → 배포 → 런타임 모니터링1단계: SAST (정적 분석)
name: Security Scan
on: [push, pull_request]
jobs:
sast:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Semgrep
uses: semgrep/semgrep-action@v1
with:
config: p/owasp-top-ten
- name: Initialize CodeQL
uses: github/codeql-action/init@v3
with:
languages: javascript, python
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v32단계: SCA (소프트웨어 구성 분석)
sca:
steps:
- name: Snyk Security Scan
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high3단계: 컨테이너 이미지 스캔
- name: Trivy 취약점 스캔
uses: aquasecurity/trivy-action@master
with:
image-ref: my-app:${{ github.sha }}
exit-code: '1'
severity: 'HIGH,CRITICAL'4단계: Secrets 탐지
- name: TruffleHog Secrets Scan
uses: trufflesecurity/trufflehog@main
with:
path: ./
base: ${{ github.event.repository.default_branch }}5단계: DAST (동적 분석)
- name: OWASP ZAP Full Scan
uses: zaproxy/[email protected]
with:
target: 'https://staging.myapp.com'
fail_action: true보안 게이트 정책
| 심각도 | 조치 |
|---|---|
| Critical | 배포 차단 |
| High | 배포 차단 |
| Medium | 경고 |
| Low | 기록만 |
DevSecOps는 도구가 아닌 문화입니다. 개발팀과 보안팀의 협업 없이 파이프라인만 구축하면 형식적인 체크박스 보안에 그칩니다.
코드만이 아니라 인프라(IaC)도 스캔하라
요즘 사고의 상당수는 애플리케이션 코드가 아니라 잘못된 인프라 설정(공개 S3, 열린 보안그룹)에서 납니다. 파이프라인에 IaC 스캔을 추가하세요.
- name: Checkov IaC Scan
uses: bridgecrewio/checkov-action@master
with:
directory: ./terraform
framework: terraformtfsec, Terrascan도 같은 목적의 대안입니다.
공급망까지 — 빌드 산출물 신뢰
SAST/SCA로 끝이 아닙니다. 빌드마다 **SBOM(구성요소 목록)**을 생성하고 아티팩트에 서명(cosign)하면, 배포물이 변조되지 않았음을 검증할 수 있습니다.
보안 게이트, 현실적으로 운영하기
| 함정 | 현실적 운영 |
|---|---|
| Critical 전부 즉시 차단 | 도입 초기엔 신규 취약점만 차단, 기존분은 기한 부여 |
| 예외 없음 | 만료일 있는 예외(waiver) 절차로 빌드 마비 방지 |
| 알림 폭주 | High↑만 PR 코멘트, 나머지는 대시보드 |
처음부터 모든 게이트를 "차단"으로 켜면 개발팀이 우회로를 찾습니다. 점진 도입이 정착의 비결입니다.
자주 묻는 질문 (FAQ)
Q. SAST·SCA·DAST 중 하나만 한다면? 의존성 취약점이 사고의 큰 비중이라 SCA부터 시작하는 경우가 많습니다. 다만 셋은 보는 영역이 달라(코드/의존성/실행) 상호 보완적입니다.
Q. 스캔 때문에 빌드가 너무 느려집니다. 전체 스캔은 야간/머지 시점으로 돌리고, PR 단계에선 변경분 위주의 빠른 스캔(증분)만 돌리는 식으로 분리하면 개발 속도를 지킬 수 있습니다.
에디터 노트 — 현장에서는
보안 게이트를 처음부터 'Critical이면 무조건 차단'으로 켜면, 2주 안에 개발팀이 우회로를 찾습니다. 효과적이었던 건 정반대였습니다 — 처음엔 '신규 취약점만 차단, 기존분은 리포트만'으로 시작해 빌드를 안 막으면서 가시성을 확보하고, 팀이 익숙해진 뒤 게이트를 조였습니다. DevSecOps에서 가장 위험한 건 취약점이 아니라 '보안을 우회하고 싶게 만드는 프로세스'입니다.
참고 자료
이 글은 AI 에이전트가 자료 조사와 1차 초안 작성을 담당하고, 사람 편집자가 사실관계·출처·톤과 맥락을 검토한 뒤 발행했습니다. 환경(OS·버전)에 따라 결과가 다를 수 있으니 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.
댓글
첫 번째 댓글을 남겨보세요.