NEW 시큐레터 CDR 백서 발행 — MARS 분석 + CDR 무해화, N2SF 시대의 콘텐츠 보안 표준 답안 백서 다운로드 →
KO
문의하기 PoC 신청
← 블로그 목록
L1 · 입문 공급망 보안

공급망 공격 & 코드서명 인증서 탈취 —
SolarWinds·3CX·XZ Utils부터 아람CA·WIZVERA까지

SolarWinds SUNBURST, 3CX 이중 공급망, XZ Utils Jia Tan 백도어, NotPetya M.E.Doc, 아람CA·SKT 코드서명 탈취, WIZVERA VeraPort까지. NIST SSDF·SBOM·Sigstore·SLSA 정책 체계, CDR의 파일 내부 구조 검증 원리를 정리.

시큐레터 보안연구팀 · 2026.04.21 · 읽기 26분
SOFTWARE SUPPLY CHAIN · INJECTION POINTS ① DEV 소스 코드 작성 오픈소스 의존성 XZ Utils ② BUILD CI/CD 파이프라인 컴파일 · 패키징 SolarWinds ③ SIGN 코드서명 인증서 PKI · HSM Stuxnet/아람CA ④ DISTRIBUTE 업데이트 서버 CDN · 미러 3CX · ASUS ⑤ INSTALL 고객 환경 실행 MSP · 에이전트 APT10/NotPetya ⚠️ 공격자는 "가장 신뢰된 경로"에 주입한다 — 서명 유효성만으로는 탐지 불가 MITRE ATT&CK T1195 Supply Chain Compromise · T1553.002 Code Signing Subversion · T1078 Valid Accounts 정상 빌드에 주입된 악성 코드는 "합법 서명"을 획득한 채 전 고객에게 배포된다 ✅ CDR의 공급망 방어 — "서명 유효성이 아니라 파일 내부 구조를 검증" 실행 가능 콘텐츠(매크로·OLE·스크립트·외부참조) 유형 기반 제거 + 구조 재조립 신뢰된 공급사 · 유효 서명 · 정상 배포 경로 모두와 무관하게 동일 원리 작동 NIST SSDF(SP 800-218) · C-SCRM(SP 800-161) · EO 14028 SBOM 요구와 보완 관계

보안 업계의 기반 가정 하나가 지난 6년간 반복적으로 무너졌다 — "디지털 서명이 유효하면 신뢰할 수 있다"는 전제다. 2020년 12월 13일 FireEye/Mandiant가 공개한 SolarWinds SUNBURST[1]는 합법 서명된 DLL 하나가 18,000여 조직을 동시에 관통할 수 있음을 드러냈다. 2023년 3월 29일 3CX DesktopApp 사건[2]은 "이중 공급망"(공급사의 공급사) 공격을 최초 확인했고, 2024년 3월 29일 Andres Freund가 발견한 XZ Utils 백도어(CVE-2024-3094, CVSS 10.0)[3]는 2년 이상 잠복한 가명 기여자가 Linux 핵심 라이브러리에 심은 오픈소스 공급망 공격이었다. 한국에서도 2010년 Stuxnet이 Realtek·JMicron 인증서를 악용했고[4], 2021년 1월 CISA AA21-022A는 WIZVERA VeraPort 공격을 공식화했다[5]. 이 글은 주요 사례의 TTP를 MITRE ATT&CK T1195·T1553.002 프레임으로 정리하고, NIST SSDF(SP 800-218)·C-SCRM(SP 800-161)·EO 14028 SBOM·Sigstore·SLSA 정책 체계를 검토한 뒤, "서명 유효성이 아니라 파일 내부 구조를 검증한다"는 CDR의 공급망 방어 원리를 해부한다.

18,000+
SolarWinds SUNBURST 영향 조직
Mandiant 2020.12.13[1]
CVSS 10
XZ Utils CVE-2024-3094
Andres Freund 2024.3.29[3]
600,000
3CX 기업 고객 규모
Mandiant 2023.3[2]
EO 14028
미 행정명령 SBOM 의무
2021.5.12[6]

1 공급망 공격이라는 구조적 문제

소프트웨어 공급망은 개발(DEV) → 빌드(BUILD) → 서명(SIGN) → 배포(DISTRIBUTE) → 설치(INSTALL)의 5단계로 구성되며, 각 단계는 이전 단계를 "신뢰"한다는 전제로 작동한다. 공격자는 신뢰 체인의 가장 취약한 고리를 찾아 주입한 뒤, 이후 단계가 자동으로 "정당성"을 부여하도록 만든다.

서명은 "내용의 안전"을 증명하지 않는다

디지털 코드서명은 "이 파일이 특정 주체의 개인키로 서명되었다"만 증명한다. "이 파일의 내용이 악성이 아니다"는 증명하지 않는다. 두 명제는 근본적으로 다르지만, 대부분의 엔드포인트 보안 제품은 전자를 후자로 해석한다. SmartScreen·Gatekeeper·macOS Notarization 모두 서명 유효성을 신뢰 판단의 중요 지표로 쓴다.

