데브섹옵스

DevSecOps; Development + Security + Operations
데브옵스의 빠른 개발·배포 흐름에 보안 활동을 자동화된 단계로 녹여 넣어 개발·보안·운영이 보안 책임을 함께 지는 방식

데브옵스는 개발과 운영 사이의 벽을 허물어 작은 변경을 자주, 안정적으로 배포하는 문화와 실무이다. 그런데 보안 검토가 배포 직전에 한 번 열리는 관문으로 남아 있으면 하루에도 여러 번 배포하는 흐름에서 병목이 되거나, 반대로 검토 없이 지나가게 된다. 데브섹옵스는 이 문제를 보안 검사를 파이프라인 각 단계의 자동화된 작업으로 바꾸고, 보안 요구사항을 계획 단계부터 다루는 방식으로 푼다.

미국 국립표준기술연구소(NIST)의 SP 800-204C(2022)는 클라우드 네이티브 애플리케이션 개발에서 데브섹옵스를 CI/CD 파이프라인이라는 흐름 위에 빌드·테스트·패키징·배포·운영 단계를 자동화 도구와 피드백으로 연결하는 패러다임으로 설명한다. SP 800-204D(2024)는 같은 파이프라인에 소프트웨어 공급망 보안을 통합하는 방법을 다룬다. CISSP 출제 기준 8.1은 개발 방법론의 예로 애자일, 폭포수, 데브옵스, 데브섹옵스, SAFe를 함께 든다.

시프트 레프트

시프트 레프트(shift left)는 보안 활동을 개발 수명 주기의 왼쪽, 즉 앞 단계로 옮긴다는 뜻이다. 설계 단계에서 발견한 결함은 문서 수정으로 끝나지만 운영 중에 발견한 결함은 긴급 패치, 사고 대응, 고객 통지까지 이어진다. 그래서 위협 모델링, 개발자 도구 안의 즉시 피드백, 커밋 단위 자동 검사로 결함을 일찍 잡는다.

시프트 레프트가 운영 단계 보안을 버린다는 뜻은 아니다. 운영 중 탐지와 대응(시프트 라이트, shift right)도 함께 해야 하고, 운영에서 얻은 사고·취약점 정보가 다시 계획 단계로 돌아오는 순환이 데브섹옵스의 본모습이다.

파이프라인 단계별 보안 활동

단계	보안 활동	산출물·통제
계획(plan)	위협 모델링, 보안 요구사항 정의, 오용 사례 작성, 규제 요구 확인	보안 사용자 스토리, 수용 기준, 위험 등록부
코드(code)	IDE 보안 플러그인(실시간 정적 검사), 비밀(키·토큰) 하드코딩 탐지, 커밋 전 훅(pre-commit hook), 동료 코드 리뷰, 시큐어 코딩 지침	서명된 커밋, 리뷰 승인 기록
빌드(build)	SAST(정적 분석), SCA(소프트웨어 구성 분석)로 오픈소스 취약점·라이선스 확인, SBOM 생성, 재현 가능한 빌드	빌드 출처 증명(provenance), SBOM
테스트(test)	DAST(동적 분석), IAST(계측 기반 분석), API 보안 테스트, 퍼징	취약점 보고서, 품질 게이트 판정
배포(release/deploy)	코드형 인프라(IaC) 템플릿과 컨테이너 이미지 스캔, 산출물 서명과 서명 검증, 배포 승인 정책(코드형 정책)	서명된 이미지, 정책 판정 기록
운영(operate/monitor)	RASP(런타임 자가 보호), 웹 방화벽, 런타임 위협 탐지, 로그·지표 모니터링, 취약점 재스캔, 사고 대응	경보, 사고 보고, 개선 백로그

각 검사 도구의 원리와 장단점은 애플리케이션 보안 테스트 문서에서, 저장소·러너·비밀 관리 같은 파이프라인 자체의 보호는 개발 환경 보안 문서에서 다룬다.

품질 게이트

모든 검사 결과로 빌드를 멈추면 오탐 때문에 개발 흐름이 막히고, 아무것도 멈추지 않으면 검사가 형식에 그친다. 그래서 '치명적 취약점이 있는 신규 의존성은 차단, 중간 위험은 경고와 티켓 발행'처럼 위험 기준에 따른 품질 게이트(quality gate)를 정책으로 정한다. 기준은 보안팀이 혼자 정하지 않고 개발·운영과 합의해 코드로 관리한다.

문화와 역할

