{"meta":{"title":"보안 인시던트에 대응","intro":"엔터프라이즈의 조직 또는 리포지토리에 영향을 주는 보안 인시던트에 전략적으로 대응합니다 GitHub .","product":"보안 및 코드 품질","breadcrumbs":[{"href":"/ko/code-security","title":"보안 및 코드 품질"},{"href":"/ko/code-security/tutorials","title":"Tutorials"},{"href":"/ko/code-security/tutorials/secure-your-organization","title":"조직 보호"},{"href":"/ko/code-security/tutorials/secure-your-organization/respond-to-a-security-incident","title":"보안 인시던트에 대응"}],"documentType":"article"},"body":"# 보안 인시던트에 대응\n\n엔터프라이즈의 조직 또는 리포지토리에 영향을 주는 보안 인시던트에 전략적으로 대응합니다 GitHub .\n\n이 문서의 지침은 엔터프라이즈 소유자, 조직 소유자, 보안 관리자 및 보안 팀을 대상으로 합니다. 그러나 이 문서에 설명된 몇 가지 작업을 수행하려면 엔터프라이즈 소유자 역할이 있어야 합니다. 일부 단계에서는 조직 소유자 또는 리포지토리 관리자와의 조정이 필요할 수 있습니다.\n\n## Introduction\n\n이 가이드에서는 보안 인시던트에 대응하는 방법, 위협의 GitHub 유효성을 검사 및 조사하는 데 사용할 수 있는 표면 및 이를 포함하고 수정하는 데 사용할 수 있는 도구를 설명합니다.\n\n> \\[!IMPORTANT] 이 단계는 일반적인 지침입니다. 모든 인시던트가 고유하며 특정 상황에 따라 다른 접근 방식이 필요할 수 있습니다.\n>\n> 플랫폼 관련 질문을 지원할 수 있지만 GitHub 지원 시스템 및 리소스에 영향을 주는 보안 인시던트를 조사하고 대응하는 것이 가장 좋습니다.\n\n### 사전 요구 사항\n\n이상적으로는 엔터프라이즈에 **대해 감사 로그 스트리밍** 및 **원본 IP 주소 표시 유형** 이 이미 활성화되어 있고(데이터를 SIEM(보안 정보 및 이벤트 관리) 시스템으로 스트리밍) 해당 데이터에 액세스할 수 있습니다.\n[엔터프라이즈에 대한 감사 로그 스트리밍](/ko/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise)을(를) 참조하세요.\n\n### 당신의 응답 전체에 걸쳐\n\n응답을 진행하면서 다음을 확인합니다.\n\n* **증거 보존**: 의심스러운 활동의 스크린샷을 찍고, 로그 또는 쿼리 결과를 내보내고, 정리하기 전에 영향을 받는 파일 또는 코드의 복사본을 저장합니다.\n* **레코드 유지**: 결과(예: 시간, 날짜, 손상 지표(IoC), 영향을 받는 리포지토리)를 문서화하고 각 결정을 기록합니다.\n* **커뮤니케이션**: 중요한 데이터가 위험에 처한 경우 관련 이해 관계자(예: 보안 리드 및 엔지니어링 관리자, 법률 및 개인 정보 보호 팀)에게 알리고 업데이트된 상태로 유지합니다.\n\n## 1단계: 신호 평가 및 신속하게 유효성 검사\n\n목표는 표시되는 신호가 실제 및 활성 위협이 될 가능성이 있는지 여부를 신속하게 확인하는 것입니다.\n\n### 1. 식별\n\n표시되는 신호의 특성을 확인합니다. 예를 들어 신호는 다음의 표시를 표시합니다.\n\n* **자격 증명 손상** (유출된 비밀에 대한 경고, 외부 사이트에서 발견된 자격 증명 보고서)\n* **무단 액세스 또는 계정 손상** (의심스러운 로그인, 익숙하지 않은 커밋 또는 변경에 대한 보고서)\n* **데이터 반출** (의심스러운 파일 변경 또는 추가, 예기치 않은 워크플로 실행, 비정상적인 API 활동, 알 수 없는 리포지토리 만들기 또는 예기치 않은 리포지토리 표시 유형 변경에 대한 보고서)\n* **악성 코드 삽입** (의심스러운 코드 변경, 예기치 않은 워크플로 실행, 추가된 새 파일의 보고서)\n* **공급망 공격** (의심스러운 패키지 버전 보고서, 취약한 종속성에 대한 경고)\n\n조직 또는 기업 전체에서 이러한 위협 신호를 식별하는 데 도움이 되도록 [일반적인 보안 인시던트 조사 영역](/ko/code-security/reference/security-incident-response/investigation-areas)을 참조하세요.\n\n> \\[!NOTE]\n> \\[!NOTE] 실행기 IP 주소는 공유 인프라에서 동적으로 할당되며 관련 없는 활동으로 인해 플래그가 지정될 수 있습니다. 자세한 내용은 [워크플로 문제 해결](/ko/actions/how-tos/troubleshoot-workflows#runner-ip-addresses-flagged-by-security-scanners)을(를) 참조하세요.\n\n초기 목표는 위협 신호를 **식별** 하여 유효성을 검사하고 대응 전략을 정하는 것이므로 조사 초기 단계에서 심층 검사에 너무 많은 시간을 할애하지 **않는 것이 좋습니다** .\n\n### 2. 유효성 검사\n\n잠재적 위협이 진짜인지, 현재 활성 상태인지 여부를 확인하기 위한 증거를 확인합니다.\n\n다음 GitHub 도구와 표면이 도움이 될 수 있습니다.\n\n| 도구/표면 | Purpose |\n| --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |\n| [보안 개요 및 보안 경고](/ko/code-security/reference/security-incident-response/investigation-tools#security-overview-and-security-alerts) | 조직 또는 기업 전체에서 보안 경고 검토 |\n| [감사 로그](/ko/code-security/reference/security-incident-response/investigation-tools#audit-logs) | 토큰 생성, 권한 변경 또는 리포지토리 표시 유형 변경과 같이 조사 중인 신호와 관련된 이벤트를 검색합니다. |\n| [활동 보기](/ko/code-security/reference/security-incident-response/investigation-tools#activity-view) | 특정 리포지토리에 대한 푸시, 커밋 및 분기 작업의 타임라인 보기 |\n| \\[ | |\n| GitHub 코드 검색]\\(/code-security/reference/security-incident-response/investigation-tools#github-code-search) | 리포지토리에서 특정 파일 이름 또는 코드 패턴과 같은 알려진 손상 지표 검색 |\n| [종속성 그래프](/ko/code-security/reference/security-incident-response/investigation-tools#dependency-graph) | 리포지토리가 특정 패키지 또는 패키지 버전에 따라 달라지는지 확인 |\n| [워크플로 실행 및 로그](/ko/code-security/reference/security-incident-response/investigation-tools#workflow-runs-and-logs) | 워크플로 실행 기록을 검토하고 로그 출력에서 의심스러운 활동을 검사합니다. |\n\n각 도구에 대한 자세한 내용은 [보안 인시던트에 대한 조사 도구](/ko/code-security/reference/security-incident-response/investigation-tools)을 참조하세요.\n\n유효성 검사 단계는 빠를 수 있습니다 **.**\n\n* 신호가 **실제** 및 **활성** 위협이 될 가능성이 있는지 여부를 결정하기에 충분한 증거를 수집하는 것을 목표로합니다.\n* 신호를 가양성으로 신속하게 배제할 수 없는 경우 실제라고 가정합니다.\n* 심층 조사는 나중에 수행할 수 있습니다.\n\n### 3. 결정\n\n수집된 증거에 따라 다음 세 가지를 결정합니다.\n\n1. **이것이 진짜 위협인가요?** 신호를 가양성으로 빠르게 자신 있게 배제할 수 없는 경우, 실제 신호로 간주하고 격리 조치를 진행합니다.\n2. **위협이 여전히 활성 상태입니까?** 공격자가 여전히 액세스 권한이 있거나 활동이 진행 중인 경우 먼저 즉각적인 봉쇄 작업의 우선 순위를 지정합니다. 침해가 과거의 기록으로 보이는 경우에도 조사와 수정을 수행해야 하지만, 응답을 계획하는 데 더 많은 시간이 있을 수 있습니다.\n3. **잠재적인 범위는 무엇인가요?** 침해가 단일 자격 증명, 리포지토리, 조직, 또는 전체 기업에까지 미칠 수 있는 범위를 고려해 보십시오. 이렇게 하면 응답을 적절하게 조정하는 데 도움이 됩니다.\n\n의심스러운 경우 위협을 실제로 처리하고 증거가 허용하는 대로 응답을 축소합니다.\n\n## 2단계: 위협 억제\n\n다음 단계에서는 실제 및 활성 위협을 처리하고 있다고 가정합니다. 이제 목표는 지금까지 알고 있는 것을 사용하여 **지속적인 위험을 즉시 줄이는** 것입니다.\n\n공격자의 액세스 및 기능을 제한하기 위해 수행할 수 있는 몇 가지 포함 작업이 있습니다.\n\n> \\[!IMPORTANT]\n> 위협의 특성, 잠재적 범위 및 이 시점에서 가지고 있는 증거에 따라 작업을 선택해야 합니다. 모든 인시던트에 대해 이러한 작업을 모두 수행하지 않는 것이 좋습니다. 일부 작업은 다른 작업보다 더 파괴적이거나 파괴적이므로 위의 위협 특성에 대한 평가에 따라 각 작업의 위험과 이점을 평가해야 합니다.\n\n### 손상된 자격 증명 해지\n\n노출되거나 악용된 자격 증명의 경우 영향을 받는 자격 증명을 해지하여 추가 오용을 방지하기 위해 수행할 수 있는 가장 즉각적인 조치입니다.\n\n* **API를 통해 해지**\n\n 토큰이 다음 형식 중 하나이며 토큰의 리터럴 값이 알려진 경우 사용자(또는 다른 사람)는 **REST API를 통해 요청을 제출하여 토큰을** 해지할 수 있습니다.\n [취소](/ko/rest/credentials/revoke?apiVersion=2022-11-28#revoke-a-list-of-credentials)을(를) 참조하세요.\n\n * Personal access token (classic)\n * Fine-grained personal access token\n * OAuth app 액세스 토큰\n * GitHub App 사용자 액세스 토큰\n * GitHub App 새로 고침 토큰\n\n* **해지 및 포함 옵션**\n\n 자격 증명 액세스를 차단하는 추가 옵션이 있습니다. 자격 증명 유형별 전체 목록은 [GitHub 자격 증명 형식 참조](/ko/organizations/managing-programmatic-access-to-your-organization/github-credential-types)을 참조하세요.\n\n* **특정 사용자에 대한 자격 증명 취소 또는 삭제**\n\n 손상된 특정 계정을 식별한 경우 엔터프라이즈 또는 조직 소유자는 해당 개별 사용자에 GitHub Enterprise Cloud 대한 SSO 권한 부여를 취소할 수 있습니다.\n Enterprise Managed Users가 있는 엔터프라이즈의 경우 자격 증명을 완전히 삭제할 수도 있습니다. 이는 여전히 위협을 포함하면서 대량 작업보다 중단이 적습니다.\n [엔터프라이즈에서 SSO 권한 부여 취소 또는 자격 증명 삭제](/ko/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens#taking-action-against-individual-members)을(를) 참조하세요.\n\n* **특정 형식의 자격 증명 취소 또는 삭제**\n\n 인시던트가 하나의 자격 증명 유형(예: 엔터프라이즈 또는 조직 소유자)으로 personal access tokens (classic)제한되면 UI를 사용하여 GitHub 모든 멤버에서만 SSO 권한 부여를 해지하거나 해당 형식의 자격 증명만 삭제할 수 있습니다. 다른 자격 증명을 방해하지 않고 영향을 받는 자격 증명 형식을 대상으로 합니다.\n [엔터프라이즈에서 SSO 권한 부여 취소 또는 자격 증명 삭제](/ko/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens#taking-action-against-a-specific-credential-type)을(를) 참조하세요.\n\n* **긴급 조치(주요 인시던트)**\n\n 엔터프라이즈 및 조직 소유자는 GitHub Enterprise Cloud 대량 긴급 조치를 취하여 엔터프라이즈 또는 조직 전체에서 액세스를 잠글 수 있습니다. 엔터프라이즈의 Enterprise Managed Users경우 **여기에는 모든 사용자 토큰 및 키 삭제가 포함됩니다**. 자동화를 중단시키고, 주요 인시던트를 위해서만 사용해야 하는 강력한 조치들입니다.\n [엔터프라이즈의 보안 인시던트에 대응](/ko/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents)을(를) 참조하세요.\n\n관리자 또는 영향을 받는 사용자가 시작한 이러한 모든 권한 부여 해제 및 해지 작업은 감사 로그에 기록되고 영향을 받는 사용자는 이메일 알림을 받습니다.\n\n### 액세스 제한\n\n엔터프라이즈, 조직 또는 리포지토리에 대한 액세스를 제한하기 위해 수행할 수 있는 몇 가지 즉각적인 작업이 있습니다.\n\n* **IP 허용 목록 구성**\n\n 알 수 없거나 의심스러운 IP 주소가 조직 또는 엔터프라이즈에 액세스하지 못하도록 차단합니다.\n [IP 허용 목록을 사용하여 엔터프라이즈에 대한 네트워크 트래픽 제한](/ko/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list)(엔터프라이즈 관리자) 및 [조직에 허용되는 IP 주소 관리](/ko/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization)(조직 소유자)을 참조하세요.\n\n* **손상되거나 의심스러운 사용자 제거**\n\n 사용자를 제거하거나 계정을 일시 중단합니다.\n (조직 소유자)을 참조하세요[](/ko/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization).\n\n* **리포지토리 표시 유형을 프라이빗으로 변경**\n\n 영향을 받는 리포지토리의 가시성을 프라이빗으로 변경하고 다른 사용자가 추가로 변경할 수 있는 기능을 제한합니다. 예를 들어 중요한 코드가 조직에 속한 공용 리포지토리에 노출되었거나 악의적인 행위자가 리포지토리의 표시 설정을 프라이빗에서 퍼블릭으로 변경한 경우 리포지토리의 표시 유형을 변경할 수 있습니다.\n [리포지토리 표시 유형 설정](/ko/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)(리포지토리 관리자 및 조직 소유자) 및 [조직의 리포지토리 표시 유형 변경 제한](/ko/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization)(조직 소유자)을 참조하세요.\n\n* **긴급 조치(주요 인시던트)**\n\n 엔터프라이즈 소유자는 GitHub Enterprise Cloud 대량 긴급 조치를 취하여 기업 전체에서 액세스를 잠글 수 있습니다. 여기에는 모든 비소유자 액세스를 차단하도록 **SSO를 잠그** 고 **조직 전체에서 모든 사용자 SSO 권한 부여를 취소하는 것이 포함됩니다**. 자동화를 중단시키고, 주요 인시던트를 위해서만 사용해야 하는 강력한 조치들입니다.\n [엔터프라이즈의 보안 인시던트에 대응](/ko/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents)을(를) 참조하세요.\n\n### 악의적인 아티팩트 및 활동 사용 안 함\n\n* **악성 워크플로 실행 중지**\n\n 워크플로 또는 실행기를 GitHub Actions 활성 공격의 일부로 사용하는 것으로 의심되는 경우 다음 작업을 수행할 수 있습니다.\n\n * 영향을 받는 리포지토리에 대해 진행 중인 워크플로 실행을 취소합니다.\n [워크플로 실행 취소](/ko/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run)을(를) 참조하세요.\n * 조직의 영향을 받는 리포지토리 또는 특정 조직에 대해 사용하지 않도록 설정합니다 GitHub Actions .\n [조직에 대한 GitHub Actions 사용하지 않도록 설정 또는 제한](/ko/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization)(조직 소유자) 및 [엔터프라이즈에서 GitHub Actions 대한 정책 적용](/ko/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise)(엔터프라이즈 관리자)을 참조하세요.\n * 자체 호스팅 실행기를 제거합니다.\n [자체 호스트형 실행기 제거](/ko/actions/how-tos/manage-runners/self-hosted-runners/remove-runners)을(를) 참조하세요.\n\n* **웹후크 사용 안 함**\n\n 손상된 리포지토리 또는 조직 웹후크가 라이브 데이터 반출 채널로 사용되고 있다고 의심되는 경우 사용하지 않도록 설정할 수 있습니다.\n [웹후크 사용 중지하기](/ko/webhooks/using-webhooks/disabling-webhooks)을(를) 참조하세요.\n\n* **유해한 브랜치 삭제**\n\n 악성 코드 또는 워크플로가 포함된 분기를 식별한 경우 즉시 삭제하여 실행을 방지합니다.\n [리포지토리 내에서 분기 관리](/ko/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository#deleting-a-branch)을(를) 참조하세요.\n\n## 3단계: 전체 조사\n\n즉각적으로 봉쇄한 후에 이제 목표는 인시던트의 전체 범위와 영향을 이해하고, 모든 침해 지표(IoC) 및 지속성 메커니즘을 식별하며, 위협을 완전히 봉쇄하고 수정하는 데 필요한 모든 증거를 수집하는 것입니다.\n\n> \\[!IMPORTANT] 인시던트 응답은 선형 프로세스가 아닙니다. 새 IoC를 검색하거나 공격에 대해 자세히 이해할 때 조사, 포함 및 수정을 반복해야 할 수 있습니다.\n\n1. 당신이 본 신호와 지금까지 수집 된 증거에 따라, 무슨 일이 있었는지에 대한 **작업 가설** 을 개발하고 그 가설을 증명하거나 반증하는 데 필요한 추가 증거를 결정합니다.\n2. **AUTOTITLE**에 설명된 다양한 [조사 영역을 고려하여 조사를](/ko/code-security/reference/security-incident-response/investigation-areas) 안내합니다.\n\n 조사를 한 줄의 조사로 제한하지 마세요. 많은 공격은 자격 증명 악용, 워크플로 파일 삽입 및 데이터 반출과 결합된 악성 패키지 설치와 같은 기술을 조합하여 사용합니다. 모든 잠재적인 공격 벡터를 조사하고 있는지 확인합니다.\n3. 지금까지 알려진 모든 IoC를 **문서화**하고, GitHub의 모든 표면에서 흔적을 찾으세요.\n4. 영향을 받는 모든 워크플로, 리포지토리 및 조직을 **인벤토리**하여 인시던트 범위를 체계적으로 캡처합니다.\n * 리포지토리 이름, 영향을 받은 항목(코드, 비밀, 워크플로) 및 손상 타임라인을 포함합니다.\n * 영향을 받는 모든 계정 및 자격 증명 목록을 만듭니다. 노출되거나 오용되었을 수 있는 토큰, SSH 키 또는 기타 자격 증명을 확인합니다.\n5. 증거에 대해 작업 이론의 **유효성**을 검사합니다.\n * 수집한 증거를 검토합니다. 초기 가설을 지원하나요?\n * 다른 설명을 고려해 보세요. 관찰한 활동에 다른 원인이 있을 수 있나요?\n * 가설이 반증되면 증거에 따라 새로운 가설을 작성하고 필요에 따라 조사 단계를 반복합니다.\n6. **격리 조치로 다시 돌아가** 새로운 IoC(침해 지표)나 즉각적인 조치가 필요한 진행 중인 활동의 증거를 발견한 경우.\n\n발생한 일과 근본 원인에 대한 이해가 높으면 결과를 문서화하고 수정을 진행합니다.\n\n## 4단계: 수정\n\n이제 목표는 손상의 모든 추적을 제거하고, 근본 원인을 수정하고, 시스템을 안전한 상태로 복원하는 것입니다. 수정 작업은 사용자가 직면한 악용에 따라 달라지지만 몇 가지 모범 사례는 다음과 같습니다.\n\n### 토큰 및 비밀 회전\n\n자격 증명이 침해되었는지 확실하지 않더라도 노출 가능성이 조금이라도 있다면 해당 자격 증명을 교체합니다.\n\n* 새 토큰 및 비밀을 생성하여 해지되었거나 노출되었을 수 있는 토큰을 대체합니다. \n* 리포지토리, 환경 및 조직 수준에 저장된 GitHub 비밀을 회전합니다.\n* 손상된 토큰을 사용하여 액세스되었을 수 있는 외부 시스템의 자격 증명을 업데이트합니다.\n* 앞으로 정기적인 회전을 장려하기 위해 토큰 만료 정책을 사용하도록 설정하는 것이 좋습니다.\n [Enterprise에서 개인용 액세스 토큰에 대한 정책 적용](/ko/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-personal-access-tokens-in-your-enterprise)을(를) 참조하세요.\n\n### 지속성 메커니즘 감사를 수행하다\n\n초기 봉쇄 작업 후에도 액세스를 유지하기 위해 공격자가 설정했을 수 있는 지속성 메커니즘을 확인해야 합니다.\n\n여기에는 다음과 같은 사항을 확인하는 것이 포함되지만 이에 국한되지는 않습니다.\n\n* 추가되거나 수정되었을 수 있는 의심스럽거나 익숙하지 않은 워크플로 파일입니다.\n* 익숙하지 않은 도메인을 가리키는 새 웹후크입니다.\n* 새로운 자체 호스팅 실행기.\n* 자체 호스팅 러너에 대한 수정.\n* 새로 설치된 GitHub Apps 또는 OAuth app 권한.\n* 리포지토리에 추가된 새 배포 키입니다.\n* 새 이진 파일 또는 실행 파일.\n\n### 종속성 감사 및 다시 설치\n\n손상된 종속성은 공격 벡터 역할을 할 수 있습니다. 종속성에 대한 전체 감사를 수행하고 신뢰할 수 있는 원본에서 다시 설치해야 합니다.\n\n* 취약한 종속성에 대한 Dependabot 경고를 검토하고, 가능한 경우 악성 패키지에 대한 Dependabot malware alerts도 확인합니다. (Dependabot malware alerts는 현재 npm 에코시스템에서 사용할 수 있습니다.) 추가 맬웨어 경고를 조사하려면 `type:malware`을(를) GitHub Advisory Database에서 검색하고 종속성 그래프를 감사하여 일치 항목을 확인하십시오.\n* 종속성을 정상 버전에 고정하거나 SHA를 커밋하고 패키지 레지스트리에서 다시 설치합니다.\n\n### 시정 확인\n\n수정 작업이 성공했음을 확인합니다.\n\n* 경고를 검토 code scanning 하여 코드 취약성이 해결되었으며 새로운 취약성이 도입되지 않은지 확인합니다.\n* 경고를 검토 secret scanning 하여 모든 리포지토리에 비밀이 노출되지 않고 모든 경고가 해결되었는지 확인합니다.\n* 인시던트 후 며칠 및 몇 주 동안 감사 로그 및 기타 관련 표면을 계속 검토하고 모니터링합니다.\n\n## 5단계 문서\n\n나머지 단계와 향후 참조를 위해서는 철저한 설명서가 필요합니다.\n\n* 조사 중에 검색된 모든 IoC를 기록합니다.\n* 타임스탬프 및 각 작업을 수행한 사용자를 포함하여 수행된 모든 수정 단계를 문서화합니다.\n* 영향을 받는 리포지토리, 워크플로 및 계정의 인벤토리를 유지 관리합니다.\n* 결정된 사항과 그 뒤에 있는 추론을 문서화합니다.\n* 규정 준수, 법적 또는 개인 정보 보호에 미치는 영향을 적어 둡니다. 이 인시던트가 알림이 필요한 데이터 위반인지 여부를 고려합니다.\n\n## 6단계: 반영 및 강화\n\n이제 목표는 인시던트로부터 배우고 유사한 인시던트 방지를 위해 보안 태세를 강화하는 것입니다.\n\n1. **시던트 요약**을 작성하십시오. 여기에는 첫 번째 표시부터 해결까지의 이벤트 타임라인과 근본 원인 분석, 수행된 결정 및 작업 및 학습된 교훈이 포함되어야 합니다.\n2. 보안 인시던트에서 **미해결 작업 항목을** 문제(예: 남은 수정 작업 및 학습된 교훈에 따라 구현해야 하는 보안 개선 사항)를 추적합니다.\n\nCopilot 는 이러한 문제를 만드는 데 도움이 될 수 있으며, 독립적으로 작업할 수 있도록 범위가 잘 지정된 문제를 할당할 Copilot 수 있습니다.\n[GitHub Copilot 세션 시작](/ko/copilot/how-tos/use-copilot-agents/cloud-agent/start-copilot-sessions)을 참조하세요.\n\n1. 아직 없는 경우, 회사 또는 팀에 최신의 **보안 인시던트 대응 계획**이 있는지 확인하세요. 여기에는 정의된 역할 및 책임, 에스컬레이션 경로, 통신 프로토콜, 심각도 분류 조건 및 일반적인 위협 유형에 대한 단계별 대응 절차가 포함되어야 합니다.\n Copilot 는 특정 요구 사항 및 리소스에 따라 이 계획을 생성하고 구체화하는 데 도움이 될 수 있습니다. 추가 지침 [은 인시던트 대응이란?](https://github.com/resources/articles/what-is-incident-response#what-is-incident-response)을 참조하세요.\n\n## 다음 단계\n\n* 아직 보안 태세를 강화하지 않은 경우 향후 인시던트의 위험을 줄이는 것이 좋습니다.\n [보안 위협으로부터 보호](/ko/code-security/tutorials/secure-your-organization/protect-against-threats)을(를) 참조하세요."}