254
자바 개발자를 위한 데브옵스 툴
7.9.2 7.9.2
테스트 커버리지와 안전 벨트테스트 커버리지와 안전 벨트
제아무리 보안 갭에 대한 지식이 많아도 실전에 활용하지 못하면 아무 쓸모가 없다. 소프트웨
어를 개발하는 동시에 보안 허점에 효과적으로 대처할 수 있는 방법은 없을까? 이 대목에서 필
자는 한 가지 메트릭에 주목하고자 한다. 바로 개발자 자신이 작성한 소스 코드의 테스트 커버
리지다. 테스트 커버리지를 충분히 확보하면 테스트 스위트를 믿고 시스템을 변경할 수 있다.
보안 갭의 영향을 받는 모든 시스템 컴포넌트가 테스트를 원활히 마친다면, 기술적인 관점에서
소프트웨어 가용성을 저해하는 장애물은 없다고 간주할 수 있다.
상황을 좀 더 자세히 살펴보자. 대부분의 보안 취약점은 의존성에 존재하며 의존성을 유지한
채 버전을 교체하는 식으로 제거한다. 따라서 버전 관리 효율성을 높이면 취약점 대처에 필요
한 민첩성도 확보된다. 매우 드물지만 컴포넌트 자체를 타 제조사의 버전으로 교체하는 경우도
있다. 이때 대체품은 해당 컴포넌트의 유의적 등가물
semantic
equivalents
이어야 한다. 컴포넌트를
새 버전으로 교체하고 유효성을 검사하려면 명확한 테스트 커버리지가 반드시 필요하다. 수동
테스트는 시간이 너무 오래 걸리며 실행할 때마다 동일한 품질을 기대하기도 어렵다. 일반적인
라인, 브랜치 커버리지보다 더 구체적인 테스트 커버리지를 확보하고 싶다면 뮤테이션
mutation
테스트를 채택하는 것도 좋은 시도다.
알려진 취약점이 ...