야 진짜 무서운 얘기 해줄게ㅋㅋㅋ
니가 열심히 만든 앱, 코드 한 줄도 안 틀렸는데 해킹당하는 상황이 실제로 존재함ㄷㄷ
어떻게 그게 가능하냐고? 바로 공급망 공격(Supply Chain Attack) 때문이야.

쉽게 말하면 이런 거야. 니가 직접 만든 코드는 완벽한데, 니가 가져다 쓰는 라이브러리, 오픈소스, 빌드 도구, 업데이트 서버 같은 것들이 이미 오염되어 있는 상황.
마치 식당에서 요리사가 아무리 깨끗하게 요리해도, 납품받은 재료 자체에 독이 들어있으면 답 없는 것처럼 말이지 🍽️

이 글에서는 실제로 터진 사건들 낱낱이 파헤치고, 개발자로서 어떻게 막을 수 있는지 현실적인 방법까지 다 알려줄게.
보안 공부 어렵다고 생각했다면 오늘 생각 바뀔 수도 있음ㅋㅋ 가보자고! 🚀

공급망 공격(Supply Chain Attack)은 소프트웨어나 하드웨어의 제조·배포 과정에 침투해서 악성코드를 심는 공격 방식이야.
직접적으로 타깃 시스템을 공격하는 게 아니라, 타깃이 신뢰하고 사용하는 제3자 구성요소를 먼저 오염시키는 거지.

실제로 현대 소프트웨어 개발 환경을 생각해봐.
Node.js 프로젝트 하나 만들면 node_modules 폴더에 수백~수천 개의 패키지가 들어오잖아.
Python 프로젝트도 마찬가지고, Java Maven 프로젝트도 의존성 트리 펼치면 어마어마하게 나오지.

일반적인 해킹은 방화벽, 백신, IDS/IPS 같은 보안 솔루션으로 어느 정도 막을 수 있어.
근데 공급망 공격은 정상적인 소프트웨어 배포 채널을 통해 들어오기 때문에 보안 솔루션이 이걸 악성으로 인식하기 엄청 어려워.

공급망 공격이 다 똑같은 게 아니야. 어디를 어떻게 공격하느냐에 따라 여러 유형으로 나뉘어.
각 유형 제대로 이해해야 나중에 예방도 제대로 할 수 있음!

정상적인 소프트웨어 업데이트 메커니즘을 탈취해서 악성 업데이트를 배포하는 방식.
사용자는 "업데이트 완료!" 알림 보고 안심하지만 사실 악성코드가 설치된 거임 😱
대표 사례: SolarWinds Orion 사건 (뒤에서 자세히 다룰 예정)

npm, PyPI, RubyGems 같은 패키지 저장소에 악성 패키지를 올려놓는 방식.
두 가지 세부 방법이 있어:

소스코드 자체는 깨끗한데, 컴파일·빌드하는 과정에서 악성코드가 삽입되는 방식.
이론적으로는 1984년 Ken Thompson의 "Reflections on Trusting Trust" 논문에서 처음 제시됨.
컴파일러 자체를 오염시키면 소스코드 감사를 아무리 해도 발견 불가능한 무서운 공격이야.

물리적 하드웨어 제조 단계에서 악성 칩이나 펌웨어를 심는 방식.
2018년 Bloomberg 보도로 유명해진 "Big Hack" 사건 — 중국 제조 서버 마더보드에 쌀알 크기의 칩이 심어졌다는 주장 (진위 논란 있음)
탐지가 거의 불가능하고 소프트웨어로는 제거 불가능해서 이론적으로 가장 무서운 유형

GitHub Actions, Jenkins, CircleCI 같은 CI/CD 도구의 취약점이나 설정 오류를 이용.
2022년 CircleCI 보안 사고가 대표적 사례 — 직원 노트북 악성코드 감염 → CI/CD 시크릿 탈취
빌드 환경에 접근하면 배포되는 모든 소프트웨어를 조작 가능함

오픈소스 프로젝트에 기여자로 참여해서 악성 코드를 PR로 제출하는 방식.
2021년 미네소타 대학교 연구팀이 Linux 커널에 의도적으로 취약점 있는 패치를 제출해서 논란이 됨 (연구 목적이었지만 커뮤니티 엄청 화남ㅋㅋ)

