[Knight Frontier] BoB 프로젝트 탐구 - 블록체인 기반의 공급망 공격 탐지 툴 제작

주제 선정 이유

요즘 npm에서 패키지 하나 설치하면 수백 개의 의존성이 딸려온다. npm install express 하나만 쳐도 200개가 넘는 패키지가 깔린다. 그 중 하나라도 악성 코드가 숨어있다면? 2021년 ua-parser-js 사건처럼 정상 패키지가 갑자기 악성 버전으로 업데이트되면 그 패키지를 사용하는 수백만 프로젝트가 순식간에 감염된다.

 

문제는 우리가 이 패키지들을 맹목적으로 신뢰한다는 것이다. 수백만 다운로드, GitHub 스타 수천 개면 안전하다고 착각한다. 하지만 메인테이너 계정이 해킹되거나, 악의적인 기여자가 교묘하게 백도어를 심을 수 있다. 2018년 event-stream 사건은 공격자가 몇 달간 정상적으로 기여하면서 신뢰를 쌓은 후, 특정 암호화폐 지갑만 타겟으로 하는 코드를 몰래 삽입한 사례다.

 

블록체인의 불변성과 투명성이 이 문제의 해결책이 될 수 있다고 생각했다. 패키지의 전체 생명주기를 블록체인에 기록하면 누가 언제 어떤 코드를 추가했는지, 빌드 프로세스가 정상인지, 전달 과정에서 변조되지 않았는지 검증할 수 있다. 특히 웹3 생태계 자체가 npm을 통한 공격에 취약한 상황이라(지갑 private key 탈취 시도 등), 블록체인으로 블록체인 생태계를 보호한다는 아이러니가 흥미롭다.

 

주제 관련 기반 지식

1. 소프트웨어 공급망과 공격 벡터

소프트웨어 공급망은 코드 작성부터 최종 사용자 배포까지의 전체 과정을 의미한다. 개발자가 IDE에서 코드를 작성하고, Git에 커밋하고, CI/CD로 빌드하고, 패키지 레지스트리에 배포하고, 사용자가 다운로드하는 각 단계마다 공격 지점이 존재한다. 전통적인 보안이 애플리케이션 자체를 보호한다면, 공급망 보안은 그 애플리케이션이 만들어지는 전 과정을 보호한다.

 

공급망 공격이 특히 위험한 이유는 신뢰의 연쇄를 악용하기 때문이다. 개발자는 npm을 신뢰하고, npm 패키지를 신뢰하고, 그 패키지의 의존성도 신뢰한다. 이 신뢰 사슬의 어느 한 곳이라도 깨지면 전체가 무너진다. 또한 공급망 공격은 탐지가 어렵다. 악성 코드가 정상 빌드 프로세스를 통해 들어오기 때문에 기존 보안 도구로는 잡아내기 힘들다.

 

가. 의존성 혼동 (Dependency Confusion) 공격

기업들은 보통 내부 패키지 레지스트리와 공개 레지스트리(npm, PyPI)를 함께 사용한다. 내부 프로젝트에서만 쓰는 패키지는 내부 레지스트리에 올리지만, 그 이름이 공개적으로 알려지면 공격자가 같은 이름으로 공개 레지스트리에 악성 패키지를 올릴 수 있다. 패키지 매니저는 기본적으로 버전이 높은 쪽을 선택하므로, 공격자가 9999.9.9 같은 극단적으로 높은 버전을 설정하면 내부 패키지 대신 악성 패키지가 설치된다.

• 공격 메커니즘: 공격자는 LinkedIn, GitHub 등에서 기업의 내부 패키지 이름을 수집한다. 개발자들이 실수로 package.json을 공개 저장소에 올리는 경우가 많기 때문이다.
• 피해 사례: 2021년 보안 연구자 Alex Birsan은 이 기법으로 Microsoft, Apple, Netflix 등 35개 기업의 내부 네트워크에 침투할 수 있음을 입증했다. 총 13만 달러의 버그 바운티를 받았다.
• 방어 방법: 내부 레지스트리를 우선시하도록 설정하거나, 내부 패키지 이름을 scope로 구분한다(@company/package-name). 또는 공개 레지스트리에 placeholder를 먼저 올려 이름을 선점한다.

나. 타이포스쿼팅 (Typosquatting)

인기 있는 패키지 이름과 비슷하지만 철자가 살짝 다른 이름으로 악성 패키지를 등록하는 수법이다. 개발자의 오타를 노린다. 예를 들어 crossenv 대신 cross-env, babelcli 대신 babel-cli 같은 식이다.

