[SW 공급망 보안②] SBOM이 능사 아니다
상태바
[SW 공급망 보안②] SBOM이 능사 아니다
  • 김선애 기자
  • 승인 2023.07.12 09:17
  • 댓글 0
이 기사를 공유합니다

SBOM, 일회성 구축 사업에 그치면 SW 공급망 보호 못해
발견된 취약점, 패치 안하면 SBOM 무용지물

[데이터넷] 소프트웨어 공급망이 공격자들의 중요한 먹잇감이 되고 있다. 복잡한 공급망의 한 지점만 침투하면 공급망에 연결된 모든 조직을 공격할 수 있기 때문이다. 보안에 소홀한 SW 개발사, 깃허브와 같은 코드 저장소, 오픈소스 취약점 등은 공급망 공격에 매우 취약하다. 대형 글로벌 기업의 코드서명 인증서가 탈취도 공격에 악용되고 있기도 하다. 소프트웨어 공급망 공격 동향을 분석하고, 필요한 대안을 제안한다.<편집자>

공급망 보호 위해 SBOM 주목

공급망 공격 방어 기술 중 하나인 SBOM이 주목받고 있다. SBOM은 소프트웨어 개발 시 사용한 컴포넌트를 정리해 해당 컴포넌트와 의존성에 대한 정보를 관리하는 시스템이다. 로그포제이(Log4j)와 같은 신종 취약점이 발견됐을 때 SBOM을 확인해 취약점 영향을 받는 파일을 찾아 위험분석을 수행할 수 있다. 소프트웨어 설치, 구성, 유지관리를 수행할 때 SBOM을 참고해 소프트웨어 전반의 잠재적인 위험을 식별할 수 있고, 취약점 영향을 받는 요소의 위치를 정확하게 파악해 빠르게 조치할 수 있다.

SBOM을 생성할 때 통합 구조를 정의하고, 최종 사용자에게 공유하기 위한 표준포맷이 필요하다. 한국정보보호산업협회 ‘2022 공급망 보호를 위한 SBOM 조사 보고서’에서 설명한 중요 SBOM 포맷은 다음과 같다.

SPDX (Software Package Data eXchange): 리눅스 재단에서 운영하는 프로젝트인 SPDX는 공유하고 수집하기 위한 소프트웨어 패키지와 관련된 정보에 대해 데이터 교환 포맷을 만드는 것을 목적으로 시작했다. 주요 SBOM 포맷 중 가장 많은 파일 형식을 지원하며, 일련의 소프트웨어 패키지, 파일, 스니펫(Snippet)을 설명한다.

전체 SPDX가 필요하지 않을 경우 라이트(Light) 표준을 사용할 수 있다. 오픈소스 라이선스에 대한 지식이나 경험이 없어도 쉽게 사용할 수 있으며, SPDX 표준과 실제 워크플로우 간의 균형을 유지할 수 있도록 돕는다.

사이클론DX(CycloneDX): 사이클론DX는 애플리케이션 보안 컨텍스트 및 공급망 구성 요소 분석에 사용하도록 설계된 경량의 SBOM 표준이다. 주요 지원 기능은 BOM 링크, 출처(Provenance), VEX(Vulnerability Exploitability eXchange), 해시값과 암호화를 통한 BOM 관련 구성요소의 무결성 검증 등이 있다.

SWID - 소프트웨어 식별 태그: SWID는 주로 라이선스에 중점을 둔 표준이다. SWID 태그가 소프트웨어 제품 설치 프로세스의 일부로 추가되며, 소프트웨어 수명주기 전반에서 소프트웨어를 쉽게 검색, 식별, 컨텍스트화 해 기업이 정확한 소프트웨어 사용 명세를 관리할 수 있도록 한다.

이 보고서에서는 SBOM에 필요한 최소 요건으로 다음의 세 가지 범주를 추가로 설명했다. 이는 소프트웨어 투명성을 강화할 수 있도록 기술적·기능적 요소를 지원하기 위한 것이다.