이거 진짜 역대급 사건이야. 사이버 보안 역사에서 가장 정교하고 충격적인 공급망 공격으로 기록됨.
SolarWinds는 IT 인프라 모니터링 소프트웨어 Orion을 만드는 회사인데, 미국 정부기관, 대기업, 보안회사들이 대거 사용하는 제품이었어.

이 악성코드가 얼마나 정교했는지 알면 진짜 소름 돋음ㄷㄷ

공격자들은 SolarWinds의 Orion 소프트웨어 빌드 파이프라인에 직접 침투해서 소스코드가 컴파일되는 과정에 악성코드를 삽입했어.
구체적으로는 SolarWinds.Orion.Core.BusinessLayer.dll 파일에 SUNBURST 코드가 포함됨.
이 DLL 파일은 SolarWinds의 디지털 서명이 정상적으로 적용되어 있었기 때문에 보안 솔루션이 악성으로 판단하지 못했어.

나중에 밝혀진 바로는 공격자들이 Orion 빌드 서버에 별도의 악성 DLL을 심어두고, 빌드 과정에서 이 DLL이 자동으로 실행되어 최종 바이너리에 SUNBURST 코드를 삽입하는 방식을 사용했다고 해.
소스코드 자체에는 악성코드가 없었기 때문에 코드 리뷰로도 발견 불가능했던 거지 😱

이건 2024년에 터진 사건인데, 진짜 소름 돋는 게 거의 성공할 뻔했어ㄷㄷ
XZ Utils는 Linux 시스템에서 파일 압축에 사용되는 핵심 라이브러리야. 거의 모든 Linux 배포판에 포함되어 있음.

단순히 코드에 악성 코드를 심은 게 아니야. 공격자는 2~3년에 걸쳐 신뢰를 구축하는 장기 작전을 펼쳤어.
심지어 다른 계정들을 동원해서 Jia Tan에게 더 많은 권한을 줘야 한다고 압박하는 소셜 엔지니어링까지 했음.
이 정도 수준의 계획성이면 개인 해커가 아니라 국가 지원을 받는 APT 그룹이라는 게 보안 전문가들의 공통된 의견이야.

3CX는 기업용 VoIP(인터넷 전화) 소프트웨어 회사야. 전 세계 60만 개 이상 기업이 사용하는 제품임.
2023년 3월, 3CX 데스크톱 앱이 악성코드를 배포하고 있다는 게 발견됐어.

조사 결과 충격적인 사실이 밝혀졌어.
3CX 직원이 Trading Technologies라는 금융 소프트웨어 회사의 오염된 설치 파일을 다운로드해서 설치했고,
그 악성코드가 3CX 개발 환경에 침투해서 3CX 소프트웨어를 오염시킨 거야.

공급망 공격이 또 다른 공급망 공격의 발판이 된 거야. 이걸 "이중 공급망 공격(Double Supply Chain Attack)"이라고 부름.
Lazarus Group은 이 공격으로 주로 암호화폐 거래소와 금융기관을 타깃으로 추가 공격을 진행했어.

Codecov는 코드 커버리지 분석 도구야. CI/CD 파이프라인에 통합해서 테스트 커버리지를 측정하는 서비스인데,
수천 개의 기업이 GitHub Actions, CircleCI 등에서 Codecov를 사용하고 있었어.

공격자들이 Codecov의 Docker 이미지 생성 과정에서 취약점을 발견하고,
Codecov가 배포하는 bash uploader 스크립트에 악성 코드를 삽입했어.

피해 기업들은 자신들의 CI/CD 파이프라인에서 Codecov 스크립트를 실행했을 뿐인데,
그 과정에서 모든 시크릿이 유출된 거야. 2개월 동안 아무도 몰랐음.

이 사건은 오픈소스 생태계의 신뢰 문제를 정면으로 건드린 사건이야.
event-stream은 Node.js에서 스트림 처리에 사용되는 유명한 패키지였어.

악성 코드는 Copay 비트코인 지갑 앱에서만 활성화되도록 설계되어 있었어.
일반 환경에서는 아무 동작도 안 하고, Copay 앱의 특정 버전에서만 실행되는 조건부 악성 코드였지.
게다가 코드가 AES 암호화로 난독화되어 있어서 일반적인 코드 분석으로는 발견하기 어려웠음.

