CVE

📊 Open Source Security: CVE·Advisory·Malware 1년간 트렌드 분석

서론

지난주 한 핀테크 스타트업의 보안팀이 긴급 회의를 소개했습니다. 원인은 단 하나였습니다. 프로덕션 환경에 배포된 ua-parser-js 패키지가 악성코드에 감염된 버전으로 교체되었고, 이를 감지하지 못한 채 3일간 운영되었습니다. 다행히 민감 데이터 유출은 없었지만, 이 사건은 오픈소스 공급망(Supply Chain) 공격이 더 이상 “남의 일"이 아님을 보여줍니다.

GitHub이 최근 공개한 연간 보안 리포트는 이러한 현실을 데이터로 증명합니다. 지난 1년간 CVE 등록 건수는 전례 없는 증가세를 보였고, 보안 권고(Advisory) 데이터베이스는 하루 평균 30개 이상의 새로운 취약점이 등록되고 있습니다. 더 우려되는 점은 악성코드(Malware)가 오픈소스 패키지 저장소를 통해 유포되는 패턴이 정교해지고 있다는 것입니다.

이 글에서는 GitHub 리포트를 기반으로 지난 1년간 오픈소스 보안 트렌드를 분석하고, DevSecOps 관점에서 당장 적용 가능한 대응 전략을 제시합니다. 데이터 기반의 인사이트를 통해 조직의 공급망 보안 체계를 점검해보시기 바랍니다.

오픈소스 보안 위협의 현주소

CVE 등록 현황: 폭발적 증가의 의미

2023~2024년 CVE 등록 건수는 역대 최고치를 기록했습니다. MITRE CVE 데이터베이스에 따르면 연간 약 40,000개 이상의 새로운 CVE가 등록되고 있으며, 이 중 상당수가 오픈소스 컴포넌트와 관련되어 있습니다.

1
2
3
4
5
6
7
8

graph LR
    A[개발자 코드 작성] --> B[오픈소스 의존성 추가]
    B --> C[패키지 매니저 설치]
    C --> D[빌드 및 배포]
    D --> E[프로덕션 환경]
    B --> F[취약점 스캔 미실시]
    F --> G[악성 패키지 포함 가능성]
    G --> E

이 다이어그램이 보여주는 핵심은 의존성 추가 시점에서 보안 검증이 누락되면 프로덕션까지 위험이 전파된다는 것입니다. GitHub 리포트에 따르면 전체 오픈소스 프로젝트의 약 96%가 외부 의존성을 포함하고 있으며, 평균적인 의존성 깊이(Dependency Depth)는 7~8단계에 달합니다.

Advisory 데이터베이스 성장세

GitHub Advisory Database는 CVE, NVD, 그리고 커뮤니티 제보를 종합한 권고 사항을 제공합니다. 지난 1년간 주요 트렌드를 정리하면 다음과 같습니다.

| 지표 | 2022-2023 | 2023-2024 | 변화율 | | :— | :— | :— | :— | | 신규 Advisory 등록 | 약 12,000건 | 약 18,000건 | +50% | | 평균 CVSS 7.0+ 비율 | 23% | 31% | +8%p | | 평균 패치 공개 소요시간 | 14일 | 9일 | -5일 | | Malware 관련 Advisory | 180건 | 420건 | +133% |

CVSS 7.0 이상의 고위험 취약점 비율이 증가한 반면, 패치 공개까지의 소요시간은 단축되었습니다. 이는 보안 커뮤니티의 대응 속도가 빨라지고 있음을 시사하지만, 동시에 공격자들도 이를 역이용하고 있음을 의미하기도 합니다.

공급망 공격의 진화: Malware 유포 패턴 분석

주요 공격 벡터 3가지

GitHub의 분석에 따르면 오픈소스 생태계 내 악성코드 유포는 크게 세 가지 패턴으로 구분됩니다.

1. Typosquatting (오타 위장) 인기 패키지와 유사한 이름을 등록하여 실수로 설치하는 것을 유도합니다. 예를 들어 react-native 대신 react-nativ를 설치하도록 유도하는 방식입니다.

2. Dependency Confusion (의존성 혼동) 기업 내부 패키지와 동일한 이름으로 공용 저장소에 악성 패키지를 등록합니다. npm이나 pip의 기본 설정이 공용 저장소를 먼저 검색하는 특성을 악용합니다.

3. 패키지 하이재킹 (Package Hijacking) 기존 인기 패키지의 유지보수자 계정을 탈취하여 악성 코드를 주입합니다. event-stream 사건이 대표적인 사례입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

graph TD
    A[공격자] --> B[Typosquatting]
    A --> C[Dependency Confusion]
    A --> D[Package Hijacking]
    B --> E[유사 이름 패키지 등록]
    C --> F[내부 패키지명 도용]
    D --> G[유지보수자 계정 탈취]
    E --> H[개발자 실수 설치]
    F --> H
    G --> I[기존 패키지에 악성코드 주입]
    I --> H
    H --> J[시스템 감염]

실제 탐지 사례: 난독화된 악성코드

