종속성 스캐닝을 사용할 때 다음과 같은 문제가 발생할 수 있습니다.

디버그 수준 로깅#

디버그 수준 로깅은 문제 해결 시 유용합니다. 자세한 내용은 디버그 수준 로깅을 참조하세요.

로컬 환경에서 분석기 실행#

파이프라인을 실행하지 않고 로컬에서 종속성 스캐닝 분석기를 실행하여 문제를 디버깅하거나 동작을 확인할 수 있습니다.

예를 들어, Python 분석기를 실행하려면 다음 명령을 사용합니다.

cd project-git-repository

docker run \
   --interactive --tty --rm \
   --volume "$PWD":/tmp/app \
   --env CI_PROJECT_DIR=/tmp/app \
   --env SECURE_LOG_LEVEL=debug \
   -w /tmp/app \
   registry.gitlab.com/security-products/gemnasium-python:5 /analyzer run

이 명령은 디버그 수준 로깅으로 분석기를 실행하고 로컬 리포지터리를 마운트하여 의존성을 분석합니다. registry.gitlab.com/security-products/gemnasium-python:5를 프로젝트 언어와 의존성 관리자에 맞는 스캐너 image:tag 조합으로 교체할 수 있습니다.

특정 언어 또는 패키지 관리자 미지원 문제 우회#

지원되는 언어에 명시된 것처럼 일부 의존성 정의 파일은 아직 지원되지 않습니다. 그러나 해당 언어, 패키지 관리자 또는 서드파티 도구를 사용하여 정의 파일을 지원되는 형식으로 변환할 수 있다면 종속성 스캐닝을 수행할 수 있습니다.

일반적인 접근 방식은 다음과 같습니다.

• .gitlab-ci.yml 파일에 전용 변환 job을 정의합니다. 적합한 Docker 이미지, 스크립트 또는 둘 다를 사용하여 변환을 수행합니다.

• 해당 job이 변환된 지원 파일을 아티팩트로 업로드하도록 설정합니다.

• 변환된 정의 파일을 사용하기 위해 dependency_scanning job에 dependencies: [<your-converter-job>]를 추가합니다.

예를 들어, pyproject.toml 파일만 있는 Poetry 프로젝트는 다음과 같이 poetry.lock 파일을 생성할 수 있습니다.

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

stages:
  - test

gemnasium-python-dependency_scanning:
  # Work around https://gitlab.com/gitlab-org/gitlab/-/issues/32774
  before_script:
    - pip install "poetry>=1,<2"  # Or via another method: https://python-poetry.org/docs/#installation
    - poetry update --lock # Generates the lockfile to be analyzed.

종속성 스캐닝 job이 예상치 않게 실행됨#

종속성 스캐닝 CI 템플릿은 rules:exists 구문을 사용합니다. 이 지시문은 최대 10000번의 검사로 제한되며, 이 횟수에 도달하면 항상 true를 반환합니다. 이로 인해 리포지터리의 파일 수에 따라 스캐너가 프로젝트를 지원하지 않더라도 종속성 스캐닝 job이 트리거될 수 있습니다. 이 제한에 대한 자세한 내용은 rules:exists 문서를 참조하세요.

오류: dependency_scanning is used for configuration only, and its script should not be executed#

자세한 내용은 애플리케이션 보안 테스팅 문제 해결을 참조하세요.

Java 기반 프로젝트에 여러 인증서 가져오기#

gemnasium-maven 분석기는 keytool을 사용하여 ADDITIONAL_CA_CERT_BUNDLE 변수의 내용을 읽으며, 단일 인증서 또는 인증서 체인을 가져옵니다. 연관되지 않은 여러 인증서는 무시되고 첫 번째 인증서만 keytool로 가져옵니다.

분석기에 연관되지 않은 여러 인증서를 추가하려면 gemnasium-maven-dependency_scanning job 정의에 다음과 같은 before_script를 선언할 수 있습니다.