⚠️ 신뢰 체인이 깨지는 3가지 방식
  • 인증서·개인키 탈취 — 개발사 내부 침투로 HSM 또는 빌드 서버의 서명 자격 증명을 획득 (Stuxnet Realtek/JMicron, Flame, 한국 아람CA 보고 사례)
  • 빌드 파이프라인 침투 — CI/CD에 악성 주입하면 정상 빌드 프로세스가 자동으로 서명을 적용 (SolarWinds SUNBURST의 SUNSPOT 빌드 임플란트)
  • 합법 발급 후 악용 및 소스 신뢰 남용 — 위장 회사로 정상 발급 · 오픈소스 메인테이너 권한 획득(XZ Utils) · 제3자 라이브러리 변조(3CX의 이중 공급망)

MITRE ATT&CK는 이를 T1195 Supply Chain Compromise(하위: T1195.001 개발도구 · T1195.002 SW 배포 · T1195.003 HW)와 T1553.002 Subvert Trust Controls: Code Signing으로 분류한다[7]. 한 번의 공급망 침해가 수만 조직에 동시에 영향을 주는 "N배 증폭 효과"가 이 기법의 본질이다.

2 SolarWinds SUNBURST — 빌드 파이프라인 침투의 정점

2020년 12월 13일, FireEye(현 Mandiant)는 SolarWinds Orion 플랫폼 소프트웨어 업데이트에 심어진 백도어 SUNBURST(UNC2452)를 공개했다[1]. CISA는 다음날 비상 지침 ED 21-01을 발령했고, 이후 AA20-352A 경보를 공개했다[8].

침투 체인

  1. 초기 침투: 공격자가 SolarWinds 내부 네트워크에 접근 (최소 2019년 9월)
  2. SUNSPOT 빌드 임플란트: Orion 빌드 서버에 taskhostsvc.exe를 설치해 MsBuild.exe 프로세스를 감시, InventoryManager.cs 소스 파일을 빌드 시점에만 악성 버전으로 스왑
  3. 정상 서명: 변조된 코드가 SolarWinds의 합법적 코드서명 인증서로 자동 서명됨
  4. 배포: 2020년 3월~6월 정상 Orion 업데이트 SolarWinds.Orion.Core.BusinessLayer.dll (버전 2019.4 HF5 ~ 2020.2.1 HF1)로 배포
  5. C2: avsvmcloud[.]com 서브도메인 DGA, 12~14일 잠복 후 활성화
"The trojanized update file is a standard Windows Installer Patch file ... including the trojanized SolarWinds.Orion.Core.BusinessLayer.dll component. Once installed, the malicious DLL will be loaded by the legitimate SolarWinds.BusinessLayerHost.exe." — FireEye/Mandiant, 2020.12.13[1]

SolarWinds 공식 공지에 따르면 Orion 고객 약 33,000곳 중 18,000여 곳이 침해 업데이트를 받았다[8]. Microsoft·Mandiant 자체도 피해자였고, 미 재무부·상무부·국토안보부·국무부·에너지부 등 연방 기관이 포함됐다. 공격자는 엔드포인트 보안을 "우회"한 것이 아니라 엔드포인트 보안이 신뢰하도록 만들어진 경로를 사용했다. 2021년 5월 EO 14028이 SBOM 의무화를 포함한 결정적 배경이다[6].

3 3CX DesktopApp — 이중 공급망 공격의 최초 확인

2023년 3월 29일 Mandiant/CrowdStrike/SentinelOne이 동시 공개한 3CX DesktopApp 공급망 사건은 공급망 공격의 진화를 상징한다[2]. 3CX는 전 세계 600,000개 기업 · 1200만 사용자가 쓰는 VoIP 소프트웨어다.

공격 체인

  1. 1차 감염: 3CX 직원이 Trading Technologies의 X_TRADER라는 증권거래 SW 설치 (이미 공급망 공격으로 변조된 상태, 2022년)
  2. 2차 확산: X_TRADER 내부의 VEILEDSIGNAL 백도어로 3CX 빌드 환경 장악
  3. 3차 주입: 3CX 데스크톱 앱(3CXDesktopApp.exe 18.12.407/416)에 악성 DLL ffmpeg.dll 사이드로드 경로 추가
  4. 합법 서명: 3CX의 정식 코드서명으로 2023년 3월 배포
  5. C2: GitHub 저장소(IconStorages/images)의 ICO 파일에서 Base64 URL 추출
"This is the first time Mandiant has seen a software supply chain attack lead to another software supply chain attack. The initial compromise of 3CX was via the trojanized X_TRADER software." — Mandiant, 2023.4.20[2]

공격 주체는 북한 연계 UNC4736(Lazarus 산하)으로 귀속됐다. 한 번의 침해가 공급망의 공급망을 타고 두 번 증폭된 이 사건은 N-tier 공급망 가시성이 SBOM 단독으로는 부족하다는 것을 드러냈다.

4 XZ Utils CVE-2024-3094 — Jia Tan의 2년 잠복

2024년 3월 29일 Microsoft PostgreSQL 개발자 Andres Freund가 OSS-security 메일링 리스트에 올린 보고서[3]는 오픈소스 생태계 역사상 가장 정교한 백도어를 드러냈다. CVE-2024-3094에 CVSS 10.0 Critical이 부여됐다[9].

