열세 번째 발걸음다른 눈으로 검사하고 근거를 읽는다

보안 검사는 프로그램을 보는 위치에 따라 알아낼 수 있는 것이 다릅니다. 소스 코드를 읽는 사람은 아직 실행되지 않은 경로를 볼 수 있지만 실제 배포 설정과 사용자 권한 흐름을 모두 알지는 못할 수 있습니다. 실행 중인 서비스만 보는 사람은 실제 응답을 확인할 수 있지만 접근하지 못한 코드 안의 문제는 놓칠 수 있습니다. 하나의 도구가 발견한 결과를 프로그램 전체의 안전성으로 바꾸지 않아야 합니다.

SAST는 실행하지 않은 코드나 관련 산출물을 분석하여 위험한 사용 패턴과 데이터 흐름을 찾는 방식입니다. 예를 들어 외부 입력이 안전한 분리 없이 SQL 실행 함수에 도달하는지 추적할 수 있습니다. 다만 실제로 도달 불가능한 경로를 경고하거나 프레임워크의 보호를 충분히 이해하지 못할 수도 있습니다. 경고에는 입력의 출처, 사용 지점, 그 사이의 통제가 근거로 따라와야 합니다.

DAST는 동작하는 애플리케이션에 요청을 보내 응답과 행동을 관찰합니다. 실제 설정 오류와 실행 중 드러나는 문제를 볼 수 있지만, 로그인 상태나 역할, 다단계 업무를 제대로 탐색하지 못하면 검사 범위가 좁아집니다. 스캐너가 첫 화면만 살폈는데 “발견 없음”을 반환했다면 로그인 뒤의 결제와 관리자 기능까지 확인한 것이 아닙니다.

IAST는 실행 중인 애플리케이션 안에서 수집한 정보를 요청 흐름과 연결해 분석하는 방식입니다. 테스트가 실제로 실행한 경로의 내부 정보를 얻을 수 있지만, 실행하지 않은 경로의 검증까지 자동으로 완료한 것은 아닙니다. SCA는 외부 라이브러리와 구성요소·버전을 식별하고 알려진 취약점과 정책 등을 대조하는 활동입니다. 같은 약어들이 보여도 관찰 대상과 한계가 서로 다릅니다.

퍼징은 형식과 값, 길이, 순서 등을 다양하게 만든 입력으로 예상하지 못한 동작을 찾습니다. 크래시와 시간 초과, 메모리 오류, 잘못된 상태를 관찰하는 데 쓸 수 있습니다. 입력을 무작정 많이 보낸 횟수보다 어떤 코드 경로와 상태를 탐색했고 실패를 재현할 수 있는지가 중요합니다. 검증은 통제한 실습 환경에서 목적과 범위를 정해 수행합니다.

ZAP 같은 웹 검사 도구에서는 요청과 응답을 관찰하는 수동적 분석과, 별도 시험 요청을 보내는 적극적 검사 활동을 구분해서 볼 수 있습니다. 공격성 입력을 보내는 검사는 상태 변경과 부하를 만들 수 있으므로 시험용 자료·계정과 범위를 정합니다. 보안 담당자는 도구의 버튼보다 검사할 업무와 허용 조건을 알아야 합니다. 복잡한 인가와 업무 논리는 사람이 만든 구체적인 시나리오가 필요합니다.

참고　[249] · [250] · [251] · [246]