KR20230130089A - 취약한 소프트웨어 패키지의 선택 및 발견을 위한 시스템및 방법 - Google Patents

취약한 소프트웨어 패키지의 선택 및 발견을 위한 시스템및 방법 Download PDF

Info

Publication number
KR20230130089A
KR20230130089A KR1020237027297A KR20237027297A KR20230130089A KR 20230130089 A KR20230130089 A KR 20230130089A KR 1020237027297 A KR1020237027297 A KR 1020237027297A KR 20237027297 A KR20237027297 A KR 20237027297A KR 20230130089 A KR20230130089 A KR 20230130089A
Authority
KR
South Korea
Prior art keywords
software
software package
package
packages
vulnerability
Prior art date
Application number
KR1020237027297A
Other languages
English (en)
Inventor
리론 레빈
알론 아들러
미카엘 클렛셀만
디마 스토펠
Original Assignee
트위스트락, 리미티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 트위스트락, 리미티드 filed Critical 트위스트락, 리미티드
Publication of KR20230130089A publication Critical patent/KR20230130089A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/04—Inference or reasoning models

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Stored Programmes (AREA)

Abstract

소프트웨어 패키지들의 취약성을 발견하기 위한 시스템 및 방법이 개시된다. 방법은 복수의 소프트웨어 패키지들 중 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지에서 적어도 하나의 잠재적 취약성 소스를 식별하는 단계 - 각각의 잠재적 취약성 소스는 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 중 하나에 대한 변경임 -; 및 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각의 데이터에 대한 적어도 하나의 취약성 식별 규칙을 선택하고 적용함으로써 복수의 소프트웨어 패키지들의 적어도 하나의 취약성을 식별하는 단계를 포함하며, 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각에 대한 적어도 하나의 취약성 식별 규칙은 잠재적으로 취약한 소프트웨어 패키지에 대한 버전 식별자들의 가용성에 기초하여 선택된다.

Description