• 실제 사례: 2017년 연구자들이 214개의 typosquatting 패키지를 발견했다. 이 중 일부는 환경 변수를 외부 서버로 전송하는 코드가 있었다.
• 자동화 공격: 공격자는 인기 패키지 Top 1000의 모든 가능한 오타 조합을 자동 생성해 패키지를 등록한다. 심지어 실제 패키지의 기능을 그대로 제공하면서 백도어만 추가하는 경우도 있다.
• 탐지의 어려움: 패키지가 실제 기능을 정상적으로 수행하면 개발자는 악성 여부를 눈치채기 어렵다. 악성 코드가 특정 조건에서만 실행되도록 만들면 더욱 은밀하다.

다. 계정 탈취 및 패키지 하이재킹

정상적으로 운영되던 인기 패키지의 메인테이너 계정을 해킹하거나 사회공학으로 접근 권한을 얻어, 악성 버전을 배포하는 방식이다. 이미 신뢰받는 패키지이기 때문에 사용자들이 의심 없이 업데이트한다.

• ua-parser-js 사건 (2021): 월 700만 다운로드의 인기 패키지가 해킹당해 암호화폐 채굴 코드가 포함된 버전이 배포되었다. 수시간 내에 수백만 시스템이 감염되었을 것으로 추정된다.
• event-stream 사건 (2018): 공격자가 먼저 오픈소스 기여자로 신뢰를 쌓은 후, 지친 메인테이너로부터 관리 권한을 넘겨받았다. 그 후 flatmap-stream이라는 의존성을 추가했는데, 여기에 특정 비트코인 지갑을 타겟으로 하는 코드가 숨어있었다.
• 방어의 어려움: 메인테이너는 보통 개인 개발자로 2FA 같은 보안 조치가 부족한 경우가 많다. npm은 2019년부터 상위 패키지에 2FA를 강제하기 시작했지만 모든 패키지에 적용되지는 않는다.

 

2. SBOM (Software Bill of Materials)

SBOM은 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 의존성의 목록과 각각의 버전, 라이선스, 출처 등을 명시한 문서다. 마치 식품의 성분표처럼 소프트웨어에 무엇이 들어있는지 투명하게 보여준다. 최근 Log4Shell 같은 대규모 취약점이 발견됐을 때, SBOM이 있으면 영향받는 시스템을 빠르게 식별할 수 있다.

 

미국 바이든 행정부는 2021년 사이버보안 행정명령(EO 14028)에서 연방정부에 소프트웨어를 공급하는 모든 업체에게 SBOM 제공을 의무화했다. 이는 공급망 보안이 국가 안보 차원의 문제로 인식되고 있음을 보여준다.

• SPDX (Software Package Data Exchange): Linux Foundation이 관리하는 ISO 표준 포맷. 라이선스 컴플라이언스에 초점을 맞췄지만 보안 정보도 포함할 수 있다.
• CycloneDX: OWASP에서 개발한 경량 포맷. 보안 취약점 정보(VEX)를 포함하도록 설계되어 DevSecOps에 적합하다.
• SBOM 생성 도구: Syft, Trivy 같은 도구들이 컨테이너 이미지나 파일 시스템을 스캔해 자동으로 SBOM을 생성한다. 하지만 런타임에 동적으로 로드되는 의존성은 놓칠 수 있다.

 

3. SLSA (Supply-chain Levels for Software Artifacts)

SLSA는 Google이 주도하는 공급망 보안 프레임워크로, 소프트웨어가 얼마나 안전하게 빌드되었는지를 4단계 레벨로 정의한다. 레벨이 높을수록 공급망 공격에 대한 저항력이 강하다.

• Level 0: 아무런 보증이 없는 상태. 대부분의 오픈소스 프로젝트가 여기 해당한다.
• Level 1: 빌드 프로세스가 자동화되고 출처(provenance) 정보가 생성된다. 하지만 변조 방지는 없다.
• Level 2: 서명된 출처 정보로 빌드의 무결성을 검증할 수 있다. 호스팅 플랫폼(GitHub Actions 등)이 신뢰의 기반이 된다.
• Level 3: Hermetic 빌드 환경에서 재현 가능한 빌드가 이루어진다. 외부 네트워크 접근이 차단되어 빌드 과정 중 악성 코드 주입이 불가능하다.
• Level 4: Two-party review를 거친다. 모든 코드 변경이 최소 두 명의 승인을 받아야 한다. 단일 개발자가 악의적 코드를 삽입하기 어렵다.

블록체인은 SLSA의 여러 요구사항, 특히 출처 정보의 불변성과 검증 가능성을 자연스럽게 만족시킬 수 있다.

 

