InfoGrab Docs

애플리케이션 보안 트러블슈팅

요약

애플리케이션 보안 기능을 사용할 때 다음 문제가 발생할 수 있습니다. GitLab 애널라이저가 출력하는 로그의 상세도는 SECURE_LOG_LEVEL 환경 변수로 결정됩니다. 심각도 높은 순서에서 낮은 순서로 로깅 수준은 다음과 같습니다:

애플리케이션 보안 기능을 사용할 때 다음 문제가 발생할 수 있습니다.

로깅 수준#

GitLab 애널라이저가 출력하는 로그의 상세도는 SECURE_LOG_LEVEL 환경 변수로 결정됩니다. 이 로깅 수준 이상의 메시지가 출력됩니다.

심각도 높은 순서에서 낮은 순서로 로깅 수준은 다음과 같습니다:

  • fatal
  • error
  • warn
  • info (기본값)
  • debug

디버그 수준 로깅 켜기#

Warning

디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 출력에 작업에서 사용 가능한 환경 변수 및 기타 시크릿의 내용이 포함될 수 있습니다. 출력은 GitLab 서버에 업로드되며 작업 로그에 표시됩니다.

사전 요구 사항:

  • 프로젝트에 대한 Maintainer 또는 Owner 역할.

디버그 수준 로깅을 활성화하려면 .gitlab-ci.yml 파일에 다음을 추가하세요:

variables:
  SECURE_LOG_LEVEL: "debug"

이는 모든 GitLab 애널라이저에게 모든 메시지를 출력하도록 지시합니다. 자세한 내용은 로깅 수준을 참조하세요.

종료 코드 1로 실패하는 Secure 작업#

Secure 작업이 실패하는데 이유가 불분명한 경우:

  1. 디버그 수준 로깅을 활성화합니다.
  2. 작업을 실행합니다.
  3. 작업의 출력을 검토합니다.
  4. debug 로그 수준을 제거하여 기본 info 값으로 돌아갑니다.

오래된 보안 보고서#

머지 리퀘스트에 대해 생성된 보안 보고서가 오래되면, 머지 리퀘스트는 보안 위젯에 경고 메시지를 표시하고 적절한 조치를 취하도록 요청합니다.

이는 두 가지 시나리오에서 발생할 수 있습니다:

소스 브랜치가 대상 브랜치 뒤에 있는 경우#

대상 브랜치와 소스 브랜치 사이의 가장 최근 공통 조상 커밋이 대상 브랜치의 가장 최근 커밋이 아닌 경우 보안 보고서가 오래될 수 있습니다.

이 문제를 해결하려면 대상 브랜치의 변경 사항을 포함하도록 리베이스하거나 병합하세요.

대상 브랜치 보안 보고서가 오래된 경우#

이는 실패한 작업 또는 새로운 어드바이저리를 포함한 많은 이유로 발생할 수 있습니다. 머지 리퀘스트에서 보안 보고서가 오래되었다고 표시되면 대상 브랜치에서 새 파이프라인을 실행해야 합니다. 새 파이프라인을 선택하여 새 파이프라인을 실행하세요.

… report.json: no matching files 경고 메시지 발생#

Warning

디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 출력에 작업에서 사용 가능한 환경 변수 및 기타 시크릿의 내용이 포함될 수 있습니다. 출력은 GitLab 서버에 업로드되며 작업 로그에 표시됩니다.

이 메시지는 종종 오류 No files to upload가 뒤따르며, JSON 보고서가 생성되지 않은 이유를 나타내는 다른 오류나 경고가 앞에 나타납니다. 이러한 메시지가 있는지 전체 작업 로그를 확인하세요. 이러한 메시지를 찾지 못하면, SECURE_LOG_LEVEL: "debug"를 사용자 정의 CI/CD 변수로 설정한 후 실패한 작업을 다시 시도하세요. 이렇게 하면 추가 조사를 위한 추가 정보가 제공됩니다.

sast job: config key may not be used with 'rules': only/except 오류 메시지 발생#

SAST.gitlab-ci.yml과 같은 .gitlab-ci.yml 템플릿을 포함할 때, GitLab CI/CD 구성에 따라 다음 오류가 발생할 수 있습니다:

Unable to run pipeline

    jobs:sast config key may not be used with `rules`: only/except

이 오류는 포함된 작업의 rules 구성이 더 이상 사용되지 않는 only 또는 except 구문으로 재정의된 경우에 나타납니다. 이 문제를 해결하려면 다음 중 하나를 수행해야 합니다:

자세한 내용은 SAST 작업 재정의를 참조하세요.

only/except 구문을 rules로 전환#

작업 실행을 제어하기 위해 템플릿을 재정의할 때, 이전 only 또는 except 인스턴스는 더 이상 호환되지 않으며 rules 구문으로 전환해야 합니다.

작업이 main에서만 실행되도록 제한하는 것을 목표로 하는 재정의의 경우, 이전 구문은 다음과 유사합니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is only executed on main or merge requests
spotbugs-sast:
  only:
    refs:
      - main
      - merge_requests

이전 구성을 새 rules 구문으로 전환하려면, 재정의는 다음과 같이 작성됩니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is only executed on main or merge requests
spotbugs-sast:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_MERGE_REQUEST_ID

태그가 아닌 브랜치에서만 작업이 실행되도록 제한하는 것을 목표로 하는 재정의의 경우, 다음과 유사합니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is not executed on tags
spotbugs-sast:
  except:
    - tags

새 rules 구문으로 전환하려면, 재정의는 다음과 같이 다시 작성됩니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is not executed on tags
spotbugs-sast:
  rules:
    - if: $CI_COMMIT_TAG == null

자세한 내용은 rules를 참조하세요.

더 이상 사용되지 않는 버전으로 템플릿 고정#

최신 지원을 보장하려면 rules로 마이그레이션하세요.

CI/CD 구성을 즉시 업데이트할 수 없는 경우, 이전 템플릿 버전으로 고정하는 몇 가지 해결 방법이 있습니다. 예를 들어:

include:
  remote: 'https://gitlab.com/gitlab-org/gitlab/-/raw/12-10-stable-ee/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml'

또한 버전별 레거시 템플릿이 포함된 전용 프로젝트를 사용할 수 있습니다. 이는 오프라인 설정이나 Auto DevOps 사용을 원하는 분들을 위해 사용할 수 있습니다.

지침은 레거시 템플릿 프로젝트에서 확인할 수 있습니다.

취약점이 발견되었지만 작업이 성공합니다. 파이프라인을 대신 실패시키려면 어떻게 해야 하나요?#

이러한 상황에서 작업이 성공하는 것은 기본 동작입니다. 작업 상태는 애널라이저 자체의 성공 또는 실패를 나타냅니다. 애널라이저 결과는 작업 로그, 머지 리퀘스트 위젯 또는 보안 대시보드에 표시됩니다.

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

Security/Dependency-Scanning.gitlab-ci.yml 및 Security/SAST.gitlab-ci.yml 템플릿에 GitLab 13.4에서 변경된 사항으로 인해, rules 속성을 설정하여 sast 또는 dependency_scanning 작업을 활성화하면 (job) is used for configuration only, and its script should not be executed 오류로 실패합니다.

sast 또는 dependency_scanning 스탠자는 variables 변경 또는 stage 변경과 같이 모든 SAST 또는 의존성 스캔에 변경을 가하는 데 사용할 수 있지만, 공유 rules를 정의하는 데는 사용할 수 없습니다.

확장성 개선을 위한 이슈가 열려 있습니다. 우선순위 지정에 도움이 되도록 이슈에 찬성 투표를 할 수 있으며, 기여를 환영합니다.

빈 취약점 보고서, 의존성 목록 페이지#

파이프라인에 allow_failure: false 옵션이 있는 작업의 수동 단계가 있고 이 작업이 완료되지 않은 경우, GitLab은 보안 보고서의 데이터로 나열된 페이지를 채울 수 없습니다. 이 경우 취약점 보고서와 의존성 목록 페이지가 비어 있습니다. 이러한 보안 페이지는 파이프라인의 수동 단계에서 작업을 실행하여 채울 수 있습니다.

이 시나리오를 처리하기 위한 이슈가 열려 있습니다. 우선순위 지정에 도움이 되도록 이슈에 찬성 투표를 할 수 있으며, 기여를 환영합니다.

애플리케이션 보안 트러블슈팅

Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