취약한 소프트웨어 패키지의 선택 및 발견을 위한 시스템 및 방법
관련 출원의 상호 참조
본 출원은 2021년 1월 11일에 출원된 미국 출원 번호 17/145,893의 이익을 주장하며, 그 내용은 참조로 여기에 포함된다.
기술 분야
본 개시는 일반적으로 소프트웨어 취약성 검출에 관한 것으로, 보다 구체적으로는 소프트웨어 취약성 검출에서 취약성 커버리지(vulnerability coverage)를 증가시키는 것에 관한 것이다.
소프트웨어 기반 기술들이 점점 더 일상 생활을 지배함에 따라, 소프트웨어 취약성을 검출하고 수정하는 것이 시스템들의 정상적인 기능에 매우 중요해졌다. 일부 기존 솔루션들은 잠재적인 취약성을 식별하기 위해 소프트웨어 및 이러한 소프트웨어를 사용하는 프로세스들을 검토하도록 훈련된 사람 작업자들을 활용한다. 이러한 프로세스들은 사용자들에 의해 보고된 이슈들 또는 코드의 수동 검토(예를 들어, 취약한 소프트웨어 패키지를 찾기 위해 소프트웨어 라이브러리를 수동으로 크롤링)를 포함할 수 있다. 그러나, 이러한 프로세스들은 자동화된 솔루션들에 비해 매우 비효율적이고, 사람의 실수가 발생할 수 있으며, 일관성 없는 결과를 초래하는 취약성 존재 여부에 대한 주관적인 판단이 필요한 경우가 많다.
소프트웨어 취약성에 대한 검색과 관련된 일부 자동화된 솔루션들이 존재한다. 그러나, 이러한 솔루션들은 소프트웨어 취약성을 정확하게 식별하는 데 상당한 어려움을 겪고 있다. 특히, 일부 자동화된 솔루션들은 이미 알려진 문제들을 확인할 수 있지만, 이러한 솔루션들은 이전에 알려지지 않은 소프트웨어들, 기존 소프트웨어의 알려지지 않은 버전들, 또는 표준화된 포맷팅의 어떤 형태가 없는 소프트웨어를 식별하는 데 어려움이 있다. 동작 시스템 취약성의 경우, 대부분의 주요 벤더들은 기존 솔루션들에 의해 이용될 수 있는 일관되고 표준적인 피드를 제공하지만 다른 소프트웨어 제공자들은 일관되고 표준적인 피드들을 제공하지 않을 수도 있다. 이는 특히 오픈 소스 소프트웨어 패키지들 또는 신뢰할 수 있는 단일 소스를 갖지 않는 임의의 다른 소프트웨어의 경우 문제가 될 수 있다.
따라서 위에서 언급한 문제들을 극복할 수 있는 솔루션을 제공하는 것이 유리할 것이다.
본 개시의 몇몇 예시적인 실시예들의 요약은 다음과 같다. 이러한 요약은 본 실시예들의 기본적인 이해를 제공하기 위해 독자의 편의를 위해 제공되며 본 개시의 범위를 완전히 정의하지는 않는다. 이러한 요약은 모든 고려된 실시예들의 광범위한 개요가 아니며, 모든 실시예들의 핵심 또는 중요한 요소들을 식별하는 것도 아니고 임의의 또는 모든 양태들의 범위를 설명하는 것도 아니다. 그것의 유일한 목적은 나중에 제시되는 보다 상세한 설명에 대한 서론으로서 단순화된 형태로 하나 이상의 실시예들의 일부 개념들을 제시하는 것이다. 편의상, "일부 실시예들" 또는 "특정 실시예들"라는 용어는 본 개시의 단일 실시예 또는 다수의 실시예들을 지칭하기 위해 본원에서 사용될 수 있다.
본 명세서에 개시된 특정 실시예들은 소프트웨어 패키지들의 취약성을 발견하기 위한 방법을 포함한다. 상기 방법은: 복수의 소프트웨어 패키지들 중 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지에서 적어도 하나의 잠재적 취약성 소스를 식별하는 단계 - 각각의 잠재적 취약성 소스는 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 중 하나에 대한 변경임 -; 및 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각의 데이터에 대한 적어도 하나의 취약성 식별 규칙을 선택하고 적용함으로써 복수의 소프트웨어 패키지들의 적어도 하나의 취약성을 식별하는 단계를 포함하며, 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각에 대한 적어도 하나의 취약성 식별 규칙은 잠재적으로 취약한 소프트웨어 패키지에 대한 버전 식별자들의 가용성에 기초하여 선택된다.
본 명세서에 개시된 특정 실시예들은 또한 프로세싱 회로로 하여금 프로세스를 실행하게 하는 명령들을 저장한 비-일시적 컴퓨터 판독 가능한 매체를 포함하며, 상기 프로세스는: 복수의 소프트웨어 패키지들 중 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지에서 적어도 하나의 잠재적 취약성 소스를 식별하는 것 - 각각의 잠재적 취약성 소스는 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 중 하나에 대한 변경임 -; 및 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각의 데이터에 대한 적어도 하나의 취약성 식별 규칙을 선택하고 적용함으로써 복수의 소프트웨어 패키지들의 적어도 하나의 취약성을 식별하는 것 - 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각에 대한 적어도 하나의 취약성 식별 규칙은 잠재적으로 취약한 소프트웨어 패키지에 대한 버전 식별자들의 가용성에 기초하여 선택됨 -를 포함한다.
본 명세서에 개시된 특정 실시예들은 또한 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템을 포함한다. 상기 시스템은: 프로세싱 회로; 및 메모리를 포함하고, 상기 메모리는 프로세싱 회로에 의해 실행될 때: 복수의 소프트웨어 패키지들 중 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지에서 적어도 하나의 잠재적 취약성 소스를 식별하고 - 각각의 잠재적 취약성 소스는 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 중 하나에 대한 변경임 -; 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각의 데이터에 대한 적어도 하나의 취약성 식별 규칙을 선택하고 적용함으로써 복수의 소프트웨어 패키지들의 적어도 하나의 취약성을 식별하도록 - 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각에 대한 적어도 하나의 취약성 식별 규칙은 잠재적으로 취약한 소프트웨어 패키지에 대한 버전 식별자들의 가용성에 기초하여 선택됨 -, 상기 시스템을 설정하는 명령들을 포함한다.
여기에 개시된 주제는 명세서 결론의 청구범위에 특히 지적되고 명확하게 청구되어 있다. 개시된 실시예들의 전술한 및 다른 목적들, 특징들, 및 장점들은 첨부된 도면들과 함께 취해진 다음의 상세한 설명으로부터 더욱 명백해질 것이다.
도 1은 다양한 개시된 실시예들을 설명하기 위해 사용되는 네트워크 다이어그램이다.
도 2는 실시예에 따라 소프트웨어 패키지들에서 알려지지 않은 소프트웨어 취약성을 발견하는 방법을 나타내는 흐름도이다.
도 3은 실시예에 따라 잠재적 취약성 소스를 식별하기 위한 방법을 나타내는 흐름도이다.
도 4는 실시예에 따라 소프트웨어 패키지를 표준화된 취약성 식별자에 매핑하는 방법을 나타내는 예시적인 흐름도이다.
도 5는 실시예에 따른 취약성 검출기의 개략도이다.
본 명세서에 개시된 실시예들은 본 명세서의 혁신적인 교시들의 많은 유리한 사용들의 예들일 뿐이라는 점에 주목하는 것이 중요하다. 일반적으로, 본 출원의 명세서에서 이루어진 설명들은 청구된 다양한 실시예들 중 어떠한 것도 반드시 제한하지 않는다. 또한, 일부 설명들은 일부 독창적인 특징들에 적용될 수 있지만 다른 특징들에는 적용되지 않을 수 있다. 일반적으로, 달리 명시되지 않는 한, 단수 요소들은 일반성을 잃지 않고 복수가 될 수 있으며 그 반대도 가능한다. 도면들에서, 같은 번호들은 여러 관점에서 같은 부분들을 가리킨다.
다양한 개시된 실시예들은 소프트웨어 취약성을 검출하기 위한 방법 및 시스템을 포함한다. 분석을 위해 하나 이상의 저장소들이 선택될 수 있다. 각 저장소는 소프트웨어 패키지들을 저장한다. 소프트웨어 패키지들과 관련된 데이터에 기초하여 선택된 저장소들의 소프트웨어 패키지들에 대한 변경들 중에서 분석을 위해 하나 이상의 잠재적 취약성 소스들이 선택된다. 잠재적 취약성 소스들은 사용 빈도, 생성 날짜, 소프트웨어 패키지가 오픈 소스로 알려져 있는지 여부, 이들의 조합 등과 같은 팩터들에 기초할 수 있는 규칙들을 사용하여 식별된다.
실시예에서, 잠재적 취약성 소스들을 식별하는 것은 변경 명령들을 쿼리(querying) 및 파싱(parsing), 특정 개발자들을 추적, 코드 코멘트들을 분석, 릴리스 노트를 분석, 및 버전 식별자들에 기초한 잠재적 취약성을 추론 중 임의의 것 또는 모두를 포함할 수 있다. 각 변경 명령은 데이터의 일부를 변경하라는 명령이므로 변경이 완료되거나 확정되었음을 나타낸다. 변경 명령들은 커밋 스테이트먼트(또는, "커밋"이라고 지칭함)을 포함할 수 있지만 이에 제한되지는 않는다.
이러한 단계들의 결과에 기초하여, 잠재적 취약성 소스들인 소프트웨어 패키지들에 대한 보안 관련 변경들이 식별된다. 보안 관련 변경들에 대해 고유한 식별자들이 생성될 수 있다. 고유한 식별자들은 나중에 취약성을 유발한 특정 변경들을 조회할 수 있도록 하면서 변경들을 익명화하는 데 활용될 수 있다. 이러한 변경들의 익명화는 독점 정보를 보존하는 데 중요할 수 있다.
이러한 변경들로 인해 발생하는 모든 취약성들을 식별하기 위해 보안 관련 변경들 각각의 데이터에 대해 취약성 식별 규칙들이 선택되어 적용되고, 따라서 이러한 변경들로 인해 취약한 소프트웨어 패키지들을 식별할 수 있다. 취약성 식별 규칙들은 소프트웨어 패키지를 저장하는 소프트웨어 저장소에 대한 버전 식별자들의 가용성에 기초하여 선택될 수 있다. 예를 들어, 소프트웨어 저장소에 패키지 버전이 있는 경우 제1 규칙이 선택될 수 있고, 저장소에 릴리스 버전이 있지만 패키지 버전은 없는 경우 제2 규칙이 선택될 수 있으며, 저장소에 소프트웨어 패키지들에 대한 어떠한 버전 식별자들도 없는 경우 제3 규칙이 선택될 수 있다. 상이한 규칙들은 소프트웨어 패키지가 취약한 것으로 간주되는 상황을 정의할 수 있다. 따라서, 이러한 취약성 식별 규칙들을 적용하면 주어진 소프트웨어 패키지가 취약한지 여부를 객관적으로 결정할 수 있다.
식별된 취약성들 중 하나를 갖는 각 소프트웨어 패키지는 표준 소프트웨어 패키지 명명 체계의 알려진 이름에 매핑될 수 있다. 이러한 소프트웨어 패키지 명명 체계는 CPE(Common Platform Enumeration)일 수 있지만 이에 제한되지 않는다. CPE는 소프트웨어 취약성에 활용될 수 있는 구조화된 명명 체계이다. CPE는 URI(Uniform Resource Identifier)들에 대한 일반 구문을 활용하며, 공식적인 이름 포맷, 시스템에 대해 이름들을 확인하는 방법, 및 텍스트와 테스트를 이름에 바인딩하기 위한 디스크립션 포맷을 포함한다. CPE는 또한 CPE에 대해 합의된 이름 목록을 정의하는 사전을 활용한다.
식별된 취약성들 중 하나를 갖는 각각의 소프트웨어 패키지는 또한 예를 들어 CVE(Common Vulnerabilities and Exposures)에 따라 정의된 식별자와 같은 표준화된 소프트웨어 취약성 식별자에 매핑될 수 있다. 소프트웨어 패키지들을 표준화된 소프트웨어 취약성 식별자들에 매핑하는 것은 소프트웨어 패키지를 표준 소프트웨어 패키지 명명 체계의 이름에 매핑하는 것에 기초할 수 있다.
일부 실시예들에서, 종속성 그래프는 식별된 취약성들에 기초하여 생성되거나 업데이트될 수 있다. 종속성 그래프는 소프트웨어 패키지들 간의 종속성을 나타내는 에지들에 의해 연결된 소프트웨어 패키지들을 나타내는 노드들을 포함한다. 종속성 그래프는 또한 취약한 것으로 식별된 소프트웨어 패키지들을 나타내는 노드들에 대한 메타데이터를 포함한다. 결과적으로, 이러한 종속성 그래프는 소프트웨어 패키지들 간의 종속성으로 인해 발생하는 취약성을 식별하는 것을 가능하게 한다. 예를 들어, 그 자체로 취약하지 않은 제1 소프트웨어 패키지는 취약한 제2 소프트웨어 패키지에 종속할 수 있으며, 그에 따라 제2 소프트웨어 패키지에 대한 제1 소프트웨어 패키지의 종속성은 취약성을 나타낼 수 있다.
개시된 실시예들은 코드 또는 코멘트들의 수동 평가에 의존하지 않고 알려진 취약성들에 기초하여 생성된 규칙들을 요구하지 않는 소프트웨어 취약성들을 검출하기 위한 자동화된 프로세스를 제공한다. 개시된 실시예들은 알려지지 않은 취약성들 또는 보고되었지만 알려진 취약성들과 명시적으로 일치하지 않는 취약성들을 식별하기 위해 이용될 수 있다. 따라서 개시된 실시예들은 사람의 실수 또는 일관되지 않은 결과들을 초래할 수 있는 주관적 분석을 요구하지 않고 기존의 자동화된 솔루션들보다 더 많은 소프트웨어 취약성들을 검출하는 것을 가능하게 한다.
더욱이, 개시된 실시예들은 취약성들이 공식적으로 보고되기 전에 또는 취약성들이 부적절하게 보고된 경우에도 취약성들을 검출하는 것을 가능하게 한다. 또한, 개시된 실시예들은 취약성 검출의 객관성을 향상시키는 미리 결정된 기준에 따라 선택된 취약성 규칙들을 사용한다. 따라서, 개시된 실시예들은 거짓 긍정(false positives)의 수를 크게 증가시키지 않고서 더 많은 소프트웨어 취약성들이 검출되도록 소프트웨어 취약성 검출의 정확도를 개선할 수 있게 한다.
또한, 개시된 실시예들은 알려진 소프트웨어 패키지들에 대해 적절하게 식별되지 않는 취약한 소프트웨어 패키지들을 정확하게 일치시키는 것을 가능하게 한다. 이와 관련하여, 소프트웨어 패키지 이름의 표준화된 버전은 종종 소프트웨어 패키지의 실제 이름(예를 들어, 소프트웨어 패키지의 메타데이터에 표시된 이름)과 일치하지 않는다는 점에 유의해야 한다. 비-제한적 예로서, 패키지의 실제 이름은 "org.apache.httpcomponents)_httpclient"로 표시될 수 있는 반면 패키지의 CPE 이름은 "apache:httpclient"일 수 있다. 기존의 자동화된 솔루션들은 패키지를 각각의 표준화된 이름에 매핑할 수 없으며, 따라서 특정 소프트웨어 패키지에 대한 변경들이 다른 소스들에서 발생할 때 그 변경들을 정확하게 식별하지 못하는 경우가 많다.
도 1은 다양한 개시된 실시예들을 설명하기 위해 사용되는 예시적인 네트워크 다이어그램(100)을 도시한다. 예시적인 네트워크 다이어그램(100)에서, 소스 저장소들(120-1 내지 120-N)(단지 단순화를 위해 개별적으로는 소스 저장소(120)로 지칭되고 집합적으로는 소스 저장소들(120)로 지칭됨), 취약성 검출기(130), 및 사용자 디바이스(140)는 네트워크(110)를 통해 통신적으로 연결된다. 네트워크(110)는 무선, 셀룰러 또는 유선 네트워크, LAN(local area network), WAN(wide area network), MAN(metro area network), 인터넷, WWW(worldwide web), 유사한 네트워크들, 및 이들의 임의의 조합일 수 있지만, 이에 제한되지 않는다.
소스 저장소들(120) 각각은 취약할 수 있는 소프트웨어 패키지들(미도시)을 저장한다. 소스 저장소들(120) 중 적어도 일부는 오픈 소스 소프트웨어 패키지들을 저장하는 오픈 소스 저장소들일 수 있다. 오픈 소스 소프트웨어 패키지들은 표준화된 포맷팅(standardized formatting)을 사용하지 않으며, 따라서 상이한 포맷들의 소프트웨어 패키지들과 연관된 미리 결정된 규칙들을 사용하는 알려진 소프트웨어 취약성들을 즉시 식별하지 못 할 수 있다. 이를 위해, 취약성 식별부(130)가 본 명세서에 기술된 바와 같이 소프트웨어 취약성들을 식별하도록 구성된다. 이러한 취약성 식별은 알려지지 않거나 부적절하게 보고된 취약성들을 식별하는 것을 가능하게 하며, 오픈 소스 소프트웨어 패키지 또는 알려진 포맷팅이 없는 다른 소프트웨어 패키지들의 취약성들을 식별할 수 있다.
사용자 디바이스(UD)(140)는 개인용 컴퓨터, 랩탑, 태블릿 컴퓨터, 스마트폰, 웨어러블 컴퓨팅 디바이스, 또는 알림을 수신하고 표시할 수 있는 임의의 다른 디바이스일 수 있지만 이에 제한되지는 않는다.
도 2는 실시예에 따라 소프트웨어 패키지들에서 알려지지 않은 소프트웨어 취약성을 발견하는 방법을 나타내는 흐름도(200)이다. 실시예에서, 방법은 도 1의 취약성 검출기(130)에 의해 수행된다.
S210에서, 분석될 취약성들의 잠재적 소스들을 식별한다. 일 실시예에서, S210은 잠재적으로 취약성을 야기하는 것으로 특정 변경들을 식별하기 위해 소프트웨어 패키지들과 관련된 다양한 데이터를 분석하는 것을 포함한다. 이와 관련하여 소프트웨어 패키지들의 변경 수는 시간이 지남에 따라 기하급수적으로 증가하며 따라서 취약성들의 모든 및 각각의 변경을 분석하는 것은 자동화된 솔루션들의 경우에도 비현실적이라는 지적이 있다. 본 명세서에 기술된 바와 같이 변경들을 선택적으로 분석함으로써, 개시된 실시예들은 이러한 변경들이 적용되는 소프트웨어 패키지를 분석하는 데 필요한 과도한 컴퓨팅 리소스 소비를 줄이는 것을 허용하면서 여전히 전부는 아니더라도 대부분의 발견되지 않은 취약성들을 식별한다.
다른 실시예에서, S210은 또한 소프트웨어 패키지들이 분석될 저장소들을 선택하는 것을 포함할 수 있다. 특정 저장소들을 선택하는 것은 분석되어야 하는 데이터의 범위를 더욱 줄일 수 있으며 그에 따라 분석과 관련된 컴퓨팅 리소스들의 소비를 더욱 줄이는 것을 가능하게 한다.
일 실시예에서, 취약성들의 잠재적 소스들의 식별은 도 3에 도시된 흐름도에 따라 수행된다. 도 3은 실시예에 따라 잠재적 취약성 소스들을 식별하기 위한 방법을 나타내는 흐름도이다.
선택적인 S310에서 저장소들이 분석을 위해 선택된다. 분석되는 저장소들이 알려지지 않거나 또는 발견되지 않은 취약한 소프트웨어 패키지들을 갖고 있을 가능성이 높게 되도록 저장소들이 분석을 위해 선택된다. 예를 들어, 오픈 소스 소프트웨어 저장소들은 주요 소프트웨어 개발자들의 소프트웨어 저장소들보다 알려지지 않은 소프트웨어 패키지들을 포함할 가능성이 높다. 또 다른 예로서, 더 자주 액세스되거나 업데이트된 소프트웨어 패키지들을 갖고 있는 저장소들은 새롭게 출현하는 취약성들을 분석하는 데 더 중요할 수 있다.
알려지지 않았거나 발견되지 않은 소프트웨어 패키지들을 갖고 있을 가능성에 기초하여 분석을 위해 저장소들을 선택하는 것은 해당 분석에 필요한 컴퓨팅 리소스들의 사용을 감소시킨다. 이와 관련하여, 잠재적인 저장소들의 총 수가 많기 때문에 자동화된 시스템들의 경우에도 이러한 모든 저장소들의 취약성들을 분석하는 것은 비실용적이다. 따라서, 개시된 실시예들은 검색될 필요가 있는 데이터의 양을 감소시키고, 따라서 분석의 효율성을 향상시킨다.
일 실시예에서, 저장소들은 다른 저장소들과 비교하여 각각의 저장소에 저장된 소프트웨어 패키지들의 상대적 사용량에 기초하여 선택된다. 다른 실시예에서, 저장소들은 사용자 데이터의 피드백 루프, 추론된 인기 저장소들, 패키지 다운로드 통계, 또는 이들의 조합에 기초하여 선택된다.
사용자 데이터는 피드백 루프를 통해 분석되어 어떤 패키지들이 더 자주 사용되는지, 따라서 어떤 저장소들이 자주 사용되는 패키지들을 포함하는지를 결정한다. 예를 들어, 특정 기간(예를 들어, 지난 주) 내에 소프트웨어 패키지의 다운로드 수가 임계값을 초과하면 소프트웨어 패키지가 자주 사용되는 것일 수 있다. 저장소는, 예를 들어 하나 이상의 자주 사용되는 소프트웨어 패키지들을 갖거나, 임계값을 초과하는 자주 사용되는 복수의 소프트웨어 패키지들을 갖거나, 가장 많은 수의 자주 사용되는 소프트웨어 패키지들을 갖는 임계 수의 저장소들(예를 들어, 가장 자주 사용되는 소프트웨어 패키지들을 갖는 상위 10개의 저장소들) 중에서 등을 기반으로, 패키지 사용 빈도에 기초하여 선택될 수 있다.
인기 있는 저장소들을 추론하는 것은, 애플리케이션 프로그래밍 인터페이스(API)를 사용하여 패키지 종속성 매니페스트에 대해 저장소들을 재귀적으로 크롤링하고 어느 패키지들이 다른 패키지들에 의해 가장 자주 종속되는지를 결정함으로써 달성될 수 있다. 예를 들어 소프트웨어 패키지에 대한 다른 소프트웨어 패키지들의 종속성들이 임계값을 초과하는 경우 해당 소프트웨어 패키지는 인기가 있을 수 있다. 저장소는, 예를 들어 하나 이상의 인기 있는 소프트웨어 패키지들을 갖거나, 임계값을 초과하는 인기 있는 복수의 소프트웨어 패키지들을 갖거나, 가장 많은 수의 인기 있는 소프트웨어 패키지들을 갖는 임계 수의 저장소들 중에서 등을 기반으로, 패키지 인기도에 기초하여 선택될 수 있다.
패키지 다운로드 통계는 예를 들어 패키지 관리자 API를 쿼리하여 획득된다. 가장 많이 다운로드된 소프트웨어 패키지들을 갖고 있는 저장소들이 선택될 수 있다.
S320 내지 S360 단계들에서는 보안 관련 변경들을 식별하기 위해 취약성들의 소스들이 될 수 있는 변경들을 나타내는 다양한 부분들의 데이터가 분석된다. 보안 관련 변경들은 예를 들어 변경 명령, 코멘트, 노트, 또는 단계들(S320 내지 S360)과 관련하여 아래에서 추가로 설명되는 소프트웨어 패키지와 관련된 다른 데이터에 반영될 수 있다.
단계들(S320 내지 S360)에서의 단계들은 임의의 순서로 또는 병렬로 수행될 수 있고, 이들 단계들의 일부만이 적어도 일부 실시예들에서 수행될 수 있다는 점에 유의해야 한다. S310과 관련하여 상술한 바와 같이 저장소들이 선택되면 선택된 저장소들에 있는 소프트웨어 패키지들만이 분석된다.
S320에서, 변경 명령 메시지들이 쿼리를 통해 획득되고 분석된다. 변경 명령들은 예를 들어 커밋들일 수 있다. 이를 위해, S320은 변경 명령 메시지들을 쿼리하고, 그에 포함된 키워드들에 기초하여 메시지들을 분석하는 것을 포함할 수 있다. 다른 실시예에서, S320은 또한 이력 변경 명령 메시지에 기초하여 보안 관련 키워드들을 식별하도록 훈련된 기계 학습 모델을 적용하는것을 포함한다. 이러한 모델은 또한 텍스트 분류를 위해 훈련될 수 있다. 보안 관련 키워드들을 포함하는 변경 명령들은 잠재적 취약성 소스로 식별된다.
S330에서, 각각의 소프트웨어 패키지와 관련된 데이터가 분석되어 그 안에 표시된 미리 결정된 개발자들을 추적한다. 개발자들은 보안 연구원들 또는 소프트웨어 개발자들일 수 있으며, 특정 소프트웨어 패키지들에 대한 보안을 소유하는 것으로 알려진 개발자들일 수 있으며, 해당 개발자들로부터의 커밋들은 잠재적으로 알려지지 않은 보안 수정과 관련될 가능성이 높다. 이를 위해, 소프트웨어 패키지에 대해 이러한 미리 결정된 의심스러운 개발자들이 식별되면 해당 개발자들에 의한 변경들은 잠재적 취약성 소스들로서 식별된다.
S340에서, 각각의 소프트웨어 패키지에 대한 코드 코멘트들이 보안 관련 키워드들에 대해 분석된다. 일 실시예에서, S340은 또한 이력 코드 코멘트들에 기초하여 보안 관련 키워드들을 식별하도록 훈련된 기계 학습 모델을 적용하는 것을 포함한다. 이러한 모델은 또한 텍스트 분류를 위해 훈련될 수 있다. 보안 관련 키워드들을 포함하는 코멘트들로 표시된 변경들은 잠재적 취약성 소스들로서 식별된다.
S350에서, 각각의 소프트웨어 패키지에 대한 릴리스 노트들이 릴리스 날짜에 대해 분석된다. 최신의 소프트웨어 패키지들(예를 들어, 현재 시간 이전의 임계 기간 미만으로 릴리스된 소프트웨어 패키지들)을 추가하거나 수정한 변경들은 잠재적 취약성 소스들로서 식별된다.
S360에서, 각각의 소프트웨어 패키지 파일의 버전 인디케이터(version indicator)가 분석되어 잠재적 취약성 소스들이 될 수 있는 소프트웨어 패키지와 관련된 파일들에 대한 변경들을 추론한다. 예시적인 구현에서, 버전 인디케이터는 매니페스트 파일에 포함될 수 있으며 소프트웨어 패키지를 그의 현재 버전 식별자로 업데이트한 변경 후에 매니페스트 파일에 대한 변경이 잠재적 취약성 소스로서 식별될 수 있다. 이를 위해, S360은 또한 소프트웨어 패키지를 그의 현재 버전으로 업데이트한 변경 명령 후에 어떤 변경 명령이 발생했는지 여부를 결정하기 위해 변경 명령들을 분석하는 것을 포함할 수 있다.
S370에서, S320 내지 S360에서 수행된 분석들에 기초하여, 이들 단계들에 대해 전술한 바와 같이 하나 이상의 잠재적 취약성 소스들이 식별된다.
선택적인 S380에서, 고유한 식별자들이 생성되어 식별된 취약성 관련 변경들 중에서 각자의 취약성 관련 변경들에 할당될 수 있다. 변경들은 변경 명령들에 의해 영구적으로 이루어지거나, 코드 코멘트에서 표시되거나, 릴리스 노트에서 표시되는 등에 의한 변경들일 수 있다. 고유한 식별자들은 나중에 취약성들을 야기한 특정 변경들을 조회하는 데 활용될 수 있으며, 또한 변경들을 익명화하는 것을 가능하게 한다. 이러한 변경들의 익명화는 독점 정보를 보존하는 데 중요할 수 있다.
도 2로 돌아가서 S220에서 취약성들이 식별된다. 식별된 취약성들은 알려지지 않거나, 부적절하게 보고되거나, 그렇지 않으면 발견되지 않은 취약성들일 수 있다. 이러한 취약성들을 식별함으로써 또한 취약한 소프트웨어 패키지들도 식별하게 된다.
일 실시예에서, S220은 S210에서 식별된 잠재적 취약성 소스인 변경의 대상이었던 각각의 소프트웨어 패키지와 관련된 데이터에 기초하여 취약성 식별 규칙들을 선택하고 적용하는 것을 포함한다. 다른 실시예에서, 취약성 식별 규칙들은 소프트웨어 패키지를 저장하는 소프트웨어 저장소에 대한 버전 식별자들의 가용성에 기초하여 선택될 수 있다. 또 다른 실시예에서, 제1 규칙은 소프트웨어 패키지를 저장하는 소프트웨어 저장소가 패키지 버전들을 가질 때 또는 패키지 버전이 소프트웨어 패키지에 대해 이용가능할 때 선택되고, 제2 규칙은 소프트웨어 패키지를 위한 저장소가 릴리스 버전들을 갖지만 패키지 버전들을 갖지 않을 때 또는 릴리스 버전은 이용가능하지만 패키지 버전은 이용가능하지 않을 때 선택되고, 제3 규칙은 소프트웨어 패키지를 위한 저장소가 소프트웨어 패키지들에 대한 어떠한 버전 식별자도 갖고 있지 않을 때 또는 패키지 버전은 물론 릴리스 버전도 소프트웨어 패키지에 대해 이용가능하지 않을 때 선택된다.
일 실시예에서, 제1 규칙은 취약한 소프트웨어 패키지를, 최신 변경 명령(예를 들어, 최신 커밋)에 표시된 버전보다 이전 버전 또는 동일한 버전인 패키지 버전을 갖는 소프트웨어 패키지로 정의한다. 제2 규칙은 취약한 소프트웨어 패키지를, 변경 명령과 시간적으로 상관되지 않은 릴리스 버전(예를 들어, 소프트웨어 패키지에 대한 가장 최근 커밋의 타임스탬프로 표시된 날짜의 임계 일수 내에 있지 않은 릴리스 날짜와 연관된 릴리스 버전)을 갖는 소프트웨어 패키지로 정의한다. 릴리스 버전의 릴리스 날짜는 공개적으로 이용가능한 저장소들에 저장될 수 있다. 제3 규칙은 취약한 소프트웨어 패키지를, 공개적 저장소들에 저장된 데이터에 표시된 릴리스 시간과 시간적으로 상관되지 않은 소프트웨어 패키지로 정의한다(예를 들어, 노드 패키지 관리자(NPM)와 같은 패키지 관리자에 의해 표시된 가장 최근 변경의 임계 시간 내에 있지 않은 생성 시간을 나타내는 데이터를 가진 소프트웨어 패키지).
S230에서, 각각의 취약한 소프트웨어 패키지(즉, 식별된 취약성을 갖는 각각의 취약한 소프트웨어 패키지)는 각자의 취약성 식별자에 매핑된다. 일 실시예에서, S230은 각각의 식별된 취약한 소프트웨어 패키지를 표준 소프트웨어 패키지 명명 체계의 표준화된 이름에 매핑하고 각각의 식별된 취약한 소프트웨어 패키지를 각각의 식별된 취약한 소프트웨어 패키지에 대한 표준화된 이름에 기초하여 표준화된 소프트웨어 취약성 식별자에 매핑하는 것을 포함한다.
일 실시예에서, 각각의 취약한 소프트웨어 패키지는 도 4에 따른 프로세스를 사용하여 각자의 취약성 식별자에 매핑된다. 도 4는 실시예에 따라 소프트웨어 패키지를 표준화된 취약성 식별자에 매핑하는 방법을 나타내는 예시적인 흐름도(S230)이다.
일 실시예에서, 도 4에 도시된 프로세스는 2개의 서브-프로세스들(400-1 및 400-2)을 더 포함한다. 제1 서브-프로세스에서, 소프트웨어 패키지는 해당 매핑을 사용하여 정확하게 식별될 수 있도록 표준화된 소프트웨어 패키지 이름에 매핑된다. 제2 서브-프로세스에서, 소프트웨어 패키지는 알려진 유형의 취약성이 소프트웨어 패키지에 대해 식별될 수 있도록 표준화된 취약성 식별자에 매핑된다. 다른 실시예들에서, 도 4의 방법은 제2 서브-프로세스(400-2)만을 포함할 수 있다.
제1 서브-프로세스(400-1)에서, S410에서, 소프트웨어 패키지의 데이터에 표시된 패키지 이름이 토큰화된다.
S420에서, 소프트웨어 패키지에 대한 하나 이상의 가능한 표준화된 소프트웨어 패키지 이름이 하나 이상의 소프트웨어 패키지 저장소들에서 식별된다. 일 실시예에서, S420은 CPE(Common Platform Enumeration)와 같은 표준화된 명명 체계로 소프트웨어 패키지들의 이름들을 나타내는 데이터를 저장하는 하나 이상의 소프트웨어 패키지 저장소들을 검색하도록 구성된 패키지 관리자 또는 다른 프로그램에 쿼리하는 것을 포함할 수 있다. 쿼리하는 것은 소프트웨어 패키지의 토큰화된 이름을 활용할 수 있다.
S430에서, 소프트웨어 패키지는 소프트웨어 패키지 저장소들에 쿼리하여 리턴된 결과들에 기초하여 표준화된 소프트웨어 패키지 이름에 매핑된다. 일 실시예에서, S430은 S420에서 식별된 가능한 표준화된 소프트웨어 패키지 이름들을 토큰화하고 소프트웨어 패키지의 토큰화된 이름을 각각의 토큰화된 가능한 표준화된 소프트웨어 패키지 이름과 비교하는 것을 포함한다. 다른 실시예에서, 토큰화된 이름들의 각 쌍 사이의 유사성 정도를 나타내는 점수가 생성될 수 있으며, 소프트웨어 패키지의 이름과 가장 높은 점수를 갖는 표준화된 소프트웨어 패키지 이름이 적절한 매핑으로 결정된다. 또 다른 실시예에서, 임계값을 초과하는 점수를 갖는 표준화된 소프트웨어 패키지 이름만이 적절한 매핑으로 결정될 수 있다.
제2 서브-프로세스(400-2)에서, S440에서, 소프트웨어 패키지의 알려진 패키지 이름에 기초하여 소프트웨어 패키지에 대한 알려진 취약성이 식별된다. 알려진 취약성은 표준화된 취약성 식별자 포맷의 식별자를 가지며 소프트웨어 패키지에 대한 변경 명령 이력을 분석함으로써 식별될 수 있다. 이러한 표준화된 포맷은 예를 들어 CVE(Common Vulnerabilities and Exposures)일 수 있다.
S450에서, 소프트웨어 패키지의 소스 코드가 분석되어 소프트웨어 패키지의 데이터에 표시된 소프트웨어 패키지의 실제 이름을 식별한다.
S460에서, S440에서 식별된 알려진 취약성과 S450에서 식별된 실제 이름에 기초하여, 소프트웨어 패키지와 표준화된 취약성 식별자 간의 매핑이 생성된다. 일 실시예에서, 맵핑은 NVD(National Vulnerabilities Database)와 같은 표준 데이터베이스로부터 추출될 수 있지만 이에 제한되지 않는다.
도 2로 돌아가서 선택적인 S240에서, 식별된 취약한 소프트웨어 패키지들에 기초하여 종속성 그래프가 생성되거나 업데이트될 수 있다. 종속성 그래프는 소프트웨어 패키지들 간의 종속성을 정의하고, 식별된 취약한 소프트웨어 패키지들을 포함하도록 생성 또는 업데이트된다. 따라서, 종속성 그래프는 취약하지 않은 소프트웨어 패키지들에 의한 취약한 소프트웨어 패키지들에 대한 종속성을 보여준다. 취약한 소프트웨어 패키지들에 대한 이러한 종속성은 취약하지 않은 소프트웨어 패키지들을 이들이 취약한 것으로 역시 간주될 수 있는 문제에 더 취약하게 만들 수 있다. 결과적으로, 종속성 그래프는 이러한 간접적인 취약성, 즉 소프트웨어 패키지 자체의 코드를 분석함으로써 식별될 수 없지만 대신 취약한 소프트웨어 패키지에 종속하는 것에 의해 상속되는 취약성을 보여준다.
S250에서, 식별된 취약한 소프트웨어 패키지들에 기초하여 알림이 생성된다. 알림은 식별된 취약한 소프트웨어 패키지들, 종속성 그래프 등을 나타낼 수 있지만 이에 제한되지 않는다.
도 5는 일 실시예에 따른 취약성 검출기(130)의 예시적인 개략도이다. 취약성 검출기(130)는 메모리(520), 저장 장치(530), 및 네트워크 인터페이스(540)에 연결된 프로세싱 회로(510)를 포함한다. 일 실시예에서, 취약성 검출기(130)의 구성요소들은 버스(550)를 통해 통신적으로 연결될 수 있다.
프로세싱 회로(510)는 하나 이상의 하드웨어 로직 구성요소들 및 및 회로들로서 실현될 수 있다. 예를 들어 그리고 제한 없이, 예시적인 유형들의 사용될 수 있는 하드웨어 로직 구성요소들은 필드 프로그래밍 가능 게이트 어레이(FPGA), 애플리케이션 특정 집적 회로(ASIC), 애플리케이션 특정 표준 제품(ASSP), 시스템-온-어-칩 시스템(SOC), 그래픽 프로세싱 유닛(GPU), 텐서 프로세싱 유닛(TPU), 범용 마이크로 프로세서, 마이크로 컨트롤러, 디지털 신호 프로세서(DSP) 등 또는 계산이나 기타 정보 조작을 수행할 수 있는 임의의 다른 하드웨어 로직 구성요소들을 포함한다.
메모리(520)는 휘발성(예를 들어, 랜덤 액세스 메모리 등), 비-휘발성(예를 들어, 읽기 전용 메모리, 플래시 메모리 등) 또는 이들의 조합일 수 있다.
하나의 구성에서, 본 명세서에 개시된 하나 이상의 실시예들을 구현하기 위한 소프트웨어는 저장 장치(530)에 저장될 수 있다. 다른 구성에서, 메모리(520)는 그러한 소프트웨어를 저장하도록 구성된다. 소프트웨어는 소프트웨어, 펌웨어, 미들웨어, 마이크로코드, 하드웨어 디스크립션 언어 등으로 지칭되는 모든 유형의 명령들을 의미하는 것으로 광범위하게 해석되어야 한다. 명령들은 코드(예를 들어, 소스 코드 포맷, 이진 코드 포맷, 실행 가능 코드 포맷, 또는 임의의 다른 적합한 코드 포맷)를 포함할 수 있다. 명령들은 프로세싱 회로(510)에 의해 실행될 때 프로세싱 회로(510)로 하여금 본 명세서에 기술된 다양한 프로세스들을 수행하게 한다.
저장 장치(530)는 자기 저장 장치, 광학 저장 장치 등일 수 있으며, 예를 들어 플래시 메모리 또는 다른 메모리 기술, 컴팩트 디스크 읽기 전용 메모리(CD-ROM), 디지털 다목적 디스크(DVD), 또는 원하는 정보를 저장하는 데 사용될 수 있는 다른 매체로 구현될 수 있다.
네트워크 인터페이스(540)는 취약성 검출기(130)가 예를 들어 소스 저장소(120), 사용자 디바이스(140), 또는 둘 모두와 통신할 수 있게 한다.
여기에 설명된 실시예들은 도 4에 도시된 특정 아키텍처로 제한되지 않으며, 개시된 실시예들의 범위를 벗어나지 않고 다른 아키텍처들이 동일하게 사용될 수 있음을 이해해야 한다.
여기에 개시된 다양한 실시예들은 하드웨어, 펌웨어, 소프트웨어, 또는 이들의 조합으로 구현될 수 있다. 더욱이, 소프트웨어는 바람직하게는 부품들 또는 특정 디바이스들 및/또는 디바이스들의 조합으로 구성된 컴퓨터 판독 가능한 매체 또는 프로그램 저장 유닛에 유형적으로 구현된 응용 프로그램으로서 구현된다. 애플리케이션 프로그램은 임의의 적합한 아키텍처를 포함하는 기계에 업로드되고 그에 의해 실행될 수 있다. 바람직하게는, 기계는 하나 이상의 중앙 처리 유닛("CPU"), 메모리 및 입력/출력 인터페이스와 같은 하드웨어를 갖는 컴퓨터 플랫폼에서 구현된다. 컴퓨터 플랫폼은 또한 동작 시스템 및 마이크로 명령 코드를 포함할 수 있다. 여기에 설명된 다양한 프로세스들 및 기능들은 컴퓨터 또는 프로세서가 명시적으로 나타나 있는지 여부에 관계없이 CPU에 의해 실행될 수 있는 마이크로 명령 코드의 일부 또는 응용 프로그램의 일부 또는 이들의 조합일 수 있다. 또한, 추가 데이터 저장 유닛 및 프린팅 유닛과 같은 다양한 다른 주변 유닛들이 컴퓨터 플랫폼에 연결될 수 있다. 또한, 비-일시적 컴퓨터 판독 가능한 매체는 일시적인 전파 신호(transitory propagating signal)를 제외한 임의의 컴퓨터 판독 가능한 매체이다.
본 명세서에 기재된 모든 예들 및 조건부 표현은 독자가 개시된 실시예의 원리와 기술을 발전시키는 데 있어 발명자에 의해 기여된 개념을 이해하는 데 도움을 주기 위한 교육적 목적을 위한 것이며, 그와 같이 특정하게 기재된 예들과 조건들에 국한되지 않는 것으로 해석되어야 한다. 더욱이, 개시된 실시예들의 원리, 양태, 및 실시예들을 인용하는 모든 설명들은 물론 그 구체적인 예들은 그 구조적 및 기능적 등가물들을 모두 포함하도록 의도된다. 또한, 그러한 등가물들은 현재 알려진 등가물들뿐만 아니라 미래에 개발될 등가물들, 즉 구조에 관계없이 동일한 기능을 수행하는 모든 요소들을 포함하는 것으로 의도된다.
여기에서 "제1", "제2" 등과 같은 명칭을 사용하는 본 명세서에서의 요소에 대한 어떠한 언급도 일반적으로 해당 요소들의 양이나 순서를 제한하지 않는다는 것을 이해해야 한다. 오히려, 이러한 명칭들은 일반적으로 둘 이상의 요소들 또는 요소의 인스턴스들을 구별하는 편리한 방법으로 여기에서 사용된다. 따라서, 제1 및 제2 요소들에 대한 인용은 단지 2개의 요소들만이 사용될 수 있거나 제1 요소가 어떤 방식으로 제2 요소보다 선행해야 함을 의미하지 않는다. 또한, 달리 명시하지 않는 한 요소들의 세트는 하나 이상의 요소들을 포함한다.
본 명세서에서 사용되는 바와 같이, "적어도 하나"라는 문구는 그와 관련하여 나열된 항목들 중 어떠한 것도 개별적으로 활용될 수 있거나 나열된 항목들 중 둘 이상의 조합이 활용될 수 있음을 의미한다. 예를 들어, 어떤 시스템이 "A, B, 및 C 중 적어도 하나"를 포함하는 것으로 기술되는 경우, 해당 시스템은 A 단독; B 단독; C 단독; 2A; 2B; 2C; 3A; A와 B의 조합; B와 C의 조합; A와 C의 조합; A, B, 및 C의 조합; 2A와 C의 조합; A, 3B, 및 2C의 조합 등을 포함할 수 있다.

