코드 검사 구성

4분

GitHub가 프로젝트에서 취약점 및 오류에 대해 코드를 검사하는 방법을 구성할 수 있습니다. 사용자 고유의 구성을 선택하면 시간을 절약하고 프로젝트에 대한 코드 검사의 가장 적합한 빈도를 결정합니다. 이 단원에서는 코드 검사 구성의 기본 사항에 대해 알아봅니다. 또한 검사 빈도를 구성하고 리포지토리 및 개발 요구 사항에 가장 잘 맞게 일정을 정하는 방법을 알아봅니다.

이전 단원에서 설명한 것처럼 GitHub에서 GitHub Actions를 사용하거나 CI(연속 통합) 시스템에서 코드 검사를 실행할 수 있습니다. GitHub에서 고급 설정 옵션을 선택하면 사용자 지정 가능한 워크플로 파일이 생성되어 리포지토리에 직접 커밋할 수 있습니다. 일반적으로 이 워크플로를 편집할 필요가 없습니다. 그러나 필요한 경우 일부 설정을 사용자 지정할 수 있습니다.

예를 들어 GitHub CodeQL 분석 워크플로를 편집하여 검사 빈도, 검사할 언어 또는 디렉터리 및 코드에서 검사할 CodeQL 코드 검사를 지정할 수 있습니다. 특정 명령 집합을 사용하여 코드를 컴파일하는 경우 CodeQL 분석 워크플로를 편집해야 할 수도 있습니다. CodeQL 분석은 GitHub에서 수행할 수 있는 코드 검사의 한 유형일 뿐입니다. GitHub Marketplace에는 몇 가지 다른 코드 검사 워크플로가 포함되어 있습니다.

기본값에서 고급 코드 검사 설정으로 전환

기본 설정 방법을 사용하여 코드 검사를 사용하기 위한 리포지토리 설정이 이미 있는 경우 설정에서 고급 설정을 사용하도록 전환할 수 있습니다. 아래의 코드 > 섹션으로 이동한 다음 세 개의 점 오버플로 아이콘(...)을 선택합니다. 드롭다운에서 고급으로 전환을 선택합니다. 그런 다음, 프롬프트에 따라 CodeQL을 사용하지 않도록 설정하고 고급 설정의 생성된 워크플로 파일을 사용하여 다시 사용하도록 설정합니다.

코드 검사 워크플로 편집

GitHub는 리포지토리의 .github/workflows 디렉터리에 워크플로 파일을 저장합니다. 파일 이름을 검색하여 추가한 워크플로를 찾을 수 있습니다. 예를 들어 기본적으로 CodeQL 코드 검사를 위한 워크플로 파일을 codeql-analysis.yml이라고 합니다.

워크플로 파일을 편집하려면 다음 단계를 수행합니다.

워크플로 편집기를 열려면 파일 보기 오른쪽 상단에 있는 편집 아이콘을 선택합니다.
편집합니다.
파일을 편집한 후 변경 내용 커밋을 선택하고 변경 내용 커밋 양식을 작성합니다. 현재 분기에 직접 커밋하도록 선택하거나 새 분기를 만들고 끌어오기 요청을 시작할 수 있습니다.

몇 가지 일반적인 코드 검사 구성 옵션은 다음 섹션을 검토하세요.

빈도 구성

워크플로 파일에 대한 일반적인 편집은 코드 검사가 발생하는 빈도를 조정하는 것입니다. 일정에 따라 또는 리포지토리에서 특정 이벤트가 발생하는 경우 코드를 검사하도록 CodeQL 분석 워크플로를 구성할 수 있습니다. 워크플로 파일을 편집하여 누군가가 변경 사항을 푸시할 때와 끌어오기 요청을 만들 때마다 코드를 검사할 수도 있습니다. 이 빈도를 조정하면 개발자가 코드에 새로운 취약성과 오류를 도입하는 것을 방지할 수 있습니다. 일정에 따라 코드를 검사하면 GitHub, 보안 연구원 및 커뮤니티가 발견한 최신 취약성과 오류에 대해 알려 줍니다. 개발자가 리포지토리를 적극적으로 유지 관리하지 않는 경우에도 마찬가지입니다.

푸시할 때 검사

기본적으로 CodeQL 분석 워크플로는 on:push 이벤트를 사용하여 리포지토리의 기본 분기 및 보호된 분기에 푸시할 때마다 코드 검사를 트리거합니다. 지정된 분기에서 코드 검사를 트리거하려면 워크플로가 해당 분기에 있어야 합니다. 푸시할 때 검사하면 리포지토리의 보안 탭에 결과가 표시됩니다.

