״소프트웨어 공급업체는 책임을 져야 합니다. 그들이 소비자, 기업 또는 중요 인프라 제공자(백악관)에게 빚진 관리 의무를 다하지 못할 때.
오늘날 모든 소프트웨어 제공업체는 계약 합의, 소프트웨어 릴리스 및 업데이트, 알림, 취약점 완화를 통해 소프트웨어의 무결성과 보안을 보장하는 데 더 큰 책임을 져야 합니다. 최근, 부문 간 작업 그룹인 ESF(Enduring Security Framework)는 고객이 소프트웨어 공급망 내에서 보안 조치를 구현하는 데 도움이 되는 권장 모범 사례 및 표준이 포함된 지침을 발표했습니다. 이 기사에서는 분류 및 우선순위 지정을 위한 효과적인 메커니즘으로 SBOM 기반 위험 점수 매기기를 활용하는 실제 권장 사항에 대해 자세히 살펴보겠습니다.
소프트웨어 설계 결함 악용, 취약한 제3자 구성 요소를 소프트웨어 제품에 통합, 소프트웨어 제품이 최종 배송되기 전에 공급업체 네트워크에 악성 코드로 침투, 배포된 소프트웨어에 악성 소프트웨어 주입 등 소프트웨어 공급망을 손상시키는 일반적인 방법이 지속되고 있습니다. 고객 환경에서.
소프트웨어 BOM(SBOM)는 소프트웨어 보안 및 소프트웨어 공급망 위험 관리에서 중요한 요소로 부상했습니다. SBOM은 소프트웨어 구성 요소를 구성하는 구성 요소 목록을 제공하는 중첩된 인벤토리 역할을 합니다.
대규모로 SBOM을 운영하려면 시스템 배포, 제품 개발, 소프트웨어 공급업체와 소비자 간의 데이터 교환에 있어 도구 자동화와 표준화가 필요합니다.
기계가 읽을 수 있는 몇 가지 중요한 사항이 있습니다. SBOM 표준 형식 업계에서 지원합니다. CycloneDX 및 SPDX는 SBOM이 생성, 분석 및 공유되는 방식을 정의합니다. VEX는 제품이 알려진 취약점의 영향을 받는지 여부를 나타내는 보안 권고의 보완적인 형태입니다. 따라서 이 취약점이 SBOM에 존재하더라도 제품이 특정 취약점의 영향을 받지 않음을 보여주는 이점을 제공합니다.
기업 내에 배포된 소프트웨어 제품 전반에 걸쳐 SBOM 콘텐츠를 연관시키면 애플리케이션 보안, 사고 대응 및 포렌식 팀, 위험 관리 및 조달에 대한 강력한 통찰력을 제공할 수 있습니다. 조직은 내부 제품에 대한 대량의 SBOM 데이터를 생성 및 관리하고 효과적인 방식으로 관리해야 하는 외부 데이터를 소비할 것으로 예상됩니다. 그러므로 지원이 필요하다. 방법 SBOM 자동화주도형 리스크 관리 대규모로.
SBOM 및 위험 평가 사용
위험 채점은 SBOM 콘텐츠에서 파생된 요약 개요를 생성하는 수단 역할을 할 수 있으므로 외부 데이터 소스와의 신속한 비교가 가능하고 수신된 SBOM 및 우선 순위에 따라 신속한 의사 결정이 가능해집니다.
- SBOM은 투명성을 강화하여 고객 조직의 소프트웨어 자산 관리, 패치 관리, 기술 부채 격차 식별 및 취약성 관리를 개선합니다. 또한 무결성과 신뢰를 검증하기 위해 구성 요소의 출처를 추출할 수 있는 가능성도 있습니다.
- 기업에 구현된 소프트웨어 제품 전반에 걸쳐 SBOM 콘텐츠 정렬을 분석하면 사고 대응 팀, 위험 관리 및 조달 프로세스 검증에 대한 귀중한 통찰력을 얻을 수 있습니다.
SBOM을 대규모 위험 정보로 전환 – 위험 점수 산정의 근거
모든 AppSec 전문가와 CISO의 주요 과제는 제품과 서비스 전반에 걸쳐 경고 피로도를 관리하는 것입니다. 타사 소프트웨어 구성 요소에서 발생하는 외부 위험 평가를 포함합니다.
구현의 주요 장애물은 다운스트림 패치 및 제품 업데이트의 가용성에 영향을 미칠 수 있는 오래된 계약 또는 라이센스 기반 지원과 오픈 소스 또는 비공개 소스 여부에 관계없이 소프트웨어 제품 내 종속성의 복잡성이 기하급수적으로 증가한다는 것입니다.
A 위험 점수 규모에 따른 우선순위 지정을 효과적으로 지원할 수 있는 소프트웨어 및 해당 구성 요소의 현재 및 미래 위험 측면을 예측하는 데 사용되는 측정 기준입니다.
위험 점수 = 확률 x 영향
위험 채점을 통해 조직은 정의된 위험 요소를 기반으로 소프트웨어 공급망 위험을 이해하고 기업 내 특정 소프트웨어 제품의 잠재적 미래 위험을 예측할 수 있습니다.
효과적인 위험 점수는 1부터 10까지의 범위(예: CVSS 및 Scorecard)일 수 있으므로 참조하기 쉽도록 모든 위험 구성 요소를 1부터 10까지의 범위로 정렬할 수 있습니다.
집계된 위험 점수: 많은 복잡한 시스템과 시스템 시스템에는 집합적 솔루션의 일부로 여러 SBOM이 있을 수 있으므로 위험 점수 모음이 될 수 있습니다.
위험 점수 구성 요소:
1. 취약점: CVE 열거를 사용하여 알려진 취약점 매핑 및 NVD, OSV 및 Github Advisories와 같은 사용 가능한 피드에서 CVSS 점수를 얻습니다.
2. 공급업체의 상황: 사용 상황에서 취약점 점수 결정을 변경할 수 있는 공급업체의 VEX 및 자문 컨텍스트입니다. SBOM을 취약점에 연결하면 위험 플래그가 활성화되고, VEX 문서를 통해 소비자는 취약점의 우선순위를 지정할 수 있습니다.
3. EPS 3.0: 향후 0일 동안 악용 가능성(1.0~30 사이)을 예측하는 FIRST의 악용 가능성 지표입니다. 이는 효과적인 추가 가능성 레이어 가장 먼저 처리해야 할 가장 중요한 CVE의 우선순위를 지정하는 데 도움이 될 수 있는 CVSS 점수입니다.
4. 케브: CISA는 또한 현재 알려진 위협 인텔리전스 피드를 공개적으로 만들었습니다. CISA KEV(알려진 악용 취약점) 카탈로그. 이 카탈로그에는 CISA에서 이미 악용되었거나 악용된 것으로 확인된 식별된 모든 CVE의 약 5%가 포함되어 있습니다. 따라서 이는 해결해야 할 영향이 큰 취약점의 우선순위를 정하기 위한 좋은 출발점이 됩니다. 또한 이는 새 버전 릴리스의 최종 승인 전에 유효성을 검사할 체크리스트의 일부입니다.
5. 위협 인텔리전스 – 추가 추가 위협 및 취약성의 소스는 알려진 악성 패키지를 제공합니다. (예: Snyk, Sonatype, Graynoise 등의 비공개 피드)
6. OSS 평판: 오픈 SSF 스코어카드는 오픈 소스 프로젝트의 소스 코드, 빌드, 종속성, 테스트 및 프로젝트 유지 관리 평판(1-10 등급)을 포함하여 소프트웨어 공급망의 다양한 부분에 영향을 미치는 성능 측정 지표를 독립적으로 평가합니다.
7. 시간 경과에 따른 성과: 제품/패키지 버전의 MTTR(평균 복구 시간) 중요한 취약점은 보안 위험 성능에 대한 관련 지표를 제공할 수 있습니다.
8. 충격 그리고 맥락. 이러한 측면에서 소프트웨어 제품의 비즈니스 컨텍스트를 기반으로 한 우선순위는 취약성 포리스트의 우선순위를 지정하고 분류하는 데 도움이 됩니다.
몇 가지 예는 다음과 같습니다
- 모듈/제품의 중요도: 이것이 미션 크리티컬한가요(민감도 또는 중요도)?
- 특정 취약점이 있는 제품은 몇 개입니까?
- 서비스/구성요소의 외부효과 노출
9. 규정 준수 노출 – 라이선스: 독점 소프트웨어 라이선스와 오픈 소스 소프트웨어 라이선스 모두 조직의 법적 정책 준수 여부를 확인하는 데 중요합니다.
위험 점수 매기기 계층 개념 – SBOM에 위험 지표 추가:
- 스타트 SBOM 데이터를 기반으로 한 CVE 열거 및 CVSS 점수를 사용합니다.
- VEX 컨텍스트를 사용하고 추가하여 중요도 우선순위 재설정
- 높은 EPSS 점수(예: 0.6-1.0)로 CVE를 평가합니다.
- Kev 목록 우선순위 지정 – 먼저 주소.
- OpenSSF 평판 점수(1-10)로 평가 - 위험한 종속성을 식별합니다.
- 분석 노출 외부 네트워크로(CVSS 벡터 사용)
- 누적된 위험을 평가합니다. 제품 수의 양 취약점별로.
- 에 의해 평가 상표 비즈니스에 대한 특정 컨테이너 SBOM의 중요성.
- 확인 규정 준수 위반 회사 라이센스 정책에 따라 SBOM 종속성 분석을 사용할 때의 위험이 있습니다.
- 공유 데이터를 관리하다 as 증명 API 및 기계 판독 가능을 통해 Jira 및 기타 시스템과 같은 다른 시스템에 대한 워크플로를 갖춘 협업 플랫폼입니다.
실제 사용 사례를 위해 위험 점수를 매긴 SBOM 활용:
- 제품 전반에 걸쳐 패치 작업 계획의 우선순위를 지정하기 위해 위험 지표를 사용하여 제품에 대한 지속적인 취약점 분류.
- 위험 측정항목을 기준으로 제품을 나란히 비교하세요.
- 배포/출시 전에 새 버전 업데이트를 비교하고 승인하세요.
- 제품 버전에 대한 위험 점수 임계값을 사용하여 기술 부채 격차를 추적합니다.
- 가장 중요한 제품 전반에 걸쳐 상위 50개 위험에 대한 빠른 보고서를 작성합니다.
- 사고 대응을 가속화하기 위한 영향 분석 - 적극적으로 악용된 취약점이 실제로 발견된 경우. 이 경우, 시간이 중요하다 내가 어떻게 영향을 받는지, 그리고 이 노출에 대한 히트맵의 폭발 반경이 얼마나 되는지 빠르게 식별합니다.
효과적인 위험 관리를 위해 Scribe Hub 플랫폼을 사용하는 방법:
- 중앙 집중식 SBOM 관리 플랫폼 – 취약성, VEX 권고, 라이선스, 평판, 악용 가능성, 스코어카드 등 보안 측면과 함께 SBOM을 생성, 관리 및 공유합니다.
- 보안 소프트웨어 구축 및 배포 – CI/CD 파이프라인의 모든 단계에서 소스 코드, 컨테이너 이미지 및 아티팩트를 지속적으로 서명하고 확인하여 변조를 감지합니다.
- SDLC 보안 자동화 및 단순화 – 위험을 통제하세요 소프트웨어 공장에서 보안 및 비즈니스 논리를 가드레일에 의해 시행되는 자동화된 정책으로 변환하여 코드 신뢰성을 보장합니다.
- 투명성을 활성화합니다. 배송 속도 향상 – 개발 팀의 결과물을 방해하지 않으면서 보안 제어를 간소화하고 책임을 수행할 수 있는 역량을 보안 팀에 부여합니다.
- 정책을 시행합니다. 규정 준수 입증 - SDLC 정책 및 거버넌스를 모니터링하고 시행하여 소프트웨어 위험 상태를 강화하고 비즈니스에 필요한 규정 준수를 입증합니다.
두 가지 예 스크라이브 허브 위험 분석 기능이 제공됩니다.
SBOM별로 매핑된 취약점, CVSS, VEX, EPSS 및 KEV 데이터를 기준으로 위험 점수를 매깁니다.
MTTR이 식별된 중요한 취약점을 복구하는 데 걸리는 평균 시간을 나타내는 시간 경과에 따른 SBOM 버전 성능의 시계열입니다.
요약
SBOM 기반 위험 평가를 통해 조직은 사전 정의된 위험 요소를 평가하고 기업 내 특정 소프트웨어 제품과 관련된 잠재적 미래 위험을 예측함으로써 공급망 위험을 평가할 수 있습니다. 위험 점수는 소프트웨어 및 해당 구성 요소와 관련된 현재 및 미래의 위험을 예측하기 위한 정량적 척도 역할을 합니다.
이 점수 측정 기준은 SBOM, VEX 등의 피드에서 가져온 지표에서 파생되며 공급망 위험 관리(SCRM)를 지원하는 콘텐츠와 일치합니다. 위험 점수를 적용하거나 평가할 때 소프트웨어의 사용 상황, 액세스 또는 격리 방법, 지원하는 프로세스 및 시스템과 같은 요소를 고려해야 합니다.
Scribe Hub는 대규모 SBOM의 추출, 관리, 증명 수집 및 위험 점수 분석을 위해 설계된 협업 플랫폼 역할을 합니다. 이 플랫폼은 복잡한 시스템과 소프트웨어 제품의 복잡성을 처리하기 위해 여러 외부 데이터 피드를 효율적으로 처리합니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
