단계 1: 교육 개발 팀의 모든 구성원은 개발자, 테스터, 프로젝트 관리자, 제품 관리자 등 관련 보안 지식을 습득하는 적절한 보안 교육을 받아야 합니다. 2 단계: 보안 요구 사항 프로젝트를 시작하기 전에 프로젝트 관리자 또는 제품 담당자와 미리 통신하여 보안 요구 사항 및 필요한 작업을 결정해야 합니다. 프로젝트 계획과 이정표를 확인하고 안전 문제로 인해 프로젝트 발표가 지연되는 것을 최소화합니다. 단계 3: 품질 관리/결함 바 품질 관리 및 결함 바는 안전 및 개인 정보 보호 품질의 최소 허용 수준을 결정하는 데 사용됩니다. 버그 바는 전체 개발 프로젝트에 적용되는 품질 문으로서 보안 취약점에 대한 심각도 임계값을 정의합니다. 예를 들어, 응용 프로그램은 [심각] 또는 [중요] 등급의 알려진 취약점을 포함할 수 없습니다. 일단 버그 바를 설정하면 긴장을 풀지 말아야 한다. 4 단계: 보안 및 개인 정보 위험 평가 SRA (보안 위험 평가) 및 PRA (개인 정보 위험 평가) 는 필수 프로세스이며 1, (보안) 프로젝트의 어떤 부분이 출시되기 전에 위협 모델이 필요합니까? 2. (보안) 출시 전에 보안 설계 평가가 필요한 프로젝트 부분은 무엇입니까? 3. (보안) 프로젝트 중 어느 부분이 양측이 승인한 프로젝트 팀을 좋아하지 않는 팀에서 침투 테스트를 해야 합니까? 4. (보안) 안전 위험을 완화하는 데 필요한 테스트 또는 분석 요구 사항이 있습니까? 5. (안전) 퍼지 테스트 요구 사항의 구체적인 범위는 무엇입니까? 6. (보안) 개인 정보 영향 등급이란 무엇입니까? 5 단계: 설계 요구 사항: 설계 단계에서는 보안 및 개인 정보 보호 문제를 신중하게 고려해야 하며, 프로젝트의 초기 단계에서 보안 요구 사항을 파악하여 보안으로 인한 수요 변화를 최소화해야 합니다. 6 단계: 공격면 감소는 위협 모델링과 밀접한 관련이 있지만 약간 다른 각도에서 보안 문제를 해결합니다. 공격면을 줄이면 공격자가 잠재적인 약점이나 취약점을 활용할 가능성이 줄어 위험이 줄어듭니다. 공격면 감소에는 시스템 서비스에 대한 액세스 종료 또는 제한, "최소 권한 원칙" 적용, 가능한 한 계층화된 방어 등이 포함됩니다. 단계 7: 위협 모델링: 프로젝트 또는 제품이 직면한 위협을 모델링하고 공격이 발생할 수 있는 영역을 설명합니다. 8 단계: 도구 개발 팀이 사용하는 편집기, 링커 등의 관련 도구 사용을 지정하면 보안 팀이 사용하는 도구 버전과 미리 통신해야 하는 보안 관련 링크가 포함될 수 있습니다. 9 단계: 안전하지 않은 함수를 버리는 많은 일반적인 함수에는 보안 위험이 있을 수 있습니다. 안전하지 않은 함수 및 API 를 비활성화하고 보안 팀에서 권장하는 함수를 사용해야 합니다. 단계 10: 정적 분석 코드 정적 분석은 관련 도구를 사용하여 수행할 수 있으며 결과는 수동 분석과 결합됩니다. 단계 1 1: 동적 프로그램 분석 동적 분석은 정적 분석을 보완하며 프로그램의 보안을 테스트하는 데 사용됩니다. 퍼지 테스트 퍼지 테스트는 역학의 특별한 형태입니다.