2024년 7월 19일 새벽 4시경(한국 시간 오후 1시경), 전 세계적인 IT 대란이 발생했습니다. 병원, 공항, 은행 등 주요 인프라에서 시스템 마비가 일어났죠. 원인은 크라우드스트라이크라는 사이버 보안 회사의 ‘팰컨 센서’ 업데이트 오류였습니다. 이 업데이트가 마이크로소프트 윈도우 운영체제와 충돌하면서 전 세계 850만 대의 윈도우 컴퓨터가 블루스크린 상태에 빠진 것입니다.
이 사건이 우리에게 던지는 질문은 명확합니다. “내가 매일 사용하는 소프트웨어, 정말 안전한가요?”
1. 소프트웨어 공급망 보안(Software Supply Chain Security)의 진짜 의미
1-1. 우리가 모르는 사이 벌어지는 일들
현대 소프트웨어는 수많은 외부 구성 요소로 이루어져 있습니다. 마치 요리에 들어가는 재료처럼 말이죠. 소프트웨어 공급망 보안이란, 이 모든 ‘재료’들이 안전한지 확인하는 과정입니다.
문제는 이 재료들 중 대부분을 우리가 직접 만들지 않는다는 점입니다. 전 세계 개발자들이 만들어 놓은 오픈소스 라이브러리를 가져다 쓰는 경우가 대부분이죠. 현대 애플리케이션의 80-90%가 오픈소스 구성 요소로 이루어져 있습니다.
1-2. 신뢰의 체인이 무너질 때
2021년 발생한 Log4j 사건을 기억하시나요? 자바 로깅 라이브러리인 Log4j의 보안취약점을 악용한 사이버보안 사고는 국내외에서 큰 피해를 입혔습니다. 이 작은 라이브러리 하나의 취약점이 전 세계 수백만 개의 애플리케이션을 위험에 빠뜨린 것입니다.
이것이 바로 소프트웨어 공급망의 무서운 점입니다. 신뢰의 사슬에서 가장 약한 고리 하나가 전체를 무너뜨릴 수 있다는 것이죠.
2. 2024년 공급망 보안 사건으로 본 현실적 위험
2-1. 크라우드스트라이크: 보안 회사가 일으킨 전산 마비 사고
크라우드스트라이크의 ‘팰컨 센서’ 업데이트가 윈도우 운영체제와 충돌하면서 발생한 이 사고로 인해 전 세계적으로 수많은 기업과 기관의 업무가 마비됐습니다. 미국의 항공사들, 영국의 주요 공항들, 그리고 NASA와 같은 정부 기관까지 영향을 받았습니다.
흥미로운 점은 크라우드스트라이크가 사이버 보안을 전문으로 하는 회사라는 것입니다. 2024년 기준으로 전 세계적으로 2만 9천여 개의 고객사를 보유한 이 회사의 업데이트 하나가 광범위한 장애를 일으킨 것이죠. 이는 의도적인 사이버 공격도 아니었습니다. 단순한 업데이트 오류였을 뿐입니다.
2-2. XZ 유틸: 오픈소스 프로젝트에 숨겨진 백도어
2024년 초 발견된 XZ 유틸 백도어 사건은 오픈소스 프로젝트의 취약성을 보여준 사례입니다. XZ 유틸은 널리 사용되는 무료 데이터 압축 도구로, 이 프로젝트에 SSH 프로토콜을 악용한 백도어가 삽입된 것이 밝혀졌습니다. 공격자는 몇 년에 걸쳐 프로젝트에 기여하며 신뢰를 쌓은 후 유지보수 권한을 획득했습니다.
2-3. 공급망 공격 증가 추세
소나타입의 2023년 보고서에 따르면, SW 공급망 공격은 2022년 이후 200% 증가했습니다. 사이버시큐리티 벤쳐스는 소프트웨어 공급망 공격으로 인한 연간 피해 금액이 2025년까지 600억 달러에 이르며 2031년까지는 1,380억 달러에 육박할 것으로 전망했습니다.
3. 공급망 공격의 주요 수법들
3-1. 의존성 투독(Dependency Poisoning)
공격자들은 개발자들이 자주 사용하는 패키지 저장소에 악성 코드가 포함된 라이브러리를 업로드합니다. 체크막스에 따르면 소프트웨어 공급망에 영향을 주는 악성 패키지가 2022년 16만개 발견됐으며, 이는 같은 해 공개된 CVE 취약점 2만5226개보다 6배 많은 수준입니다.
3-2. 빌드 시스템 침투
개발자의 컴퓨터나 회사의 빌드 서버를 해킹해서 소프트웨어 제작 과정에서 악성 코드를 심는 방법입니다. 이렇게 만들어진 소프트웨어는 정상적인 디지털 서명까지 받기 때문에 탐지가 매우 어렵습니다.
3-3. 공급업체 직접 해킹
2020년 솔라윈즈 사건처럼 소프트웨어 회사 자체를 해킹해서 정상적인 업데이트를 통해 악성 코드를 배포하는 방법입니다. 사용자 입장에서는 신뢰하는 회사에서 온 정상적인 업데이트이기 때문에 의심할 이유가 없죠.
4. SBOM – 소프트웨어의 ‘영양성분표’
4-1. SBOM이 왜 필요한가?
SBOM(Software Bill of Materials)은 소프트웨어에 들어간 모든 구성 요소의 목록입니다. 미국 행정명령 14028에서 SBOM을 “소프트웨어 구축에 사용되는 다양한 구성 요소의 세부 사항과 공급망 관계를 포함하는 공식 기록”으로 정의합니다.
마치 식품의 영양성분표와 같은 역할을 합니다. 어떤 재료가 들어갔는지, 그 재료는 어디서 왔는지, 언제 만들어졌는지 등을 명확히 기록하는 것이죠.
4-2. SBOM의 실무적 활용 사례
Log4j 취약점이 발견되었을 때를 생각해보면, SBOM의 중요성을 쉽게 이해할 수 있습니다. SBOM이 잘 관리된 조직들은 영향받는 시스템을 빠르게 찾아낼 수 있었지만, 그렇지 않은 곳들은 전체 시스템을 수동으로 검토해야 했습니다.
가트너는 2025년까지 중요 인프라 소프트웨어를 개발하거나 조달하는 조직의 60%가 소프트웨어 엔지니어링 관행에서 SBOM을 의무화하고 표준화할 것으로 전망한다고 발표했습니다. 이는 2022년 20% 미만에서 크게 증가한 수치입니다.
4-3. SBOM 구현 시 주의사항
SBOM을 만드는 것도 중요하지만, 지속적으로 업데이트하는 것이 더 중요합니다. SBOM 생성을 위한 국제 표준이 있지만, 표준에 맞게 설계된 SBOM이라 해도 조직에서 최신 상태로 관리하지 못하면 무용지물입니다.
5. SLSA 프레임워크 – 공급망 보안의 단계별 접근법
5-1. SLSA가 제시하는 4단계 보안 성숙도
SLSA(Supply-chain Levels for Software Artifacts)는 공급망 보안을 위한 체크리스트와 표준을 제공하는 보안 프레임워크입니다. 마치 게임의 레벨처럼 4단계로 나누어 점진적으로 보안을 강화할 수 있도록 설계되었습니다.
- 레벨 1: 자동화된 빌드 환경 구축
- 레벨 2: 디지털 서명을 통한 출처 증명
- 레벨 3: 격리된 빌드 환경과 강화된 출처 제어
- 레벨 4: 완전히 격리된 빌드와 최고 수준의 출처 보장
5-2. SLSA 도입 시 고려사항
대부분의 기업은 레벨 1부터 시작하는 것이 현실적입니다. OpenSSF, Chainguard, Eclipse, Rust Foundation이 2023년에 공동 실시한 설문조사에 따르면, 50% 이상의 참여자가 완전격리 빌드(hermetic builds) 같은 특정 SLSA 관행을 구현하기 어렵다고 응답했습니다.
하지만 완벽하지 않더라도 시작하는 것이 중요합니다. 레벨 1만 달성해도 기본적인 공급망 공격의 상당 부분을 방어할 수 있습니다.
6. 지금 당장 시작할 수 있는 보안 대책
6-1. 오늘부터 할 수 있는 5가지
1단계: 현황 파악하기
- 현재 사용 중인 모든 오픈소스 라이브러리 목록 작성
- 각 라이브러리의 버전과 마지막 업데이트 날짜 확인
- 보안 취약점 데이터베이스(CVE)에서 해당 버전들 검색
2단계: 자동화 도구 도입
- GitHub의 Dependabot이나 Snyk 같은 무료 도구로 시작
- CI/CD 파이프라인에 보안 스캔 단계 추가
- 취약점 발견 시 자동 알림 설정
3단계: 업데이트 정책 수립
- 보안 업데이트는 24시간 내 적용 원칙
- 기능 업데이트는 테스트 후 1주일 내 적용
- 메이저 버전 업데이트는 별도 검토 후 적용
6-2. 개발팀과의 소통 전략
개발자들에게 보안의 중요성을 설득하는 것은 쉽지 않습니다. 하지만 크라우드스트라이크 사건 같은 실제 사례를 들어 설명하면 효과적입니다. “우리 회사에서도 이런 일이 일어날 수 있다”는 현실감을 주는 것이 중요합니다.
6-3. 경영진 보고를 위한 핵심 지표
- 리스크 노출도: 알려진 취약점을 가진 구성 요소 수
- 평균 복구 시간: 취약점 발견부터 패치 적용까지의 시간
- SBOM 커버리지: 전체 소프트웨어 중 SBOM이 있는 비율
- 공급업체 보안 점수: 주요 소프트웨어 공급업체의 보안 평가 점수
7. 2025년 공급망 보안 전망과 대비책
7-1. 예상되는 새로운 위협들
AI 기반 공격의 우려 공격자들이 AI를 활용해 더욱 정교한 공급망 공격을 수행할 가능성이 제기되고 있습니다. 하지만 구체적인 사례는 아직 확인되지 않았습니다.
클라우드 환경의 새로운 위협 가트너는 2025년까지 전 세계 약 45%의 조직에서 소프트웨어 공급망 공격이 발생할 것이라고 전망했습니다. 특히 오픈소스 환경을 겨냥한 APT(지능형 지속 위협) 공격이 증가할 것으로 예상됩니다.
7-2. 정부 규제 강화 트렌드
미국은 이미 연방 기관에 SBOM 제출을 의무화했고, 유럽연합도 사이버 복원력 법안(Cyber Resilience Act)을 통해 비슷한 규제를 준비하고 있습니다. 한국도 과학기술정보통신부와 한국인터넷진흥원이 2024년 5월 ‘SW 공급망 보안 가이드라인 1.0’을 발표했습니다.
7-3. 선제적 대응 전략
Zero Trust 원칙 적용 “기본적으로 신뢰하지 않고 항상 검증한다”는 Zero Trust 원칙을 공급망에도 적용해야 합니다. 아무리 신뢰하는 공급업체라도 지속적인 검증이 필요합니다.
보안 커뮤니티 참여 OWASP, OpenSSF 같은 보안 커뮤니티에 참여해서 최신 위협 정보를 공유하고 대응 방안을 함께 모색하는 것이 중요합니다.
8. 성공/실패 사례를 보며, 우리가 준비해야 하는 것은?
8-1. Log4j 사건에서 배우는 교훈
2021년 Log4j 취약점이 발견되었을 때, 조직들의 대응 속도에는 큰 차이가 있었습니다. 빠르게 대응한 조직들의 공통점은:
- 완전한 SBOM을 보유하고 있었음
- 자동화된 취약점 스캐닝 시스템 운영
- 사전에 정의된 보안 사고 대응 절차
- 개발팀과 보안팀 간의 원활한 소통 체계
8-2. 실패 사례에서 얻는 교훈
반대로 피해를 크게 입은 조직들의 특징은:
- 사용 중인 오픈소스 구성 요소를 정확히 파악하지 못함
- 수동적인 보안 관리 체계
- 보안팀과 개발팀 간의 소통 부족
- 경영진의 보안 투자에 대한 인식 부족
9. 소규모 기업을 위한 현실적 접근법
9-1. 예산이 제한적일 때의 우선순위
모든 기업이 대규모 보안 투자를 할 수 있는 것은 아닙니다. 소규모 기업들을 위한 현실적인 접근법:
1단계: 무료 도구 최대 활용
- GitHub의 보안 기능들 (Dependabot, Security Advisories)
- OWASP Dependency-Check
- npm audit, pip-audit 같은 내장 도구들
2단계: 클라우드 서비스 활용
- 자체 보안 인프라 구축보다는 검증된 클라우드 서비스 활용
- SaaS 형태의 보안 도구들로 초기 투자 부담 줄이기
9-2. 외주 개발 시 체크포인트
외주로 소프트웨어를 개발하는 경우:
- 계약서에 SBOM 제공 의무 명시
- 사용된 오픈소스 라이브러리 목록과 라이선스 정보 요구
- 개발 완료 후 보안 스캔 결과 제출 요구
- 취약점 발견 시 무상 패치 제공 약속
소프트웨어 공급망 보안은 하루아침에 완성되는 것이 아닙니다. 크라우드스트라이크 같은 전문 보안 회사도 실수할 수 있는 영역이니까요. 중요한 것은 완벽한 보안이 아니라 지속적인 개선과 준비입니다. 2024년의 크라우드스트라이크 사건은 우리에게 중요한 교훈을 남겼습니다. 소프트웨어 공급망의 한 고리가 끊어지면 전체 시스템이 마비될 수 있다는 것, 그리고 이에 대한 준비가 얼마나 중요한지 말입니다. 하지만 절망할 필요는 없습니다. 체계적인 접근과 지속적인 관리를 통해 충분히 대응할 수 있는 영역입니다. 오늘부터 작은 단계라도 시작해보세요. 🙂
참고 자료
공식 문서 및 가이드라인
- NIST 사이버보안 프레임워크 – 미국 국가표준기술연구소
- ISO/IEC 27001 표준 – 정보보안 관리시스템 국제표준
- SANS 공급망 보안 가이드 – 실무 중심 보안 백서
업계 보고서
- 소나타입 연례 보고서 – 공급망 공격 현황
- 체크막스 공급망 보안 리포트 – 보안 동향 분석
실무 도구 및 플랫폼