데이터 필드: 데이터 필드에는 추적하고 유지 관리해야 하는 각 구성 요소에 대한 기본 정보가 있다. 이 정보는 공급자 이름, 컴포넌트 이름과 버전, 기타 고유의 식별자, 의존성 관계, SBOM 데이터 작성자, 타임스탬프 등이 포함된다.

자동화 지원: 자동 생성과 기계 가독성을 포함한 자동화 지원을 통해 소프트웨어 에코시스템 전반, 특히 조직 경계 전반에 걸쳐 확장할 수 있다. 자동화 기능은 기존 취약성 관리 관행에 SBOM을 통합하거나 보안 정책 준수 여부를 감사하려는 기업에 필요하다.

실제 사용과 프로세스: SBOM은 구조화된 데이터 집합 그 이상으로, 안전한 개발 수명 주기의 운영에 통합하려면 SBOM 사용에 초점을 맞춘 관행과 프로세스를 따라야 한다. SBOM을 요청하거나 제공하기 위한 정책, 계약 또는 약정에서 많은 요소를 명시적으로 다루어야 한다. 빈도, 깊이, 알려지지 않은 불확실성, 배포(Distribution)와 전달(Delivery), 액세스 컨트롤, 실수 해결 등이 포함된다.

권장 데이터 필드: 몇 년에 걸쳐 계획되었거나 더 높은 수준의 보안이 필요한 작업에 대해 데이터 필드를 고려하는 것이 좋다. 권장하는 데이터 필드는 구성 요소의 해시, 라이프사이클 단계(Lifecycle Phase), 기타 구성요소와 관계, 라이선스 정보 등이다.

SBOM, 최신성·무결성 지켜져야

SBOM은 사용중인 소프트웨어를 검사해 알려진 취약성과 버전, 패치를 확인할 수 있어 공급망 위협에 사전에 대응할 수 있지만, SBOM이 소프트웨어 공급망 자체를 보호하는 것은 아니다. SBOM을 의무화 한 미국의 경우, 보안보다는 컴플라이언스 관점에서 SBOM을 도입하는 추세에 있는데, 자칫 잘못하면 SBOM을 위한 SBOM에 그칠 수 있다는 지적도 나온다.

소프트웨어를 구입하거나 구축하는 시점에 개발사로부터 SBOM을 제공받았다 해도, 이후 운영 과정에서 수정·변경을 할 때 SBOM도 그에 맞게 변경되지 않으면 SBOM은 구축 시점에만 유효한 일회성 솔루션에 그치고 만다. 체크박스 형식의 SBOM은 취약점 대응보다 규제준수 활동을 위한 것으로 제한돼 실제 공급망 보안 효과를 떨어뜨린다.

장일수 스패로우 대표는 “SBOM은 단순한 리스트가 아니라, 소프트웨어에서 사용하는 코드와 구성요소의 최신성을 자동으로 유지하는 관리도구이다. 1년 전 구축한 소프트웨어를 예로 들어보면, 그동안 여러 차례의 수정과 업데이트를 진행했는데 SBOM은 1년 전 공급받았던 당시와 같다면 SBOM의 역할을 하지 못한다. 소프트웨어 변경이나 새로 발견된 취약점 등을 실시간에 가깝게 파악해 취약한 요소를 즉시 알려줘야 한다”고 말했다.

그는 이어 “소프트웨어 구성 분석(SCA) 툴이나 오픈소스 툴을 이용해 SBOM을 쉽게 생성할 수 있지만, 자동차 제조사 등에서 사용하는 수많은 소프트웨어에 대한 SBOM을 커스터마이징 해 쉽게 관리할 수 있는 관리툴도 사용할 수 있으면 좋다. 무엇을 사용하든, SBOM의 최신성과 무결성이 지켜져야 한다”고 말했다.

SDLC 전 과정에서 보안 점검 수행해야