gemnasium-maven-dependency_scanning:
  before_script:
    - . $HOME/.bashrc # make the java tools available to the script
    - OIFS="$IFS"; IFS=""; echo $ADDITIONAL_CA_CERT_BUNDLE > multi.pem; IFS="$OIFS" # write ADDITIONAL_CA_CERT_BUNDLE variable to a PEM file
    - csplit -z --digits=2 --prefix=cert multi.pem "/-----END CERTIFICATE-----/+1" "{*}" # split the file into individual certificates
    - for i in `ls cert*`; do keytool -v -importcert -alias "custom-cert-$i" -file $i -trustcacerts -noprompt -storepass changeit -keystore /opt/asdf/installs/java/adoptopenjdk-11.0.7+10.1/lib/security/cacerts 1>/dev/null 2>&1 || true; done # import each certificate using keytool (note the keystore location is related to the Java version being used and should be changed accordingly for other versions)
    - unset ADDITIONAL_CA_CERT_BUNDLE # unset the variable so that the analyzer doesn't duplicate the import

종속성 스캐닝 job이 "strconv.ParseUint: parsing "0.0": invalid syntax" 메시지와 함께 실패함#

Docker-in-Docker는 지원되지 않으며, 이를 호출하려는 시도가 이 오류의 원인일 가능성이 높습니다.

이 오류를 수정하려면 종속성 스캐닝에서 Docker-in-Docker를 비활성화하세요. CI/CD 파이프라인에서 실행되는 각 분석기에 대해 개별 <analyzer-name>-dependency_scanning job이 생성됩니다.

include:
  - template: Dependency-Scanning.gitlab-ci.yml

variables:
  DS_DISABLE_DIND: "true"

메시지: <file>이 <commit SHA>에 존재하지 않음#

파일에 있는 의존성의 Location이 표시될 때 링크의 경로는 특정 Git SHA로 이동합니다.

그러나 종속성 스캐닝 도구가 검토한 lockfile이 캐시된 경우, 해당 링크를 선택하면 <file> does not exist in <commit SHA> 메시지와 함께 리포지터리 루트로 리다이렉트됩니다.

lockfile은 빌드 단계에서 캐시되어 스캔이 시작되기 전에 종속성 스캐닝 job에 전달됩니다. 캐시가 분석기 실행 전에 다운로드되므로, CI_BUILDS_DIR 디렉터리에 lockfile이 존재하면 종속성 스캐닝 job이 트리거됩니다.

이 경고를 방지하려면 lockfile을 커밋해야 합니다.

DS_MAJOR_VERSION 또는 DS_ANALYZER_IMAGE를 설정한 후 최신 Docker 이미지를 더 이상 받지 못함#

특정 이유로 DS_MAJOR_VERSION 또는 DS_ANALYZER_IMAGE를 수동으로 설정했고, 이제 분석기의 최신 패치 버전을 다시 받기 위해 구성을 업데이트해야 하는 경우, .gitlab-ci.yml 파일을 편집하여 다음 중 하나를 수행하세요.

• DS_MAJOR_VERSION을 종속성 스캐닝 템플릿에서 참조된 버전과 일치하도록 설정합니다.

• DS_ANALYZER_IMAGE 변수를 직접 하드코딩한 경우, 종속성 스캐닝 템플릿에서 최신 라인과 일치하도록 변경합니다. 줄 번호는 편집한 스캐닝 job에 따라 다릅니다.

예를 들어, gemnasium-maven-dependency_scanning job은 DS_ANALYZER_IMAGE가 "$SECURE_ANALYZERS_PREFIX/gemnasium-maven:$DS_MAJOR_VERSION"으로 설정되어 있으므로 최신 gemnasium-maven Docker 이미지를 가져옵니다.

setuptools 프로젝트의 종속성 스캐닝이 use_2to3 is invalid 오류와 함께 실패함#

