들어가며
보안 사고가 터지면 기업은 시스템부터 격리하고 로그를 뜯어보며 원인을 찾습니다. 그런데 이 원인이 종종 "해킹당했다" 또는 "바이러스에 감염됐다"는 한 줄짜리 설명으로 뭉뚱그려지는 경우가 많습니다.
문제는 여기서 시작됩니다. 악성코드 사고인데 취약점 패치만 하고 끝내거나, 반대로 취약점 사고인데 백신만 깔고 마무리하는 실수가 실제로 벌어집니다. 이처럼 원인을 제대로 구분하지 않으면 대응도 어긋날 수밖에 없습니다.
악성코드(Malware)와 취약점(Vulnerability)은 비슷해 보이지만, 근본적인 원인과 대응 방식, 심지어 사용해야 할 관리 도구까지 다릅니다.
이 글에서는 실제로 벌어졌던 두 사고를 통해 이 차이를 짚어보고, 기업이 각각에 어떻게 대응해야 하는지 정리했습니다.
사례로 보는 차이
사고 1. 통신사 유심 정보가 통째로 빠져나간 날
2025년 4월, A 통신사의 인증 서버(HSS)에서 이상 징후가 포착됐습니다. 조사 결과 공격자는 BPFDoor라는 백도어 악성코드를 심어놓고 무려 987일(추정 최초 침투 2021년 8월) 동안 조용히 숨어있었습니다. 그 결과 전화번호, IMSI, 인증키(Ki)까지 약 2,696만 건의 정보가 유출되었고, 회사는 전 고객 대상 무료 유심 교체를 진행했습니다.
여기서 주목할 핵심은 따로 있습니다. 공격자가 BPFDoor를 심을 수 있었던 배경에는 2016년에 이미 패치가 나온 리눅스 OS 취약점(DirtyCow)이 방치돼 있었다는 사실입니다. 즉, 진입로는 취약점이었고, 실제 정보 탈취를 수행한 것은 악성코드였습니다.
•
사고 유형: 악성 코드 → 공격자가 만든 프로그램이 실제로 시스템에 설치되어 동작했다는 점이 핵심입니다.
사고 2. 전 세계 SharePoint 서버를 뒤흔든 "ToolShell"
공개 며칠 만에 전 세계 85대 이상, 29개 기관의 서버가 뚫렸고, 미국 에너지부 산하 기관도 피해를 입었습니다. CISA는 이 취약점을 즉시 KEV(악용 확인된 취약점) 목록에 올리고 연방기관에 조속한 조치를 지시했습니다.
공격자들은 이 취약점으로 인증을 우회해 서버에 진입한 뒤, 웹셸을 심고 SharePoint 설정 파일 속 암호화 키까지 탈취해 지속적으로 서버를 장악했습니다.
•
사고 유형: 취약점 → 공격자가 직접 만든 코드가 아니라, 소프트웨어 자체에 내재되어 있던 결함이 공격의 출발점이었습니다.
그래서 뭐가 다른가?
구분 | 악성코드 (Malware) | 취약점 (Vulnerability) |
정의 | 공격자가 제작해 시스템에 설치한 악의적 프로그램 | 소프트웨어 개발 시점부터 존재하던 구조적 결함 |
위험시점 | 발견 시점에 이미 공격이 진행 중이거나 완료된 상태 | 공개되기 전에도 이미 악용되고 있을 수 있음(제로데이) |
대표사례 | 통신사 사고(악성코드 33종, 2025년 4월, A통신사)
*관련기사 URL: https://www.msit.go.kr/bbs/view.do?sCode=user&mId=307&mPid=208&bbsSeqNo=94&nttSeqNo=3185964 | SharePoint 사고(CVE-2025-53770, 2025년 7월, Microsoft)
*관련기사 URL:CVE-2025-53770 - 보안 업데이트 가이드 - Microsoft - Microsoft SharePoint Server 원격 코드 실행 취약성 |
핵심은 출발점의 차이입니다. 그러나 실무에서는 이 두 가지가 독자적으로 존재하기보다 연쇄적으로 작용하는 경우가 훨씬 흔합니다.
•
통신사 사고: 악성코드가 실제 실행 지점이었지만, 그 설치 경로엔 방치된 OS 취약점이 있었습니다.
•
SharePoint 사고: 취약점이 진입로였지만, 침투 후 공격자는 곧바로 웹셸(악성스크립트)을 심어 거점을 확보했습니다.
정리하면 두 사고 모두 취약점으로 들어와 악성코드로 눌러앉는 같은 패턴을 공유합니다. 사고 원인을 하나로만 정리하는 순간, 공격 체인의 절반을 놓치게 됩니다.
그럼 기업은 무엇을 준비해야 하는가?
취약점만 잘 관리하면 악성코드는 괜찮겠지? 라는 판단은 위험하다. 악성코드, 취약점 모두 대응체계를 갖춰야 한다. 원인에 따라 탐지하는 지점과 필요한 솔루션/기술이 각각 다르다.
구분 | 악성코드 | 취약점 |
핵심 조치 | 감염 경로 차단, 감염 시스템 격리 및 악성 파일 제거 | 소프트웨어 결함 식별, 패치 적용 및 컴포넌트 교체 |
도구 범주 | 공급망 보안 솔루션 | SCA(Software Composition Analysis) 도구 |
주요 역할 | 패키지에 섞여 들어오는 악성코드를 다운로드 이전 단계에서 탐지·차단 | 사용 중인 오픈소스 컴포넌트 목록을 파악하고 알려진 취약점(CVE) 식별/패치 |
참고 | Sonatype Firewall, JFrog Xray 등 |
이렇게 관리 대상이 완전히 다르기 때문에, 취약점 사고를 공급망 보안 솔루션으로만 막으려 하거나 악성코드 유입을 SCA 도구에만 의존하려 하면 반드시 보안 사각지대가 발생합니다.
결론, 둘 다 봐야 한다.
악성코드와 취약점은 서로 다른 방식으로 시스템을 위협합니다. 어떤 공격은 악성코드만으로 이루어지고, 또 다른 공격은 오직 취약점만을 파고들기도 합니다.
물론, 앞선 사례처럼 공격자가 취약점을 통해 시스템에 침투한 뒤 악성코드를 설치하는 연계 공격도 빈번합니다.
이처럼 공격의 형태가 다양하기에, SCA 도구로 취약점만 관리하거나 공급망 보안 솔루션만 운영하는 방식으로는 전체 공격 경로를 파악하고 방어할 수 없습니다.
오픈소스를 사용하는 기업이라면 이 두 관점을 같이 가져가는 게 좋습니다.
•
SCA 도구 검토 시: 단순히 SBOM을 뽑아내고 취약점을 나열하는 데 그치지 않고, 발견된 취약점의 위험 우선순위를 분석해주거나 개발 정책에 따라 자동으로 차단하는 등 실질적인 대응까지 돕는 기능을 갖췄는지 반드시 확인해야 합니다.
•
공급망 보안 솔루션 검토 시: 검증되지 않은 패키지가 파이프라인에 들어오기 전 단계를 빠짐없이 검사하는지, 위험 발견 시 실제로 차단까지 이어지는지를 확인해야 합니다.
오픈소스 컴포넌트는 매일같이 늘어나고, 새로운 위협은 더욱 정교하게 위장하며 우리를 위협합니다. 이처럼 복잡한 환경에서 가장 먼저 해야 할 일은, 우리가 무엇을 막고 있는지 명확히 아는 것입니다.
유입되는 코드(악성코드)와 사용 중인 코드(취약점)는 탐지해야 할 시점과 대상이 명백히 다릅니다.
진정한 오픈소스 보안은 바로 이 탐지 시점을 명확하게 구분하는 것에서 시작됩니다. 이 구분이 선행되어야만, 두 개의 위협을 차단하는 효과적인 방어 체계를 완성할 수 있습니다.
참고 자료
본 글은 정부·조사기관의 공식 발표와 주요 언론 보도를 근거로 작성되었습니다.•
민관합동조사단, A 통신사 침해사고 최종 조사결과 발표 (2025.7, 정책브리핑)
•
데일리시큐, BPFDoor 악성코드를 이용한 국내 통신사 침해 사고 민관합동조사단 발표 관련 보도 (2025.7)
•
CISA, Known Exploited Vulnerabilities Catalog — CVE-2025-53770 등재 (2025.7)
•
Microsoft Security Response Center, CVE-2025-53770 보안 권고 (2025.7)
오세덕 프로
오픈소스 거버넌스 업무