GitHub가 노출된 시크릿의 PR 병합을 막는다, AI 탐지는 제외다
실용 가이드
GitHub 푸시 보호도 모든 비밀을 막지는 못한다…차단 뒤 확인할 것
저장소에 API 키와 토큰이 들어가는 일을 줄이려면 해당 저장소의 Settings에서 Advanced Security를 열고 Secret Protection을 활성화한 뒤 Push protection을 켠다. GitHub의 저장소 설정 안내는 이 순서와 설정에 필요한 관리 권한을 명시한다. 설정을 마친 뒤에는 보호 대상 저장소와 우회 경고를 확인해야 한다. 차단 알림이 없더라도 모든 종류의 비밀이 검사됐다고 판단할 수는 없다.
GitHub의 푸시 보호 설명에 따르면 지원되는 비밀은 명령줄 푸시, GitHub 웹 화면의 커밋과 파일 업로드, REST API 요청에서 감지되면 저장소에 도달하기 전에 차단된다. 다만 개인 계정에 적용되는 보호와 저장소에 적용되는 보호는 범위와 우회 경고가 다르다. 운영자는 저장소의 활성 상태를 먼저 확인하고, 실제 차단이 일어났다면 커밋에서 값을 제거했는지, 우회가 허용됐다면 경고에 남은 사유가 타당한지 살펴야 한다.
보호할 저장소에서 설정을 켠다
저장소 메인 화면에서 Settings를 열고 왼쪽 Security and quality의 Advanced Security로 이동한다. Secret Protection이 꺼져 있다면 먼저 Enable을 누른 다음 그 아래 Push protection을 활성화한다. 이 설정은 저장소 소유자, 조직 소유자, 보안 관리자 또는 관리자 권한이 있는 사용자가 다룰 수 있다. 메뉴가 보이지 않거나 설정을 바꿀 수 없다면 해당 권한을 가진 사람에게 저장소 이름을 지정해 적용을 요청한다.
조직이나 기업 수준에서도 저장소 보호를 켤 수 있으므로 운영 정책을 정할 때는 어떤 저장소가 실제 적용 대상인지 확인한다. 조직 설정이 존재한다는 사실만으로 새로 만든 저장소나 다른 조직으로 옮긴 저장소까지 같은 보호를 받는다고 추정하지 않는 편이 좋다. 특히 공개 저장소와 비공개 저장소를 함께 관리한다면 각각의 저장소에서 활성 상태를 확인해 범위를 기록한다. 설정이 켜져 있어도 실제 차단 여부는 해당 비밀의 패턴이 탐지 대상인지에 달려 있다.
작동 여부를 확인하려고 실제로 쓰는 키를 임의로 커밋하지 않는다. 테스트가 필요하다면 조직이 관리하는 시험용 자격 증명과 폐기 절차를 먼저 정하고, 어떤 패턴이 차단 대상인지 확인한 뒤 진행한다. 보호 기능을 시험하는 과정에서 유효한 비밀을 새 커밋이나 원격 저장소 이력에 남기면 점검 자체가 처리해야 할 노출을 만든다.
개인 보호와 저장소 보호의 범위를 구분한다
GitHub.com의 개인 계정 푸시 보호는 기본적으로 켜져 있고, 그 계정이 공개 저장소에 지원되는 비밀을 보내는 일을 막는다. 저장소 푸시 보호는 보호하려는 저장소에 명시적으로 켜야 하며 GitHub Secret Protection이 필요하다. 따라서 구성원 계정에서 차단 화면이 나타났다는 경험만으로 팀의 비공개 저장소도 보호된다고 결론 내릴 수 없다. 관리자가 확인할 대상은 구성원별 체감 여부보다 해당 저장소의 설정 상태다.
두 보호 방식의 차이는 차단을 우회했을 때 더 커진다. 개인 계정 보호만 적용된 공개 저장소에서는 사용자가 차단을 우회해도 저장소에 푸시 보호가 켜져 있지 않으면 우회 경고가 생성되지 않는다. 반면 저장소 보호가 활성화된 곳에서는 우회에 대한 경고가 저장소의 Security and quality 영역에 남는다. 우회 기록을 검토하려는 팀이라면 대상 저장소의 보호 상태를 먼저 확정해야 경고가 없는 이유를 잘못 해석하지 않는다.
차단되면 파일과 전송할 커밋을 함께 고친다
차단 메시지가 표시되면 감지된 비밀의 종류와 위치를 확인하고, 전송하려던 커밋에서 그 값을 제거한 뒤 다시 푸시한다. 작업 파일의 현재 모습에서만 값을 지워도 이전 커밋에 같은 값이 남아 있으면 푸시 대상 이력에는 계속 포함될 수 있다. 여러 커밋을 한 번에 보내는 경우에는 마지막 파일만 보지 말고 이번에 전송되는 커밋을 살핀다. 비밀을 제거한 새 커밋만 추가하는 방식으로 처리해도 앞선 커밋의 내용은 남을 수 있다.
감지된 값이 실제 서비스에서 쓰는 자격 증명이라면 그 값이 다른 경로에도 노출됐는지 확인하고, 노출 가능성이 있다면 발급 서비스에서 폐기하거나 교체한다. 코드가 비밀을 직접 담지 않도록 배포 환경의 비밀 관리 수단으로 값을 옮기는 것도 재발을 줄이는 방법이다. 차단이 한 번 성공했다고 해서 같은 값이 다른 브랜치, 파일 또는 이미 공개된 이력에 없는지까지 확인된 것은 아니다. 다시 푸시하기 전에는 전송 범위에 남은 값을 점검한다.
오탐으로 보이는 문자열도 위치와 용도를 먼저 확인한다. 시험용 값인지, 실제 인증에 쓸 수 있는 값인지 구분해야 우회 사유를 정확히 선택할 수 있다. 특히 겉모양이 시험용처럼 보여도 외부 서비스가 발급한 유효한 토큰이면 단순히 테스트에 사용했다고 처리할 일이 아니다. 값의 성격이 불명확할 때는 우회보다 발급 기록과 사용처 확인을 우선한다.
우회가 허용됐다면 열린 경고와 닫힌 경고를 본다
저장소 푸시 보호의 기본 설정에서는 쓰기 권한이 있는 사용자가 사유를 선택해 차단을 우회할 수 있다. 우회가 이뤄지면 보안 경고가 만들어지고 감사 로그에 해당 사건이 남는다. 관리자는 차단 횟수만 보지 말고 실제로 저장소에 들어간 값, 우회한 사람과 사유를 검토해야 한다. 필요한 경우 담당자에게 자격 증명의 폐기나 교체를 요청할 수 있도록 경고 처리 상태도 기록한다.
‘나중에 고치겠다’는 사유의 우회는 열린 경고로, ‘테스트에 사용한다’거나 ‘오탐’이라는 사유의 우회는 닫힌 경고로 생성된다. 따라서 열린 경고만 보면 허용된 모든 푸시를 파악할 수 없다. 닫힌 항목도 실제 시험용 값이나 오탐인지 확인하고, 설명과 다른 유효 자격 증명이 남았다면 다시 처리한다. 감사 로그는 경고와 함께 우회가 일어난 경위를 확인할 단서가 된다.
우회 결정에 별도 승인이 필요한 저장소라면 delegated bypass를 설정해 우회할 역할이나 팀을 지정하고 다른 기여자의 요청에 검토 단계를 둘 수 있다. 완전 면제를 받은 주체의 푸시는 보호 검사를 건너뛰므로, 자동화 계정에 적용할 때도 필요한 범위만 지정한다. 누가 우회를 허용할 수 있고 허용 뒤 어떤 경고가 남는지 실제 설정과 맞춰 확인해야 한다.
차단되지 않은 비밀은 탐지 조건부터 확인한다
GitHub의 탐지 범위 안내에 따르면 공개 저장소에서 50MB를 넘는 푸시는 사전 검사를 건너뛰며, 새 비밀이 다섯 개보다 많이 감지돼도 차단 화면에는 처음 다섯 개만 표시된다. 차단 메시지의 목록을 푸시 전체의 완전한 검사 결과로 받아들이면 안 되는 이유다. 여러 파일이나 커밋을 함께 보냈다면 표시된 항목 이외에도 자격 증명이 들어 있는지 변경 범위를 살핀다.
푸시 보호는 secret scanning이 알아보는 모든 비밀을 사전에 막는 기능이 아니다. 지원되는 비밀 중에서도 차단 대상으로 선택된 식별 가능한 패턴이 적용되며, 일부 오래된 토큰 형식은 오탐 가능성 때문에 빠질 수 있다. 먼저 해당 서비스와 토큰 유형이 지원 목록에 있는지 확인하고, 같은 서비스의 오래된 형식까지 동일하게 보호된다고 가정하지 않는다. 조직 내부에서 발급하는 고유한 문자열은 기본 패턴에 없다면 맞춤 패턴과 별도의 비밀 관리 절차를 검토한다.
서로 짝을 이루는 자격 증명은 두 구성 요소가 같은 파일에서 함께 발견돼야 탐지되는 유형도 있다. 예를 들어 식별자와 비밀 값이 다른 파일에 나뉘어 들어가면 둘을 실제로 조합해 사용할 수 있어도 경고가 생기지 않을 수 있다. 이런 구조의 자격 증명을 쓴다면 한 파일만 훑는 대신 관련 설정 파일과 생성된 산출물까지 변경 범위를 확인한다. 경고가 없다는 사실보다 값이 실제 인증에 사용 가능한지가 우선 판단 기준이다.
푸시가 지나치게 크거나 이력이 복잡하면 사전 검사 시간이 초과돼 차단하지 못할 수도 있다. 시간 초과로 사전 차단이 누락된 푸시는 이후 스캔에서 비밀이 발견되면 경고가 만들어질 수 있다. 큰 푸시가 성공했다면 저장소의 사후 secret scanning 경고를 확인하고, 경고가 아직 보이지 않아도 의심되는 변경 파일은 직접 살핀다. 우회 요청에 커밋이나 파일 경로가 빠져 있다면 검사 시간 초과로 위치를 찾지 못했을 가능성이 있으므로 해당 푸시의 이력 범위를 더 넓게 확인한다.
운영할 때 확인할 순서
- 보호할 저장소에서 Secret Protection과 Push protection의 활성 상태를 확인하고, 조직의 적용 대상 목록과 대조한다.
- 차단된 푸시는 감지된 위치와 함께 전송할 커밋을 검토해 값을 제거한다. 실제 자격 증명이라면 발급 서비스에서 폐기 또는 교체가 필요한지도 판단한다.
- 우회가 발생했다면 열린 경고와 닫힌 경고를 모두 확인하고, 감사 로그의 사유와 실제 저장소에 남은 값을 대조한다.
- 차단되지 않은 의심 값은 지원 패턴, 토큰 형식, 짝을 이루는 값의 위치와 푸시 크기를 순서대로 살핀다. 큰 푸시는 사후 경고까지 확인한다.
함께 읽기:
관련 기사
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.
0