Secure SDLC Review 가이드

무엇인가

이 검토는 귀사 개발 팀이 현재 계획, 설계, 코딩, 테스트, 릴리스, 지속적인 유지 관리 전반에서 보안에 어떻게 접근하는지 살펴봅니다. 범위는 작업 시작 전에 서면으로 확정됩니다. 선택한 서비스에 따라 위협 모델링이나 설계 검토 관행, 코드 리뷰 프로세스, 보안 테스트 도구 사용, 의존성 관리, 시크릿 처리, 릴리스 승인 워크플로, 운영 환경 접근 통제, 사고 대비 태세, 팀 내 보안 지식 공유 방식 등을 검토할 수 있습니다. 이 작업은 증거를 평가하고 실제 업무 관행을 관찰하도록 설계되었으며, 개별 개발자를 감사하거나 개발 일정을 방해하기 위한 것이 아닙니다. 귀사는 무엇이 잘 작동하는 것으로 보이는지, 어디에서 공백이나 불일치가 관찰되었는지, 적절한 다음 단계가 무엇일 수 있는지를 설명하는 체계적인 보고서를 받습니다. 관찰 사항은 기술 및 비기술 이해관계자가 우선 개선 사항, 합리적인 다음 투자, 전문가 의견이나 별도 계약이 필요할 수 있는 우려 사항을 구분할 수 있도록 정리됩니다.

누구를 위한 것인가?

Secure SDLC Review는 다음과 같은 기업에 적합합니다.

• 사내 또는 외주 개발 팀을 두고 있으면서 아직 소프트웨어 개발·배포 과정에서 보안이 어떻게 고려되는지 공식 검토를 받은 적이 없는 기업
• 최근 개발 팀을 확장했거나, 개발·배포 관행을 바꾸었거나, 새 플랫폼으로 이전했거나, 새 도구를 도입하여 보안 관행이 이를 따라가고 있는지 확인하려는 기업
• 엔터프라이즈 영업, 규정 준수 절차 또는 안전한 개발 규율의 증거를 기대하는 대형 고객과의 계약을 준비하는 기업
• 감사인, 투자자, 고객 또는 이사회의 안전한 개발 관행에 관한 질문에 현재 상태를 과장하지 않고 신중하게 답해야 하는 기업

무엇을 명확히 하는 데 도움이 되는지

Secure SDLC 검토는 다음 사항을 명확히 하는 데 도움이 됩니다.

• 설계, 코딩, 테스트, 릴리스 단계에서 어떤 보안 관행이 갖추어진 것으로 보이며, 어디에서 증거가 불완전하거나 프로세스에 더 명확한 담당자가 필요한지
• 개인의 지식, 비공식적 소통 또는 문서화되지 않은 습관에 의존하여 보안 결정이 일관되지 않거나 새 팀원에게 보이지 않을 수 있는 부분
• 어떤 도구, 점검 지점 또는 승인 단계가 효과적으로 사용되고 있으며, 어떤 것이 소음, 지연 또는 잘못된 안심을 만들고 있는지
• 현재 팀 안에서 무엇을 처리하고, 무엇에 교육이나 더 명확한 지침이 필요하며, 무엇을 별도 범위의 기술적·조직적 변경으로 논의해야 하는지

포함된 내용

• 검토할 팀 구조, 개발·배포 관행, 증거 출처를 포함하여 작업 시작 전 범위의 서면 확정
• 문서 검토, 팀 인터뷰, 그리고 적절한 경우 실제 작업 산출물 관찰을 통한 합의된 개발 관행의 검토
• 이론적 심각도만이 아니라 관련성과 실행 가능성에 따라 우선순위를 매긴 실질적 관찰 사항을 담은 체계적인 발견 사항 보고서
• 기술 및 비기술 의사결정자 모두를 위한 맥락을 갖춘 각 관찰 사항의 알기 쉬운 설명
• 계획, 채용, 교육 또는 도구 관련 결정에 참고하도록 사내에 공유할 수 있는 경영진 요약
• 발견 사항, 우선순위, 현실적인 다음 단계를 논의하는 1회의 후속 대화

포함되지 않은 것

• 별도로 범위를 정하지 않는 한 전체 애플리케이션 침투 테스트, 인프라 검토 또는 능동적 취약점 악용
• 규정 준수 인증, 감사 의견 또는 기업이 적용 가능한 모든 개발 표준을 충족한다는 진술
• 검토 기간 중의 프로세스 재설계, 도구 구현 또는 팀 교육
• 합의된 계약 종료 후의 지속적인 모니터링, 상시 평가 또는 재테스트
• 서면 범위에 포함되지 않은 팀, 저장소, 시스템 또는 배포 파이프라인에 대한 검토

선택해야 할 때

특정 도구 투자, 교육 프로그램 또는 프로세스 변경에 착수하기 전에 귀사 개발 팀이 오늘날 보안에 어떻게 접근하는지 명확하고 증거에 기반한 시각을 원할 때 Secure SDLC Review를 선택하십시오. 팀이 성장했거나, 개발·배포 관행이 바뀌었거나, 이해관계자가 안전한 개발에 관해 아직 자신 있게 답할 수 없는 합리적인 질문을 했을 때 유용한 단계입니다. 감사, 고객 보안 검토 또는 개발 역량이 논의될 사내 계획 주기 전에도 도움이 될 수 있습니다. 정확한 기술적 문제나 프로세스 문제를 이미 알고 있고 집중적인 구현이 필요한 경우에는 범위를 정한 개선 프로젝트가 대개 더 적합합니다. 이 검토의 가치는 다음 투자를 더 신중하게 만들고 실제 제약을 해결할 가능성을 높여 준다는 데 있습니다.

우리의 접근 방식

당사는 검토 범위와 증거 접근 방식을 서면으로 확정하는 것부터 시작합니다. 귀사는 어떤 팀, 저장소, 관행, 산출물을 검토하는지, 어떤 접근 권한이나 논의가 필요한지, 인계 시 무엇을 받게 되는지를 설명하는 알기 쉬운 개요서를 받습니다. 담당 전문가는 제공된 정보와 접근 권한으로 작업하며, 제공된 증거로 남는 질문이 있으면 후속 조치할 수 있도록 보고서에 명확히 기록합니다. 관찰 사항은 실질적인 평가로 작성됩니다. 즉, 관찰된 관행, 그것이 중요해질 수 있는 맥락, 그리고 그에 비례하는 권고 사항이나 다음 질문을 담습니다. 보고서는 어떤 개선에 언제 자원을 투입할지에 대해 기술 리더십, 제품 담당자, 경영진 이해관계자 간의 건설적인 대화를 돕기 위한 것입니다. 인계 시에는 귀사와 함께 우선순위를 검토하여, 문서가 우선순위를 정하거나 실행하기 어려운 목록이 아니라 현실적인 계획의 근거가 되도록 합니다.

자주 묻는 질문

관련 기사