Claims (19)

  1. 소프트웨어 패키지들의 취약성(vulnerabilities)을 발견하기 위한 방법에 있어서:
    복수의 소프트웨어 패키지들 중 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지에서 적어도 하나의 잠재적 취약성 소스를 식별하는 단계로서, 각각의 잠재적 취약성 소스는 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 중 하나에 대한 변경인, 상기 적어도 하나의 잠재적 취약성 소스를 식별하는 단계; 및
    적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각의 데이터에 대한 적어도 하나의 취약성 식별 규칙을 선택하고 적용함으로써 복수의 소프트웨어 패키지들의 적어도 하나의 취약성을 식별하는 단계를 포함하며,
    적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각에 대한 적어도 하나의 취약성 식별 규칙은 잠재적으로 취약한 소프트웨어 패키지에 대한 버전 식별자들의 가용성에 기초하여 선택되는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  2. 제1항에 있어서, 패키지 버전이 소프트웨어 패키지에 대해 이용가능할 때 소프트웨어 패키지에 대한 선택된 적어도 하나의 취약성 식별 규칙은 제1 규칙이고, 제1 규칙은 소프트웨어 패키지에 대한 가장 최근 변경 명령에 표시된 버전보다 이전 버전이거나 동일한 버전의 패키지 버전을 갖는 소프트웨어 패키지로 취약성을 정의하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  3. 제2항에 있어서, 릴리스 버전이 소프트웨어 패키지에 대해 이용가능하지만 패키지 버전이 소프트웨어 패키지에 대해 이용가능하지 않을 때 소프트웨어 패키지에 대한 선택된 적어도 하나의 취약성 식별 규칙은 제2 규칙이고, 제2 규칙은 소프트웨어 패키지에 대한 가장 최근 변경 명령의 임계 기간 내에 있지 않은 릴리스 버전을 갖는 소프트웨어 패키지로 취약성을 정의하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  4. 제3항에 있어서, 패키지 버전과 릴리스 버전이 소프트웨어 패키지에 대해 이용가능하지 않을 때 소프트웨어 패키지에 대한 선택된 적어도 하나의 취약성 식별 규칙은 제3 규칙이고, 제3 규칙은 소프트웨어 패키지에 대해 패키지 관리자에 의해 표시된 가장 최근 변경의 임계 기간 내에 있지 않은 생성 시간을 갖는 소프트웨어 패키지로 취약성을 정의하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  5. 제1항에 있어서, 상기 적어도 하나의 잠재적 취약성 소스를 식별하는 단계는: 변경 명령 메시지들을 분석하는 단계, 적어도 하나의 미리 결정된 메시지를 추적하는 단계, 보안 관련 키워드들에 대한 코드 코멘트들을 분석하는 단계, 릴리스 날짜에 대한 릴리스 노트를 분석하는 단계, 및 버전 인디케이터를 업데이트하는 변경 후 발생하는 파일들에 대한 변경들에 기초하여 취약성을 추론하는 단계 중 적어도 하나를 더 포함하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  6. 제1항에 있어서, 복수의 소프트웨어 패키지 저장소들의 각각의 다른 소프트웨어 저장소에 저장된 소프트웨어 패키지들과 비교하여 복수의 소프트웨어 패키지 저장소들 각각에 저장된 소프트웨어 패키지들의 상대적 사용량에 기초하여 복수의 소프트웨어 패키지 저장소들 중에서 적어도 하나의 소프트웨어 패키지 저장소를 선택하는 단계를 더 포함하고,
    상기 복수의 소프트웨어 패키지들은 선택된 적어도 하나의 소프트웨어 패키지 저장소에 저장되는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  7. 제6항에 있어서, 상기 복수의 소프트웨어 패키지 저장소들 중에서 적어도 하나의 소프트웨어 패키지 저장소를 선택하는 단계는:
    복수의 소프트웨어 패키지 저장소들 각각에 대한 소프트웨어 패키지 사용 빈도를 결정하기 위해 사용자 데이터를 분석하는 단계를 더 포함하고,
    적어도 하나의 소프트웨어 패키지 저장소 각각은 복수의 소프트웨어 패키지 저장소들 중에서 가장 높은 소프트웨어 패키지 사용 빈도를 갖는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  8. 제6항에 있어서, 상기 복수의 소프트웨어 패키지 저장소들 중에서 적어도 하나의 소프트웨어 패키지 저장소를 선택하는 단계는:
    패키지 종속성 매니페스트에 대해 복수의 소프트웨어 패키지 저장소들을 재귀적으로 크롤링하는 단계; 및
    복수의 소프트웨어 패키지 저장소들 각각에 대해, 소프트웨어 패키지 저장소에 저장된 각각의 소프트웨어 패키지에 종속하는 소프트웨어 패키지들의 수에 기초하여 소프트웨어 패키지 저장소의 상대적 사용량을 결정하는 단계를 더 포함하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  9. 제1항에 있어서, 적어도 하나의 식별된 취약성은 복수의 소프트웨어 패키지들 중 적어도 하나의 취약한 소프트웨어 패키지와 연관되고,
    상기 방법은 식별된 적어도 하나의 취약성에 기초하여 종속성 그래프를 생성하는 단계를 더 포함하며,
    상기 종속성 그래프는 소프트웨어 패키지들 사이의 복수의 종속성들을 나타내고, 복수의 종속성들은 적어도 하나의 취약한 소프트웨어 패키지에 대한 적어도 하나의 종속성을 포함하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 방법.
  10. 프로세싱 회로로 하여금 프로세스를 실행하게 하는 명령들을 저장한 비-일시적 컴퓨터 판독 가능한 매체로서, 상기 프로세스는:
    복수의 소프트웨어 패키지들 중 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지에서 적어도 하나의 잠재적 취약성 소스를 식별하는 것 - 각각의 잠재적 취약성 소스는 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 중 하나에 대한 변경임 -; 및
    적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각의 데이터에 대한 적어도 하나의 취약성 식별 규칙을 선택하고 적용함으로써 복수의 소프트웨어 패키지들의 적어도 하나의 취약성을 식별하는 것을 포함하고,
    적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각에 대한 적어도 하나의 취약성 식별 규칙은 잠재적으로 취약한 소프트웨어 패키지에 대한 버전 식별자들의 가용성에 기초하여 선택되는, 비-일시적 컴퓨터 판독 가능한 매체.
  11. 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템에 있어서:
    프로세싱 회로; 및
    메모리를 포함하고,
    상기 메모리는 프로세싱 회로에 의해 실행될 때:
    복수의 소프트웨어 패키지들 중 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지에서 적어도 하나의 잠재적 취약성 소스를 식별하고 - 각각의 잠재적 취약성 소스는 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 중 하나에 대한 변경임 -;
    적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각의 데이터에 대한 적어도 하나의 취약성 식별 규칙을 선택하고 적용함으로써 복수의 소프트웨어 패키지들의 적어도 하나의 취약성을 식별하도록 - 적어도 하나의 잠재적으로 취약한 소프트웨어 패키지 각각에 대한 적어도 하나의 취약성 식별 규칙은 잠재적으로 취약한 소프트웨어 패키지에 대한 버전 식별자들의 가용성에 기초하여 선택됨 -, 상기 시스템을 설정하는 명령들을 포함하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  12. 제11항에 있어서, 패키지 버전이 소프트웨어 패키지에 대해 이용가능할 때 소프트웨어 패키지에 대한 선택된 적어도 하나의 취약성 식별 규칙은 제1 규칙이고, 제1 규칙은 소프트웨어 패키지에 대한 가장 최근 변경 명령에 표시된 버전보다 이전 버전이거나 동일한 버전의 패키지 버전을 갖는 소프트웨어 패키지로 취약성을 정의하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  13. 제12항에 있어서, 릴리스 버전이 소프트웨어 패키지에 대해 이용가능하지만 패키지 버전이 소프트웨어 패키지에 대해 이용가능하지 않을 때 소프트웨어 패키지에 대한 선택된 적어도 하나의 취약성 식별 규칙은 제2 규칙이고, 제2 규칙은 소프트웨어 패키지에 대한 가장 최근 변경 명령의 임계 기간 내에 있지 않은 릴리스 버전을 갖는 소프트웨어 패키지로 취약성을 정의하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  14. 제13항에 있어서, 패키지 버전과 릴리스 버전이 소프트웨어 패키지에 대해 이용가능하지 않을 때 소프트웨어 패키지에 대한 선택된 적어도 하나의 취약성 식별 규칙은 제3 규칙이고, 제3 규칙은 소프트웨어 패키지에 대해 패키지 관리자에 의해 표시된 가장 최근 변경의 임계 기간 내에 있지 않은 생성 시간을 갖는 소프트웨어 패키지로 취약성을 정의하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  15. 제11항에 있어서, 상기 시스템은 또한:
    변경 명령 메시지들을 분석하는 것, 적어도 하나의 미리 결정된 메시지를 추적하는 것, 보안 관련 키워드들에 대한 코드 코멘트들을 분석하는 것, 릴리스 날짜에 대한 릴리스 노트를 분석하는 것, 및 버전 인디케이터를 업데이트하는 변경 후 발생하는 파일들에 대한 변경들에 기초하여 취약성을 추론하는 것 중 적어도 하나를 수행하도록 구성되는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  16. 제11항에 있어서, 상기 시스템은 또한:
    복수의 소프트웨어 패키지 저장소들의 각각의 다른 소프트웨어 저장소에 저장된 소프트웨어 패키지들과 비교하여 복수의 소프트웨어 패키지 저장소들 각각에 저장된 소프트웨어 패키지들의 상대적 사용량에 기초하여 복수의 소프트웨어 패키지 저장소들 중에서 적어도 하나의 소프트웨어 패키지 저장소를 선택하도록 구성되고,
    상기 복수의 소프트웨어 패키지들은 선택된 적어도 하나의 소프트웨어 패키지 저장소에 저장되는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  17. 제16항에 있어서, 상기 시스템은 또한:
    복수의 소프트웨어 패키지 저장소들 각각에 대한 소프트웨어 패키지 사용 빈도를 결정하기 위해 사용자 데이터를 분석하도록 구성되고,
    적어도 하나의 소프트웨어 패키지 저장소 각각은 복수의 소프트웨어 패키지 저장소들 중에서 가장 높은 소프트웨어 패키지 사용 빈도를 갖는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  18. 제16항에 있어서, 상기 시스템은 또한:
    패키지 종속성 매니페스트에 대해 복수의 소프트웨어 패키지 저장소들을 재귀적으로 크롤링하고;
    복수의 소프트웨어 패키지 저장소들 각각에 대해, 소프트웨어 패키지 저장소에 저장된 각각의 소프트웨어 패키지에 종속하는 소프트웨어 패키지들의 수에 기초하여 소프트웨어 패키지 저장소의 상대적 사용량을 결정하도록 구성되는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
  19. 제11항에 있어서, 적어도 하나의 식별된 취약성은 복수의 소프트웨어 패키지들 중 적어도 하나의 취약한 소프트웨어 패키지와 연관되고,
    상기 시스템은 또한:
    식별된 적어도 하나의 취약성에 기초하여 종속성 그래프를 생성하도록 구성되고,
    상기 종속성 그래프는 소프트웨어 패키지들 사이의 복수의 종속성들을 나타내고, 복수의 종속성들은 적어도 하나의 취약한 소프트웨어 패키지에 대한 적어도 하나의 종속성을 포함하는, 소프트웨어 패키지들의 취약성을 발견하기 위한 시스템.
