"코드 감사"의 두 판 사이의 차이

180 바이트 추가됨 ,  2년 전
1 개의 출처 구조, 0 개의 링크를 깨진 것으로 표시 #IABot (v2.0beta14)
잔글 (봇: 날짜 변수 정리)
(1 개의 출처 구조, 0 개의 링크를 깨진 것으로 표시 #IABot (v2.0beta14))
 
== 가이드라인 ==
소프트웨어를 감사할 때, 모든 핵심 요소들은 각자 그리고 전체 프로그램과 함께 감사되어야 한다. 이것은 고위험의 취약점들을 먼저 찾고, 저위험의 취약점들을 찾아 내려가는 좋은 방식이다. 고위험의 취약점이나 저위험의 취약점 모두 일반적으로 그 상황과 어떻게 사용되는지에 따라 달려있다. 애플리케이션 침투 테스트는 소프트웨어의 취약점들을 인식하기 위하여 애플리케이션을 공격하기 위한 모든 가능한, 알려진 기법들을 시도한다.<ref name="source-code-audit-faq">{{웹 인용|title = Source Code Audit - FAQ|url = http://www.ouncelabs.com/resources/code-audit-faq.asp|확인날짜 = 2015-11-04|보존url = https://web.archive.org/web/20090210113645/http://www.ouncelabs.com/resources/code-audit-faq.asp|보존날짜 = 2009-02-10|깨진링크 = 예}}</ref> 이것은 일반적인 감사 기법이며 어떠한 구체적인 취약점들도 찾아낼 수 있지만 소스 코드의 어디에 위치하는지는 알 수 없다. 몇몇은 사이클 종료 감사 기법이 개발자들을 압도하며, 궁극적으로 팀에게 알려진 문제들의 긴 리스트를 남겨주지만, 실질적인 개선은 되지 않는다고 주장한다. 이러한 경우에, 인라인 감사 접근법이 대체제로 추천된다.
 
=== 고위험 취약점 ===

편집

277,649