안전한 소프트웨어 개발 라이프사이클이란 무엇인가요?

소프트웨어 개발은 전통적으로 계획, 코딩, 테스트, 배포라는 선형적인 경로를 따릅니다. 수십 년 동안 보안은 수천 줄의 코드가 이미 작성된 테스트 단계에서만 고려 대상이 되었습니다.

SSDLC는 소프트웨어 개발 라이프사이클(SDLC)의 첫날부터 모든 단계에 보안을 임베딩함으로써, 이러한 전통적인 접근 방식에 도전합니다. SSDLC는 흔히 요구 사항 정의, 분석, 기획, 설계, 개발, 문서화, 테스트, 배포, 유지보수의 9단계로 구성됩니다.

팀은 먼저 기능적 요구 사항과 함께 보안 문제를 논의하고, 개발자는 검증된 입력 및 인증 표준을 사용하여 보안 코드를 작성합니다. 테스트는 릴리스 직전이 아니라 종종 자동화된 코드 후기를 통해 지속적으로 실행됩니다.

보안을 개발 프로세스 초기에 배치하는 이러한 "시프트 레프트" 접근 방식은 조직이 소프트웨어를 구축하는 방식을 혁신하는 데 도움이 될 수 있습니다. 테스트 중에 “이게 안전한가요?”라고 묻는 대신에 팀은 코드 첫 줄을 작성하기 전에 "어떻게 이걸 안전하게 만들 수 있을까요?"라고 묻습니다.

예를 들어, 은행 애플리케이션의 경우를 생각해 보세요. 기존 개발에서는 사전 출시 테스트 중에 SQL 인젝션 취약점을 발견하면 개발자가 수백 개의 파일에 걸쳐 데이터베이스 상호 작용을 다시 작성해야 할 수 있습니다. SSDLC를 사용하다면 설계, 빌드 및 테스트 전반에 걸쳐 보안 검사가 실행되기 때문에 팀이 해당 취약점을 조기에 감지할 가능성이 훨씬 더 높습니다.

최근 데이터는 이러한 사전 예방적 접근 방식이 중요한 이유를 잘 보여 줍니다. 최근의 소프트웨어 공급망 보안 연구에 따르면, 소프트웨어 공급망 공격은 불과 3년 만에 1300% 급증했습니다.¹

SSDLC는 조직을 보호하기 위해 이러한 사이버 공격 과 다른 공격에 대해 조직을 보호할 수 있습니다. 취약점을 조기에 발견할 수록 수정은 간단하고 비용은 줄어듭니다. 또한 일반 데이터 보호 규정(GDPR) 및 건강 보험 양도 및 책임에 관한 법률(HIPAA)과 같은 규정을 준수하는 데 도움이 될 수 있습니다.

일반적으로 SDLC 모델을 거의 따르는 9개의 SSDLC 단계가 있습니다. 단, 모든 단계에는 보안 고려 사항도 포함됩니다.

• 요구사항
• 분석
• 계획 수립
• 설계
• 개발
• 문서
• 테스트
• 배포
• 유지보수

팀은 완성될 소프트웨어의 기능을 논의하면서, 첫날부터 기능적 요구 사항과 더불어 보안 요구 사항을 정의합니다. 예를 들어, 민감한 데이터 필드에 대한 암호화를 구현하거나 역할 기반 액세스 제어(RBAC)를 설정하는 것 등이 이에 해당합니다. 이 논의에서는 잠재적인 보안 위험을 검토하고, GDPR의 데이터 보호 표준과 같은 규제 준수 요구 사항을 면밀히 살펴봅니다.

조직은 발생 가능한 취약점들을 수치화하고 위협 지형을 파악함으로써, 낙관적인 가정 대신 최악의 시나리오를 가정해 대비합니다. 예를 들어, 의료 앱은 환자 데이터 유출, 랜섬웨어 공격, 내부자 위협의 위험을 분석하여 각 상황에 대응 계획을 세울 수 있습니다.

보안 팀과 이해관계자는 역할을 설정하고, 리소스를 할당하고, 잠재적인 비즈니스 영향에 따라 허용 가능한 기준선을 정의합니다. 이러한 계획을 통해 개발 기한을 준수하면서 고위험 취약점의 우선순위를 지정할 수 있습니다. 또한 코딩을 시작하기 전에 보안 도구와 교육에 대한 예산을 책정할 수 있습니다.

설계 단계에는 계획된 아키텍처의 잠재적인 보안 취약점을 체계적으로 분석하는 위협 모델링이포함됩니다. 이러한 관행은 보안 설계가 비용이 많이 드는 사후 수정 작업으로 추가되는 것이 아니라, 최고의 플랫폼 선정부터 최적의 UI 구성에 이르기까지 시스템 청사진에 내장되도록 합니다.

