[OWASP 시리즈] OWASP Top10 2025 RC A03, 소프트웨어 공급망의 균열, 이제는 조직 전체의 리스크다
![[OWASP 시리즈] OWASP Top10 2025 RC A03, 소프트웨어 공급망의 균열, 이제는 조직 전체의 리스크다](https://images.unsplash.com/photo-1590497008432-598f04441de8?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDIzfHxzdXBwbHklMjBjaGFpbiUyMGZhaWx1cmV8ZW58MHx8fHwxNzY0NzQ1NTY1fDA&ixlib=rb-4.1.0&q=80&w=1200)
OWASP가 공개한 Top10 2025 RC에서 확인할 수 있는 변화 중 하나는 기존 OWASP Top10 2021 A06 ‘취약하고 오래된 구성요소(Vulnerable and Outdated Components)’가 OWASP Top10 2025 RC A03: Software Supply Chain Failures라는 더 넓은 개념으로 재정의되었다는 것이다. 이는 단순한 명칭 변경이 아닌소프트웨어 개발, 배포 전 과정에서 발생하는 위협을 포함하는 방향으로 범위를 확장한 것이다. 이와 같은 변화가 제시하는 방향성은 조직은 개별 라이브러리의 취약성을 포함한 소프트웨어 개발, 배포의 모든 경로상에 있는 것들을 모두 공격 표면으로 인식하고 대응해야 한다는 것이다. 이 글에서는 OWASP Top10 2025 RC A3의 의미, A06에서 A03로의 변화 배경, 2025년 새롭게 포함된 CWE 분석, 그리고 실제 보안 대응 전략까지 종합적으로 정리한다.
A03: Software Supply Chain Failures - 문제의 원인 분석
OWASP는 소프트웨어 공급망 실패를 “소프트웨어의 개발, 배포, 업데이트 등의 모든 소프트웨어 생애주기에서 발생하는 모든 위협”으로 판단하고 있다. 보다 세부적으로 언급하자면 코드 작성 단계뿐 아니라 개발자가 사용하는 IDE, 로컬 환경, 빌드 서버, 아티팩트 저장소, 서드파티 패키지, 프레임워크, 컨테이너 이미지, 운영 플랫폼까지 소프트웨어와 관련된 모든 요소들과 관련된 것들을 공급망의 일부로 바라본다는 것이다. 이와 같은 관점에서 A03에서 언급하는 내용을 정리하면 다음과 같다.
1) 구성요소 버전, 의존성 미추적
이제는 소프트웨어를 만들더라도 코드를 처음부터 끝까지 개발하는 경우는 거의 없다. 즉, 모든 소프트웨어에는 외부에서 개발한 라이브러리와 그 라이브러리가 사용하는 다른 라이브러리까지 이어지는 모습을 쉽게 확인할 수 있다. 이러한 상황이라면 소프트웨어는 수십~수백 개의 라이브러리와 종속성을 갖게 되며 그 복잡성은 기하급수적으로 증가한다.
우리가 사용하는 소프트웨어의 경우 직접 사용하는 라이브러리뿐 아니라 2차·3차로 연결되는 ‘중첩(Transitive) 의존성’까지 확인하지 않으면, 취약한 코드가 어느 경로로 유입되어 어디까지 영향을 미치는지 파악조차 어려운 상황에 도달할 것이다. 바로 이와 같은 논리가 소프트웨어 공급망에 의한 실패를 불러오는 중요한 요인이며 가장 중요한 내용으로 소프트웨어 공급망 보안을 위해 항상 염두해야 하는 내용이다. 사실 이후 언급하는 내용은 하나하나가 중요하지만 세부적인 사례를 설명하는 것으로 이해하면 충분하며 본질은 복잡한 종속성의 문제가 가장 큰 부분이라 할 수 있다.
2) 취약·지원 종료(EOL)·업데이트 불가 컴포넌트 사용
의존성이 복잡할수록 오래되었거나 지원 종료(EOL) 된 구성요소가 포함될 가능성도 커진다. 지속적인 패치가 제공되지 않는 OS, DBMS, 라이브러리는 취약점이 발견되는 즉시 공격에 노출될 수밖에 없다.
예를 들어 마이크로소프트 Windows는 EOS 시점이 다가오면 광범위하게 공지되지만, 대부분의 오픈소스 라이브러리는 이러한 관리 체계가 없다. 심지어 패치가 제공되더라도 자동 업데이트 기반의 적용 경로가 없거나, 레거시 환경에서는 적용 자체가 실패하기도 한다. 결국 많은 조직이 패치가 불가능하거나 정상 동작이 보장되지 않는 구성요소를 그대로 사용하게 되고, 이는 공급망 실패의 전형적인 원인이 된다.
3) 취약성 스캐닝 및 보안 공지 모니터링 미흡
CVE 등의 취약점 모니터링은 공급망 보안의 기본이지만, 실제 조직 환경에서는 후순위로 밀리는 경우가 많다. 국내의 경우 거버넌스 중심의 점검 비중이 크고 대부분 비지니스 로직 자체를 대상으로 하기 때문에, 최신 취약점 분석·검증 역량이 내부적으로 축적되지 않는다.
또한 조직이 직접 PoC/익스플로잇을 확보해 검증하기에는 기술 난이도와 비용 부담이 높다. 이로 인해 우리는 단순 스캐닝 결과에 의존하거나, 최신 취약점이 발표되었음에도 영향 분석이 이루어지지 않는 ‘사후 대응 구조’가 일반적이다.
특히 공급망 구조에서는 자체 코드뿐 아니라 수십 개의 서드파티 라이브러리 취약점까지 추적해야 하므로 난이도는 더 증가한다. 대표적으로 Log4Shell, OpenSSL 취약점은 사용 중인 구성요소를 정확히 파악하지 못하는 상태가 어떤 재앙으로 이어지는지를 보여주는 사례다. SBoM(Sofware Bill of Materials) 기반의 분석 없이 취약점 모니터링을 수행하는 것은 사실상 공급망 전체를 ‘블라인드 상태’로 운영하는 것과 같다.
4) 공급망에서의 변경 관리(change management) 부재
소프트웨어 공급망은 개발 환경, 코드 저장소, 빌드 도구, CI/CD 파이프라인, 컨테이너 베이스 이미지와 같은 수많은 요소가 상시적으로 업데이트되고 변경되는 지속적 변화 시스템이다. 그러나 이러한 변화는 자동화된 파이프라인 내에서 비동기적으로 발생하기 때문에, 많은 조직이 변경의 출처·의도·영향을 추적하지 못한다.
이와 같은 비가시성이 생기는 순간 공격자에게 기회가 열린다. 악성 기능을 수반하는 코드 또는 도구 등이 정상 업데이트처럼 빌드 파이프라인을 통과하면, 조직 스스로가 공격자가 심어놓은 악성 코드를 최종 제품에 포함해 사용자에게 배포하는 구조가 만들어질 수 있다. SolarWinds 사태는 이러한 ‘변경 관리 사각지대’가 어떻게 대규모 공급망 공격으로 이어지는지 명확히 보여주는 대표적 사례다.
5) 공급망 구성요소의 접근 통제 미흡
소프트웨어 공급망은 패키지 매니저(npm, PyPI), 코드 저장소, 내부 아티팩트 저장소, CI/CD, 컨테이너 레지스트리 등 다단계 체인으로 구성되어 있다. 이 중 한 지점이라도 접근 통제가 미흡하면 악성 패키지 하나가 전체 공급망을 오염시킬 수 있다.
특히 npm·PyPI처럼 누구나 패키지를 등록할 수 있는 오픈 레지스트리는 악성 코드 유입의 주요 경로다. 실제 여러 악성 패키지는 개발자의 로컬 환경을 넘어 빌드 서버까지 침투해 문제를 일으켰다. 이는 공격자가 배포한 악성 패키지의 유입 한 번만으로 공급망 전체를 장악할 수 있다는 것을 보여준다.
6) 패치 지연 및 호환성 테스트 부족
공급망 취약점은 신속하게 대응해야 하지만, 많은 조직은 여전히 월 단위·분기 단위 패치 주기를 유지한다. 최신 취약점이 등장하는 속도에 비해 지나치게 느린 대응이다. 또한 라이브러리 업데이트가 서비스에 미치는 영향을 우려해 호환성 테스트를 충분히 수행하지 못하면 업데이트는 계속 지연되고 취약점은 방치된다.
테스트 자동화가 미비하거나 의존성이 복잡한 환경일수록 이러한 지연은 심해진다. 결국 패치 지연은 단순 운영 문제가 아니라 공급망 전체의 공격 노출 시간을 비정상적으로 늘리는 구조적 위험 요소가 된다.
결국 공급망 구성요소 접근 통제는 단순한 보안 정책이 아니라, “어떤 코드가 우리의 빌드 파이프라인을 통과할 수 있는가?”를 기술적으로 규정하는 것이다. 이를 위해 공식 저장소를 통한 설치 강제, 패키지 서명 검증 활성화, 내부 프록시 레지스트리 사용, 의존성 허용 목록 기반 의존성 관리, 그리고 CI/CD 환경에서의 무결성 검증 강화 등이 필수적으로 수반되어야 한다.
A06(2021)에서 A03(2025)로 — 위험 범위의 대폭 확장
OWASP Top10 2021 A06은 “취약하거나 오래된 구성요소 사용”이라는 비교적 좁은 범위를 다뤘다. 라이브러리, 프레임워크, 런타임이 주요 대상이었고 문제의 핵심은 ‘패치되지 않은 컴포넌트의 존재’였다. 반면 OWASP Top10 2025 RC A03은 이름에서 알 수 있듯이 범위가 확장되었다.
- 라이브러리 → 빌드·배포 전체로 확대이제 취약점의 출발점을 코드에 영향을 미칠 수 있는 모든 요소에서 찾는다. 공격자는 빌드 서버, 레지스트리, IDE, 배포 스크립트 등 어디든 침투할 수 있으며, 이는 실제 공격 사례에서도 확인되고 있기 때문이다.
- 단일 구성요소의 취약 → 프로세스 전체의 취약으로 전환패치가 늦어지는 이유, 미지원 컴포넌트를 계속 사용하는 이유, 변조된 패키지가 유입되는 이유 등 내부 프로세스의 취약성까지 고려해야 하는 것으로 판단된다.
- CWE 범위 확장 : 특히 CWE-447(Unimplemented or Unsupported Feature in UI)이나 CWE-1329(Reliance on Component That is Not Updateable) 같이 기존에는 단순 코드 문제로 보이던 항목들이 공급망 취약성의 일부로 편입되었다. 이는 “코드 품질 문제 → 유지보수 불가능 상태 → 공급망 리스크”라는 위험 흐름을 반영하는 것으로 보인다.
A03에 포함된 CWE 분석 — 왜 이들은 공급망 취약성인가
CWE-1395: Dependency on Vulnerable Third-Party Component
공급망 위험 중 가장 직관적이며 실제 사고로 이어질 가능성이 높은 CWE라 할 수 있다. 하나의 취약한 의존성만으로도 전체 제품이 원격 코드 실행(RCE)이나 데이터 노출 위험에 노출될 수 있다. 그러므로 공급망 보안 입장에서 보자면 당연히 포함되야 하는 CWE라 할 수 있다.
CWE-1395는 소프트웨어가 외부에서 제공되는 서드파티 라이브러리나 프레임워크에 취약점이 존재함에도 이를 계속 사용하는 상황을 의미한다. 현대 소프트웨어는 수십~수백 개의 외부 컴포넌트로 구성되기 때문에, 단 하나의 취약한 라이브러리만으로도 전체 서비스가 원격 코드 실행(RCE), 권한 상승, 데이터 유출 같은 치명적 위협에 노출될 수 있다.
특히 공급망 보안에서는 취약한 의존성 하나가 빌드 → 배포 → 실행 환경 전체에 전파되며 확산되는 구조적 문제를 만든다. Log4Shel, OpenSSL Heartbleed 등 실제 사고들 모두 서드파티 컴포넌트 취약성을 핵심 공격 경로로 사용했다. 즉 CWE-1395는 공급망 실패 중 가장 실질적인 공격 표면을 제공하는 요소이며, 단일 취약점이 대규모 파급 효과를 일으킬 수 있는 전형적 사례로 OWASP A03에 포함되었다고 볼 수 있다.
CWE-1104: Use of Unmaintained Third Party Components
CWE-1104는 특정 구성요소가 더 이상 유지보수되지 않아 보안 패치·기능 개선·취약점 수정이 전혀 제공되지 않는 상태를 의미한다. 이는 현재 취약점 존재 여부와 관계없이, 향후 발견될 모든 취약점에 대해 영구적으로 방치된 상태가 된다는 점에서 공급망 관점에서 매우 위험한 형태다.
이러한 컴포넌트는 시간이 지날수록 기술 부채(Technical Debt)가 누적되며, 신규 취약점이 공개되면 조직은 이를 인지하더라도 수정할 방법이 없다. 즉, CWE-1104는 “이미 존재하는 취약한 의존성(CWE-1395)”보다 범위가 더 넓으며, 패치될 가능성조차 없는 구성요소를 계속 사용하는 구조적 취약성을 강조한다.
공급망에서는 이런 유지보수 종료(EOL)된 컴포넌트가 상위 애플리케이션, 서비스에 연쇄적으로 영향을 미쳐, 전체 제품을 지속적인 공격 상태에 빠뜨린다. 그 결과 공격자는 오래된 API, 낙후된 의존성, 알려진 공격 벡터 등을 통해 손쉽게 침투할 수 있게 된다.
CWE-1329: Reliance on Component That is Not Updateable
CWE-1329는 조직이 사용하는 구성요소가 구조적으로 업데이트가 불가능한 상태에 놓여 있을 때 발생한다. 이는 단순히 “업데이트를 하지 않았다”의 문제가 아닌 패치를 적용할 수 있는 경로가 존재하지 않는 환경적 제약을 의미한다. 대표적으로 IoT 기기, 산업용 제어장비(ICS), 내장형 장비(embedded systems)는 펌웨어 구조가 폐쇄적이거나, 공급업체가 패치를 제공하지 않아 패치 자체가 불가능하거나 장비 전체를 교체해야만 해결되는 상황이라 할 수 있다.
공급망 관점에서 이런 구성요소는 최고의 리스크로 평가된다. 취약점이 공개되더라도 조직은 대응 수단이 없고, 공격자는 패치되지 않는 영원한 Attack Surface를 확보할 수 있기 때문이다. 특히 장비가 장기간 현장에서 운영되는 특성상, 취약한 구성요소는 오랜 기간 공격 벡터로 남게 되며, 애초에 업데이트 경로가 차단되어 있기 때문에 방어가 불가능한 구조적 취약점으로 이어진다.
결국 CWE-1329는 소프트웨어 공급망이 갖는 “업데이트 전달 체계의 단절” 문제를 상징하며, A03 범주 내에서 가장 치명적인 형태의 공급망 실패라 할 수 있다.
CWE-447: Unimplemented or Unsupported Feature in UI
CWE-447은 이미 폐기되었거나 유지보수가 중단된 기능, 라이브러리, API를 계속 사용하는 상황에서 발생한다. 이는 단순한 레거시 코드의 존재를 넘어서는 문제다. 핵심은 해당 기능이 더 이상 패치를 제공하지 않으며, 현대적 보안 요구사항을 만족시키지 못하는 ‘단절된 기술 부채’가 된다는 점이다.
기능이 EOL 상태에 돌입하면 새 취약점이 발견되더라도 공급기업 또는 커뮤니티는 더 이상 패치를 제공하지 않는다. 이 시점부터 해당 구성요소는 시간이 지날수록 취약점이 누적된다. 특히 공급망 내부에서 이 기능을 사용하는 다른 구성요소·모듈은 이를 인지하지 못한 채 계속 빌드, 배포 프로세스에 포함될 수 있다. 그 결과, 공격자는 오래전부터 존재하던 취약한 코드 경로를 악용할 수 있다.
공급망 맥락에서 폐기 기능 사용은 “업데이트 가능하지만 이미 유지보수가 종료된 구성요소를 계속 쓰는 경우”로, CWE-1329가 설명하는 “업데이트 자체가 불가능한 구조적 한계”와는 다른 형태의 위험이지만, 둘 모두 공급망의 생애주기 관리 실패라는 공통된 본질을 갖는다.
OWASP가 제시하는 대응 전략 — 공급망 전체를 하나의 시스템으로 보자!
SBOM(Sofware Bill of Materials) 관리
OWASP측에서 A03의 문제에 대응하기 위해 가장 중요한 요소로 생각하는 것은 SBOM을 구축하고 중앙에서 관리하는 것이다. SBOM은 애플리케이션을 구성하는 모든 라이브러리, 버전, 의존성 정보를 ‘재료 목록’처럼 정리한 문서다. 이를 통해 직·간접 의존성 전체 추적, 컴포넌트 버전 및 라이선스 정보 관리, 변경 이력 관리와 취약성 대응 속도 향상을 기대할 수 있을 것으로 예상한다.
사용하지 않거나 유지보수 불가능한 요소 탐지/제거 — 공격면 감소
기능·파일·문서 등 필요 없는 요소가 많을수록 공격 표면도 커진다. 최소 운영 원칙에 따라 불필요한 요소를 제거하면 공급망 위험을 실질적으로 줄일 수 있다. 이를 위해 OWASP는 개발자rk 의존성의 유지보수 상태를 정기적으로 점검해야 하며, 지원 종료(EOL) 컴포넌트는 가능한 한 빠르게 교체할 것을 권고한다.
지속적인 버전·취약성 모니터링
OWASP Dependency Check, retire.js, SCA(Sofware Composition Analysis) 도구 등 버전과 취약점얼을 스캔할 수 있는 도구들이 알려져 있다. OWASP에서는 모든 것을 선재적으로 차단할 수 없더라고 지속적으로 스캔하며, CVE·NVD·벤더 보안 공지 등을 모니터링 할 것을 권고하고 있다.
공식·신뢰 가능한 소스만 사용
패키지 다운로드는 공식 레지스트리와 서명된 패키지를 사용하는 것이 원칙이다. npm, PyPI 등에서 악성 패키지가 노출되는 사례는 계속 증가하고 있다.
CI/CD·IDE·개발 도구를 공급망의 일부로 간주하고 강화
모든 개발 환경에 MFA, IAM 원칙 적용(Ref. Amazon Cloud)하고 서명된 빌드 및 변경 추적, 환경별 비밀값 관리 등과 같이 개발 환경 전반에 걸쳐 사용, 저장, 관리하는 모든 요소들을 공급망의 일부로 간주하고 앞서 언급한 대응 방안 적용을 권고 한다.
변경 관리(Change Management) 체계 확립
CI/CD 설정, 코드 저장소, IDE, SBOM 도구, 로그 시스템, SaaS 연동 등 모든 요소는 변경될 때마다 기록해야 한다. 이를 통해 변조·오염된 구성요소가 내부로 유입되는 것을 조기에 감지할 수 있다.
OWASP의 이상적인 대응 전략? 현실적인 대응전략으로!
앞서 설명한 것과 같이 복잡한 소프트웨어 공급망 상호아과 복잡해진 서비스 아키텍처, 빠른 배포 주기 속에서, 조직은 앞서 제시한 OWASP의 모든 대응 전략을 수행할 수 있을까? 이론적으로 충부한 자원이 주어진다면 불가능한 일이 있겠나 싶지만 현실 세계에서 자원은 무한하지 않다. 그렇다면 현실 세계에서 어느 정도 타협점을 찾고 100%가 될 수 없지만 100%에 가장 가까지 가기 위해 노력해야 한다.
이 과정에서 Attack Surface Management(ASM)는 공격면을 지속적으로 관리하며 보안 담당자가 놓치기 쉬운 노출 자산을 조기에 발견할 수 있도록 돕는다. 그러나 ASM은 어디까지나 “표면” 관리를 자동화하는 도구로 실제 취약점의 위험도나 공격 시나리오는 판단하지 못한다. 이 지점에서 PTaaS(Pentesting as a Service)의 필요성이 생겨난다. PTaaS는 자동화된 스캐닝, 리포팅을 넘어 사람이 공격자의 관점에서 자산, API, 구성 요소의 상호작용을 직접 검증하고 기록하면 공격자가 활용 가능한 실질적인 위협 시나리오를 찾아낸다. 특히 현대 서비스를 구성하는 수많은 마이크로서비스, API 게이트웨이, 서드파티 통합 환경에서는 단일 취약점보다 각각의 취약점을 연계한 공격이 위협적이므로 이와 같은 상호작용을 통한 위협 탐지/제거 활동이 효과적이다.
하지만 ASM과 PTaaS의 조합에도 부족한 부분이 있을 수 있는데, 이는 두 서비스가 이미 알려진 취약점을 기반으로 판단하는 경향이 있어 엄연한 한계가 존재한다. 이러한 자동화, 서비스 기반 보안 모델의 공백을 메우는 것이 바로 Offensive Security Research이다. 연구팀이 신종 취약점, 제로데이, 공격 체인, 우회 기법 등을 지속적으로 발굴하고 ASM과 PTaaS 플랫폼에 적용하여 최신 위협 지식을 업데이트하는 과정을 거쳐 방어 모델 전반의 대응력을 상시적으로 향상시킬 수 있다. 즉, ASM이 “무엇이 노출되었는지”를 보여주고, PTaaS가 “그 노출이 어떻게 공격되는지”를 검증한다면, Offensive Research는 “앞으로 무엇이 공격될지”를 예측하고 대비하는 역할을 수행한다. 세 분야는 서로 분리된 기능이 아니라, 공격면 확대와 위협 고도화가 동시에 일어나는 환경에서 지속적인 공격자 관점의 가설 제기 → 자동화된 자산 탐지 → 맥락 기반 검증 → 위협 모델 업데이트라는 순환 구조를 완성시키는 필수 요소라고 할 수 있다.🆃🆃🅔
Related Materials
Donghwi Shin
Donghwi Shin
Donghwi Shin