2to3 지원은 setuptools 버전 v58.0.0에서 제거되었습니다. 종속성 스캐닝(python 3.9 실행)은 2to3을 지원하지 않는 setuptools 버전 58.1.0+를 사용합니다. 따라서 lib2to3에 의존하는 setuptools 의존성은 다음 메시지와 함께 실패합니다.

error in <dependency name> setup command: use_2to3 is invalid

이 오류를 우회하려면 분석기의 setuptools 버전을 다운그레이드하세요(예: v57.5.0).

gemnasium-python-dependency_scanning:
  before_script:
    - pip install setuptools==57.5.0

psycopg2를 사용하는 프로젝트의 종속성 스캐닝이 pg_config executable not found 오류와 함께 실패함#

psycopg2에 의존하는 Python 프로젝트를 스캔하면 다음 메시지와 함께 실패할 수 있습니다.

Error: pg_config executable not found.

psycopg2는 gemnasium-python Docker 이미지에 설치되지 않은 libpq-dev Debian 패키지에 의존합니다. 이 오류를 우회하려면 before_script에서 libpq-dev 패키지를 설치하세요.

gemnasium-python-dependency_scanning:
  before_script:
    - apt-get update && apt-get install -y libpq-dev

CI_JOB_TOKEN으로 poetry config http-basic 사용 시 NoSuchOptionException 오류#

이 오류는 자동 생성된 CI_JOB_TOKEN이 하이픈(-)으로 시작할 때 발생할 수 있습니다. 이 오류를 방지하려면 Poetry의 구성 권장 사항을 따르세요.

오류: project has unresolved dependencies#

다음 오류 메시지는 build.gradle 또는 build.gradle.kts 파일로 인한 Gradle 의존성 해결 문제를 나타냅니다.

• Project has <number> unresolved dependencies (GitLab 16.7 ~ 16.9)

• project has unresolved dependencies: ["dependency_name:version"] (GitLab 17.0 이상)

GitLab 16.7 ~ 16.9에서는 gemnasium-maven이 미해결 의존성을 만나면 처리를 계속할 수 없습니다.

GitLab 17.0 이상에서 gemnasium-maven은 미해결 의존성 처리 방식을 제어하는 데 사용할 수 있는 DS_GRADLE_RESOLUTION_POLICY 환경 변수를 지원합니다. 기본적으로 미해결 의존성이 발견되면 스캔이 실패합니다. 그러나 환경 변수 DS_GRADLE_RESOLUTION_POLICY를 "none"으로 설정하면 스캔을 계속 진행하여 부분적인 결과를 생성할 수 있습니다.

build.gradle 파일 수정에 대한 지침은 Gradle 의존성 해결 문서를 참조하세요. 자세한 내용은 이슈 482650을 참조하세요.

또한 Kotlin 2.0.0에 의존성 해결에 영향을 미치는 알려진 문제가 있으며, Kotlin 2.0.20에서 수정될 예정입니다. 자세한 내용은 이 이슈를 참조하세요.

Go 프로젝트 스캔 시 빌드 제약 조건 설정#

종속성 스캐닝은 linux/amd64 컨테이너에서 실행됩니다. 따라서 Go 프로젝트에 대해 생성된 빌드 목록에는 이 환경과 호환되는 의존성이 포함됩니다. 배포 환경이 linux/amd64가 아닌 경우, 최종 의존성 목록에 추가적으로 호환되지 않는 모듈이 포함될 수 있습니다. 또한 배포 환경에서만 호환되는 모듈이 목록에서 누락될 수도 있습니다. 이 문제를 방지하려면 .gitlab-ci.yml 파일의 GOOS 및 GOARCH 환경 변수를 설정하여 빌드 프로세스가 배포 환경의 운영 체제와 아키텍처를 타깃으로 하도록 구성할 수 있습니다.

예를 들어:

variables:
  GOOS: "darwin"
  GOARCH: "arm64"

GOFLAGS 변수를 사용하여 빌드 태그 제약 조건을 제공할 수도 있습니다.