또한 on:push 검사가 열려 있는 끌어오기 요청에 매핑할 수 있는 결과를 반환하면 이러한 경고는 다른 끌어오기 요청 경고와 동일한 위치의 끌어오기 요청에 자동으로 표시됩니다. 경고는 분기 헤드의 기존 분석을 대상 분기에 대한 분석과 비교하여 식별됩니다.

PR에 대해 검사

기본 CodeQL 분석 워크플로는 pull_request 이벤트를 사용하여 기본 분기를 대상으로 하는 끌어오기 요청에 대한 코드 검사를 트리거합니다. 끌어오기 요청이 비공개 포크에서 온 경우 리포지토리 설정에서 "포크 끌어오기 요청에서 워크플로 실행" 옵션을 선택한 경우에만 pull_request 이벤트가 트리거됩니다. 끌어오기 요청을 검사하면 결과가 끌어오기 요청 검사에서 경고로 표시됩니다.

헤드 커밋이 아닌 끌어오기 요청의 병합 커밋을 검색하도록 구성된 pull_request 트리거를 사용하는 경우 각 푸시에서 분기 헤드를 검사하는 것보다 더 효율적이고 정확한 결과를 생성합니다. 그러나 끌어오기 요청에서 트리거하도록 구성할 수 없는 CI/CD 시스템을 사용하는 경우에도 코드 검사가 결과를 분기의 열린 끌어오기 요청에 매핑하고 경고를 끌어오기 요청에 주석으로 추가하도록 on:push 트리거를 계속 사용할 수 있습니다.

끌어오기 요청 확인 실패를 일으키는 심각도 정의

기본적으로 Error 심각도 수준이나 Critical 또는 High 보안 심각도 수준이 있는 경고만 끌어오기 요청 확인 실패를 일으킵니다. 끌어오기 요청 실패는 코드 검색을 중지하지 않고 코드를 병합하려고 할 때 차단기를 나타냅니다. 리포지토리의 보안 탭 아래에 있는 코드 검사 경고 탭에서 끌어오기 요청 실패 목록을 찾을 수 있습니다. 리포지토리 설정에서 끌어오기 요청 확인 실패를 유발하는 경고 심각도 및 보안 심각도 수준을 변경할 수 있습니다.

GitHub.com에서 리포지토리의 기본 페이지로 이동합니다. 리포지토리 이름 아래에서 설정을 선택합니다.
왼쪽 사이드바에서 코드 보안 및 분석을 선택합니다.
보호 규칙 아래의 코드 검사 섹션에서 드롭다운 메뉴를 사용하여 끌어오기 요청 확인 실패를 트리거할 심각도 수준을 선택합니다.

불필요한 끌어오기 요청 검사 방지

변경된 파일에 관계없이 기본 분기를 대상으로 하는 특정 끌어오기 요청에서 코드 검사가 트리거되지 않도록 할 수 있습니다. 코드 검사 워크플로에서 on:pull_request:paths-ignore 또는 on:pull_request:paths를 지정하여 이 설정을 구성할 수 있습니다. 예를 들어, 끌어오기 요청의 유일한 변경 사항이 파일 확장자가 .md 또는 .txt인 파일인 경우 다음 paths-ignore 배열을 사용할 수 있습니다.

on:
   push:
      branches: [main, protected]
   pull_request:
      branches: [main]
      paths-ignore:
         - '**/*.md'
         - '**/*.txt'

검사 일정 조정

기본 CodeQL 분석 워크플로를 사용하는 경우 워크플로는 이벤트에 의해 트리거되는 검사 외에도 임의로 생성된 날짜와 시간에 일주일에 한 번 리포지토리의 코드를 검사합니다. 이 일정을 조정하려면 워크플로의 cron 값을 편집합니다.

다음 예는 main라는 기본 분기와 protected라는 하나의 보호된 분기가 있는 리포지토리에 대한 CodeQL 분석 워크플로를 보여줍니다.

on:
   push:
      branches: [main, protected]
   pull_request:
      branches: [main]
   schedule:
      - cron: '20 14 * * 1'

이 워크플로는 다음을 검사합니다.

기본 분기 및 보호된 분기에 대한 모든 푸시
기본 분기에 대한 모든 끌어오기 요청
매주 월요일 14:20 UTC의 기본 분기

피드백

이 페이지가 도움이 되었나요?