SBOM 쓰나미에 대비하기
수년 동안 오픈소스 커뮤니티는 SBOM(Software Bills of Material)을 지지해왔습니다. 간단히 말해 SBOM은 애플리케이션이나 제품에 포함된 모든 오픈소스 구성요서의 목록입니다. SBOM은 여러가지 분명한 이점이 있습니다.
소프트웨어 개발자에게: SBOM은 개발팀이 사용 중인 모든 오픈 소스 구성 요소 의 취약점과 잠재적 위험을 파악할 수 있도록 해줍니다.
소프트웨어 소비자/제품 팀에게: SBOM은 오픈소스 구성요소를 식별하고 타사 또는 외부에서 개발된 소프트웨어 및 바이너리의 취약성에 대한 경고를 제공하므로 팀은 소스 코드에 반드시 액세스할 필요 없이 위험을 효과적으로 관리할 수 있습니다.
IT 및 운영 팀에게: SBOM은 취약점 스캐너를 보완하여, 클라우드 애플리케이션 및 컨테이너를 포함한 IT 인프라의 구성요소와 사용 위치에 대한 지속적인 취약점 경고를 제공합니다.
법률 및 컴플라이언스 팀에게: SBOM은 오픈 소스 구성 요소를 관련 라이선스에 매핑하여 지적 재산권(IP) 위엄을 초래할 수 있는 의무와 충돌을 식별합니다.
간단히 말해, SBOM이 많을수록 팀이 소프트웨어를 개발하고 사용하는 데 있어 투명성은 높아지고 위험은 줄어들게 됩니다.
SBOM에 대한 법적 요구 사항이 증가하고 있습니다.
오픈소스 커뮤니티만이 이러한 노력을 기울이는 것은 아닙니다. 공급망 보안에 대한 우려가 커지면서 입법 노력이 추진되었습니다.
미국 법률
EO 14028
2020년 SolarWinds 공격으로 인해 행정명령(EO) 14028 “국가의 사이버 보안 개선”이 발동되었습니다. EO 14028은 미국 정부에 소프트웨어를 제공하는 조직이 "제품이 안전하게 구축 및 작동되도록 보장하고, 보다 안전한 사이버 공간을 조성하기 위해 연방 정부와 협력"하도록 요구합니다. 요구 사항 중에는 “구매자에게 각 제품에 대한 소프트웨어 자재 명세서(SBOM)를 직접 제공하거나 이를 공개 웹사이트에 게시하는 것"이 있습니다.
보안 소프트웨어 개발 프레임워크 (SSDF)
NIST 발행물 800-218: SSDF(Secure Software Development Framework) 버전 1.1: 소프트웨어 취약성 위험 완화를 위한 권장 사항. 800-218을 준수하는 조직은 다음과 같은 여러 관행을 따라야 합니다.
· “모든 소프트웨어 릴리스의 구성 요소 및 기타 종속성에 대한 출처 데이터를 수집, 유지 및 공유해야 합니다.(예: 소프트웨어 자재 명세서[SBOM]).” (PS.3.2)
· 소프트웨어 구성 요소에 대한 출처 정보(예: SBOM, 소스 구성 분석 등)를 확보하고 해당 정보를 분석하여 구성 요소로 인해 발생할 수 있는 위험을 더 잘 평가해야 합니다. (PW.4.1)
식품의약국(FDA)
2022년에 의료 기기의 여러 취약점이 공개된 후, 의회는 연방식품,의약품,화장품법(FD&C Act)에 섹션 524B를 추가하여, 기기의 사이버 보안을 보장하도록 개정했습니다. 이 법에 따라 사이버 장치에 대한 시판 전 제출 서류에는 다음이 포함되어야 합니다:
· 적절한 시간 내에 취약성 공개 및 관련 절차를 포함하여 시판 후 사이버 보안 취약성과 악용을 모니터링, 식별 및 해결하기 위한 계획
· 정치 및 관련 시스템이 사이버 보안을 합리적으로 보장하고 장치 및 관련 시스템에 대한 시판 후 업데이트 및 패치를 제공하기 위한 프로세스 및 절차를 설계, 개발 및 유지관ㄹ리
· 상용, 오픈 소스 및 기성 소프트웨어 구성 요소를 포함한 소프트웨어 자재 명세서(SBOM)
유럽 법률
사이버복원력법(CRA)
CRA는 2022년에 제안되었으며 2024년에
발효될 예정입니다. CRA의 목표는 "디지털
요소가 있는 제품"(PDE)이 취약점이 적은
상태로 고객에게 제공되도록 하고 제조업체가
제품 수명주기 동안 고객의 보안을
모니터링하고 관리하도록 지원하며, PDE 구매
과정에서 제조업체가 취한 보안조치에 대해
소비자에게 알리는 것입니다.
CRA의 부록 I에는 조직이 계획, 설계, 개발 또는
계획에서 사이버 보안을 고려하도록 하기 위해
따라야하는 “필수 사이버 보안 요구사항"이 설명
되어 있습니다. 여기에는 모든 사이버 보안 위험에
대한 문서화, 모든 오픈 소스 구성 요소를 나열하는
SBOM(Software Bill of Materials), 제품 수명
동안 새로운 취약점과 적극적으로 악용되는
취약점에 대한 지속적인 모니터링 및 보고가 포함됩니다.
아시아 법률
대한민국: SW 공급망 보안 지침
이 지침은 소프트웨어 공급망 공격에 대한 정부 차원의 대응의 일부입니다. 과학기술 정보통신부, 국정원, 디지털 플랫폼정부위원회(디플위원회), 한국인터넷진흥원(KISA)이 발행한 자료입니다.
일본: 소프트웨어 관리를 위한 소프트웨어 자재 명세서(SBOM) 구현 가이드
2023년 일본 경제산업부(METI)는 소프트웨어 관리를 위한 소프트웨어 자재명세서(SBOM) 구현 가이드를 발행했습니다. 가이드 (영어, 일본어)는 3단계로 나누어집니다.
o 1단계: 환경 및 시스템 개발 – 1단계 동안 조직은 요구 사항을 숙지하고 SBOM 도구를 선택하고 사용하는 방법을 배울 수 있습니다.
o 2단계: SBOM 제작 및 공유 – 2단계에서는 스캔 애플리케이션을 능숙하게 사용하여 내부 및 외부에서 사용할 수 있는 형식으로 SBOM을 생성하는데 중점을 둡니다.
o 3단계: SBOM 사용 및 관리 – 3단계에서는 팀이 프로덕션에서 SBOM 도구를 사용하여 보안 및 라이선스 위험을 관리합니다. 여기에는 "심각도 평가, 영향 평가, 취약점 수정, 잔여 위험 확인"이 포함됩니다.
SBOM의 쓰나미
오늘날 조직들은 자체적으로 개발한 애플리케이션에 대해 SCA(소프트웨어 구성 분석)도구를 사용하여 SBOM을 생성하고 보안 및 라이센스 위험을 완화합니다. 공급업체(또는 공급업체의 공급업체)로부터 제 3자 또는 4자 SBOM을 관리해야 하는 경우는 거의 없었습니다.
하지만, 이 상황이 곧 변화할 것입니다. 변화하는 법률 환경으로 인해 공급업체와 파트너로부터 수백 또는 수천 개의 SBOM이 조직에 유일될 것입니다.
써드파티 SBOM관리의 과제
보안 및 위험 관리 팀은 소프트웨어 또는 소프트에어가 포함된 제품을 제공하는 모든 기업으로부터 SBOM을 받을 수 있는 환경에 대비해야 합니다. 이로 인해 몇 가지 해결해야 할 일들이 생깁니다.
SBOM 검증 불가 : SBOM을 수동으로 작성하거나 오픈 소스 도구를 선택한 소프트웨어 공급업체는 중요한 오픈소스 컴포넌트를 누락할 가능성이 높습니다.
소스 코드에 대한 접근 불가 : 소프트웨어 공급업체는 소스코드를 제공하지 않기 때문에, 애플리케이션과 소프트웨어에 대해 소비업체가 독립적으로 SBOM을 생성할 수 없습니다.
표준화된 취약점 및 라이선스 데이터 부재 : 새로운 취약점이 공개되어도 공급업체는 수동으로 조회하거나 SBOM을 업데이트하지 않기 때문에 이로인해 소프트웨어 사용자가 위험에 노출될 수 있습니다
정책에 대한 가시성 부족 : 소프트웨어를 개발하는 조직은 필요한 오픈 소스 라이선스와 보안 표준에 대한 정책이 있을 수 있지만, 외부의 제3자(또는4자 공급업체)는 해당 정보를 거의 공개하지 않습니다.
써드파티 SBOM 관리 모범 사례
수백 또는 수천 개의 써드파티 SBOM 전반에 걸친 보안 및 라이선스 위험 관리는 아래 네 가지 모범 사례를 따름으로써 간소화 할 수 있습니다.
1. 모든 SBOM을 중앙에서 관리하기
이 단계는 간단합니다. 수십 또는 수백 개의 SBOM을 수동으로 관리하거나 자체 데이터베이스에서 관리하는 것은 지속 가능한 솔루션이 아닙니다. 대신, 내부 및 외부에서 생성된 모든 BOM에 대한 단일 저장소 역할을 하는 SBOM 솔루션을 찾으십시오. 모든 컴포넌트 식별자, 심각도 점수, 라이센스 또는 보안 데이터가 신뢰할 수 있는 소스에서 나온 것인지 확인하십시오.
2. 전체 공격면에 대해 SBOM을 유지하기
웹 애플리케이션과 IT 인프라는 대부분의 조직에서 가장 중요한 공격면일 가능성이 큽니다. 기기 펌웨어, 애플리케이션 및 IT 인프라의 취약한 오픈소스 구성요소는 공격자가 쉽게 공격할 수 있는 벡터를 제공합니다. 이를 통해 공격자는 우회하고, 권한을 승격하고, 랜섬웨어, 지능형 지속 위협(APT), 데이터 도난 등의 공격을 실행할 수 있습니다.
SBOM을 생성하는 데 반드시 소스 코드가 필요한 것은 아닙니다. 일부 Binary SCA(바이너리 소프트웨어 구성요소 분석) 도구를 사용하면 소스 코드에 접근하지 않고도 SBOM을 생성할 수 있으며, 이는 소프트웨어 라이선스 계약을 위반하지도 않습니다.
애플리케이션과 달리 조직에 도입되는 IT 인프라는 공식적인 SDLC(소프트웨어 개발 생명주기)를 따라 도입되는 것이 아니므로, IT인프라를 SBOM에 포함하는 것이 매우 중요합니다. 바이너리 SCA 솔루션은 IT인프라의 OS와 OS에 설치되어 제공되는 프로그램들을 분석해서 SBOM을 자동으로 생성하며 컴포넌트의 라이선스 및 취약점 정보를 제공합니다. 이렇게 생성된 SBOM을 이용하여 조직은 취약한 구성 요소를 식별하고 우선 순위에 따라 조치를 취할 수 있도록 돕습니다.
3. 중요한 써드파티 SBOM을 검증하기
모든 애플리케이션과 제품이 조직에 동일한 위험을 초래하는 것은 아닙니다. 공급업체에서 제공하는 SBOM이 있는 경우에도 중요한 시스템은 바이너리 SCA를 사용하여 검증해야 합니다. 바이너리 SCA를 사용하면 팀은 라이센스 계약을 위반하는 리버스 엔지니어링 기술 없이도 이러한 애플리케이션 및 제품 펌웨어에 대한 포괄적인 SBOM을 생성할 수 있게 해줍니다.
예를 들어, 아래 그래픽은 널리 사용되는 세 가지 무선 라우터의 최신 펌웨어 릴리스에 대한 SBOM을 보여줍니다. 각 펌웨어 릴리스 펌웨어에 사용된 오픈소스 컴포넌트와 관련된 1,000개 이상의 보안 취약점을 포함하고 있으며, 그 중 수십개는 공개적으로 사용가능한 익스플로잇이 포함되어 있습니다.
중요 시스템의 위험에 대한 가시성을 제공함으로써 IT 및 보안 팀은 공급업체 선택이나 위험 완화를 위한 보상 통제 등 현명한 결정을 내릴 수 있습니디다.
4. SBOM 데이터를 활용한 실행
위험에 대한 시기적절하고 실행 가능한 데이터가 없다면 각 애플리케이션의 오픈 소스 목록을 보유하는 것이 쓸모가 없습니다. 미국 국가 취약점 데이터베이스(NVD), 일본 취약점 노트(JVN). 중국 국가 취약점 데이터베이스(CNVD)와 같은 신뢰할 수 있는 출처에서 가져온 정확한 라이센스 및 취약점 데이터가 여기에 포함됩니다.
반드시 포함되어야 할 정보는 다음과 같습니다.
우선순위 설정 : 조직의 목표에 가장 중요한 시스템이 무엇인지 이해해야 합니다. 온라인 뱅킹 애플리케이션의 심각도 점수가 7인 취약점은 내부 애플리케이션의 심각도 점수가 10인 취약점보다 더 중요할 가능성이 높습니다. 또한 해당 취약점에 대한 악용 코드가 공개되었는지도 확인해야 합니다. 공개적으로 이용 가능한 익스플로잇은 공격을 훨씬 단순하게 만드어 "스크립트 키디"를 포함한 잠재적인 위협 행위자를 증가 시킵니다.
점수 매기기 : 대부분의 조직은 CVSS(Common Vulnerability Scoring System)를 사용하여 중요 자산에 대한 위험을 측정하고 우선순위를 지정합니다. 이는 기본, 시간, 환경 지표로 분류된 다양한 요소를 사용하여 위험 심각도를 정량적으로 측정합니다. 모든 SBOM에 걸쳐 점수를 표준화하는 SBOM 관리 솔루션을 찾으십시오.
기본 점수는 취약점의 특징을 나타냅니다. 이 점수는 공격 벡터, 취약점을 악용하는데 필요한 권한, 악용 성공 시 시스템의 기밀성, 무결성 및 가용성에 미치는 영향과 같은 요소를 평가합니다. 시간 점수는 위험을 완화하기 위한 악용 코드와 패치 또는 해결 방법의 성숙도와 가용성을 포함하여 시간이 지남에 따라 변화하는 취약점의 긴급성을 나타냅니다. 환경 점수는 조직에 미치는 영향 잠재력을 나타냅니다. 이는 취약점이 존재하는 특정 환경에 적용되며 각 조직마다 고유합니다.
악용 가능성 : 구성 요소에 취약점이 있다고 해서 반드시 악용 가능한 문제를 나타내는 것은 아닙니다. 공격자가 악용하려면 취약점에 도달할 수 있어야 합니다. 예를 들어, 취약한 코드가 존재하지 않으면 (당연히) 접근할 수 없습니다. 때때로 개발자는 컴포넌트를 수정하거나 부분적으로 사용합니다. "배포된 대로" 코드를 분석하는 바이너리 SCA 도구는 취약한 코드 조각의 존재 여부를 확인하여 오탐 및 불필요한 재작업을 최소화할 수 있습니다.
해결 지침 : 취약한 컴포넌트는 종종 수년 된 경우가 많습니다. 보고된 취약점을 수정하기 위해 단순히 업그레이드하면 훨씬 더 많은 취약점이 있는 컴포넌트 버전을 사용할 수 있습니다. 모든 버전의 보안 정보를 제공하는 솔루션을 찾으십시오.
바이너리 SCA가 더 좋은 이유
대부분의 조직은 소스 코드 기반 SCA를 통해 SBOM을 생성하며, 이는 부정확한 결과를 초래할 수 있습니다. SBOM을 생성하는 다양한 접근 방식을 간략하게 살펴보겠습니다.
패키지 매니저 파싱
대부분의 SCA 도구는 단순히 패키지 관리자 또는 빌드 파일을 파싱하여 오픈 소스 종속성 목록을 생성합니다. 이는 속도는 빠르지만 모호한 버전을 잘못 식별할 수 있고 개발자가 애플리케이션에 직접 컴파일한 구성 요소를 놓칠 수 있으며 C 및 C++와 같은 패키지 관리자를 지원하지 않는 프로그래밍 언어에는 사용할 수 없습니다.
해시 매칭
보다 정교한 SCA 솔루션은 소스 또는 바이너리에 대한 해시를 생성하고 이를 미리 생성한 오픈 소스 컴포넌트의 DB와 비교합니다. 이를 통해 패키지 관리자 파싱에서 누락된 일부 컴포넌트를 식별할 수 있지만, 해시 기반 매치가 어떤 경우에는 비효율적일 수 있습니다. 이는 컴파일 프로세스에 사용된 옵션에 따라 단일 소스에서 거의 무한한 수의 컴파일된 바이너리가 생성될 수 있기 때문입니다.
바이너리 분석
패키지 관리자 파싱과 해시 매치를 사용하는 것 외에도 Insignary Clarity는 오픈 소스 구성 요소의 "fingerprint"을 검색하여 문자열 리터럴, 함수 및 변수 이름과 같이 컴파일 프로세스에서 변경되지 않고 살아남는 코드 요소를 식별한다는 점에서 독특합니다. 이를 수많은 오픈 소스 저장소의 오픈 소스 구성 요소를 이용하여 생성한 fingerprint DB와 비교합니다.
이 fingerprint는 해시 매치가 비효율적인 경우 사용됩니다. 예를 들어, 임베디드 Linux 영역에는 재사용 가능한 바이너리 구성 요소에 대한 표준 저장소가 거의 없기 때문에 비교를 위한 해시 값을 얻기가 어렵습니다.
인사이너리 클래리티(Clarity)로 대비하세요
곧 내부 및 써드파티 SBOM을 관리하는 것이 모든 조직의 책임이 될 것입니다. 이를 위해서는 내부 프로젝트 및 IT 인프라에 대한 SBOM을 생성하고, 공급업체 및 파트너의 SBOM을 검증하고, 라이선스 및 보안 위험을 추적하는 능력이 필요할 것입니다.
Insignary Clarity는 보안, 개발 및 위험 관리 팀의 업무를 편하게 만드는 Binary SCA 솔루션입니다. 내부 및 외부 SBOM을 생성, 검증 및 관리하기 위한 솔루션을 제공합니다. Clarity는 소스 코드 및 바이너리에서 오픈 소스 구성 요소를 식별하고 해당 구성 요소를 라이선스 및 보안 위험에 매핑하며 명확한 해결 지침을 제공합니다.
더 자세한 내용은 인사이너리에 문의하세요.