애플리케이션 보안 기능을 사용할 때 다음 문제가 발생할 수 있습니다. GitLab 애널라이저가 출력하는 로그의 상세도는 SECURE_LOG_LEVEL 환경 변수로 결정됩니다. 심각도 높은 순서에서 낮은 순서로 로깅 수준은 다음과 같습니다:

애플리케이션 보안 기능을 사용할 때 다음 문제가 발생할 수 있습니다.

로깅 수준#

GitLab 애널라이저가 출력하는 로그의 상세도는 SECURE_LOG_LEVEL 환경 변수로 결정됩니다. 이 로깅 수준 이상의 메시지가 출력됩니다.

심각도 높은 순서에서 낮은 순서로 로깅 수준은 다음과 같습니다:

  • fatal
  • error
  • warn
  • info (기본값)
  • debug

디버그 수준 로깅 켜기#

Warning

디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 출력에 작업에서 사용 가능한 환경 변수 및 기타 시크릿의 내용이 포함될 수 있습니다. 출력은 GitLab 서버에 업로드되며 작업 로그에 표시됩니다.

사전 요구 사항:

  • 프로젝트에 대한 Maintainer 또는 Owner 역할.

디버그 수준 로깅을 활성화하려면 .gitlab-ci.yml 파일에 다음을 추가하세요:

variables:
  SECURE_LOG_LEVEL: "debug"

이는 모든 GitLab 애널라이저에게 모든 메시지를 출력하도록 지시합니다. 자세한 내용은 로깅 수준을 참조하세요.

종료 코드 1로 실패하는 Secure 작업#

Secure 작업이 실패하는데 이유가 불분명한 경우:

  1. 디버그 수준 로깅을 활성화합니다.
  2. 작업을 실행합니다.
  3. 작업의 출력을 검토합니다.
  4. debug 로그 수준을 제거하여 기본 info 값으로 돌아갑니다.

오래된 보안 보고서#

머지 리퀘스트에 대해 생성된 보안 보고서가 오래되면, 머지 리퀘스트는 보안 위젯에 경고 메시지를 표시하고 적절한 조치를 취하도록 요청합니다.

이는 두 가지 시나리오에서 발생할 수 있습니다:

소스 브랜치가 대상 브랜치 뒤에 있는 경우#

대상 브랜치와 소스 브랜치 사이의 가장 최근 공통 조상 커밋이 대상 브랜치의 가장 최근 커밋이 아닌 경우 보안 보고서가 오래될 수 있습니다.

이 문제를 해결하려면 대상 브랜치의 변경 사항을 포함하도록 리베이스하거나 병합하세요.

대상 브랜치 보안 보고서가 오래된 경우#

이는 실패한 작업 또는 새로운 어드바이저리를 포함한 많은 이유로 발생할 수 있습니다. 머지 리퀘스트에서 보안 보고서가 오래되었다고 표시되면 대상 브랜치에서 새 파이프라인을 실행해야 합니다. 새 파이프라인을 선택하여 새 파이프라인을 실행하세요.

… report.json: no matching files 경고 메시지 발생#

Warning

디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 출력에 작업에서 사용 가능한 환경 변수 및 기타 시크릿의 내용이 포함될 수 있습니다. 출력은 GitLab 서버에 업로드되며 작업 로그에 표시됩니다.

이 메시지는 종종 오류 No files to upload가 뒤따르며, JSON 보고서가 생성되지 않은 이유를 나타내는 다른 오류나 경고가 앞에 나타납니다. 이러한 메시지가 있는지 전체 작업 로그를 확인하세요. 이러한 메시지를 찾지 못하면, SECURE_LOG_LEVEL: "debug"를 사용자 정의 CI/CD 변수로 설정한 후 실패한 작업을 다시 시도하세요. 이렇게 하면 추가 조사를 위한 추가 정보가 제공됩니다.

sast job: config key may not be used with 'rules': only/except 오류 메시지 발생#

SAST.gitlab-ci.yml과 같은 .gitlab-ci.yml 템플릿을 포함할 때, GitLab CI/CD 구성에 따라 다음 오류가 발생할 수 있습니다:

Unable to run pipeline

    jobs:sast config key may not be used with `rules`: only/except

