SAST는 작성한 소스 코드의 구조와 흐름에서 잠재적인 보안 약점을 찾는 정적 분석입니다. SCA는 프로젝트가 사용하는 외부 라이브러리와 그 버전 등 구성요소를 파악해 공개 취약점 정보를 대조하는 분석입니다. 취약한 외부 라이브러리의 버전을 찾는 질문이라면 SAST보다 SCA가 먼저 맞는 도구 범주입니다.
두 분석은 서로 대체하지 않습니다. SAST 경보는 실제 실행 경로와 입력 통제를 확인해야 하고, SCA 경보도 해당 패키지·버전·배포 여부를 확인해야 합니다. 아래 상황과 수치는 이해를 위한 가상 예시이며 특정 검사 도구의 실제 탐지 결과가 아닙니다.
무엇을 검사하는지부터 구분합니다
정적 애플리케이션 보안 검사(SAST)는 프로그램을 실행하지 않고 소스 코드나 중간 표현을 살펴 잠재적인 취약 코드를 찾습니다. 예를 들어 사용자 입력이 검증 없이 민감한 함수에 전달되는지, 권한 확인을 건너뛰는 경로가 있는지 단서를 찾을 수 있습니다. 반면 소프트웨어 구성 분석(SCA)은 서비스가 가져다 쓰는 외부 라이브러리나 프레임워크의 구성요소와 버전을 확인하고, 해당 구성요소와 관련된 공개 취약점 정보를 살핍니다. OWASP Developer Guide는 SAST를 정적 코드 분석으로 설명하고, 의존성 검사는 외부 구성요소의 공개 취약점 정보를 찾는 활동의 예로 듭니다. 도구 하나가 전체 위험을 증명하는 것이 아니라, 다른 검사와 함께 써야 한다는 점도 중요합니다.
| 관찰한 항목 | 먼저 볼 분석 | 판단 이유 | 추가 확인 |
|---|---|---|---|
| 직접 작성한 입력 처리 함수에서 입력값이 검증 없이 파일 경로로 전달됨 | SAST | 코드 내부 데이터 흐름과 검증 지점을 살펴야 함 | 실행 가능한 경로인지, 상위 계층에서 이미 검증하는지 확인 |
| 잠금 파일에 외부 패키지의 이름과 구버전이 기록됨 | SCA | 외부 구성요소와 버전을 식별해 알려진 취약 정보와 대조해야 함 | 실제 빌드·배포에 포함됐는지, 취약 조건에 해당하는지 확인 |
| 화면에 반영된 서비스가 예상과 다른 응답을 반환함 | DAST 등 실행 중 검사도 고려 | 운영 또는 시험 중인 애플리케이션의 동작을 관찰하는 문제 | 환경·계정 권한·테스트 범위를 안전하게 설정 |
가상 주문 서비스의 두 경보를 분리해 봅니다
주문 서비스에 직접 만든 파일명 정리 함수와 외부 이미지 처리 패키지가 있다고 합시다. 첫 번째 경보는 함수의 입력이 파일 경로를 만드는 과정에 연결될 수 있다는 내용입니다. 이 경보가 실제 취약점인지 알려면 입력이 어디서 들어오는지, 정규화·허용목록 검사가 앞뒤에 있는지, 위험한 함수 호출이 어떤 조건에서 실행되는지를 따라가야 합니다. SAST는 코드 단서와 흐름을 좁혀 주지만, 경보 문구만으로 외부 공격이 가능하다고 결론내지는 않습니다.
두 번째 경보는 잠금 파일에 기록된 이미지 처리 패키지의 특정 버전이 공개 취약점 정보와 맞을 수 있다는 내용입니다. 여기서는 SCA로 실제 의존성 트리와 버전을 확인하고, 취약점 레코드의 영향 범위·수정 버전·필요 조건을 비교합니다. 개발 전용 도구가 운영 빌드에 들어갔는지, 해당 기능을 사용하지 않는다는 사실이 위험을 없애는지 등은 레코드와 시스템 맥락에 따라 따로 평가해야 합니다. 패키지 이름이 비슷하다는 이유만으로 동일 구성요소라고 보거나, 보고서에 표시됐다는 이유로 곧바로 침해로 단정하지 않습니다.
검사 결과는 대상·경로·영향 순서로 확인합니다
- 질문의 대상이 직접 작성 코드인지, 외부 구성요소인지 먼저 표시합니다.
- 코드 문제라면 입력부터 민감 작업까지 이어지는 경로와 검증·권한 확인을 추적합니다.
- 의존성 문제라면 실제로 해석된 패키지 이름, 버전, 전이 의존성 여부와 배포 포함 여부를 확인합니다.
- 공개 취약점 경보라면 영향 버전과 수정 버전, 취약 조건이 현재 설정에 맞는지 원문 레코드를 대조합니다.
- 두 분석의 빈틈을 줄이기 위해 실행 중 검사나 수동 검토가 필요한지 결정합니다.
OWASP Dependency-Check는 프로젝트 의존성에서 공개된 취약점 정보를 찾으려는 SCA 도구의 한 예입니다. 이는 모든 언어·패키지·취약점을 빠짐없이 알아내거나, 각 경보가 현재 서비스에서 악용된다는 보증이 아닙니다. 구성요소 식별이 불완전하거나 정보가 늦게 반영될 수 있고, 코드 분석에도 분석기 규칙과 설정에 따른 오탐·미탐 가능성이 있습니다. 따라서 보고서의 숫자만 비교해 보안 수준을 순위 매기기보다, 어떤 자산과 경로를 얼마나 확인했는지를 함께 기록하는 편이 유용합니다.
외부 라이브러리 문제를 모두 SAST라고 부르지 않습니다
‘코드 보안 검사’라는 넓은 표현만 보고 모든 항목을 SAST로 분류하면 검사 목적과 후속 조치가 흐려집니다. 자체 코드의 취약한 데이터 흐름은 SAST의 질문이고, 패키지 구성과 알려진 취약 버전은 SCA의 질문입니다. 반대로 SCA 보고서에서 패키지가 발견되지 않았다고 자체 작성 코드가 안전하다고 말할 수는 없습니다. 시험 문제에서 ‘외부 라이브러리 목록·버전·공개 취약점’을 제시하면 SCA를, ‘소스 코드 내부의 잠재 결함’을 제시하면 SAST를 우선 연결하세요. 실제 점검에서는 하나를 선택하는 것이 아니라 필요한 범위를 함께 확인합니다.
세 문장을 보고 먼저 할 검사를 떠올립니다
회상 연습: ① 직접 작성한 권한 검사 코드가 빠졌을 가능성, ② 잠금 파일의 외부 패키지가 알려진 취약 버전일 가능성, ③ 시험 서버에서 실행할 때 응답이 변하는 현상. 각각 SAST, SCA, 실행 중 검사(DAST 등)가 우선 후보입니다. 답을 말한 뒤에는 검사 이름만 외우지 말고 대상과 확인할 증거를 한 문장씩 덧붙여 보세요. 예를 들어 두 번째는 ‘의존성 트리에서 배포 패키지의 정확한 버전을 확인하고, 취약점 레코드의 영향 범위와 대조한다’고 설명할 수 있습니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
직접 작성한 입력 처리 함수에 검증 누락 가능성이 있고, 잠금 파일에는 외부 패키지의 취약 버전 경보가 있다. 각 항목에서 먼저 적용할 분석은 무엇이며, 경보 뒤에 각각 무엇을 확인해야 하나요?
정답과 해설 확인
코드 내부 흐름은 SAST로 살피고 입력부터 민감 작업까지의 경로와 실제 검증을 확인합니다. 외부 패키지 버전은 SCA로 구성요소와 버전을 식별하고, 배포 포함 여부 및 공개 취약점 레코드의 영향 범위·조건을 대조합니다. 라이선스 분석은 이 글에서 다루지 않습니다.이 글은 작성 코드의 잠재 결함과 외부 의존성의 공개 취약점 정보를 비교합니다. 연결된 출처가 직접 다루지 않는 라이선스 정책은 범위에서 제외하며, 두 분석 모두 결과를 맥락에 대조해야 합니다.