개발자는 오픈 웹 애플리케이션 보안 프로젝트(OWASP)와 같은 단체에서 제정한 보안 코딩 표준을 바탕으로, 안전한 코딩 관행을 실무에 적용합니다. 이러한 표준에는 모든 입력값 검증, 인증 기술 구현, 올바른 API 호출 사용, 저장소 스캔, 그리고 보안을 고려한 예외 처리 등이 포함됩니다.

개발자는 종종 보안 플러그인이 포함된 통합 개발 환경(IDE)을 사용하여 문제를 조기에 발견하는 데 도움을 받습니다.

팀은 보안 위험을 완화하기 위해 소프트웨어 종속성을 평가하며, 보안 테스트는 개발 단계부터 시작됩니다. 예를 들어, 결제 처리 모듈은 통합 후가 아니라 개발 단계에서 보안 테스트를 거칩니다. 

팀은 감사, 규정 준수 점검, 보안 검토를 위해 보안 통제 항목과 프로세스를 문서화합니다. 이를 통해 신속한 인시던트 대응이 가능해지며, 지속적으로 규제 표준을 준수할 수 있습니다.

테스트에서는 코드 리뷰와 보안 테스트를 결합하여 수행합니다. 팀은 배포 전에 기능과 보안을 모두 검증합니다.

테스트 과정에는 프로그램을 실행하지 않고 소스 코드를 분석하는 정적 애플리케이션 보안 테스트(SAST)와 프로그램이 실행 중인 상태에서 애플리케이션을 테스트하는 동적 애플리케이션 보안 테스트(DAST)가 모두 포함됩니다.

고도화된 테스트 단계에서는 윤리적 해커가 코드를 직접 공략해보거나, 모의 침투 테스트를 통해 데이터 보안을 검증하고, API를 대상으로 한 시뮬레이션 공격 등을 수행하기도 합니다. 또한, 소프트웨어 구성 분석(SCA)을 병행하여 취약한 오픈소스 의존성이나 라이선스 문제를 식별할 수 있습니다.

팀은 소프트웨어를 출시하기 전에 서버, 구성,미들웨어 등 배포 환경을 보호합니다. 이렇게 하면 잘못 구성된 인프라로 인해 취약점이 유입되는 것을 방지할 수 있습니다.

많은 팀이 지표, 로그, 추적과 같은 소프트웨어 텔레메트리를 수집하여, 실제 환경에서 코드가 어떻게 작동하는지 면밀히 관찰합니다. OpenTelemetry(OTel)는 클라우드 네이티브 컴퓨팅 재단(CNCF)의 오픈소스 프로젝트로, 특정 공급업체에 종속되지 않는 방식으로 지표, 로그, 추적을 수집하고 전송할 수 있게 해 줍니다. 이를 통해 다양한 서비스와 파이프라인, 그리고 운영 환경 전반에서 일관된 모니터링 신호를 확보할 수 있습니다.

지속적인 모니터링을 통해 위협과 취약성을 조기에 탐지하여 소프트웨어 라이프사이클 전반에 걸쳐 신속하게 문제를 해결할 수 있습니다. 이 단계는 제로데이 익스플로잇을 방지하고 새로 발견된 취약점에 대응하는 데 특히 중요할 수 있습니다.

조직은 일반적으로 보안 벤치마크, 보안 모범 사례, 위험 평가 툴을 포함하는 종합 방법론과 같은 확립된 프레임워크를 통해 안전한 소프트웨어 개발 라이프사이클을 시작합니다. 가장 일반적인 프레임워크는 다음과 같습니다.

미국 국립표준기술연구소(NIST)는 보안 소프트웨어 개발 프레임워크인 NIST SP 800-218을 포함하여 보안 개발을 위한 벤치마크 및 정부 지원 사례를 제공합니다.

이 프레임워크는 조직이 모든 개발 팀에서 기본 보안 요구 사항을 설정하도록 돕습니다. 다른 프레임워크에 비해 더 구체적이고 지시적인 연방 정부 수준의 표준을 제공하므로 정부 계약자 및 규제 대상 산업에 이상적입니다. 연방 기관과 협력하는 조직들은 계약상의 필수 요건으로서 NIST 표준을 준수해야 하는 경우가 많습니다.

오픈 웹 애플리케이션 보안 프로젝트(OWASP)는 오픈 프레임워크인 소프트웨어 보증 성숙도 모델(SAMM)을 제공합니다.

OWASP SAMM은 조직이 현재의 소프트웨어 보안 관행을 평가하고, 각자의 고유한 위험 프로필에 맞춘 단계적 개선 프로그램을 구축할 수 있도록 돕습니다. 