자 이제 무서운 얘기는 충분히 했고ㅋㅋ 진짜 중요한 예방 방법 알아보자.
이론적인 얘기 말고 실제로 개발하면서 바로 적용할 수 있는 것들로 정리했어.

가장 기본적이면서 중요한 것부터. 패키지 잠금 파일을 반드시 사용하고 버전 관리에 포함시켜야 해.

# ❌ 이렇게 하면 안 됨 - 버전 범위 지정
"dependencies": {
  "lodash": "^4.0.0",  // 4.x.x 중 아무 버전이나 설치됨
  "express": "~4.18.0" // 4.18.x 중 아무 버전이나 설치됨
}

# ✅ 이렇게 해야 함 - 정확한 버전 고정
"dependencies": {
  "lodash": "4.17.21",  // 정확히 이 버전만
  "express": "4.18.2"   // 정확히 이 버전만
}

# 그리고 package-lock.json 또는 yarn.lock을 반드시 git에 커밋!

정기적으로 의존성 취약점 검사를 해야 해. 이건 CI/CD에 자동화해두면 더 좋음.

# Node.js
npm audit                    # 취약점 검사
npm audit fix                # 자동 수정 (가능한 경우)
npm audit --audit-level=high # 높은 심각도만 표시

# Python
pip install pip-audit
pip-audit                    # 취약점 검사

# Java (Maven)
mvn dependency-check:check   # OWASP Dependency Check

# GitHub Actions에서 자동화
- name: Security Audit
  run: npm audit --audit-level=moderate

SBOM(Software Bill of Materials)은 소프트웨어에 포함된 모든 구성요소 목록이야.
마치 식품의 성분표처럼, 소프트웨어에 어떤 라이브러리가 어떤 버전으로 들어있는지 명세하는 거지.

# CycloneDX 형식 SBOM 생성 (Node.js)
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-file sbom.json

# SPDX 형식 SBOM 생성
npm install -g spdx-sbom-generator
spdx-sbom-generator

# Syft 도구 사용 (다양한 언어 지원)
syft packages dir:. -o spdx-json > sbom.spdx.json

다운로드하는 소프트웨어나 패키지의 디지털 서명을 반드시 검증해야 해.
물론 SolarWinds 사건처럼 서명 자체가 오염될 수 있지만, 서명 검증은 기본 중의 기본이야.

# npm 패키지 서명 검증 (npm 9.x+)
npm audit signatures

# GPG 서명 검증 (Linux 패키지)
gpg --verify package.tar.gz.sig package.tar.gz

# SHA256 체크섬 검증
sha256sum -c package.sha256

# Python 패키지 서명 검증
pip install --require-hashes -r requirements.txt
# requirements.txt에 해시 포함:
# requests==2.28.1 \
#   --hash=sha256:7c5599b102feddaa661c826c56ab4fee28bfd17f5abca1ebbe3e7f19d7c97983

CI/CD 파이프라인과 빌드 환경에서 최소한의 권한만 부여해야 해.
Codecov 사건처럼 CI/CD 환경에 모든 시크릿이 노출되어 있으면 한 번에 다 털림.

# GitHub Actions에서 최소 권한 설정
permissions:
  contents: read        # 코드 읽기만
  packages: write       # 패키지 배포만
  id-token: write       # OIDC 토큰만

# 환경별 시크릿 분리
jobs:
  deploy-prod:
    environment: production  # 프로덕션 환경 시크릿만 접근
    steps:
      - uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789:role/deploy-role
          # 루트 키 대신 역할 기반 임시 자격증명 사용!

기업 환경에서는 공개 패키지 저장소를 직접 사용하는 것보다 내부 프라이빗 레지스트리를 운영하는 게 훨씬 안전해.
Dependency Confusion 공격도 이 방법으로 막을 수 있음.

# Nexus Repository Manager 설정 예시
# .npmrc 파일
registry=https://nexus.company.com/repository/npm-group/
@company:registry=https://nexus.company.com/repository/npm-private/

# pip 설정
[global]
index-url = https://nexus.company.com/repository/pypi-group/simple/
trusted-host = nexus.company.com

# Dependency Confusion 방지 - 내부 패키지 스코프 설정
# package.json
{
  "name": "@company/internal-package",
  "publishConfig": {
    "registry": "https://nexus.company.com/repository/npm-private/"
  }
}

