새로운 취약점이 공개되는 속도는 지속적으로 증가하고 있습니다. 현재 연간 평균 CVE는 15,000개입니다. 2022년에는 26,000개 이상의 새로운 CVE가 보고되었습니다. 분명히 모든 취약점이 소프트웨어와 관련된 것은 아닙니다. 특정 취약점이 문제인지 파악하려면 먼저 취약점이 포함된 라이브러리나 제품을 사용하고 있는지 파악한 다음 해당 라이브러리의 문제가 있는 버전과 모듈을 사용하고 있는지 파악해야 합니다. 마지막으로, 해당 취약점이 특정 제품과 관련이 있는지, 그리고 취약한 라이브러리나 제품을 사용한 방식과 관련이 있는지 확인하려면 개발 팀과 상의해야 합니다.
이 모든 것을 알아내는 과정은 간단하지 않고 꽤 많은 시간이 걸릴 수 있습니다. 유명한 사이버 보안 전문가인 Tom Alrich는 다음과 같이 추정합니다. 특정 소프트웨어 제품에 존재하는 모든 CVE의 약 95%는 악용될 수 없습니다.. 그러나 최종 사용자이거나 타사 소프트웨어를 시스템에 통합하려는 회사인 경우 문제가 있는 5%를 어떻게 식별하여 적절한 교정이나 패치를 요청할 수 있습니까?
이런 생각이 드는 곳이 바로 이곳이다 VEX(Vulnerability Exploitability Exchange)가 등장합니다.. VEX의 목적은 다음과 같이 정의됩니다. 지도 2021년 미국 통신정보청(NTIA)은 "제품이 포함된 구성 요소의 특정 취약성으로 인해 영향을 받는지, 영향을 받는 경우 제품이 영향을 받는지에 대한 추가 정보를 사용자(예: 운영자, 개발자 및 서비스 제공자)에게 제공합니다. , 해결을 위해 권장되는 조치가 있는지 여부.”
지금 당장 여러분은 어떻게 VEX 문서를 얻고 구성요소 점검을 시작할 수 있을지 고민하고 계실 것입니다. 글쎄요, VEX 사용의 현실은 늘 그렇듯이 복잡합니다.
VEX의 목적을 알아보세요
간단히 말해서, VEX는 '이 소프트웨어의 내 버전이 여기에 악용될 수 있습니까?'라는 질문에 빠르고 쉽게 대답하도록 되어 있습니다. 취약점?'.
해당 질문에 대한 대답은 다음 네 가지 주요 옵션 중 하나가 되어야 합니다.
- 영향을받지 않았다: 이 취약점과 관련하여 수정이 필요하지 않습니다.
- 체하는: 이 취약점을 교정하거나 해결하기 위한 조치가 권장됩니다.
- 결정된: 이러한 제품 버전에는 취약점에 대한 수정 사항이 포함되어 있습니다.
- 조사중인: 해당 제품 버전이 취약점의 영향을 받는지는 아직 알려지지 않았습니다. 업데이트는 이후 릴리스에서 제공될 예정입니다.
VEX는 기계 판독이 가능하고 기계 생성이 가능해야 하기 때문에 관심 있는 모든 사람이 쿼리하고 필요한 답변을 얻을 수 있도록 어딘가에 이러한 문서에 대한 검색 가능한 데이터베이스를 두는 것이 아이디어입니다.
특정 소프트웨어 제품에서 취약점의 95%가 악용되지 않는다고 가정하므로, 이 시스템은 각 제품에서 발견된 방대한 취약점 목록을 사용자가 주의를 기울이거나 수정 또는 패치를 요청해야 하는 취약점으로 축소하기 위한 것입니다. 을 위한.
VEX의 역사에 관한 흥미로운 사실이 많이 있습니다.
2020년에 NTIA(미국 통신정보청)는 VEX의 아이디어를 수반되는 도구로 논의하기 시작했습니다. SBOM (소프트웨어 BOM). 2021년 XNUMX월 NTIA는 VEX가 수행해야 하는 작업에 대한 한 페이지 분량의 소개와 설명을 공개했습니다.
나중에 새로운 자문 형식의 요구 사항을 개선하려는 노력은 CISA(미국 사이버 보안 및 인프라 보안국)의 후원으로 진행되었습니다. 문서 2022년 초에 VEX 문서가 도움이 될 것으로 예상되는 몇 가지 사용 사례와 좀 더 자세한 내용을 다룰 예정입니다. 초안인 문서는 NTIA가 SBOM의 최소 필수 필드를 정의한 것과 동일한 방식으로 VEX 문서의 최소 필수 필드를 정의했습니다.
그 이후로 실제로 기계가 읽을 수 있는 VEX 문서 형식을 만들려는 두 가지 주요 시도가 있었습니다.
- XNUMXD덴탈의 CSAF(공통 보안 권고 프레임워크) 최초로 사용 가능한 형식이었습니다. 이 형식은 사이버 보안, 블록체인, IoT 및 기타 분야에 대한 오픈 소스 표준을 생산하는 데 전념하는 국제 비영리 단체인 OASIS Open에서 2022년 말에 출시했습니다.
- 사이클론 DX, OWASP(개방형 웹 애플리케이션 보안 프로젝트)에서 시작한 SBOM용 표준화된 형식으로, VEX 문서도 생성할 수 있도록 조정되었습니다.
CSAF는 포괄적인 형식이지만 실제로 성공적으로 사용하려면 여러 필드와 많은 메타 정보를 포함해야 실제 채택 가능성이 낮습니다. CyclonDX VEX 이니셔티브는 훨씬 더 얇으므로 가장 많이 사용할 VEX 표준을 고려할 때 아마도 적합할 것입니다. CyclonDX 형식을 사용합니다.
VEX가 장애물에 부딪힌 이유 – 성공을 방해하는 문제 발견
VEX는 좋은 아이디어이며 특정 소프트웨어 제품에서 특정 취약점이 실제로 악용될 수 있는지 신속하게 확인할 수 있는 귀중한 기능을 제공할 수 있습니다.
그러나 지금까지 구현을 방해하는 몇 가지 문제가 있습니다.
- 제출 책임 – 필수 VEX 서류 제출을 담당하는 사람은 누구입니까? 소프트웨어 제작자입니까? 제3자 보안 회사입니까, 아니면 비영리 단체입니까? 정부 기관? 여러 출처에서 모순되는 정보를 제출하면 어떻게 되나요?
- VEX 데이터베이스 – VEX 정보를 누가, 무엇으로 저장하고 분류해야 합니까? 일부 문서가 소프트웨어의 악용 가능한 문제를 설명한다고 가정하면 정보가 잘못된(악의적인) 손에 들어갈 위험이 있지 않습니까?
- 현재 형식은 버전 문제를 제대로 다루지 않으며 결합 버전 관리 문제는 더욱 적습니다.
결합된 소프트웨어/패키지 버전은 여러 소프트웨어 패키지 또는 구성 요소를 단일 릴리스 또는 설치 패키지로 함께 묶는 방식을 의미합니다.
취약점 패치와 관련하여 결합된 소프트웨어/패키지 버전은 프로세스를 돕거나 방해할 수 있습니다. 한편, 필요한 모든 구성 요소가 포함된 단일 설치 패키지를 사용하면 취약점을 식별하고 패치하는 프로세스를 단순화할 수 있습니다. 각 개별 구성 요소를 수동으로 식별하고 패치할 필요 없이 전체 패키지에 패치를 적용하기만 하면 됩니다.
그러나 이것의 반대 측면은 패키지 내의 한 구성 요소가 취약하면 전체 소프트웨어가 취약하다는 것입니다. 이는 패키지 내의 일부 구성 요소가 패치되었더라도 패치되지 않은 구성 요소가 하나만 존재하면 전체 패키지가 여전히 위험에 처할 수 있음을 의미합니다.
귀하의 소프트웨어에 있는 라이브러리 A의 버전 1에 취약점이 있다고 가정해 보겠습니다. 이 문제는 라이브러리 A가 라이브러리 B 버전 2와 함께 존재할 때만 나타납니다. 보안 패치가 있지만 모든 사람이 이를 설치하지는 않습니다. 즉, 소프트웨어의 해당 취약점에 대한 VEX 문서는 제품, 해당 버전, 포함된 라이브러리, 해당 버전 및 출시 가능한 패치의 가능한 모든 조합을 다루어야 함을 의미합니다. 그것은 간단하게 표현하기가 쉽지 않은 복잡한 정보가 많습니다.
- VEX는 가능한 모든 버전과 패치가 포함된 하드웨어에 내장된 소프트웨어를 어떻게 처리합니까? 하드웨어를 쉽게 열고 직접 패치할 수 없다는 점을 고려하면 이 소프트웨어를 패치하는 것은 누구의 책임입니까?
이는 VEX를 처리하기 위한 자동 도구가 이해하고 고려해야 할 문제 중 일부일 뿐입니다.
모든 버전에 대한 정보를 요청하고 얻을 수 있다면 더 쉽지 않을까요?
이 중요한 정보를 문서로 공유하는 것이 가장 좋은 방법이라는 가정은 잘못된 것일 수 있습니다. 버전, 패치, 취약점의 모든 조합을 포괄할 만큼 충분한 VEX 문서를 생성하는 것은 당연히 누구도 수행하고 싶어하지 않는 중대한 작업입니다.
학자 특정 소프트웨어 프로젝트 또는 제품의 각 빌드에 대한 보안 관련 정보를 추적하고 공유하기 위한 플랫폼을 구축했습니다. 그 일환으로 각 빌드는 정확한 SBOM과 제품에서 발견된 취약점 목록을 생성합니다.
Scribe를 사용하면 소프트웨어 제작자가 이러한 각 취약점에 VEX 형식의 권고를 추가하여 악용할 수 없는지, 조사 중인지 등을 확인할 수 있습니다. 버전이 출시되면 해당 버전에 대한 모든 보안 정보를 관심 있는 제3자와 공유할 수 있습니다. , 규제 기관 등. 취약점 목록과 VEX 권고 목록을 포함하면 수신자는 이 특정 제품에서 잠재적인 문제가 될 수 있는 취약점만 볼 수 있어야 합니다. 이는 제품을 "화이트리스트"에 포함할 수 있는 소프트웨어 생산자와 특정 소프트웨어 제품에 관련된 위험 수준을 정확히 이해하는 소프트웨어 소비자 모두에게 많은 부담을 안겨줍니다.
소프트웨어 생산자는 특정 취약점이 실제로 제품의 특정 버전과 관련이 있는지 확실하게 말할 수 있는 유일한 사람이므로 자신의 제품에 대한 권고를 추가하고 수정할 수 있는 유일한 사람입니다. 이와 관련하여 소프트웨어 제작자의 판단은 최종적이며 논쟁의 여지가 없습니다. 이 정보를 누구와 공유할지 결정하는 것도 소프트웨어 제작자의 특권입니다.
제품 빌드, SBOM 및 보안 정보의 전체 기록이 Scribe에 저장되므로 사용자는 전체 소프트웨어 수명 주기 동안 사용할 수 있는 모든 버전에 대해 이 정보를 쉽게 요청하고 얻을 수 있습니다.
결론
요즘 소프트웨어 제품을 제대로 스캔하면 수천 개가 아니더라도 수백 개의 취약점이 생성될 수 있다는 점을 기억하십시오. 대부분의 사람들은 그러한 숫자를 다룰 수 없습니다. 경고 피로가 시작되고 취약점의 수가 그 숫자가 됩니다.
감지된 문제의 수를 관리 가능한 수준으로 줄일 수 있는 가능성은 소프트웨어 제작자와 사용자에게 도움이 될 것입니다. 목표는 소프트웨어 제작자가 가능한 한 빨리 문제를 패치하고 해결할 수 있도록 실제 문제에만 집중하는 것입니다.
다음과 같은 자동화된 도구 학자 각 프로젝트 및 빌드에 대한 관련 취약점만 볼 수 있는 쉬운 방법과 쉽게 공유할 수 있는 정보를 제공하여 산더미 같은 취약점을 훨씬 더 줄이고 관리하기 쉽게 만듭니다.
그러나 중요한 주의 사항은 관련 취약점만 쉽게 확인하고 대응할 수 있는 이러한 미래는 오픈 소스 커뮤니티의 적극적인 참여 없이는 불가능하다는 것입니다. 요즘 대부분의 코드는 상당한 양의 오픈 소스 소프트웨어로 구성되어 있으므로 해당 라이브러리의 유지 관리 담당자와 개발자가 코드를 괴롭히는 악용 가능한 취약점을 발견하고 해결하는 데 참여해야 합니다.
관련된, 악용 가능한 취약점의 문제는 사라지지 않으므로 우리 모두는 '이 소프트웨어의 내 버전이 여기에 악용될 수 있습니까?'라는 질문에 대한 답을 얻을 수 있는 가장 효율적이고 비용 효과적인 방법을 찾아야 합니다. 취약점'.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