사회공학의 장기 플레이

  • 2021.4 — "Jia Tan"(JiaT75) 계정이 GitHub에 등장. XZ Utils 프로젝트에 소소한 기여 시작
  • 2022 — Jigar Kumar·Dennis Ens 등 가명 계정들이 원 메인테이너 Lasse Collin에게 번아웃을 이유로 Jia Tan에게 권한을 넘기라고 압박
  • 2023 — Jia Tan이 공동 메인테이너 획득
  • 2024.2 — XZ Utils 5.6.0 릴리스에 백도어 삽입 (테스트 파일 bad-3-corrupt_lzma2.xz, good-large_compressed.lzma에 페이로드 은닉)
  • 2024.3.29 — Andres Freund가 sshd 로그인 지연(~500ms) 성능 이상을 추적하다 발견
"After observing a few odd symptoms around liblzma ... logins with ssh taking a lot of CPU, valgrind errors, I figured out the answer: The upstream xz repository and the xz tarballs have been backdoored." — Andres Freund, oss-security, 2024.3.29[3]

백도어는 liblzma에 IFUNC 해석기를 통해 링크되어 sshd의 RSA_public_decrypt 함수를 후킹하고, 특정 ED448 공개키로 서명된 페이로드가 ssh 인증 경로에 들어올 때 원격 코드 실행을 허용했다. Fedora 40/41 beta·Debian sid·openSUSE Tumbleweed가 영향권에 있었으나 광범위한 프로덕션 배포 직전에 발견됐다. XZ Utils는 단일 메인테이너에 의존하는 "1인 공급망"이었고, 이런 프로젝트가 거의 모든 현대 Linux 인프라에 포함된다. SLSA와 Sigstore가 이 문제에 대한 커뮤니티 답변이다[10].

5 NotPetya M.E.Doc — 국가 경제 단위의 피해

2017년 6월 27일 우크라이나 회계 SW M.E.Doc 업데이트 서버가 침해되어 NotPetya 와이퍼가 배포됐다[11]. 표면적으로는 랜섬웨어처럼 보였으나 복호화 불가능한 파괴형 악성코드였다. Maersk(50,000대 PC 재구축, 추정 $250~$300M), Merck($870M), FedEx/TNT($400M) 등이 피해를 입었고, 미 백악관 공식 추정 전 세계 피해는 $10B+에 달했다 — 역사상 최대 규모 사이버 파괴. Andy Greenberg(Wired)는 NotPetya를 "The Most Devastating Cyberattack in History"로 규정했다. 공급망 공격이 단일 기업이 아니라 국가 경제·물류·의료 전체를 인질로 잡을 수 있다는 증거였다. 공격 주체는 러시아 GRU Sandworm(APT44)로 미·영이 공식 귀속했다.

6 코드서명 탈취 기법 계보 — Stuxnet에서 현재까지

코드서명 인증서 탈취는 새로운 기법이 아니다. 2010년대 초부터 APT 그룹의 표준 도구함에 포함되어 있었다.

연도사건탈취/악용된 인증서공격 주체
2010StuxnetRealtek Semiconductor · JMicron TechnologyEquation Group (NSA/Unit 8200 추정)[4]
2012FlameMD5 충돌로 Microsoft 터미널서버 CA 위조동일 계열
2013Bit9 침해Bit9 화이트리스트 서명 인증서중국계 APT
2017.7NotPetyaM.E.Doc 업데이트 서명Sandworm (GRU)[11]
2017.9CCleanerPiriform 정식 서명 (v5.33)APT17 / Axiom[12]
2019.3ASUS ShadowHammerASUS Live Update 서명BARIUM (Winnti)[13]
2020.12SolarWinds SUNBURSTSolarWinds Orion 서명UNC2452 (APT29/Cozy Bear)[1]
2023.33CX DesktopApp3CX 정식 서명UNC4736 (Lazarus)[2]
2024.3XZ Utils(서명 없는 오픈소스) 메인테이너 권한 탈취Jia Tan 가명 / 국가 연계 의심[3]

CCleaner(2017.9) — Piriform 빌드 시스템 침해로 v5.33.6162에 백도어 삽입, 약 227만 대에 1단계 페이로드 설치, 2단계로 Cisco·Intel·Microsoft·Samsung·VMware 등 40여 기술 기업 선별 침투 시도[12].

ASUS ShadowHammer(2019.3) — Kaspersky GReAT가 공개한 Operation ShadowHammer는 ASUS Live Update 유틸리티 변조. 정식 코드서명 유지한 채 약 57,000대 설치, 그러나 약 600개 MAC 주소만 표적으로 하는 외과적 공격[13].

7 한국 공급망 사례 — 아람CA·SKT 코드서명 탈취 보고

한국은 공급망 공격의 초기부터 표적이자 경로였다. 다만 공식 문서화된 자료의 공개 범위가 상대적으로 제한적이다.

아람CA / SKT 코드서명 탈취 보고

