InfoGrab DocsInfoGrab Docs

SBoM 의존성 그래프 수집 개요

요약

이 프로세스는 모든 SBoM::Occurrence 모델이 수집된 후 시작됩니다. 모든 작업은 백그라운드 워커에서 수행되며, 이 워커는 이후 머지 리퀘스트에서 추가될 예정입니다. 의존성 그래프와 관련된 모든 레코드는 sbom_graph_paths 데이터베이스 테이블에 저장되며, 더 쉬운 필터링을 위해 sbom_occurrences 및 projects에 대한 외래 키를 가집니다.

개요#

이 프로세스는 모든 SBoM::Occurrence 모델이 수집된 후 시작됩니다. 수집 작업은 슬라이스 단위로 처리되므로, 슬라이스 단위로 병행 처리하는 것은 까다롭기 때문입니다.

모든 작업은 백그라운드 워커에서 수행되며, 이 워커는 이후 머지 리퀘스트에서 추가될 예정입니다. SBoM 보고서 수집 시간이 늘어나지 않도록 하기 위해서입니다. 즉, SBoM 보고서가 수집된 시점과 의존성 그래프가 업데이트되는 시점 사이에 지연이 발생합니다.

의존성 그래프와 관련된 모든 레코드는 sbom_graph_paths 데이터베이스 테이블에 저장되며, 더 쉬운 필터링을 위해 sbom_occurrencesprojects에 대한 외래 키를 가집니다.

구현 세부 사항#

이 기능은 개발 진행 중이므로 이 문서는 최신 상태가 아닐 수 있습니다.

  • Sbom::Ingestion::IngestReportService는 SBoM 보고서를 처리하는 역할을 합니다.

  • 처리가 완료되면 Sbom::BuildDependencyGraphWorker를 실행하여 의존성 그래프 계산을 백그라운드 워커로 전달합니다.

  • Sbom::BuildDependencyGraph가 실제 무거운 작업을 처리합니다. 해당 클래스는 문서화되어 있으므로 세부 사항은 여기서 생략합니다.

  • SBoM 보고서가 변경되지 않은 경우 의존성 그래프의 계산을 건너뜁니다.

  • Sbom::PathFinder는 타깃 의존성에 도달하는 가능한 모든 경로를 반환합니다. 모노레포에서 작업할 때 (name, version) 쌍만으로는 정밀하지 않기 때문에, 이 클래스는 Sbom::Occurrence를 인수로 받습니다.

세부 사항#

  • 데이터베이스 테이블은 클로저 테이블(closure table)로 설계되었습니다.

  • 데이터베이스 테이블 구조를 확인할 수 있습니다.

  • 의존성이 전이적(transitive)인 경우, 해당 Sbom::Occurrence#ancestors에 항목이 포함됩니다.

  • 의존성이 직접 의존성(direct dependency)인 경우, 해당 Sbom::Occurrence#ancestors에는 {}가 포함됩니다.

  • 의존성은 직접 의존성인 동시에 전이적 의존성일 수 있습니다.

  • 프로젝트 내에 동일한 의존성의 버전이 두 개 이상 존재할 수 있습니다(예: Node에서는 이를 허용함).

  • 모노레포에서처럼 동일한 의존성 버전에 대해 Sbom::Occurrence가 두 개 이상 존재할 수 있습니다. 이러한 Sbom::Occurrence 행은 서로 다른 input_file_pathsource_id를 가져야 합니다(단, 의존성 트리 구축 시 SQL JOIN을 피하기 위해 source_id는 사용하지 않습니다).

SBoM 의존성 그래프 수집 개요

GitLab v19.1
원문 보기
요약

이 프로세스는 모든 SBoM::Occurrence 모델이 수집된 후 시작됩니다. 모든 작업은 백그라운드 워커에서 수행되며, 이 워커는 이후 머지 리퀘스트에서 추가될 예정입니다. 의존성 그래프와 관련된 모든 레코드는 sbom_graph_paths 데이터베이스 테이블에 저장되며, 더 쉬운 필터링을 위해 sbom_occurrences 및 projects에 대한 외래 키를 가집니다.

개요#

이 프로세스는 모든 SBoM::Occurrence 모델이 수집된 후 시작됩니다. 수집 작업은 슬라이스 단위로 처리되므로, 슬라이스 단위로 병행 처리하는 것은 까다롭기 때문입니다.

모든 작업은 백그라운드 워커에서 수행되며, 이 워커는 이후 머지 리퀘스트에서 추가될 예정입니다. SBoM 보고서 수집 시간이 늘어나지 않도록 하기 위해서입니다. 즉, SBoM 보고서가 수집된 시점과 의존성 그래프가 업데이트되는 시점 사이에 지연이 발생합니다.

의존성 그래프와 관련된 모든 레코드는 sbom_graph_paths 데이터베이스 테이블에 저장되며, 더 쉬운 필터링을 위해 sbom_occurrencesprojects에 대한 외래 키를 가집니다.

구현 세부 사항#

이 기능은 개발 진행 중이므로 이 문서는 최신 상태가 아닐 수 있습니다.

  • Sbom::Ingestion::IngestReportService는 SBoM 보고서를 처리하는 역할을 합니다.

  • 처리가 완료되면 Sbom::BuildDependencyGraphWorker를 실행하여 의존성 그래프 계산을 백그라운드 워커로 전달합니다.

  • Sbom::BuildDependencyGraph가 실제 무거운 작업을 처리합니다. 해당 클래스는 문서화되어 있으므로 세부 사항은 여기서 생략합니다.

  • SBoM 보고서가 변경되지 않은 경우 의존성 그래프의 계산을 건너뜁니다.

  • Sbom::PathFinder는 타깃 의존성에 도달하는 가능한 모든 경로를 반환합니다. 모노레포에서 작업할 때 (name, version) 쌍만으로는 정밀하지 않기 때문에, 이 클래스는 Sbom::Occurrence를 인수로 받습니다.

세부 사항#

  • 데이터베이스 테이블은 클로저 테이블(closure table)로 설계되었습니다.

  • 데이터베이스 테이블 구조를 확인할 수 있습니다.

  • 의존성이 전이적(transitive)인 경우, 해당 Sbom::Occurrence#ancestors에 항목이 포함됩니다.

  • 의존성이 직접 의존성(direct dependency)인 경우, 해당 Sbom::Occurrence#ancestors에는 {}가 포함됩니다.

  • 의존성은 직접 의존성인 동시에 전이적 의존성일 수 있습니다.

  • 프로젝트 내에 동일한 의존성의 버전이 두 개 이상 존재할 수 있습니다(예: Node에서는 이를 허용함).

  • 모노레포에서처럼 동일한 의존성 버전에 대해 Sbom::Occurrence가 두 개 이상 존재할 수 있습니다. 이러한 Sbom::Occurrence 행은 서로 다른 input_file_pathsource_id를 가져야 합니다(단, 의존성 트리 구축 시 SQL JOIN을 피하기 위해 source_id는 사용하지 않습니다).