"우리는 안전한데, 거래처가 뚫렸습니다"
2026년 1분기 ASEC 보고서에 따르면 기업 침해 사고의 62%가 직접 공격이 아닌 공급망 경로로 발생했습니다. IBM X-Force 보고서도 공급망 침해가 전년 대비 4배 증가했다고 발표했습니다.
공격자 입장에서는 보안이 탄탄한 대기업을 직접 공격하는 것보다, 보안이 약한 외주 개발사, SaaS 공급업체, 오픈소스 패키지를 경유하는 것이 훨씬 효율적입니다.
공급망 공격 3대 경로
1. 외주 개발사 경유
외주 개발사가 납품한 코드에 백도어가 포함되거나, 개발 과정에서 사용한 계정 정보가 유출되는 사례가 반복되고 있습니다.
실제 사례: 2025년 국내 중견 IT기업이 외주 개발한 관리자 페이지에서 하드코딩된 관리자 계정(admin/admin1234)이 발견됐습니다. 외주 개발사가 테스트용으로 넣고 삭제하지 않은 것입니다. 이 계정으로 고객 데이터 8만 건이 유출됐습니다.
점검 체크리스트:
- [ ] 외주 계약서에 보안 요구사항(시큐어코딩 기준, 취약점 점검 의무) 명시
- [ ] 납품 코드 SAST(정적 분석) 점검 수행
- [ ] 하드코딩된 자격 증명(계정, API 키) 스캔
- [ ] 외주 개발사 VPN/접근 권한은 프로젝트 종료 후 즉시 회수
- [ ] 납품 코드에 대한 SBOM(소프트웨어 구성 목록) 요구
2. SaaS 연동 리스크
Slack, Notion, Jira, Google Workspace 같은 SaaS를 API로 연동할 때, 과도한 권한(OAuth scope)을 부여하는 경우가 많습니다.
점검 체크리스트:
- [ ] 연동된 SaaS 목록과 부여된 OAuth 권한 범위 파악
- [ ] "모든 데이터 읽기/쓰기" 같은 과도한 권한 축소
- [ ] 사용하지 않는 연동 앱 정기 정리 (분기 1회)
- [ ] SaaS 공급업체의 SOC2/ISO27001 인증 확인
- [ ] SaaS 장애/침해 시 영향 범위 사전 파악
3. 오픈소스 패키지 오염
npm, PyPI, Maven 등 패키지 저장소에 악성 패키지가 올라오는 사례가 급증하고 있습니다. 이름이 비슷한 가짜 패키지(타이포스쿼팅)나, 인기 패키지의 의존성에 악성 코드를 주입하는 방식이 대표적입니다.
점검 체크리스트:
- [ ] 의존성 목록(package.json, requirements.txt) 정기 감사
- [ ] npm audit, pip-audit, trivy 등 자동 취약점 스캔 CI/CD 파이프라인에 포함
- [ ] 새 패키지 도입 시 다운로드 수, 마지막 업데이트, 메인테이너 수 확인
- [ ] lock 파일(package-lock.json, poetry.lock) 커밋 필수
- [ ] private registry 또는 미러 사용 검토
SBOM이 왜 중요한가
SBOM(Software Bill of Materials)은 소프트웨어에 포함된 모든 구성 요소의 목록입니다. 미국은 이미 연방 조달에 SBOM을 의무화했고, 한국도 KISA 주도로 SBOM 가이드라인을 준비 중입니다.
SBOM이 있으면:
- 취약점 발표 시 우리 제품에 해당되는지 5분 안에 파악 가능
- 외주 코드에 어떤 오픈소스가 들어갔는지 투명하게 관리
- 공급망 사고 발생 시 영향 범위를 즉시 특정
공급망 보안, 어디서부터 시작해야 하나
완벽한 공급망 보안은 한 번에 만들 수 없습니다. 하지만 현재 우리 회사의 공급망 리스크가 어디에 있는지 파악하는 것이 첫 단계입니다.
SENTRIX는 외주 코드 보안 점검, SaaS 연동 권한 감사, SBOM 구축 컨설팅을 제공합니다. 보안 전문 기업의 시각으로 공급망 전체를 진단합니다.