Symantec·Mandiant·ESET 공개 APT 보고서는 2010년대 중반부터 한국 SW 개발사·통신사 명의 코드서명 인증서가 APT 도구에 사용된 사례를 관측해왔다[14]. 공격 주체는 북한 연계 Lazarus·Andariel·Kimsuky로 귀속되는 경우가 많다. 한국 인증서는 뱅킹 트로이목마·MBR 와이퍼·드로퍼에 반복 사용됐고, 2013년 DarkSeoul(3.20 방송·금융사 동시 파괴)과 이후 Lazarus Operation Blockbuster에서도 재등장했다[15].

한국 개발사 구조적 취약점 (KISA·국정원 공동 조사)

  • 코드서명 개인키를 HSM이 아닌 파일 시스템에 보관
  • 빌드 서버가 개발 PC와 같은 네트워크 세그먼트에 위치
  • Windows 관리자 계정 공유 관행
  • 공급사 보안 감사(TPRM) 공식 절차 부재

8 WIZVERA VeraPort 공격 — CISA AA21-022A

2020년 11월 ESET은 한국 WIZVERA VeraPort 시스템을 이용한 공급망 공격을 공개했고[16], 2021년 1월 22일 미국 CISA가 AA21-022A 경보로 정식 확인했다[5].

VeraPort는 한국 금융·공공 웹사이트 접속 시 보안 플러그인(키보드 보안·방화벽·PKI 모듈)을 자동 설치하는 통합 프로그램이다. 이 자동 설치 채널 자체가 공격 표적이 됐다.

"Lazarus Group actors use a watering hole tactic ... the integrated WIZVERA VeraPort management software installs cyber actor-supplied malicious binaries alongside legitimate software. The malicious binaries are signed with stolen but valid code-signing certificates." — CISA AA21-022A, 2021.1.22[5]

ESET 보고에 따르면 Dream Security USA Inc. 등 한국 개발사 명의 인증서가 탈취·악용됐으며, 일부는 KISA 경로 공식 발급 인증서였다. 구조적 의미는 분명하다 — 국가 단위 신뢰 인프라(공인인증서·금융 플러그인·자동 설치 채널)가 공격 경로가 될 수 있다는 것. 시그니처 기반 방어뿐 아니라 자동 설치 채널 자체가 Zero Trust 검증 대상이어야 한다는 함의다.

9 APT10 Operation CloudHopper — MSP를 통한 공급망

2017년 4월 PwC UK·BAE Systems가 공개한 Operation Cloud Hopper[17]는 MSP(Managed Service Provider) 경유 공급망 공격의 전형이다. 주체는 중국 MSS 연계 APT10(Stone Panda/MenuPass). 공격자는 글로벌 IT 아웃소싱 MSP에 초기 침투한 뒤, MSP가 보유한 고객사 원격 관리 채널(RMM·점프서버)을 장악해 "정당한 관리 세션"으로 고객사 내부를 자유 이동했다. 2018년 12월 미 법무부 APT10 기소 공소장에 따르면 최소 12개국 45개 이상의 기술 기업·정부 기관이 침해됐다[18]. 한국에도 직접적인 문제다 — 다수 중견·중소 기업이 IT 운영을 외주 MSP에 의존한다.

10 공급망 공격 TTP 매트릭스 — MITRE ATT&CK

기법MITRE ID대표 사례탐지 난이도
Supply Chain Compromise: SW Dev ToolsT1195.001XcodeGhost, ccache 변조상
Supply Chain Compromise: SW DistributionT1195.002SolarWinds, 3CX, ASUS, CCleaner, NotPetya최상
Supply Chain Compromise: HWT1195.003BMC 펌웨어 등 (학술 보고 중심)최상
Subvert Trust Controls: Code SigningT1553.002Stuxnet, Flame, WIZVERA VeraPort상
Subvert Trust Controls: Code Signing Policy ModificationT1553.006Windows 레지스트리 조작중
Valid AccountsT1078MSP 관리자 계정 탈취(APT10)상
Trusted RelationshipT1199협력사·공급사 경유 접근상
DLL Side-LoadingT1574.0023CX ffmpeg.dll, 다수 APT중
Ingress Tool Transfer via Legit UpdateT1105정상 업데이트 채널 활용최상

이 매트릭스의 공통점은 "기존 탐지 관점에서는 정상처럼 보인다"는 것이다. 서명 유효성 · 인증된 관리자 · 정상 업데이트 채널 · 승인된 프로세스 — 모든 신뢰 지표가 "OK"로 찍힌다.

11 정책 프레임 — NIST SSDF · C-SCRM · EO 14028 · K-SBOM

EO 14028 (2021.5.12)

SolarWinds 직후 발효된 미 행정명령은 연방 조달 SW에 SSDF 준수 및 SBOM 제출 의무화를 명시했다[6] (§4(e) SSDF/SBOM, §4(f) NIST 프레임, §4(r) CISA 최소요소).

NIST SP 800-218 SSDF v1.1 · SP 800-161 Rev.1 C-SCRM

SSDF는 PO/PS/PW/RV 4개 실천 그룹으로 조직 준비·코드 보호·시큐어 코딩·취약점 대응을 정의한다[19]. C-SCRM은 공급망 리스크를 Tier 1(전사)/Tier 2(사업부)/Tier 3(시스템) 3단계로 통합 관리하는 모델과 공급사 실사 절차를 제시한다[20].