variables:
  GOFLAGS: "-tags=test_feature"

Go 프로젝트의 종속성 스캐닝에서 거짓 양성 반환#

go.sum 파일에는 프로젝트의 빌드 목록을 생성하는 동안 고려된 모든 모듈의 항목이 포함됩니다. go.sum 파일에는 모듈의 여러 버전이 포함되지만, go build가 사용하는 MVS 알고리즘은 하나만 선택합니다. 따라서 종속성 스캐닝이 go.sum을 사용하면 거짓 양성이 보고될 수 있습니다.

거짓 양성을 방지하기 위해 Gemnasium은 Go 프로젝트의 빌드 목록을 생성할 수 없는 경우에만 go.sum을 사용합니다. go.sum이 선택되면 다음 경고가 발생합니다.

[WARN] [Gemnasium] [2022-09-14T20:59:38Z] ▶ Selecting "go.sum" parser for "/test-projects/gitlab-shell/go.sum". False positives may occur. See https://gitlab.com/gitlab-org/gitlab/-/issues/321081.

SSH 사용 시 호스트 키 인증 실패#

모든 gemnasium 이미지에 openssh-client를 설치한 후 ssh를 사용하면 Host key verification failed 메시지가 나타날 수 있습니다. 이미지를 빌드할 때 $HOME이 /tmp로 설정되어 있어 설정 중에 사용자 디렉터리를 표현하기 위해 ~를 사용하는 경우 이 문제가 발생할 수 있습니다. 이 문제는 gemnasium-python 이미지를 사용할 때 SSH로 프로젝트 클론 실패에 설명되어 있습니다. openssh-client는 /root/.ssh/known_hosts를 찾을 것으로 예상하지만 이 경로가 존재하지 않으며, 대신 /tmp/.ssh/known_hosts가 존재합니다.

이 문제는 openssh-client가 사전 설치된 gemnasium-python에서는 해결되었지만, 다른 이미지에 openssh-client를 처음부터 설치할 때 발생할 수 있습니다. 이를 해결하려면 다음 중 하나를 선택하세요.

• 키와 호스트를 설정할 때 절대 경로(~/.ssh/known_hosts 대신 /root/.ssh/known_hosts)를 사용합니다.

• 관련 known_hosts 파일을 지정하는 UserKnownHostsFile을 ssh 구성에 추가합니다. 예: echo 'UserKnownHostsFile /tmp/.ssh/known_hosts' >> /etc/ssh/ssh_config.

오류: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE#

이 오류는 requirements.txt 파일에 있는 패키지의 해시가 다운로드된 패키지의 해시와 일치하지 않을 때 발생합니다. 보안 조치로 pip는 패키지가 변조되었다고 간주하여 설치를 거부합니다. 이를 해결하려면 요구 사항 파일에 포함된 해시가 올바른지 확인하세요. pip-compile로 생성된 요구 사항 파일의 경우, pip-compile --generate-hashes를 실행하여 해시가 최신 상태인지 확인하세요. pipenv로 생성된 Pipfile.lock을 사용하는 경우, pipenv verify를 실행하여 lockfile에 최신 패키지 해시가 포함되어 있는지 확인하세요.

오류: In --require-hashes mode, all requirements must have their versions pinned with ==#

이 오류는 요구 사항 파일이 GitLab Runner가 사용하는 것과 다른 플랫폼에서 생성된 경우 발생합니다. 다른 플랫폼을 타깃으로 하는 지원 여부는 이슈 416376에서 추적하고 있습니다.

편집 가능 플래그로 인해 Python 종속성 스캐닝이 중단될 수 있음#

requirements.txt 파일에서 현재 디렉터리를 타깃으로 하는 -e/--editable 플래그를 사용하면, Gemnasium Python 종속성 스캐너가 pip3 download를 실행할 때 중단되는 문제가 발생할 수 있습니다. 이 명령은 타깃 프로젝트를 빌드하는 데 필요합니다.

