GitHub Advanced Security 강제 적용에 '조직 소유자' 값이 추가됐다, 어제까지 코드 스캐닝을 끌 수 있던 계정을 세어보라

GitHub가 9월 15일 보안 구성 강제 적용에 조직 소유자 차단 값을 넣었다. 그 전까지 조직 소유자는 전사 보안 설정을 덮어쓸 수 있었다. 에이전트가 PR을 늘리는 조직이라면 예외 권한부터 세어야 한다.

AI가 쓴 코드를 어떻게 검토하느냐는 질문은 대개 리뷰 규칙으로 답이 간다. 필수 승인 인원, 코드 스캐닝, 시크릿 검사. 규칙 목록은 대체로 잘 만들어진다. 문제는 목록이 아니라, 그 목록을 끌 수 있는 사람의 수다.

기업 보안 설정은 상속 구조를 갖는다. 엔터프라이즈가 정하고, 조직이 받고, 리포지토리가 적용한다. 그런데 상속의 각 단계마다 예외 버튼이 하나씩 달려 있다. 마감이 급한 팀은 그 버튼을 누른다. 눌린 사실은 감사 로그에 남지만, 로그를 매주 읽는 조직은 드물다.

어제 GitHub가 그 버튼 하나를 없앨 수 있게 했다.

강제 적용 드롭다운에 세 번째 값이 생겼다

GitHub 9월 15일 체인지로그는 GitHub Advanced Security 보안 구성의 Enforcement 드롭다운 선택지를 늘렸다고 적었다. 값은 셋이다. Don't enforce, Enforce for repository owners, Enforce for repository and organization owners. 마지막 값이 이번에 추가됐고, 적용 대상은 GitHub Enterprise Cloud다.

여기서 읽을 것은 새 값이 아니라 그 전의 상태다. 어제까지 엔터프라이즈가 강제할 수 있는 범위는 리포지토리 소유자까지였다. 조직 소유자는 전사 보안 구성을 덮어쓸 수 있었다. 대기업에서 조직은 보통 본부·사업부 단위로 쪼개지고, 조직 소유자 권한을 가진 계정은 수십 개가 된다. 전사 보안 정책이 실제로는 그 수십 명이 각자 덮어쓰지 않기로 한 합의에 걸려 있었다는 뜻이다.

설정은 문서가 아니라 권한으로 존재한다. 어떤 정책이 실제로 작동하는지 알고 싶으면 정책 문서를 읽을 게 아니라, 그 정책을 끌 수 있는 계정을 세면 된다.

코드를 쓰는 쪽도, 리뷰를 닫는 쪽도 이미 에이전트다

이 변경이 지금 나왔다는 점이 중요하다. 같은 플랫폼에서 GitHub Agentic Workflows는 6월 11일 퍼블릭 프리뷰로 올라가, 코딩 에이전트가 GitHub Actions 안에서 이슈 분류와 CI 실패 분석을 돌린다. 리뷰 쪽에서는 9월 11일 업데이트로 Copilot 코드 리뷰가 자기가 남긴 코멘트를 스스로 해결 처리하고, 셸 도구로 빌드를 돌려 검증한다. 이 조합은 미해결 0건이 검토 완료를 뜻하지 않는 문제를 만든다.

사람이 문장을 읽고 판단하는 지점이 줄어들면, 남는 통제는 자동으로 도는 검사와 그 검사를 끌 수 있는 권한뿐이다.

Anthropic이 9월 10일 공개한 위협 인텔리전스 리포트는 반대편에서 같은 그림을 보여준다. 2025년 12월부터 2026년 8월까지 차단한 사례에서 공격자들은 모델을 자율 멀티 에이전트 프레임워크에 넣어 공격 단계를 위임했고, 사람의 개입은 표적 선정과 결과 검토로 줄었다. 공격은 기계 속도로 도는데 방어 설정만 회의 속도로 도는 구간이 생긴다.

가져갈 것

• 우리 엔터프라이즈의 GHAS 보안 구성 Enforcement 값은 Enforce for repository and organization owners인가, 아직 repository owners까지인가?
• 조직 소유자 권한을 가진 계정은 몇 개이고, 그중 이번 분기에 로그인 기록이 없는 계정은 몇 개인가?
• 코드 스캐닝·시크릿 스캐닝이 꺼진 리포지토리 목록을 뽑았을 때, 그중 에이전트가 PR을 여는 리포지토리가 있는가?
• Copilot 코드 리뷰가 자기 코멘트를 닫는 리포지토리에서, 병합 조건이 미해결 코멘트 0건 하나에만 걸려 있지 않은가?
• GitHub Actions에서 도는 에이전트 워크플로가 쓰는 토큰의 권한 범위를 지난 30일 안에 확인했는가?

안 되는 경우

• 이번 옵션은 GitHub Enterprise Cloud의 GHAS 보안 구성 이야기다. GHAS를 쓰지 않거나 GitHub Enterprise Server·다른 코드 호스팅을 쓰는 조직에는 그대로 적용되지 않는다.
• 체인지로그는 이미 조직 단위로 덮어쓴 설정이 새 값을 켰을 때 어떻게 처리되는지, 켜는 순간 무엇이 깨질 수 있는지 밝히지 않았다. 영향 범위는 직접 확인해야 한다.
• 조직이 하나뿐이고 관리자가 두세 명인 회사라면 실익이 작다. 이 문제는 조직 소유자 권한이 수십 개로 흩어진 구조에서 생긴다.
• 강제 적용은 반대 방향으로도 작동한다. 잘못 만든 구성을 끌 수 없게 전사에 밀어 넣으면, 예외 요청 티켓이 보안팀 한 곳으로 몰린다.

이번 주에 바꿀 것은 정책 문서가 아니다. 엔터프라이즈 보안 구성 화면을 열어 Enforcement 값을 확인하고, 조직 소유자 목록을 뽑아 인원수를 세는 일이다. 두 숫자를 나란히 놓으면 우리 회사의 코드 검사 정책이 규칙인지 권고인지 그 자리에서 판정된다. 사업영역 →