4.9 보안 소프트웨어 개발 수명 주기
개요와 동기
대부분의 보안 결함은 이국적이지 않습니다. 평범한 실수입니다. 빠진 인가 검사, 신뢰한 입력, 아무도 갱신하지 않은 의존성, 설정 파일에 붙여넣은 비밀. 그것을 비싸게 만드는 것은 언제 잡히느냐입니다. 요구 사항을 쓰는 동안 발견된 결함은 대화 한 번의 비용이 듭니다. 출시 일주일 전 침투 테스트에서 발견된 같은 결함은 소동의 비용이 들고, 프로덕션에서 발견되면 인시던트, 공개, 신뢰 상실의 비용이 듭니다. 보안 소프트웨어 개발 수명 주기(SSDLC)는 끝에 보안 테스트를 덧붙이는 대신, 소프트웨어를 계획, 설계, 구축, 리뷰, 출하, 운영하는 방식의 모든 단계에 보안을 짜 넣어 이런 결함을 일찍, 지속적으로 잡는 규율입니다.
이 장은 4부의 프로세스 척추입니다. 4.2장의 애플리케이션 수준 방어(공격에 저항하는 코드를 쓰는 방법)와 4.4장의 런타임 규율(방어가 시험받을 때 탐지하고 대응하는 방법)을 묶고, 4.1장(보안 기초와 문화)에서 마음가짐을 물려받고, 4.6장(컴플라이언스와 거버넌스)이 감사 산출물로 바꾸는 증거를 만듭니다. 그 장들이 무엇과 왜를 다룬다면 이 장은 언제와 어떻게를 다룹니다. 전달 흐름의 어느 지점에 각 통제가 속하는지, 누가 소유하는지, 어떤 관문을 지키는지입니다.
큰 팀에서 수익은 지렛대입니다. 수백 명의 엔지니어가 각자 독립적으로 보안을 얼마나 할지 결정하면, 가장 약한 고리가 실제 노출을 정합니다. 정의된 수명 주기는 안전한 길을 기본 경로로 만들어, 평균적인 엔지니어가 영웅적 행동 없이 합리적으로 안전한 소프트웨어를 출하하게 합니다. 기업에게 그 일관성은 모든 감사와 통합의 비용을 낮춥니다. 시민이 세금이나 급여 데이터의 다른 제공자를 고를 수 없는 정부에게, 문서화된 수명 주기는 흔히 운영의 법적 전제 조건이며, 이 장의 프레임워크가 그 의무에 대응됩니다.
핵심 원칙
- 보안을 왼쪽으로 옮기십시오. 결함을 가장 싼 단계, 곧 항상 가장 이른 단계에서 찾아 고치십시오.
- 보안을 사람이 아니라 파이프라인의 속성으로 만드십시오. 안전한 길이 쉬운 길이 되도록 관문을 자동화하십시오.
- 모든 단계에 소유자와 관문을 두십시오. 요구 사항에서 운영까지, 분명한 통과 조건과 함께.
- 체크박스가 아니라 위험을 관리하십시오. 악용 가능성과 영향으로 중요한 결함의 우선순위를 정하고, 하나의 느린 주기 말 감사보다 많은 작은 지속적 검사를 선호하십시오.
- 공격자가 그렇게 하므로 의존성과 빌드 시스템을 공격 표면의 일부로 다루십시오.
- 프로그램을 측정하십시오. 측정할 수 없는 수명 주기는 개선할 수 없는 수명 주기입니다.
권장 사항
전체 수명 주기에 걸쳐 보안을 왼쪽으로 옮긴다
Shift-left 테스트는 검증을 전달 흐름의 더 앞으로, 릴리스 직전이 아니라 결정이 내려지는 순간 쪽으로 옮기는 것을 뜻합니다. 보안에 적용하면 목표가 다시 구성됩니다. 마지막에 보안을 테스트해 넣는 것이 아니라 처음부터 설계하고 구축해 넣은 뒤 지속적으로 검증합니다. 경제성은 분명합니다. 기획 회의에서 다시 쓴 요구 사항은 거의 공짜입니다. 코드가 존재한 뒤 다시 한 설계 결함은 며칠이 들고, 프로덕션에서 패치한 취약점은 인시던트가 듭니다. 그러나 shift-left에는 실패 방식이 있습니다. 보안 도구 더미를 개발자에게 떠넘기고 끝났다고 부르는 것입니다. 잘하면 각 초기 검사를 그에 따라 행동할 지원과 짝지어, 발견 사항이 맥락, 수정 제안, 소유자와 함께 도착합니다.
보안 요구 사항과 악용 사례를 쓴다
보안은 어떤 코드보다 앞서, 일을 구성하는 방식에서 시작됩니다. 시스템이 해야 할 일을 말하는 기능 요구 사항과 함께, 절대 해서는 안 되는 일과 보장해야 하는 일을 말하는 보안 요구 사항을 쓰십시오. 어떤 데이터가 민감한지, 누가 인가되는지, 무엇이 기록되어야 하는지, 어떤 규제가 적용되는지입니다. 그다음 사용자 스토리를 악용 사례와 오용 사례로 보완하십시오. 적대적 행위자가 각 기능을 무력화하려고 시도할 방법의 짧은 서술입니다. 사용자 스토리가 “고객이 비밀번호를 재설정한다”라고 말하는 곳에서 악용 사례는 “공격자가 다른 사람의 비밀번호를 재설정한다”를 묻고, 그 질문이 속도 제한, 토큰 만료, 검증에 대한 진짜 요구 사항을 이끕니다. 이는 아직 화면 위의 단어일 때 결함의 부류 전체를 드러냅니다. 악용 사례를 스토리에 붙여 두어 설계, 리뷰, 완료의 정의로 함께 이동하게 하십시오.
설계에 위협 모델링 관문을 둔다
위협 모델링은 만들기 전에 설계를 검토해 무엇이 잘못될 수 있는지 찾는 구조화된 실천입니다. 자산을 식별하고, 신뢰 경계를 가로지르는 데이터 흐름을 매핑하고, 위협을 열거하고, 완화를 결정합니다. 설계를 바꾸는 것이 아직 싼 시점에 작동하므로 할 수 있는 지렛대 효과가 가장 큰 보안 활동입니다. 인증, 민감한 데이터, 돈, 새 신뢰 경계에 닿는 모든 기능에 대해 가벼운 관문으로 만들고, STRIDE라는 약어로 알려진 체크리스트인 위장, 변조, 부인, 정보 노출, 서비스 거부, 권한 상승 같은 위협 범주를 훑으십시오. 의례를 비례하게 유지하십시오. 화이트보드, 데이터 흐름 다이어그램, 악용 사례를 갖춘 한 시간짜리 세션이 공식 문서가 잡을 대부분을 잡습니다. 발견한 위협, 선택한 완화, 의식적으로 수용한 위험을 기록하십시오. 그 기록이 4.6장의 설계 단계 증거와 4.2장의 보안 설계를 위한 출발 지도가 됩니다. 중요한 설계 변경에 묶으십시오. 그렇지 않으면 한 번 쓰고 다시 보지 않는 문서로 쇠퇴합니다.
보안 코딩 표준과 안전한 기본값을 채택한다
사용하는 각 언어와 프레임워크에 구체적인 보안 코딩 표준을 엔지니어에게 주십시오. 질의를 매개변수화하는 방법, 출력을 인코딩하는 방법, 입력을 검증하는 방법, 비밀을 다루는 방법, 어떤 암호 라이브러리를 호출하고 어느 것을 절대 직접 만들지 말지입니다. 이를 안전한 기본 구성 요소와 짝지으십시오. 안전한 선택을 기본으로, 안전하지 않은 선택을 어렵게 만드는 공유 라이브러리로, 엔지니어가 기억해서가 아니라 공짜로 출력 인코딩이나 매개변수화된 질의를 얻게 합니다. 최고의 표준은 도구가 시행하는 것이며, 위반이 리뷰어가 알아채는 데 의존하지 않고 검사를 실패시킵니다. 실제로 침해를 일으키는 부류를 덮도록 잘 알려진 약점 카탈로그에 비추어 다듬고, 가치보다 소음을 더 많이 만드는 규칙은 쳐내십시오.
코드 리뷰에서 보안을 명시한다
코드 리뷰(2.5장)는 자연스러운 보안 관문입니다. 변경을 읽는 두 번째 사람이 빠진 인가 검사나 신뢰한 입력을 알아채기에 좋은 위치에 있기 때문입니다. 리뷰어가 기억하기를 바라는 대신 보안 차원을 명시하십시오. 입력 처리, 인가, 비밀, 암호, 의존성 변경의 위험한 영역에 맞춘 짧은 보안 체크리스트를 리뷰 템플릿에 추가하십시오. 인증이나 결제 경로 같은 민감한 코드의 변경을 보안 깊이가 있는 리뷰어에게 라우팅하고, 그 경로를 표시해 라우팅이 자동이 되게 하십시오. 사람의 리뷰 전에 자동화된 검사를 실행해, 리뷰어가 도구가 이미 잡은 린트 수준의 발견 사항이 아니라 로직과 설계 의도(맥락적이고 새로운 것)에 주의를 쓰게 하십시오.
파이프라인의 알맞은 지점에 알맞은 자동화 관문을 둔다
여러 부류의 보안 도구가 지속적 통합 및 전달 파이프라인(8.1장)에 속하며, 각각이 어디에 맞는지 알면 한 도구가 다른 도구의 일을 하기를 기대하지 않게 됩니다. 정적 애플리케이션 보안 테스트(SAST)는 소스 코드를 실행하지 않고 분석해 모든 커밋에서 인젝션과 안전하지 않은 API 사용 같은 결함을 잡습니다. 소프트웨어 구성 분석(SCA)은 서드파티 및 오픈 소스 의존성의 알려진 취약점과 라이선스 문제를 검사하며, 2.18장의 의존성 및 공급망 관리의 파이프라인 쪽 팔입니다. 비밀 스캔은 실수로 커밋된 자격 증명, 토큰, 키를 찾으며, 커밋 시점(pre-commit 훅으로)과 후비책으로서의 파이프라인 양쪽에 속합니다. 코드형 인프라(IaC) 스캔은 Terraform, CloudFormation, 쿠버네티스 매니페스트의 안전하지 않은 설정을 확인해, 열린 스토리지 버킷을 아직 diff일 때 잡습니다.
동적 애플리케이션 보안 테스트(DAST)는 엔드포인트를 탐색하는 공격자처럼 실행 중인 애플리케이션을 바깥에서 실행하며, 배포된 테스트나 스테이징 환경에 대해 더 뒤에 맞습니다. 상호작용형 애플리케이션 보안 테스트(IAST)는 실행 중인 애플리케이션을 계측해 기능 테스트 중 안에서 관찰하며, 정적 통찰과 동적 커버리지를 결합하고 거짓 양성을 줄입니다. 규칙으로, SAST, SCA, 비밀 스캔, IaC 스캔은 빌드를 관문 통제하고, DAST와 IAST는 실행 중인 시스템을 검증합니다. 모두를 중요한 것에서 실패하고 나머지는 경고하도록 조정하십시오. 늑대가 나타났다고 외치는 관문은 팀이 끄는 관문이기 때문입니다.
전달 팀에 보안 챔피언을 심는다
중앙 보안 팀은 수백 명의 엔지니어를 위해 모든 변경을 리뷰할 수 없고, 먼 문지기로 운영되는 보안 기능은 팀이 우회하는 병목이 됩니다. 보안 챔피언 모델은 각 전달 팀 안에 보안 의식이 있는 엔지니어를 심어 이를 해결합니다. 전업 전문가가 아니라 추가 교육, 중앙 팀과의 직통선, 지역적으로 보안 기준을 높일 명시적 시간을 얻는 개발자입니다. 챔피언은 위협 모델링 세션을 운영하고, 자기 스택의 코딩 표준을 다듬고, 도구 발견 사항을 분류하고, 중앙 정책을 팀의 현실로 번역해, 중앙 팀의 도달 범위를 인원에 선형으로 비례하게 늘리지 않고 확장합니다. 실천 공동체, 인정, 실제 시간으로 챔피언에 투자하십시오. 아니면 그 역할은 조직도의 이름으로 쇠퇴합니다.
확립된 프레임워크에 프로그램을 닻 내린다
수명 주기를 처음부터 발명할 필요는 없습니다. 성숙한 프레임워크가 수십 년의 학습을 담고 있고 감사자에게 공유된 어휘를 주기 때문입니다. Microsoft 보안 개발 수명 주기(SDL)는 Microsoft 자신의 어려운 교훈에서 태어나 단계별 구체적 활동을 처방하는 실천 기반 모델입니다. OWASP SAMM(Software Assurance Maturity Model)과 BSIMM(Building Security In Maturity Model)은 평가 모델입니다. SAMM은 처방적으로 향해 갈 성숙도 목표를 주고, BSIMM은 서술적으로 실제 기업들의 큰 표본이 실제로 하는 일을 알려 줘 벤치마크하게 합니다. NIST 보안 소프트웨어 개발 프레임워크(SSDF)는 특별 간행물 800-218로 발행된, 점점 미국 정부의 소프트웨어 공급망 요건을 떠받치는 간결한 성과 중심 실천의 집합입니다. 넷을 혼란스럽게 섞기보다 하나를 척추로 고르십시오. 프레임워크는 지도이지 영토가 아닙니다. 위험에 맞는 실천을 채택하고, 구현한 것을 기록하십시오. 그 기록이 정확히 4.6장과 10.2장(위험, 감사, 보증)이 필요로 하는 것이기 때문입니다.
완료의 정의에 보안을 넣고 SLA에 따라 시정을 운영한다
관문은 “완료”가 뜻하는 것의 일부일 때만 유지됩니다. 변경이 보안 조건을 충족하기 전에는 완료가 아니도록 팀의 완료의 정의를 확장하십시오. 처리되지 않은 심각도 높은 스캐너 발견 사항 없음, 설계가 바뀌었다면 갱신된 위협 모델, 제대로 관리되는 비밀, 알려진 치명적 취약점 없는 의존성입니다. 이로써 보안이 특별한 사건이 아니라 일상적 인수 기준이 됩니다. 프로덕션으로 빠져나간 발견 사항에는 명시적 시정 서비스 수준 협약(SLA)을 갖춘 취약점 관리 프로세스를 운영하십시오. 심각도에 따라 정해지는 최대 수정 시간으로, 치명적 결함은 며칠 단위로, 낮은 심각도는 더 긴 추적되는 기간으로 측정합니다. 실제 위험으로 우선순위를 정하고, 심각도 점수를 악용 가능성과 노출과 섞어, 방화벽 세 겹 뒤의 이론적 결함보다 인터넷에 노출된 악용 가능한 결함을 먼저 고치십시오. 모든 발견 사항을 하나의 시스템에서 종결까지 추적하고, 다른 운영 지표처럼 연령을 보고하십시오. 아무도 측정하지 않는 SLA는 소원입니다.
공급망 무결성을 처음부터 끝까지 보호한다
공격자는 점점 여러분의 코드가 아니라 그것이 이동하는 경로를 표적으로 삼습니다. 침해된 의존성, 오염된 빌드 단계, 전송 중에 바꿔치기된 서명되지 않은 산출물입니다. 이것이 공급망 공격이며, 방어는 여러 단계에 닿습니다. 모든 릴리스에 무엇이 들어 있는지 정확히 알도록 소프트웨어 자재 명세서(SBOM)를 생성하십시오. 의존성을 고정하고 검증하며, 공용 인터넷에서 직접 가져오지 말고 통제된 내부 레지스트리를 통해 끌어오십시오. 광범위한 권한을 가진 빌드 서버는 가치가 높은 표적이므로 빌드 시스템 자체를 강화하고, 소비자가 실행하는 것이 여러분이 빌드한 것임을 확인할 수 있도록 출처를 갖춘 서명되고 검증 가능한 산출물을 만드십시오. 이런 접점은 2.18장의 의존성 규율과 10.2장의 보증 의무에 연결됩니다. 빌드와 릴리스 파이프라인을 프로덕션 인프라로 다루십시오. 거기의 침해는 다운스트림의 모든 것을 한꺼번에 침해하기 때문입니다.
프로그램을 측정하고 결과를 되먹임한다
측정하는 것을 개선합니다. 수명 주기가 동작하는지 알려 주는 선행 지표를 추적하십시오. 중요한 변경의 위협 모델 커버리지, 예상 관문이 켜진 파이프라인의 비율, 심각도별 평균 시정 시간, 탈출 결함 비율(관문이 잡았어야 할 프로덕션에서 발견된 결함), 팀이 도구를 계속 신뢰하는지 예측하는 거짓 양성률입니다. 결과를 되먹임하십시오. 탈출 결함은 관문을 조정하고, 시끄러운 도구는 조정되거나 교체되고, 되풀이되는 결함 부류는 새 안전한 기본값과 교육을 이끕니다. 측정 없는 수명 주기는 의례로 표류합니다.
장단점
| 접근 방식 | 장점 | 단점 |
|---|---|---|
| 파이프라인의 shift-left 관문 | 가장 싼 수정. 빠르고 지속적인 피드백 | 조정하지 않으면 도구 난립과 경보 피로 |
| 설계의 위협 모델링 관문 | 고치기 싼 동안 설계 결함을 잡음 | 기술과 시간 필요. 다시 보지 않으면 쇠퇴 |
| 팀에 심긴 보안 챔피언 | 보안을 확장. 지역적 소유권과 맥락 | 재원이 부족하거나 인정받지 못하면 희석 |
| 중앙 보안 문지기 | 일관된 기준. 분명한 책임성 | 팀이 우회하는 병목이 됨 |
| 프레임워크에 닻 내린 프로그램 (SDL, SAMM, SSDF) | 검증된 실천. 감사 준비된 어휘 | 의례 위험. 판단 없는 화물 숭배 |
| 엄격한 시정 SLA | 한정된 노출. 측정 가능한 책임성 | 심각도 점수가 잘못되면 조작과 체크박스 채우기 |
| 차단 관문 (빌드 실패) | 나쁜 것이 출하되지 않는다는 강한 보장 | 거짓 양성에서 전달이 멈춤. 우회 압박 |
핵심 긴장은 엄밀함 대 흐름입니다. 파이프라인에 너무 적게 밀어 넣으면 결함이 비싼 곳으로 빠져나가고, 조정하지 않고 너무 많이 밀어 넣으면 소음에 전달을 막거나 팀이 관문이 무의미해질 때까지 경고를 클릭해 넘기도록 훈련시킵니다. 가차 없이 조정하고 각 관문의 강도를 그것이 지키는 위험에 맞춰 해결하십시오. 유출된 자격 증명이나 알려진 치명적 취약점에서는 빌드를 막되, 낮은 심각도 스타일 발견 사항은 경고만 하십시오. 팀이 느끼는 마찰이 위험에 비례할 때, 안전한 길이 최소 저항의 길로 남습니다.
팀과 논의할 질문
오늘 전달 흐름의 어느 단계에서 보안이 실제로 일어나며, 어디서 일어나는 척만 합니까? 대부분의 조직은 진짜 보안 노력이 끝, 곧 릴리스 전 스캔이나 연간 침투 테스트에 모여 있고, 요구 사항, 설계, 리뷰 단계는 열망 속에서만 보안을 언급함을 발견합니다. 현재 흐름을 단계별로 정직하게 매핑하고, 보안 활동에 진짜 소유자와 진짜 관문이 있는 곳과 구호인 곳을 표시하십시오. 최근 기능 하나를 가져와 첫 요구 사항부터 배포까지 그것에 어떤 보안 작업이 진정으로 일어났는지 따라가 보십시오. 찾은 간극이 shift-left 백로그이고, 전부 구호이고 관문이 없는 단계가 결함이 제품에 조용히 들어오는 곳입니다.
스캐너가 발견 사항을 보고하면 다음에 무슨 일이 일어나며, 입증할 수 있습니까? 이 장의 모든 관문의 가치는 발견 사항이 나타난 뒤의 워크플로에 달려 있습니다. 실제 예를 따라가 보십시오. SAST나 SCA 도구가 무언가를 표시하면, 누가 통지받고, 심각도와 악용 가능성은 어떻게 평가되고, SLA는 무엇이고, 어디에 추적되고, 미뤄진 것이 아니라 고쳐졌음을 어떻게 압니까? 많은 팀이 인상적인 도구는 있지만 답이 없으며, 이는 발견 사항이 모두가 무시하도록 배운 큐에 쌓인다는 뜻입니다. 지난 분기의 발견 사항과 심각도별 시정 시간 목록을 내놓을 수 없다면 스캔 습관은 있어도 취약점 관리 프로그램은 없는 것이며, 그 차이가 정확히 감사자와 공격자가 모두 탐색할 것입니다.
어떤 단일 프레임워크가 프로그램의 닻이며, 각 팀이 자기 일에서 “안전하게 완료”가 무엇을 뜻하는지 말할 수 있습니까? 공유된 척추가 없으면 모든 팀이 충분히 안전하다는 자기 정의를 즉흥으로 만들고, 조직의 실제 태세는 백 개의 사적 판단의 평균이 됩니다. 어떤 확립된 프레임워크(Microsoft SDL, OWASP SAMM, BSIMM, NIST SSDF)가 참조인지 함께 결정한 뒤, 그 선택이 현장에 닿았는지 확인하십시오. 전달 팀이 완료의 정의에 있는 보안 조건을 읊고 각각을 시행하는 관문을 가리킬 수 있습니까? 세 다른 팀의 완료의 정의를 비교하십시오. 수렴은 수명 주기가 실재한다는 뜻이고, 발산은 슬라이드 위의 프레임워크와 파이프라인의 즉흥이 있다는 뜻입니다.
어떤 발견 사항이 빌드를 막고, 어떤 것은 경고만 하며, 선이 어디 있는지는 누가 결정했습니까? 모든 관문의 강도는 정책 선택이며, 어느 방향으로든 틀리면 비용이 큽니다. 소음에서 막으면 팀이 전달 압박 아래서 관문을 우회하거나 끄도록 배우고, 모든 것에 경고하면 치명적 항목이 읽히지 않고 빠져나갑니다. 대규모 조직에서 위험은 표류입니다. 각 팀이 자기 임계값을 조용히 다시 조정해 “파이프라인이 초록”이 그룹마다 다른 것을 뜻하고 중앙에서는 실제 노출을 알 수 없게 됩니다. 각 도구의 현재 통과 또는 실패 정책, 팀이 실제로 겪는 거짓 양성률, 재정의된 발견 사항과 그 이유의 최근 예를 가져오십시오. 기업과 정부 환경에서는 누가 위험을 수용할 권한을 가졌고 그 수용이 어디 기록되는지 더하십시오. 이름 붙은 소유자도 서면 정당화도 없이 막히지 않은 치명적 항목은 정확히 감사자가 지적하고 공격자가 찾을 간극이기 때문입니다.
보안 챔피언은 실제 능력입니까 조직도의 이름입니까, 그리고 그것을 실제로 유지하는 정직한 비용은 얼마입니까? 챔피언 모델은 작은 중앙 팀이 수백 명의 엔지니어에게 닿는 방법이지만 조용히 실패합니다. 역할이 배정되고, 시간은 보호되지 않고, 교육은 오지 않으며, 한 분기 안에 아무도 행동하지 않는 직함이 됩니다. 경쟁하는 끌림은 항상 전달 압박입니다. 마감이 다가오면 챔피언의 보안 시간이 가장 먼저 희생되므로, 질문은 리더십이 그 시간을 진정으로 확보했는지 바라기만 했는지입니다. 이름 붙은 챔피언 목록, 지난 분기에 보안 작업에 실제로 쓴 시간, 받는 교육과 공동체 지원, 운영한 위협 모델링 세션을 가져오십시오. 많은 팀과 오래 사는 시스템에 퍼진 대기업이나 정부 기관에서 이 능력은 감사 사이에 수명 주기를 살려 두는 것이므로, 재원 부족을 감독이 아니라 프로그램이 쇠퇴하도록 두는 결정으로 다루십시오.
오늘 오후 널리 쓰이는 의존성에 치명적 취약점이 닿는다면, 영향받는 모든 서비스를 얼마나 빨리 찾고 고쳤음을 입증할 수 있습니까? 공급망 노출은 상류의 결함 하나를 조직 전체의 인시던트로 바꾸는 실패 방식이며, 답은 전적으로 일찍 구축했거나 하지 않은 기반에 달려 있습니다. 릴리스별 소프트웨어 자재 명세서(SBOM), 통제된 내부 레지스트리를 통해 끌어온 고정되고 검증된 의존성, 강화된 빌드 시스템입니다. 긴장은 투자 대 속도입니다. SBOM을 생성하고 질의하는 것과 모든 의존성을 레지스트리로 라우팅하는 것은 팀이 구해 주는 날까지 싫어하는 마찰을 더하기 때문입니다. 현재 의존성 목록, 모든 서비스에 걸쳐 패키지와 버전으로 질의할 수 있는지, 빌드 시스템 권한의 상태, 마지막으로 빠른 패치를 리허설한 때를 가져오십시오. 법정 보고 의무와 계약상 시정 SLA를 지닌 기업과 정부 기관에서 “이 구성 요소를 담은 시스템이 무엇인가”에 몇 주가 아닌 몇 분 안에 답하는 능력은 통제된 공개와 뉴스로 알게 되는 침해의 차이입니다.
분야별 관점
스타트업. 보안 팀도 짧은 런웨이도 없다면 수명 주기를 인력이 아니라 도구에 구축하십시오. 모든 풀 리퀘스트에 SAST, 소프트웨어 구성 분석, 비밀 스캔을 돌리고, 관문이 신뢰받도록 심각도 높은 발견 사항에서만 빌드를 실패시키십시오. 한 엔지니어를 보안 챔피언으로 지명하고, 돈이나 개인 데이터에 닿는 것에 30분짜리 위협 모델링 세션을 운영하십시오. 무거운 문서화와 공식 프레임워크는 당분간 건너뛰되, 파이프라인 로그는 유지하십시오. 첫 기업 고객이 SOC 2를 물을 때 그것이 감사 증거가 되기 때문입니다.
소기업. 보안 전문가도 빠듯한 예산도 없으니 만들기보다 사는 안전한 기본값에 기대십시오. 의존성과 비밀 스캔을 대신 돌리는 호스팅 저장소, 관문이 켜진 관리형 파이프라인, 합리적 기본값을 가진 프레임워크입니다. 직접 쓰는 대신 빌린 짧은 보안 코딩 표준을 채택하고, 수명 주기를 발명하는 대신 확립된 프레임워크에서 가벼운 실천 하나를 고르십시오. 매일 돌볼 사람 없이도 보안이 유지되도록, 기본으로 실제 위험에서 빌드를 실패시키는 도구를 선호하십시오.
대기업. 많은 팀에 걸친 규모에서 문제는 일관성과 증거입니다. 하나의 프레임워크에 닻을 내리고, 파이프라인 관문을 표준화하고, 중앙 제품 보안 그룹에 연결된 훈련된 보안 챔피언을 각 전달 팀에 심으십시오. 시정 SLA를 중앙에서 추적하고 연령을 위험 위원회에 보고하며, 위협 모델과 스캔 결과를 감사 산출물로 저장하고, 릴리스별 SBOM을 내보내는 내부 레지스트리를 통해 의존성을 흘리십시오. 목표는 사업부 사이를 옮겨 다니는 엔지니어가 어디서나 같은 관문을 만나고, 모든 릴리스를 요구 사항에서 프로덕션까지 추적할 수 있는 것입니다.
정부. 조달 규칙, 투명성 의무, 공적 책임성이 모든 선택을 형성하며, 문서화된 수명 주기는 흔히 운영의 법적 전제 조건입니다. NIST SSDF와 운영 인가 요건에 대응하는 관련 통제 카탈로그(예컨대 NIST 800-53) 같은 인정된 프레임워크에 맞추고, 위협 모델링을 의무로 하고 독립적 보증 기능이 리뷰하게 하며, 서명되고 출처를 지닌 산출물과 함께 전체 스캔 관문을 시행하십시오. 시정 SLA를 계약에 쓰고 발견 사항과 수정의 불변 기록을 유지하십시오. 공무원이 이런 시스템을 수십 년 물려받으며, 감사 추적이 새 팀이 안전하게 운영하고 대중에게 답하게 해 주는 것이기 때문입니다.
사례
스타트업. 스무 명 규모의 핀테크 스타트업은 보안 팀에 인력을 댈 수 없으므로 수명 주기를 도구와 습관에 구축합니다. 모든 풀 리퀘스트가 SAST, SCA, 비밀 스캔을 돌리고, 관문이 신뢰받도록 심각도 높은 발견 사항에서만 빌드가 실패합니다. 한 엔지니어가 보안 챔피언을 자원해, 돈이나 개인 데이터에 닿는 모든 기능에 30분짜리 위협 모델링 세션을 운영하고 한 쪽짜리 보안 코딩 표준을 유지합니다. 완료의 정의에는 “처리되지 않은 치명적 발견 사항 없음”과 “비밀은 코드가 아닌 볼트에”가 포함됩니다. 나중에 첫 기업 고객과 SOC 2 감사를 추구할 때, 파이프라인 로그와 시정 추적기가 이미 필요한 증거입니다.
대기업. 수천 명의 엔지니어를 가진 한 글로벌 은행이 NIST SSDF에 프로그램의 닻을 내리고, OWASP SAMM으로 성숙도를 측정하고, BSIMM으로 동료와 벤치마크합니다. 모든 전달 팀에 중앙 제품 보안 그룹에 연결된 훈련된 보안 챔피언이 있습니다. 위협 모델링은 신뢰 경계를 가로지르는 모든 변경의 필수 관문이며 그 산출물은 감사 증거로 저장됩니다. 파이프라인은 빌드에 SAST, SCA, IaC 스캔, 비밀 스캔을, 스테이징에 DAST를 시행하고, 의존성은 릴리스별 SBOM을 만드는 내부 레지스트리를 통해서만 흐릅니다. 시정 SLA가 중앙에서 추적되어 위험 위원회에 보고되므로, 사업부 사이를 옮겨 다니는 엔지니어는 같은 관문을 만나고 감사자는 어느 릴리스든 요구 사항에서 프로덕션까지 추적할 수 있습니다.
정부. 한 국가 세무 당국은 법정 보안 의무 아래 운영되며 정의된 수명 주기를 통과하지 않은 소프트웨어를 출하할 수 없습니다. 운영 인가 요건에 대응하는 NIST SSDF와 NIST 800-53 통제에 맞춥니다. 모든 시민 대면 서비스에 보안 요구 사항과 악용 사례가 쓰이고, 위협 모델은 의무이며 독립적 보증 기능(10.2장)이 리뷰하고, 모든 파이프라인이 서명되고 출처를 지닌 산출물과 함께 전체 스캔 관문을 시행합니다. 시정 SLA는 계약상이며, 발견 사항과 수정의 불변 기록이 계속 운영을 인가하는 감사를 뒷받침합니다. 공무원이 이런 시스템을 수십 년 물려받으므로, 문서화된 수명 주기는 저자들이 떠난 한참 뒤에도 새 팀이 서비스를 안전하게 유지하게 해 줍니다.
비즈니스 사례: 동기, ROI, TCO
안전한 수명 주기의 수익은 그것이 막는 침해, 인시던트, 긴급 재작업의 비용에서 관문을 만드는 소소하고 대체로 일회성인 비용을 뺀 것입니다. 경제성은 모두 같은 쪽을 가리킵니다. 결함을 일찍 잡을수록 쌉니다. 위협 모델에서 잡은 설계 결함은 화이트보드 대화이고, 같은 결함이 프로덕션에서 잡히면 공개, 시정, 규제 노출, 평판 손상이 붙은 인시던트입니다. 자동화된 관문은 재사용 가능한 인프라이므로 비용은 한 번 치르고 모든 미래 변경에 걸쳐 상각되는 반면, 그것이 막는 인시던트는 각각 전체 프로그램보다 훨씬 많은 비용이 들었을 것입니다.
총소유비용은 도구 라이선스가 아니라 조정과 워크플로가 지배합니다. 거짓 양성으로 팀을 범람시키는 조정되지 않은 수명 주기는 엔지니어링 주의를 낭비하고, 무시되는 경보를 낳고, 비활성화된 관문으로 끝나며, 거짓된 확신을 제조하므로 프로그램이 없는 것보다 나쁩니다. 사람 쪽을 예산에 넣으십시오. 챔피언의 시간, 분류 워크플로, 지속적 조정입니다. 리더십을 설득하려면 수명 주기를 그들이 이미 추적하는 지표에 연결하십시오. 탈출 결함 비율, 평균 시정 시간, 감사 지적 사항, 후반 보안 놀람의 주기 시간 비용입니다. 규제되고 정부인 환경에서 문서화되고 시행되는 수명 주기는 흔히 운영 자체의 전제 조건으로, 보안을 비용 센터에서 사업을 할 면허로 바꿉니다.
안티패턴과 함정
- 끝에서의 보안 연극: 단일 릴리스 전 스캔이나 연간 침투 테스트가 수명 주기를 대신해, 결함이 가장 비쌀 때 발견되는 것.
- 워크플로 없는 도구 난립: SAST, DAST, SCA를 사지만 소유자, SLA, 분류가 없어 발견 사항이 모두가 무시하는 큐에 쌓이는 것.
- 조정되지 않은 관문의 경보 피로: 모든 것을 표시하는 시끄러운 도구가 엔지니어가 관문이 무의미해질 때까지 경고를 클릭해 넘기도록 훈련시키는 것.
- 문지기 병목: 모든 변경을 승인해야 하는 중앙 팀이 팀이 우회하거나 분노하는 대기열이 되는 것.
- 이름뿐인 챔피언: 교육, 시간, 인정 없이 역할만 배정되어 빈 직함으로 쇠퇴하는 것.
- 한 번 위협 모델링하고 다시는 안 함: 킥오프 때 쓰고 설계가 바뀌어도 다시 보지 않는 설계 단계 문서.
- 화물 숭배 프레임워크: SDL이나 SSDF 활동을 실제 위험에 맞추지 않고 결과를 바꾸는지 확인하지 않은 채 의례로 채택하는 것.
- 관리되지 않는 공급망: 공용 인터넷에서 직접 고정되지도 검증되지도 않은 의존성을 끌어오고, SBOM도 없고 과도한 권한의 빌드 시스템이 있는 것.
- 서류상의 SLA: 아무도 측정하지 않는 시정 기한으로, 치명적 항목이 소위 기한을 조용히 넘기는 것.
성숙도 모델
- 1단계, 시작: 보안이 늦은 추가물이고 대체로 반응적입니다. 테스트가 있다 해도 릴리스 가까이에 이루어지고, 위협 모델링이 없고, 스캔이 수동이거나 없으며, 발견 사항은 즉흥적으로 처리되고, 공급망이 관리되지 않습니다. 주어진 기능이 안전한지는 전적으로 누가 썼느냐에 달려 있습니다.
- 2단계, 발전: 기본 실천이 나타나지만 고르지 않게 닿습니다. 일부 파이프라인이 SAST나 SCA와 비밀 스캔을 돌리고, 코드 리뷰가 보안을 언급하고, 치명적 발견 사항이 고쳐지지만, 커버리지는 군데군데이고, 위협 모델링은 드물고, 시정에 추적되는 SLA가 없고, 각 팀이 자기 접근을 즉흥으로 만들어 그룹 사이에 기준이 크게 다릅니다.
- 3단계, 표준화: 확립된 프레임워크에 닻을 내린 문서화된 수명 주기가 조직 전체에서 시행됩니다. 보안 요구 사항과 악용 사례, 위협 모델링 관문, 보안 코딩 표준, 전체 파이프라인 관문, 완료의 정의 속 보안, 추적되는 시정 SLA, 보안 챔피언, 공급망 통제가 팀 전반에서 표준이어서, 엔지니어가 어디서 일하든 같은 기대를 만납니다.
- 4단계, 관리: 프로그램이 기준선에 대해 측정되고 통제됩니다. 선행 지표가 추적되고 보고됩니다. 중요한 변경의 위협 모델 커버리지, 예상 관문이 켜진 파이프라인의 비율, SLA에 대한 심각도별 평균 시정 시간, 탈출 결함 비율, 도구별 거짓 양성률입니다. 목표가 설정되고, 편차가 조치를 촉발하며, 진행 여부 결정은 의견이 아니라 증거에 근거해, 리더십이 수명 주기가 유지되는지 가정하지 않고 볼 수 있습니다.
- 5단계, 오케스트레이션: 프로그램이 조직 전체에서 지속적으로 개선되고 적응하며 통합됩니다. 탈출 결함이 관문을 조정하고, 시끄러운 도구가 쳐내지고, 되풀이되는 결함 부류가 새 안전한 기본값과 교육을 이끌고, 챔피언이 활발한 공동체를 이루고, 공급망 출처가 처음부터 끝까지 검증되며, 보안 계획이 전달 및 위험 관리에 엮여 위협 그림과 비즈니스가 이동함에 따라 수명 주기가 스스로 재균형됩니다.
논의를 위한 아이디어
- 수명 주기에서 오늘 가장 약한 단계는 어디이며, 거기에 구호가 아닌 진짜 관문을 추가하려면 무엇이 필요합니까?
- 오늘 오후 의존성의 치명적 취약점이 공개된다면, 영향받는 모든 서비스가 패치되기까지 얼마나 걸리며, 어떻게 압니까?
- 빌드를 막는 관문과 경고만 하는 관문의 선은 어디이며, 어떤 발견 사항이 어느 쪽에 속하는지 누가 결정합니까?
- 보안 챔피언에게 실제 시간과 인정이 주어집니까, 아니면 조용히 쇠퇴하는 직함입니까?
- 지난달 출하한 릴리스의 위협 모델과 스캔 결과를 감사자에게 내놓을 수 있습니까?
- 다음 스프린트에 추적하기 시작한다면 보안에 대한 팀의 실제 행동을 가장 크게 바꿀 단일 지표는 무엇입니까?
핵심 요점
- 보안 소프트웨어 개발 수명 주기는 모든 단계에서 보안을 만들고 검증하며, 고치기 가장 쌀 때로 결함을 왼쪽으로 옮깁니다. 애플리케이션 보안(4.2장)과 보안 운영(4.4장)을 잇는 프로세스 척추입니다.
- 모든 단계에 소유자와 관문을 두십시오. 보안 요구 사항과 악용 사례, 설계의 위협 모델링 관문, 보안 코딩 표준, 코드 리뷰의 보안, 완료의 정의 속 보안입니다.
- 각 자동화 도구를 맞는 곳에 두십시오. SAST, SCA, 비밀 스캔, IaC 스캔이 빌드를 관문 통제하고, DAST와 IAST가 실행 중인 시스템을 검증하며, 모든 관문을 중요한 것에서 실패하고 늑대를 외치지 않도록 조정하십시오.
- 팀에 심은 보안 챔피언으로 프로그램을 확장하고, 확립된 프레임워크(Microsoft SDL, OWASP SAMM, BSIMM, NIST SSDF)에 닻을 내리고, 명시적이고 측정되는 SLA에 따라 시정을 운영하십시오.
- SBOM, 검증된 의존성, 강화된 빌드 시스템으로 공급망을 처음부터 끝까지 방어하고, 프로그램이 의례로 쇠퇴하지 않고 계속 개선되도록 전체를 측정하십시오.
참고 문헌과 더 읽을거리
- Michael Howard and Steve Lipner, The Security Development Lifecycle
- Adam Shostack, Threat Modelling: Designing for Security
- Gary McGraw, Software Security: Building Security In
- National Institute of Standards and Technology, Secure Software Development Framework (SSDF), Special Publication 800-218
- OWASP Foundation, Software Assurance Maturity Model (SAMM)
- Synopsys, Building Security In Maturity Model (BSIMM)
- OWASP Foundation, OWASP Application Security Verification Standard (ASVS)
- Laura Bell, Michael Brunton-Spall, Rich Smith, and Jim Bird, Agile Application Security