인섹시큐리티 “SCA·SBOM으론 공급망 보안 미흡, 개발부터 배포까지 검사해야”

“기존의 소프트웨어(SW) 공급망 보안 제품들은 소스코드와 소프트웨어 구성요소 명세서(SBOM) 중심으로 점검하는 경우가 많습니다. 하지만 개발자가 저장소에 올린 코드가 깨끗해도, 이를 실제 프로그램으로 만들고 배포하는 과정에서 악성코드나 악성 패키지가 들어갈 수 있습니다. 소스코드 작성 이후 단계까지 실시간으로 반복 검사해야 합니다.”

김종광 인섹시큐리티 대표는 14일 열린 기자간담회에서 현재 시중에 있는 소프트웨어(SW) 공급망 보안 솔루션들의 한계점을 짚으며 이같이 말했다. 소프트웨어 구성요소 분석(SCA) 도구로 소스코드와 오픈소스 취약점을 점검하고 SBOM을 만들더라도, 이후 빌드·배포 과정에서 공격이 이뤄지면 언제든 결과물이 오염될 수 있다는 설명이다.

인섹시큐리티는 이 같은 빈틈을 겨냥한 제품으로 옵스왓(OPSWAT)의 ‘메타디펜더 소프트웨어 공급망(MetaDefender Software Supply Chain)’을 내세웠다. 메타디펜더는 소스코드뿐 아니라 외부 패키지와 소스코드를 실행 가능한 형태로 만든 결과물인 아티팩트, 컨테이너 이미지까지 개발·배포 과정에서 반복 검사한다. N2SF 전환 시장에서는 이 검사 기능을 서로 다른 보안영역 사이의 안전한 자료 전송과 연결할 계획이다. 악성코드 검사 등을 통과한 결과물만 정보 등급에 따라 나뉜 업무망으로 보내는 크로스도메인 기능을 앞세운다는 구상이다.

소스코드 검사해도, 이후 과정서 오염될 수 있어

기업의 SW 개발 과정은 소스코드 작성 이후에도 계속된다. 여러 개발자가 작성한 코드는 깃허브·깃랩과 같은 저장소에 모이고, 이후 지속적 통합·배포(CI/CD) 절차를 거쳐 컴퓨터에서 실행할 수 있는 파일이나 설치 패키지로 만들어진다. 이렇게 만들어진 결과물을 ‘아티팩트’라고 한다.

기업은 아티팩트를 컨테이너 이미지로 만들어 서비스에 배포하기도 한다. 컨테이너 이미지는 프로그램과 실행에 필요한 라이브러리·설정 등을 하나로 묶은 파일이다. 도커로 컨테이너를 만들고 쿠버네티스로 여러 컨테이너를 운영하는 환경에서 사용한다.

소스코드와 실제 배포물 사이에는 여러 단계가 있다. 공격자가 정상 패키지와 비슷한 이름으로 악성 패키지를 등록해 개발자의 오타를 노리는 ‘타이포스쿼팅’이 대표적인 공격이다. 인공지능(AI)이 실제로 존재하지 않는 패키지 이름을 제시하는 점을 악용해 공격자가 해당 이름을 먼저 등록하는 ‘슬롭스쿼팅’도 등장했다. 오픈소스 관리자 계정을 탈취해 악성 버전을 배포하거나, 유지보수가 중단된 프로젝트를 넘겨 받은 뒤 업데이트에 악성코드를 넣는 공격도 가능하다. 공격자가 CI/CD 서버를 장악하면 저장소에 보관된 소스코드는 그대로 둔 채 빌드 결과물에 악성 파일을 추가할 수도 있다.

김 대표는 “SCA와 SBOM이 공급망 보안의 출발점이지만, 최종 배포물의 안전성까지 보증하지는 않는다”고 설명했다. 제품마다 검사 범위는 다르지만, 기업이 SCA를 소스코드와 외부 패키지 점검에만 적용하면 이후 빌드 서버나 아티팩트·컨테이너 저장소에서 발생한 변조를 놓칠 수 있다는 것이다.

그는 “빌드 서버가 침해되면 공격자가 외부에서 악성 패키지를 내려받도록 스크립트를 바꿀 수 있다”며 “소스코드는 정상이지만 빌드 결과물에는 악성코드가 들어가는 상황이 생길 수 있다”고 말했다.

개발·연동 과정에 남은 인증정보도 공격 통로

인섹시큐리티는 개발·서비스 연동 과정에 남은 인증정보가 실제 공격에 악용될 수 있다며, 국내 온라인동영상서비스(OTT) 플랫폼에서 발생한 침해사고와 전자지급결제대행(PG)사 가맹점의 결제 연동 인증정보가 노출된 사고를 사례로 들었다.

