GOTROOT / 리서치

공급망 보안과 오픈소스 취약점 관리 — 우리가 ‘기대고 있는 것들’은 안전한가 | GOTROOT

오픈소스 의존성과 전이 의존성에 숨은 취약점, 공급망 공격 유형(타이포스쿼팅·의존성 혼동·전이 CVE), SBOM으로 무엇을 쓰는지 파악하기, 그리고 ‘버전’이 아니라 실제 악용 가능성을 APT 관점으로 검증하는 법을 정리했습니다.

GOTROOT 리서치 팀 2026. 6. 5.

요즘 소프트웨어를 만드는 일은 ‘작성’보다 ‘조립’에 가깝습니다. 우리가 직접 쓴 코드는 사실 일부고, 나머지 대부분은 오픈소스 라이브러리와 그 라이브러리가 또 끌어오는 의존성으로 채워집니다. 편리한 만큼, 공격자도 우리가 직접 만든 코드보다 우리가 신뢰하는 ‘부품’을 노리는 쪽이 효율적이라는 걸 압니다. 이 글은 공급망 보안과 오픈소스 취약점 관리를, 점검 현장의 관점에서 차분히 정리한 글입니다.

내 코드보다 많은, 남의 코드

직접 설치한 라이브러리(직접 의존)는 눈에 보이지만, 그 라이브러리가 또 끌어오는 ‘전이 의존성(transitive dependency)’은 잘 보이지 않습니다. 정작 위험은 이 보이지 않는 깊은 곳에서 자주 나옵니다. 아래는 점검에서 흔히 마주치는 모양입니다.

your-app
├─ web-framework@2.4
│    └─ json-parser@1.1          ← 직접 의존 (내가 설치)
│         └─ legacy-utils@0.9    ← 전이 의존 (설치한 적 없는데 따라옴)
│              └─ [CVE-20XX-XXXX] 역직렬화 RCE   ★ 위험은 여기
└─ image-lib@3.2
     └─ native-decoder@0.5       ← 알려진 버퍼 오버플로

legacy-utils@0.9는 아무도 직접 설치하지 않았지만, 세 단계 아래에서 조용히 들어와 있습니다. “우리가 뭘 쓰고 있는지조차 모른다”는 게 공급망 보안의 첫 번째 어려움입니다.

공급망 공격은 이런 길로 들어옵니다

유형	한 줄 설명
전이 의존성 CVE	깊은 곳의 오래된 패키지에 알려진 취약점이 남아 있음
타이포스쿼팅	유명 패키지와 비슷한 이름의 악성 패키지를 실수로 설치
의존성 혼동(confusion)	내부 패키지명을 공개 저장소에 올려 빌드가 그쪽을 당겨오게 함
계정 탈취된 패키지	정상 패키지의 새 버전에 악성 코드가 심김
빌드 파이프라인 침해	CI/CD나 빌드 도구를 통해 산출물에 코드가 주입됨

SBOM — 일단 ‘무엇을 쓰는지’부터

관리의 출발점은 목록입니다. SBOM(Software Bill of Materials)은 “이 소프트웨어가 어떤 컴포넌트와 버전으로 이루어져 있는가”의 명세서입니다. 무엇을 쓰는지 알아야, 새 취약점이 공개됐을 때 “우리가 영향받는가”를 몇 분 안에 답할 수 있습니다.

# 1) 무엇을 쓰는지 목록화 (SBOM 생성)
syft dir:. -o cyclonedx-json > sbom.json

# 2) 알려진 취약점과 대조
grype sbom:sbom.json
osv-scanner --sbom sbom.json
# 결과: 컴포넌트 → 버전 → 해당 CVE → 심각도

버전만 보지 않습니다 — 실제로 악용되는가

스캐너는 “이 버전은 취약합니다”까지 알려줍니다. 하지만 그게 ‘우리 환경에서 실제로 악용되는가’는 또 다른 질문입니다. 취약한 함수가 실제 호출 경로에 있는지(도달 가능성), 외부 입력이 거기까지 닿는지를 봐야 우선순위가 정해집니다. 그래서 저희는 점검에서 식별된 컴포넌트를 1-day 관점으로 한 번 더 확인합니다 — 공개된 패치를 거꾸로 읽어, 이 설정에서 실제로 익스플로잇이 되는지 통제된 범위에서 증명하는 거죠. 실제 표적 공격(APT)이 노리는 지점이 정확히 여기라서요. (발굴 과정은 0-day는 어떻게 발굴되는가, 점검 흐름은 모의해킹 진행 글에 이어집니다.)

한 번이 아니라, 계속 이어가기

SBOM을 빌드마다 갱신해, 새 CVE가 나오면 ‘우리가 영향받는지’를 자동으로 답하게 하기
‘버전 낮음’의 수가 아니라, 도달 가능성·외부 노출 기준으로 우선순위 잡기
새 의존성 추가 시 출처·서명·평판을 확인하는 가벼운 정책 두기

현장 노트: 사고 후 “어떻게 들어왔나”를 추적하다 보면, 정작 진입로가 3년 전 누군가 추가한 전이 의존성인 경우가 많습니다. 누구의 잘못도 아니에요. 그래서 ‘무엇을 쓰는지’를 평소에 알고 있는 것만으로도 대응 속도가 확 달라집니다.

자주 묻는 질문

의존성 스캐너를 이미 쓰고 있는데, 또 필요한가요?

스캐너로 ‘목록과 알려진 CVE’를 잡는 건 훌륭한 출발입니다. 거기에 ‘실제 우리 환경에서 악용되는가’를 사람이 확인하는 한 겹이 더해지면, 어떤 것부터 고쳐야 할지가 분명해집니다.

오픈소스를 안 쓰면 안전한가요?

현실적으로 오픈소스를 완전히 피하긴 어렵고, 그럴 필요도 없습니다. 핵심은 ‘무엇을 쓰는지 알고, 빠르게 대응할 수 있는 체계’를 갖추는 것입니다.

마치며

우리가 기대고 있는 부품이 안전한지 아는 것은, 이제 보안의 기본기에 가깝습니다. 우리 서비스의 컴포넌트와 의존성을 APT 관점으로 함께 점검해 보고 싶으시면 모의해킹 상담으로 편하게 연락 주세요. ‘무엇을 쓰는지’부터 차분히 같이 살펴보겠습니다.