이러한 이유로, 경직된 규정 준수 요건보다는, 유연하고 성숙도에 기반한 접근 방식을 추구하는 조직들이 이 프레임워크를 선호하는 경우가 많습니다. 예를 들어, 스타트업은 인증과 같은 핵심 영역에 기본적인 보안 관행을 적용하는 것으로 시작하여, 팀의 규모와 예산이 커짐에 따라 점진적으로 포괄적인 보안 테스트로 범위를 확장해 나갈 수 있습니다.

OWASP DevSecOps 가이드라인은 통합 보안 테스트 도구인 SAST, DAST, SCA(소프트웨어 구성 분석), IAST(인터랙티브 애플리케이션 보안 테스트)를 통한 파이프라인 구현을 상세히 설명합니다. 이 지침을 따르면 개발 워크플로를 중단하지 않고도 기존의 지속적 통합 및 지속적 제공(CI/CD) 파이프라인에 보안 테스트를 더 쉽게 포함할 수 있습니다.

결과적으로, 릴리스 주기를 늦추지 않으면서 보안을 자동화하려는 조직들은 OWASP DevSecOps 가이드라인을 선호할 수 있습니다. 매일 업데이트를 배포하면서도 PCI DSS 규정 준수를 유지해야 하는 핀테크 기업이 대표적인 예입니다.

많은 조직이 DevOps 및 DevSecOps 관행을 통해 SSDLC를 구현합니다. 이는 보안 테스트를 자동화하고 이를 CI/CD 파이프라인에 통합함으로써, 보안 표준을 유지하는 동시에 개발 속도를 높입니다. DevSecOps 기법을 활용해 개발 팀은 보안 설계, 구축, 운영 및 유지관리뿐만 아니라 애플리케이션 보안을 책임집니다. 빠른 반복(Iteration)을 수행하고 병목 현상을 방지하기 위해, 팀은 보안 테스트에 자동화 기술을 사용하는 경우가 많습니다.

SLSA(‘살사’라고 발음)는 소프트웨어 공급망을 보호하기 위한 커뮤니티 프레임워크로, 원래 구글이 제안했으며, 현재는 OpenSSF 관리하에 운영되고 있습니다. 

이 지침은 조직이 변조를 방지하고, 아티팩트 무결성을 검증하고, 빌드 프로세스 및 종속성의 검증을 자동화하는 데 도움이 됩니다. 조직이 공급망 보안을 최적화하고 출처를 구축하려는 경우 SLSA를 구현하여 소프트웨어가 구축 프로세스 중에 변조되지 않았음을 증명할 수 있습니다. 예를 들어, 애플리케이션을 배포하는 소프트웨어 공급업체는 릴리스가 정품이고 변조가 되지 않았음을 고객에게 증명해야 합니다.

SSDLC를 통해 조직은 여러 가지 핵심 이점을 얻을 수 있습니다. 

SSDLC의 '시프트 레프 (shift left)' 접근 방식을 사용하면 조직이 취약점을 가장 쉽게 해결할 수 있고 가장 비용이 적게 드는 경우, 즉 배포 후가 아닌 설계 및 개발 중에 취약점을 탐지하고 수정할 수 있습니다.

예를 들어, 설계 단계에서 검토를 수행하면, 기획된 아키텍처가 보안 설정이 되지 않은 API 엔드포인트를 통해 민감한 고객 데이터를 노출할 수 있다는 사실을 발견할 수 있습니다. 이러한 문제를 조기에 발견하면 처음부터 더 안전한 아키텍처를 구축할 수 있으며, 데이터 유출로 인한 잠재적 피해와 보안 통제를 사후에 수정하는 데 드는 막대한 비용을 방지할 수 있습니다.

조직은 또한 유출이 발생했을 때 비용을 절감할 수 있습니다. 데이터 유출 비용(CODB) 보고서에 따르면 SSDLC를 포함한 DevSecOps 접근 방식은 데이터 유출 사고 시 피해 비용을 줄이는 데 기여한 가장 큰 요인이었습니다. 이러한 접근 방식을 사용하는 조직은 데이터 유출 사고당 미화 22,7192달러의 비용 절감 효과를 거두었습니다.

SSDLC는 배포 전에 보안 문제를 식별하여 잠재적으로 긴급 수정을 방지하고 소프트웨어 안정성을 개선하여 시스템 가동 중단을 방지하는 데 도움이 될 수 있습니다. 모든 단계에서 위협 모델링과 상세한 코드 검토를 통해 이러한 안정성을 강화할 수도 있습니다.

