SAST와 SCA는 어떻게 다른가?
static application security testing(SAST)은 조직의 개발자가 직접 작성한 자체 코드를 검사합니다. software composition analysis(SCA)는 개발자가 가져와 사용하는 오픈 소스 및 서드파티 구성 요소를 검사합니다.
두 방식의 차이는 「누구의 코드를 검사하는가」에 있습니다. SAST는 개발자가 작성한 코드를, SCA는 외부에서 가져온 오픈 소스 및 서드파티 구성 요소를 검사합니다. 두 방식 모두 애플리케이션이 프로덕션 환경에 배포되기 전에 실행되며 보안 문제를 조기에 식별합니다. 다만 같은 코드베이스 안에서 서로 다른 영역을 검사합니다.
이 구분이 중요한 이유는 최신 애플리케이션은 대부분 처음부터 새로 작성하기보다 기존 구성 요소를 조합해 만들기 때문입니다. 개발팀은 일부 로직을 직접 작성하고, 빠른 개발을 위해 수백 개의 라이브러리에 의존합니다. 두 방식의 결과를 함께 살펴보면 애플리케이션이 배포되기 전에 위험이 어디에 존재하는지 전체적으로 파악할 수 있습니다.
CNAPP 시장 가이드 다운로드
클라우드 보안 플랫폼을 평가할 때 확인해야 할 핵심 기준과 시장 흐름을 한눈에 파악하세요.
static application security testing(SAST)이란 무엇인가?
static application security testing(SAST)은 애플리케이션이 실행되기 전에 소스 코드의 보안 결함을 스캔하는 화이트박스 테스트 방식입니다. SAST는 코드를 구성 요소 단위로 분해해 SQL 인젝션, cross-site scripting(XSS), 버퍼 오버플로와 같은 문제를 개발 초기에 드러냅니다.
SAST 도구는 소스 코드를 추상 구문 트리(Abstract Syntax Tree, AST)로 분석하고, 신뢰할 수 없는 입력값에서 민감한 싱크(Sink)까지 이어지는 데이터 흐름을 추적합니다. 이를 통해 인젝션 및 XSS 경로를 찾아내고, 탐지 결과를 심각도에 따라 순위화해 팀이 무엇을 먼저 수정해야 하는지 알려 줍니다. 이러한 상세 정보를 바탕으로 개발팀은 어떤 코드 취약점을 우선 해결할지 결정할 수 있습니다.
software composition analysis(SCA)란 무엇인가?
software composition analysis(SCA)는 팀이 작성한 코드가 아니라, 애플리케이션이 의존하는 오픈 소스 및 서드파티 코드를 스캔합니다. 여기에는 패키지, 라이브러리, 그리고 이를 포함해 배포되는 바이너리와 container images 등이 포함됩니다. SCA는 모든 dependencies 항목의 목록을 작성하고, 각 항목을 알려진 취약점 database 목록과 대조하며, 배포 전에 위험한 버전과 라이선스 문제를 식별합니다.
다시 말해, SCA는 개발팀이 직접 만들지 않은 코드를 식별합니다. SCA 도구는 이어서 dependencies 항목 전체에 대한 포괄적인 목록을 만들고, 알려진 취약점 database 목록과 대조해 스캔한 뒤, 잠재적 위험을 개발자에게 알립니다. 또한 라이선스 준수 여부를 추적해 오픈 소스 사용이 법적 조건을 벗어나지 않도록 지원합니다.
이후 SCA 도구는 취약점, 라이선스 위험 및 기타 문제를 정리한 보고서를 수정 권장 사항과 함께 생성합니다. 이 결과는 개발 워크플로에 다시 반영되므로 개발자는 배포 전에 문제를 해결할 수 있습니다. 대표적인 SCA 도구로는 Wiz, JFrog Xray, Xygeni 등이 있습니다.
SAST와 SCA의 주요 차이점
두 방식은 같은 목표를 공유하지만, 조직의 자체 코드와 외부 코드로 역할을 나눕니다. 아래 표는 각 방식의 검사 대상, 실행 시점, 그리고 발견된 문제를 실제로 수정하는 방법을 정리한 것입니다.
| 항목 | SAST | SCA |
|---|---|---|
| 검사 대상 | 자체 코드(조직의 개발자가 작성한 코드)를 검사해 잘못된 코딩이나 안전하지 않은 방식으로 인해 발생할 수 있는 취약점을 식별 | 애플리케이션 개발에 사용되는 오픈 소스 구성 요소 또는 서드파티 라이브러리 |
| 테스트 단계 | 주로 개발 초기 단계에서 사용 | 주로 빌드 단계에서 사용 |
| 취약점 유형 | 코드 수준 취약점(예: XSS, SQL 인젝션) | 서드파티 라이브러리의 취약점(CVE, 노출) |
| 수정 방법 | 애플리케이션 소스 코드 수정 | dependencies 버전 업그레이드 또는 교체 |
SAST의 장점
Shift-left security(개발 초기 단계로 보안 점검을 앞당기는 접근 방식): SAST를 활용하면 개발자는 개발 주기 초기에 보안 문제를 식별하고 수정할 수 있습니다. 이를 통해 대규모 보안 침해 가능성을 줄이고 조직의 보안 태세를 크게 강화합니다.
안전한 코딩: SAST는 안전한 코딩 프로세스를 정착시키고 개발자가 더 견고한 코드를 작성하도록 돕습니다. 예를 들어 개발자가 사용자 입력을 처리하는 함수를 작성한다고 가정합니다. SAST가 없다면 입력 길이를 제대로 검증하지 않아 버퍼 오버플로 취약점을 실수로 만들 수 있습니다. SAST 도구는 이를 잠재적 보안 문제로 표시하고, 개발자가 입력값 검증 로직을 추가하도록 유도합니다. 그 결과 공격자가 해당 취약점을 악용해 악성 코드를 실행하는 상황을 방지할 수 있습니다.
규정 준수: 여러 산업은 PCI DSS, FedRAMP, FISMA, SOC 2, HIPAA 등 소프트웨어 보안 관련 규제 표준을 준수해야 합니다. 조직은 SAST를 통해 소스 코드 수준에서 의무 요구 사항을 충족할 수 있습니다. 또한 SAST는 규정 준수 증빙을 위한 문서화와 감사 추적을 지원합니다. 이러한 프로세스는 법적 처벌 위험을 해소하고 고객 신뢰를 높입니다.
심각도 기반 탐지 결과: SAST는 각 탐지 결과에 심각도를 부여해 팀이 분류 작업(Triage)을 시작할 출발점을 제공합니다. 다만 심각도만으로는 해당 코드가 실제로 배포되어 접근 가능한 상태인지 알 수 없습니다.
SAST의 한계
SAST는 많은 이점이 있지만 몇 가지 단점도 있습니다.
커버리지 공백: SAST 솔루션은 코드 자체에 존재하는 취약점만 탐지할 수 있으므로 외부 dependencies 항목은 완전히 검사하지 못합니다. 또한 SAST는 runtime 단계의 애플리케이션 취약점을 탐지하지 못합니다.
언어별 SAST 인스턴스 필요: 두 개 이상의 프로그래밍 언어를 사용하는 조직은 언어마다 별도의 SAST 인스턴스가 필요합니다. SAST 인스턴스마다 유지 관리와 구성 절차가 다르기 때문에 운영 비용이 누적될 수 있습니다.
False positives: SAST 솔루션의 주요 한계 중 하나는 잘못된 경보가 발생하기 쉽다는 점입니다. 스캔 결과에 false positives(오탐)가 많으면 alert fatigue(경보 피로) 현상으로 이어질 수 있습니다.
소스 코드 접근 필요: 애플리케이션의 소스 코드에 접근하지 못할 수도 있습니다. 소스 코드가 없으면 SAST는 제대로 작동하지 않거나 아예 작동하지 않습니다.
Wiz 클라우드 보안 데모 보기
Wiz가 멀티클라우드 환경의 위험을 어떻게 발견하고 우선순위화하는지 실제 화면으로 확인하세요.
SCA의 장점
효율성: SCA는 개발팀이 코드를 작성하는 동시에 오픈 소스 구성 요소의 알려진 취약점을 빠르고 효율적으로 추적하고 식별합니다.
공급망 보호 범위: Wiz Research에 따르면 악성 패키지의 90%가 공개 레지스트리에서 유입됩니다. 이는 SCA가 탐지하도록 설계된 바로 그 노출 영역입니다.
자동화: 많은 SCA 도구는 식별된 취약점에 대한 자동 수정 옵션을 제공합니다.
종속성 관리: SCA는 조직이 서드파티 dependencies 항목을 관리하도록 지원합니다. 이를 통해 최신 버전을 사용하고 오래되었거나 취약한 구성 요소를 피할 수 있습니다.
라이선스 준수: SCA는 오픈 소스 구성 요소의 라이선스 준수 여부를 추적해 법적 문제를 예방합니다. 또한 조직이 각 구성 요소를 라이선스 조건에 맞게 사용하도록 보장합니다.
SCA의 한계
SAST와 마찬가지로 SCA에도 몇 가지 단점이 있습니다.
위험 소유권: 취약점이 식별된 구성 요소는 여러 팀과 프로젝트에 속해 있을 수 있습니다. 따라서 위험이 식별되더라도 누가 보안 문제를 수정할 책임을 져야 하는지 판단하기 어려울 수 있습니다. 특히 팀에 잠재적 위험 알림이 대량으로 전달되면 혼란과 대응 지연이 발생할 수 있습니다.
False positives: 앞서 언급했듯이 SCA 도구는 잠재적 위험의 긴 목록을 생성하는 경향이 있으며, 여기에는 관련 없는 위험과 false positives(오탐)가 포함될 수 있습니다. SCA 결과를 수동으로 검토하는 팀은 실제 위험을 평가하는 데 쓸 수 있었던 리소스를 크게 낭비할 수 있습니다.
기술 부채: 기술 부채는 software development lifecycle(SDLC) 초기부터 안전한 코딩 프로세스를 우선시하지 않을 때 발생합니다. 과거에 사용하던 라이브러리나 오픈 소스 구성 요소가 방치될 때도 기술 부채가 생길 수 있습니다. 이를 해결하지 않으면 개발 비용 증가, 프로젝트 일정 지연, 보안 취약점으로 이어질 수 있습니다.
커버리지 공백: SCA 도구가 효과를 발휘하려면 최신 취약점 database 정보가 필요합니다. 또한 software composition analysis 솔루션은 사용 중인 모든 서드파티 구성 요소나 모든 오픈 소스 프로젝트를 식별하지 못할 수 있습니다.
SAST, SCA 또는 두 가지 모두를 사용해야 하는 시점
대부분의 팀에는 두 가지가 모두 필요합니다. 각 방식이 다른 방식으로는 볼 수 없는 사각지대를 보완하기 때문입니다. 개발자가 코드를 작성하고 커밋하는 초기 단계에서 SAST를 실행하고, 빌드 시점에 SCA를 실행해 위험한 dependencies 항목이 배포되기 전에 차단하시기 바랍니다.
두 방식 모두 자동화된 pipelines 환경에 자연스럽게 통합됩니다. SAST와 SCA를 CI/CD pipelines 환경에 통합하면 수동 검토를 기다리지 않고 코드가 변경될 때마다 스캔이 실행됩니다. SAST는 팀이 소유한 로직을 담당하고, SCA는 오픈 소스 계층의 알려진 취약점과 정책 위반을 감시합니다. software bill of materials(SBOM)도 바로 이 계층에서 만들어집니다.
진정한 효과는 두 방식의 탐지 결과를 결합할 때 드러납니다. SAST는 개발자 코드에 대한 상세한 관점을 제공하고, SCA는 애플리케이션이 의존하는 외부 dependencies 항목에 집중합니다. 하지만 목표는 애플리케이션 보안으로 동일합니다. 두 보고서를 하나의 화면으로 통합하면 부분적인 두 그림이 신뢰할 수 있는 하나의 애플리케이션 위험 지도로 바뀝니다. 그 결과 팀은 SAST, SCA 또는 둘 다 필요한지 확신을 갖고 결정할 수 있습니다.
SBOM의 내용을 채우는 주체는 SCA입니다. 스캐너는 빌드 시점에 종속성 트리를 분석하면서 모든 직접 및 전이적 구성 요소를 담은 CycloneDX 또는 SPDX 형식의 목록을 생성할 수 있습니다. 다음 치명적인 CVE가 공개되고 누군가 「우리도 영향을 받는가?」라고 물을 때 필요한 산출물이 바로 이것입니다.
SAST 및 SCA와 함께 활용하는 DAST의 역할
SAST와 SCA는 모두 애플리케이션이 실행되기 전에 저장된 상태의 코드와 dependencies 항목을 분석합니다. dynamic application security testing(DAST)은 정반대의 관점을 취합니다. DAST는 소스 코드를 보지 않고 외부에서 실행 중인 애플리케이션을 테스트합니다. 공격자처럼 실제 동작 중인 endpoint 지점을 탐색해 runtime 단계에서만 나타나는 문제를 찾아냅니다.
이러한 블랙박스 관점 덕분에 세 가지 방식은 서로를 대체하지 않고 보완합니다. SAST와 SCA는 코드와 dependencies 항목에 어떤 문제가 있는지 알려 주고, DAST는 배포 후 애플리케이션이 실제로 어떻게 동작하는지 확인합니다. 세 방식을 함께 사용하면 동일한 애플리케이션을 runtime 이전과 runtime 단계에서 모두 살펴볼 수 있어, 어느 한 방식만으로는 남는 공백을 메울 수 있습니다.
Wiz의 SAST 및 SCA 기반 코드 보안 지원
기존 AppSec 스캐너는 노이즈가 많은 이론적 경보를 쏟아내는 경향이 있어, 개발자는 어떤 탐지 결과가 실제 프로덕션에 영향을 미치는지 추측해야 합니다. Wiz의 code security 솔루션을 사용하면 팀은 Wiz의 네이티브 SAST를 사용하든 기존 SAST 및 SCA 도구를 통합하든 원하는 방식으로 코드를 보호할 수 있습니다. 어느 방식이든 동일한 code-to-cloud 컨텍스트, 통합된 우선순위 지정, 더 빠른 수정 워크플로의 이점을 얻습니다. Wiz는 Checkmarx 통합을 통해 SAST와 SCA를 결합해 단일 플랫폼에서 코드 위험에 대한 완전한 가시성을 제공합니다.
이러한 기능은 Wiz Code 안에서 동작하며 Security Graph를 통해 연결됩니다. 따라서 탐지 결과에는 우선순위를 판단하는 데 필요한 컨텍스트가 함께 제공됩니다. Wiz code security 솔루션의 주요 기능과 이점은 다음과 같습니다.
Wiz SAST: Wiz는 네이티브 SAST 엔진과 전용 SAST AI 에이전트를 함께 제공해 더 높은 정확도와 더 적은 노이즈로 코드 취약점을 찾아냅니다. 탐지 결과는 Wiz Security Graph를 통해 클라우드 runtime 컨텍스트로 보강되며, Wiz AI-APP의 일부로서 팀이 더 빠르게 우선순위를 정하고 수정하도록 지원합니다.
고급 SAST 통합: Wiz의 SAST 엔진은 애플리케이션 보안 테스트 솔루션의 선도 기업인 Checkmarx를 기반으로 구동할 수 있습니다. Checkmarx의 SAST 기능을 통해 SQL 인젝션, cross-site scripting(XSS), 버퍼 오버플로 등 다양한 취약점을 탐지합니다.
심층 SCA 기능: Wiz의 SCA 엔진은 애플리케이션에서 사용하는 오픈 소스 구성 요소와 라이브러리의 취약점을 식별하고 관리합니다. Wiz는 최신 취약점 database 정보를 유지하고 실행 가능한 수정 권장 사항을 제공합니다.
SBOM 가시성: Wiz는 추가 에이전트 없이(agentless) 포괄적인 software bill of materials(SBOM)를 생성합니다. 이를 통해 소프트웨어 공급망 내 모든 구성 요소를 완전하게 파악하고 효과적인 vulnerability management 체계를 운영할 수 있습니다.
통합: Wiz는 CI/CD pipeline, GitHub 등 기존 개발 도구 및 프로세스와 통합되므로 일상 업무에 코드 보안을 손쉽게 적용할 수 있습니다.
지속적인 모니터링: Wiz는 코드베이스를 지속적으로 모니터링하고 새로운 취약점이 발견되면 즉시 알립니다.
수정 가이드: Wiz 플랫폼은 식별된 취약점을 수정하기 위한 상세 가이드와 권장 사항을 제공해 문제를 빠르고 효율적으로 해결하도록 돕습니다.
Wiz가 cloud environment 전반을 어떻게 보호하는지 직접 확인하려면 Wiz 작동 모습 보기를 통해 데모를 신청하시기 바랍니다.
Wiz 데모로 CloudSec 혁신 시작
복잡한 클라우드 환경 전반의 취약점, 권한, 노출을 하나의 플랫폼에서 관리하는 방법을 확인하세요.
클라우드 보안 자가 진단 체크리스트
다운로드
[CTA-END]