이 문제를 해결하려면 Python 종속성 스캐닝을 실행할 때 -e/--editable 플래그를 사용하지 마세요.

SBT를 사용한 메모리 부족 오류 처리#

Scala 프로젝트에서 종속성 스캐닝을 사용하는 동안 SBT에서 메모리 부족 오류가 발생하면, SBT_CLI_OPTS 환경 변수를 설정하여 해결할 수 있습니다. 구성 예시는 다음과 같습니다.

variables:
  SBT_CLI_OPTS: "-J-Xmx8192m -J-Xms4192m -J-Xss2M"

쿠버네티스 실행기를 사용하는 경우 기본 쿠버네티스 리소스 설정을 재정의해야 할 수 있습니다. 메모리 문제를 방지하기 위한 컨테이너 리소스 조정 방법은 쿠버네티스 실행기 문서를 참조하세요.

NPM 프로젝트에 package-lock.json 파일이 없음#

기본적으로 종속성 스캐닝 job은 리포지터리에 package-lock.json 파일이 있을 때만 실행됩니다. 그러나 일부 NPM 프로젝트는 package-lock.json 파일을 Git 리포지터리에 저장하는 대신 빌드 과정에서 생성합니다.

이러한 프로젝트에서 의존성을 스캔하려면 다음을 수행하세요.

• 빌드 job에서 package-lock.json 파일을 생성합니다.

• 생성된 파일을 아티팩트로 저장합니다.

• 아티팩트를 사용하고 규칙을 조정하도록 종속성 스캐닝 job을 수정합니다.

예를 들어, 구성은 다음과 같을 수 있습니다.

include:
  - template: Dependency-Scanning.gitlab-ci.yml

build:
  script:
    - npm i
  artifacts:
    paths:
      - package-lock.json  # Store the generated package-lock.json as an artifact

gemnasium-dependency_scanning:
  needs: ["build"]
  rules:
    - if: "$DEPENDENCY_SCANNING_DISABLED == 'true' || $DEPENDENCY_SCANNING_DISABLED == '1'"
      when: never
    - if: "$DS_EXCLUDED_ANALYZERS =~ /gemnasium([^-]|$)/"
      when: never
    - if: $CI_COMMIT_BRANCH && $GITLAB_FEATURES =~ /\bdependency_scanning\b/ && $CI_GITLAB_FIPS_MODE == "true"
      variables:
        DS_IMAGE_SUFFIX: "-fips"
        DS_REMEDIATE: 'false'
    - if: "$CI_COMMIT_BRANCH && $GITLAB_FEATURES =~ /\\bdependency_scanning\\b/"

파이프라인에 종속성 스캐닝 job이 추가되지 않음#

종속성 스캐닝 job은 규칙을 사용하여 의존성이 있는 lockfile이나 빌드 도구 관련 파일이 존재하는지 확인합니다. 이러한 파일이 감지되지 않으면 lockfile이 파이프라인의 다른 job에서 생성되더라도 job이 파이프라인에 추가되지 않습니다.

이 상황이 발생하면 리포지터리에 지원되는 파일이 있거나 런타임에 지원되는 파일이 생성됨을 나타내는 파일이 있는지 확인하세요. 종속성 스캐닝 job을 트리거하기 위해 이러한 파일을 리포지터리에 추가할 수 있는지 고려해 보세요.

리포지터리에 이러한 파일이 있다고 생각되는데도 job이 트리거되지 않는 경우, 다음 정보를 포함하여 이슈를 등록하세요.

• 사용하는 언어와 빌드 도구.

• 제공하는 lockfile의 종류와 생성 위치.

종속성 스캐닝 템플릿에 직접 기여할 수도 있습니다.

gradlew: permission denied와 함께 종속성 스캐닝 실패#

gradlew에서 permission denied 오류는 일반적으로 gradlew가 실행 비트 없이 리포지터리에 체크인된 경우에 발생합니다. job에서 다음 메시지와 함께 오류가 나타날 수 있습니다.

