DevOps 리소스에 대한 보안 권장 사항
이 문서에서는 환경 설정 페이지를 사용하여 Azure DevOps, GitHub 또는 GitLab 환경을 연결하는 경우 클라우드용 Microsoft Defender 볼 수 있는 권장 사항을 나열합니다. 사용자 환경에 표시되는 권장 사항은 보호 중인 리소스와 사용자 지정된 구성을 기반으로 합니다.
이러한 권장 사항에 대한 응답으로 수행할 수 있는 작업에 대해 알아보려면 클라우드용 Defender 권장 사항 수정을 참조하세요.
DevOps 보안 이점 및 기능에 대해 자세히 알아봅니다.
DevOps 권장 사항은 보안 점수에 영향을 주지 않습니다. 먼저 해결할 권장 사항을 결정하려면 각 권장 사항의 심각도와 보안 점수에 미치는 잠재적 영향을 살펴봅니다.
Azure DevOps 권장 사항
Azure DevOps 리포지토리에는 GHAzDO(Azure DevOps)에 대한 GitHub 고급 보안이 사용하도록 설정되어 있어야 합니다.
설명: 클라우드용 Defender DevOps 보안은 중앙 콘솔을 사용하여 Azure DevOps에서 코드에서 클라우드로 애플리케이션 및 리소스를 보호하는 기능을 통해 보안 팀의 역량을 강화합니다. Azure DevOps용 GitHub Advanced Security를 비롯한 GHAzDO(Azure DevOps) 리포지토리에 대한 GitHub Advanced Security를 사용하도록 설정하면 클라우드용 Microsoft Defender 표시된 Azure DevOps 리포지토리의 비밀, 종속성 및 코드 취약성에 대한 결과를 얻을 수 있습니다.
심각도: 높음
Azure DevOps 리포지토리에는 비밀 검사 결과 확인이 있어야 합니다.
설명: 비밀이 코드 리포지토리에서 발견되었습니다. 보안 위반을 방지하기 위해 즉시 수정합니다. 리포지토리에 있는 비밀은 누출되거나 악의적 사용자가 검색하여 애플리케이션 또는 서비스가 손상될 수 있습니다. Microsoft Security DevOps 자격 증명 검사 도구는 실행되도록 구성된 빌드만 검색합니다. 따라서 결과는 리포지토리에 있는 비밀의 전체 상태를 반영하지 않을 수 있습니다.
심각도: 높음
Azure DevOps 리포지토리에는 코드 검사 결과 해결이 있어야 합니다.
설명: 코드 리포지토리에서 취약성이 발견되었습니다. 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다.
심각도: 보통
Azure DevOps 리포지토리에는 종속성 취약성 검사 결과 해결이 있어야 합니다.
설명: 코드 리포지토리에 있는 종속성 취약성입니다. 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다.
심각도: 보통
코드 검사 결과가 해결되면 Azure DevOps 리포지토리에 인프라가 있어야 합니다.
설명: 리포지토리에 있는 코드 보안 구성 문제로서의 인프라. 템플릿 파일에서 문제가 검색되었습니다. 관련 클라우드 리소스의 보안 상태를 향상시키려면 이러한 문제를 수정하는 것이 좋습니다.
심각도: 보통
Azure DevOps 파이프라인에는 포크 빌드에 사용할 수 있는 비밀이 없어야 합니다.
설명: 공용 리포지토리에서 조직 외부의 사용자가 포크를 만들고 포크된 리포지토리에서 빌드를 실행할 수 있습니다. 이러한 경우 이 설정을 사용하도록 설정하면 외부 사용자가 내부로 의도된 파이프라인 비밀을 빌드하는 데 액세스할 수 있습니다.
심각도: 높음
Azure DevOps 서비스 연결이 모든 파이프라인에 대한 액세스 권한을 부여해서는 안 됩니다.
설명: 서비스 연결은 작업에서 작업을 실행하기 위해 Azure Pipelines에서 외부 및 원격 서비스로의 연결을 만드는 데 사용됩니다. 파이프라인 권한은 서비스 연결을 사용할 권한이 있는 파이프라인을 제어합니다. 파이프라인 작업의 보안을 지원하기 위해 서비스 연결에 모든 YAML 파이프라인에 대한 액세스 권한이 부여되지 않아야 합니다. 이는 공격자가 중요한 리소스에 액세스하여 다른 파이프라인을 공격하는 데 한 파이프라인에서 사용되는 구성 요소의 취약성을 사용할 수 있기 때문에 최소 권한 원칙을 유지하는 데 도움이 됩니다.
심각도: 높음
Azure DevOps 보안 파일은 모든 파이프라인에 대한 액세스 권한을 부여해서는 안 됩니다.
설명: 보안 파일은 개발자에게 파이프라인 간에 공유할 수 있는 파일을 저장할 수 있는 방법을 제공합니다. 이러한 파일은 일반적으로 서명 인증서 및 SSH 키와 같은 비밀을 저장하는 데 사용됩니다. 보안 파일에 모든 YAML 파이프라인에 대한 액세스 권한이 부여된 경우 권한이 없는 사용자는 YAML 파이프라인을 빌드하고 보안 파일에 액세스하여 보안 파일에서 정보를 도용할 수 있습니다.
심각도: 높음
비밀 변수가 있는 Azure DevOps 변수 그룹이 모든 파이프라인에 대한 액세스 권한을 부여해서는 안 됩니다.
설명: 변수 그룹은 YAML 파이프라인에 전달하거나 여러 파이프라인에서 사용할 수 있도록 할 수 있는 값과 비밀을 저장합니다. 동일한 프로젝트의 여러 파이프라인에서 변수 그룹을 공유하고 사용할 수 있습니다. 비밀을 포함하는 변수 그룹이 모든 YAML 파이프라인에서 액세스할 수 있는 것으로 표시되면 공격자는 새 파이프라인을 만들어 비밀 변수와 관련된 자산을 악용할 수 있습니다.
심각도: 높음
Azure DevOps 클래식 Azure 서비스 연결을 사용하여 구독에 액세스하면 안 됩니다.
설명: Azure 클래식 서비스 연결 대신 ARM(Azure Resource Manager) 유형의 서비스 연결을 사용하여 Azure 구독에 연결합니다. ARM 모델은 강력한 액세스 제어, 향상된 감사, ARM 기반 배포/거버넌스, 비밀용 관리 ID 및 키 자격 증명 모음에 대한 액세스, Entra 권한 기반 인증, 간소화된 관리를 위한 태그 및 리소스 그룹 지원 등 여러 가지 보안 향상 기능을 제공합니다.
심각도: 보통
(미리 보기) Azure DevOps 리포지토리에는 API 보안 테스트 결과가 확인되어야 합니다.
설명: 코드 리포지토리에 있는 API 보안 취약성 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다.
심각도: 보통
(미리 보기) Azure DevOps 리포지토리에는 코드 푸시에 대한 최소 2개 검토자 승인이 필요합니다.
설명: 의도하지 않거나 악의적인 변경 내용이 직접 커밋되지 않도록 하려면 Azure DevOps 리포지토리에서 기본 분기 대한 보호 정책을 구현하는 것이 중요합니다. 코드가 기본 분기 병합되기 전에 두 명 이상의 코드 검토자가 끌어오기 요청을 승인하도록 요구하는 것이 좋습니다. 최소 두 명의 검토자의 승인을 요구하면 무단 수정의 위험을 줄일 수 있으며 이로 인해 시스템 불안정 또는 보안 취약성이 발생할 수 있습니다.
이 권장 사항은 Azure DevOps를 클라우드용 Defender 연결한 경우 클라우드용 Defender 기본 보안 태세에서 제공됩니다.
심각도: 높음
(미리 보기) Azure DevOps 리포지토리는 요청자가 자체 끌어오기 요청을 승인하도록 허용해서는 안 됩니다.
설명: 의도하지 않거나 악의적인 변경 내용이 직접 커밋되지 않도록 하려면 Azure DevOps 리포지토리에서 기본 분기 대한 보호 정책을 구현하는 것이 중요합니다. 끌어오기 요청 작성자가 자신의 제출을 승인하지 못하도록 금지하여 모든 변경 내용이 작성자가 아닌 다른 사람이 객관적인 검토를 받도록 하는 것이 좋습니다. 이렇게 하면 무단 수정의 위험을 줄일 수 있으며 이로 인해 시스템 불안정 또는 보안 취약성이 발생할 수 있습니다.
이 권장 사항은 Azure DevOps를 클라우드용 Defender 연결한 경우 클라우드용 Defender 기본 보안 태세에서 제공됩니다.
심각도: 높음
(미리 보기) Azure DevOps 프로젝트에는 클래식 파이프라인 만들기를 사용하지 않도록 설정해야 합니다.
설명: 클래식 빌드 및 릴리스 파이프라인 만들기를 사용하지 않도록 설정하면 동일한 리소스(예: 동일한 서비스 연결)를 공유하는 YAML 및 클래식 파이프라인에서 발생하는 보안 문제가 방지됩니다. 잠재적인 공격자는 클래식 파이프라인을 활용하여 최신 YAML 파이프라인을 중심으로 설정된 일반적인 방어 메커니즘을 회피하는 프로세스를 만들 수 있습니다.
심각도: 높음
GitHub 권장 사항
GitHub 조직은 모든 리포지토리에서 액세스할 수 있는 작업 비밀을 만들지 않아야 함
설명: GitHub 조직 수준에서 저장된 GitHub Action 워크플로에 사용되는 비밀의 경우 액세스 정책을 사용하여 조직 비밀을 사용할 수 있는 리포지토리를 제어할 수 있습니다. 조직 수준 비밀을 통해 여러 리포지토리 간에 비밀을 공유할 수 있습니다. 이렇게 하면 중복된 비밀을 만들 필요가 줄어듭니다. 그러나 리포지토리에서 비밀에 액세스할 수 있게 되면 리포지토리에 대한 쓰기 액세스 권한이 있는 모든 사용자는 워크플로의 모든 분기에서 비밀에 액세스할 수 있습니다. 공격 노출 영역을 줄이려면 선택한 리포지토리에서만 비밀에 액세스할 수 있는지 확인합니다.
이 권장 사항은 Azure DevOps를 클라우드용 Defender 연결한 경우 클라우드용 Defender 기본 보안 태세에서 제공됩니다.
심각도: 높음
GitHub 리포지토리에 비밀 검사를 사용하도록 설정해야 함
설명: GitHub는 리포지토리에 실수로 커밋된 비밀의 사기성 사용을 방지하기 위해 알려진 유형의 비밀을 리포지토리에 검사합니다. 비밀 검사는 GitHub 리포지토리에 있는 모든 분기의 전체 Git 기록에서 비밀을 검사합니다. 비밀의 예로 서비스 공급자가 인증을 위해 발급할 수 있는 토큰과 프라이빗 키가 있습니다. 비밀이 리포지토리에 체크 인되면 리포지토리에 대한 읽기 액세스 권한이 있는 모든 사용자가 비밀을 사용하여 해당 권한으로 외부 서비스에 액세스할 수 있습니다. 비밀은 프로젝트 리포지토리 외부의 안전한 전용 위치에 저장해야 합니다.
심각도: 높음
GitHub 리포지토리에 코드 검색을 사용하도록 설정해야 함
설명: GitHub는 코드 검색을 사용하여 코드에서 보안 취약성 및 오류를 찾기 위해 코드를 분석합니다. 코드 검사는 코드의 기존 문제에 대한 수정을 찾고 심사하고 우선 순위를 지정하는 데 사용할 수 있습니다. 또한 코드 검사는 개발자가 새로운 문제를 도입하지 않도록 방지할 수 있습니다. 검사를 특정 날짜 및 시간에 예약하거나 리포지토리에서 푸시와 같은 특정 이벤트가 발생하는 경우 검사를 트리거할 수 있습니다. 코드 검사에서 코드의 잠재적 취약성 또는 오류를 발견하면 GitHub에서 경고를 리포지토리에 표시합니다. 취약성은 프로젝트의 기밀성, 무결성 또는 가용성을 손상시키기 위해 악용될 수 있는 프로젝트 코드의 문제입니다.
심각도: 보통
Dependabot 검사를 GitHub 리포지토리에 사용하도록 설정해야 함
설명: GitHub는 리포지토리에 영향을 주는 코드 종속성에서 취약성을 검색할 때 Dependabot 경고를 보냅니다. 취약성은 프로젝트 또는 해당 코드를 사용하는 기타 프로젝트의 기밀성, 무결성 또는 가용성을 손상시키기 위해 악용할 수 있는 프로젝트 코드의 문제입니다. 취약성은 공격 유형, 심각도 및 방법에 따라 다릅니다. 코드가 보안 취약성이 있는 패키지에 종속된 경우 이 취약한 종속성은 다양한 문제를 일으킬 수 있습니다.
심각도: 보통
GitHub 리포지토리에 비밀 검사 결과가 확인되어야 합니다.
설명: 코드 리포지토리에 있는 비밀입니다. 이는 보안 위반을 방지하기 위해 즉시 수정해야 합니다. 리포지토리에 있는 비밀은 악의적 사용자가 유출하거나 검색할 수 있습니다. 이로 인해 애플리케이션 또는 서비스가 손상될 수 있습니다.
심각도: 높음
GitHub 리포지토리에는 코드 검사 결과 확인이 있어야 합니다.
설명: 코드 리포지토리에 있는 취약성 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다.
심각도: 보통
GitHub 리포지토리에는 종속성 취약성 검사 결과 해결이 있어야 합니다.
설명: GitHub 리포지토리에는 종속성 취약성 검사 결과 해결이 있어야 합니다.
심각도: 보통
GitHub 리포지토리에는 코드 검사 결과 해결로 인프라가 있어야 합니다.
설명: 코드 보안 구성 문제로서의 인프라가 리포지토리에서 발견되었습니다. 템플릿 파일에서 문제가 검색되었습니다. 관련 클라우드 리소스의 보안 상태를 향상시키려면 이러한 문제를 수정하는 것이 좋습니다.
심각도: 보통
GitHub 리포지토리에는 기본 분기 사용하도록 설정된 보호 정책이 있어야 합니다.
설명: 의도하지 않은/악의적인 변경 내용이 리포지토리에 직접 커밋되지 않도록 하려면 분기 보호 정책을 통해 리포지토리의 기본 분기 보호해야 합니다.
심각도: 높음
GitHub 리포지토리에는 기본 분기 사용할 수 없는 강제 푸시 있어야 합니다.
설명: 기본 분기 일반적으로 배포 및 기타 권한 있는 활동에 사용되므로 변경 내용을 신중하게 접근해야 합니다. 강제 푸시 사용하도록 설정하면 기본 분기 의도하지 않거나 악의적인 변경이 발생할 수 있습니다.
심각도: 보통
GitHub 조직에는 비밀 검사 푸시 보호가 사용하도록 설정되어 있어야 합니다.
설명: 푸시 보호는 비밀이 포함된 커밋을 차단하여 실수로 비밀이 노출되는 것을 방지합니다. 자격 증명 노출의 위험을 방지하려면 모든 비밀 검사 사용 리포지토리에 대해 Push Protection을 자동으로 사용하도록 설정해야 합니다.
심각도: 높음
GitHub 리포지토리는 자체 호스팅 실행기를 사용하면 안 됩니다.
설명: GitHub의 자체 호스팅 실행기는 임시 정리 가상 머신에서 작업을 보장하지 않으며 워크플로의 신뢰할 수 없는 코드에 의해 지속적으로 손상될 수 있습니다. 따라서 자체 호스팅 실행기는 작업 워크플로에 사용해서는 안 됩니다.
심각도: 높음
GitHub 조직에는 작업 워크플로 권한이 읽기 전용으로 설정되어 있어야 합니다.
설명: 기본적으로 작업 워크플로에는 악의적인 사용자가 권한이 부여된 워크플로를 악용하여 리소스에 액세스하고 변조하지 못하도록 읽기 전용 권한이 부여되어야 합니다.
심각도: 높음
GitHub 조직에는 관리자 권한이 있는 사람이 두 명 이상 있어야 합니다.
설명: 관리자가 두 명 이상 있으면 관리자 액세스가 손실될 위험이 줄어듭니다. 이는 중단 계정 시나리오의 경우에 유용합니다.
심각도: 높음
GitHub 조직에는 기본 사용 권한이 사용 권한 또는 읽기 없이 설정되어야 합니다.
설명: 조직이 최소 권한 원칙을 따르고 불필요한 액세스를 방지하려면 기본 권한을 없음으로 설정하거나 읽어야 합니다.
심각도: 높음
(미리 보기) GitHub 리포지토리에는 API 보안 테스트 결과 확인이 있어야 합니다.
설명: API 보안 취약성이 코드 리포지토리에서 발견되었습니다. 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다.
심각도: 보통
(미리 보기) GitHub 조직은 모든 리포지토리에서 작업 비밀에 액세스할 수 있도록 해서는 안 됩니다.
설명: GitHub 조직 수준에서 저장된 GitHub Action 워크플로에 사용되는 비밀의 경우 액세스 정책을 사용하여 조직 비밀을 사용할 수 있는 리포지토리를 제어할 수 있습니다. 조직 수준 비밀을 사용하면 여러 리포지토리 간에 비밀을 공유할 수 있으므로 중복된 비밀을 만들 필요가 줄어듭니다. 그러나 리포지토리에서 비밀에 액세스할 수 있게 되면 리포지토리에 대한 쓰기 액세스 권한이 있는 모든 사용자는 워크플로의 모든 분기에서 비밀에 액세스할 수 있습니다. 공격 노출 영역을 줄이려면 선택한 리포지토리에서만 비밀에 액세스할 수 있는지 확인합니다.
심각도: 높음
(미리 보기) GitHub 조직은 공용 코드와 일치하는 Copilot 제안을 차단해야 합니다.
설명: GitHub의 필터를 사용하여 GitHub에서 공용 코드와 일치하는 코드 제안을 차단하면 보안 및 법적 규정 준수가 향상됩니다. 공용 또는 오픈 소스 코드의 의도하지 않은 통합을 방지하여 법적 문제의 위험을 줄이고 라이선스 조건을 준수하도록 보장합니다. 또한 퍼블릭 코드의 잠재적 취약성을 조직의 프로젝트에 도입하지 않도록 방지하여 더 높은 코드 품질과 보안을 유지할 수 있습니다. 필터를 사용하도록 설정하면 GitHub Copilot는 GitHub의 공용 코드에 대해 약 150자의 주변 코드로 코드 제안을 확인합니다. 일치하거나 거의 일치하는 경우 제안이 표시되지 않습니다.
심각도: 높음
(미리 보기) GitHub 조직은 외부 협력자 다단계 인증을 적용해야 합니다.
설명: GitHub 조직의 외부 협력자 대해 다단계 인증을 적용하는 것은 공동 작업자가 암호 외에 추가 형태의 ID를 사용하여 조직의 리포지토리 및 리소스에 액세스하도록 요구하는 보안 조치입니다. 이렇게 하면 암호가 손상된 경우에도 무단 액세스로부터 보호하여 보안을 강화하고 업계 표준을 준수하는 데 도움이 됩니다. 여기에는 협력자에게 요구 사항에 대해 알리고 전환에 대한 지원을 제공하여 궁극적으로 데이터 위반의 위험을 줄이는 것이 포함됩니다.
심각도: 높음
(미리 보기) GitHub 리포지토리에는 코드 푸시에 대한 최소 2개 검토자 승인이 필요합니다.
설명: 의도하지 않거나 악의적인 변경 내용이 직접 커밋되지 않도록 하려면 GitHub 리포지토리의 기본 분기 대한 보호 정책을 구현하는 것이 중요합니다. 코드가 기본 분기 병합되기 전에 두 명 이상의 코드 검토자가 끌어오기 요청을 승인하도록 요구하는 것이 좋습니다. 최소 두 명의 검토자의 승인을 요구하면 무단 수정의 위험을 줄일 수 있으며 이로 인해 시스템 불안정 또는 보안 취약성이 발생할 수 있습니다.
심각도: 높음
GitLab 권장 사항
GitLab 프로젝트에는 비밀 검사 결과 해결이 있어야 합니다.
설명: 비밀이 코드 리포지토리에서 발견되었습니다. 이는 보안 위반을 방지하기 위해 즉시 수정해야 합니다. 리포지토리에 있는 비밀은 악의적 사용자가 유출하거나 검색할 수 있습니다. 이로 인해 애플리케이션 또는 서비스가 손상될 수 있습니다.
심각도: 높음
GitLab 프로젝트에는 코드 검사 결과 해결이 있어야 합니다.
설명: 코드 리포지토리에서 취약성이 발견되었습니다. 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다.
심각도: 보통
GitLab 프로젝트에는 종속성 취약성 검사 결과 해결이 있어야 합니다.
설명: GitHub 리포지토리에는 종속성 취약성 검사 결과 해결이 있어야 합니다.
심각도: 보통
GitLab 프로젝트에는 코드 검사 결과 해결로 인프라가 있어야 합니다.
설명: 코드 보안 구성 문제로서의 인프라가 리포지토리에서 발견되었습니다. 표시된 문제가 템플릿 파일에서 검색되었습니다. 관련 클라우드 리소스의 보안 상태를 향상시키려면 이러한 문제를 수정하는 것이 좋습니다.
심각도: 보통
사용되지 않는 DevOps 보안 권장 사항
코드 리포지토리에서 코드 검사 결과를 확인해야 함
설명: 클라우드용 Defender DevOps 보안이 코드 리포지토리에서 취약성을 발견했습니다. 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다. (관련 정책 없음)
심각도: 보통
코드 리포지토리에서 비밀 검사 결과를 확인해야 함
설명: 클라우드용 Defender DevOps 보안이 코드 리포지토리에서 비밀을 발견했습니다. 이는 보안 위반을 방지하기 위해 즉시 수정해야 합니다. 리포지토리에 있는 비밀은 악의적 사용자가 유출하거나 검색할 수 있습니다. 이로 인해 애플리케이션 또는 서비스가 손상될 수 있습니다. Azure DevOps의 경우 Microsoft Security DevOps CredScan 도구는 실행되도록 구성된 빌드만 검색합니다. 따라서 결과는 리포지토리에 있는 비밀의 전체 상태를 반영하지 않을 수 있습니다. (관련 정책 없음)
심각도: 높음
코드 리포지토리에서 Dependabot 검사 확인해야 함
설명: 클라우드용 Defender DevOps 보안이 코드 리포지토리에서 취약성을 발견했습니다. 리포지토리의 보안 상태를 향상시키려면 이러한 취약성을 수정하는 것이 좋습니다. (관련 정책 없음)
심각도: 보통
코드 리포지토리에서 코드 제공 인프라 검사 결과를 확인해야 함
설명: 클라우드용 Defender DevOps 보안은 리포지토리에서 코드 보안 구성 문제로 인프라를 발견했습니다. 표시된 문제가 템플릿 파일에서 검색되었습니다. 관련 클라우드 리소스의 보안 상태를 향상시키려면 이러한 문제를 수정하는 것이 좋습니다. (관련 정책 없음)
심각도: 보통
GitHub 리포지토리에 코드 검색을 사용하도록 설정해야 함
설명: GitHub는 코드 검색을 사용하여 코드에서 보안 취약성 및 오류를 찾기 위해 코드를 분석합니다. 코드 검사는 코드의 기존 문제에 대한 수정을 찾고 심사하고 우선 순위를 지정하는 데 사용할 수 있습니다. 또한 코드 검사는 개발자가 새로운 문제를 도입하지 않도록 방지할 수 있습니다. 검사를 특정 날짜 및 시간에 예약하거나 리포지토리에서 푸시와 같은 특정 이벤트가 발생하는 경우 검사를 트리거할 수 있습니다. 코드 검사에서 코드의 잠재적 취약성 또는 오류를 발견하면 GitHub에서 경고를 리포지토리에 표시합니다. 취약성은 프로젝트의 기밀성, 무결성 또는 가용성을 손상시키기 위해 악용될 수 있는 프로젝트 코드의 문제입니다. (관련 정책 없음)
심각도: 보통
GitHub 리포지토리에 비밀 검사를 사용하도록 설정해야 함
설명: GitHub는 리포지토리에 실수로 커밋된 비밀의 사기성 사용을 방지하기 위해 알려진 유형의 비밀을 리포지토리에 검사합니다. 비밀 검사는 GitHub 리포지토리에 있는 모든 분기의 전체 Git 기록에서 비밀을 검사합니다. 비밀의 예로 서비스 공급자가 인증을 위해 발급할 수 있는 토큰과 프라이빗 키가 있습니다. 비밀이 리포지토리에 체크 인되면 리포지토리에 대한 읽기 액세스 권한이 있는 모든 사용자가 비밀을 사용하여 해당 권한으로 외부 서비스에 액세스할 수 있습니다. 비밀은 프로젝트 리포지토리 외부의 안전한 전용 위치에 저장해야 합니다. (관련 정책 없음)
심각도: 높음
Dependabot 검사를 GitHub 리포지토리에 사용하도록 설정해야 함
설명: GitHub는 리포지토리에 영향을 주는 코드 종속성에서 취약성을 검색할 때 Dependabot 경고를 보냅니다. 취약성은 프로젝트 또는 해당 코드를 사용하는 기타 프로젝트의 기밀성, 무결성 또는 가용성을 손상시키기 위해 악용할 수 있는 프로젝트 코드의 문제입니다. 취약성은 공격 유형, 심각도 및 방법에 따라 다릅니다. 코드가 보안 취약성이 있는 패키지에 종속된 경우 이 취약한 종속성은 다양한 문제를 일으킬 수 있습니다. (관련 정책 없음)
심각도: 보통