SBOM 표준 비교

표준관리 주체포맷특징
SPDXLinux FoundationRDF/JSON/YAML/Tag-ValueISO/IEC 5962:2021 국제표준 등재[21]
CycloneDXOWASPJSON/XML/Protobuf취약점(VEX)·서비스·ML-BOM 확장[22]
SWID TagsISO/IEC 19770-2XML자산 식별 중심 (보조적)

한국 K-SBOM 정책

과학기술정보통신부·KISA는 2023년부터 K-SBOM 가이드라인을 순차 발표했다[23]. SPDX·CycloneDX 호환을 기본으로 하되 한국 공공기관 조달 특성을 반영한다. 2024년 기준 주요 공공 SI 사업 RFP에 SBOM 제출이 포함되기 시작했다.

12 Sigstore · SLSA — 커뮤니티 해법

Sigstore (OpenSSF)

Cosign(서명)·Fulcio(단기 인증서)·Rekor(투명 로그)로 구성되는 OpenSSF 프로젝트[10]. 개발자가 개인키를 보관하지 않고 OIDC 기반 단기 인증서를 발급받으며, 모든 서명 이벤트가 Rekor 투명 로그에 공개 기록된다 (Certificate Transparency와 유사). 공격자가 키를 훔쳐도 로그에 흔적이 남아 은밀한 재서명이 불가능하다.

SLSA v1.0 (Supply-chain Levels for Software Artifacts)

Google 제안, OpenSSF 관리 성숙도 모델[24]. Build L1(프로비넌스 생성) → L2(호스팅 빌드 플랫폼의 서명된 프로비넌스) → L3(빌드 환경 격리 + 위·변조 불가). L3 달성 시 SolarWinds류 빌드 임플란트가 구조적으로 어려워진다. 다만 소스 자체가 악성이면(XZ Utils처럼) 프로비넌스가 완벽해도 백도어가 그대로 빌드된다는 한계는 남는다.

13 CDR의 공급망 방어 역할 — 파일 내부 구조 검증

정책·커뮤니티 해법(SSDF·SBOM·Sigstore·SLSA)은 모두 공급사 측의 대응이다. 수신 측 조직은 공급사 전부를 통제할 수 없으며, 특히 협력사가 보내는 업무 파일은 SBOM 범위 밖이다. CDR(Content Disarm & Reconstruction)은 파일이 실행 환경에 도달하기 전에 구조적으로 실행 가능 요소를 제거한다 — 서명 유효성·송신자 신뢰도·출처 도메인과 무관하게 동일 원리로.

✅ CDR이 무력화하는 공급망 벡터
  1. 파트너 경유 문서 내 매크로·OLE·DDE — 정상 서명된 메일로 온 DOCX·HWP·XLSX 내부의 실행 요소 제거
  2. 업데이트 동반 설정 파일 내 스크립트 — JSON/XML/ZIP 아카이브 내부의 실행 가능 콘텐츠 구조적 제거
  3. 협력사 공유 PDF의 JavaScript·외부 참조 — PDF Action/Launch/Embedded File 전면 정규화
  4. 이중 공급망(3CX류)에서 파생된 업무 문서 — 업스트림 공급망 침해 여부와 무관하게 파일 수준 처리
  5. 합법 서명된 아카이브 내부의 LNK·JSE·CHM — 유형 기반 제거로 서명 유효성과 독립
  6. MSP 관리 채널 경유 문서 — 관리자 권한 경로를 타고 들어오는 파일도 동일 게이트 통과

시큐레터 4제품의 공급망 통제 지점

제품공급망 통제 지점주요 기능
SLF (파일 보안)파일 서버 · 문서 중앙화 · 반입 게이트협력사·파트너 반입 파일 전수 무해화 · MARS 엔진 정적 분석 병행
SLE (이메일 보안)이메일 첨부 · 링크 · 외부 도메인DISARM 기반 첨부 재구성 · 신뢰 발신자 포함 예외 없음 정책 · URL Rewrite
SLCDR (웹 콘텐츠 CDR)웹 업로드 · 포털 다운로드 · 공유 링크업로드 경로 실시간 무해화 · 외부 파트너 포털 연동
ConTI (위협 인텔리전스)공급사 · 인증서 · 도메인 평판IoC 추적 · 신규 공급망 캠페인 조기 경보 · CDR 정책 피드백

네 제품은 서로 다른 채널에서 들어오는 파일을 동일한 "실행 가능 콘텐츠 유형 제거" 원리로 처리한다. "어느 채널이 먼저 뚫릴지 모르므로 모든 채널에 같은 게이트를 둔다"는 것이 설계 철학이다.

SBOM은 구성 요소를 추적해 취약점 발견 시 영향 범위를 판단한다. CDR은 구성 요소가 무엇이든 파일 수준에서 실행 요소를 제거해 공격 트리거를 차단한다. 병용하면 "무엇이 있는지"를 알면서 "무엇이 들어오든 실행되지 않도록" 한다.

14 공급망 공격 유형 · 대응 · 한계 매트릭스

