Sec 섹션 분석기 개발

분석기는 CI 파이프라인 컨텍스트 내에서 실행되도록 Docker 이미지로 배포됩니다. 이 가이드는 분석기 전반에 걸친 개발 및 테스트 관행을 설명합니다.

공유 모듈

공통 동작 및 인터페이스를 위해 분석기 간에 공유되는 여러 Go 모듈이 있습니다:

command Go 패키지는 CLI 인터페이스를 구현합니다.
common 프로젝트는 로깅, 인증서 처리 및 디렉터리 검색 기능을 위한 기타 공유 모듈을 제공합니다.
report Go 패키지의 Report 및 Finding 구조체는 JSON 보고서를 직렬화합니다.
template 프로젝트는 새로운 분석기를 위한 스캐폴딩을 제공합니다.

분석기를 사용하는 방법

분석기는 Docker 이미지로 배포됩니다. 예를 들어, 작업 디렉토리를 스캔하기 위해 Semgrep Docker 이미지를 실행하려면:

스캔하려는 소스 코드 디렉토리로 cd 합니다.
docker login registry.gitlab.com을 실행하고 사용자 이름과 함께 개인 또는 프로젝트 액세스 토큰을 read_registry 범위 이상으로 제공합니다.

Docker 이미지를 실행합니다:

docker run \
    --interactive --tty --rm \
    --volume "$PWD":/tmp/app \
    --env CI_PROJECT_DIR=/tmp/app \
    -w /tmp/app \
    registry.gitlab.com/gitlab-org/security-products/analyzers/semgrep:latest /analyzer run

Docker 컨테이너는 분석기 카테고리에 해당하는 보고서 파일 이름으로 마운트된 프로젝트 디렉토리에 보고서를 생성합니다. 예를 들어, SAST는 gl-sast-report.json이라는 이름의 파일을 생성합니다.

분석기 개발

분석기를 업데이트하려면:

Go 소스 코드를 수정합니다.
새로운 Docker 이미지를 빌드합니다.
테스트 프로젝트에서 분석기를 실행합니다.
생성된 보고서를 예상 내용과 비교합니다.

analyzer라는 이름의 Docker 이미지를 생성하는 방법은 다음과 같습니다:

docker build -t analyzer .

예를 들어, Secret Detection을 테스트하려면 다음을 실행합니다:

wget https://gitlab.com/gitlab-org/security-products/ci-templates/-/raw/master/scripts/compare_reports.sh
sh ./compare_reports.sh sd test/fixtures/gl-secret-detection-report.json test/expect/gl-secret-detection-report.json \
| patch -Np1 test/expect/gl-secret-detection-report.json && git commit -m 'Update expectation' test/expect/gl-secret-detection-report.json
rm compare_reports.sh

자신의 환경에 맞게 이진 파일을 사용하여 로컬에서 실행할 수도 있지만 analyze 및 run는 아마도 작동하지 않을 것입니다.

분석기의 런타임 종속성이 누락되기 때문입니다.

다음은 SpotBugs를 기반으로 한 예입니다:

go build -o analyzer
./analyzer search test/fixtures
./analyzer convert test/fixtures/app/spotbugsXml.Xml > ./gl-sast-report.json

실행 기준

SAST 활성화에는 GitLab CI/CD 구성에 미리 정의된 템플릿을 포함해야 합니다.

다음의 독립적인 기준은 프로젝트에서 실행해야 하는 분석기를 결정합니다:

SAST 템플릿은 rules:exists를 사용하여 특정 파일의 존재 여부에 따라 실행될 분석기를 결정합니다. 예를 들어, Brakeman 분석기는 다음과 같은 경우에 실행됩니다 .rb 파일과 Gemfile이 있을 때입니다.
각 분석기는 실제 분석을 수행하기 전에 사용자 정의할 수 있는 일치 인터페이스를 실행합니다. 예를 들어: Flawfinder는 C/C++ 파일을 확인합니다.
일반 파일 확장자에서 실행되는 일부 분석기의 경우 CI/CD 변수를 기반으로 한 체크가 있습니다. 예를 들어: Kubernetes 매니페스트는 YAML로 작성되므로 Kubesec는 SCAN_KUBERNETES_MANIFESTS가 true로 설정된 경우에만 실행됩니다.

1단계는 프로젝트에 적합하지 않은 분석기를 실행함으로써 낭비되는 컴퓨팅 할당량을 방지하는 데 도움을 줍니다.

