해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 62 - Shifting Left for DevSecOps Using Modern Edge Platforms
1. Shift Left와 Shift Right
현대 기업 환경에서 보안 침해를 탐지하는 데 걸리는 시간은 평균적으로 200일이 넘는다.
이는 단순한 보안 공백을 넘어 막대한 비즈니스 손실로 이어진다.
IBM의 연구에 따르면, 테스트 단계에서 발견된 버그를 수정하는 비용은 설계 단계에서 발견했을 때보다 무려 15배나 더 많이 소요된다.
문제를 늦게 발견할수록 금전적 비용뿐만 아니라 재작업에 드는 시간과 엔지니어의 에너지가 소모되며, 이는 궁극적으로 제품 로드맵의 지연을 초래한다.
이러한 비효율을 타파하고 리소스 낭비를 막기 위해, 웹 애플리케이션 및 API 보호(WAAP : Web Application and API Protection)를 DevOps 수명 주기에 내재화하는 DevSecOps와 시프트 레프트 전략이 필수적으로 요구된다.
DevSecOps는 완전히 새로운 개념이라기보다 기존 DevOps 모델의 확장에 가깝다.
핵심은 소프트웨어 개발 수명 주기(SDLC : Software Development Life Cycle)의 모든 단계에 보안을 통합하는 것이다.
이를 이해하기 위해서는 Shift Left와 Shift Right의 개념적 차이를 명확히 구분해야 한다.
-
시프트 레프트 (Shift Left): 예방과 조기 발견
-
기존의 Waterfall 방식이나 초기 모델에서는 보안이 프로세스의 가장 오른쪽(배포 직전 혹은 이후)에 위치
-
Shift Left는 보안 프로세스를 개발 타임라인의 왼쪽, 즉 기획 및 개발 초기 단계로 이동시키는 것을 의미
-
목적: 보안 취약점의 예방 및 조기 수정
-
주요 활동:
-
설계 단계의 위협 모델링
-
개발자 IDE(통합 개발 환경) 내 보안 플러그인 활용
-
소스 코드 정적 분석(SAST) 및 소프트웨어 구성 분석(SCA)
-
-
효과: 개발자가 코드를 작성하는 순간 보안 결함을 구문 오류처럼 즉시 인지하고 수정함으로써, 수정 비용을 최소화한다.
-
-
시프트 라이트 (Shift Right): 관찰과 대응
-
운영 및 모니터링 단계에서의 보안을 강화하는 것을 의미
-
아무리 초기에 철저히 검증해도 100% 완벽한 보안은 불가능하기 때문에, 실제 운영 환경에서의 가시성을 확보하는 것
-
목적: 실시간 위협 탐지, 데이터 수집, 빠른 사고 대응
-
주요 활동:
-
실운영 환경 모니터링 및 로깅
-
카오스 엔지니어링(Chaos Engineering)을 통한 회복 탄력성 테스트
-
사용자 피드백 루프 활용
-
-
효과: 배포 이후 발생할 수 있는 미지의 위협(Zero-day 등)을 탐지하고, 실제 사용자 경험에 기반한 보안 데이터를 수집하여 다시 개발 단계로 피드백을 전달한다.
-
결론적으로 성공적인 DevSecOps는 시프트 레프트를 통해 결함을 최소화하고, 시프트 라이트를 통해 잔존 위험을 관리하는 순환 구조를 갖추는 것이다.
2. 보안의 철학
프레젠테이션에서는 보안을 개발이 끝난 후 덧붙이는 부착물로 인식해서는 안 된다고 한다.
케이크를 다 구운 뒤 마지막에 바르는 아이싱처럼 방화벽을 설치하는 방식은 비효율적이다.
보안은 반죽에 섞이는 밀가루처럼 프로세스 전체에 녹아들어 있어야 하며, 제대로 구현된다면 겉으로 드러나지 않아야 한다고 주장한다.
또한, 보안은 비즈니스의 속도를 늦추는 장애물이 아니다.
경주용 자동차의 강력한 브레이크가 존재하는 이유는 차를 멈추기 위해서가 아니라, 더 빨리 달리고 코너를 과감하게 공략하기 위함이다.
즉, 강력한 보안 프로세스는 기업이 리스크를 통제하며 비즈니스 속도를 가속화할 수 있게 돕는다고 한다.
3. Shift Left 구현 전략
단순한 개념을 넘어, 실제 파이프라인에서 시프트 레프트를 구현하는 방법은 다음과 같다.
-
기획 (Plan): 코드를 작성하기 전부터 보안 위협을 식별하는 위협 모델링을 수행
-
코딩 (Code): 개발 환경(IDE)에 보안 스캔 도구를 내장하여 실시간 피드백을 제공
-
빌드 (Build):
-
소프트웨어 구성 분석(SCA : Software Composition Analysis)을 통해 오픈소스 라이브러리의 버전과 취약점(예: Log4j 구버전 등)을 식별
-
SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)을 관리
-
-
테스트 (Test) 및 가상 패치:
-
전통적으로 운영 단계에 있던 웹 애플리케이션 방화벽(WAF)이나 API 보호 솔루션을 테스트 단계로 가져와 적용
-
가상 패치의 힘:
-
만약 배포 직전 취약점이 발견되면, 과거에는 배포를 중단하고 코드를 수정해야 했음.
-
-
하지만 보안 솔루션을 테스트 단계에 통합하면, 코드를 당장 수정하지 않더라도 보안 솔루션 단에서 해당 공격 경로를 차단하는 규칙을 적용 (가상 패치)하여 배포 일정은 그대로 유지할 수 있음.
-
근본적인 코드 수정은 다음 배포 사이클에서 진행하면 되므로 비즈니스 속도를 저해하지 않는 장점 존재
-
-
4. DevSecOps 성공을 측정하는 핵심 성과 지표 (KPI)
조직이 DevSecOps를 얼마나 효과적으로 수행하고 있는지, 그리고 시프트 레프트가 제대로 작동하는지를 판단하기 위해서는 정량적인 지표 관리가 필수적이다.
단순한 보안성 강화가 아닌 구체적인 수치로 측정해야 한다.
-
애플리케이션 커버리지 (Application Coverage)
-
정의: 조직 내 전체 애플리케이션 중 표준화된 보안 프로세스(SCA, SAST, DAST 등)가 적용된 비율.
-
목표: 90~95% 이상의 커버리지를 달성해야 사각지대를 없앨 수 있다.
-
-
평균 탐지 시간 (MTTD - Mean Time To Detect)
-
정의: 보안 침해나 취약점이 발생한 시점부터 조직이 이를 인지하는 데까지 걸리는 시간.
-
맥락: 업계 평균은 약 200일이다. 시프트 레프트가 잘 정착된 조직은 이를 실시간 혹은 며칠 단위로 획기적으로 단축해야 한다.
-
-
평균 해결 시간 (MTTR - Mean Time To Resolve)
-
정의: 취약점이 발견된 후 이를 해결(패치 또는 완화)하는 데 걸리는 시간.
-
맥락: 업계 평균은 약 70일이다. 하지만 성숙한 조직은 Log4j와 같은 치명적 이슈 발생 시, 코드 수정 전 가상 패치 등을 통해 수 시간(4시간 이내) 내에 위협을 무력화할 수 있다.
-
-
배포 속도 및 롤백 빈도 (Release Velocity & Rollback Rate)
-
정의: 소프트웨어 릴리스 빈도와 보안 문제로 인해 운영 단계에서 배포를 Rollback하는 횟수.
-
해석: 시프트 레프트가 성공적이라면, 운영 단계에서의 롤백은 줄어들고 개발 단계에서의 수정이 늘어나야 한다. 운영 단계의 롤백은 비용이 가장 많이 들기 때문이다.
-
-
비즈니스 영향도 (Business Impact)
-
정의: 보안 감사 통과율 및 B2B 계약 시 보안 검토 소요 시간.
-
해석: 보안이 내재화된 조직은 고객사의 까다로운 보안 질의에 즉각 대응할 수 있다. 이는 계약 체결 속도를 높여 매출 증대에 직접적으로 기여한다.
-
5. 결론
결론적으로, 웹 애플리케이션 및 API 보호를 개발 초기 단계로 통합하는 시프트 레프트는 비용 절감과 리스크 관리를 넘어 비즈니스 성장을 위한 필수 생존 전략이다.
보안은 개발 후반부의 '아이싱'이 아닌 전체 프로세스의 '밀가루'처럼 내재화되어야 하며, 이를 통해 수정 비용을 획기적으로 줄이고 배포 속도를 가속화할 수 있다.
기업은 가상 패치와 같은 기술적 수단과 명확한 KPI 관리를 통해, 보안을 단순한 규제 준수의 대상이 아닌 매출 증대와 시장 경쟁력을 견인하는 핵심 비즈니스 파트너로 재정의해야 한다.
