[데이터넷] 클라우드는 ‘코드’로 운영된다. 모든 서비스가 코드로 제작될 뿐 아니라 인프라까지도 코드로 구성된다. 이 환경에서 개발단계부터 운영단계까지 전체 라이프사이클을 아우르는 코드 보안 도구와 컴플라이언스 툴이 필요하며, 코드를 공급받는 수요자 관점에서의 보안도 필수다. 코드 보안 기술 트렌드와 시장 동향을 알아본다. <편집자>

AppSec 영역 중 최근 큰 관심을 모으고 있는 것이 오픈소스 보안이다. 시높시스 조사에 따르면 전 세계 17개 산업분야에서 사용 중인 애플리케이션 중 오픈소스를 포함한 코드베이스가 97%에 이른다. 그 중에서 취약점이 1개 이상 있는 코드베이스가 81%, 고위험 취약점을 가진 코드베이스는 49%에 달한다. 코드베이스 53%는 라이선스 충돌을 포함하고 있다.

2년 이상 업데이트되지 않은 오픈소스 구성요소 포함 비율이 88%, 4년 이상 방치된 오픈소스 포함 비율이 85%에 이른다. 오랫동안 업데이트되지 않은 오픈 소스는 취약점 관리도 되지 않은 상태일 경우가 많아 공격에 악용될 가능성이 높다.

취약점 파악 어려운 오픈소스

오픈소스 취약점은 공급망 공격에 이용될 수 있다. 해커의 주요 타깃이 되는 IoT, 항공우주, 항공, 자동 차, 교통, 물류 시스템에서 사용하는 소프트웨어의 92%가 오픈소스로 이뤄졌으며, 그중 64%는 고위험 취약점을 갖고 있는 것으로 분석됐다. 항공우주 등 분야는 오픈소스 사용률이 평균보다 낮은 60%이지만, 고위험 취약점은 평균보다 높은 60%에 이른다.

개발 단계에서 오픈소스 취약점을 해결하는 것이 쉽지 않다. 코드 없이 라이브러리로 제공되는 오픈소스의 보안 취약점은 소스코드를 분석하는 SAST로 찾아내기 어렵다.

오픈소스를 제공하는 커뮤니티와 개발자의 평판을 참고해 믿을 수 있는 코드만을 가져오기 때문에 안전하다고 하지만, 오픈소스 커뮤니티에서 모든 취약점을 다 파악하고 있다고 장담할 수 없다. 또한 신뢰할 수 있는 개발자라도 취약점이 포함된 패키지를 업로드 할 수 있다. 개발자가 감염되어 패키지에 취약점이 삽입되거나 개발자 계정이 탈취돼 악성 패키지가 업로드 되는 경우도 있으며, 타이포스쿼팅, 체인재킹 등으로 악성 패키지가 정상 패키지로 둔갑해 개발자들의 선택을 받을 수 있다.

체크막스가 설명한 오픈소스 악성 패키지 유형 중에 서는 미숙한 공격자도 쉽게 공격할 수 있는 의존성 혼동(Dependency Confusion)이 있다. 신뢰할 수 있는 패키지와 동일하거나 유사한 이름의 악성 패키지를 업로드 하는 것을 말하는데, 이러한 악성 패키지가 깃허브 퍼블릭 리포지토리에서 재사용되는 경우가 많다. 또 공격자들은 패키지 코드를 난독화 해 오픈소스 커뮤니티에서 탐지하기 어렵게 만들고 있다.

조직 절반 “오픈소스 보안 정책 없거나 알지 못해”

공급망 공격 위험을 줄이는 방법으로 소프트웨어 재료 명세서(SBoM)가 논의되고 있으며, 미국 정부는 이를 의무화하기도 했다. 우리나라에서도 사이버 보안을 국가 10대 필수 전략 기술 중 하나로 선정하면서 공급망 보안을 중점 기술 중 하나로 여기고 있고, 그 일환으로 SBoM의 필요에 대해 적극적으로 고려하는 중이다.

SBoM은 애플리케이션을 공급할 때 여기에 포함된 코드의 목록을 기록한 것이다. 오픈소스 이름과 버전, 외부 개발사와 프로젝트명 등을 기록해 향후 취약점이나 장애, 업그레이드 시 애플리케이션 코드구성을 파악하기 위한 것이다.

SBoM은 AppSec을 위한 부차적인 요구사항일 뿐, 보안을 위한 근본적인 해결책은 아니다. SBoM이 정확하게 작성됐는지 여부를 검증하기 어렵고, SBoM이 침해를 당해 위·변조되거나 공격자의 손에 들어가 침입할 수 있는 취약점을 파악하기 쉽게 할 수도 있다.

