자동 분석 도구의 finding은 도구가 규칙과 관측한 자료를 바탕으로 표시한 검토 대상입니다. OWASP는 SAST finding을 검토해야 하며 자동으로 실제 취약점이라고 간주해서는 안 된다고 안내합니다. 코드의 도달 경로, 입력 통제, 실제 자산과 영향 조건을 살핀 뒤 판단해야 합니다.
경고를 무조건 오탐이라고 버리는 것도, 검증 없이 확정 취약점이라고 단정하는 것도 위험합니다. 확인한 근거와 아직 모르는 조건을 함께 기록하세요. 아래 코드 흐름과 사례는 교육용으로 새로 작성한 것이며 공식 기출이나 판매 카드 문항이 아닙니다.
finding은 분석기가 표시한 문제 후보입니다
정적 분석 도구는 소스 코드나 중간 표현을 실행하지 않고 살펴 특정 패턴을 찾습니다. 예를 들어 위험해 보이는 함수 호출, 검증되지 않은 입력의 전달, 비밀 값의 저장 같은 규칙을 표시할 수 있습니다. OWASP Developer Guide는 SAST가 잠재적인 보안 문제를 찾는 기법이라고 설명하면서, finding을 자동으로 실제 취약점이라고 간주하지 말고 검토해야 한다고 명시합니다. 도구는 코드의 전체 사용 맥락을 알지 못할 수 있습니다. 입력값이 실제 외부에서 제어되는지, 위험한 함수까지 도달하는지, 그 전에 검증·인코딩이 이루어지는지, 해당 기능이 배포 설정에서 사용되는지 확인해야 합니다. 도구의 경고는 중요한 조사 단서이지만 그 자체로 영향이 입증된 증거는 아닙니다.
입력값이 실제 위험한 호출까지 가는지 추적합니다
교육용 Python 예를 보겠습니다. 분석기가 마지막 실행 줄을 SQL 삽입 후보로 표시했지만, 코드를 따라가면 외부 입력을 SQL 문자열에 이어 붙이지 않고 값 매개변수로 전달합니다. 이 가정된 구현과 호출 경로가 실제 배포 코드에도 동일하다면, 이 흐름에 대한 SQL 삽입 finding은 오탐으로 분류할 근거가 있습니다. 다만 다른 쿼리 경로, 데이터베이스 드라이버의 바인딩 동작, 배포 코드가 같은지는 별도 확인해야 합니다. 코드에 ‘정리’나 ‘검증’이라는 함수 이름이 있다는 사실만으로 안전을 확정하지 않습니다.
user_value = request.query["q"]
sql = "SELECT id FROM items WHERE name = ?"
rows = db.execute(sql, (user_value,))| 확인 질문 | 관찰한 근거 | 기록할 판단 |
|---|---|---|
| 입력 출처가 외부인가 | q 값은 요청에서 읽음 | 외부 입력이라는 사실은 확인 |
| 값이 SQL 구조에 결합되는가 | 문장은 고정 문자열이고 값은 별도 매개변수로 전달 | 이 경로의 SQL 삽입 후보는 오탐으로 분류할 근거가 있음 |
| 전체 배포 흐름도 같은가 | 이 예의 다른 호출 경로와 실제 빌드는 아직 비교하지 않음 | 다른 경로와 배포 코드에는 결론을 확대하지 않음 |
경고를 확인할 때는 네 가지 근거를 모읍니다
- 도구 이름·버전·규칙과 경고 위치를 기록합니다. 그래야 같은 finding을 재검토할 수 있습니다.
- 입력 또는 데이터의 출처에서 경고 지점까지의 흐름을 따라가고 실제 도달 가능한 경로를 확인합니다.
- 위험 함수나 민감 자산이 어떤 조건에서 사용되는지, 검증·인코딩·권한 확인이 앞서 적용되는지 살핍니다.
- 재현·영향을 충분히 확인하지 못했다면 ‘후보’, ‘미확인’으로 남깁니다. 반박할 때도 그 근거와 확인 범위를 씁니다.
확정 여부는 도구가 아니라 근거가 결정합니다
확정 판단을 위해 항상 공격을 실행해야 하는 것은 아닙니다. 코드 흐름, 구성, 안전한 테스트, 제품 영향에 대한 자료 등으로 취약 조건이 성립하는지 확인할 수 있습니다. 어떤 방법을 택하든 권한과 범위를 지켜야 하고, 재현이 시스템에 피해를 줄 수 있다면 안전한 격리 환경이나 비파괴 검증 방법을 먼저 선택해야 합니다. 이 글은 실제 서비스를 공격하는 절차를 안내하지 않습니다. 증거가 충분하지 않을 때는 ‘분석기가 경고를 냈다’, ‘경로 도달성을 확인했다’, ‘영향을 확인하지 못했다’처럼 관찰과 판단을 나눠 보고합니다. 오탐으로 분류하더라도 어떤 전제나 코드 경로 때문에 해당 규칙이 적용되지 않는지 기록하면 나중에 조건이 바뀌었을 때 다시 판단하기 쉽습니다.
경고를 끄거나 확정하기 전에 맥락을 확인하세요
흔한 실수는 finding을 ‘도구가 찾았으니 취약’ 또는 ‘시험에서 문제가 재현되지 않았으니 오탐’으로 양분하는 것입니다. 위 코드 예에서는 값 매개변수화가 실제로 적용된 해당 SQL 경로의 finding을 오탐으로 분류할 근거가 있지만, 이 결론을 다른 호출 경로나 배포 코드에 확대할 수는 없습니다. 반대로 동적 시험에서 재현되지 않았다는 사실만으로 모든 입력·환경에서 취약점이 없다고 증명되는 것도 아닙니다. 정적 분석의 한계는 경고를 무시해도 된다는 뜻이 아니며, 확인한 코드 경로와 남은 조건을 함께 기록해야 합니다.
회상 연습: 근거 수준을 세 문장으로 정리합니다
예시 답: ‘정적 분석기가 입력 전달 경로에 규칙 기반 finding을 표시했다. 실제 외부 입력이 해당 경로에 도달하는지와 배포 환경에서 기능이 활성화되어 있는지는 확인하지 않았다. 이 두 조건과 사용 문맥을 추가 검토한 뒤 영향 여부를 판단한다.’ 이 답은 도구의 결과를 보존하고 검증의 빈틈도 드러냅니다. 연습할 때는 첫 문장에 관찰 사실, 다음 문장에 미확인 조건, 마지막에 안전한 후속 확인을 배치하면 자동 경고와 판단을 섞지 않을 수 있습니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
가상 코드에서 요청값은 고정 SQL 문자열과 별도 값 매개변수로 실행됩니다. 분석기는 SQL 삽입 후보를 표시했습니다. 이 경로의 finding을 어떻게 분류하고, 어떤 범위는 더 확인해야 하나요?
정답과 해설 확인
제시된 코드와 데이터베이스 호출이 실제로 같은 방식으로 동작한다면, 고정 SQL 구조와 별도 값 바인딩을 근거로 이 경로의 SQL 삽입 finding을 오탐으로 분류할 수 있습니다. 다만 실제 배포 코드, 드라이버의 바인딩, 다른 쿼리 경로는 별도 확인하고 결론을 확대하지 않습니다.코드 예시는 입력→고정 쿼리→매개변수 바인딩→실행 경로를 보여 줍니다. 한 경로의 조건을 판별한 결과와 애플리케이션 전체에 대한 보안 결론은 구분해야 합니다.