그러나 기술적 제한으로 인해 대규모 프로젝트에는 사용할 수 없습니다.

따라서 2단계는 불일치하는 분석기가 조기에 종료될 수 있도록 하기 위한 최종 확인 역할을 합니다.

분석기 테스트 방법

의존성 스캐닝 분석기가 테스트 프로젝트를 사용하여 다운스트림 파이프라인 기능을 사용하는 방법에 대한 동영상 안내:

로컬 변경 사항 테스트

분석기용 공유 모듈(예: command 또는 report)에서 로컬 변경 사항을 테스트하려면, go mod replace 지시문을 사용하여 원격에서 태그된 명령의 버전을 사용하는 대신 로컬 변경 사항으로 command를 로드할 수 있습니다. 예를 들어:

go mod edit -replace gitlab.com/gitlab-org/security-products/analyzers/command/v3=/local/path/to/command

또는 go.mod 파일을 수동으로 업데이트하여 동일한 결과를 얻을 수 있습니다:

module gitlab.com/gitlab-org/security-products/analyzers/awesome-analyzer/v2

replace gitlab.com/gitlab-org/security-products/analyzers/command/v3 => /path/to/command

require (
    ...
    gitlab.com/gitlab-org/security-products/analyzers/command/v3 v2.19.0
)

Docker에서 로컬 변경 사항 테스트

go.mod 파일에서 replace를 사용하려면 Docker를 다음과 같이 설정하세요:

command의 내용을 분석기 디렉토리로 복사합니다. cp -r /path/to/command path/to/analyzer/command.
분석기의 Dockerfile에 복사 문을 추가합니다: COPY command /command.
위 단계에서 COPY 문이 가리키는 경로와 일치하도록 replace 문을 업데이트합니다: replace gitlab.com/gitlab-org/security-products/analyzers/command/v3 => /command

분석기 스크립트

analyzer-scripts 리포지토리는 대부분의 분석기와 상호작용할 수 있는 스크립트를 포함하고 있습니다. 이 스크립트는 GitLab CI와 유사한 환경에서 분석기를 빌드, 실행 및 디버그할 수 있게 해주며, 분석기의 변경 사항을 로컬에서 검증하는 데 특히 유용합니다.

추가 정보는 프로젝트 README를 참조하세요.

버전 관리 및 릴리스 프로세스

GitLab 보안 제품은 GitLab의 독립적인 버전 관리 시스템을 사용합니다 MAJOR.MINOR. 모든 제품은 Semantic Versioning의 변형을 사용하며, Docker 이미지로 제공됩니다.

Major는 GitLab의 새로운 주요 릴리스가 있을 때마다 증가하며, 호환되지 않는 변경 사항이 허용되는 경우입니다. Minor는 새로운 기능을 위해 증가하며, Patch는 버그 수정용으로 예약되어 있습니다.

분석기는 다음과 같은 방식으로 Docker 이미지로 릴리스됩니다:

기본 브랜치에 푸시할 때마다 edge 이미지 태그가 덮어씌워집니다.
모든 awesome-feature 브랜치에 푸시할 때마다 해당하는 awesome-feature 이미지 태그가 생성됩니다.
각 Git 태그는 해당하는 Major.Minor.Patch 이미지 태그를 생성합니다. 수동 작업을 통해 해당하는 Major와 latest 이미지 태그를 이 Major.Minor.Patch를 가리키도록 오버라이드할 수 있습니다.

대부분의 경우, MAJOR 이미지를 사용하는 것이 선호되며, 이는 최신 권장 사항이나 도구의 패치로 자동으로 업데이트됩니다.

우리의 포함된 CI 템플릿은 주요 버전으로 고정되지만, 필요 시 사용자는 직접 버전을 오버라이드할 수 있습니다.

새로운 분석기 Docker 이미지를 릴리스하기 위해 두 가지 다른 옵션이 있습니다:

수동 릴리스 프로세스
자동 릴리스 프로세스

다음 다이어그램은 새로운 분석기 버전이 릴리스될 때 생성되는 Docker 태그를 설명합니다:

우리의 지속적인 배포 흐름에 따라, GitLab Rails 애플리케이션과 대응 관계가 없는 새로운 구성 요소는 언제든지 릴리스할 수 있습니다. 구성 요소가 기존 애플리케이션과 통합될 때까지는 우리의 표준 릴리스 주기 및 프로세스에 의해 반복이 차단되어서는 안 됩니다.