구분	전통적 방식	데브섹옵스
보안 책임	보안팀이 최종 검토하고 승인	개발·보안·운영이 공동 책임. 보안팀은 기준과 도구를 제공하는 지원 조직
보안 검토 시점	출시 직전 단계 관문	계획부터 운영까지 계속, 대부분 자동화
피드백 속도	수주에서 수개월 뒤 보고서	커밋·빌드 직후 개발자 도구 안에서
개발자 역할	보고서를 받아 수정	보안 결함을 일상 결함처럼 직접 처리
보안 담당 확산	소수 전문가	팀마다 보안 챔피언(security champion)을 두어 지식 전파

도구를 사는 것만으로 데브섹옵스가 되지는 않는다. 비난 없는 사후 검토(blameless postmortem), 보안 결함을 기술 부채로 가시화하는 백로그 관리, 개발자 교육이 함께 가야 한다.

NIST SSDF와의 관계

NIST SP 800-218 '보안 소프트웨어 개발 프레임워크(SSDF, Secure Software Development Framework)' 1.1판(2022년 2월)은 특정 SDLC 모델에 매이지 않는 상위 수준의 보안 개발 실무를 네 그룹으로 정리한다. 2025년 12월에는 1.2판 초안(SP 800-218 Rev. 1)이 공개되었다.

그룹	의미	데브섹옵스에서의 예
PO (Prepare the Organization)	조직의 사람·프로세스·기술을 보안 개발에 맞게 준비	보안 요구 정의, 역할·교육, 도구 체인 구축
PS (Protect the Software)	소프트웨어의 모든 구성 요소를 변조·무단 접근에서 보호	저장소 접근 통제, 코드·산출물 서명, 출처 증명 보관
PW (Produce Well-Secured Software)	출시본의 취약점을 최소화	위협 모델링, SAST·DAST, 안전한 기본 설정
RV (Respond to Vulnerabilities)	남은 취약점을 찾아 대응하고 재발을 막음	취약점 접수·분류, 근본 원인 분석, 파이프라인 규칙 보강

SSDF는 '무엇을 해야 하는가'를 말하고, 데브섹옵스 파이프라인은 그것을 '어떻게 자동으로 매번 하는가'를 구현한다고 보면 된다.

지표

데브섹옵스 효과를 보려면 속도와 보안을 함께 측정한다.

전달 성과: DORA 연구의 소프트웨어 전달 성과 지표(변경 리드 타임, 배포 빈도, 실패 배포 복구 시간, 변경 실패율, 배포 재작업률). 자세한 내용은 DORA 메트릭 참고.
취약점 처리: 심각도별 평균 수정 시간, 기한 초과 취약점 수, 운영 환경에서 발견된 취약점 비율(늦게 발견된 비율).
적용 범위: SAST·SCA가 적용된 저장소 비율, SBOM이 생성되는 빌드 비율, 서명된 산출물 비율.
품질: 오탐률, 게이트로 차단된 빌드 수와 그중 정당한 차단 비율.

지표는 목표 자체가 되면 왜곡된다. 팀 간 순위 경쟁보다 같은 팀의 시간에 따른 개선을 본다. 보안 지표도 참고한다.

AI와 데브섹옵스

AI 코드 도우미가 만든 코드도 사람이 쓴 코드와 같은 파이프라인 검사를 거쳐야 한다. 존재하지 않는 패키지 이름을 제안하는 환각은 공격자가 그 이름으로 악성 패키지를 등록하는 공급망 공격으로 이어질 수 있으므로 SCA와 의존성 허용 목록이 중요해진다. 반대로 AI는 오탐 분류, 수정 코드 제안, 위협 모델 초안 작성에 쓰여 보안 검토의 병목을 줄이기도 한다.

시험 포인트

데브섹옵스의 핵심은 보안을 자동화해 파이프라인에 통합하고 책임을 공유하는 것이다. "배포 전 보안팀의 수동 승인 단계를 추가한다"는 데브섹옵스 취지에 맞지 않는 답이다.
시프트 레프트의 이유는 결함 수정 비용이 뒤로 갈수록 커지기 때문이다. 가장 이른 보안 활동은 계획 단계의 위협 모델링과 보안 요구사항 정의이다.
SAST는 빌드 전후 소스 대상, DAST는 실행 중 애플리케이션 대상, SCA는 외부 구성 요소 대상이다. 단계와 도구를 짝지어 기억한다.
데브섹옵스에서도 직무 분리는 사라지지 않는다. 사람 대신 파이프라인이 승인 정책을 강제하고, 파이프라인 설정 변경 자체를 통제한다.

같이 보기

참고 문헌