공급망 공격의 경로와 소프트웨어·하드웨어 보안 대응

신뢰된 경로를 우회로로 바꾸는 공격

공급망 공격은 최종 대상 시스템을 정면으로 겨냥하지 않는다. 제품이나 서비스가 개발되고 제조되며 배포되는 과정에 먼저 침투한 뒤, 신뢰받는 개발사나 공급업체의 경로를 통해 악성코드 또는 백도어를 전달한다.

기업의 IT 인프라는 여러 벤더의 제품과 서비스로 구성된다. 공급망이 복잡해질수록 공격자가 노릴 수 있는 지점도 늘어난다. 이 공격은 신뢰 관계를 악용하고, 한 번의 침해가 광범위한 사용자에게 전파될 수 있으며, 탐지 이후에도 영향이 장기간 이어질 수 있다는 점에서 위협적이다.

배포와 개발 과정에서 발생하는 침해

배포 서버를 통한 악성 업데이트 유포

배포 서버 해킹은 소프트웨어 또는 업데이트 파일을 제공하는 서버에 악성코드를 삽입하는 방식이다. 사용자는 정상적인 배포 채널을 이용한다고 믿기 때문에 악성 업데이트가 내부 환경까지 도달하기 쉽다.

2020년 SolarWinds 공격에서는 공격자들이 Orion 플랫폼 업데이트 배포 서버에 접근해 악성코드를 삽입했고, 18,000개 이상의 고객이 영향을 받았다.

⤢✕

제조 단계에 삽입되는 물리적 백도어

하드웨어 공급망에서는 제조 과정의 장치나 펌웨어가 공격 대상이 된다. 공격자는 물리적 구성 요소에 악성 기능을 심거나, 제조 단계에서 백도어가 포함된 장비가 유통되도록 만들 수 있다.

2018년에는 중국 제조업체가 생산한 서버 마더보드에 초소형 스파이 칩이 삽입되어 미국 기업 및 정부 네트워크에 백도어를 제공했다는 의혹이 제기되었다.

⤢✕

코드 저장소와 라이브러리를 노리는 공격

개발 리포지토리나 라이브러리는 소프트웨어 공급망의 핵심 자산이다. 저장소에 삽입된 악성코드는 정상 빌드 과정을 거쳐 릴리스 버전에 포함될 수 있다.

2021년 PHP 공식 Git 저장소가 해킹되어 백도어가 삽입되었다. 해당 변경은 빠르게 발견되어 실제 배포 전에 차단되었다.

⤢✕

방문자가 모이는 지점을 악용하는 워터링 홀

워터링 홀 공격은 특정 조직이나 업계 구성원이 자주 찾는 웹사이트를 침해한 뒤, 방문자에게 악성코드를 전달하는 방식이다.

2017년 CCleaner 공격에서는 인기 시스템 유틸리티 소프트웨어의 다운로드 서버가 해킹되어 악성코드가 포함된 버전이 배포되었고, 200만 명 이상의 사용자가 영향을 받았다.

⤢✕

공급망 참여자별 방어 체계

공통적으로는 전체 공급망을 대상으로 위험 평가와 관리 프레임워크를 수립해야 한다. 주기적인 보안 감사와 취약점 평가를 수행하고, 제3자 벤더 보안 관리 프로세스를 마련하는 것이 출발점이다.

시스템의 중요도에 따라 보호 수준을 달리하는 전산자원 등급관리도 필요하다. 핵심 자산에는 강화된 보안 통제를 적용하고, 접근 권한은 최소 권한 원칙으로 운영한다. 공급망 공격 탐지와 대응을 담당할 전담팀, 사고 대응 계획과 정기 훈련, 위협 인텔리전스 공유 네트워크도 대응 체계에 포함된다.

소프트웨어 개발사의 패키징 통제

개발사는 저장소 접근 통제를 강화하고 코드 서명 및 해시 검증 절차를 갖춰야 한다. CI/CD 파이프라인의 보안을 강화하며, 빌드 서버와 배포 서버를 분리해 침해 확산 경로를 줄이는 방식이 필요하다.

