소프트웨어 개발 라이프사이클 보안

소프트웨어 개발 라이프사이클(SDLC)은 소프트웨어 개발, 배포, 유지 관리에 사용되는 프레임워크입니다. 이 프레임워크는 프로세스에 집중하여 소프트웨어 품질을 향상하겠다는 목표로 태스크 또는 활동을 6-8단계로 형식화합니다. 단계를 형식화하는 것은 진행률과 비용을 모니터링하면서 기능 개선에 활용할 수 있는 측정 및 분석을 지원하기 위해서입니다. 

SDLC의 단계:

• 계획: 소프트웨어의 범위 및 목적 결정
• 요구 사항: 소프트웨어가 수행해야 하는 기능 정의
• 설계: 아키텍처, 플랫폼, 사용자 인터페이스와 같은 주요 매개 변수 결정
• 빌드: 소프트웨어 개발 및 구현
• 문서: 사용자와 이해관계자가 소프트웨어를 사용하고 운영하는 방법을 이해하는 데 도움이 되는 정보 산출
• 테스트: 소프트웨어의 요구 사항 충족 여부 검증
• 배포: 대상 사용자에게 소프트웨어 제공
• 유지 관리: 소프트웨어에서 발견된 버그 또는 취약점 해결

얼핏 보면 SDLC와 애플리케이션 라이프사이클 관리(ALM)는 둘 다 소프트웨어 개발 및 관리 프로세스를 처리하므로 매우 비슷해 보입니다. SDLC는 개발 단계에 주로 초점을 맞춘 ALM의 하위 집합으로 볼 수 있습니다. ALM은 일반적으로 소프트웨어 포트폴리오 관리를 폭넓은 관점에서 파악하기 위해 사용되는 반면, SDLC의 도메인은 단일 애플리케이션입니다.  

일반적인 오해 중 하나는 SDLC가 특정 소프트웨어 개발 방법론과 연결되어 있다는 것입니다. 순차적으로 실행되는 SDLC의 전체 8단계는 워터폴(waterfall) 소프트웨어 개발 프로세스를 설명하는 것으로 보이지만, 워터폴(waterfall), 애자일, DevOps, 린(lean), 반복, 나선형 개발은 모두 SDLC 방법론임을 이해하는 것이 중요합니다. 여러 SDLC 방법론은 단계의 이름, 포함된 단계 또는 단계가 실행되는 순서가 각기 다를 수 있습니다. 계획 및 요구 사항 분석과 같은 활동은 한 단계로 묶을 수 있습니다. 이러한 차이에 관계없이, SDLC는 필요한 소프트웨어 개발 활동을 이해하고 분석하는 데 사용할 수 있는 프레임워크를 제공합니다.

애자일과 DevOps와 같은 SDLC 방법론은 워터폴(waterfall)의 선형적 접근 방식 대신에 소프트웨어 개발의 반복적 특성을 강조합니다.

소프트웨어 개발의 일반적인 문제는 보안 관련 활동이 테스트 단계까지, 즉 중요한 설계와 구현이 대부분 완료된 후인 SDLC 후반부로 미뤄진다는 것입니다. 테스트 단계에서 수행되는 보안 점검은 스캔과 침투 테스트로 제한되어 피상적일 수 있으므로, 더 복잡한 보안 문제를 파악하지 못할 수 있습니다. 이처럼 SDLC 프로세스의 후기 단계에 발견되는 문제로 인해 프로덕션 단계로의 진행이 지연되는 경우가 많습니다. 이러한 문제들은 재개발 및 재테스트가 필요할 수 있으므로 해결하는 데 시간이 더 많이 걸리고 비용도 많이 듭니다.

효과적인 보안 프로세스를 구현하려면 팀이 “개발 초기 단계로 이동(shift-left)”해야 합니다. 프로젝트 생성 시점부터 프로젝트 전 과정에 걸쳐 실행되는 SDLC의 각 단계에서 보안을 고려하는 것도 이에 해당합니다. 보안 소프트웨어 개발 라이프사이클(SSDLC)을 도입하기 위해 SDLC의 각 단계에서 추가할 보안 단계가 있습니다. 여기에는 다음이 포함됩니다.

갈수록 증가하는 보안 위협 환경에 대비하기 위해 조직은 지속적으로 업데이트되는 일련의 보안 사례 및 프로세스가 필요합니다. SSDLC의 일부인 보안 게이트 및 제어를 개발 및 배포 프로세스 전반에 걸쳐 초기에 구현해야 합니다. 신속한 반복을 위해 조직은 DevOps 프로세스와 자동화된 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 활용했습니다. 장애를 피하려면 지속적이고 자동화된 프로세스로 보안을 구현해야 합니다. 개발 팀은 설계, 빌드, 운영, 유지 관리 외에도 애플리케이션 보안을 담당해야 합니다. 