공격 유형대표 사례주 대응 기법한계
빌드 파이프라인 침투SolarWinds SUNBURSTSLSA L3 · 빌드 격리 · 프로비넌스소스 자체 변조에는 무력
이중 공급망3CX DesktopAppN-tier SBOM · 공급사의 공급사 감사실무 가시성 한계
오픈소스 메인테이너 침투XZ Utils다수 메인테이너 · 커뮤니티 코드 리뷰1인 프로젝트 구조적 취약
업데이트 서버 변조NotPetya M.E.Doc · ASUS · CCleaner서명 검증 · 업데이트 경로 무결성합법 서명 동반 시 무력
코드서명 인증서 탈취Stuxnet · 아람CA 보고 · WIZVERAHSM · 서명 기록 투명화(Sigstore)발행 CA 측 침해 시 근본 해결 난망
MSP 경유APT10 CloudHopper관리자 계정 MFA · 점프서버 감사"정상 관리 세션" 탐지 어려움
파트너 업무 파일협력사 경유 문서CDR 파일 내부 구조 검증원본 일부 기능 손실 가능
오픈소스 패키지 타이포스쿼팅npm·PyPI 변종의존성 락 · 내부 미러신규 변종 식별 지연
💡 단일 기법으로 해결 불가 — 층위 방어

위 매트릭스의 메시지는 명확하다. 공급망 공격은 단일 통제로 방어 불가능하다. SSDF·SBOM·SLSA·Sigstore는 공급사 측 성숙도를 높이고, Zero Trust 네트워크 · MFA · 점프서버는 관리 채널을 보호하며, CDR은 수신 측에서 파일이 실행 환경에 도달하기 전 마지막 구조 검증 게이트로 작동한다. 세 계층이 독립적이어야 한 층이 뚫려도 다음 층이 버틴다.

15 실무 체크리스트

공급망 공격 대응 준비도
  1. SBOM 수집·관리 체계공급사로부터 SPDX/CycloneDX 수신 · 내부 자산 인벤토리 연계
    EO 14028 / K-SBOM 준거
  2. 빌드 환경 격리 (SLSA L2+ 지향)CI/CD 네트워크 분리 · 서명 HSM 보관 · 프로비넌스 기록
    NIST SSDF PS
  3. 서명 검증의 제한적 신뢰 정책"유효 서명=무해" 해석 금지 · 서명은 참고 지표로만 취급
    Zero Trust
  4. 협력사 반입 파일 전수 CDR신뢰 발신자 포함 예외 없음 · 4제품 통합 정책
    파일 수준 게이트
  5. MSP·원격관리 채널 MFA·점프서버APT10 CloudHopper 패턴 대비 · 관리자 세션 감사
    Trusted Relationship
  6. 공급사 실사(TPRM) 절차계약에 보안 요구사항 · 정기 감사 · 침해 통보 SLA
    NIST SP 800-161
  7. 오픈소스 의존성 락 · 내부 미러빌드 재현성 · 타이포스쿼팅 방어 · 중앙 리포지토리
    XZ Utils류 대비
  8. 업데이트 경로 무결성 검증업데이트 서버 인증·무결성 해시·롤백 절차
    M.E.Doc류 대비
  9. ConTI 피드 연동공급망 캠페인 IoC·탈취 인증서 해시 실시간 반영
    선제 탐지
  10. 침해 대응 SOP + 고객 공지 절차공급사 측 침해 공지 수신 시 영향 평가 · 격리 · 통보
    거버넌스

16 자주 묻는 질문 (FAQ)

