SBOM(소프트웨어 구성 요소 목록)이란 특정 소프트웨어 제품을 구성하는 구성 요소 및 종속성 목록을 말합니다. 여기에는 소프트웨어를 빌드하는 데 필요한 모든 라이브러리, 모듈, 프레임워크 및 기타 외부 리소스와 이들 간의 관계가 포함됩니다. 본질적으로 SBOM은 소프트웨어 시스템의 디지털 공급망을 나타냅니다. 그리고 이제는 연방 정부에 소프트웨어를 판매하는 모든 공급업체가 이를 준수해야 합니다. 소프트웨어를 개발하거나 운영하는 다른 모든 사람들도 이를 통해 혜택을 누릴 수 있습니다.
SBOM은 10년 넘게 오픈소스 커뮤니티의 일부로 자리 잡아 왔지만, 2020 년과 2021년에 미국 기업과 정부 기관을 대상으로 한 소프트웨어 공급망 공격이 잇따르면서 사이버 보안 분야에서 더욱 주목받게 되었습니다.
특히 ‘ ’ SolarWinds 해킹 사건—이 사건에서 국토안보부 및 재무부를 비롯한 연방 기관들이 자신도 모르게 트로이 목마가 심어진 구성 요소를 배포함으로써 공격자들이 피해자의 컴퓨터 시스템에 접근할 수 있게 된 사례—를 계기로, 행정명령 이 2021년 5월 에 따라 연방 정부에 소프트웨어를 판매하는 모든 공급업체가 SBOM을 통해 구성 요소를 상세히 공개하도록 요구하게 되었습니다.
소프트웨어 공급망이 매우 복잡하기 때문에, 단 하나의 소프트웨어 구성 요소만으로도 보안에 막대한 영향을 미칠 수 있습니다. 그러나 사용자들은 비즈니스에 가장 중요한 애플리케이션 내에 중첩된 구성 요소들에 대해서는 거의 파악하지 못하고 있다. 제품의 “구성 요소” 목록을 확보하면 보안 위험에 대해 더 명확히 파악할 수 있을 뿐만 아니라, 취약점이 위기로 번지기 전에 이를 추적하고 해결할 수 있는 로드맵을 마련해 줍니다.
SBOM의 기원은 무엇인가요?
SBOM에 대한 새로운 강조는 바이든 대통령의 ‘국가 사이버 보안 강화( )’ 행정명령(EO) 14028호 에서 비롯된 것으로, 이 명령은 연방 정부 네트워크를 보다 효과적으로 보호하기 위해 미국 국립표준기술연구소(NIST) 및 기타 연방 기관에 소프트웨어 공급망의 보안 및 무결성과관련된 다양한 이니셔티브 를 통해 사이버 보안을 강화할 것을 지시하고 있습니다.
이 행정명령은 주로 2020 년과 ’21년에 미국 기업과 미국 정부를 대상으로 한 사이버 공격이 급증한 데 대한 대응 조치였다. 이 기간 동안 발생한 사이버 공격은 빈도가 더 잦아지고 규모도 더 커졌으며, 그중에서도 가장 심각한 피해를 입힌 두 건의 사건—솔라윈즈(SolarWinds) 해킹 사건과 콜로니얼 파이프라인(Colonial Pipeline) 랜섬웨어 공격—이 이번 행정명령(EO)의 발동을 촉발했습니다.
SolarWinds 공격 사건에서, IT 네트워크 및 인프라를 모니터링하고 관리하는 데 사용되는 텍사스 소재 기업의 오리온(Orion) 소프트웨어 내 트로이목마가 심어진 단 하나의 구성 요소로 인해, 해커들은 포춘 500 대 기업, 여러 연방 정부 기관, 심지어 결국 이 침해 사실을 발견한 미국 사이버보안 기업을 포함한 수천 개 기관의 시스템 에 접근할 수 있게 되었습니다. 최대 18.000명의 민간 및 공공 부문 피해자가 감염된 소프트웨어를 다운로드했으나, 실제로 피해를 입은 사람은 그보다 적었다.
콜로니얼 파이프라인 랜섬웨어 공격은 단일 기관을 표적으로 삼았지만, 미국의 인프라 전반에 광범위한 영향을 미쳤다. 동부 해안 지역 연료 공급량의 약 45 %를 담당하는 이 회사는 해킹 공격을 발견하자, 위협을 차단하기 위해 핵심 컴퓨터 시스템을 오프라인 상태로 전환할 수밖에 없었으며, 이로 인해 사실상 운영이 중단되었다. 그로 인한 연료 부족 사태로 인해 사재기 열풍이 일었고, 휘발유 가격이 급등했다.
[관련 기사: 바이든 대통령의 행정명령이 기술 업계 경영진에게 어떤 의미를 갖는가]
이 행정명령은 이러한 사건 및 기타 보안 사고에서 얻은 교훈을 반영하며, 점점 더 정교해지는 사이버 공격을 완화하기 위해 공공 및 민간 부문 간의 협력을 촉진하고자 한다. 구체적으로, 여기에는 몇 가지 목표가 제시되어 있습니다:
- 정보 공유 강화 —이 행정명령은 정부와 민간 부문 간의 위협 정보 공유에 대한 계약상 장벽을 제거하도록 지시하며, IT 서비스 제공업체들이 연방 정부에 잠재적인 영향을 미칠 수 있는 위협, 취약점 및 사고에 관한 정보를 공유할 것을 요구하고 있다.
- 정부 사이버보안 현대화 —이 행정명령은 연방 정부에 더 강력한 사이버보안 기준과 모범 사례를 도입할 것을 지시하고 있다. 여기에는 안전한 클라우드 서비스 도입, 제로 트러스트 보안 모델 적용, 그리고 다단계 인증(MFA) 및 암호화 절차 구현이 포함됩니다.
- 소프트웨어 공급망 보안 강화 —정부는 계약업체로부터 조달하는 소프트웨어에 대한 기본 소프트웨어 개발 보안 기준을 마련할 예정이다. 상무부와 미국 국립통신정보청(NTIA)은 소프트웨어 제품을 구성하는 개별 구성 요소를 나열하고 상세히 기술한 ‘소프트웨어 부품 명세서(BOM)’의 구성 요소를 공표해야 한다.
- 사이버 보안 안전 검토 위원회 설립 —정부는 정부 및 민간 부문 전문가들이 공동 의장을 맡는 ‘사이버 보안 안전 검토 위원회( )’ 를 신설할 예정이며, 이 위원회는 중대한 사이버 보안 사고 발생 시 소집되어 사고 원인을 분석하고 보안 개선을 위한 권고안을 마련할 것입니다.
[관련 기사: 공급망을 강화하기 위한 미국 정부의 대응 방안]
- 사고 대응 매뉴얼 작성 —정부 IT 책임자들은 모든 연방 기관이 사이버 공격에 효과적으로 대응하고 피해를 복구할 수 있도록, 보안 사고 대응을 위한 ‘ ’ 표준 매뉴얼 을 마련해야 합니다.
- 사건 탐지 능력 강화 —이 행정명령은 사이버 보안 사건 탐지 능력을 향상시키기 위해 정부 전반에 걸쳐 엔드포인트 탐지 및 대응(EDR) 시스템을 구축하고, 연방 정부 내 정보 공유를 개선할 것을 요구하고 있습니다.
- 조사 및 대응 능력 강화 —정부는 연방 정부 네트워크에서 발생하는 사이버 보안 사고에 대한 조사 및 대응 능력을 강화하기 위해 모든 연방 기관에 적용될 사이버 보안 사건 기록 요건을 마련할 예정이다.
이 행정명령은 여러 정부 기관이 달성해야 할 당면 목표를 제시했으나, 연방 정부 조달 공급망 전반에 연쇄적인 영향을 미치고 있다. 구체적으로, 이 행정명령은 다음 세 그룹에 영향을 미칩니다:
- 연방 행정 기관—등 최고 수준의 정부 기관들은 기술 환경과 보안 관행을 현대화할 책임을 맡고 있다.
- 연방 정부 계약업체—미국 정부와 거래하는 계약업체(상용 기성 소프트웨어(COTS) 공급업체 포함)는 계약 조건에 새로운 사이버 보안 기준이 반영될 것으로 예상할 수 있습니다. 또한 이들은 사이버 사고에 관한 정보를 더 많이 공유해야 합니다.
- 민간 기업—민간 기업은 새로운 사이버 보안 법안의 적용을 받게 되며, 기존 법률 및 정책에 대한 집행이 강화될 전망입니다. 특히 소프트웨어 공급망 보안 및 사이버 사고 보고에 더욱 중점을 둘 것입니다. 또한 소프트웨어 및 사물인터넷(IoT) 기기에 대한 소비자 보안 라벨링 도입 제안으로 투명성이 더욱 강조되고 있으며, 이에 따라 해당 공급업체들을 대상으로 새로운 보안 요구사항과 평가 기준이 마련되고 있다.
오늘날 SBOM이 중요한 이유는 무엇일까요?
SBOM은 조직이 자사의 소프트웨어 및 그 종속 구성 요소에 존재할 수 있는 취약점을 파악하고 해결하는 데 도움이 될 수 있기 때문에 중요합니다. 현대적인 애플리케이션은 물리적 제품을 제조하는 기업들이 사용하는 것만큼이나 복잡한 소프트웨어 구성 요소 공급망을 통해 개발됩니다. 일반적인 앱은 자체 개발 코드와 재사용 가능한 타사 구성 요소를 혼합하여 수십 개의 구성 요소로 구축됩니다. 개발자는 자신이 작성한 코드에 오류나 실수가 있는지 직접 검토할 수 있지만, 타사 코드에 대해서는 파악하기 어렵습니다. 공격자들은 이러한 점을 파악하고 악용하여, 탐지를 피할 가능성이 높다는 것을 알면서도 타사 구성 요소를 표적으로 삼습니다.
“취약점이 발견되거나 공개되었을 때, SBOM을 통해 해당 소프트웨어 버전이 조직 내에서 어디에 사용되고 있는지 파악할 수 있습니다.”
이제는 악명 높은 ‘솔라윈즈(SolarWinds)’ 사건 외에도, 지난 몇 년간 발생한 일련의 공급망 공격 사례들은 이러한 시나리오가 초래할 수 있는 파괴적인 영향을 여실히 드러내 주었다. 공격자들은 오픈소스 소프트웨어인 Apache Log4j 의 치명적인 취약점을 악용했는데, 이 소프트웨어는 수백만 개의 자바 기반 애플리케이션에서 발생하는 활동을 기록하는, 거의 모든 곳에서 사용되는 로깅 라이브러리입니다. 해커들은 또한 마이크로소프트 익스체인지 서버(Microsoft Exchange Server)의 ‘ ’ 제로데이 취약점 4건 을 악용해 미국 내 30.000 개 기관의 네트워크에 접근했습니다.
SBOM은 기업이 이러한 유형의 공급망 공격으로부터 더 효과적으로 방어하고, 위험 관리의 우선순위를 정하는 데 도움이 될 수 있습니다. 예를 들어, SBOM을 활용하여 먼저 알려진 취약점이 있는 라이브러리의 사용을 배제하고, 그 다음 각 오픈소스 라이브러리의 최신 버전을 사용하고 있는지 확인할 수 있습니다. 취약점이 발견되거나 공개되었을 때, SBOM을 활용하면 해당 소프트웨어 버전이 조직 내에서 어디에 사용되고 있는지 파악하는 데 도움이 될 수 있습니다. 보다 일반적으로 말해, SBOM을 통해 조직은 사용하는 소프트웨어에 대해 더 충분한 정보를 바탕으로 의사결정을 내릴 수 있으며, 소프트웨어 공급업체가 더 안전한 제품을 개발하도록 장려합니다.
SBOM은 어떤 구성 요소들로 이루어져 있나요?
2021년 7월에서 NTIA는 “소프트웨어 자재 명세서(SBOM)의 최소 구성 요소”를 발표하며, SBOM에 대한 연방 정부의 요건 을 제시했습니다. 이는 SBOM의 기본 구성 요소를 데이터 필드, 자동화 지원, 관행 및 프로세스라는 세 가지 범주로 분류합니다. 각 항목을 좀 더 자세히 살펴보겠습니다.
데이터 필드
데이터 필드는 각 구성 요소를 효과적으로 식별하여, 소프트웨어 공급망 전반에 걸쳐 모니터링하고 취약점 및 라이선스 데이터베이스와 대조할 수 있도록 해야 합니다. NTIA는 다음 7가지 데이터 필드를 명시하고 있습니다:
- 공급업체 이름: 해당 구성 요소를 생성하고 식별하는 조직의 이름입니다.
- 구성 요소 이름: 원본 공급업체가 소프트웨어 단위에 부여한 이름.
- 컴포넌트 버전: 소프트웨어 제품에 사용된 컴포넌트의 빌드 및 버전 정보.
- 기타 고유 식별자: 조회 키 및 NIST의 CPE 사전()에 수록된 식별자 등, 구성 요소를 식별하는 데 사용할 수 있는 기타 정보.
- 의존성 관계: 해당 컴포넌트와 다른 소프트웨어 간의 의존성에 대한 설명. 예를 들어, 구성 요소 A가 소프트웨어 B에 포함되어 있습니다.
- SBOM 데이터 작성자: 해당 컴포넌트의 SBOM 데이터를 생성한 조직의 이름입니다.
- 타임스탬프: SBOM 데이터가 생성된 날짜 및 시간입니다.
자동화 지원
보안 전문가들이 모든 SBOM에서 침해된 구성 요소를 수동으로 검색하는 것은 현실적으로 불가능하기 때문에, NTIA는 모든 SBOM이 다음 세 가지 기계 판독 가능 형식 중 하나를 통해 자동화를 지원하도록 요구합니다:
- 사이클론 DX
- 소프트웨어 패키지 데이터 교환(SPDX)
- 소프트웨어 식별(SWID) 태그
[Read also: Here’s your security automation playbook for 2023]
실무 및 프로세스
실무 및 프로세스는 소프트웨어 제품의 전체 수명 주기 동안 SBOM 문서의 정확성을 보장합니다. NTIA는 다음과 같은 몇 가지 필수 요소를 제시했습니다:
- 빈도: 소프트웨어 구성 요소가 새로운 빌드나 릴리스로 업데이트될 때마다, 해당 소프트웨어의 새 버전을 반영하기 위해 새로운 SBOM을 생성해야 합니다. 여기에는 업데이트된 구성 요소나 종속성을 통합하기 위한 소프트웨어 빌드가 포함됩니다. 마찬가지로, 공급업체가 기존 SBOM 데이터의 오류를 수정하거나 정보를 업데이트하고자 하는 경우, 수정된 새로운 SBOM을 발행해야 합니다.
- 자세히 보기: SBOM에는 모든 최상위 구성 요소가 포함되어야 하며, 해당 구성 요소의 종속성을 나열해야 합니다.
- 알려진 미지 사항: 때로는 개발자들이 특정 컴포넌트에 대한 모든 의존성 관계를 알지 못한다는 사실을 인식하기도 합니다. 이러한 경우, SBOM에는 해당 데이터가 불완전하다는 점을 명확히 밝히고, 어떤 관계가 존재할 수 있는지 설명해야 합니다.
[함께 읽어보세요: ‘알고 있는 미지의 요소’에 대해 평가해 보셨나요? 좋긴 하지만 거기서 멈추지 마세요—리더들은 “알 수 없는 미지의 것들”까지 상상해 보는 것이 유리합니다]
- 배포 및 제공: SBOM은 이를 필요로 하는 사용자가 적절한 접근 권한과 역할을 부여받은 상태에서 적시에 이용할 수 있어야 합니다.
- 접근 제어: SBOM 데이터를 비공개로 유지하고자 하는 조직은 사용자가 SBOM 데이터를 자사의 보안 도구에 통합할 수 있도록 허용 범위 및 편의 조치 등을 포함한 조건을 명시해야 합니다.
- 오류에 대한 유연성: SBOM 데이터 관리는 지속적으로 발전하고 있는 관행이므로, 사용자는 우발적인 오류에 대해 관대하게 대처해야 합니다. 공급업체는 과거 SBOM에서 문제가 발견될 경우 최신 데이터를 제공해야 하며, 사용자는 지속적인 개선을 장려하기 위해 이러한 업데이트와 수정 사항을 불이익 없이 수용해야 합니다.
SBOM 관련 요구 사항은 앞으로도 계속 확대되고 발전해 나갈 것으로 보입니다. 업데이트된 지침에는 더 많은 데이터 필드와 보안 점수, 취약점 목록 및 기타 정보가 추가될 수 있습니다. 조직은 SBOM의 최소 요건만을 충족하면 되지만, 소프트웨어 제품에 대한 추가적인 관련 정보를 포함한다면 투명성과 보안에 대한 확고한 의지를 보여줄 수 있습니다.
SBOM 개발 수명 주기란 무엇인가요?
이상적으로는 소프트웨어가 배포될 때마다 SBOM이 자동으로 생성되어야 하며, 가능한 한 완전한 구성 목록을 포함해야 합니다. SBOM 라이프사이클은 애플리케이션을 식별하고, SBOM을 생성하며, 이를 최종 사용자에게 제공하는 프로세스를 마련함으로써 이러한 과정을 원활하게 지원합니다.
“소프트웨어가 배포될 때마다 SBOM이 자동으로 생성되어야 하며, 가능한 한 완전한 구성 목록을 포함해야 합니다.”
이는 다음의 다섯 단계로 구성됩니다:
- 자산 탐색 —첫 번째 단계는 SBOM을 제공해야 하는 애플리케이션을 찾는 것입니다. 모든 앱에 대한 완벽한 가시성을 확보하려면 의 자산 탐색 도구 를 사용하는 것이 좋습니다.
- 애플리케이션 데이터 분석 —SBOM에 필요한 애플리케이션 데이터가 수집됩니다.
- SBOM 생성 —관련 애플리케이션 데이터가 모두 포함된 SBOM 파일이 생성됩니다. SBOM이 항상 소프트웨어의 최신 상태와 일치하도록 하기 위해서는 앱이 새로 출시될 때마다 이 작업을 수행해야 합니다.
- SBOM 저장 —SBOM은 암호화를 통해 중앙 집중적이고 안전하게 저장되어야 합니다.
- SBOM 검색 기능 —마지막 단계는 최종 사용자가 잠재적인 취약점을 조회할 수 있도록 SBOM에 대한 검색 기능을 확보하는 것입니다.
어떤 SBOM 표준이 있나요?
SBOM 표준은 소프트웨어의 구성을 상세히 기술하는 스키마로, 취약점 스캐너나 소프트웨어 라이선스 추적 도구와 같은 다른 도구에서 활용할 수 있는 기계 가독형 파일 형식으로 제공됩니다. 현재 SBOM을 생성하고 최종 사용자와 공유하는 데에는 크게 세 가지 표준이 있습니다:
- SPDX—리눅스 재단(Linux Foundation)에서 개발한 SPDX(Software Package Data Exchange) 표준은 앱의 구성 요소, 라이선스, 저작권 및 보안 정보와 같은 SBOM 데이터를 다양한 파일 형식으로 전달하기 위해 널리 채택된 형식입니다.
- CycloneDX—CycloneDX는 OWASP 커뮤니티에서 개발한 또 다른 개방형 표준입니다. 이 솔루션은 SPDX 표준을 기반으로 하지만, 구현과 사용이 더 용이하도록 간소화되었습니다.
- SWID—SWID(Software Identification Tags의 약자)는 소프트웨어의 구성 요소를 설명하고 맥락을 제공하기 위해 다양한 애플리케이션에서 자동으로 생성될 수 있는 메타데이터의 한 종류입니다.
NTIA는 이 세 가지 SBOM 표준을 적합한 표준으로 선정했는데, 이는 해당 표준들이 사람이 읽을 수 있을 뿐만 아니라 기계가 읽을 수 있어 자동화를 지원함으로써, 최종 사용자가 조직 전반에 걸쳐 SBOM을 보다 쉽게 사용하고 확장할 수 있도록 돕기 때문입니다.
[관련 기사: 리스크 관리의 미래는 자동화에 달려 있다]
SBOM을 작성하고 사용하는 데에는 어떤 어려움이 있나요?
다른 새로운 시스템과 마찬가지로, SBOM을 작성하고 사용하는 데에는 몇 가지 어려움이 따릅니다.
가장 큰 걸림돌은 표준화가 이루어지지 않았다는 점이다. 전체 공급망이 동일한 표준, 프로세스 및 도구를 준수할 때 SBOM이 가장 큰 효과를 발휘할 가능성이 높습니다. 그러나 아직 초기 단계인 만큼 이러한 사항들에 대해서는 합의가 거의 이루어지지 않았으며, 소프트웨어 공급업체와 최종 사용자 간에 일관성이 없는 것은 불가피하다. 이로 인해 SBOM을 분석하고 주문에 맞게 조정하는 데 추가 시간이 소요될 수 있습니다.
“SBOM은 전체 공급망이 동일한 표준, 프로세스 및 도구를 준수할 때 가장 큰 효과를 발휘할 가능성이 높습니다. 그러나 아직 초기 단계인 만큼, 이 문제들에 대해서는 합의점이 거의 없다.”
또 다른 과제는 SBOM을 지속적으로 조정해야 한다는 점입니다. 앱이 새로 출시될 때마다, 해당 앱의 현재 상태를 반영한 새로운 SBOM이 반드시 포함되어야 합니다. 따라서 SBOM 생성을 소프트웨어 개발 수명 주기에 통합할 수 있는 SBOM 관리 도구를 도입하는 것이 매우 중요합니다.
스프레드시트나 이메일과 같은 전통적인 방식을 사용하여 SBOM을 생성하는 경우, 공급망 파트너가 늘어남에 따라 SBOM을 확장하는 것도 문제가 될 수 있습니다. 게다가 이러한 수동 방식은 시간이 많이 소요되고 오류가 발생하기 쉬우며, 구성 요소 간의 계층적 관계를 파악하기 어렵게 만들 수 있습니다.
효과적인 SBOM을 작성하기 위한 모범 사례에는 어떤 것들이 있나요?
다음 모범 사례들은 효과적인 SBOM을 작성하는 데 도움이 될 수 있습니다:
- 일관된 형식을 사용하십시오—SBOM 데이터를 구성할 때는 표준 형식을 따르는 것이 중요합니다. SPDX, CycloneDX, SWID가 가장 널리 사용되지만, 결국 어떤 형식을 선택하느냐보다는 일관성 있게 사용하는 것이 더 중요합니다.
- SBOM 생성 자동화 —소프트웨어 배포 파이프라인의 일환으로 SBOM을 자동으로 생성하면 여러 가지 이점이 있습니다. 무엇보다 개발자들이 각 SBOM을 수동으로 작성할 필요가 없게 되므로 시간을 절약할 수 있을 것입니다. 또한 이를 통해 SBOM이 소프트웨어 배포 주기의 일상적인 일부가 될 가능성이 높아집니다. 마지막으로, 이를 통해 연방 정부에 IT 서비스를 제공하기 위해 바이든 행정명령에서 정한 요건을 충족할 수 있습니다.
- 각 릴리스마다 SBOM을 업데이트하십시오 —SBOM은 애플리케이션이 업데이트될 때마다 포함하여 각 소프트웨어 릴리스별로 구체적으로 작성되어야 합니다. 여기서 핵심은 자동화입니다. 개발자들이 앱을 업데이트할 때마다 SBOM을 수동으로 업데이트해야 한다면, 실제로 업데이트가 이루어질 가능성은 훨씬 낮아집니다.
- 완전한 메타데이터를 포함하십시오—보편적으로 통용되는 SBOM 표준은 없지만, 각 SBOM에 가능한 한 많은 메타데이터를 포함하는 것을 관행으로 삼아야 합니다. 이를 통해 최종 사용자가 수동으로 조회해야 하는 정보의 양을 줄일 수 있을 뿐만 아니라, 보안과 투명성에 대한 귀사의 의지를 보여줄 수 있습니다. 또한 업데이트하기도 더 쉬워집니다.
