GitHub, 사내 1만4000여 저장소 소유권 정비…활성 저장소 100% 검증

GitHub이 사내 주력 조직에 속한 1만4000여 저장소를 정비해 모든 활성 저장소에 검증된 소유자를 부여했다. GitHub 공식 보안 블로그에 따르면 회사는 45일이 채 걸리지 않는 기간에 담당자가 불분명한 저장소를 분류하고, 사용되지 않는 저장소는 보관 처리했으며, 새 저장소를 만들 때 소유권 정보를 의무적으로 입력하도록 절차를 바꿨다.

이번 작업은 비밀정보 탐지 경고를 처리하는 과정에서 시작됐다. 저장소에 노출된 자격 증명을 회수할 수는 있어도 실제 담당 조직을 찾지 못하면 서비스 중단 위험을 판단하거나 조치 업무를 배정하기 어려웠기 때문이다. 서비스 카탈로그와 연결되지 않은 문서, 내부 도구, 일회성 프로젝트와 개인 실험 저장소가 특히 관리 공백에 놓여 있었다.

GitHub은 저장소 Custom Properties에 소유권 유형과 소유자 이름을 기록했다. 소유권 유형은 서비스 카탈로그, 팀, 개인 계정으로 구분했으며 별도 GitHub App이 팀의 존재 여부와 구성원 수, 개인 계정의 재직 상태, 서비스 카탈로그 항목의 유효성을 확인하도록 했다. 기존 서비스와 연결된 약 1500개 저장소는 자동으로 채웠고 나머지 저장소는 소유자를 지정하도록 안내했다.

초기 유예 기간은 30일이었다. 기한이 지나도 소유권이 지정되지 않은 저장소는 삭제하지 않고 읽기 전용으로 보관했다. 이 과정에서 약 8000개 저장소가 추가로 보관됐으며, 정비가 끝난 뒤에는 약 3000개의 활성 저장소와 1만1000개의 보관 저장소가 남았다. GitHub은 보관이 되돌릴 수 있는 조치라는 점을 활용해 오분류 위험을 낮췄고, 이후 감시 주기를 한 시간으로 단축했다.

대규모 자동화에는 별도 안전장치도 넣었다. 한 번의 실행에서 보관이나 경고 생성 대상이 기준치를 넘으면 작업을 중단하고 담당자에게 알리도록 해, 서비스 카탈로그의 오래되거나 잘못된 데이터가 대량 보관으로 이어지는 상황을 막았다. 저장소 생성 단계에서도 소유권 값을 필수로 받아 정비 이후의 상태가 다시 흐트러지지 않도록 했다.

GitHub 공식 문서는 Custom Properties를 조직 내 저장소에 구조화된 메타데이터를 붙이고 규칙 집합과 자동화 대상을 지정하는 기능으로 설명한다. 속성 값을 모든 저장소에 요구하거나 저장소 생성·이관 때 사용자가 값을 직접 입력하도록 설정할 수도 있다. 이번 사례는 저장소 목록 정리가 단순 자산 관리가 아니라 취약점 대응과 규정 준수, 장애 연락망을 연결하는 보안 통제의 기반이 될 수 있음을 보여준다.

출처: GitHub 공식 보안 블로그 https://github.blog/security/application-security/how-github-gave-every-repository-a-durable-owner/ · GitHub Docs https://docs.github.com/en/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization