SAST: 정적 코드 분석이란 무엇입니까?
SAST(정적 애플리케이션 보안 테스트) 그리고 그 내용을 조사하는 분석기법 소스 코드를 실행하지 않고 보안 취약점을 나타내는 패턴을 찾습니다. 실행 중인 애플리케이션이 필요한 동적 테스트와 달리 SAST는 코드에서 직접적으로 개발 초기 단계에서 문제를 식별할 수 있습니다.
SAST는 SQL 주입, XSS(교차 사이트 스크립팅) 등의 취약점에 대한 코드를 분석합니다. 버퍼 오버플로, 하드코딩된 자격 증명, 안전하지 않은 역직렬화 등이 있습니다. SAST 도구 코드 모델(AST - Abstract Syntax Tree)을 구축하고 보안 규칙을 적용합니다. 문제가 있는 패턴을 식별합니다.
이 기사에서는 주요 SAST 도구와 이를 파이프라인에 통합하는 방법을 살펴보겠습니다. 가장 일반적인 문제 중 하나인 오탐을 관리하기 위한 CI/CD 및 전략입니다.
무엇을 배울 것인가
- SAST 작동 방식 및 DAST와 IAST의 차이점
- CI/CD 파이프라인에서 SonarQube, Semgrep 및 CodeQL 구성
- Semgrep에 대한 사용자 정의 규칙 작성
- 오탐지 관리 및 결과 우선순위 지정
- 즉각적인 피드백을 위해 SAST를 IDE에 통합하세요.
- 품질 게이트 및 배포 차단 임계값
SAST vs DAST vs IAST: 차이점
올바른 도구를 선택하려면 세 가지 접근 방식의 차이점을 이해하는 것이 중요합니다. 보안 테스트 원칙:
보안 테스트 접근 방식 비교
| 특성 | SAST | DAST | IAST |
|---|---|---|---|
| 복수 | 소스 코드(화이트박스) | 애플리케이션 실행(블랙박스) | 에이전트가 있는 런타임(회색 상자) |
| 언제 | 개발 중 CI에서 | 준비/사전 제작 중 | 기능 테스트 중 |
| 적용 범위 | 모든 코드, 심지어 도달할 수 없는 코드 | HTTP를 통해 접근 가능한 부분만 | 테스트 중에 실행된 코드 |
| 거짓 긍정 | 중간 높음 | 베이스 | 매우 낮음 |
| 속도 | 빠르게(분) | 느림(시간) | 테스트에 따라 다릅니다 |
최적의 접근 방식 및 사용 세 가지 모두 보완적인 방식으로: SAST for 개발 중 신속한 피드백, 런타임 보안을 검증하는 DAST, 테스트 중 정확한 상관 관계.
SonarQube: 종합적인 코드 품질 분석
소나큐브 400,000개 이상의 조직에서 사용되는 가장 인기 있는 SAST 플랫폼입니다. 보안 외에도 코드 품질, 코드 냄새, 중복 및 테스트 범위를 분석합니다. 커뮤니티 버전은 오픈 소스이며 30개 이상의 프로그래밍 언어를 포함합니다.
Docker Compose를 사용하여 설정
로컬 또는 스테이징 환경에서 SonarQube를 시작하는 가장 빠른 방법 도커 작성:
# docker-compose.sonarqube.yml
version: "3.8"
services:
sonarqube:
image: sonarqube:lts-community
container_name: sonarqube
ports:
- "9000:9000"
environment:
- SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonarqube
- SONAR_JDBC_USERNAME=sonar
- SONAR_JDBC_PASSWORD=sonar_password
volumes:
- sonarqube_data:/opt/sonarqube/data
- sonarqube_logs:/opt/sonarqube/logs
- sonarqube_extensions:/opt/sonarqube/extensions
depends_on:
- db
db:
image: postgres:15
container_name: sonarqube-db
environment:
- POSTGRES_USER=sonar
- POSTGRES_PASSWORD=sonar_password
- POSTGRES_DB=sonarqube
volumes:
- postgresql_data:/var/lib/postgresql/data
volumes:
sonarqube_data:
sonarqube_logs:
sonarqube_extensions:
postgresql_data:
GitHub Actions에 통합
GitHub Actions를 사용하여 SonarQube를 CI/CD 파이프라인에 통합하면 다음을 실행할 수 있습니다. 푸시 또는 풀 요청이 있을 때마다 자동으로 분석됩니다.
# .github/workflows/sonarqube.yml
name: SonarQube Analysis
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
sonarqube:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: SonarQube Scan
uses: SonarSource/sonarqube-scan-action@v3
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
- name: SonarQube Quality Gate
uses: SonarSource/sonarqube-quality-gate-action@v1
timeout-minutes: 5
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
Semgrep: 가볍고 사용자 정의 가능한 정적 분석
셈그렙 Return Security(현재 Semgrep Inc.)에서 만든 오픈 소스 SAST 도구 이는 사용자 정의 규칙을 생성하는 단순성이 두드러집니다. SonarQube와는 다르게 서버가 필요한 Semgrep은 간단한 명령줄 도구로 실행할 수 있습니다.
Semgrep의 강력한 기능은 다음을 작성할 수 있는 패턴 일치 언어에 있습니다. 찾고 싶은 코드를 작성하는 것과 거의 비슷합니다.
사용자 정의 Semgrep 규칙 작성
다음은 Python 애플리케이션에서 SQL 주입을 감지하는 Semgrep 규칙의 예입니다.
# .semgrep/sql-injection.yml
rules:
- id: python-sql-injection
patterns:
- pattern: |
cursor.execute($QUERY)
- pattern-not: |
cursor.execute($QUERY, $PARAMS)
- metavariable-pattern:
metavariable: $QUERY
patterns:
- pattern: |
f"..."
message: >
Possibile SQL injection: la query SQL utilizza f-string
invece di parametri preparati. Usa cursor.execute(query, params)
con placeholder %s per prevenire injection.
severity: ERROR
languages: [python]
metadata:
cwe:
- "CWE-89: Improper Neutralization of Special Elements"
owasp:
- "A03:2021 - Injection"
confidence: HIGH
CI/CD 통합
Semgrep은 모든 CI/CD 파이프라인에 쉽게 통합됩니다. 다음은 설정입니다. GitHub 작업:
# .github/workflows/semgrep.yml
name: Semgrep Security Scan
on:
push:
branches: [main]
pull_request:
jobs:
semgrep:
runs-on: ubuntu-latest
container:
image: semgrep/semgrep
steps:
- uses: actions/checkout@v4
- name: Run Semgrep
run: |
semgrep scan \
--config auto \
--config .semgrep/ \
--sarif --output semgrep-results.sarif \
--error \
--severity ERROR
- name: Upload SARIF
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: semgrep-results.sarif
CodeQL: GitHub의 의미 분석
CodeQL 코드를 데이터로 처리하는 GitHub에서 개발한 분석 엔진 의심스럽다. 패턴 일치를 사용하는 Semgrep과 달리 CodeQL은 데이터베이스를 구축합니다. 관계형 코드를 사용하여 취약점을 찾기 위한 복잡한 쿼리를 작성할 수 있습니다.
CodeQL은 분석에 탁월합니다. 오염 추적: 흐름을 따라가는 능력 사용자 입력(소스)부터 민감한 작업(싱크)까지의 데이터를 확인하여 데이터가 도중에 소독됩니다.
CodeQL: 주요 이점
- GitHub의 공개 저장소에는 무료
- 오염 추적을 통한 심층 의미 분석
- GitHub Security Lab에서 확장 및 유지 관리하는 규칙 커뮤니티
- GitHub Advanced Security와의 기본 통합
- QL 언어의 사용자 정의 쿼리 지원
오탐지 관리
SAST 도구의 가장 큰 문제 중 하나는 거짓 긍정: 실제로 존재하지 않는 취약점을 보고하는 경고입니다. 오탐지 비율도 높으면 도구에 대한 팀의 신뢰가 약화되고경고 피로, 어디서 개발자는 모든 경고를 무시하기 시작합니다.
거짓 긍정을 줄이기 위한 전략
- 규칙 조정: 애플리케이션 컨텍스트와 관련이 없는 규칙을 비활성화합니다.
- 타겟 제외: 생성된 파일, 테스트, 공급업체 코드 제외
- 기준선: 기준선을 설정하고 새로운 결과에만 집중
- 우선순위: CRITICAL 및 HIGH 심각도에 먼저 초점을 맞춥니다.
- 억제 코멘트: 문서화된 설명으로 오탐지를 표시합니다.
# Esempio di suppression in codice Python
import hashlib
# Questo uso di MD5 e per checksum, non per sicurezza
# nosemgrep: python-weak-hashing
file_hash = hashlib.md5(file_content).hexdigest() # noqa: S303
# Esempio di suppression per SonarQube
password = get_env("DB_PASSWORD") # NOSONAR - password da env var, non hardcoded
품질 게이트: 배포를 차단해야 하는 경우
Un 품질게이트 코드가 요구하는 최소 품질 및 안전 임계값을 정의합니다. 석방되려면 준수해야 합니다. 그리고 도구에서 SAST를 변환하는 메커니즘 파이프라인의 차단 게이트에 대한 정보를 제공합니다.
품질 게이트 권장
| 미터법 | 임계값 | 행동 |
|---|---|---|
| 심각한 취약점 | 0 | 블록 배포 |
| 높은 취약성 | 0(새 코드) | 블록 배포 |
| 중간 정도의 취약성 | 최대 5개(신규 코드) | 경고, 검토가 요청됨 |
| 보안 핫스팟 | 100% 리뷰됨 | 검토되지 않으면 차단 |
| 코드 적용 범위 | 최소 80%(새 코드) | 경고 |
IDE의 SAST: 즉각적인 피드백
가장 효과적인 왼쪽 이동 방법은 SAST 분석을 개발자의 IDE로 직접 가져오는 것입니다. 이를 통해 코드를 작성하는 동안 취약점을 찾아 수정할 수 있습니다. 커밋하기 전에도.
- SonarLint: IntelliJ, VS Code, Eclipse용 플러그인. 규칙을 동기화하기 위해 SonarQube에 연결됨
- Semgrep VS 코드 확장: 편집기에서 직접 결과를 강조표시합니다.
- GitHub 코파일럿: 상황에 맞는 보안 수정 사항을 제안합니다.
IDE에 통합하면 피드백 루프가 몇 분(CI/CD)에서 몇 초로 줄어들어 개발자가 문제를 즉시 수정할 가능성이 크게 높아집니다.
SAST 모범 사례
여러 기업 프로젝트에서 SAST를 구현한 후 얻은 모범 사례는 다음과 같습니다. 우리는 다음을 권장합니다:
- 비차단 모드로 시작: 처음 2~4개의 스프린트에서는 SAST는 배포를 차단하지 않고 보고서만 생성합니다. 이를 통해 팀은 도구에 익숙해질 수 있습니다.
- 기준선 설정: 기존 발견의 수를 기록하고 점진적인 감소에 중점을 둡니다.
- 새로운 코드에 집중하세요: 팀이 레거시 기술 부채에 갇히는 것을 방지하기 위해 새로운 코드에만 엄격한 임계값을 적용합니다.
- 컨텍스트에 대한 사용자 정의 규칙: 애플리케이션 패턴과 관련된 Semgrep/CodeQL 규칙 생성
- 결과에 대한 주간 검토: Security Champion과 함께 SAST 결과를 분류하는 데 매주 1~2시간을 할애합니다.
- 측정항목 및 추세: 시간 경과에 따른 MTTR, 오탐률, 취약성 밀도 추적
결론
SAST는 DevSecOps 패러다임의 첫 번째 방어 계층입니다. 취약점 식별 소스 코드가 실행되기 전에 시간, 비용, 위험을 절약할 수 있습니다. 성공의 열쇠는 적용 범위와 유용성 사이의 균형입니다. 너무 많은 규칙이 생성됩니다. 경고 피로도가 너무 낮아 심각한 취약점이 통과됩니다.
다음 기사에서는 살펴보겠습니다. DAST(동적 애플리케이션 보안 테스트), 실행 중인 애플리케이션을 분석하여 다음을 찾는 SAST의 자연스러운 보완물 XSS, CSRF 및 잘못된 구성과 같은 런타임 취약점.