GitHub, 방치된 레포지토리도 30일 주기로 자동 보안 스캔

{

"content": "이 기능은 소프트웨어 자산을 전수 조사하는 보안 전략의 일환으로 만들어졌다. 기존에는 개발 중인 레포지토리에만 보안 스캔을 적용했으나, 레거시 코드베이스도 의존성 취약점이나 시크릿 키 노출 같은 위험에 그대로 노출되어 있다.\n\n• 보안 데브옵스 관점: 개발 중단과 보안 유지는 별개의 문제다. 6개월 이상 비활성화된 코드베이스도 정기적인 취약점 스캐닝 대상이 되어야 한다.\n• 거버넌스 요구사항: 금융, 의료 등 규제 산업에서는 보관 중인 레포지토리도 보안 준수 증명이 필요하며, 감사 로그 자동화가 필수적이다.\n• 실질적 이점: 수백 개 레포지토리를 운영하는 조직에서 일일이 수동 활성화할 필요 없이, 중앙 집중식 정책 한 번만 설정하면 전체에 적용할 수 있다.\n\n결국 이 기능은 보안 사각지대를 줄이는 조직 차원의 보호 조치로 볼 수 있다."

}

{

"content": "본문에 따르면 해당 기능은 코드 스캐닝 기본 설정(Default Setup)을 사용하는 레포지토리에만 적용됩니다. 커스텀 워크플로우(Custom Workflow)를 설정한 레포지토리는 제외됩니다.\n• Technical Constraint: GitHub의 기본 설정은 CodeQL(CodeQL) 기반의 자동 분석 파이프라인이며, 사용자가 별도 YAML 워크플로우를 정의한 경우 해당 설정이 우선 적용됩니다.\n• Migration Path: 커스텀 설정을 사용 중인 레포지토리도 Periodic Scanning을 원할 경우, 기본 설정으로 마이그레이션(Default Setup Migration)하거나 별도의 스케줄러(Scheduler) 연동이 필요합니다.\n• 실제 시나리오: GitHub Enterprise Cloud 환경에서는 CodeQL 분석 자동화가 가장 흔한 패턴이나, 일부 조직은 타 정적 분석 도구(Static Analysis Tool) 통합을 위해 커스텀 워크플로우를 유지합니다.\n따라서 조직 내 레포지토리 정책 수립 시, 보안 자동화 달성률(Automation Coverage)을 높이기 위해 기본 설정 채택을 권장하는 근거가 됩니다."

}

{

"result": "기능상 30일 주기로 스캔이 실행되며, 이는 활발하게 개발 중인 레포지토리에서 일반적으로 사용되는 풀 리퀘스트 기반 방식과 대비됩니다.\n• 탐지 지연 시간: 30일 간격은 즉각적인 발견에는 한계가 있으나, 비활성 레포지토리에서는 코드 변경이 드물어 누적 취약점 파악에는 충분합니다.\n• 외부 의존성 취약점: 외부 라이브러리의 CVE(Common Vulnerabilities and Exposures) 발표가 빈번하므로, 30일 주기는 외부 위협에 대한 위험 허용 범위 내 결정입니다.\n• 사용자 정의 불가: 현재 30일 주기는 고정값이며, 조직의 보안 정책에 따라 주기를 조정할 수 없는 구조입니다.\n결론적으로 이 기능은 최소 효과적 보안 자동화의 개념으로, 비용 대비 효율성을 극대화한 설계로 볼 수 있습니다."

}