Q1. 서명된 파일을 CDR로 처리하면 서명이 깨지지 않나요?
깨진다. CDR은 파일 구조를 재구성하므로 원본 서명은 무효화된다. 이것이 본질적으로 올바른 동작이다 — SolarWinds·3CX·ASUS 모두 "원본 서명이 유효했다"는 사실이 공격 성립의 핵심이었다. 필요 시 무해화된 파일에 조직 내부 서명을 다시 적용할 수 있다.
Q2. SBOM이 있으면 공급망 공격을 막을 수 있나요?
SBOM은 "무엇이 들어있는지"를 추적하는 도구이지 공격 자체를 차단하지 않는다. SolarWinds의 BusinessLayer.dll이 SBOM에 기재되어 있었어도, 내부에 백도어가 심어진 사실까지는 SBOM이 알려주지 않는다. SBOM + CDR + SLSA + Sigstore의 층위 방어가 필요하다.
Q3. SolarWinds 같은 빌드 임플란트를 CDR이 막나요?
CDR은 실행 파일(EXE·DLL·MSI)을 무해화하지 않는다. CDR의 역할은 협력사·파트너로부터 들어오는 문서·아카이브·PDF·HTML 파일의 구조 검증이다. 빌드 임플란트에는 SLSA·Sigstore·프로비넌스·빌드 격리가 1차 방어이며, CDR은 독립된 "업무 파일 채널"의 방어층이다.
Q4. 3CX 같은 이중 공급망에 대비하려면?
N-tier 공급망 가시성이 필요하다. 공급사의 공급사까지 SBOM을 요구하고, 침해 통지 SLA를 계약에 포함한다. 수신 측은 "신뢰된 공급사 파일이라도 CDR 게이트 예외 없음" 정책을 유지한다 — 신뢰하는 공급사 자체가 피해자일 수 있다.
Q5. XZ Utils 같은 오픈소스 공격도 CDR로 막나요?
직접 막지는 못한다. 오픈소스 공급망 방어는 다수 메인테이너·커뮤니티 리뷰·SLSA·의존성 스캐닝의 영역이다. 다만 XZ류 공격으로 엔드포인트가 침해됐을 때 "침해 단말에서 공격자가 이동하는 업무 문서"는 CDR 방어 범위에 포함된다.
Q6. 한국 아람CA·SKT 코드서명 탈취 보고는 공식 자료인가요?
Symantec·Mandiant·ESET 공개 APT 보고서에 한국 SW 개발사 및 일부 통신·IT 자회사 명의 인증서가 악용된 사례 관측이 있다[14]. 귀속 범위는 보고서별 상이하므로 법적 판단은 유보하고, 공통 지적된 한국 개발사의 코드서명 관리 관행(HSM 미사용·빌드 서버 공유) 개선이 실무 과제다.
Q7. WIZVERA VeraPort 공격은 재발 가능성이 있나요?
CISA AA21-022A가 제기한 구조적 문제는 "자동 설치 채널 자체가 공격 표면"이라는 점이다. 한국 특유의 금융·공공 플러그인 자동 설치 생태계에 내재된 모델 문제이므로 유사 패턴은 다른 도구에도 존재할 수 있다. 대응은 설치 패키지 서명 로그 투명화·해시 화이트리스트·사용자 단계 CDR의 병용.
Q8. 4제품(SLF·SLE·SLCDR·ConTI)을 공급망 맥락에서 어떻게 배치하나요?
채널별로 배치한다. SLE는 이메일 경유, SLF는 파일 서버·문서 중앙화, SLCDR은 웹 업로드·파트너 포털, ConTI는 공급망 IoC·탈취 인증서 경보를 위 세 제품에 피드백. PoC·BMT 단계에서 조직별 파일 유입 채널을 매핑해 커버리지를 산정한다.

✓ 결론 — "신뢰하지 않음"이 새로운 신뢰다

2010년 Stuxnet부터 2024년 XZ Utils까지 15년에 걸쳐 공급망 공격은 "서명된 파일은 안전하다"는 가정을 반복적으로 무너뜨렸다. SolarWinds는 빌드 파이프라인을, 3CX는 공급망의 공급망을, XZ Utils는 오픈소스 메인테이너 권한을, NotPetya는 업데이트 서버를, ASUS·CCleaner는 합법 서명 자체를, WIZVERA VeraPort는 국가 단위 자동 설치 채널을, APT10 CloudHopper는 MSP 관리 채널을 공격 경로로 사용했다.

정책 체계는 이에 대응해 진화했다. EO 14028이 SBOM 의무화를 명시하고, NIST SP 800-218 SSDF · SP 800-161 C-SCRM이 프레임을 제시했으며, OpenSSF의 Sigstore·SLSA가 커뮤니티 해법으로 자리잡았다. 한국도 K-SBOM 정책을 공공 조달에 반영하기 시작했다. 그러나 이들은 모두 공급사 측의 조치다. 수신 측 조직은 공급사 전부를 통제할 수 없다.

그래서 Zero Trust의 파일 수준 구현이 필요하다. CDR은 서명 유효성·송신자 신뢰도·출처 도메인을 무시하고 파일 내부 구조만을 검증한다. SBOM이 "무엇이 들어있는지"를 알려주고 SLSA가 "어떻게 빌드됐는지"를 증명하는 동안, CDR은 "무엇이 들어오든 실행되지 않도록" 한다. 세 층이 독립적이기 때문에 한 층이 뚫려도 조직은 버틴다. 공급망 공격 시대의 원칙은 하나로 수렴한다 — "신뢰하지 않고 검증한다". 시큐레터 4제품(SLF·SLE·SLCDR·ConTI)이 파일 유입의 모든 채널에서 같은 원리로 작동하도록 설계된 이유다.

공급망 공격 대응 준비도 진단

SBOM 수집 체계 점검 · 공급사 반입 파일 채널 매핑 · 4제품 배치 설계 · MSP·원격관리 경로 게이트 · EO 14028/K-SBOM 정합성 컨설팅까지 지원.

