처음에 소스검사 툴 사용해서 프로젝트 소스 진단하라는 이야기를 들었을 때, 그냥 빨리 해치워야 되는 일 정도로 생각했습니다. 개발자로서의 성장에 그리 유의미한 부분이 없다고 느껴서 였습니다. 그러나 탐지 된 버그 및 문제점들을 읽어 내려갈 수록 정말 중요하고, 보안과 코드의 흐름상 단순히 개인 공부로는 얻기 어려운 것들을 알 수 있었습니다. 꽤나 많은 문제점들이 나왔지만 기억에 많이 남는 부분으로 요약해보고자 합니다.

Fortify

좀 더 고전적(?)인 방식의 소스 검사 툴인 듯합니다. 커뮤니티에서는 기술은 계속 발전하는데 툴이 그대로이니 의미 없다는 이야기도 있었습니다. 그래도 배울건 많았다.

• 싱글톤 문제: 마이그레이션 이전 버전에서는 어떻게 통과 했는지 모르겠습니다. 싱글톤 문제들이 두 곳 정도 있었습니다. 전역변수를 여러 메서드에서 공유하면서 생겨나는 문제였습니다. 첫번째 경우는 전역 변수를 사용하지 않고 메소드 하위에 지역변수로 값을 복사하는 방식으로 변경 하여 해결 했습니다. 두번째는 전역 변수에 final을 추가하여 변경 할 수 없게 만들어 해결 했고, 세번째는 여러 메서드가 분리해서 갖고 있던 로직을 하나의 메서드로 모두 옮겨 전역변수가 필요 없게 만들어 해결 했습니다.
• TLS 1.0 1.1 1.2: TLS라는 보안 프로토콜이 있다는 것을 배웠습니다. 결과적으로는 사내에서 사용하는 버전이 1.0이어서 권장되는 1.2.로 버전업은 불가하였지만 보안 방식에 버전에 따라 취약해질 수 있다는 사실을 배운 경험이었습니다.
• AES: 암호화 방식에서도 권장되는 방식이 있음을 알 수 있었습니다. 단방향 암호화 방식상 이미 DB에 암호화 되어 저장되어있는 데이터가 있어 변경 불가하여 오탐처리 하였습니다.

Sonarqube

• Stream close 문제: stream의 경우 객체를 생성한 후 필히 close()를 하여 메모리 손실을 막아야합니다. 메모리 관리가 제대로 되지 않을 경우 누수로 인해 서버에 성능과 안정성에 지장을 줄 수 있는 부분이었습니다. 본래에 코드에도 close() 메서드가 사용되어 stream을 닫는 코드가 있었으나 문제는 코드 상에서 에러가 발생할시 close()가 동작하지 못할 수 있다는 문제가 있었습니다. 해당 사례는 try-finally문을 사용하여 예외가 발생하더라도 finally문 내부에 있는 close() 메서드가 동작하게 하여 해결 할 수 있었습니다.

Blackduck

• 각각의 구형 라이브러리가 갖는 보안상의 문제점을 지적하고, 권장되는 라이브러리를 추천해주었습니다. 온라인 환경이 아니었기에 하나하나 jar파일을 추가하는 방식으로 최신화를 완료하였습니다. 몇몇 라이브러리는 전자정부 프레임워크와의 호환성으로 인해 오탐처리를 해야되는 부분도 있었습니다.