수동 릴리스 프로세스

새 분석기를 위한 CHANGELOG.md 항목이 올바른지 확인합니다.
릴리스 소스(일반적으로 master 또는 main 브랜치)가 통과한 파이프라인을 가지고 있는지 확인합니다.
프로젝트 창의 왼쪽 메뉴에서 Deployments 메뉴를 선택한 다음, Releases 하위 메뉴를 선택하여 분석기 프로젝트의 새 릴리스를 생성합니다.
New release를 선택하여 New Release 페이지를 엽니다.
1. Tag name 드롭다운에서 CHANGELOG.md에서 사용된 것과 동일한 버전을 입력합니다. 예: v2.4.2, 그리고 태그를 생성하는 옵션을 선택합니다(Create tag v2.4.2).
2. Release title 텍스트 박스에 위에서 사용한 것과 동일한 버전을 입력합니다. 예: v2.4.2.
3. Release notes 텍스트 박스에 CHANGELOG.md의 해당 버전에서 메모를 복사하여 붙여넣습니다.
4. 다른 모든 설정은 기본값으로 둡니다.
5. Create release를 선택합니다.

위의 프로세스를 따른 후 새 릴리스를 생성하면, 위에서 제공한 Tag name으로 새로운 Git 태그가 생성됩니다. 이는 주어진 태그 버전으로 새로운 파이프라인을 트리거하고 새로운 분석기 Docker 이미지가 빌드됩니다.

분석기가 analyzer.yml 템플릿을 사용하는 경우, 위의 New release 프로세스의 일환으로 트리거된 파이프라인은 자동으로 새로운 분석기 Docker 이미지의 태깅 및 배포를 수행합니다.

분석기가 analyzer.yml 템플릿을 사용하지 않는 경우, 새로운 버전의 분석기 Docker 이미지를 수동으로 태깅하고 배포해야 합니다:

프로젝트 창의 왼쪽 메뉴에서 CI/CD 메뉴를 선택한 다음, Pipelines 하위 메뉴를 선택합니다.
새 파이프라인이 현재 이전에 사용한 것과 동일한 태그로 실행 중이어야 합니다. 예: v2.4.2.
파이프라인이 완료되면, blocked 상태가 될 것입니다.
창의 오른쪽에 있는 Manual job 재생 버튼을 선택하고 tag version을 선택하여 새로운 버전의 분석기 Docker 이미지를 태그하고 배포합니다.

Git 태그를 생성할 시점을 결정하기 위해 최선을 다하세요. 이는 이후 릴리스 작업을 트리거합니다.

결정을 내릴 수 없다면, 다른 사람의 의견을 요청하세요.

자동 릴리스 프로세스

자동 릴리스 프로세스를 사용하기 전에 다음을 수행해야 합니다:

CREATE_GIT_TAG: true를 CI/CD 환경 변수로 구성합니다.
CI/CD 프로젝트 설정의 Variables를 확인합니다. 프로젝트 그룹에서 GITLAB_TOKEN 환경 변수를 이미 상속받지 않는 한, API에 대한 전체 읽기/쓰기 액세스를 가진 프로젝트 액세스 토큰을 만들고 이 토큰을 참조하는 GITLAB_TOKEN을 CI/CD 환경 변수로 구성합니다.

위의 단계가 완료되면 자동 릴리스 프로세스는 다음과 같이 실행됩니다:

프로젝트 유지 관리자가 MR을 기본 브랜치에 병합합니다.
기본 파이프라인이 트리거되고 upsert git tag 작업이 실행됩니다.
- CHANGELOG.md의 최신 버전이 Git 태그 중 하나와 일치하는 경우, 작업은 수행되지 않습니다.
- 그렇지 않으면, 이 작업은 releases API를 사용하여 새로운 릴리스 및 Git 태그를 자동으로 생성합니다. 버전 및 메시지는 프로젝트의 CHANGELOG.md 파일에서 가장 최근 항목에서 얻습니다.
새로운 Git 태그에 대해 자동으로 파이프라인이 트리거됩니다. 이 파이프라인은 분석기의 latest, major, minor 및 patch Docker 이미지를 릴리스합니다.

분석기를 릴리스한 후 수행할 단계

새로운 버전의 분석기 Docker 이미지가 태깅되고 배포된 후, 해당 테스트 프로젝트와 함께 테스트합니다.
관련 그룹 Slack 채널에 릴리스를 발표합니다. 예시 메시지:

FYI 방금 ANALYZER_NAME ANALYZER_VERSION를 릴리스했습니다. LINK_TO_RELEASE

푸시된 Git 태그는 삭제하지 마세요. 태그가 사용되거나 Go 패키지 레지스트리에 의해 캐시될 가능성이 높습니다.

중요한 수정사항이나 패치를 백포트하는 방법

이전 버전에 중요한 수정사항이나 패치를 백포트하려면 아래 단계를 따르십시오.

수정 사항을 백포트할 태그에서 새로운 브랜치를 생성합니다. 브랜치가 존재하지 않는 경우.
- 예를 들어 최신 안정적인 태그가 v4이고 v3에 수정 사항을 백포트하는 경우 v3라는 새로운 브랜치를 만듭니다.
방금 생성한 브랜치를 대상으로 하는 병합 요청을 제출합니다.
승인된 후, 병합 요청을 브랜치에 병합합니다.
브랜치에 대한 새로운 태그를 생성합니다.
분석기에 자동 릴리스 프로세스가 활성화되어 있으면 새로운 버전이 릴리스됩니다.
그렇지 않으면 수동 릴리스 프로세스를 따라 새로운 버전을 릴리스해야 합니다.
주의: 릴리스 파이프라인은 최신 edge 태그를 덮어쓰므로 최신 릴리스 파이프라인의 tag edge 작업을 다시 실행해야 할 수 있습니다.

새로운 분석기 개발

우리는 가끔 새로운 프레임워크와 도구를 지원하기 위해 새로운 분석기 프로젝트를 구축해야 합니다.
그 과정에서 우리의 엔지니어링 오픈 소스 가이드라인을 따라야 하며, 여기에는 라이센스 및 코드 표준이 포함됩니다.

또한 GitLab 애플리케이션에 통합될 사용자 지정 분석기를 작성하려면 최소 기능 세트가 필요합니다:

체크리스트

기본 도구가 다음을 갖추고 있는지 확인하십시오:

허용된 소프트웨어 라이센스.
헤드리스 실행(CLI 도구).
GitLab Runner의 Linux 또는 Windows Docker 실행기를 사용하여 실행되도록 패키지화할 수 있는 종속성.
파일 이름이나 확장을 기준으로 감지할 수 있는 호환 가능한 프로젝트.
오프라인 실행(인터넷 액세스 없음) 또는 사용자 지정 프록시 및/또는 CA 인증서를 사용하는 것으로 구성할 수 있습니다.

Dockerfile

Dockerfile은 GitLab이라는 이름의 비권한 사용자(unprivileged user)를 사용해야 합니다. 이는 Red Hat OpenShift 인스턴스와의 호환성을 제공하기 위해 필요합니다. OpenShift는 컨테이너를 관리자(root) 사용자로 실행하는 것을 허용하지 않습니다. 비권한 사용자로서 컨테이너를 실행할 때 고려해야 할 특정 제한 사항이 존재하며, Docker 파일 시스템에 기록해야 하는 모든 파일은 GitLab 사용자에게 적절한 권한이 필요합니다. 더 자세한 내용은 다음 병합 요청을 참조하십시오: Docker 이미지에서 root 대신 GitLab 사용자 사용.

최소 취약성 데이터

필요한 필드의 전체 목록은 우리의 보안 보고서 스키마를 참조하십시오.

보안 보고서 스키마 리포지토리에는 각 보고서 유형에 대한 필수 필드를 나열한 JSON 스키마가 포함되어 있습니다:

컨테이너 이미지의 위치

컨테이너 레지스트리에 쓰기 액세스 권한이 있는 사람 수를 제한하기 위해,

모든 이미지는 아래 위치에 게시되어야 합니다. 개발 프로젝트의 컨테이너 레지스트리는 비공개로 설정되어야 합니다.

그룹: https://gitlab.com/security-products/
프로젝트 경로: https://gitlab.com/security-products/<NAME> (예시)
레지스트리 주소: registry.gitlab.com/security-products/<NAME>[/<IMAGE_NAME>]:[TAG]
권한
- 최상위 그룹
  - 유지 관리 관리자: @gitlab-org/secure/managers, @gitlab-org/govern/managers
- 프로젝트 수준
  - read_registry 및 write_registry 액세스 권한이 있는 배포 토큰을 사용하여 이미지를 푸시합니다.
  - 토큰은 생성자가 보호된 및 마스크된 변수로 원래 프로젝트에 입력됩니다 (즉, security-products 네임스페이스 하에 있는 프로젝트).
프로젝트 설정
- 가시성, 프로젝트 기능, 권한.
  - 프로젝트 가시성: 공개. “사용자가 액세스를 요청할 수 있음” 체크 해제.
  - 문제: 비활성화.
  - 리포지토리: “프로젝트 구성원만 가능”으로 설정. 비활성화: 병합 요청, 포크, Git LFS, 패키지, CI/CD.
  - 나머지 항목 비활성화: 분석, 요구 사항, 위키, 스니펫, 페이지, 작업.
- 서비스 데스크: 비활성화.

각 Sec 섹션의 그룹은 다음에 대한 책임이 있습니다:

그들의 아티팩트에 대한 사용 중지 및 제거 일정을 관리하고 이를 위해 문제를 생성합니다.
새 위치에 프로젝트를 생성하고 구성합니다.
새로운 위치에 릴리스 아티팩트를 푸시하도록 빌드를 구성합니다.
자신의 지원 계약에 따라 이전 위치에서 이미지를 제거하거나 유지합니다.

컨테이너 이미지의 일일 재구성

분석기 이미지는 매일 재구성되어 기본 이미지 공급자가 제공하는 패치를 자주 자동으로 가져옵니다.

이 프로세스는 현재 MAJOR 릴리즈와 일치하는 GitLab의 버전에 사용되는 이미지에만 적용됩니다. 매일 새 버전을 릴리스하는 것이 아니라 각 활성 이미지 변형을 재구성하고 해당 태그를 덮어쓰는 것이 목표입니다:

MAJOR.MINOR.PATCH 이미지 태그 (예: 4.1.7)
MAJOR.MINOR 이미지 태그 (예: 4.1)
MAJOR 이미지 태그 (예: 4)
latest 이미지 태그

재구성 프로세스의 구현은 프로젝트에 따라 다를 수 있습니다. 그러나 이를 달성하기 위한 공유 CI 구성이 우리의 개발 ci-templates 프로젝트에서 제공됩니다.

Go의 보안 및 빌드 수정

Go로 구현된 Secure 분석기의 Dockerfile은 Go의 MAJOR 릴리스만 참조해야 하며, MINOR 수정 사항은 참조하지 않아야 합니다.

이것은 분석기를 컴파일하는 데 사용되는 Go의 버전이 특정 시점에서 사용 가능한 모든 보안 수정 사항을 포함하도록 보장합니다.

예를 들어, 분석기 CLI를 빌드하기 위해 분석기의 다중 단계 Dockerfile은 golang:1.15-alpine 이미지를 사용해야 하지만 golang:1.15.4-alpine은 사용하지 않아야 합니다.

MINOR 수정 사항의 Go가 릴리스되고 보안 수정 사항을 포함하는 경우, 프로젝트 유지 관리자는 Secure 분석기를 재구성해야 하는지 확인해야 합니다.

빌드에 사용된 Go의 버전은 릴리스에 해당하는 build 작업의 로그에 표시되어야 하며, Go 바이너리에서 strings 명령을 사용하여 추출할 수 있습니다.

최신 이미지가 영향을 받는 Go 버전으로 빌드되었다면, 다시 빌드해야 합니다.

이미지를 재구성하기 위해 유지 관리자는 다음 중 하나를 수행할 수 있습니다:

안정적인 릴리스에 해당하는 Git 태그에 대한 새 파이프라인 트리거
BUILD 번호가 증가하는 새 Git 태그 만들기
기본 브랜치에 대한 파이프라인 트리거 및 PUBLISH_IMAGES 변수를 비어 있지 않은 값으로 설정

어떤 방법으로든 새 Docker 이미지가 빌드되고 동일한 이미지 태그인 MAJOR.MINOR.PATCH 및 MAJOR와 함께 게시됩니다.

이 워크플로우는 동일한 GO의 MAJOR 릴리스의 MINOR 수정 간의 완전한 호환성을 가정합니다.

호환성 문제가 발생하면 프로젝트 파이프라인이 테스트를 실행할 때 실패합니다. 이 경우 Dockerfile에 MINOR 수정 사항을 참조하고, 호환성 문제가 해결될 때까지 그 예외를 문서화해야 할 수도 있습니다.

Dockerfile에서 참조되지 않으므로, Go의 MINOR 수정 사항은 프로젝트 변경 로그에 언급되지 않습니다.