동일한 소스코드로 빌드하면 항상 동일한 바이너리가 나와야 해.
이게 보장되면 빌드 환경이 오염되었는지 독립적으로 검증할 수 있어.

Debian Linux, Bitcoin Core, Tor Browser 등이 재현 가능한 빌드를 채택하고 있어.
reproducible-builds.org 프로젝트에서 관련 도구와 가이드를 제공함.

SLSA(Supply-chain Levels for Software Artifacts, "살사"라고 읽음)는 Google이 제안한 공급망 보안 프레임워크야.
소프트웨어 공급망의 무결성을 보장하기 위한 4단계 레벨을 정의함.

Sigstore는 오픈소스 소프트웨어 서명을 위한 새로운 표준이야. Linux Foundation이 지원하는 프로젝트.
기존 GPG 서명의 복잡함을 해결하고, 투명한 로그(Transparency Log)를 통해 서명을 공개적으로 검증 가능하게 함.

# cosign으로 컨테이너 이미지 서명
cosign sign --key cosign.key ghcr.io/myorg/myapp:latest

# 서명 검증
cosign verify --key cosign.pub ghcr.io/myorg/myapp:latest

# keyless 서명 (OIDC 기반, GitHub Actions에서)
- name: Sign container image
  uses: sigstore/cosign-installer@main
- run: |
    cosign sign --yes ghcr.io/${{ github.repository }}:latest

# Python 패키지 서명 (PyPI는 2023년부터 Sigstore 지원)
python -m sigstore sign dist/*.whl

사용하는 서드파티 소프트웨어나 서비스 제공업체의 보안 수준을 정기적으로 평가해야 해.
SolarWinds 사건 이후 많은 기업들이 공급업체 보안 평가를 강화했어.

재능넷에서 프리랜서로 활동하는 개발자든, 기업 소속 개발자든 이 체크리스트는 꼭 확인해봐.
당장 오늘부터 적용할 수 있는 것들이야!

# ❌ 나쁜 예 - 태그나 브랜치로 고정 (변경 가능)
- uses: actions/checkout@v3
- uses: actions/setup-node@main

# ✅ 좋은 예 - 특정 커밋 해시로 고정 (불변)
- uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608
- uses: actions/setup-node@1a4442cacd436585916779262731d1f68fbc272a

# Trivy로 컨테이너 이미지 취약점 스캔
trivy image myapp:latest

# Grype로 SBOM 기반 취약점 스캔
grype sbom:./sbom.json

# Snyk으로 코드 및 의존성 스캔
snyk test
snyk container test myapp:latest

말만 하면 뭐해, 실제로 쓸 수 있는 도구들 정리해줄게.
대부분 오픈소스라서 무료로 쓸 수 있음! 💪

공격자들도 계속 진화하고 있어. 앞으로 어떤 위협이 올지 미리 알아두면 대비하기 좋겠지?

이미 일부 보안 연구자들이 AI를 이용해서 오픈소스 코드에 탐지하기 어려운 취약점을 자동으로 삽입하는 실험을 했어.
앞으로 AI가 발전할수록 더 정교한 악성 코드 삽입이 가능해질 거야.
반대로 AI를 이용한 코드 분석과 이상 탐지도 발전하고 있어서 공격과 방어 모두 AI화되는 추세임.

요즘 AI 모델을 Hugging Face 같은 플랫폼에서 다운로드해서 쓰는 경우 많잖아.
이 AI 모델 자체에 악성 코드를 심는 새로운 형태의 공급망 공격이 등장하고 있어.
Pickle 파일 취약점을 이용해서 AI 모델 파일에 악성 코드를 삽입하는 방법이 실제로 발견됨.

각국 정부가 소프트웨어 공급망 보안에 대한 규제를 강화하고 있어.

"신뢰하되 검증하라(Trust but Verify)"에서 "절대 신뢰하지 말고 항상 검증하라(Never Trust, Always Verify)"로 패러다임이 바뀌고 있어.
공급업체가 아무리 신뢰받는 곳이라도 항상 검증하는 Zero Trust 원칙을 공급망에도 적용하는 거지.

"알겠는데 어디서부터 시작해야 해?"라는 생각 드는 거 알아ㅋㅋ
단계별로 정리해줄게. 오늘부터 시작할 수 있는 것들이야.

이 글에서 다룬 내용들의 원본 자료와 더 깊이 공부할 수 있는 리소스들이야.