[FATA] [gemnasium-maven] [2024-11-14T21:55:59Z] [/go/src/app/cmd/gemnasium-maven/main.go:65] ▶ fork/exec /builds/path/to/gradlew: permission denied

로컬에서 chmod +ux gradlew를 실행하여 파일을 실행 가능하게 만들고 Git 리포지터리에 푸시하세요.

지원되지 않는 Gradle 버전으로 인한 종속성 스캐닝 nebula lock 생성 실패#

지원되지 않는 Gradle 버전(9.0 이상)으로 dependency.lockfiles를 생성하려고 하면 다음 오류가 발생합니다.

FAILURE: Build failed with an exception.
* Where:
Initialization script '/builds/gitlab-org/app/app/nebula.gradle' line: 11
* What went wrong:
Failed to notify build listener.
> org/gradle/util/NameMatcher

Gradle 빌드를 Gradle 8.10.2로 다운그레이드해 보세요.

종속성 스캐닝 스캐너가 더 이상 Gemnasium이 아님#

기존에는 종속성 스캐닝에 사용되는 스캐너가 Gemnasium이었으며 사용자는 취약점 페이지에서 이를 확인할 수 있었습니다.

SBOM을 사용한 종속성 스캐닝이 출시되면서 Gemnasium 스캐너는 내장 GitLab SBoM Vulnerability Scanner로 교체되었습니다. 이 새 스캐너는 더 이상 CI/CD job에서 실행되지 않고 GitLab 플랫폼 내에서 실행됩니다. 두 스캐너는 동일한 결과를 제공할 것으로 예상되지만, SBOM 스캔이 기존 종속성 스캐닝 CI/CD job 이후에 발생하므로 기존 취약점은 새 GitLab SBoM Vulnerability Scanner로 스캐너 값이 업데이트됩니다.

GitLab SBoM Vulnerability Scanner는 GitLab 내장 종속성 스캐닝 기능에서 유일하게 기대되는 값입니다.

최신 SBOM을 기반으로 프로젝트 의존성 목록이 업데이트되지 않음#

파이프라인에 SBOM을 생성하는 job이 실패하면 DeleteNotPresentOccurrencesService가 실행되지 않아 의존성 목록이 변경되거나 업데이트되지 않습니다. SBOM을 업로드하는 다른 성공적인 job이 있고 파이프라인이 전반적으로 성공한 경우에도 이 현상이 발생할 수 있습니다. 이는 관련 보안 스캐닝 job이 실패할 때 의존성 목록에서 의존성이 실수로 제거되는 것을 방지하기 위해 설계된 것입니다. 프로젝트 의존성 목록이 예상대로 업데이트되지 않는 경우, 파이프라인에서 실패한 SBOM 관련 job을 확인하고 수정하거나 제거하세요.

종속성 스캐닝이 "open /etc/ssl/certs/ca-certificates.crt: permission denied"와 함께 실패함#

이 오류는 일반적으로 컨테이너를 실행하는 사용자가 root 그룹에 속하지 않음을 나타냅니다. id를 실행하여 사용자가 해당 그룹에 속해 있는지 확인하세요.

$ id
uid=1000(node) gid=0(root) groups=0(root),1000(node)

OpenShift를 실행하거나 쿠버네티스 실행기를 사용하는 경우, 그룹 ID(GID) 0을 사용하여 실행기가 실행되도록 구성하세요.

[[runners]]
[runners.kubernetes]
    [runners.kubernetes.pod_security_context]
    run_as_non_root = true
    run_as_group = 0

커스텀 또는 병합된 CycloneDX SBOM에서 취약점 스캐닝 결과 없음#

종속성 스캐닝 CI/CD job은 성공하고 SBOM 컴포넌트가 의존성 목록에 나타나지만, 파이프라인 보안 탭에 취약점이 보고되지 않습니다.

GitLab 18.10 이상에서는 보안 탭에 다음 메시지가 표시됩니다: "SBOM report is missing required GitLab metadata properties needed for vulnerability scanning."