⤢✕

개발 환경은 외부 네트워크와 엄격히 분리하고, 물리적·논리적 접근 통제를 적용해야 한다. 불필요한 네트워크 서비스와 포트는 차단하며, 외부 연결이 필요할 때는 강화된 인증과 암호화를 적용한다.

하드웨어 개발사의 제조 보안

하드웨어 개발사는 구성 요소의 출처를 검증하고 추적할 수 있어야 한다. 생산 라인에서는 랜덤 샘플링 검사를 수행하고, 완제품에는 TPM 등의 무결성 검증 기술을 적용한다. 펌웨어와 드라이버에는 코드 서명을 의무화하는 방안이 요구된다.

제조 시설 자체의 물리 보안도 중요하다. 다층적 보안 통제, 생산 현장 CCTV 감시와 기록 유지, 직원 배경 조사 및 보안 교육, 외부 방문자 통제와 에스코트 정책을 함께 운영해야 한다.

도입기관의 벤더 관리

대상기관은 공급망 보안 전담 조직을 두고 구매·조달 팀과 보안 팀이 협업할 수 있는 구조를 마련해야 한다. 지속적인 보안 교육과 인식 제고 프로그램을 운영하며, 외부 보안 전문가와의 협력 관계도 유지할 필요가 있다.

공급업체는 계약 이후에도 지속적으로 평가해야 한다. 벤더 보안 평가와 실사 절차를 두고, 보안 요구사항을 명확히 정의하며, ISO 27001 등의 보안 인증을 확인한다. 정기 평가에서 식별된 위험은 개선 조치로 연결되어야 한다.

⤢✕

업데이트 경로가 남긴 사례

SolarWinds 공격

2020년 미국 IT 관리 소프트웨어 회사 SolarWinds의 Orion 플랫폼이 해킹되어 악성 업데이트가 배포되었다. 미국 정부기관과 글로벌 기업들이 피해를 입었고, 공격자들은 약 9개월 동안 탐지되지 않았다.

이 사례는 코드 서명 절차만으로 충분하지 않으며, 내부 빌드 시스템 보안과 이상 활동 모니터링 체계를 함께 강화해야 한다는 점을 보여준다.

NotPetya 공격

2017년 우크라이나 세무 소프트웨어 업데이트 서버가 해킹되어 악성코드가 배포되었다. 공격은 전 세계로 확산됐고 100억 달러 이상의 경제적 손실을 초래했다.

지역적으로 사용되는 소프트웨어도 글로벌 피해로 이어질 수 있다. 업데이트 메커니즘의 보안, 신속한 패치, 백업 정책이 모두 필요한 이유다.

공급망 보안이 향하는 방향

기술 측면에서는 블록체인 기반 공급망 무결성 검증 시스템, AI/ML 기반 이상 징후 탐지, 제로 트러스트 아키텍처의 확대 적용이 제시되고 있다. 하드웨어 보안 모듈(HSM)과 신뢰 실행 환경(TEE)의 활용도 증가하는 방향이다.

규제와 표준화의 움직임도 이어진다. 미국 NIST의 Secure Software Development Framework(SSDF), EU의 NIS2 지침에 따른 공급망 보안 요구사항 강화, ISO/IEC 27036 시리즈의 적용 확대, 산업별 공급망 보안 표준의 등장이 여기에 해당한다.

보안과 개발을 통합하는 DevSecOps 문화, 공급망 보안을 경영진 의제로 다루는 관점, 산업 간 정보 공유와 협력도 함께 자리 잡아야 한다. 공급망 보안을 경쟁 우위로 인식하는 조직 문화 역시 기술 통제만큼 중요하다.

직접적인 방어만으로는 공급망 공격 위험을 다루기 어렵다. 소프트웨어와 하드웨어 공급망의 가시성을 확보하고, 공급업체와 보안 협력 관계를 구축하며, 다층 방어·지속 모니터링·정기 위험 평가를 연결해야 잠재적 피해를 줄일 수 있다.