{{위키데이터 속성 추적}}
소프트웨어 '''코드 감사''' (code audit)는 프로그래밍 프로젝트에서 [[소프트웨어 버그|버그]], 보안 위반 또는 프로그래밍 규칙을 위배하는 것을 발견하는 것을 목적으로 [[소스 코드]]를 종합적으로 분석하는 것이다. 이것은 소프트웨어가 배포되기 전에 오류들을 감소시킬 목적의 [[방어적 프로그래밍]] 패러다임의 필수 요소이다. [[C (프로그래밍 언어)|C]]와 [[C++]] 소스 코드는 감사해야 하는 가장 흔한 코드인 반면, 많은 고수준 프로그래밍 언어들은 잠재적으로 더 적은 취약한 함수들을 갖는다.

== 가이드라인 ==
소프트웨어를 감사할 때, 모든 핵심 요소들은 각자 그리고 전체 프로그램과 함께 감사되어야 한다. 이것은 고위험의 취약점들을 먼저 찾고, 저위험의 취약점들을 찾아 내려가는 좋은 방식이다. 고위험의 취약점이나 저위험의 취약점 모두 일반적으로 그 상황과 어떻게 사용되는지에 따라 달려있다. 애플리케이션 침투 테스트는 소프트웨어의 취약점들을 인식하기 위하여 애플리케이션을 공격하기 위한 모든 가능한, 알려진 기법들을 시도한다.<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|url-status = dead}}</ref> 이것은 일반적인 감사 기법이며 어떠한 구체적인 취약점들도 찾아낼 수 있지만 소스 코드의 어디에 위치하는지는 알 수 없다. 몇몇은 사이클 종료 감사 기법이 개발자들을 압도하며, 궁극적으로 팀에게 알려진 문제들의 긴 리스트를 남겨주지만, 실질적인 개선은 되지 않는다고 주장한다. 이러한 경우에, 인라인 감사 접근법이 대체제로 추천된다.

=== 고위험 취약점 ===
몇몇 고위험 취약점들은 다음과 같은 것들의 사용으로 인해 생길 수 있다.
* 경계를 체크하지 않는 함수들은 (예를 들면, [[String.h|strcpy]], sprintf, vsprintf, 그리고 sscanf) [[버퍼 오버플로]] 취약점을 유발할 수 있다.<ref name="guidelines-for-c-source-code-auditing">{{웹 인용|title = Guidelines for C source code auditing|url = http://mixter.void.ru/vulns.html|확인날짜 = 2015년 11월 4일|보존url = https://web.archive.org/web/20080328073833/http://mixter.void.ru/vulns.html|보존날짜 = 2008년 3월 28일|url-status = dead}}</ref>
* 버퍼들의 포인터 조작은 이후의 경계 체크를 위협할 수 있다. 예를 들면 <code>if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;</code><ref name="guidelines-for-c-source-code-auditing">{{웹 인용|title = Guidelines for C source code auditing|url = http://mixter.void.ru/vulns.html|확인날짜 = 2015년 11월 4일|보존url = https://web.archive.org/web/20080328073833/http://mixter.void.ru/vulns.html|보존날짜 = 2008년 3월 28일|url-status = dead}}</ref>
* 특히 비 정적인 인자들과 함께 호출된 execve() 같은 호출, 실행 파이프, system() 등<ref name="guidelines-for-c-source-code-auditing">{{웹 인용|title = Guidelines for C source code auditing|url = http://mixter.void.ru/vulns.html|확인날짜 = 2015년 11월 4일|보존url = https://web.archive.org/web/20080328073833/http://mixter.void.ru/vulns.html|보존날짜 = 2008년 3월 28일|url-status = dead}}</ref>
* 입력 확인, 예를 들면 (SQL에서): <code>statement := "SELECT * FROM users WHERE name = '" + userName + "';"</code> 은 [[SQL 삽입]] 취약점의 한 예이다.
* 파일 포함 함수 (예를 들면 (PHP): <code>include($page . '.php');</code> )는 [[원격 파일 포함]] 취약점의 한 예이다.
* 악성코드와 링크될 수 있고, 내부의 변경할 수 있는 데이터 구조체를 반환하는 라이브러리들. 악성코드는 구조체를 변경시키거나 추후의 변화를 관찰하기 위해 참조를 유지시키려 할 수 있다.

=== 저위험 취약점 ===
아래는 코드 감사 시 발견되어야 하지만, 높은 위험 상황을 만들지는 않는 취약점들이다.
* 서버 사이드에 영향이 없는, 클라이언트 사이드 코드 취약점 (예를 들면 [[사이트간 스크립팅]])
* 사용자 이름 계산
* 디렉토리 순회 ([[웹 애플리케이션]]에서)

== 툴 ==
소스 코드 감사 툴들은 일반적으로 흔한 취약점들을 찾으며, 특정한 [[프로그래밍 언어]]에 동작한다. 이러한 자동화 툴들은 시간을 절약해 주지만, 깊은 감사 시에는 의존해서는 안된다. 정책 기반 접근법의 한 부분으로서 이러한 툴들을 적용하는 것이 추천된다.<ref>"[http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1331438,00.html Static analysis at the end of the SDLC doesn't work] {{웨이백|url=http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1331438,00.html |date=20101015045541 }}" by Wayne Ariola, SearchSoftwareQuality.com, September 22, 2008</ref>

== 요구사항에 대한 의존성 ==
만약 낮은 한계점으로 시작한다면, 특히 전에 감사되지 않은 경우에 대부분의 소프트웨어 감사 툴들은 많은 취약점들을 탐지할 것이다. 그러나 이러한 경고들의 실제 중요점은 애플리케이션이 어떻게 사용되는지에 달려있다. 악성코드와 링크될 수 있는 라이브러리는 매우 엄격한 요구사항을 갖는다. 프로그램이 단지 악성적인 입력값에만 노출되어 있다면, 첫번째로 입력에 주의를 기울여야 한다. 이러한 공격들은 프로그램이 허가된 사용자에 의해 보호되는 시설 안에서만 사용된다면, 거의 일어나지 않을 것이다.

== 같이 보기 ==
* [[방어적 프로그래밍]]
* [[원격 파일 포함]]
* [[SQL 삽입]]
* [[버퍼 오버플로]]

== 각주 ==
{{각주}}

[[분류:정보 기술 감사]]