최근 발견된 악성 패키지들은 단순한 난독화를 넘어 다단계 페이로드 구조를 사용합니다. 다음은 실제 악성 패키지에서 발견된 패턴을 단순화한 예시입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 악성 패키지의 위장된 초기화 코드 패턴
const _0x4a2f = ['join', 'charCodeAt', 'toString', 'split'];

function _0x3e8c(_0x2d9fx1) {
    const _0x2d9fx2 = _0x2d9fx1['split']('');
    const _0x2d9fx3 = _0x2d9fx2['map']((_0x2d9fx4) => {
        return _0x2d9fx4['charCodeAt'](0);
    });
    // 디코딩 후 외부 서버와 통신
    const _0x2d9fx5 = Buffer['from'](_0x2d9fx3)['toString']();
    return _0x2d9fx5;
}

// 설치 후 실행되는 postinstall 스크립트에서 호출
// 실제로는 더 복잡한 다단계 구조 사용

이 코드는 실행 시 난독화된 문자열을 디코딩하여 외부 명령(Command & Control) 서버와 통신합니다. 정적 분석만으로는 악의적인 의도를 파악하기 어렵게 설계되어 있습니다.

위험도 평가: CVSS vs SSVC

기존 CVSS의 한계

CVSS(Common Vulnerability Scoring System)는 취약점 심각도를 평가하는 표준이지만, 오픈소스 공급망 공격에는 완벽하지 않습니다. CVSS는 기술적 영향도에 집중하는 반면, 실제 악용 가능성이나 비즈니스 영향도는 반영하지 않기 때문입니다.

| 평가 기준 | CVSS v3.1 | SSVC | | :— | :— | :— | | 평가 주체 | NIST/CVE 기관 | CISA/벤더/사용자 | | 주요 초점 | 기술적 영향도 | 악용 가능성 + 비즈니스 영향 | | 패치 우선순위 | 점수 기준 | 의사결정 트리 기반 | | 공급망 특성 반영 | 제한적 | 직접 반영 | | 자동화 적합성 | 높음 | 중간 (컨텍스트 필요) |

SSVC 기반 의사결정 프로세스

SSVC(Stakeholder-Specific Vulnerability Categorization)는 CVSS의 한계를 보완하기 위해 개발된 새로운 평가 프레임워크입니다. 특히 공급망 공격과 관련하여 다음 4가지 차원을 평가합니다.

1
2
3
4
5
6

graph LR
    A[취약점 발견] --> B[Exploitation 상태]
    B --> C[Automatable 여부]
    C --> D[시스템 중요도]
    D --> E[사용자 영향]
    E --> F[의사결정: Schedule/Out-of-Band/IMMEDIATE]

이 프로세스를 통해 단순한 점수가 아닌, 조직의 컨텍스트를 반영한 패치 우선순위를 결정할 수 있습니다.

실무 적용: Step-by-Step 가이드

1단계: 의존성 매핑 및 인벤토리 구축

첫 번째 단계는 현재 프로젝트의 모든 의존성을 파악하는 것입니다. 다음은 npm 기준으로 의존성 트리를 분석하는 방법입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 의존성 트리 전체 출력
npm list --all --json > dependency-tree.json

# 중복 의존성 및 버전 충돌 확인
npm dedupe --dry-run

# 알려진 취약점 스캔
npm audit --json > audit-report.json

# SBOM (Software Bill of Materials) 생성
# CycloneDX 포맷 사용
npx @cyclonedx/cyclonedx-npm --output-file sbom.xml

생성된 SBOM은 향후 취약점이 발견되었을 때 영향 범위를 신속하게 파악하는 데 필수적입니다.

2단계: 자동화된 보안 게이트 구축

CI/CD 파이프라인에 보안 게이트를 통합하여 취약한 패키지의 배포를 사전에 차단합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# GitHub Actions 예시: 보안 스캔 게이트
name: Security Gate

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high
          allow-licenses: MIT, Apache-2.0, BSD-3-Clause
      
      - name: Run Snyk Security Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high --fail-on=all
      
      - name: Check for Malicious Packages
        run: |
          npx socket scan --json > socket-report.json
          # 악성 패키지 탐지 시 CI 실패
          if grep -q '"malicious": true' socket-report.json; then
            echo "Malicious package detected!"
            exit 1
          fi

3단계: 패키지 출처 검증

패키지의 출처와 무결성을 검증하는 메커니즘을 도입합니다. npm의 provenance 기능과 Sigstore를 활용할 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# npm provenance 확인
npm audit signatures

# 특정 패키지의 provenance 정보 조회
npm view <package-name> --json | jq '.dist.attestations'

# Sigstore를 통한 서명 검증 (cosign 설치 필요)
cosign verify <registry>/<image>@<digest> \
  --certificate-identity=<expected-identity> \
  --certificate-oidc-issuer=<expected-issuer>

4단계: 지속적 모니터링 및 대응 체계

일회성 스캔으로는 부족합니다. 이미 배포된 의존성에 대해 새로운 취약점이 공개될 때 즉시 알림을 받을 수 있는 체계가 필요합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