OTT 플랫폼 사고에서는 개발환경 접속키와 소스코드에 남아 있던 운영 환경 접속키가 공격 경로로 쓰였다. 공격자는 탈취한 개발환경 접속키로 소스코드 저장소에 들어간 뒤, 코드에 포함된 운영환경 접속키를 확보했다. 이후 운영 시스템과 회원 데이터베이스(DB)에 접근했다.

PG사 관련 사고에서는 가맹점 웹사이트의 결제 연동 인증정보가 외부에 노출됐다. 제3자는 이 정보를 이용해 해당 가맹점의 결제내역을 조회했다. PG사 시스템이 직접 침해된 것은 아니지만, 가맹점과 결제 서비스를 연결하는 과정에서 인증정보가 노출되면서 사고로 이어졌다.

김 대표는 “두 사고가 빌드 결과물에 악성코드를 넣는 공급망 공격과는 경로가 다르지만, 소스코드나 서비스 연동 과정에 남은 비밀번호와 접속 토큰, API키가 실제 공격에 악용될 수 있다는 점을 보여준다”고 설명했다.

그는 “핵심은 인증정보가 코드에 포함되는 시점을 예측하기 어렵다는 점”이라며 “최초 점검 당시에는 없었던 접속키를 개발자나 협력사가 이후 코드에 추가할 수 있다”고 설명했다. 이어 “개발자가 수십명에서 수백명에 이르는 환경에서는 보안 담당자가 모든 변경 사항을 일일이 확인하기도 어렵다”고 덧붙였다. 이어 “모의해킹이나 컨설팅을 통해 한 차례 검사하는 것으로는 부족하다”며 “소스코드가 저장소에 올라오거나 수정될 때마다 인증정보와 악성코드, 악성 패키지를 검사할 수 있어야 한다”고 강조했다.

옵스왓 메타디펜더, 저장소 변경 감지해 자동 검사

인섹시큐리티에 따르면, 옵스왓의 메타디펜더 소프트웨어 공급망은 소스코드 저장소뿐 아니라 아티팩트 저장소와 컨테이너 레지스트리를 연결해 검사한다. 소스코드, 빌드 결과물, 컨테이너 이미지로 이어지는 각 단계에서 악성코드와 취약점, 노출된 인증정보, 민감정보, 라이선스 문제를 실시간으로 확인하고 공유한다.

깃허브(GitHub), 깃랩(GitLab), 비트버킷(Bitbucket)과 같은 소스코드 저장소를 지원한다. 제이프로그(JFrog)와 넥서스(Nexus) 등 아티팩트 저장소, 하버(Harbor) 같은 컨테이너 레지스트리에도 연결할 수 있다. 지원 목록에 없는 저장소는 표현 상태 전송(REST) 애플리케이션 프로그래밍 인터페이스(API)를 통해 연동할 수 있다는 설명이다.

검사는 저장소에서 파일을 추가하거나 수정하면 자동으로 시작한다. 저장소가 변경 사실을 ‘웹훅’으로 알리면 메타디펜더가 새로 올라온 대상을 가져와 검사하는 구조다. 웹훅은 특정 사건이 발생했을 때 다른 시스템에 이를 자동으로 알려주는 기능이다.

기존에 검사했던 파일까지 매번 다시 보지는 않는다. 파일의 고유한 지문인 해시값을 비교해 새로 추가하거나 변경한 파일만 골라 검사한다. 개발자가 별도의 보안 도구를 직접 실행하지 않아도 기존 개발 절차 안에서 검사를 반복할 수도 있다.

검사에는 여러 백신 엔진을 함께 사용하는 멀티스캐닝과 SBOM 분석, 취약점 검사, 데이터 유출 방지(DLP) 기능을 적용한다. DLP는 소스코드에 포함된 비밀번호와 API 키, 접속 토큰, 개인정보 등 외부에 노출되면 안 되는 정보를 찾는 역할을 한다. 알려지지 않은 파일의 행위를 별도 환경에서 확인하는 샌드박스도 결합할 수 있다.

인터넷에 연결하지 않은 기업 내부 환경에도 구축할 수 있다. 외부 클라우드에 소스코드를 보내기 어려운 공공기관과 금융회사, 국방·중요 인프라 기관도 사용할 수 있다.

최준혁 인섹시큐리티 과장은 “언제 어느 단계에서 악성코드가 들어올지 알 수 없기 때문에 소스코드뿐 아니라 패키지·빌드·배포 단계에 반복 검사를 적용해야 한다”며 “소스코드와 아티팩트, 컨테이너 저장소별로 검사 정책을 다르게 설정할 수 있다”고 설명했다.

