DevSecOps의 뼈대: 형상관리와 '통제 가능한' CI/CD
최종 수정일: 10월 13일
요약 보안을 개발 프로세스에 녹여내기 위한 선결 과제는 모든 변경 사항에 대한 완벽한 추적성(Traceability)을 확보하는 것입니다. 형상관리가 그 기반을 제공하며, 사전 정의된 검증과 승인을 통과해야만 배포가 승인되는 체계가 바로 '통제 가능한 CI/CD'입니다. |
형상관리는 단순한 코드 저장소가 아닙니다
DevSecOps의 출발점은 소스코드 변경 이력을 신뢰할 수 있는 상태로 만드는 것입니다. 예기치 못한 결함이나 보안 사고가 발생했을 때, 시스템은 다음 질문에 즉각 답할 수 있어야 합니다.
• 누가, 언제, 어떤 코드를 수정했는가?
• 어떤 브랜치에서 작업되었으며, 승인권자는 누구인가?
• 코드 품질 검사와 보안 스캔을 정상적으로 통과한 커밋인가?
• 현재 운영 환경에 실시간 서비스 중인 소스 버전은 무엇인가?
GitLab과 같은 최신 형상관리 플랫폼을 체계적으로 구성하면 브랜치 전략(Branching Strategy), 코드 리뷰, 병합 요청(Merge Request), 다단계 승인 결재선을 단일 거버넌스로 확립할 수 있습니다. 이처럼 소스코드 변경 이력에 대한 투명한 추적성(Audit Trail)이 확보되어야만, 그 위에 품질 및 보안 자동화 점검을 안정적으로 안착시킬 수 있습니다.
CI/CD, 무조건 빠른 자동화보다 '통제 가능한 자동화'
CI/CD(지속적 통합·지속적 배포)는 변경 사항을 빠르게 검증하고 배포하는 핵심 체계입니다. 그런데 핵심 업무 시스템에서는 자동화 자체보다 자동화를 통제할 수 있는지가 더 중요합니다. 검증되지 않은 취약한 코드가 자동으로 운영 환경에 반영되면, 그 속도만큼 장애와 보안 위험도 빠르게 퍼지기 때문입니다.
DevSecOps 관점의 CI/CD는 각 단계를 하나의 파이프라인으로 연결합니다.
1. 코드 변경 및 커밋 (Code Change)
2. 빌드 (Build)
3. 테스트
4. 코드 인스펙션(품질·보안 점검)
5. 승인
6. 배포
7. 모니터링
테스트와 코드 인스펙션에서 보안·품질을 점검하고, 기준을 통과하지 못한 코드는 개발자에게 되돌아갑니다.
특히 운영 반영 직전에는 코드 품질 기준을 통과했는지, 보안 점검 결과에 문제가 없는지, 승인을 받았는지 반드시 확인할 수 있어야 합니다. 이 조건 중 하나라도 충족하지 못하면 배포가 멈추는 구조, 이것이 '통제 가능한 자동화'입니다.
도구는 각자의 역할이 있습니다
도구 | 역할 | DevSecOps에서의 의미 |
GitLab | 형상관리 | 변경 이력 추적, 협업 코드 리뷰, 병합 권한 통제의 단일 기준점 |
Jenkins | CI/CD 파이프라인 | 빌드·점검·테스트·배포 전 과정을 표준 워크플로우로 자동 실행 |
SonarQube | 코드 인스펙션 | 코드 스멜, 잠재적 보안 취약점, 시큐어코딩 위배 사항 수치화 탐지 |
이 도구들을 파편화된 상태로 개별 운용하면 도구별 사일로(Silo)가 발생합니다. GitLab에 변경 사항이 푸시되면 Jenkins가 파이프라인을 트리거하고, 그 흐름 속에서 SonarQube가 품질과 보안 규정을 엄격히 검사하여 통과 여부를 GitLab으로 되돌려주는 유기적 연계가 갖추어질 때 비로소 진정한 DevSecOps 플랫폼이 완성됩니다.
다음 편 예고
3편에서는 취약점을 더 일찍 찾아내는 코드 인스펙션과 보안 진단, 그리고 공공기관 L사의 실제 전환 사례를 소개합니다
