BDBA(Black Duck Binary Analysis) 분류 범위가 오해를 불러일으킴

BDBA(Black Duck Binary Analysis) 분류 범위가 오해를 불러일으킴

Black Duck Binary Analysis(일명 Protecode) 도구에는 취약점 분류를 위한 여러 옵션이 있습니다.

도움말에서:

분류 범위

타사 구성 요소 내에서 분류된 취약성에 범위를 적용할 수 있습니다. 알려진 취약점을 분류할 때 다음 옵션 중에서 선택할 수 있습니다.

계정: 회사 계정 내 모든 컴포넌트 사용에 적용됩니다.

그룹: 그룹 내 구성요소의 모든 용도에 적용됩니다.

애플리케이션: 동일한 애플리케이션 내에서 해당 컴포넌트를 사용하는 경우에만 적용됩니다.

애플리케이션 이름: 동일한 응용 프로그램 이름을 가진 검사된 응용 프로그램 내의 구성 요소 사용에 적용됩니다.

파일 해시: 동일한 파일 해시가 있는 검사된 응용 프로그램 내에서 구성 요소 사용에 적용됩니다.

내가 원하는 것은 라이브러리에서 CVE를 분류하여 분류 결과가 다음 스캔으로 전달되도록 하는 것입니다. "파일 해시" 옵션이 정확히 이 작업을 수행해야 한다고 기대하지만, 다음에 아카이브를 업로드할 때 여전히 분류되지 않은 것과 동일한 CVE가 표시됩니다. 뭐가 문제 야?

답변1

TL;DR - "그룹" 범위를 사용하세요.

세부

API 문서를 통해 좀 더 명확해졌습니다.

PUT /api/triage/vulnerability/

component - Component name
version - Component version
vulns - List of vulnerability ids
scope - Scope in which the triage affects. Possible values:

- CA - Account wide
- FN - Filename
- FH - File hash
- R - Result
- G - Group

product_id - In FN, FH and R scopes the related product

group_id - In G scope the related group

실제로 도구에서 분류가 완료되었습니다.파일에 반대하지 않습니다, 하지만라이브러리 버전 대비(컨텍스트의 라이브러리 === 구성 요소). 버전을 분류하기 때문에 파일을 분류할 이론적인 가능성조차 없습니다. 이것을 염두에두면 나머지 생각은 간단합니다.

그렇다면 "파일 해시"는 무엇입니까?

"FH"를 사용하는 경우 product_id가 필요하며 product는 바이너리와 함께 업로드된 아카이브와 동의어(현재 컨텍스트에서)라는 것이 명확하게 기록되어 있습니다. 따라서 모든 제품에는 업로드된 아카이브의 해시인 "파일 해시"가 하나만 있습니다. 이 옵션을 완전히 쓸모 없게 만드는 이유는 100개의 파일을 별도로 업로드하지 않고 여러 바이너리가 포함된 소프트웨어와 함께 archive\zip\tar.gz를 업로드하기 때문입니다. 그리고 Readme 파일이 변경된 경우에도 아카이브의 해시는 다시 패키징할 때마다 변경됩니다.

내가 원하는 것은 라이브러리에서 CVE를 분류하여 분류 결과가 다음 스캔으로 전달되도록 하는 것입니다.

"파일 해시"는 이 목적에 적합하지 않으므로 사용 가능한 다른 범위 옵션을 살펴보고 여기서 무엇을 할 수 있는지 살펴보겠습니다.

결과

가장 간단하고 기본 옵션입니다. 동시에 가장 쓸모가 없습니다. Application도움말에 언급된 범위 에 직접 매핑됩니다 Applies to uses of the component within the same application only. 즉, 어떤 이월도 없습니다.

파일 이름

저는 개인적으로 Application name도움말의 해당 줄보다 "파일 이름"이 더 명확하다고 생각합니다. 그럼에도 불구하고 이는 매우 명확합니다. 아카이브 이름이 동일한 경우에만 분류가 수행됩니다. 문제가 어떻게든 해결되면 새로운 문제, 즉 다양한 빌드를 차별화하는 문제가 발생합니다. 일반적으로 MyCoolBuild_942_ab4e3f과거 빌드에 대한 결과를 쉽게 찾고 확인할 수 있도록 zip 이름을 다음과 같이 지정합니다 . 신경 쓰지 않는다면 zip 이름을 MyCoolBuild.zip.

그룹

짐작할 수 있듯이 이것은 단지 그룹 전체의 분류입니다. 팀에 자체 그룹이 있는 경우 해당 그룹을 사용할 수 있습니다.

내 경우에는 회사 전체가 하나의 그룹에 파일을 업로드하므로5월그러나 도구 설명서에 따르면 이 라이브러리의 사용자 정의 빌드를 만드는 경우(예를 들어 일부 CVE를 직접 수정하기 위해) 버전 접미사를 사용해야 한다고 나와 있습니다. 모든 사람이 이 규칙을 따르면 사용자 정의 라이브러리의 이름을 지정하지 않지만 1.0.2다른 1.0.2_company_build팀의 분류 간에 충돌이 발생하지 않습니다.

계정

BDBA 인스턴스에는 이 옵션이 없기 때문에 잘 모르겠습니다 -_-

위 가정의 정확성 테스트

위의 모든 내용은 몇 번의 테스트 업로드를 통해 쉽게 확인할 수 있습니다.

파일 해시- 동일한 파일을 다른 이름으로 두 번 업로드하고 "FH" 범위의 CVE를 분류합니다. 그런 다음 분류가 이어집니다.

파일 이름- 아카이브를 한 번 업로드한 후 아카이브를 약간 수정(내부에 빈 텍스트 파일 추가)하고 다시 업로드합니다. 심사는 이월됩니다.

그룹- 버전이 자동 감지된 라이브러리 하나를 업로드한 다음 바이너리를 수정하고 다른 이름으로 업로드합니다. 분류는 계속됩니다.

추가 테스트로 두 개의 라이브러리가 포함된 아카이브를 업로드하고 그 중 하나의 버전을 재정의할 수도 있습니다. 이렇게 하면 UI에서 라이브러리가 분리되고 분리된 분류가 가능해집니다.

관련 정보