[소스코드] 취약점 개발자 고충

개발자 입장에서 취약점 진단 결과보고서를 받아보면 난감하기 그지없을 것이다. 취약점이 수백개 또는 수천개가 나온다. 조치하려면 난감할 것이다.

보통 취약점 진단자의 경우 프로그래밍을 안해봤을 경우가 크다고 생각한다. 나의 경우 프로그래밍을 해서 개발자가 조치하기 쉽도록 말도안되는 컴파일의 부산물이나 오픈소스코드는 배제하고 취약점 영향도 크리티컬과 하이만 보고서로 추출을한다.

업무 프로세스에 맞게 툴돌리고 결과보고서를 개발자에게 던져주면 개발자가 갈려나가면서 조치결과를 보내줄 것이므로 신경쓸 필요가 없는 것이다. 예를 들면 1년에 1회 취약점 점검을 실시한다든가 이미 수행한 결과가 있기때문에 별도의 명시가 되어있지 않는한 취약점 완수에대한 결과보고는 중요하지 않다고 본다.

그러나 개발자 입장에서는 해당건을 조치하는데 전념할 것이다. 개발자 입장에서는 취약점 진단자가 상위 부서개념으로 물어보기도 뭐하고 조치해야하나 끙끙할 것으로 생각된다.

이럴때는 적절한 협의가 필요하다. 취약점 보고서를 받을때 취약점 정리표 요청하라.

왼쪽 노랑색은 취약점 점검자가 보내주고 오른쪽은 개발자가 작성하는 형식으로 문서를 주고 받도록하자. 

물론 개발자는 조치하지 않으려고 얼토당도하지않은 예외처리사유를 보내주면 안된다. 위는 XSS 취약점 예제로 해당 취약점은 사용자 입력값에 의해서 클라이언트사이트에서 영향을 받는 취약점이다. 사용자의 의도된 행위를 기반으로 일어나기때문에 해당 취약점이 사용자 입력값에 의하여 조작이 불가능한 파라미터에 대하여 취약점으로 잡혔다면 예외처리를 해주어야한다. 왜냐하면 사용자가 조작하여 취약점이 발현되지 않기 때문이다.

하지만 취약점이 있다는것 자체로 문제를 삼는 사람이있다면 필터링을 적용 시켜줘야겠다. 

나는 개발의 큰틀은 개발자를 이길 수는 없지만 취약점 나온 부분에서는 개발자보다 위에 선점하려고 모든 조치방안과 경우의 수를 생각하여 조치하도록 유도하고있다. 솔직히 다른사람은 개발자보다 모르니 개발자가 압박주면 개발자 입김으로 컨트롤 할 수 있을거라고 생각한다. 물로 이경우에도 조치 불가능한 건에만 해야곘다. 조치가능한데 귀찮다는 이유로 예외처리로 몰고가기에는 너무 날로먹는게 아닌지 모르겠다.

취약점 점검자 입장에서는 주요정보통신기반 취약점 진단 가이드를 기준으로 보안적 측면에서 조치를 권고 드린다고 말 할 것이다. 또는 내부감사 지적사항이다. 국정원 실태평가의 진단 대상이다. 무조건 해야하는 상황으로 만들 수도 있으니 조치하여 잡음없이 넘어가는 편이 좋다고 생각한다. 유지보수 입장에서는 할 수 있는 것과 할 수 없는 것을 구별하여 공수를 산정하는 것도 중요하지만 업무 프로세스상 해야하는 것도 있다.

나도 수많은 취약점점검 결과서를 개발자분들께 전달드리지만 나도 찜찜하다. 해당 결과에 대하여 어떤 문의가 올지 매우 두근두근 거린다. 그러기에 나도 항상 공부를하며 대응을해야하고 개발자 입장에서 한번더 생각해본다. 가끔 와 이거를 다 조치를 해야하네 라는 사이즈의 예외처리를한 취약점을보면 던져주기 미안하지만 어쩔수 없다. 업무인걸 거의 다같이하는 조별과제 같은 느낌이다. 

그리고 취약점은 1개를 조치하면 30개가 조치되는 것도 있다 이를 Sink라고 표현한다(Fortify 제품) Sink를 취약점 점검자에게 문의하여 해당건을 쳐내는 방식으로 조치를하자.

ex. 최상단에 입력값 필터링을 걸어서 연결되는 수많은 페이지를 커버할 수 있다.