이 문제는 SBOM에 필요한 GitLab CycloneDX 속성이 누락된 경우에 발생합니다. 이러한 속성이 없으면 취약점 스캐너가 SBOM 컴포넌트에 대한 결과를 생성할 수 없습니다. 의존성 목록은 채워지지만 취약점은 보고되지 않습니다.

이 문제는 다음과 같은 경우에 일반적으로 발생합니다.

• cyclonedx merge를 사용하여 여러 SBOM을 병합하면 메타데이터 속성이 제거됩니다.

• 서드파티 SBOM 생성기에 GitLab 전용 속성이 포함되지 않습니다.

• gitlab:meta:schema_version 속성(반드시 1이어야 함)이 metadata.properties에 없습니다.

취약점 스캐닝에 필요한 속성#

이 문제를 해결하려면 다음 방법 중 하나를 선택하세요.

• 각 SBOM을 개별적으로 업로드합니다.

  병합하는 대신 각 SBOM을 별도의 artifacts: reports: cyclonedx: 항목으로 업로드합니다. 이렇게 하면 각 파일의 GitLab 전용 속성이 유지됩니다.

• 서드파티 SBOM에 속성을 추가합니다.

  서드파티 도구로 생성된 SBOM에는 일반적으로 GitLab 전용 속성이 포함되지 않습니다. 취약점 스캐닝을 활성화하려면 SBOM의 metadata.properties에 다음이 포함되어 있는지 확인하세요.

  gitlab:meta:schema_version을 1로 설정합니다.

  • gitlab:dependency_scanning:input_file:path를 lockfile의 리포지터리 상대 경로로 설정합니다 (예: package-lock.json 또는 src/Gemfile.lock).

  SBOM에 여러 lockfile의 컴포넌트가 포함된 경우, 각 컴포넌트가 올바른 소스 파일을 가리키도록 메타데이터가 아닌 각 컴포넌트의 properties 배열에 input_file:path를 설정하세요. 지원되는 속성의 전체 목록은 GitLab CycloneDX 속성 분류를 참조하세요.

자세한 내용은 이슈 542813과 머지 리퀘스트 221549를 참조하세요.

취약점 스캐닝에서 모든 의존성에 잘못된 입력 파일이 표시됨#

취약점 보고서 또는 의존성 목록에 있는 모든 의존성이 다른 lockfile에서 비롯된 것임에도 동일한 입력 파일 경로를 표시합니다.

이 문제는 gitlab:dependency_scanning:input_file:path 속성이 컴포넌트별이 아닌 metadata.properties에 설정된 경우 발생합니다. 속성 분류에 따르면, 메타데이터 수준의 속성은 문서의 모든 객체에 적용되므로 단일 값이 모든 컴포넌트를 재정의합니다.

이 문제를 해결하려면 최상위 메타데이터가 아닌 각 컴포넌트의 properties 배열에 개별적으로 input_file:path를 설정하세요. input_file:path 속성은 다른 lockfile의 컴포넌트를 포함하는 병합된 SBOM에 특히 중요합니다.

오류: node with package name <package_name> does not exist#

이 문제는 패키지 관리자(일반적으로 nuget)가 패키지를 찾을 수 없을 때 발생합니다. 애플리케이션을 빌드하는 데 사용된 이미지와 종속성 스캔을 실행하는 데 사용된 이미지가 다를 때 발생할 수 있습니다.

이 문제를 해결하려면 종속성 스캐너가 애플리케이션을 빌드하는 데 사용하는 것과 동일한 .NET SDK 이미지를 사용하세요. 다음을 실행하여 정확한 이미지를 찾을 수 있습니다.

curl --silent "https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/raw/master/build/gemnasium/alpine/Dockerfile" | grep "vrange-nuget-build" | grep "FROM"

위에 링크된 Dockerfile에서 현재 이미지 버전을 확인하세요.