2026-10-13 수정 공개 자료에서 확인되지 않는 'ASEC 보고서 공급망 경로 62%'와 출처를 찾을 수 없는 '외주 관리자 페이지 하드코딩 계정으로 고객 데이터 8만 건 유출' 사례를 지우고, 안랩 ASEC·과기정통부 공개 자료와 티빙 침해사고 조사결과로 바꿨습니다. IBM 공급망 침해 수치를 '2020년 이후 약 4배'로, 미국 'SBOM 의무화'와 한국 '가이드라인 준비 중' 서술을 실제 제도 현황(2026년 1월 OMB 메모 폐지, 2024년 5월 가이드라인 1.0 발표)으로 바로잡고, 근거 없는 '납품 코드 백도어 반복'·'5분 안에'·'즉시 특정'·'급증' 표현과 서비스 페이지에 없는 서비스명을 지운 뒤 참고 자료를 달았습니다.
"우리는 안전한데, 거래처가 뚫렸습니다"
안랩 ASEC은 '2026년 1분기 공격기법 동향보고서'에서 '신뢰 관계(협력사·외주·API·자동화 스크립트)의 악용이 효과적인 우회 경로로 부상했다'고 정리했습니다. 과학기술정보통신부와 한국인터넷진흥원(KISA)도 2026년 상반기 사이버 위협 동향의 랜섬웨어 항목에서, 협력업체와 공급망 계정을 우회 경로로 이용하는 사례가 늘면서 대기업뿐 아니라 중소·중견기업과 협력사도 직접적인 표적이 되고 있다고 밝혔습니다.
해외 자료도 같은 방향입니다. IBM X-Force 2026 보고서에 따르면 대형 공급망·제3자 침해는 2020년 이후 약 4배로 늘었습니다. IBM은 주원인으로 개발 워크플로와 SaaS 연동에서 신뢰 관계와 CI/CD 자동화를 악용한 것을 들었습니다. 보고서의 다른 수치는 IBM X-Force 2026 요약에 정리했습니다.
본사의 보안이 탄탄해도 회사가 믿고 연결한 외주 개발사, SaaS 공급업체, 오픈소스 패키지가 뚫리면 그 연결을 타고 침해가 들어올 수 있습니다.
공급망 공격 3대 경로
1. 외주 개발사 경유
개발 과정에서 쓰는 계정과 키가 노려지는 일은 반복되고 있습니다. 과기정통부·KISA에 따르면 공격자는 개발자 단말과 클라우드 개발 환경에 정보 탈취형 악성코드(인포스틸러)를 심어 GitHub·npm·PyPI 계정 비밀번호, 개인 접근 토큰(PAT), 클라우드 접근 키를 노립니다. 외주 개발사에 저장소·서버·클라우드 접근 권한을 내줬다면 그 계정과 키도 같은 위험에 놓입니다.
국내 사례(개발·운영 접속키 관리 문제): 과기정통부의 티빙(TVING) 침해사고 조사결과(2026-09-03)에 따르면, 공격자는 개발자가 가진 '개발환경 접속키'를 탈취해 소스코드가 포함된 개발 프로젝트 361건을 빼냈습니다. 키를 빼낸 경로는 조사단이 피싱·악성코드·공급망 공격·키 공유 등을 분석했지만 확인하지 못했습니다. 조사단은 이 프로젝트들에서 운영환경(클라우드) 접속키 43개를 확인했고, 그중 41개는 소스코드에 하드코딩돼 있었고 3개는 환경변수에 평문으로 저장돼 있었습니다(1개는 중복). 공격자는 이 가운데 2개를 썼습니다. 1차 유출 시도에는 하드코딩된 키를, 대규모 유출에는 환경변수에 평문으로 저장된 키를 썼고, 평문으로 저장된 DB 접속정보까지 얻어 이용자 정보를 빼냈습니다. 유출된 계정은 3,954만 개(중복 계정 포함)였습니다. 조사단은 사고 원인으로 키 관리체계 미비와 비정상 행위 모니터링 부재 등을 지목했습니다. 코드에 남은 키 하나가 운영 시스템까지 열어 줄 수 있다는 점은 외주로 납품받은 코드에도 그대로 적용됩니다.
점검 체크리스트:
- ☐ 외주 계약서에 보안 요구사항(시큐어코딩 기준, 취약점 점검 의무) 명시
- ☐ 납품 코드 SAST(정적 분석) 점검 수행
- ☐ 소스코드와 설정 파일·환경변수에 하드코딩된 자격 증명(계정, API 키, 클라우드 접속키) 스캔
- ☐ 외주 인력의 저장소·클라우드 권한은 맡은 프로젝트로만 한정
- ☐ 외주 개발사 VPN/접근 권한은 프로젝트 종료 후 즉시 회수
- ☐ 납품 코드에 대한 SBOM(소프트웨어 자재명세서) 요구
2. SaaS 연동 리스크
Slack, Notion, Jira, Google Workspace 같은 SaaS를 API로 연동할 때, 과도한 권한(OAuth scope)을 부여하는 경우가 많습니다. 안랩 ASEC도 2026년 1분기 보고서에서 공급망·SaaS 연동 서비스의 접근권한을 점검 대상으로 꼽았습니다. 업무 계정에 연결한 서드파티 AI 도구가 침해의 출발점이 된 사례는 Vercel 사고로 본 AI 도구 공급망 리스크에서 다뤘습니다.
점검 체크리스트:
- ☐ 연동된 SaaS 목록과 부여된 OAuth 권한 범위 파악
- ☐ "모든 데이터 읽기/쓰기" 같은 과도한 권한 축소
- ☐ 사용하지 않는 연동 앱 정기 정리 (분기 1회)
- ☐ SaaS 공급업체의 SOC 2 보고서(가능하면 Type II) 또는 ISO/IEC 27001 인증서 확인, 국내 공급업체는 ISMS·ISMS-P 인증 여부 확인
- ☐ SaaS 장애/침해 시 영향 범위 사전 파악
3. 오픈소스 패키지 오염
npm, PyPI, Maven 같은 패키지 저장소에 악성 패키지가 올라오는 사례가 이어지고 있습니다. 이름이 비슷한 가짜 패키지(타이포스쿼팅)나, 인기 패키지의 의존성에 악성 코드를 넣는 방식이 대표적입니다.
과기정통부·KISA는 2026년 상반기 사이버 위협 동향에서 '공개 소프트웨어(오픈소스) 생태계를 노린 개발자 계정 탈취와 소프트웨어 공급망 공격의 고도화'를 주요 위협으로 꼽았습니다. 탈취한 계정과 토큰으로 정상 패키지의 유지관리 권한을 악용하거나 CI/CD 파이프라인으로 악성 패키지를 배포하는 방식이고, 토큰 하나가 노출되면 수백 개 저장소와 서비스의 침해로 이어질 수 있다고 경고했습니다. 실제 사례는 npm '미니 샤이-훌루드' 공급망 웜에서 다뤘습니다.
점검 체크리스트:
- ☐ 의존성 목록(package.json, requirements.txt) 정기 감사
- ☐
npm audit,pip-audit,trivy등 자동 취약점 스캔 CI/CD 파이프라인에 포함 - ☐ 새 패키지 도입 시 다운로드 수, 마지막 업데이트, 메인테이너 수 확인
- ☐ lock 파일(package-lock.json, poetry.lock) 커밋 필수
- ☐ private registry 또는 미러 사용 검토
- ☐ 개발자·유지관리자 계정에 다중 인증(MFA) 적용, 배포용 토큰(PAT·npm·PyPI)은 최소 권한·최소 유효기간으로 발급
SBOM이 왜 중요한가
SBOM(Software Bill of Materials, 소프트웨어 자재명세서)은 소프트웨어를 구성하는 전체 컴포넌트의 구성요소와 의존관계를 기술한 명세서입니다(과기정통부 정의). 무엇이 들어 있는지뿐 아니라 무엇이 무엇에 기대고 있는지까지 담습니다.
제도 현황은 다음과 같습니다(2026년 10월 기준).
- 미국(연방 조달): 2021년 행정명령 14028은 공급망 보안 지침에 '구매자에게 SBOM 제공'을 넣도록 했고, 2022년 OMB 메모 M-22-18은 연방 기관이 소프트웨어 중요도에 따라 SBOM을 요구할 수 있다고만 했습니다. 연방 조달 전체에 걸친 일괄 의무는 아니었습니다. 2026년 1월 23일에는 OMB 메모 M-26-05가 M-22-18과 후속 M-23-16을 폐지했고, 이제 계약에 '요청 시 최신 SBOM 제출' 조건을 넣을지는 각 기관이 위험을 따져 정합니다. 분야별 법적 의무는 따로 있습니다. 의료기기는 연방 식품의약품화장품법 524B조의 'cyber device' 요건(소프트웨어 탑재, 인터넷 연결 가능, 사이버 위협에 취약할 수 있음)을 충족하는 경우, 2023년 3월 29일 이후 제출하는 시판 전 신청에 SBOM을 포함해야 합니다.
- 한국: 과기정통부·국가정보원·디지털플랫폼정부위원회가 2024년 5월 12일 「SW 공급망 보안 가이드라인 1.0」을 발표했고, KISA 등 기관 누리집에서 내려받을 수 있게 했습니다. 당시 정부는 SBOM 제도화를 점진적으로 준비하겠다고 밝혔습니다. 이후 과기정통부·KISA가 SBOM 기반 공급망 보안 관리체계 구축 사례집(2026년 4월)을 냈고, 과기정통부·국정원이 SBOM 활용 확산을 담은 'SW 공급망 보안 단계별 이행안(로드맵)'(2026년 6월)을 발표했습니다.
SBOM이 있으면:
- 새 취약점 발표 시 우리 제품에 해당하는지 빠르게 확인 가능
- 외주 코드에 어떤 오픈소스가 들어갔는지 목록으로 관리
- 공급망 사고 발생 시 영향 범위를 좁히는 데 활용
미국 행정명령 14028도 SBOM이 있으면 새로 발견된 취약점의 잠재적 위험에 놓였는지 빠르고 쉽게 판단할 수 있다고 설명합니다. 다만 실제로 걸리는 시간은 SBOM이 최신 상태인지, 소프트웨어 구성요소 분석(SCA) 같은 자동화 도구와 자산 목록에 연결돼 있는지에 따라 달라집니다.
공급망 보안, 어디서부터 시작해야 하나
완벽한 공급망 보안은 한 번에 만들 수 없습니다. 하지만 현재 우리 회사의 공급망 리스크가 어디에 있는지 파악하는 것이 첫 단계입니다.
먼저 할 일은 세 가지입니다.
- 외주 개발사, 연동한 SaaS, 주요 오픈소스 패키지 목록을 한 문서로 정리합니다.
- 각 항목이 접근하는 계정·데이터·권한을 적고, 끝난 계약의 계정과 키부터 회수합니다.
- 우리 저장소와 납품받은 코드에 하드코딩된 키가 없는지 스캔합니다.
SENTRIX의 모의해킹·취약점 진단은 외주로 납품받은 웹·앱·API가 실제 공격에 뚫리는지 점검하며 점검 깊이(블랙박스·그레이박스·화이트박스)는 상담 단계에서 정하고, 보안 아키텍처 리뷰의 데이터 흐름·암호화 평가에서는 외부 연동으로 데이터가 어디까지 흐르는지 함께 검토합니다(연동 앱을 어디까지 볼지는 사전에 협의합니다). 외부자 관리는 ISMS-P 인증 기준 2.3 외부자 보안에도 해당합니다. 외부 검토가 필요하면 모의해킹·취약점 진단 상담을 요청하세요.
참고 자료
- 안랩 ASEC, 2026년 1분기 공격기법 동향보고서(2026-04-10)
- 과학기술정보통신부, 2026년 상반기 사이버 위협 동향 발표(2026-07-30)
- IBM, IBM 2026 X-Force Threat Index: AI-Driven Attacks are Escalating as Basic Security Gaps Leave Enterprises Exposed(2026-02-25)
- 과학기술정보통신부, 티빙(TVING) 침해사고 조사결과 발표(2026-09-03)
- 과학기술정보통신부, 정부, 소프트웨어 공급망 보안 가이드라인(지침) 1.0 발표(2024-05-12)
- 과학기술정보통신부, 복잡한 공급망 보안 체계 구축, 사례집을 활용하세요!(2026-04-16)
- 과학기술정보통신부, 정부, 소프트웨어(SW) 공급망 보안 단계별 이행안(로드맵) 발표(2026-06-24)
- 미국 관리예산처(OMB), M-26-05 Adopting a Risk-based Approach to Software and Hardware Security(2026-01-23)
- 미국 관리예산처(OMB), M-22-18 Enhancing the Security of the Software Supply Chain through Secure Software Development Practices(2022-09-14)
- 미국 연방관보(Federal Register), Executive Order 14028 Improving the Nation's Cybersecurity(2021-05-12)
- 미국 법전, 21 U.S.C. 360n-2 Ensuring cybersecurity of devices