KR1020237027297A 2021-01-11 2022-01-06 취약한 소프트웨어 패키지의 선택 및 발견을 위한 시스템및 방법 KR20230130089A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/145,893 US20220222351A1 (en) 2021-01-11 2021-01-11 System and method for selection and discovery of vulnerable software packages
US17/145,893 2021-01-11
PCT/IB2022/050099 WO2022149088A1 (en) 2021-01-11 2022-01-06 System and method for selection and discovery of vulnerable software packages

Publications (1)

Publication Number Publication Date
KR20230130089A true KR20230130089A (ko) 2023-09-11

Family

ID=82322816

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237027297A KR20230130089A (ko) 2021-01-11 2022-01-06 취약한 소프트웨어 패키지의 선택 및 발견을 위한 시스템및 방법

Country Status (6)

Country Link
US (1) US20220222351A1 (ko)
EP (1) EP4275328A4 (ko)
JP (1) JP2024502379A (ko)
KR (1) KR20230130089A (ko)
CN (1) CN116830105A (ko)
WO (1) WO2022149088A1 (ko)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220004643A1 (en) * 2020-07-02 2022-01-06 Cisco Technology, Inc. Automated mapping for identifying known vulnerabilities in software products
US20230036739A1 (en) * 2021-07-28 2023-02-02 Red Hat, Inc. Secure container image builds
US20240045786A1 (en) * 2022-08-04 2024-02-08 Airbiquity Inc. Build system supporting code audits, code verification, and software forensics
US11893120B1 (en) * 2022-09-08 2024-02-06 Soos Llc Apparatus and method for efficient vulnerability detection in dependency trees

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8732294B1 (en) * 2006-05-22 2014-05-20 Cisco Technology, Inc. Method and system for managing configuration management environment
US7984426B2 (en) * 2006-12-28 2011-07-19 Sap Ag Graphical representation of dependencies between changes of source code
US8745612B1 (en) * 2011-01-14 2014-06-03 Google Inc. Secure versioning of software packages
US8473894B2 (en) * 2011-09-13 2013-06-25 Sonatype, Inc. Method and system for monitoring metadata related to software artifacts
US9141378B2 (en) * 2011-09-15 2015-09-22 Sonatype, Inc. Method and system for evaluating a software artifact based on issue tracking and source control information
US8763132B2 (en) * 2012-06-15 2014-06-24 Honeywell International Inc. Open source security monitoring
CN103841155B (zh) * 2012-11-26 2015-12-23 腾讯科技（深圳）有限公司 一种软件下载方法和软件下载装置
US10984322B2 (en) * 2013-04-09 2021-04-20 International Business Machines Corporation Estimating asset sensitivity using information associated with users
US9176729B2 (en) * 2013-10-04 2015-11-03 Avaya Inc. System and method for prioritizing and remediating defect risk in source code
US9575744B2 (en) * 2014-09-26 2017-02-21 Oracle International Corporation Live updating of a shared plugin registry with no service loss for active users
US9535685B1 (en) * 2015-03-24 2017-01-03 EMC IP Holding Company LLC Smartly identifying a version of a software application for installation
US9507946B2 (en) * 2015-04-07 2016-11-29 Bank Of America Corporation Program vulnerability identification
WO2017134665A1 (en) * 2016-02-03 2017-08-10 Cocycles System for organizing, functionality indexing and constructing of a source code search engine and method thereof
US10275601B2 (en) * 2016-06-08 2019-04-30 Veracode, Inc. Flaw attribution and correlation
US10228925B2 (en) * 2016-12-19 2019-03-12 Uptake Technologies, Inc. Systems, devices, and methods for deploying one or more artifacts to a deployment environment
US10339311B2 (en) * 2017-02-17 2019-07-02 Sap Se Anomalous commit detection
US10769250B1 (en) * 2017-10-26 2020-09-08 Amazon Technologies, Inc. Targeted security monitoring using semantic behavioral change analysis
US10372438B2 (en) * 2017-11-17 2019-08-06 International Business Machines Corporation Cognitive installation of software updates based on user context
US20190303579A1 (en) * 2018-04-02 2019-10-03 Ca, Inc. Decentralized, immutable, tamper-evident, directed acyclic graphs documenting software supply-chains with cryptographically signed records of software-development life cycle state and cryptographic digests of executable code
US20190305957A1 (en) * 2018-04-02 2019-10-03 Ca, Inc. Execution smart contracts configured to establish trustworthiness of code before execution
US10977381B2 (en) * 2018-06-28 2021-04-13 Mohammad Mannan Protection system and method against unauthorized data alteration
US20200050431A1 (en) * 2018-08-08 2020-02-13 Microsoft Technology Licensing, Llc Recommending development tool extensions based on usage context telemetry
US11416622B2 (en) * 2018-08-20 2022-08-16 Veracode, Inc. Open source vulnerability prediction with machine learning ensemble
US20200074084A1 (en) * 2018-08-29 2020-03-05 Microsoft Technology Licensing, Llc Privacy-preserving component vulnerability detection and handling
US11336676B2 (en) * 2018-11-13 2022-05-17 Tala Security, Inc. Centralized trust authority for web application components
US11106512B2 (en) * 2018-12-07 2021-08-31 Vmware, Inc. System and method for container provenance tracking
US11386233B2 (en) * 2019-04-30 2022-07-12 JFrog, Ltd. Data bundle generation and deployment
US10999314B2 (en) * 2019-07-19 2021-05-04 JFrog Ltd. Software release tracking and logging
WO2021014326A2 (en) * 2019-07-19 2021-01-28 JFrog Ltd. Software release verification
WO2021019302A1 (en) * 2019-07-31 2021-02-04 JFrog Ltd. Metadata storage architecture and data aggregation
US11455400B2 (en) * 2019-08-22 2022-09-27 Sonatype, Inc. Method, system, and storage medium for security of software components
US20210141632A1 (en) * 2019-11-08 2021-05-13 Salesforce.Com, Inc. Automated software patching for versioned code
US11487641B1 (en) * 2019-11-25 2022-11-01 EMC IP Holding Company LLC Micro services recommendation system for identifying code areas at risk
US11157591B2 (en) * 2019-12-30 2021-10-26 Atlassian Pty Ltd. Asynchronous static analysis system for a collaborative software development environment
US11687335B2 (en) * 2020-04-30 2023-06-27 Oracle International Corporation Software defect prediction model
US11275579B2 (en) * 2020-05-14 2022-03-15 Bank Of America Corporation Discovery and authorization optimization of GIT based repositories
CN111859399A (zh) * 2020-07-29 2020-10-30 网宿科技股份有限公司 一种基于oval的漏洞检测方法及装置
US11860680B2 (en) * 2020-11-24 2024-01-02 JFrog Ltd. Software pipeline and release validation

