취약점 점검과 침투 테스트 결과를 수정으로 연결하기

커머스 플랫폼을 운영하면서 취약점 점검과 침투 테스트의 결과에 대응했습니다. 점검 보고서를 받는 것에서 끝나지 않고, 발견된 조건을 이해하고 코드나 설정을 수정한 뒤 결과를 다시 확인해야 했습니다.

자동 점검과 침투 테스트는 확인하는 범위가 달랐습니다. 한쪽에서 문제가 나오지 않았다는 사실만으로 다른 확인까지 끝낼 수는 없었습니다.

점검 방식별 확인 범위

자동 점검에도 여러 종류가 있습니다. 의존성의 알려진 취약점을 찾는 것과 소스 코드의 위험한 패턴을 찾는 것은 같은 검사가 아닙니다.

침투 테스트도 수동 확인과 도구를 함께 사용할 수 있습니다. 중요한 차이는 자동인지 수동인지 하나가 아니라, 어떤 대상과 조건을 확인했고 어떤 범위가 남았는지입니다.

보고서와 재현 조건

보고서에 권한 우회나 데이터 노출 가능성이 적혀 있으면, 영향을 받는 경로와 계정 권한, 요청 조건부터 확인해야 했습니다. 같은 기능이라도 일반 사용자와 관리자, 다른 사용자의 데이터에 접근할 때 결과가 달라질 수 있습니다.

재현 조건을 파악해야 수정 범위도 정할 수 있습니다. 화면의 버튼을 숨기는 조치로 충분한지, 서버의 권한 검사나 데이터 조회 조건을 바꿔야 하는지 구분해야 합니다.

점검팀과 개발팀이 같은 조건으로 결과를 확인하는 과정도 필요했습니다. 환경이나 계정이 다르면 수정 전후를 제대로 비교하기 어렵습니다.

대응 우선순위

심각도는 우선순위를 정하는 출발점입니다. 실제 노출 여부와 사용 경로, 영향을 받는 데이터, 임시 완화 가능성도 함께 봐야 합니다.

등급 이름만으로 모든 서비스의 수정 시한을 동일하게 정하기보다 조직의 정책과 위험에 맞춰 담당자·기한·남은 조치를 연결해야 합니다. 예외를 두는 경우에도 그 이유와 재검토 시점이 있어야 나중에 그대로 방치되지 않습니다.

새 빌드와 기존 배포 파일 점검

CI에서 의존성이나 코드를 검사하면 변경을 반영하기 전에 문제를 찾는 데 도움이 됩니다. 기준에 따라 빌드를 막을 수도 있지만, 검사 결과를 분류하고 조치할 담당자가 함께 정해져 있어야 합니다.

새 빌드를 검사하는 것과 이미 운영 중인 배포 파일을 다시 확인하는 것도 다릅니다. 소스가 바뀌지 않아도 새 취약점 정보가 공개될 수 있기 때문입니다. 점검 도구의 정보가 갱신됐을 때 기존 버전의 영향을 다시 확인할 수 있어야 합니다.

수정 뒤 재확인

수정 후에는 보고서의 재현 조건으로 다시 확인하고, 정상적인 사용 흐름이 깨지지 않았는지도 봅니다. 같은 로직을 사용하는 다른 API나 서비스에도 문제가 있는지 확인할 필요가 있습니다.

공통 라이브러리를 고쳤다면 각 서비스의 빌드와 배포 상태까지 이어서 확인해야 합니다. 수정한 코드가 있다는 사실과 운영에 반영된 상태를 구분해야 누락을 찾을 수 있습니다.

OWASP의 가이드도 테스트를 서비스와 위험에 맞춰 적용하는 참고 자료입니다. 항목을 모두 체크했다는 이유만으로 보안 확인이 완결됐다고 보기보다, 확인한 범위와 남은 문제를 기록하는 데 활용하는 편이 맞습니다.

다음 글에서는 장애 감지 지표와 알림 조건을 정리합니다.

참고 자료

• OWASP Web Security Testing Guide v4.2