현대 소프트웨어 개발 환경에서 보안은 더 이상 릴리스 직전에 점검하는 선택 사항이 아닙니다. 개발 초기 단계부터 보안을 내재화하고, 자동화된 도구로 지속적으로 검증하는 체계가 필수가 되었는데요. 애플리케이션 보안 테스팅 도구를 개발하는 스패로우 역시 이러한 변화에 맞춰 사내 개발보안 문화를 정립하고 DevSecOps를 실제 개발 프로세스에 적용해왔습니다. 스패로우에서는 어떻게 DevSecOps를 실제로 구현했는지 그 여정을 소개합니다!

■ ​스패로우는 왜 DevSecOps를 선택했을까요?

과거 스패로우의 보안 점검 프로세스는 개발팀이 제품 기능 개발을 완료한 뒤 품질 검증을 진행함과 동시에 보안 점검을 수행하는 형태였습니다. 이 과정에서 취약점이 발견되면 개발팀으로 회신하여 취약점을 수정하고 재점검을 하는 방식이었죠. 그러나 이 과정에서 다양한 문제들이 발생했습니다.

제품 릴리즈 직전 발견된 취약점으로 인해 릴리즈 일정이 지연되기도 했고, 이미 작성되어 여러 검증을 거친 코드를 다시 수정하고 재점검하는 데 상당한 시간과 비용이 소요되었습니다. 개발 후반부로 갈수록 코드 수정의 파급 범위가 넓어지고, 연관된 테스트 케이스도 다시 검증해야 했기 때문입니다.

이러한 문제들을 해결하기 위해 스패로우는 ‘보안을 소프트웨어 개발 생명 주기 전반에 통합하자’는 목표 아래 Shift-Left 전략을 채택했습니다. 이 전략의 핵심은 개발자가 코드를 작성하는 순간부터 보안을 고려하고, 자동화된 보안 테스팅 도구가 이를 즉각적으로 검증하는 것입니다.

■ ​DevSecOps 파이프라인 구축 3단계

1️⃣ 개발 단계에 보안 테스팅 통합하기
DevSecOps 파이프라인의 첫 단계는 개발 단계에 보안 테스팅을 통합하는 일입니다. 개발자는 소스 코드를 작성하며 수시로 보안 테스팅을 수행합니다. 이 과정을 통해 취약한 코드나 안전하지 않은 오픈소스 구성 요소가 저장소에 유입되는 것을 차단할 수 있습니다. 개발 중에 취약점을 즉시 발견하고 조치하면, 나중 단계에서 수정하는 것에 비해 비용을 최대 30배까지 절감할 수 있다는 연구 결과도 있으며, 개발 단계에서는 해당 코드를 작성한 개발자가 바로 수정할 수 있어 컨텍스트 전환 비용이 최소화됩니다.

​

2️⃣ 빌드 단계에 보안 검사 통합하기
다음 단계는 CI/CD 빌드 단계에 보안 검사를 통합하는 일입니다. 코드 통합과 배포를 자동으로 수행하는 빌드 파이프라인에 애플리케이션 보안 테스팅 단계를 추가하여, 설정된 보안 기준에 미달하는 경우 빌드가 자동으로 실패하며 담당 개발팀에게 알림이 전송됩니다. 개발팀은 상세한 분석 리포트를 참고하여 취약점을 조치한 후 다시 빌드를 진행합니다.

​

3️⃣ 구성 요소 지속 모니터링하기
마지막 단계는 배포된 애플리케이션에 포함된 구성 요소를 지속적으로 모니터링하는 일입니다. 배포 시점에는 안전하다고 판단된 오픈소스 라이브러리나 의존성 패키지도 시간이 지나면서 새로운 취약점이 공개될 수 있습니다. 이러한 상황에 효과적으로 대응하기 위해 스패로우는 배포된 소프트웨어를 대상으로 SBOM(Software Bill of Materials)을 생성하고 관리합니다. SBOM에는 애플리케이션을 구성하는 모든 구성 요소 정보가 포함되어 있어, 새로운 취약점이 공개되었을 때 제품이 영향을 받는지 즉시 확인하여 효과적으로 모니터링할 수 있습니다.

■ ​DevSecOps의 완성, 사내 개발보안 문화 조성하기

자동화된 파이프라인 구축만으로는 DevSecOps가 성공적으로 정착되기 어렵습니다. 조직 내 개발보안 문화의 조성이 함께 이루어져야 합니다. 스패로우는 제품 개발에 참여하는 구성원들의 보안 역량을 향상시키기 위해 여러 교육 프로그램을 운영하고 있습니다. 동시에 신규 입사자들을 대상으로는 DevSecOps 프로세스 및 내부 시큐어코딩 가이드라인에 대한 온보딩 교육을 제공합니다.

또한, 처음부터 엄격한 정책을 적용하면 개발자들의 저항이 생기고 프로세스가 형식적으로 운영될 위험이 있습니다. 이를 최소화하기 위해 단계적으로 프로세스를 확대하는 접근법을 사용했습니다. 초기에는 개발자들이 도구와 프로세스에 익숙해질 수 있도록 보안 테스트 결과에 따른 빌드 차단 없이 리포트만 생성하고 검토하는 수준으로 운영했습니다. 이후 개발자들이 프로세스에 익숙해지면서 취약점의 심각도에 따라 차단의 범위를 확대하는 방식으로 정책을 강화했습니다. 마지막으로 실제 제품 개발 환경에서 발생할 수 있는 다양한 예외 상황을 처리하기 위한 예외 승인 프로세스도 함께 확립했습니다.

■ 그 여정에서 배운 것들

안전한 소프트웨어 개발을 위해 DevSecOps 프로세스를 도입할 때 중요한 것은 처음부터 완벽한 시스템을 구축하는 것보다 작게라도 시작해서 지속적으로 개선해 나가는 것입니다. 이 과정에서 단순히 자동화 도구를 도입하는 것만으로는 부족하며, 조직 내 구성원이 왜 보안이 중요한지, 어떻게 하면 안전한 소프트웨어를 개발할 수 있는지에 대한 진정한 이해와 공감이 필요합니다.

DevSecOps는 하루아침에 완성되는 것이 아닙니다. 도구, 프로세스, 그리고 무엇보다 사람들의 인식 변화가 함께 이루어져야 합니다. 스패로우의 여정이 비슷한 고민을 하는 조직들에게 작은 영감이 되었으면 합니다. 보안은 제품의 품질이자 고객에 대한 약속입니다. 소프트웨어 개발 생명 주기 전반에 보안을 자연스럽게 통합한다면, 고객이 안심하고 사용할 수 있는 신뢰받는 소프트웨어를 만들 수 있습니다.

또한, 조직 구성원 모두가 보안의 중요성에 공감하는 문화가 함께 자리 잡아야 비로소 진정한 DevSecOps를 실현할 수 있습니다. 스패로우는 앞으로도 안전한 소프트웨어 개발 환경을 만들기 위한 기술과 경험을 꾸준히 공유해 나가겠습니다.