4. Sigstore - 소프트웨어 서명의 민주화

전통적으로 소프트웨어 서명은 GPG 키 같은 걸 사용했는데, 키 관리가 복잡하고 일반 개발자들이 접근하기 어려웠다. Sigstore는 이를 단순화해 누구나 쉽게 소프트웨어에 서명하고 검증할 수 있게 만든 오픈소스 인프라다.

• Cosign: 컨테이너 이미지 서명 도구. cosign sign 명령 한 줄이면 이미지에 서명할 수 있다. 키를 미리 생성하지 않아도 OIDC로 임시 인증서를 받는다.
• Rekor: 투명성 로그 (Transparency Log). 모든 서명이 불변 로그에 기록되어 나중에 누구나 검증할 수 있다. Certificate Transparency와 비슷한 개념이다.
• Fulcio: 단명 인증서 CA. Google, GitHub, Microsoft 같은 OIDC 제공자로 인증하면 10-20분간 유효한 코드 서명 인증서를 발급한다. 키 관리 부담이 사라진다.
• 블록체인과의 차이: Rekor는 Merkle Tree 기반의 로그지만 중앙화된 서버에서 운영된다. 블록체인은 완전히 탈중앙화되어 단일 실패점이 없다는 장점이 있지만, 비용과 확장성에서는 Rekor가 유리하다.

 

5. 분산 저장소 - IPFS와 Arweave

블록체인에 모든 패키지 코드를 저장하는 건 비현실적이다. 이더리움은 바이트당 20,000 가스가 들어 수 MB 파일 하나 저장하는 데 수천 달러가 든다. 대신 파일은 분산 저장소에 저장하고, 블록체인에는 해시값과 메타데이터만 기록하는 하이브리드 접근이 필요하다.

 

가. IPFS (InterPlanetary File System)

IPFS는 콘텐츠 주소 지정(Content Addressing)을 사용하는 P2P 파일 시스템이다. 파일의 내용을 해시한 값이 주소가 되므로, 내용이 바뀌면 주소도 바뀐다. 이는 무결성 검증에 완벽하다.

• 동작 방식: 파일을 IPFS에 추가하면 CID(Content Identifier)를 받는다. 이 CID로 네트워크의 어느 노드에서든 파일을 가져올 수 있다. 파일은 여러 노드에 분산 저장된다.
• 패키지 무결성: 블록체인에 ipfs://Qm... 형태의 CID를 저장하면, 사용자는 패키지를 다운로드한 후 해시를 계산해 CID와 비교함으로써 변조 여부를 확인할 수 있다.
• 영속성 문제: IPFS는 기본적으로 캐시다. 아무도 파일을 호스팅하지 않으면 사라진다. Pinning Service(Pinata, Filebase 등)를 사용하거나 Filecoin으로 영구 저장을 보장해야 한다.

나. Arweave - 영구 저장소

Arweave는 한 번 비용을 지불하면 데이터가 최소 200년 이상 저장되는 것을 목표로 하는 블록체인 기반 저장소다. 스토리지 비용의 지속적 감소를 가정한 경제 모델(Endowment)을 사용한다.

• Blockweave 구조: 일반 블록체인과 달리 각 블록이 이전 블록뿐 아니라 과거의 무작위 블록과도 연결된다. 이를 통해 전체 데이터를 유지하도록 인센티브를 제공한다.
• 비용 모델: 초기에 한 번 비용을 지불하면 끝이다. 200년 저장 비용을 미리 예측해 받는다. 1GB당 약 7달러 수준이다 (2024년 기준).
• 패키지 저장소 응용: npm 패키지의 모든 버전을 Arweave에 저장하면 영원히 접근 가능한 불변 기록이 된다. 패키지가 unpublish되어도 역사가 보존된다.

 

프로젝트 진행 과정 예상

프로젝트를 시작한다면 먼저 공급망 공격의 실제 사례들을 심층 분석할 것이다. 공격자가 어떤 경로로 침투했는지, 어느 단계에서 막을 수 있었는지, 피해 규모는 어땠는지를 정리한다. 이를 통해 우선적으로 방어해야 할 공격 벡터를 식별한다.

 

다음으로 블록체인 아키텍처를 설계한다. 온체인에는 무엇을 저장하고 오프체인에는 무엇을 저장할지 결정해야 한다. 나는 다음과 같은 구조를 고려할 것이다:

• 온체인: 패키지 메타데이터(이름, 버전, 설명), 파일 해시(IPFS CID), 메인테이너 DID, 서명, 타임스탬프
• 오프체인: 실제 패키지 코드(IPFS/Arweave), 상세한 빌드 로그, 의존성 그래프