SSDLC는 개발부터 CI/CD 파이프라인을 거쳐 배포까지 코드를 다루는 모든 인프라와 인력을 포함하는 소프트웨어 공급망을 보호하는 데 도움이 됩니다. 위협 모델링 및 종속성 스캔과 같은 위험 관리 관행과 액세스 제한 및 서명 같은 사이버 보안 제어를 결합하여 전체 수명 주기에서 취약성을 방지합니다.

예를 들어, SSDLC는 조직이 모든 구성 요소와 종속성을 추적할 수 있도록 소프트웨어 자재 명세서(SBOM)를 도입하는 데 도움을 줄 수 있습니다. 이러한 접근 방식을 통해, 서드파티 라이브러리에서 취약점이 발견되었을 때 이를 식별하고 해결하는 것이 훨씬 수월해집니다.

SSDLC는 각 개발 단계마다 보안 통제 항목과 문서화를 구축하여, 조직이 규정 준수를 효과적으로 유지할 수 있도록 돕습니다. 이러한 프로세스는 유럽 일반 개인정보보호법(GDPR), 건강 보험 양도 및 책임에 관한 법률(HIPAA), 캘리포니아 소비자 개인정보보호법(CCPA)과 같이 산업별로 특화된 보안 표준을 지속적으로 준수해야 하는 조직에 필수적입니다. 더욱 신뢰할 수 있는 규정 준수 체계를 갖추면, 법적 분쟁을 줄이고 잠재적인 과징금 발생 가능성을 차단하는 데 도움이 됩니다. 

SSDLC를 구현할 때 개발, 운영 및 보안 팀은 소프트웨어 개발의 다양한 관점을 표면화하기 위해 자주 긴밀하게 협력해야 합니다. 이러한 필수 협업은 부서 간의 사일로를 허물고 나중에 비용이 많이 들 수 있는 보안 문제를 방지하는 데 도움이 될 수 있습니다.

많은 이점에도 불구하고 조직에서 SSDLC를 채택할 때 몇 가지 도전 과제가 발생할 수 있습니다. 

더 빠른 시장 출시를 원하는 이해관계자는 보안 요구 사항이 개발 속도의 장애물이라고 생각하는 경우가 많습니다. 심지어 보안 테스트를 이후 단계로 연기하도록 요청할 수도 있습니다. 

이 접근 방식은 초기 개발을 가속화할 수 있지만 배포 후 취약점이 드러나면 비용이 많이 드는 지연이 발생하는 경우가 많습니다.

예를 들어, 설계 단계에서 위협 모델링을 건너뛰면 치명적인 공격 경로가 노출될 수 있습니다. 체계적인 위협 분석이 없으면, 인증 시스템, 데이터 접근 제어 또는 서드파티 서비스 통합 과정에서의 보안 허점을 놓칠 수 있습니다. 이러한 취약점은 실제 운영 환경에서 수정하려면 비용이 기하급수적으로 증가하게 됩니다.

위협 환경이 계속 진화함에 따라 개발팀은 최신 보안 지식을 유지해야 합니다. 전문 보안 전문 지식이 없는 조직은 SSDLC를 효과적으로 구현하기 위해 추가 교육, 전문 고용 또는 외부 컨설턴트가 필요할 수 있습니다.

예를 들어, 보안 코딩을 처음 접하는 개발자는 정적 분석 도구를 언제 사용해야 하는지 또는 결과를 해석하는 방법을 모를 수 있습니다. 적절한 교육이 없으면 이러한 도구는 해결되지 않은 심각한 취약점을 표시하거나 개발 시간을 낭비하는 오탐을 생성할 수 있습니다. 숙련된 개발자라도 새로운 위협과 보안 관행을 최신 상태로 유지하기 위해 지속적인 교육이 필요한 경우가 많습니다.

다중 통합이 포함된 복잡한 소프트웨어 아키텍처에는 때때로 정교한 보안 도구와 프로세스가 필요할 수 있으며, 이로 인해 개발 시간과 비용이 증가할 수 있습니다. 예를 들어, 서로 다른 데이터 형식과 통신 프로토콜을 사용하는 IoT 장치를 통합하면 팀이 보호해야 할 다른 공격 표면이 생성될 수 있습니다.

다양한 사용 사례를 지원하면서 최소한의 액세스 권한으로 작동해야 하는 암호화 API 구현을 고려해 보세요. 일부 서비스에는 암호 해독 권한이 없는 암호화 기능이 필요할 수 있습니다. 이 프로세스는 접근 제어, 인증 및 전송 계층 보안(TLS)에 대한 세심한 계획을 필요로 하므로, 팀은 보안이나 기능을 손상시키지 않고 해결해야 하는 각 통합 지점에 복잡성을 더합니다.