인섹시큐리티는 이날 소스코드를 빌드하는 과정에서 악성 파일이 결과물에 추가되는 상황을 시연했다. 소스코드 저장소 검사에서는 문제가 없었지만, 빌드가 끝난 아티팩트를 다시 검사해 악성 파일을 찾았다. 정상 결과물은 운영망 저장소로 보냈고 악성 파일이 들어간 결과물은 전송 전에 차단했다.

정부 가이드라인에도 탐지·차단 절차 구체화 필요

정부는 2024년 ‘SW 공급망 보안 가이드라인 1.0’을 배포했다. 가이드라인은 공개 저장소의 악성 패키지, CI/CD 코드와 저장소·컨테이너·빌드 서버 침해 등을 주요 공급망 공격 유형으로 제시한다. 개발사가 수행할 조치로 빌드 체인 공격 대응과 최종 패키지 검증도 권고한다.

가이드라인은 SW 구성요소를 파악하는 SBOM 생성과 알려진 취약점·라이선스 분석 방법도 담고 있다. 정부는 기업과 기관이 공급망에 포함된 구성요소를 확인하고 취약점 발생 시 신속하게 영향을 파악할 수 있도록 SBOM 확산을 추진하고 있다.

김 대표는 “정부의 SW 공급망 보안 가이드라인에서 악성코드와 악성 패키지를 반복 검사하고 위험한 결과물의 배포를 막는 절차를 더 구체적으로 제시할 필요가 있다”고 조언했다. 그는 “현재 가이드라인에도 악성코드와 악성 패키지의 위험이 나오지만, 실제 적용 내용은 SBOM을 만들고 구성요소의 취약점과 라이선스를 진단하는 것에 초점이 맞춰져 있다”며 “코드 진단에서 탐지와 차단까지 이어지는 더 세부적인 공급망 보안 지침이 필요해 보인다”고 짚었다.

N2SF 시장, 크로스도메인 기술로 공략

인섹시큐리티는 옵스왓 메타디펜더를 통해 N2SF 시장에서 크로스도메인 보안을 핵심 사업으로 추진한다. N2SF는 국가·공공기관의 업무정보와 정보시스템을 기밀(C), 민감(S), 공개(O)로 분류하고 등급과 위험 수준에 따라 보안 통제 기술을 다르게 적용하는 보안 체계다.

기관이 망을 분리하더라도 업무 과정에서는 데이터와 SW를 서로 다른 보안영역으로 옮겨야 한다. 개발망에서 만든 프로그램을 운영망에 배포하거나 외부에서 받은 파일을 내부 업무망으로 반입하는 경우다. 이때 전송 대상에 악성코드나 민감정보가 포함됐는지 검사하고, 보안정책을 통과한 파일만 옮기도록 통제하는 기술이 크로스도메인 솔루션(CDS)이다.

메타디펜더의 크로스도메인 전송 기능은 개발망에서 소스코드와 아티팩트·컨테이너 이미지를 검사한 뒤 정책을 통과한 결과물만 운영망으로 전달한다. 파일의 등급과 유형, 출처를 확인하고 악성코드나 민감정보가 발견되면 전송을 막는 방식이다.

문서 파일에는 ‘콘텐츠 무해화(CDR)’ 기술도 적용할 수 있다. CDR은 문서에 포함된 매크로와 스크립트, 숨겨진 객체 등 공격에 이용될 수 있는 요소를 제거한 뒤 파일을 다시 만드는 기술이다. 김 대표는 “N2SF의 C, S등급 정보가 이동하는 구간을 중심으로 시장에서 CDR 적용 요구가 커질 것”이라고 전망했다.

망 사이에서 데이터의 이동 방향을 한쪽으로 제한해야 할 때는 데이터 다이오드를 결합한다. 데이터 다이오드는 물리적으로 역방향 통신을 막아 허용한 방향으로만 데이터를 보낸다. 메타디펜더가 ‘어떤 파일을 보낼 수 있는지’를 판단한다면, 데이터 다이오드는 ‘어느 방향으로 보낼 수 있는지’를 결정한다.

파일을 망 사이에서 주고받을 때는 ‘메타디펜더 관리형 파일 전송(MetaDefender MFT)’을 이용할 수 있다. 사용자와 단말을 인증하고, 부서·업무별 전송 권한과 관리자 승인 절차를 적용한다. 전송 과정에서 악성코드와 민감정보를 검사하고 결과와 전송 기록을 남긴다.

김 대표는 “N2SF에서는 데이터 등급에 따라 망 사이를 이동할 때 정책을 적용해 허용하거나 차단해야 한다”며 “메타디펜더의 검사 기술과 크로스도메인 전송을 결합해 안전성을 확인한 파일과 SW만 보안 경계를 통과시키는 것이 핵심”이라고 강조했다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network