무엇이 잘못되어 있었나?
극적인 것은 없었습니다. 그게 핵심입니다. 보안은 릴리스마다 마지막에 손으로 검토되었습니다. 발견은 코드가 끝난 뒤에 도착했고, 그래서 릴리스는 기다렸고, 같은 재작업이 스프린트마다 돌아왔습니다. 지연은 눈에 보이는 부분일 뿐이었습니다. 그 아래에서 감사 지적은 쌓였고, 오래된 코드는 아무도 갚을 시간이 없는 부채를 안았고, 서드파티 구성 요소는 검사 없이 운영에 들어갔고, 작은 보안팀은 늘 뒤처져 있었습니다. 모두가 자기 일을 하고 있었습니다. 일이 잘못된 자리에 있었을 뿐입니다. 빨간 표시는 출구 관문입니다. 길 아래의 점은 각 단계를 재는 자리입니다.
무엇을 했나?
도구가 아니라 사람에서 시작했습니다. 한 임원이 변화의 후원자가 되기로 했고, DevSecOps 포럼이 모이기 시작했고, 모든 개발팀이 보안 챔피언, 즉 질문을 양방향으로 나르는 사람을 한 명씩 정했습니다. 그런 다음에야 로드맵을 그렸습니다. 가이드라인, 표준, 파이프라인에 꽂을 도구들을 OWASP DevSecOps Maturity Model로 측정합니다. 목표는 단순했습니다. 12개월 안에 모든 영역에서 레벨 2, 가장 중요한 두 곳인 빌드와 배포, 테스트와 검증에서 레벨 3.
한 해를 네 단계로 잘랐고, 각 단계에는 통과해야 나갈 수 있는 관문을 두었습니다. 첫 세 달은 기반이었습니다. 평가, 정책, 그리고 한두 개의 시범 애플리케이션에서 코드와 의존성 검사, 그 이상은 아니었습니다. 3개월에서 6개월은 자동화였습니다. 정책 게이트, 시크릿 검사, 동적 테스트. 6개월에서 12개월은 확장이었습니다. 새 팀이 안전하게 시작하도록 하는 파이프라인 템플릿, 인프라와 컨테이너 검사. 12개월 뒤에는 최적화가 옵니다. 이것은 끝나지 않습니다. 런타임 모니터링과 분기마다 숫자를 들여다보는 일.
수명 주기의 모든 단계에 통제가 붙었습니다. 계획할 때 위협 모델링. 코딩할 때 시크릿 검사. 빌드할 때 코드, 의존성, 구성 요소 목록 검사. 테스트할 때 동적 테스트. 릴리스할 때 서명된 산출물과 정책 게이트. 배포할 때 시크릿 금고를 갖춘 인프라와 컨테이너 검사. 운영할 때 모니터링. 그리고 주인 없는 도구는 썩기 때문에, 정책, 파이프라인 운영, 수정, 분류에 대한 책임의 규칙을 RACI로 다시 쓰고 NIST SSDF, OWASP SAMM, ISO/IEC 27001:2022에 맞추어, 감사인이 요구하는 증거가 저절로 쌓이게 했습니다.
무엇이 바뀌었나?
보안은 사건이기를 멈추고 습관이 되었습니다. 습관이 유지되는지는 네 개의 숫자가 말해 줍니다. 각각 첫 단계에서 기준선을 잡았습니다. 치명적 결함을 얼마나 빨리 고치는지, 운영 전에 잡히는 발견의 비율, 안전한 파이프라인을 거치는 애플리케이션 수, 릴리스에 걸리는 시간. 모든 통제는 먼저 시범 운영하고, 다음에 자동화하고, 팀이 신뢰한 뒤에야 릴리스 관문이 되었습니다. 이 순서가 이런 프로그램을 가라앉히는 두 가지 위험, 개발자의 저항과 알림 피로가 뿌리내리지 못하게 했습니다.