DevSecOps는 소프트웨어 개발의 속도 및 효율성을 향상하는 동시에 보안을 강화하고, 일관성, 반복 가능성, 협업을 개선하기 위한 기술과 인력, 프로세스를 포함하는 일련의 사례입니다. DevSecOps의 핵심은 개발, 운영 및 보안 전반에서 공유하는 소유권을 생성하는 것입니다. DevSecOps의 목표는 다음과 같습니다.

• 안전성을 높이고 위험을 최소화: 잠재적인 프로덕션 문제를 줄일 수 있도록 애플리케이션 개발 및 인프라 라이프사이클 초기 단계에 더 많은 보안 취약점을 제거
• DevOps 릴리스 사이클의 효율성 및 속도 향상: 레거시 보안 사례 및 툴 제거. 자동화 사용, 툴체인 표준화, 코드형 인프라와 코드형 보안 및 코드형 컴플라이언스 구현으로 반복 가능성과 일관성을 높여 개발 프로세스 개선
• 리스크 감소 및 가시성 확대: 애플리케이션 개발 및 인프라 라이프사이클 초기에 보안 게이트를 구현하여 인적 오류 가능성은 줄이고 보안과 컴플라이언스, 예측 가능성, 반복 가능성은 높이는 동시에 감사 우려 완화

DevSecOps 성숙도 모델의 네 단계를 진행하면 보안이 CI/CD 파이프라인 전반에 걸쳐 통합되고 비즈니스 및/또는 전 세계적인 상황 변화에 따라 조정되도록 보장할 수 있습니다. Open Web Application Security Project®(OWASP)는 소프트웨어 보안 및 IT 보안 인식 제고를 위해 커뮤니티 주도의 오픈소스 소프트웨어 프로젝트를 지원하는 비영리 재단입니다. OWASP는 보안 개발 라이프사이클을 개선하는 데 사용할 수 있는 프로젝트, 툴, 문서를 무료로 제공합니다.

소프트웨어 공급망 보안은 위험 관리와 사이버 보안 분야의 모범 사례를 결합하여 잠재적 취약점으로부터 소프트웨어 공급망을 보호하도록 지원합니다. 소프트웨어 공급망은 애플리케이션 개발에서 CI/CD 파이프라인 및 배포에 이르는 SDLC에서 코드를 수정하는 모든 요소와 사용자로 구성됩니다. 

소프트웨어 공급망 보안은 조직, 고객, 오픈소스 기여를 활용하는 모든 조직에 중요합니다. 보안 침해를 원하는 조직은 없지만, 다른 조직에서 유사 사건이 발생하는 것에 대해서도 책임지고 싶어하지 않는 것은 마찬가지입니다. 소프트웨어 공급망을 위한 보호 기능은 반드시 구현해야 합니다. 

보안 팀이 고려해야 할 몇 가지 공급 보안 모범 사례는 다음과 같습니다.

• 공급망 전체에 걸쳐 리소스(예: 개발자 툴, 소스 코드 리포지토리, 기타 소프트웨어 시스템)에 대한 최소 권한 액세스 제공, 다단계 인증 지원, 강력한 암호 사용
• 연결된 모든 기기와 민감한 데이터에 대한 보안 강화
• 티어 1 공급업체를 시작으로 공급업체 및 비즈니스 상대 확인. 위험 평가를 실시하여 취약점에 대한 각 공급업체의 사이버 보안 상태 및 공공 정책 평가.

Red Hat은 조직이 온프레미스, 클라우드 또는 엣지 사이트에서 보안을 강화하기 위해 인프라와 애플리케이션 스택 및 라이프사이클 전반에 걸쳐 계층화된 보안 접근 방식을 구현할 수 있도록 지원하는 신뢰할 수 있는 오픈소스 소프트웨어를 제공합니다. Red Hat 기술은 소프트웨어 공급망 보안에 초점을 맞춘 프로세스를 통해 개발됩니다. 이러한 보안 중심의 기반을 바탕으로 조직은 하이브리드 환경을 구축, 관리 및 제어하고, 자동화 전략을 구현하여, DevSecOps 사례로 SDLC에서 보안 기능을 개발하는 데 집중할 수 있습니다.

Red Hat과 보안 파트너 에코시스템은 통합적인 DevSecOps 접근 방식을 통해 조직이 보안에 영향을 주지 않고 지속적으로 혁신할 수 있도록 지원합니다. Red Hat은 오픈 하이브리드 클라우드 전반에 걸쳐 보안 중심 애플리케이션을 구축, 배포, 실행할 수 있는 강력한 포트폴리오를 제공할 수 있는 전문성과 역량을 갖추고 있어, 조직의 DevSecOps 단계에 관계없이 지원할 수 있습니다.