오픈소스 보안의 가장 심각한 문제는 보안에 대한 인식이 여전히 낮다는 것이다. 스닉(Snyk)과 리눅스파운데이션의 조사에 따르면 조직의 34%가 오픈소스 보안 정책을 수립하지 않았으며, 17%는 계획이 있는지 없는지 모른다고 답했다. 오픈소스 보안 취약성을 해결하는데 걸리는 시간은 평균 97.8일이며 닷넷(.Net)은 무려 149일이 걸린다. 일부 관리자들은 몇 년 동안 문제를 해결하지 못한다고 털어놨다.

쉽게 재사용할수 있는 오픈소스는 복잡한 ‘의존성(Dependencies)’의 문제도 있다. 의존성은 하나의 프로젝트에 포함되는 패키지를 말하는데, 애플리케이션 이 패키지 A를 사용하고, 패키지 A가 패키지 B를 사용하면 애플리케이션은 간접적으로 패키지 B에 종속된다. 패키지 B에 취약점이 있으면 이 애플리케이션에 취약점이 있다. 그러나 ①애플리케이션에 속한 ②패키지 A에 속한 ③패키지 B에 취약점이 있다는 것을 일반 취약점 진단 도구로 찾기 어렵다.

애플리케이션이 많아지면 이 같은 의존성 문제도 심각하다. 스닉에 따르면 프로젝트당 평균 의존성이 68.8로 조사됐으며, 파이썬은 평균 25개, 자바스크립트는 평균 173개의 의존성을 갖는다.

스닉 보고서에서는 “오픈소스 보안은 취약성이 있는 라이브러리 위치를 빠르게 찾아 조치하는 것인데, 하나의 애플리케이션에 수많은 패키지들이 복잡하게 얽히면서 취약한 라이브러리를 찾는 것이 매우 어렵게 됐다”며 “SCA 도구는 이러한 문제를 해결해 줄 수 있다”고 설명했다.

오픈소스 취약점 해결 위해 SCA 필수

오픈소스 보안과 컴플라이언스를 제공하는 스닉이 SCA 분야에서 뛰어난 경쟁력을 보이고 있다. OSBC를 통해 국내에 공급되는 스닉의 제품군은 ▲코드 ▲오픈소스 ▲컨테이너 ▲IaC 취약점 진단 모듈로 구성돼있으며, 모든 종류의 코드 취약점을 소프트웨어 배포 전, 개발 단계에서 진단하고 해결할 수 있게 한다. 또한 소스코드 저장소와 연동된 UI를 통해 자동으로 수정하거나 CLI에서 명령어 하나로 취약점 없는 버전으로 수정할 수 있게 한다.

스닉은 방대하고 정확한 취약점 정보를 보유하고 있다. 스닉의 취약점 DB는 CVE 취약점 대비 4.4배 많은 취약점 정보를 포함하고 있고, NVD 대비 최대 46일 더 빠르게 취약점을 탐지했다. NVD의 자바 스크립트 관련 취약점의 92%는 스닉이 먼저 탐지한 것이다.

개발도구, 형상관리, CI/CD, 런타임, 레지스트리, 이슈관리 등 모든 개발 환경 도구와 원활하게 연동할 수 있으며, 구글, 몽고디비, 세일즈포스, 아틀라시안 등에서도 스닉을 활용하고 있다. 스닉은 올해 초 클라우드 보안 기업 푸가(Fugue)를 인수하면서 SaaS로 제공되는 ‘스닉 클라우드’를 출시, ‘코드에서 클라우드로, 다시 코드로’ 이어지는 피드백 루프를 완성할 수 있게 됐다.

오픈소스 라이선스 관리와 보안 분야에서는 블랙덕이 가장 인지도가 높았으며, 이를 인수한 시높시스는 SAST ‘커버리티’, 퍼징 테스트 솔루션 ‘디펜직스’를 함께 제공하면서 소프트웨어 라이프사이클 전반의 위협을 관리한다.

시높시스는 가트너 매직쿼드런트 리더에 자리하고 있으며, SAST, DAST, IAST, SCA, IaC 검색, 컨테 이너 검사, 퍼징, API 테스트 등을 광범위한 제품 포트폴리오를 제공한다.

한편 소스코드 저장소인 깃랩과 깃허브가 가트너 AST 분야 매직쿼드런트에 챌린저와 니치 플레이어에 각각 올라 눈길을 끈다. 깃랩은 자체 워크플로우에서 독점·오픈소스 검색 도구와 기능을 결합한 SAST와 DAST를 제공하며, IaC 스캐닝, 컨테이너 보안을 강화했다. 개발 파이프라인 전반의 보안규정 준수를 지원하는 옵션을 제공하며, SCA 취약성 자동 교정 기능, 컨테이너 검색, 전문성 없이도 사용 가능한 퍼징 기능도 지원한다.

깃허브는 개발자 워크플로우에 통합할 수 있는 SAST와 SCA를 지원한다. 동일 프로젝트, 동일 코드 에서도 혼동 없이 작업할 수 있도록 뛰어난 협업 능력을 제공하며, 개발자 친화적인 환경을 지원해 시큐어 SDLC를 시작하는 개발자에게 유용하다.