Also Published As

Publication number Publication date
EP4275328A4 (en) 2024-06-19
CN116830105A (zh) 2023-09-29
WO2022149088A1 (en) 2022-07-14
JP2024502379A (ja) 2024-01-18
EP4275328A1 (en) 2023-11-15
US20220222351A1 (en) 2022-07-14

Similar Documents

Publication Publication Date Title
US9798648B2 (en) Transitive source code violation matching and attribution
US10235141B2 (en) Method and system for providing source code suggestion to a user in real-time
KR20230130089A (ko) 취약한 소프트웨어 패키지의 선택 및 발견을 위한 시스템및 방법
US9330095B2 (en) Method and system for matching unknown software component to known software component
US20210182031A1 (en) Methods and apparatus for automatic detection of software bugs
US8583626B2 (en) Method to detect reference data tables in ETL processes
US10929125B2 (en) Determining provenance of files in source code projects
US9690690B1 (en) Scalable transitive violation matching
US20160132509A1 (en) Complex query handling
US8954376B2 (en) Detecting transcoding tables in extract-transform-load processes
US10203953B2 (en) Identification of duplicate function implementations
CN107784003B (zh) 数据查询异常检测方法、装置、设备及系统
US20210405980A1 (en) Long method autofix engine
CN108427580B (zh) 配置对命名重复的检测方法、存储介质和智能设备
US20240104235A1 (en) Techniques for agentless detection of sensitive data on managed databases
US20230315843A1 (en) Systems and methods for cybersecurity alert deduplication, grouping, and prioritization
Costabello Error-tolerant RDF subgraph matching for adaptive presentation of linked data on mobile
Tukaram Design and development of software tool for code clone search, detection, and analysis
US20230315860A1 (en) Cyber attribution of software containers
US20230100418A1 (en) Metadata-driven data ingestion
US20240134967A1 (en) Systems and methods for contextual alert enrichment in computing infrastructure and remediation thereof
US20230359822A1 (en) Method and system to extract data dependencies for machine learning models
US20220114189A1 (en) Extraction of structured information from unstructured documents
Cheng et al. Revisiting Knowledge-Based Inference of Python Runtime Environments: A Realistic and Adaptive Approach
Grafberger et al. Towards Interactively Improving ML Data Preparation Code via" Shadow Pipelines"