이 오류는 포함된 작업의 rules 구성이 더 이상 사용되지 않는 only 또는 except 구문으로 재정의된 경우에 나타납니다. 이 문제를 해결하려면 다음 중 하나를 수행해야 합니다:

자세한 내용은 SAST 작업 재정의를 참조하세요.

only/except 구문을 rules로 전환#

작업 실행을 제어하기 위해 템플릿을 재정의할 때, 이전 only 또는 except 인스턴스는 더 이상 호환되지 않으며 rules 구문으로 전환해야 합니다.

작업이 main에서만 실행되도록 제한하는 것을 목표로 하는 재정의의 경우, 이전 구문은 다음과 유사합니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is only executed on main or merge requests
spotbugs-sast:
  only:
    refs:
      - main
      - merge_requests

이전 구성을 새 rules 구문으로 전환하려면, 재정의는 다음과 같이 작성됩니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is only executed on main or merge requests
spotbugs-sast:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_MERGE_REQUEST_ID

태그가 아닌 브랜치에서만 작업이 실행되도록 제한하는 것을 목표로 하는 재정의의 경우, 다음과 유사합니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is not executed on tags
spotbugs-sast:
  except:
    - tags

새 rules 구문으로 전환하려면, 재정의는 다음과 같이 다시 작성됩니다:

include:
  - template: Jobs/SAST.gitlab-ci.yml

# Ensure that the scanning is not executed on tags
spotbugs-sast:
  rules:
    - if: $CI_COMMIT_TAG == null

자세한 내용은 rules를 참조하세요.

더 이상 사용되지 않는 버전으로 템플릿 고정#

최신 지원을 보장하려면 rules로 마이그레이션하세요.

CI/CD 구성을 즉시 업데이트할 수 없는 경우, 이전 템플릿 버전으로 고정하는 몇 가지 해결 방법이 있습니다. 예를 들어:

include:
  remote: 'https://gitlab.com/gitlab-org/gitlab/-/raw/12-10-stable-ee/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml'

또한 버전별 레거시 템플릿이 포함된 전용 프로젝트를 사용할 수 있습니다. 이는 오프라인 설정이나 Auto DevOps 사용을 원하는 분들을 위해 사용할 수 있습니다.

지침은 레거시 템플릿 프로젝트에서 확인할 수 있습니다.

취약점이 발견되었지만 작업이 성공합니다. 파이프라인을 대신 실패시키려면 어떻게 해야 하나요?#

이러한 상황에서 작업이 성공하는 것은 기본 동작입니다. 작업 상태는 애널라이저 자체의 성공 또는 실패를 나타냅니다. 애널라이저 결과는 작업 로그, 머지 리퀘스트 위젯 또는 보안 대시보드에 표시됩니다.

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

Security/Dependency-Scanning.gitlab-ci.yml 및 Security/SAST.gitlab-ci.yml 템플릿에 GitLab 13.4에서 변경된 사항으로 인해, rules 속성을 설정하여 sast 또는 dependency_scanning 작업을 활성화하면 (job) is used for configuration only, and its script should not be executed 오류로 실패합니다.

sast 또는 dependency_scanning 스탠자는 variables 변경 또는 stage 변경과 같이 모든 SAST 또는 의존성 스캔에 변경을 가하는 데 사용할 수 있지만, 공유 rules를 정의하는 데는 사용할 수 없습니다.

확장성 개선을 위한 이슈가 열려 있습니다. 우선순위 지정에 도움이 되도록 이슈에 찬성 투표를 할 수 있으며, 기여를 환영합니다.

빈 취약점 보고서, 의존성 목록 페이지#

파이프라인에 allow_failure: false 옵션이 있는 작업의 수동 단계가 있고 이 작업이 완료되지 않은 경우, GitLab은 보안 보고서의 데이터로 나열된 페이지를 채울 수 없습니다. 이 경우 취약점 보고서와 의존성 목록 페이지가 비어 있습니다. 이러한 보안 페이지는 파이프라인의 수동 단계에서 작업을 실행하여 채울 수 있습니다.

이 시나리오를 처리하기 위한 이슈가 열려 있습니다. 우선순위 지정에 도움이 되도록 이슈에 찬성 투표를 할 수 있으며, 기여를 환영합니다.