변경 사항이 빌드 관련하고 변경 로그 항목이 필요하지 않은 경우 빌드 태그를 사용하는 것이 합리적일 수 있습니다. 예를 들어, 새로운 레지스트리 위치에 Docker 이미지를 푸시하는 경우.

Git 태그로 재빌드

분석기를 재빌드하기 위해 새로운 Git 태그를 생성할 때,

새로운 태그는 이전과 동일한 MAJOR.MINOR.PATCH 버전을 가지지만,

BUILD 번호( semver에서 정의된 대로)는 증가합니다.

예를 들어, 분석기의 최신 릴리즈가 v1.2.3이고,

해당 Docker 이미지가 영향을 받은 Go 버전을 사용하여 구축되었다면,

유지관리자는 이미지를 재빌드하기 위해 Git 태그 v1.2.3+1을 생성합니다.

최신 릴리즈가 v1.2.3+1인 경우, 그들은 v1.2.3+2를 생성합니다.

빌드 번호는 이미지 태그에서 자동으로 제거됩니다.

예를 들어, gemnasium 프로젝트에서 Git 태그 v1.2.3+1을 생성하면

파이프라인이 이미지를 재빌드하고 gemnasium:1.2.3으로 푸시합니다.

재빌드를 위해 생성된 Git 태그에는 새로운 빌드가 필요한 이유를 설명하는 간단한 메시지가 있습니다.

예: Go 1.15.6으로 재빌드.

태그에는 릴리즈 노트가 없으며, 릴리즈가 생성되지 않습니다.

분석기를 재빌드하기 위해 새로운 Git 태그를 생성하려면 다음 단계를 따르세요:

새로운 Git 태그를 생성하고 메시지 제공

git tag -a v1.2.3+1 -m "Go 1.15.6으로 재빌드"

태그를 리포지토리에 푸시
```
git push origin --tags
```
Git 태그에 대한 새로운 파이프라인이 트리거되고 새로운 이미지가 빌드되어 태그가 지정됩니다.
master 브랜치에 대해 새로운 파이프라인을 실행하여 전체 테스트 모음을 실행하고 새로운 태그가 지정된 이미지에 대한 새로운 취약점 보고서를 생성합니다. 이는 단계 3.에서 트리거된 릴리즈 파이프라인이 일부 테스트만 실행하기 때문에 필요합니다. 예를 들어, Container Scanning 분석을 수행하지 않습니다.

월간 릴리즈 프로세스

이 작업은 매월 18일에 수행해야 합니다. 그러나, 이는 부드러운 마감일이며 며칠 후에 수행하는 것도 문제가 없습니다.

우선, 이 리포지토리의 스크립트를 사용하여 릴리즈에 대한 새로운 문제를 생성하십시오: ./scripts/release_issue.rb MAJOR.MINOR.

이 문제는 전체 릴리즈 프로세스를 안내합니다. 일반적으로 다음 작업을 수행해야 합니다:

GitLab 문서에서 지원되는 기술 목록을 확인하세요.
CI 작업 정의가 여전히 정확한지 검토하고, 모든 ENV 변수들이 도구에 따라 docker run 시 Docker 컨테이너로 전달되는지 확인합니다.
필요시, 마지막 Git 태그에 해당하는 파이프라인으로 가서

이 이미지를 빌드하는 수동 작업을 트리거하세요.

파이프라인에서 사용되는 현재 봇 계정
- 계정 이름: @group_2452873_bot
  - 사용 용도: 릴리즈/태그 생성을 위해 사용
  - 소속: 그룹 gitlab-org/security-products
  - 최대 역할: Developer
  - 관련된 GITLAB_TOKEN의 범위:
  - 관련된 GITLAB_TOKEN의 만료일:

종속성 업데이트

분석기 소스에서 사용되는 모든 종속성 및 업스트림 스캐너(있는 경우)는 주로 보안 수정 및 비파괴적인 변경 사항을 포함하여 월간 주기로 업데이트됩니다.

정적 분석 팀은 모든 SAST 분석기의 종속성 관리를 자동화하기 위해 사용자 정의 내부 도구 (SastBot)를 사용합니다. SastBot은 매월 8일에 MR을 생성하고 이를 정적 분석 팀원들에게 배포하여 검토를 진행하도록 합니다. 프로세스에 대한 자세한 내용은 Dependency Update Automation을 참조하세요.

On this page