
GitHub 공식 변경 로그에 따르면 회사는 2026년 7월 8일 GitHub Advanced Security 엔터프라이즈 고객을 대상으로 기업 내부 보안 권고인 ‘Innersource advisories’를 정식 제공한다고 밝혔다. 이 기능은 공개 오픈소스 보안 권고와 비슷한 방식으로 작동하지만, 권고의 가시성과 알림 범위가 해당 기업 내부 저장소로 제한된다.
GitHub는 기업이 내부에서 발견한 취약점을 사내 저장소에 알리고, 필요한 경우 Dependabot을 통해 보안 알림과 버전 업데이트 풀리퀘스트를 전달할 수 있다고 설명했다. 공개 취약점 데이터베이스에 등록되기 전이거나 외부 공개 대상이 아닌 내부 컴포넌트라도, 조직 안에서는 같은 공급망 보안 흐름으로 대응할 수 있게 되는 셈이다.
이번 기능의 핵심은 내부 소프트웨어 공급망을 공개 생태계와 유사한 구조로 관리하게 한다는 데 있다. 기업은 내부 컴포넌트나 오픈소스 컴포넌트에 대한 권고를 만들 수 있고, GitHub는 의존성 그래프를 활용해 해당 컴포넌트를 쓰는 저장소를 찾아 알림을 전파한다. 패치 버전이 필요한 경우 Dependabot이 취약한 버전을 수정 버전으로 올리는 풀리퀘스트를 생성할 수 있다.
GitHub Docs도 같은 구조를 설명한다. 문서에 따르면 Innersource advisories는 공개 권고와 유사한 Open Source Vulnerability(OSV) 데이터 형식을 사용하지만 공개적으로 보이지 않는다. 권고는 단일 엔터프라이즈 범위로 제한되며, 그 기업 내부 저장소에만 알림을 전파한다. 이는 공개 공개 절차와 별개로 사내 수정 흐름을 먼저 밀어낼 수 있다는 의미다.
관리 방식도 API 중심으로 제공된다. GitHub 변경 로그는 기업이 내부 취약점을 생성, 수정, 철회할 수 있는 새 REST API 엔드포인트를 사용할 수 있다고 밝혔다. 보안팀이나 플랫폼팀은 이를 내부 취약점 관리, SBOM, 패키지 릴리스, 개발자 알림 시스템과 연결해 자동화할 수 있다.
적용 대상에는 제한이 있다. GitHub Docs는 이 기능을 활성 GitHub Code Security 또는 GitHub Advanced Security 라이선스가 있는 엔터프라이즈에서 만들 수 있다고 안내한다. 라이선스가 만료되거나 GitHub Code Security가 비활성화되면 권고는 더 이상 보이지 않고 알림도 전파되지 않는다. 다만 기본 데이터는 삭제되지 않으며, 라이선스를 다시 활성화하면 기존 권고가 복원된다.
범위 제한도 확인해야 한다. 현재 권고는 엔터프라이즈 전체 단위로만 지정할 수 있고, 기업 안의 개별 조직이나 특정 조직 그룹만 대상으로 삼을 수는 없다. 또한 엔터프라이즈마다 활성 권고는 2,000개로 제한된다. 오래되거나 더 이상 유효하지 않은 권고를 철회하는 운영 절차가 필요하다.
이번 발표는 공급망 보안이 공개 오픈소스 취약점 대응을 넘어 기업 내부 코드와 패키지 관리로 확장되고 있음을 보여준다. 대규모 기업에서는 내부 라이브러리, 공통 서비스, 프라이빗 패키지가 여러 제품 저장소에 걸쳐 쓰인다. 취약점 발견 이후 어느 저장소가 영향을 받는지 찾고, 소유자에게 알리고, 수정 풀리퀘스트까지 연결하는 과정은 보안팀의 반복 업무가 되기 쉽다.
다만 Innersource advisories는 도구만으로 해결되는 기능은 아니다. 기업이 실제 효과를 얻으려면 내부 패키지 이름과 버전 관리, 의존성 그래프 정확도, 취약점 공개 권한, 패치 릴리스 절차가 함께 정리돼야 한다. 내부 권고가 엔터프라이즈 전체로 전파되는 만큼, 보안팀과 개발 조직 사이의 책임 구분도 명확해야 한다.
출처: GitHub Changelog https://github.blog/changelog/2026-07-08-innersource-security-advisories-are-generally-available/ · GitHub Docs https://docs.github.com/enterprise-cloud@latest/code-security/concepts/vulnerability-reporting-and-management/innersource-advisories