공급망 방어 진단 신청 → 공공 · 금융 · 대기업 · SW 개발사 맞춤 · SBOM 연동 · PoC·BMT 지원
REFERENCES
  1. FireEye/Mandiant, Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor, 2020.12.13 — mandiant.com.
  2. Mandiant, 3CX Software Supply Chain Compromise Initiated by a Prior Software Supply Chain Compromise; Suspected North Korean Actor Responsible, 2023.4.20 — mandiant.com.
  3. Andres Freund, backdoor in upstream xz/liblzma leading to ssh server compromise, oss-security mailing list, 2024.3.29 — openwall.com.
  4. Symantec Security Response, W32.Stuxnet Dossier v1.4, 2011.2 — Realtek/JMicron 코드서명 인증서 악용 기술 — broadcom.com.
  5. CISA, Alert AA21-022A — North Korean Malicious Cyber Activity: AppleJeus 및 WIZVERA VeraPort 관련 ESET 보고 인용, 2021.1.22 — cisa.gov.
  6. The White House, Executive Order 14028 on Improving the Nation's Cybersecurity, 2021.5.12 — whitehouse.gov.
  7. MITRE ATT&CK, T1195 Supply Chain Compromise · T1553.002 Subvert Trust Controls: Code Signing — attack.mitre.org/T1195, T1553.002.
  8. CISA, Alert AA20-352A — Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations, 2020.12.17 — cisa.gov.
  9. NVD, CVE-2024-3094 — XZ Utils Backdoor (CVSS 10.0) — nvd.nist.gov.
  10. OpenSSF, Sigstore — A new standard for signing, verifying and protecting software — sigstore.dev.
  11. Andy Greenberg (Wired), The Untold Story of NotPetya, the Most Devastating Cyberattack in History, 2018.8.22 — wired.com.
  12. Cisco Talos, CCleanup: A Vast Number of Machines at Risk, 2017.9.18 — talosintelligence.com.
  13. Kaspersky GReAT, Operation ShadowHammer, Securelist 2019.3.25 — securelist.com.
  14. Symantec Threat Hunter Team, Lazarus Group: Stolen Code-Signing Certificates Abused in Targeted Attacks 및 Mandiant APT38 보고서 — mandiant.com/apt38.
  15. Novetta, Operation Blockbuster — Unraveling the Long Thread of the Sony Attack, 2016.2.24 — operationblockbuster.com.
  16. ESET Research, Lazarus supply-chain attack in South Korea, WeLiveSecurity 2020.11.16 — welivesecurity.com.
  17. PwC UK & BAE Systems, Operation Cloud Hopper, 2017.4 — pwc.co.uk.
  18. U.S. Department of Justice, Two Chinese Hackers Associated With the Ministry of State Security Charged With Global Computer Intrusion Campaigns (APT10), 2018.12.20 — justice.gov.
  19. NIST, SP 800-218 Secure Software Development Framework (SSDF) v1.1, 2022.2 — csrc.nist.gov/sp/800-218.
  20. NIST, SP 800-161 Rev.1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, 2022.5 — csrc.nist.gov/sp/800-161.
  21. Linux Foundation, SPDX — ISO/IEC 5962:2021 International Standard for SBOM — spdx.dev.
  22. OWASP, CycloneDX Bill of Materials Standard — cyclonedx.org.
  23. KISA, K-SBOM 가이드라인 및 공공 SW 공급망 보안 정책 — kisa.or.kr.
  24. OpenSSF, SLSA — Supply-chain Levels for Software Artifacts v1.0 — slsa.dev.
  25. CISA, Software Bill of Materials (SBOM) — cisa.gov/sbom.
  26. ENISA, Threat Landscape for Supply Chain Attacks, 2021.7 — enisa.europa.eu.
  27. CrowdStrike, 3CX Supply Chain Attack Technical Analysis, 2023.3.29 — crowdstrike.com.
  28. SentinelOne Labs, SmoothOperator · 3CX Campaign Analysis, 2023.3.29 — sentinelone.com.
  29. SecuLetter Inc., MARS Platform · File Security Technology — seculetter.com.
  30. SecuLetter Inc., Ensecure v2 · DISARM Solution Introduction KO, 2025.
관련 글
Zero Trust
Zero Trust 파일 보안 — 신뢰하지 않고 검증하는 아키텍처
정책
K-SBOM 정책과 공공 SW 공급망 보안
TTP
MITRE ATT&CK T1195 공급망 공격 TTP 해부

공급망 보안 실무 검토가 필요하신가요?

시큐레터 보안연구팀이 현재 환경을 함께 검토합니다. 기밀 유지 보장, 비용 없음.

PoC 신청
관련 포스트
L3 · 실무 공공 · N2SF 대응 · L3

N2SF CDR 매핑 가이드 / 260개 통제항목 체크리스트

국정원 N2SF 1.0의 260개 통제항목 중 CDR이 직접 담당하는 영역을 매핑했다. 민감등급 문서 반입 통제, 망간 파일 전송, 3등급 분류까지 공공기관 정보보호 담당자가 실제로 쓸 체크리스트.

2026-04-21 18분 읽기 →
L2 · 기술 기술 비교 · L2

CDR vs 샌드박스 vs AV / 2026 3자 비교 매트릭스

파일 보안 기법 3가지를 한 표에 올렸다. 탐지율·회피 내성·처리 속도·운영 비용·제로데이 대응까지 12개 기준으로 비교. 어떤 조직에 어떤 조합이 맞는지, 실제 구매 현장에서 쓰는 기준으로 정리한다.

2026-04-21 14분 읽기 →
L1 · 입문 CDR 카테고리 교육 · L1

탐지를 전제로 한 보안의 한계, / CDR은 판정하지 않는다

CDR(Content Disarm and Reconstruction)은 "악성인지 판단하는" 보안이 아니다. 탐지 패러다임의 구조적 한계, CDR의 3단계 원리, 리버스엔지니어링 분석과의 조합, 공공·금융·엔터프라이즈 적용 현황을 공식 자료와 공개 출처에 근거해 정리한다.

2026-04-15 22분 읽기 →