graph TD
    A[의존성 인벤토리] --> B[취약점 DB 구독]
    B --> C[새로운 CVE 공개]
    C --> D[자동 매칭]
    D --> E{영향 받는 패키지 존재?}
    E -->|Yes| F[Slack/PagerDuty 알림]
    E -->|No| G[로그 기록]
    F --> H[JIRA 티켓 자동 생성]
    H --> I[패치 우선순위 할당]
    I --> J[패치 적용 및 검증]

이 흐름을 구현하기 위해 다음과 같은 도구 조합을 추천합니다:

| 기능 | 도구 | 특징 | | :— | :— | :— | | 취약점 DB | GitHub Advisory, OSV | 오픈소스, API 제공 | | 모니터링 | Dependabot, Renovate | PR 자동 생성 | | 알림 | Slack Webhook, OpsGenie | 실시간 알림 | | SBOM 관리 | Dependency-Track, GUAC | 중앙화된 추적 |

Malware 탐지 심화: 정적 vs 동적 분석

정적 분석의 한계와 보완

정적 분석(Static Analysis)은 코드를 실행하지 않고 패턴을 분석합니다. 빠르고 자동화에 유리하지만, 난독화된 악성코드는 탐지하기 어렵습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# 정적 분석 기반 악성 패키지 탐지 예시
import ast
import re

def detect_suspicious_patterns(package_path):
    suspicious_patterns = [
        r'eval\s*\(',           # eval() 사용
        r'exec\s*\(',           # exec() 사용
        r'__import__\s*\(',     # 동적 import
        r'subprocess\.(call|run|Popen)',  # 서브프로세스 실행
        r'base64\.b64decode',   # Base64 디코딩
        r'os\.system',          # 시스템 명령 실행
    ]
    
    findings = []
    
    for py_file in package_path.rglob('*.py'):
        content = py_file.read_text()
        
        for pattern in suspicious_patterns:
            matches = re.findall(pattern, content)
            if matches:
                findings.append({
                    'file': str(py_file),
                    'pattern': pattern,
                    'count': len(matches)
                })
    
    return findings

동적 분석: 샌드박스 활용

동적 분석(Dynamic Analysis)은 패키지를 격리된 환경에서 실행하여 행위를 관찰합니다. 네트워크 연결 시도, 파일 시스템 접근, 프로세스 생성 등을 모니터링합니다.

주요 동적 분석 플랫폼:

  • Socket.dev: 설치 시점 악성코드 탐지
  • Snyk: 실시간 모니터링 및 차단
  • Phylum: 공급망 공격 특화 분석
  • OSS Index: Sonatype의 무료 취약점 DB

결론

핵심 요약

지난 1년간 오픈소스 보안 위협은 양적으로나 질적으로 급격히 진화했습니다. GitHub 리포트가 보여주는 핵심 데이터를 정리하면:

  1. CVE/Advisory 폭증: 연간 50% 이상 증가, 고위험 취약점 비율 상승 2. Malware 진화: 난독화, 다단계 페이로드, 정교한 사회공학 3. 공격 표면 확대: 평균 7~8단계의 의존성 깊이, 96% 프로젝트가 외부 의존성 사용

이러한 환경에서 “취약점이 발견되면 패치하면 된다"는 대응식 접근은 더 이상 유효하지 않습니다. 예방적 보안(Preventive Security) 체계가 필수입니다.

전문가 인사이트

CVE 분석가로서 강조하고 싶은 점은 **가시성(Visibility)**과 **속도(Velocity)**입니다. 의존성 트리 전체를 파악하지 못하면 영향 범위를 분석할 수 없고, 대응 속도가 늦으면 공격자에게 선점당합니다.

특히 다음 세 가지를 당장 실행하시기 바랍니다:

  1. SBOM 생성 자동화: 모든 프로덕션 배포에 SBOM을 포함하고 중앙 집중 관리 2. CI/CD 보안 게이트: High/Critical 취약점이 있으면 배포 차단 3. 실시간 모니터링: 이미 배포된 의존성에 대한 지속적 CVE 알림 구독

공급망 공격은 앞으로 더 증가할 것입니다. 하지만 체계적인 준비와 자동화된 대응 체계가 있다면 위험을 허용 가능한 수준으로 관리할 수 있습니다.

참고자료

출처: https://news.google.com/rss/articles/CBMivwFBVV95cUxPNDh5UWc1eW4yc1d3V3B4cXJ0TzB5MVZaRUpLT1lMTmpJQWlyUTBNNS1iVjFlMzlzenViTDNhYjNjbWFtSTZ0SEVlRjZtWHhxRkVqdHlSX1dFOVNvM3czdk0za19iT1BId3hxOGJkbnlpeEY3WW1PdzF1MG9OTnFVcnJOdUJFSEs0Tnl6RS1zX2ZTeGg4X0JyckRyRFdNZWtnbGV5OUo5TGVfblU5bmxYb1FzRDQ4bzgyeDFOVXpJQQ?oc=5

© 2025 - 2026 코딩이 싫은 거북이
Hugo로 만듦
Jimmy의 Stack 테마 사용 중