여러 고객사를 다녀보는 컨설턴트 입장에서 보면, 소스진단 도구만으로 어플리케이션 보안정책을 유지관리하겠다는 고객사를 본다.
특히, 최근의 어플리케이션 보안진단 도구들의 마케팅 전략을 보면, 소스진단(정적진단) 도구와 원격진단(동적진단) 도구를 연동하여 모든 어플리케이션의 보안을 해결할 수 있다고 강조하는 과장된 마케팅 전략이 고객사의 어플레케이션 보안정책을 혼란시키는 원인을 제공하게 된 것이 아닌가 생각들기도 한다.

소스진단 도구가 점검하지 못하는 부분이 어떤 것인지 대표적인 취약점을 간략히 살펴보면 아래와 같다.
- 비즈니스 로직 취약점
- 사용자 권한 취약점
- 사용자 인증 취약점

쇼핑몰을 예로들면, 아직도 가끔 날코딩된 쇼핑몰 사이트에서 발견되는 가격변조 취약점이 가장 대표적인 비즈니스 로직상의 취약점으로 볼수 있다.
프록시 같은 도구를 이용해서 HTTP request시 구입상품의 가격을 1원으로 구매요청을 할 수 있지 점검하는 항목은 아주 기본적인 점검항목이지만, 불행하게도 소스진단 도구가 이러한 비즈니스 로직까지 이해하고 관련 라인들을 점검해주지는 못한다.

OWASP top10 또는 국내 취약점 점검항목에 빠지지 않고 있는 점검항목중에 하나가 권한상승 취약점이다.
온라인 교육사이트를 예로 들면, 일반적으로 actor를 수강자, 강사, 관리자로 나누는데, 수강자가 강사권한을 획득할 수 있다던가, 관리자 권한을 획득할 수 있다던가 하는 취약점이다.
Java Sprint Framework와 같은 개발 Framework을 이용하면, 복잡하고 어렵지 않게 구현할 수 있지만 날코딩 수준의 웹사이트는 여러 종류의 Actor들에 대한 권한을 설계하는 것은 쉽지 않을 것이다.
이러한 취약점도 소스 취약점 점검도구는 점검해주질 못하는 것이 당연하다.

여러 기업이나 기관들의 웹사이트가 많아지면서 웹 사이트간에 사용자 인증정보를 연동시켜서 사용자의 별도 로그인 행위 없이 자동 로그인 처리를 구현하는 경우가 많다.
OpenID 또는 OpenAuth와 같은 검증된 기법들이 있지만, 이해관계가 복잡하고 짧은 개발기간으로 인해 이런 좋은 기법을 적용 못하고 인증정보를 paramter로 전달하여 구현하는 경우가 많다.
이런 경우 이 parameter 값을 변조하여 타 사용자를 도용할 수 있는 취약점들이 자주발견된다.
이런 경우 입력값의 정의 여부, 또는 cookie의 안전성 정도만을 기준으로 스캔을 수행하는 소스점검 도구로는 이런 취약점을 점검하지 못하는 것이 당연하다.

일반적으로 도구라는 것은 사람이 하는 일 중에서 반복적인 작업을 신속하게 또는 빠짐없이 처리해주는 경우가 대부분이다.
소스 취약점 점검도구도 마챦가지로 위에서 살펴본 몇 가지 한계가 있기 마련이므로 그 한계를 극복하기 위하여 소스 취약점 전문인력의 수작업이 병행되는 것이 효과적이다.