스마트 컨트랙트는 다음 기능을 구현한다:

1. 패키지 등록: 새 패키지를 블록체인에 등록. 초기 메인테이너 설정.
2. 버전 배포: 새 버전 추가 시 파일 해시와 서명 기록. 이전 버전은 불변으로 유지.
3. 권한 관리: 메인테이너 추가/제거. 멀티시그나 DAO 투표로 중요 패키지 보호.
4. 검증 요청: 사용자가 다운로드한 파일의 해시를 온체인 기록과 비교.

탐지 도구는 여러 레이어로 구성한다:

• CLI 도구: npm install wrapper로 동작. 패키지 설치 전 블록체인 조회해 서명 검증. 알려진 악성 패키지 블랙리스트와 비교.
• CI/CD 플러그인: GitHub Actions, GitLab CI에 통합. 전체 의존성 트리를 스캔하고 보고서 생성.
• 모니터링 대시보드: 실시간으로 새 패키지 등록을 감시. 타이포스쿼팅 패턴 탐지, 급작스러운 메인테이너 변경 알림.

ML 기반 이상 탐지도 추가한다. 패키지의 정상적인 행동 패턴을 학습한다:

• 다운로드 추이 (급증/급감 탐지)
• 코드 변경 빈도와 크기
• 새로 추가된 의존성
• 네트워크 통신 코드 추가
• 난독화된 코드 포함

이상 징후가 감지되면 자동으로 경고를 발생시키고, 심각한 경우 커뮤니티 투표를 통해 패키지를 격리할 수 있다.

 

예상 시행착오

가장 큰 도전은 확장성과 비용이다. npm에는 매주 수만 건의 패키지 업데이트가 일어난다. 이 모든 걸 이더리움 메인넷에 기록하면 가스비가 천문학적으로 늘어난다. 레이어 2 솔루션(Optimism, Arbitrum)을 사용하거나, 배치 처리로 여러 업데이트를 한 트랜잭션에 묶거나, 심지어 별도의 사이드체인을 구축하는 것도 고려해야 한다.

 

사용자 경험도 큰 고민이다. 대부분의 개발자는 블록체인 지갑이 없고, 가스비를 내고 싶어 하지 않는다. Meta-transaction을 사용해 가스비를 프로젝트에서 대신 지불하거나, 무료로 읽기만 하고 쓰기는 패키지 메인테이너만 하도록 제한할 수 있다. 또는 초기에는 중요한 상위 1000개 패키지만 온보딩하고 점진적으로 확대하는 전략도 가능하다.

 

기존 생태계와의 통합도 어려울 것이다. npm, PyPI 같은 기존 레지스트리들이 협력하지 않으면 parallel 시스템이 되어 채택률이 낮아진다. 기존 레지스트리의 미러 역할을 하면서 추가적인 검증 레이어를 제공하는 방식이 현실적일 수 있다.

 

주제 조사 후 느낀 점

이 주제를 깊이 파고들수록 공급망 공격이 단순히 기술적 취약점을 악용하는 게 아니라 신뢰 관계를 악용하는 사회공학이란 걸 깨달았다. event-stream 공격자는 몇 달간 정상적으로 기여하면서 커뮤니티의 신뢰를 얻었다. 기술적으로는 아무 문제가 없었다. 문제는 사람과 프로세스였다.

 

블록체인이 만능은 아니라는 것도 배웠다. 블록체인은 "무엇이 일어났는가"를 투명하게 기록하지만, "그것이 올바른가"를 자동으로 판단하지는 못한다. 악성 코드가 정상적인 프로세스를 통해 서명되어 블록체인에 기록될 수 있다. 따라서 블록체인은 전체 보안 전략의 한 부분이어야 하고, 코드 리뷰, 정적 분석, 샌드박스 테스팅 같은 다른 방어 계층과 결합되어야 한다.

 

가장 인상 깊었던 건 이 문제가 기술뿐 아니라 거버넌스와 인센티브 설계의 문제라는 점이다. 누가 패키지를 검증할 것인가? 검증자에게 어떤 보상을 줄 것인가? 악의적인 정보를 제공하는 노드를 어떻게 처벌할 것인가? 이런 질문들은 순수하게 기술적으로만 답할 수 없고, 경제학과 게임 이론을 요구한다. 암호경제학(cryptoeconomics)이 단순한 유행어가 아니라 실제로 필요한 학문임을 깨달았다.

 

https://slsa.dev/

Supply-chain Levels for Software Artifacts

 

https://docs.sigstore.dev/cosign/signing/overview/

Overview