SBOM을 ‘단순한 오픈소스 리스트’로 이해하면 안된다. SBOM은 사용하는 모든 소프트웨어의 모든 구성요소와 의존성을 포함해야 한다. 오픈소스뿐 아니라 인하우스 개발이나 소트프웨어 개발사에서 공급받은 코드 등도 SBOM에 포함된다.

SBOM이 소프트웨어 공급망을 보호할 수 있다고 생각하는 것도 오해다. SBOM은 소프트웨어 구성 명세를 보여줄 뿐, 다른 보안 기능을 하는 것은 아니다. SBOM을 통해 사용중인 코드에 취약점 영향을 받는 것이 있는지 확인하고 조치하지 않으면 SBOM은 무용지물이다.

장일수 스패로우 대표는 “단 하나의 기술만으로 복잡한 소프트웨어 공급망을 보호할 수 없다. SBOM은 소프트웨어 공급망 보안을 위한 기술 중 하나일 뿐이지, SBOM만으로 공급망을 보호할 수 있다고 생각해서는 안된다”며 “소프트웨어 기획, 개발, 테스트, 배포, 운영 전 단계에서 취약점을 찾아 제거해야 한다”고 말했다.

스패로우는 애플리케이션 보안 테스팅(AST) 도구인 정적분석(SAST), 동적분석(DAST), SCA를 통합한 ‘스패로우 엔터프라이즈’를 출시하고 소프트웨어 라이프사이클 전체를 중단없이 보호할 수 있도록 지원한다. 스패로우 엔터프라이즈는 AST 모든 영역에서 검출되는 취약점을 단일 대시보드로 보여주며, 조치사항을 표시하고 지속적으로 추적해 코드 취약점이 제대로 제거됐는지, 다른 영향은 없는지 등을 보여줄 수 있다.

또 스패로우 AST 도구를 API로 제공해 서비스 기업들이 시큐어코딩이나 취약점 진단 시 쉽게 사용할 수 있도록 한다. 해외 소프트웨어 보안 서비스 기업에 OEM으로 공급하는 등 다양한 방법으로 공급할 계획이다. 현재 동남아시아 보안 컨설팅 기업들과 다양한 협력 방법을 찾고 있다.

스패로우 애플리케이션 보안 취약점 통합관리 예시
스패로우 애플리케이션 보안 취약점 통합관리 예시

스패로우는 SCA 솔루션에서 SBOM을 자동으로 생성하는 기능을 제공한다. 스패로우 SCA는 사용중인 오픈소스 라이선스와 취약점을 식별하며, 소스코드는 물론 바이너리 파일도 분석할 수 있다. 의존성 파일 분석, 코드 스니펫 분석도 지원한다. SCA에서 자동 생성되는 SBOM은 국제 표준인 SPDX, 사이클론DX, SWID 태그 형식을 사용해 상세한 소프트웨어 구성 컴포넌트 정보를 모두 포함한다. 스패로우SCA는 소프트웨어 개발 프로세스와 쉽게 연계되며, 분석 수행과 진단결과 확인을 위한 API도 제공한다.

스패로우는 생성형AI를 이용해 코드 취약점 검출과 수정 작업을 한층 수월하게 돕는다. AST 도구를 이용해 검출된 취약점을 분류하고, 최적의 수정안을 제안받으며, 오·미탐을 제거하고 정확한 코드 수정이 이뤄질 수 있도록 한다. 검출된 취약점과 유사한 코드, 래핑된 코드를 전체 소프트웨어에서 찾아 제안한다.

장일수 대표는 “소프트웨어 공급망 공격 위험성이 갈수록 심해지면서 코드보안에 대한 관심이 높아지고 있어 AST 수요는 크게 늘고 있다. 소프트웨어 개발 라이프사이클(SDLC) 전반에서 보안 기능을 내재화해야 하며 AST 솔루션을 이용해 개발부터 배포까지 모든 과정을 보호하고자 하는 고객이 증가하고 있어 고무적”이라고 말했다.


관련기사

댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.