운영 환경에서 발견된 소프트웨어 취약점을 수정하는 데 드는 비용은 개발 단계에서 발견된 취약점을 수정하는 데 드는 비용보다 평균 4배 더 높습니다. IBM의 2025년 데이터 침해 비용 보고서에 따르면 평균 침해 비용은 4.88만 달러이며, 탐지되지 않은 소스 코드 취약점에서 비롯된 침해는 근본적인 원인을 해결하기 위해 단순한 사고 대응뿐 아니라 코드베이스 수정까지 필요하기 때문에 복구 비용이 가장 많이 드는 유형 중 하나입니다. 코드 스캐닝 도구는 취약점 발견을 침해 발생 후가 아닌 개발 환경에서 최대한 조기에 할 수 있도록 지원하기 위해 존재합니다.
코드 스캐닝은 소스 코드, 컴파일된 바이너리 또는 실행 중인 애플리케이션을 자동화된 방식으로 분석하여 소프트웨어가 실제 서비스에 배포되기 전에 보안 취약점, 품질 결함, 규정 준수 위반 및 기술 부채를 식별하는 작업입니다. 이는 애플리케이션 보안의 기초를 다지는 단계로, 침투 테스트나 위협 모델링을 대체하는 것이 아니라, 사람이 대규모 환경에서 일관되게 발견하기 어려운 예측 가능하고 반복적인 오류 유형을 체계적으로 포착하는 기준선 역할을 합니다.
팀에서 배송하는 모든 언어를 스캔하세요
SMART TS XL COBOL, Java, Python, JavaScript를 비롯한 전체 포트폴리오에 걸쳐 정적 코드 스캔을 동시에 실행합니다.
자세히 알아보세요…코드 스캐닝이란 무엇인가요?
코드 스캐닝은 소프트웨어 아티팩트, 소스 코드, 바이트코드, 바이너리 또는 실행 중인 애플리케이션을 자동화된 방식으로 검사하여 모든 코드 줄을 사람이 직접 검토할 필요 없이 결함을 식별하는 기술입니다. 스캐닝 도구는 규칙 집합, 패턴 매칭, 데이터 흐름 분석을 적용하고, 더욱 정교한 도구의 경우 프로시저 간 오염 추적 기능을 활용하여 프로덕션 환경에 배포되기 전에 발견될 수 있는 문제를 찾아냅니다.
코드 스캐닝이란 무엇인가: 코드 스캐닝 은 코드 리뷰, 아키텍처 분석, 침투 테스트 또는 런타임 모니터링을 대체하는 것이 아닙니다. 코드 스캐닝은 코드베이스 전체에서 알려진 패턴을 안정적이고 일관되게 포착하는 빠르고 체계적이며 확장 가능한 1차 필터입니다. 여기에는 코드 리뷰어가 일상적인 것처럼 보여 자세히 살펴보지 않는 부분까지 포함됩니다.
이 맥락에서 코드 검증이란 코드가 명세대로 동작하는지 확인하는 것을 의미합니다 . 스캐닝은 검증의 한 구성 요소로, 패턴 감지 및 데이터 흐름 분석을 처리하는 자동화된 부분입니다. 수동 검토, 테스트 및 형식 검증은 다른 구성 요소입니다. 이 모든 요소가 함께 검증 프로그램을 구성하며, 스캐닝만으로는 충분하지 않습니다.
정적 코드 스캐닝과 동적 코드 스캐닝: 핵심적인 차이점
스캐닝 프로그램을 구축할 때 가장 중요한 선택은 각 접근 방식이 언제 실행되고 무엇을 볼 수 있는지 이해하는 것입니다.
| 외형 치수 | 정적(SAST) | 동적(DAST) |
|---|---|---|
| 실행될 때 | 소스 코드의 경우 실행이 필요하지 않습니다. | 실행 중인 애플리케이션에 대해 |
| 그것이 보는 것 | 코드 구조, 데이터 흐름, 패턴 위반 | 런타임 동작, 서버 구성, API 응답 |
| 찾기 | SQL 인젝션 패턴, 하드코딩된 비밀 키, 불안정한 암호화, 코드 스멜 | 인증 우회, 런타임 인젝션, 세션 관리 결함, 서버 구성 오류 |
| 그리워 | 런타임 전용 취약점, 설정 문제 | 테스트 중에 코드 수준 패턴이 트리거되지 않았습니다. |
| 속도 | 빠르며, 몇 초에서 몇 분 안에 실행됩니다. | 속도가 느리고, 실행 환경이 필요합니다. |
| 개발자 피드백 | 즉시, IDE 또는 사전 커밋 | 지연됨, 애플리케이션 배포 필요 |
| 오탐율 | 더 높은 레벨에서는 런타임 컨텍스트가 부족합니다. | 더 낮은 수치는 악용 가능성을 확인시켜 줍니다. |
| 최적의 통합은 다음과 같습니다. | IDE, 사전 커밋, 모든 PR에 대한 CI/CD | 스테이징 환경, 사전 릴리스 게이트 |
대부분의 팀에게 현실적인 해답은 두 가지 모두 실행하는 것입니다 . IDE와 CI 파이프라인에서 정적 스캔을 실행하면 코드 패턴에 대한 빠르고 조기적인 피드백을 얻을 수 있습니다. 스테이징 환경에 대한 동적 스캔은 취약점을 확인하고 정적 분석으로는 발견할 수 없는 구성 문제를 찾아냅니다.
코드 스캐닝의 네 가지 유형
SAST, 정적 애플리케이션 보안 테스트
SAST는 실행 없이 소스 코드, 바이트코드 또는 바이너리를 분석합니다. 이는 가장 일반적인 코드 스캐닝 방식으로, IDE 및 CI/CD 파이프라인에 통합되어 있습니다. SAST는 오염 분석(신뢰할 수 없는 입력이 위험한 곳으로 연결되는 것을 추적)을 통해 인젝션 취약점을, 패턴 매칭을 통해 암호화 방식의 오용을, 문자열 분석을 통해 하드코딩된 자격 증명을, 그리고 메트릭 및 패턴 규칙을 통해 구조적 품질 문제를 찾아냅니다.
가장 좋은 도구: Semgrep, SonarQube, Checkmarx, CodeQL, Veracode, Snyk Code, SMART TS XL.
DAST, 동적 애플리케이션 보안 테스트
DAST는 실제 애플리케이션을 대상으로 조작된 입력을 전송하고 응답을 관찰합니다. 소스 코드를 볼 수는 없으며, 공격자가 애플리케이션과 상호 작용하는 방식처럼 외부에서 접근합니다. DAST는 런타임 컨텍스트가 필요한 인증 우회, 비즈니스 로직 결함, 서버 측 요청 위조 및 구성 취약점을 SAST가 탐지할 수 없는 상황에서 찾아냅니다.
추천 도구: OWASP ZAP, Burp Suite, Invicti, Acunetix, HCL AppScan.
SCA, 소프트웨어 구성 분석
SCA는 종속성 매니페스트를 스캔합니다.package.json, pom.xml, requirements.txt, go.modSCA는 취약점 데이터베이스를 대상으로 타사 라이브러리의 알려진 CVE를 식별합니다. 모든 최신 애플리케이션은 오픈 소스 종속성을 사용합니다. SCA는 이러한 종속성이 알려진 취약점을 유발하지 않도록 보장하는 스캔 계층입니다.
추천 도구: Snyk, OWASP Dependency-Check, Mend(이전 WhiteSource), GitHub Dependabot, npm audit.
IAST, 대화형 애플리케이션 보안 테스트
IAST는 애플리케이션 서버에 내장된 에이전트 또는 센서를 사용하여 런타임에 애플리케이션을 계측합니다. 애플리케이션 내부에서 실제 요청 처리를 관찰하여 DAST의 런타임 정확도와 SAST의 코드 수준 통찰력을 결합합니다. IAST는 네 가지 유형 중 오탐률이 가장 낮지만 계측된 배포 환경이 필요합니다.
최적의 도구: Contrast Security, Seeker(Synopsys), HCL IAST.
이들을 결합하는 방법: 빠른 개발자 피드백을 위해 모든 커밋에 대해 SAST를 실행합니다. 모든 종속성 변경에 대해 SCA를 실행합니다. 모든 릴리스 전에 스테이징 환경에 대해 DAST를 실행합니다. 오탐률을 최소화해야 하는 중요 애플리케이션에는 IAST를 추가합니다.
코드 스캐닝으로 실제로 발견하는 것
스캔 유형에 따라 탐지하는 취약점 유형이 다릅니다. 이 매핑을 통해 팀은 특정 위험 프로필에 맞는 스캐너를 선택하는 방법을 파악할 수 있습니다.
| 취약점 범주 | SAST | 마지막 | SCA | IAST |
|---|---|---|---|---|
| SQL 인젝션 | 강력함(오염 분석) | 강력한 (적극적인 테스트) | 아니 | 강한 |
| XSS | 보통 | 강한 | 아니 | 강한 |
| 하드코딩된 비밀/자격 증명 | 강력한 (패턴 매칭) | 아니 | 일부의 | 아니 |
| 깨진 인증 | 부분적 (패턴만) | 강한 | 아니 | 강한 |
| 취약한 종속성(CVE) | 아니 | 아니 | 강한 | 아니 |
| 암호화 오용 | 강력한 (알려진 악성 API) | 아니 | 일부의 | 일부의 |
| 보안 설정 오류 | 부분적 (코드 내 설정) | 강한 | 아니 | 일부의 |
| SSRF | 강력함(오염 분석) | 강한 | 아니 | 강한 |
| 경로 탐색 | 강한 | 보통 | 아니 | 강한 |
| 명령 주입 | 강력함(오염 분석) | 강한 | 아니 | 강한 |
| 코드 품질 / 기술적 부채 | 강한 | 아니 | 아니 | 아니 |
| 데드 코드 | 강한 | 아니 | 아니 | 아니 |
SDLC에서의 코드 스캐닝: 언제 무엇을 실행해야 할까요?
보안에서 취약점 탐지를 개발 초기 단계로 옮기는 '시프트 레프트(shift-left)' 원칙 때문에 코드 스캐닝이 표준 관행이 되었습니다. 개발자 IDE에서 SQL 인젝션을 발견하면 수정하는 데 몇 분밖에 걸리지 않습니다. 하지만 실제 운영 환경에서 침해 사고가 발생한 후 이를 발견하면 사고 대응, 복구 및 규제 보고에 몇 주가 소요됩니다.
IDE에서는 SonarLint, Snyk IDE 확장 프로그램, Semgrep IDE 플러그인이 개발자가 코드를 작성하는 동안 취약점을 즉시 표시해 줍니다. 취약한 줄이 작성될 때 나타나는 SQL 인젝션 플래그를 수정하는 데는 몇 초밖에 걸리지 않습니다.
사전 커밋 훅: 코드가 저장소에 도달하기 전에 빠른 SAST 규칙 및 비밀 키 감지를 실행합니다. 사전 커밋 훅은 10초 이내에 완료되어야 하며, 그렇지 않으면 개발자가 비활성화할 수 있습니다.
모든 풀 리퀘스트에 대해 전체 SAST 스캔 및 SCA 검사를 수행합니다. 대부분의 팀은 이 단계에서 품질 게이트를 적용하여 새로운 중요 취약점이 발견될 경우 병합을 차단합니다.
매일 밤 또는 매주: 심층적인 프로시저 간 분석, 전체 DAST 스캔, 포괄적인 SCA 감사를 수행합니다. 이러한 작업은 커밋별 실행에는 너무 느리지만 메인 브랜치에서 정기적으로 실행됩니다.
완전한 CI/CD 스캔 구성:
얌
# GitHub Actions: layered scanning at the right pipeline stage
name: Code Scanning Pipeline
on:
push:
branches: [main, develop]
pull_request:
jobs:
sast:
name: Static Analysis
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Semgrep SAST scan
uses: semgrep/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/security-audit
p/secrets
- name: SonarCloud quality gate
uses: SonarSource/sonarcloud-github-action@master
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
sca:
name: Dependency Scan
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Snyk dependency check
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high
secrets:
name: Secret Detection
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: TruffleHog secret scan
uses: trufflesecurity/trufflehog@main
with:
extra_args: --only-verified코드 스캐닝 도구: 실용적인 개요
| 수단 | 타입 | 지원 기기 | 오픈 소스 |
|---|---|---|---|
| 셈그렙 | SAST | 사용자 지정 규칙, 빠른 스캔, 다국어 지원 | 예 (커뮤니티 규칙) |
| 소나큐브 / 소나클라우드 | SAST | 품질 및 보안, CI/CD 통합, 트렌드 추적 | 커뮤니티 에디션 |
| CodeQL | SAST | 심층 의미 분석, GitHub 네이티브 | 가능 |
| 체크 마크스 | SAST | 기업용 애플리케이션 보안 프로그램, 규정 준수 | 아니 |
| Snyk 코드 | SAST | 개발자 친화적이고 IDE 우선의 보안 | 프리미엄 (Freemium) |
| OWASP 잽 | 마지막 | 무료 DAST, CI/CD 호환 | 가능 |
| Burp 스위트 | 마지막 | 수동 및 자동화 웹 애플리케이션 보안 테스트 | 커뮤니티 에디션 |
| 스닉 / 멘드 | SCA | 의존성 취약점 관리 | 프리미엄 (Freemium) |
| OWASP 종속성 검사 | SCA | 오픈소스 종속성 CVE 스캐닝 | 가능 |
| 대비 보안 | IAST | 실행 정확도, 낮은 오탐률 | 아니 |
| SMART TS XL | SAST + 구조 | 다국어, COBOL, 엔터프라이즈, 레거시 | 아니 |
효과적인 코드 스캐닝을 위한 모범 사례
신뢰도가 높고 노이즈가 적은 규칙부터 시작하세요. 첫날부터 사용 가능한 모든 규칙 세트를 실행하면 수천 건의 탐지 결과가 발생하여 개발자에게 부담을 주고 도입을 저해합니다. 심각도와 신뢰도가 높은 엄선된 규칙 세트(OWASP Top 10 패턴, 비밀 키 탐지, 알려진 위험한 함수 호출 등)로 시작하세요. 팀이 도구 사용에 대한 자신감을 쌓아감에 따라 규칙을 점진적으로 추가하세요.
새로운 코드에만 적용하세요. 기존에 보안 취약점이 있는 레거시 코드베이스의 경우, 현재 PR에서 발생한 취약점(전체 코드베이스가 아닌)에 대해서만 품질 게이트를 설정하여 보안 검사를 워크플로에 포함시키면, 기존에 발견된 취약점으로 인해 모든 개발이 중단되는 백로그를 만들지 않고도 보안 검사를 수행할 수 있습니다.
얌
# SonarQube: new-code quality gate configuration
# Block merges on new critical security hotspots only
sonar.qualitygate.wait=true
sonar.newCode.referenceBranch=main
# Existing findings in main don't block PRs
# Only new findings in the PR diff are gated오탐을 체계적으로 조정하세요. 개발자가 한 번 조사하고 무시하는 오탐은 성가신 존재일 뿐입니다. 하지만 6개월 동안 모든 PR에서 오탐이 발생하면 개발자는 발견된 내용을 완전히 무시하게 됩니다. 경고 억제 검토 프로세스를 구축하세요. 모든 경고 억제에는 문서화된 정당성이 필요하며, 경고 억제는 분기별로 검토됩니다.
조사 결과를 심각도 단계별로 분류하세요. 모든 조사 결과에 즉각적인 조치가 필요한 것은 아닙니다. 단계별 대응 방안을 적용하세요.
- 결정적인 (CVSS 9+, 취약점 확인됨): 배포 차단, 24시간 내 수정
- 높음 (CVSS 7-8): PR 병합 차단, 스프린트 내 수정
- 중급백로그에 추가, 분기 내 처리 예정
- 낮음 / 정보 제공: 리팩토링 중 추적 및 주소 지정
중요한 것을 측정하세요. 심각도 등급별 평균 해결 시간(MTTR), 스프린트별 발견된 문제 대비 해결된 문제 비율, 그리고 시간 경과에 따른 오탐률을 추적하세요. 이러한 지표는 스캐너가 실행 중인지 여부가 아니라 스캔 프로그램이 제대로 작동하는지 여부를 알려줍니다.
코드 스캐닝으로 기술 부채를 방지하는 방법
기술 부채는 품질 문제가 지연될 때, 예를 들어 개발 단계에서 SAST 규칙으로 탐지할 수 있었던 SQL 인젝션 패턴이 프로덕션 환경에 배포되어 보안 패치, 회귀 테스트 및 배포 조정이 필요하게 될 때 발생합니다. 코드 스캐닝 도구는 이러한 기술 부채 누적을 원천적으로 차단합니다.
코드 스캐닝과 기술 부채 감소를 직접적으로 연결하는 세 가지 메커니즘이 있습니다.
복잡성 감지. 임계값 이상의 순환 복잡도, 깊게 중첩된 조건문, 그리고 긴 함수는 코드 스멜로 분류됩니다. 이러한 패턴들을 방치하면 코드베이스는 점점 더 변경하기 어려워지고 비용도 많이 들게 됩니다. 코드 스캐닝은 복잡성이 구조적인 문제로 발전하기 전에 리팩토링을 유도하는 지표 기반의 조기 경고를 제공합니다.
코드 중복 감지. 중복 코드는 가장 비용이 많이 드는 기술 부채 중 하나입니다. 모든 버그 수정 및 기능 변경 사항은 여러 곳에 적용되어야 하며, 복사본은 필연적으로 서로 다르게 됩니다. SonarQube의 코드 중복 감지 및 유사 규칙은 코드베이스 전체에서 이러한 패턴을 찾아내어, 불일치가 발생하기 전에 코드를 통합할 수 있도록 지원합니다.
데드 코드 식별. 데드 코드는 실제 운영 환경에서 전혀 호출되지 않는 함수와 모듈로, 코드베이스 크기를 증가시키고 개발자를 혼란스럽게 하며 마이그레이션 분석을 복잡하게 만듭니다. 도달 가능성 분석을 수행하는 스캐닝 도구는 데드 코드를 체계적으로 식별하여 더 이상 누적되기 전에 제거할 수 있도록 합니다.
복합적인 효과: 지속적인 스캔을 받는 코드베이스는 스캔을 하지 않는 유사한 코드베이스에 비해 결함 밀도, 순환 복잡도, 중복률, 사용되지 않는 코드 비율이 낮습니다. 이러한 지표는 기능 개발 속도 향상, 유지 관리 비용 절감, 운영 환경 장애 위험 감소로 직결됩니다.
방법 SMART TS XL 기업 규모의 코드 스캐닝 기능을 제공합니다.
표준 코드 스캔 도구는 단일 언어 내에서만 작동합니다. 자바 서비스, 파이썬 파이프라인, COBOL 배치 프로그램, JCL 작업 스트림, RPG 모듈 등이 공존하는 엔터프라이즈 환경에서는 각 언어별로 고유한 구성과 결과 대시보드를 갖춘 자체 스캐너가 필요하기 때문에 코드 스캔 환경이 파편화됩니다.
SMART TS XL의 정적 코드 분석 COBOL, JCL, Java, Python, RPG, PL/I, SQL 및 최신 스택을 포함한 환경 내 모든 언어를 동시에 스캔하여 단일 분석 과정에서 전체 포트폴리오에 걸쳐 통합된 품질 지표, 보안 결과 및 구조적 데이터를 생성합니다. 레거시 메인프레임 애플리케이션과 최신 클라우드 서비스를 함께 사용하는 조직의 경우, 이러한 언어 간 호환성은 최신 스택만 스캔하는 프로그램과 전체 시스템을 스캔하는 프로그램의 차이를 만들어냅니다.
애플리케이션 종속성 매핑 기능은 개별 파일 스캔을 넘어 아키텍처 분석까지 확장합니다. 어떤 구성 요소의 결합도가 가장 높은지, 순환 종속성이 존재하는지, 어떤 프로그램이 명시적인 API가 아닌 암시적인 파일 인터페이스를 통해 데이터를 공유하는지 등을 파악할 수 있습니다. 이러한 구조적 분석 결과는 단일 파일 패턴 매칭 도구로는 감지할 수 없는 아키텍처 보안 및 품질 문제를 해결해 줍니다.
영향 분석 기능을 통해 스캔 결과를 대규모로 실행 가능한 조치로 전환할 수 있습니다. 예를 들어 150개 프로그램이 의존하는 고빈도 구성 요소에서 취약점이 발견되면 영향 분석을 통해 수정 작업의 범위를 정의하고, 테스트해야 할 프로그램, 업데이트해야 할 호출자, 수정 사항의 전체 영향 범위를 파악할 수 있습니다. 이를 통해 취약점 발견 사항을 문제 목록에서 명확한 범위가 정의된 구조화된 수정 프로그램으로 변환할 수 있습니다.
엔터프라이즈 검색 기능을 통해 전체 포트폴리오에서 스캔 결과를 쿼리할 수 있습니다. 특정 보안 취약 API를 사용하는 모든 프로그램, 하드코딩된 자격 증명이 포함된 모든 파일, 복잡성 임계값을 초과하는 모든 구성 요소를 수백만 줄의 코드와 다양한 언어 조합에서 단 몇 초 만에 찾을 수 있습니다.
팀을 관리하는 경우 레거시 현대화 프로그램 SMART TS XL스캐닝을 통해 마이그레이션 전 품질 기준선을 제공합니다. 여기에는 마이그레이션 범위에서 제외된 사용되지 않는 코드, 마이그레이션 순서를 결정하는 복잡성 분포, 변환된 코드를 클라우드 인프라에 배포하기 전에 해결해야 하는 보안 문제가 포함됩니다.
일찍 스캔하고, 지속적으로 스캔하고, 모든 것을 스캔하세요.
보안 취약점 해결에 걸리는 평균 시간이 가장 짧은 조직은 가장 적극적인 침투 테스트 프로그램을 운영하는 조직이 아닙니다. 오히려 코드 리뷰 단계에 도달하기 전, 개발자의 IDE에서, 또는 커밋 전 단계에서, 혹은 CI/CD 파이프라인에서 가장 많은 취약점을 발견하는 조직입니다. 코드 스캐닝이 바로 이러한 작업을 대규모로 수행하는 방법입니다.
스캐닝 프로그램을 구축한다는 것은 위험 프로필에 맞는 SAST, DAST, SCA, IAST를 적절히 조합하고, 개발 수명주기의 적절한 시점에 통합하고, 커버리지를 희생하지 않고 노이즈를 최소화하도록 조정하고, 스캐너가 실행 중이라고 가정하는 것이 아니라 시간이 지남에 따라 프로그램의 효과를 측정하는 것을 의미합니다. 스캐너가 실행되는 것은 시작일 뿐이며, 프로그램이 제대로 작동하는 것이 목표입니다.
