지난 몇 년간 발생한 주요 소프트웨어 공급망 공격에서 우리가 배운 것이 있다면 SolarWinds and Log4Shell 공격, 이러한 종류의 공격은 상당히 파괴적일 수 있다는 것입니다. 그러나 오늘날 상호 연결된 디지털 세상에서 기업이 이를 피하는 것은 점점 더 어려워지고 있습니다.
소프트웨어 공급망 공격으로부터 면역되는 사람은 아무도 없습니다. 상황을 더욱 악화시키는 것은 단일 회사의 침해로 인해 소프트웨어 공급망에 있는 수천 개의 회사가 잠재적으로 공격에 노출될 수 있다는 것입니다. 이는 내부 시스템을 보호하는 것만으로는 충분하지 않다는 의미입니다. 조직이 공급망 위험을 사전에 줄이고 공격을 완화할 수 있는 방법 중 하나는 소프트웨어 자재 명세서(SBOM)라는 개념을 채택하는 것입니다.
귀하의 조직은 일상 업무의 다양한 측면을 실행하기 위해 다양한 외부 시스템에 의존할 가능성이 높습니다. 그러나 공급자가 이를 공개하지 않는 한 이러한 외부 시스템이 제기하는 위험에 대한 가시성은 아마도 없을 것입니다. SBOM은 사용하는 소프트웨어 구성 요소를 구성하는 요소에 대한 통찰력을 제공하는 포괄적인 구성 요소 목록 역할을 합니다. 이 문서는 공급망 공격 위험 관리를 위한 핵심 구성 요소.
공급망 위험 관리에서 SBOM의 기능은 무엇입니까?
귀하가 사용하는 타사 소프트웨어의 잠재력을 완전히 이해하고 위험을 줄이려면 해당 소프트웨어의 구성을 알아야 합니다. SBOM(Software Bill of Materials)은 완전한 투명성을 제공하므로 내부 시스템의 보안을 보다 효율적으로 제어할 수 있습니다.
소프트웨어 BOM은 소프트웨어 또는 애플리케이션의 구성 요소, 서비스 및 타사 종속성의 목록입니다. BOM의 개념은 새로운 개념은 아니지만 최근에야 소프트웨어 세계에 적용되기 시작했습니다. 이 개념의 뿌리는 제조업체가 일반적으로 다양한 공급업체의 부품을 사용하여 제품을 만드는 제조 산업에서 찾을 수 있습니다. 제품의 이력을 추적하고 향후 유지 관리를 용이하게 하기 위해 모든 구성 요소와 각 구성 요소의 출처를 자세히 설명하는 BOM이 생성됩니다.
SBOM은 많은 미국 정부 기관에 영향을 미친 2020 Solarwinds 공격 이후 최근에 대중화되었습니다. 이에 대한 응답으로, 바이든 대통령, 행정명령 발령 연방 기관에 요청하도록 의무화한 것 SBOM 소프트웨어 개발자와 파트너 관계를 맺고 있는 공급업체로부터 공급망 공격을 예방할 수는 없지만 정확한 SBOM은 소프트웨어 제품 내의 모든 종속성을 드러냅니다. 이는 투명성을 보장하고 공급망의 취약성을 노출시켜 공급망 위험을 줄이는 귀중한 사이버 보안 도구가 됩니다.
오픈 소스 코드를 사용하는 개발자에게 SBOM이 중요한 이유
타사 또는 오픈 소스 코드를 재사용하는 것은 현대 소프트웨어 개발 프로세스의 필수적인 부분입니다. 개발자는 여전히 자신의 코드를 작성해야 하지만 일상적으로 타사 오픈 소스 구성 요소를 소프트웨어에 통합합니다. 프로젝트를 계속해서 빠른 속도로 진행하려면 이렇게 하는 것이 매우 필요해졌습니다.
과거에는 오픈 소스 소프트웨어를 사용하는 조직과 개발자가 해당 구성 요소에 대해 알고 싶어 하는 유일한 이유는 라이선스 문제를 피하기 위해서였습니다. 많은 오픈 소스 소프트웨어에는 사용 및 배포가 제한된 구성 요소가 포함되어 있으므로 이를 사용하려는 사람은 누구나 이러한 제한 사항을 인식해야 했습니다. 그러나 이제 개발자들은 오픈 소스 소프트웨어 사용에 따른 위험이 라이선싱 이상의 위험이라는 점을 인식하기 시작했습니다. 보안 문제도 발생할 수 있습니다. BOM은 오픈 소스 소프트웨어의 라이센스 및 보안 요구 사항을 모두 이해하는 데 필수적입니다.
개발자의 경우 소프트웨어 BOM은 사용 중인 오픈 소스 소프트웨어의 코드베이스에 대한 더 나은 가시성을 제공합니다. 이는 많은 경우에 시간과 노력을 절약하는 데 도움이 될 수 있습니다. 예를 들어 새로운 취약점이 발견된 경우입니다. BOM이 없으면 개발자는 문제의 원인을 파악하기 위해 소프트웨어의 모든 부분을 검토해야 합니다. 복잡한 프로젝트의 경우 이는 힘들고 시간이 많이 걸리는 작업입니다. SBOM을 사용하면 취약점이 포함된 소프트웨어를 쉽게 식별할 수 있으며 필요한 버그 수정이 즉시 수행됩니다. 그 밖의 이유 SBOM 소프트웨어 개발에서 매우 중요합니다.
-
코드 팽창 감소—사용하는 모든 오픈 소스 코드에는 유사한 기능을 수행하는 약간 다른 대안이 수십 개 있을 수 있습니다. SBOM을 사용하면 시스템에 대한 표준 구성 요소 목록을 생성하여 중복을 줄일 수 있습니다. 또한 사용하는 각 구성 요소에는 고유한 결함이나 취약점이 있으므로 코드를 필요한 것만으로 간소화하면 취약점을 더 쉽게 추적하고 수정할 수 있습니다.
-
라이센스 의무를 준수합니다.우리는 라이센스가 소프트웨어의 모든 구성 요소를 알고자 하는 주요 동기 중 하나라는 점을 언급했습니다. SBOM을 획득하면 사용하기로 선택한 구성 요소에 대한 모든 라이센스 의무를 준수하게 됩니다.
-
위험을 사전에 평가하고 해결합니다.새로 식별된 위험을 식별하고 해결하는 것은 어렵고 시간이 많이 걸릴 수 있습니다. 그러나 명확하게 설명된 구성 요소 목록을 사용하면 사전에 취약점을 찾고 수정하기 시작할 수 있습니다. 이를 통해 문제를 식별하는 기간이 단축되고 프로세스가 더욱 효율적으로 만들어집니다.
-
테스트와 코드 검토가 더 쉬워집니다.소프트웨어를 출시하기 전에 광범위한 테스트와 검토를 거쳐야 합니다. 개발자가 해당 소프트웨어의 모든 구성 요소와 하위 구성 요소를 명확하게 이해하고 있으면 이 프로세스가 더 쉬워집니다. SBOM을 사용하면 검토 시간을 대폭 단축할 수 있으므로 문서가 없을 때보다 더 빠르게 코드를 프로덕션에 투입할 수 있습니다.
SBOM을 사용하면 코드가 작성되는 동안 초기 단계에서 유해한 구성 요소를 감지하고 방지하기 위한 보안 테스트를 시작할 수 있습니다. 또한 이 문서는 타사 코드와 해당 구성 요소에 대한 심층적인 컨텍스트를 제공하여 코드 베이스를 검토하고 변경하는 데 필요한 작업과 시간을 줄여줍니다.
-
단종(EOL) 소프트웨어 식별—이는 오픈 소스 소프트웨어에서 상당히 흔한 현상입니다. 때로는 공급망의 상위에 있는 공급업체가 더 이상 제품을 지원하지 않기 때문에 이러한 구성 요소의 수명이 다하게 됩니다. 여전히 작동하지만 지원되지 않는 오픈 소스 소프트웨어는 취약점을 악용할 수 있는 주요 노드입니다. SBOM을 사용하면 EOL 소프트웨어를 모니터링하고 가능하면 이를 교체하기 위한 사전 조치를 취할 수 있습니다.
SBOM 사용 사례 및 이점
개발하는 모든 소프트웨어에 대해 소프트웨어 자재 명세서(SBOM)를 받는 것이 필수는 아닙니다. 그러나 이를 준비하는 것은 모든 디지털 제품 개발자가 살펴보아야 할 모범 사례로 빠르게 자리잡고 있습니다. 다음은 이 문서가 매우 유용한 몇 가지 SBOM 사용 사례입니다.
SBOM 사용 사례
연방 요구 사항 준수
2020년과 2021년의 주요 소프트웨어 공급망 공격 이후 바이든 대통령은 다음과 같은 성명을 발표했습니다. 행정 명령 정부에 소프트웨어 솔루션을 공급하는 기관 및 공급업체에 대한 주요 권장 사항을 간략하게 설명합니다. 행정 명령에 포함된 요구 사항 중 하나는 연방 정부에서 사용할 모든 소프트웨어에 대해 SBOM을 포함하라는 제안이었습니다. SBOM이 모든 사람에게 의무적인 것은 아니지만 미국 연방 정부에 소프트웨어를 제공하는 모든 조직은 사용하는 모든 구성 요소와 버전 변경 사항을 자세히 설명하는 SBOM을 제공해야 합니다.
소프트웨어 소비자의 위험 감소
SBOM은 소프트웨어 도구의 타사 구성 요소에 대한 완전한 가시성을 제공합니다. 소프트웨어의 모든 구성 요소와 하위 구성 요소를 추적하는 것은 조직이 사용하려고 하거나 이미 사용하고 있는 모든 소프트웨어 솔루션의 보안 및 규정 준수 표준을 확인할 수 있는 방법 중 하나입니다.
BOM 없이 소프트웨어를 사용하는 소비자는 공급업체로부터 받는 코드에 오픈 소스 구성 요소가 있다는 사실을 알고 있을 것입니다. 그러나 이러한 구성 요소가 알려지지 않았기 때문에 소비자는 소프트웨어의 잠재적인 악성 코드, 지원되지 않는 구성 요소 및 기타 취약점을 인식하지 못할 수 있습니다.
위기 상황에 대한 신속한 대응
SBOM을 사용하면 소프트웨어 코드베이스에 대한 가시성이 제공됩니다. 궁극적으로 이를 통해 개발자는 위기가 발생할 경우 이에 더 쉽게 대응할 수 있습니다. 예를 들어, SBOM이 없으면 새로운 취약점을 처리하려는 소프트웨어 엔지니어링 팀은 문제를 파악하기 위해 사용하는 모든 소프트웨어를 수동으로 검토해야 합니다. 그러나 BOM을 사용할 수 있는 경우 취약성을 포함할 수 있는 소프트웨어의 범위를 좁히고 매우 짧은 시간 내에 필요한 수정 사항을 수행하는 것이 더 쉽습니다. 이를 통해 위기 해결 시간을 절약하고 발생할 수 있는 피해를 최소화할 수 있습니다.
정보 비대칭 문제
현재 소프트웨어 시장에는 정보 비대칭 문제가 있습니다. 앱 보안에 대한 전체 정보를 비밀로 유지함으로써 소프트웨어 공급업체나 제작자는 소프트웨어 품질에 대해 책임을 지지 않습니다. SBOM은 소프트웨어 고객에게 제품 보안에 대한 정보를 제공합니다. 이로 인해 생산자는 소프트웨어 개발에서 최고의 보안 표준을 준수해야 합니다.
인수합병 지원
소프트웨어 BOM은 회사 인수에 필요할 수 있는 문서 중 하나입니다. 사업 인수 과정의 일부에는 구매의 잠재적 위험을 평가하기 위한 실사가 포함됩니다. SBOM은 회사가 운영하는 보안 프레임워크와 인수로 인한 잠재적 위험에 대한 심층적인 통찰력을 제공합니다.
SBOM의 이점
현대 조직의 가장 중요한 보안 관행 중 하나는 소프트웨어 공급망 위험에 접근하는 것입니다. 여기에는 조직의 소프트웨어 스택에 공급망 위험을 초래할 수 있는 타사 구성 요소가 포함되어 있는지 여부를 아는 것이 포함됩니다. 이러한 소프트웨어 취약점은 다른 소프트웨어 애플리케이션에 의존하는 구성 요소에서 흔히 발견됩니다. 이것이 바로 소프트웨어 BOM이 제품 보안 프레임워크의 중요한 구성요소인 이유입니다. 다음은 가장 중요한 몇 가지 사항입니다. SBOM의 장점.
- 취약점을 선제적으로 처리-SBOM의 궁극적인 이점은 조직이 사용하는 소프트웨어의 보안 프레임워크를 조사하고, 취약점을 식별하고, 이를 사전에 제거하는 방법을 찾는 것입니다. 이를 통해 조직은 공급망 위험을 줄일 수 있습니다.
- 보안 위기 관리 프로세스 개선—SBOM을 생성한다고 해서 시스템 취약성이 제거되거나 소프트웨어 공급망 공격이 완전히 방지되는 것은 아닙니다. 그러나 공급망 위험을 줄이고 위기 발생 시 관리 프로세스를 개선할 수 있습니다. 소프트웨어 애플리케이션에서 잠재적인 취약성 지점으로 작용할 수 있는 모든 종속성 목록이 있으면 위험 관리 프로세스가 단순화됩니다.
- 비용을 줄이다-SBOM을 활용하여 보안 위험을 처리하면 장기적으로 비용이 절감됩니다. 취약점을 찾기 위해 코드를 수동으로 구문 분석하는 프로세스에는 비용이 많이 들 수 있습니다. 소프트웨어 BOM은 소프트웨어 기반 라이브러리에 대한 가시성을 제공합니다. 이는 시간을 절약하고 보안 평가 비용을 줄이는 데 도움이 됩니다.
결론
평판을 중시하는 모든 소프트웨어 조직에서 데이터가 지속적으로 업데이트되는 포괄적인 SBOM을 만드는 것은 소프트웨어 공급망 공격의 영향을 방지하는 주요 방법 중 하나입니다. 소프트웨어 제품을 구축하는 데 있어 타사 소프트웨어를 사용하는 것은 사실상 불가피하므로, 사용하는 모든 구성 요소에 대한 포괄적인 구성 요소 목록을 가지고 있으면 문제의 범위를 훨씬 더 쉽게 좁히고 보다 효과적으로 해결할 수 있습니다. 또한 소프트웨어 라이센스 문제를 준수하는 것이 더 쉽고, 경우에 따라 정부 규정도 준수할 수 있습니다.