DevSecOps란 무엇인가 — 정의·역사·실제 적용

DevSecOps 의 한 줄 정의 — 소프트웨어 전달 파이프라인의 모든 단계 에 보안 책임을 분산시키되, 그 책임을 이행했다는 사실 이 자동으로 증명되는 체계.

이 정의에는 세 가지 단어가 결정적이다 — 모든 단계, 분산, 증명. 하나라도 빠지면 그건 DevSecOps 가 아니라 그냥 보안 도구를 더 붙인 CI 다.

어디서 왔나

DevSecOps 라는 단어는 2012년 전후 미국 국방부 계열에서 등장했고, 2018년 OWASP 가 DevSecOps Maturity Model 을 공개하면서 일반화됐다. 핵심 동기는 단순했다 — 보안이 출시 직전에만 개입하면, 늦었거나 차단할 권한이 약하다.

그래서 슬로건이 됐다 — "Shift Left". 보안 검증을 파이프라인의 왼쪽(=일찍) 으로 옮기자.

"Shift Left" 가 잘못 이해되는 지점

많은 조직이 Shift Left 를 "개발자에게 보안을 떠넘긴다" 로 번역한다. 그래서 이런 일이 벌어진다.

• 개발자 PC 에 SAST 도구가 강제 설치된다.
• PR 마다 SAST/DAST/SCA 가 동시에 돌아 빌드 시간이 두 배가 된다.
• 위반이 발견돼도 예외 신청 절차 가 무거워서 결국 무시된다.

이건 분산 도 아니고 증명 도 아니다. 개발자에게 마찰만 주는 보안 이다.

Shift Left 는 책임을 떠넘기는 것 이 아니라 판단의 비용을 낮추는 것 이다.

진짜 DevSecOps 의 세 가지 요건

1. 단계별 적정 검사

전 단계에 같은 검사를 도배하지 않는다. 단계마다 비용 대비 가치 가 다른 검사가 있다.

2. 분산 된 책임, 통합 된 가시성

보안팀은 게이트가 아니라 플랫폼 을 제공해야 한다. 개발팀은 게이트를 통과시키는 게 아니라 플랫폼이 만드는 신호를 자기 제품 품질로 흡수 해야 한다.

이걸 가능하게 하는 게 공통 데이터 평면 이다. 어떤 PR 에 어떤 검사가 통과/실패했고, 어떤 예외가 누구의 승인으로 적용됐는지 — 보안과 개발이 같은 그래프를 본다.

3. 증명 가능한 감사

규제 산업(공공·금융) 에서는 한 단계 더 들어간다 — 그 검사가 실제로 그 시점에 실행됐다는 사실 자체 를 증명해야 한다.

who?     이 검사를 실행한 주체 (빌드 워커, 작업자, 에이전트)
what?    어떤 입력에 어떤 도구·버전을 적용했고
when?    정확히 언제
result?  결과는 무엇이며 어떻게 보존되었는가

이 네 개가 변조 불가능한 형태(WORM 스토리지·서명된 로그) 로 보존되지 않으면, 사고 발생 시 증거 가 없다.

온프레미스에서 더 어려운 이유

폐쇄망 / 분리망 환경에서는 클라우드 SaaS 보안 도구를 못 쓴다 는 단순한 한계 외에도 두 가지가 더해진다.

1. CVE/취약점 DB 를 어떻게 동기화하나 — 인터넷이 없는데 SCA 도구의 의미가 뭔가? 답은 내부 미러 와 오프라인 배포 가능한 도구 선택.
2. 에이전트 / 자동화 주체의 권한 모델 — 사람과 다른 권한 모델로 자동화가 동작하면 감사가 깨진다. 사람과 동일한 권한 모델에 묶여야 한다.

정리

DevSecOps 는 도구가 아니다. 보안 책임을 단계별로 적정 수준에서 분산시키되, 그 이행을 자동으로 증명할 수 있는 체계 다. 이 체계가 없으면, 도구를 100개 붙여도 사고 났을 때 답을 못 한다.

FAQ

Q. 우리 조직은 SAST/SCA 도구를 다 쓰는데 왜 매번 사고가 나나? A. 도구가 부족한 게 아니라 도구의 결과가 한 평면에 모이지 않아서 다. PR/배포/감사 트레이스가 분리돼 있으면 통합된 결정이 안 나온다.

Q. DevSecOps 와 그냥 보안의 차이? A. 보안 = 별도 조직의 gate. DevSecOps = 파이프라인의 기본값 으로 보안이 흡수된 상태. 다른 점은 언제 개입하느냐 가 아니라 책임이 어디에 있느냐.

Q. 작은 팀에서도 의미가 있나? A. 있다. 도구는 적게 골라도 된다. 핵심은 시크릿/취약 의존성 차단 + 증명 가능한 빌드 감사 두 개. 그것만 잘 되면 작은 팀일수록 효과가 크다.