Claude Code 비밀 유출: Apiiro, 공개 GitHub 파일 1,122개에서 자격 증명 발견

Apiiro가 공개 GitHub 설정 파일 1,122개에서 자격 증명을 발견했다고 보고한 뒤, Claude Code 비밀 유출 문제로 Anthropic의 저장된 승인 기능이 면밀한 검토 대상이 됐다. 11월 5일 공개된 이 연구는 비밀 정보가 포함된 명령을 기억하는 기능을 설명한다. 다만 실제 공개까지는 결과 파일을 커밋하고 푸시하는 추가 단계가 필요하다.

이 문제의 핵심에는 유용한 단축 기능과 그것이 만들어 내는 민감한 기록 사이의 긴장이 있다. 개발자는 작업을 완료하기 위해 작업을 승인하지만, 소프트웨어는 별도의 보호가 필요한 정보를 보존한다. 실행에 관한 결정이 저장에 관한 결정으로 이어지지만, 사용자는 두 선택을 별개의 문제로 인식하지 않는 경우가 많다.

Anthropic은 이 우려를 인정하면서도 설정 파일은 로컬에 남아 있어야 한다고 강조했다. Cursor 역시 자율 실행과 그 위험을 다루는 문서를 제공한다는 점에서 유용한 비교 대상이다. 이러한 제품 전반에서 중요한 질문은 권한 시스템이 자격 증명이 축적되는 또 다른 장소를 만들지 않으면서 편의성을 어떻게 유지할 수 있느냐는 것이다.

Claude Code 비밀 유출 조사 결과가 실제로 측정한 것

Apiiro의 자격 증명 노출 연구는 .claude/settings.local.json의 공개 사본 104,185개를 조사했다. 표시된 파일 1,122개에서 서로 다른 비밀 정보 1,379개를 식별했다. 연구진은 해당 자격 증명을 실제로 테스트하지 않았으므로, 이 수치가 유효한 접근 권한이나 성공적인 침입을 입증하는 것은 아니다.

이 헤드라인은 침해된 계정이 아니라 노출된 파일을 측정한다. 이 차이는 사고 대응, 구매 결정, 그리고 조사 결과의 심각성에 관한 모든 주장에 중요하다. 자격 증명이 존재한다는 사실은 조사할 이유를 제공하지만, 그 유효성과 권한이 즉각적인 결과를 결정한다.

기저에 있는 워크플로는 익숙하다. 코딩 어시스턴트가 작업을 제안하고, 개발자가 이를 검토하며, 지속적인 승인은 이후의 중단을 줄인다. 예기치 않은 결과는 저장된 승인이 개발자가 일시적이라고 여겼던 정보를 보존할 때 나타난다.

스테이징 데이터베이스 점검을 예시 시나리오로 생각해 볼 수 있다. 개발자는 어시스턴트가 실패한 연결을 조사하도록 해야 하며, 인증 정보가 포함된 명령을 승인한다. 그 점검을 마치는 데 자격 증명이 영구적인 프로젝트 아티팩트가 될 필요는 없다.

그러나 승인 기록은 작업에 필요했던 바로 그 정보를 보존할 수 있다. 그 목적은 관리 업무처럼 들리기 때문에, 비밀번호나 액세스 토큰과 별개로 생각하기 쉽다. 검토자가 구성 파일에는 민감한 운영 데이터가 아니라 환경설정만 포함된다고 가정할 때 이러한 분리는 위험해진다.

공개 저장소는 또 다른 경계를 더한다. 이전에는 개발자의 컴퓨터에서만 이용 가능했던 정보가 프로젝트를 읽을 수 있는 누구에게나 공개된다. 따라서 승인 기능과 게시 워크플로는 별도로 검토해야 한다.

해당 옵션을 선택하면 비밀번호가 자동으로 GitHub에 전송된다고 말하는 것은 증거를 과장하는 일이다. 보고된 순서는 로컬 저장 후 프로젝트 변경을 기록하고 공유하는 시스템인 버전 관리 도구를 통한 게시로 이어진다. 각 단계에는 예방할 기회가 있다.

이 문제를 단순히 부주의한 커밋으로만 설명하는 것도 축소 해석이다. 제품 동작은 누군가 커밋할 수 있는 민감한 자료가 무엇인지 결정한다. 더 안전한 게시 워크플로도 도움이 되지만, 불필요한 자격 증명 사본을 피하는 것은 문제의 더 이른 지점을 해결한다.

관련된 변화는 팀이 검토 중 고려해야 할 사항이다. 에이전트 설정은 애플리케이션 코드 및 배포 구성과 함께 주의를 기울일 가치가 있다. 파일에 실행 가능한 프로그램이 전혀 없더라도, 보존하는 정보를 통해 보안에 영향을 미칠 수 있다.

이는 민감한 변경의 의미를 확장한다. 검토자는 파일이 애플리케이션에 무엇을 하게 하는지뿐 아니라 무엇을 드러내는지도 고려해야 한다. 권한 기록은 바로 그 교차점에 놓인다.

로컬 설정 파일은 조건이 따르는 약속이다

Anthropic의 로컬 설정 문서에 따르면 지속적인 Bash 승인은 .claude/settings.local.json의 허용 규칙이 된다. Bash는 프로그램을 실행하는 데 사용하는 명령 셸이다. Claude Code는 문서화된 조건에서 이 파일을 처음 작성할 때 개발자의 전역 Git ignore 구성에 제외 규칙을 추가한다.

문서는 별도로 .claude/settings.json을 팀이 커밋할 수 있는 공유 프로젝트 구성으로 지정한다. 수동으로 만든 로컬 파일에는 별도의 제외 규칙이 필요하다. 이러한 구분은 의도된 경계를 명확히 하지만, 파일이 어떻게 생성됐는지에도 중요성을 부여한다.

파일을 로컬이라고 부르는 것만으로는 프라이버시가 보장되지 않는다. 이름은 사람에게 의도를 전달하지만, 저장소 제어 방식은 해당 파일이 프로젝트와 함께 이동하는지를 결정한다. 두 보호 장치는 연관돼 있지만 실패 조건은 다르다.

전역 제외 규칙은 개발자 환경에 속한다. 프로젝트 수준의 제외 규칙은 저장소 워크플로에 속한다. 팀이 보안 관행이 컴퓨터, 기여자 또는 개발 환경의 변화에도 유지되기를 기대할 때 이 차이는 중요하다.

프로젝트 인계를 분석적 예시로 생각해 보자. 원래 작성자는 어떤 파일에 개인 상태가 담겨 있고 어떤 파일이 소스 제어에 속하는지 알고 있다. 새 기여자는 반드시 같은 이해를 물려받지 않은 채 디렉터리 구조를 보게 된다.

모든 기여자가 동일한 구분을 다시 파악해야 할 때 문제는 조직적 차원으로 번진다. 개인 지식에 의존하는 규칙은 반복적인 주의를 요구한다. 공유 프로젝트 정책으로 표현된 규칙은 검사하고 논의하기가 더 쉽다.

어느 접근 방식도 커밋에 포함되는 내용을 검토할 필요를 없애지는 않는다. 제외 규칙은 예방적 관행인 반면, 커밋된 변경은 실제 게시 결정이다. 팀은 둘 중 하나가 존재한다고 해서 다른 하나까지 보장된다고 가정하지 말고 모두 평가해야 한다.

용어에도 주의가 필요하다. 설정은 보통 표시 옵션이나 편집기 동작처럼 무해한 환경설정을 떠올리게 한다. 권한 파일은 그 내용이 실제 작업에서 비롯되기 때문에 훨씬 더 민감한 기록을 담을 수 있다.

이 불일치는 제품 설계에 부담을 준다. 소프트웨어가 명령 인수를 보존한다면, 사용자가 그 파일을 일반 구성으로 취급하기 전에 이러한 지속성을 이해하도록 도와야 한다. 관련 경고는 기록을 만드는 결정 가까이에 있어야 한다.

여기에는 정당한 사용성 제약도 있다. 모든 구현 세부 사항을 검사하도록 요구하면 어시스턴트 사용이 더 어려워지고 피상적인 승인을 부추길 수 있다. 설계 과제는 작업 자체를 압도하지 않으면서 중요한 결과를 드러내는 것이다.

기업 구매자에게 이는 구체적인 평가 질문이 된다. 관리자는 어떤 에이전트 파일을 공유해도 안전한지, 어떤 파일은 개인적으로 남아야 하는지, 어떤 파일에 민감한 데이터가 포함될 수 있는지를 설명할 수 있는가? 제품의 답변은 직원들이 실제로 사용하는 저장소 제어 방식과 일치해야 한다.

문서를 통해 설명되는 Claude Code 권한은 의도된 모델을 제시한다. 실질적인 시험은 그 모델이 일상적인 협업 중에도 이해하기 쉬운 상태로 유지되는지다. 문서는 기대를 설정하지만, 관찰 가능한 동작이 팀이 이를 안정적으로 따를 수 있는지를 결정한다.

이 단축 기능은 반복적인 프롬프트를 지속적인 데이터와 맞바꾼다

지속적인 승인의 편의성은 이해하기 쉽다. 개발자는 어시스턴트가 모든 단계에서 중단하지 않고 일상적인 작업을 계속하기를 원한다. 같은 결정을 반복해서 요청하는 시스템은 사용자가 더 광범위하거나 오래 지속되는 권한을 찾도록 유도한다.

핵심적인 상충 관계는 더 적은 중단과 이를 가능하게 하기 위해 보존되는 정보 사이에 있다. 인터페이스가 둘을 함께 제시하더라도 실행 권한과 자격 증명 저장은 별도의 결정이 필요하다.

설계를 평가하는 유용한 방법은 기능과 데이터를 분리하는 것이다. 기능은 에이전트가 승인된 개발 작업을 실행하는 것처럼 무엇을 할 수 있는지를 설명한다. 데이터에는 실행 중 제공되는 구체적인 인수와 인증 자료가 포함된다.

기능을 보존하기 위해 모든 데이터를 보존해야 하는 것은 아니다. 그러나 인수를 제거하면 규칙의 의미가 바뀔 수 있다. 더 광범위한 승인은 사용자가 전혀 의도하지 않았던 작업을 허용해 또 다른 보안 문제를 만들 수 있다.

따라서 저장된 명령에서 의심스러운 텍스트를 단순히 삭제하는 것만으로는 완전한 설계 명세가 될 수 없다. 제품은 불필요한 보존을 피하면서 사용자가 의도한 범위를 유지해야 한다. 이후 작업이 다시 권한을 요청할 때도 그 동작은 이해하기 쉬워야 한다.

자격 증명 참조는 또 다른 설계 방향을 제공한다. 명령은 값을 직접 포함하는 대신 별도로 제공된 값을 참조할 수 있다. 그러면 승인 기록에 자격 증명 자체가 포함될 필요가 줄어든다.

참조 방식도 주의가 필요하다. 프로그램이 확인된 값을 출력할 수 있고, 오류 메시지가 이를 드러낼 수 있으며, 다른 아티팩트가 출력을 보존할 수도 있다. 하나의 기록에서 평문 비밀번호를 피한다고 해서 노출은 줄어들지만 완전한 보호가 보장되는 것은 아니다.

바로 이 지점에서 이야기는 특정 버튼을 넘어 중요해진다. 에이전트 소프트웨어는 연속성, 디버깅, 협업을 지원하기 위해 기록을 만든다. 모든 기록에는 내용에 비례하는 명확한 목적, 대상 독자, 보존 정책이 있어야 한다.

어시스턴트의 겉보기 기억 기능은 이러한 질문을 가릴 수 있다. 사용자는 작업을 계속하는 대화를 경험하지만, 구현은 서로 다른 공유 규칙을 가진 파일을 만들 수 있다. 제품 팀은 중요한 경계를 눈에 띄게 만들어야 한다.

Cursor의 백그라운드 에이전트 보안 문서는 유용한 비교를 제공한다. 이 문서는 격리된 가상 머신, 인터넷 접근, 자동 터미널 실행을 설명한다. 또한 신뢰할 수 없는 콘텐츠가 에이전트의 동작 방향을 바꾸는 프롬프트 인젝션을 통해 악의적인 지시가 데이터 탈취로 이어질 수 있다고 경고한다.

이 비교가 Cursor가 Claude Code의 보고된 승인 저장 동작을 공유한다는 사실을 입증하는 것은 아니다. 이는 경쟁 제품의 설계가 실행, 격리, 사용자 검토 전반에 걸쳐 책임을 서로 다르게 배분한다는 점을 보여 준다. 구매자는 승인 방식만으로 제품을 선택하기보다 이러한 메커니즘을 별도로 비교해야 한다.

격리는 작업이 실행되는 환경을 제한한다. 승인은 작업의 진행 여부를 결정한다. 자격 증명 처리는 어떤 민감한 데이터가 환경에 들어가고 이후 어떤 기록이 남는지를 결정한다.

이러한 제어 장치는 경계가 명확할 때 서로를 보완한다. 한 계층에서 성공적인 결정이 다른 모든 계층도 안전하다는 증거로 취급될 때 혼란스러워진다. 승인된 작업도 여전히 부적절한 기록을 남길 수 있다.

따라서 Claude Code 보안 위험은 워크플로 수준에서 평가해야 한다. 유용한 질문은 승인된 작업이 어떤 정보를 만들고, 그 정보가 어디에 지속되며, 나중에 누가 이를 검색할 수 있는가이다.

Anthropic은 격차를 인정했지만, 자동 모드는 해결을 보증하는 증명서가 아니다

Claude Code 팀의 Boris Cherny는 권한 안전성 논의에서 해당 보고서에 답했습니다. 그는 Claude Code에 과거 비밀정보 정리 기능이 없었다며 자동 모드와 리포지토리 비밀정보 스캔을 권장했습니다. 또한 기본적인 비밀정보 탐지를 포함해 프로토타이핑 과정에서 적용할 수 있는 보호 장치도 설명했습니다.

한 독자는 자동 모드에서도 문제가 된 승인 경로에 도달할 수 있는지 물었습니다. Cherny는 그 지적을 인정했습니다. 그의 발언은 적극적으로 대응하고 있음을 보여주지만, 포괄적인 수정이 이미 배포됐다는 것을 입증하지는 않습니다.

제안된 보호 장치는 방지하려는 실패 사례를 기준으로 검증해야 합니다. 수동 승인을 줄이는 일과 자격 증명의 영구 저장을 막는 일은 서로 관련돼 있지만, 수용 기준은 다릅니다. 한쪽에 대한 증거가 다른 쪽의 증거를 대신해서는 안 됩니다.

회의적인 관점은 간단합니다. 민감한 작업이 여전히 자격 증명을 포함한 승인 기록을 만든다면, 기본 실행 모드를 바꿔도 그 경로는 여전히 중요합니다. 대응책은 프롬프트 빈도뿐 아니라 그로 인해 생성되는 산출물도 다뤄야 합니다.

Anthropic이 권한 중단을 줄이는 데 집중하는 데에도 타당한 이유가 있습니다. 반복되는 프롬프트는 신중한 검토로 이어지지 않은 채 주의력을 소모할 수 있습니다. 다만 그러한 개선이 포괄적인 보안 주장으로 바뀌어서는 안 됩니다.

이견은 부분적으로 통제가 어디에 있어야 하는지에 관한 것입니다. 일부 사용자는 에이전트의 해석과 관계없이 유지되는 고정된 제한을 원합니다. 다른 이들은 일상적인 활동과 민감한 작업을 구분할 수 있는 자동 평가를 선호합니다.

이러한 접근 방식은 저장된 기록에 비밀번호가 포함되는지와는 다른 질문에 답합니다. 엄격한 실행 경계는 과도한 데이터 보존과 공존할 수 있습니다. 자동 검토 도구는 중단을 줄일 수 있지만, 무엇을 디스크에 기록할지에 관한 명시적 규칙은 여전히 필요합니다.

엔터프라이즈 평가는 이 질문들을 분리해서 다뤄야 합니다. 구매자는 자동 작업 실행을 중요하게 여기면서도 예측 가능한 저장 동작을 요구할 수 있습니다. 제품은 고객에게 한쪽으로 다른 쪽을 추론하라고 요구하는 대신, 관찰 가능한 결과를 통해 둘 다 입증해야 합니다.

신뢰할 수 있는 검증은 통제된 프로젝트에서 인공 자격 증명을 사용하는 방식이 될 수 있습니다. 작업 후 승인 기록과 그 밖의 생성된 산출물을 점검해야 합니다. 민감한 로컬 파일이 이미 추적되고 있을 때의 동작도 확인해야 합니다.

이는 Anthropic이 완료한 테스트에 대한 주장이 아니라 제안된 평가 조건입니다. 유망한 대응과 입증된 개선을 구분하는 데 필요한 증거를 설명합니다. 공개된 결과가 있다면 고객은 변경 사항의 범위를 판단할 수 있습니다.

Claude Code의 비밀정보 유출은 커뮤니케이션 과제도 드러냅니다. 사용자에게 다른 통제를 활성화하라고 조언하는 것은 유용하지만, 제품 자체가 어떤 책임을 맡을지는 여전히 불분명합니다. 명확한 릴리스 노트는 새 보호 기능과 남아 있는 조건을 모두 설명해야 합니다.

가장 공정한 결론은 제한적이면서도 실행 가능해야 합니다. Anthropic은 우려를 인지하고 있고, 사용자들은 관련된 예외 사례를 제기했으며, 제안된 변경의 효과는 관찰이 필요합니다. 현재 이용 가능한 증거로는 이를 일축하거나 완전한 해결을 선언하는 어느 쪽도 적절하지 않습니다.

보안 팀은 다른 종류의 리포지토리 검토를 맡게 됩니다

보안 팀의 즉각적인 압박은 가시성과 관련됩니다. 애플리케이션 검토는 흔히 프로덕션에서 실행되는 코드에 집중합니다. 에이전트가 생성한 설정은 애플리케이션 자체의 동작이 바뀌기 전에도 노출을 만들 수 있습니다.

검토는 개발 워크플로 전반에서 민감한 정보를 따라가야 합니다. 구성 파일은 내용과 대상 위치를 기준으로 검토받아야 합니다. 관리 목적이라고 해서 그 안의 정보가 무해해지는 것은 아닙니다.

GitHub의 푸시 보호는 지원되는 비밀정보 탐지를 게시 전에 차단합니다. 해당 문서는 공급자별 패턴, 일반 패턴, 사용자 지정 패턴, AI 탐지 패턴을 구분하며, 각각의 구성 요구사항이 다를 수 있음을 설명합니다. 따라서 팀은 모든 자격 증명이 탐지될 것이라 가정하지 말고, 실제로 활성화한 범위를 검증해야 합니다.

스캐너의 존재와 스캐너가 입증한 적용 범위는 서로 다른 증거입니다. 식별 가능한 서비스 토큰과 명령어에 포함된 일반 비밀번호는 서로 다른 탐지 과제를 제시합니다. 인공 예시를 활용한 테스트는 구성된 시스템이 팀이 실제로 사용하는 패턴을 인식하는지 보여줄 수 있습니다.

이는 개발자와 보안 담당자 사이의 대화를 바꿉니다. 개발자에게는 계속 기능하는 워크플로가 필요합니다. 보안 팀에는 민감한 값이 공유를 목적으로 하는 자료에 조용히 유입되지 않는다는 증거가 필요합니다.

공동의 목표는 반복 가능한 경계여야 합니다. 개인 에이전트 상태에는 명시적인 저장 위치가 있어야 하고, 공유 설정에는 명확한 검토 기준이 있어야 하며, 탐지된 자격 증명은 이를 폐기할 수 있는 담당자에게 전달돼야 합니다.

사고 대응에서도 차단과 정리를 구분해야 합니다. GitHub의 민감한 데이터 제거 지침은 노출된 자격 증명의 폐기 또는 교체를 우선시합니다. 과거 기록을 제거하려면 조율이 필요하며, 복제본, 포크 및 다른 참조에 사본이 남을 수 있다고 설명합니다.

이 순서는 자격 증명과 그 자격 증명을 포함한 문서의 차이를 반영합니다. 문서를 수정하면 해당 위치에서 독자가 보는 내용이 바뀝니다. 자격 증명을 폐기하면 해당 자격 증명이 계속해서 접근을 승인할 수 있는지가 바뀝니다.

압박을 받는 팀에서는 문제가 된 파일이 최신 보기에서 사라지기 때문에 눈에 보이는 정리가 완료처럼 느껴질 수 있습니다. 중요한 보안 결과는 노출된 값이 여전히 권한을 보유하는지 여부입니다. 과거 기록 정리와 접근 검토는 추가적인 결과를 다룹니다.

기록을 발견한 사람이 소유자를 식별할 수 없으면 책임 소재는 더 복잡해집니다. 개발자는 프로젝트 이름을 알아볼 수 있지만 어떤 시스템이 토큰을 발급했는지는 모를 수 있습니다. 명확한 소유권은 탐지에서 효과적인 차단까지의 경로를 단축합니다.

팀에는 비밀정보를 보존하지 않고 교훈을 보존하는 방법도 필요합니다. 사고 기록에는 영향을 받은 워크플로, 담당 서비스, 예방 변경 사항을 설명할 수 있습니다. 설명을 구체화한다는 이유로 민감한 값을 복사해서는 안 됩니다.

이 구분은 검색 가능한 지식 베이스에도 적용됩니다. 유용한 엔지니어링 지식에는 승인된 절차와 과거 실패에 대한 설명이 포함됩니다. 자격 증명은 일반 참조 자료가 아니라 접근 관리를 위해 설계된 시스템에 보관해야 합니다.

Claude Code의 보안 위험은 대응에 담당자가 지정될 때 더 쉽게 관리할 수 있습니다. 개발자는 작업을 설명하고, 플랫폼 팀은 리포지토리 규칙을 강제하며, 서비스 소유자는 접근 자격 증명을 교체할 수 있습니다. 보안 담당자는 조사 중에 이 모든 관계를 재구성할 필요가 없어야 합니다.

실질적인 조직 변화는 더 넓은 검토 범위입니다. 팀은 어시스턴트가 수정한 것뿐 아니라 남긴 것도 점검해야 합니다. 그렇게 하면 지속되는 에이전트 상태가 일반적인 엔지니어링 거버넌스의 일부가 됩니다.

노출 경로가 닫히고 있음을 무엇으로 입증할 수 있을까요?

다음으로 유용한 증거는 제품 동작, 리포지토리 통제, 복구 결과에서 나와야 합니다. 이러한 신호는 보고된 과정의 서로 다른 부분을 다룹니다. 함께 살펴보면 원래의 노출 경로를 재현하기가 더 어려워졌는지 보여줄 수 있습니다.

진전은 저장 방지와 자격 증명 권한 축소로 측정해야 합니다. 발표 문구만으로는 어느 결과도 입증할 수 없습니다. 가장 강력한 증거는 특정 보호 장치를 관찰 가능한 변화와 연결합니다.

첫째, 민감한 승인이 저장되는 방식을 바꾸는 문서화된 Claude Code 릴리스를 주시해야 합니다. 결정적인 세부 사항은 정상적인 명령에 인증 정보가 포함됐을 때 어떤 일이 발생하는지입니다. 릴리스는 생성되는 기록과 여전히 사용자 개입이 필요한 상황을 설명해야 합니다.

합성 비밀정보가 더 이상 저장된 승인에 나타나지 않는다는 증거는 의미 있는 제품 개선이라는 주장을 강화할 것입니다. 같은 값이 대체 권한 경로에서 계속 남는다는 증거는 그 결론의 범위를 좁힐 것입니다. 두 결과 모두 더 안전한 자동화에 관한 일반적 발언보다 더 많은 정보를 제공합니다.

테스트 범위는 표면적인 동작만큼 중요합니다. 새 프로젝트와 기존에 추적되는 설정 파일이 있는 리포지토리는 서로 다른 시작 조건을 나타냅니다. 명확한 설명은 보호 기능이 어떤 조건을 포괄하는지 밝혀야 합니다.

둘째, 에이전트 구성과 명령어에 포함된 자격 증명에 대한 적용 범위를 보여주는 리포지토리 통제를 주시해야 합니다. 여기에는 명확한 제외 정책과 검증된 비밀정보 탐지가 포함됩니다. 의미 있는 결과는 게시 시도가 중지되는지, 아니면 효과적인 검토 절차로 전달되는지입니다.

정책 문서만으로는 실행 여부가 불확실합니다. 인공 자격 증명이 예상된 대응을 유발한다는 통제된 실험은 더 강한 증거를 제공합니다. 반복적인 누락은 보완 통제로서의 스캔에 대한 신뢰를 약화시킬 것입니다.

이 신호는 경쟁사에도 중요합니다. 공급업체는 실행 환경을 서로 다르게 설명할 수 있지만, 보존되는 산출물을 어떻게 다루는지도 설명해야 합니다. 생성 파일, 공유 경계, 자격 증명 처리에 관한 명확한 문서는 구매자에게 비교를 더 유용하게 만듭니다.

셋째, 제거된 파일과 무효화된 자격 증명을 구분하는 복구 보고를 주시해야 합니다. 리포지토리의 외관은 쉽게 관찰할 수 있지만, 접근 권한의 지속 여부에는 담당 서비스의 정보가 필요합니다. 신뢰할 수 있는 후속 조치는 이 결과들을 분리해 다뤄야 합니다.

Apiiro의 결과는 여기에서 독립적으로 재현되지 않았으며, 해당 수집 자료를 모든 Claude Code 프로젝트의 무작위 표본으로 취급해서는 안 됩니다. 보고된 모집단은 공개적으로 발견 가능한 파일로 구성됩니다. 이는 더 넓은 사용자 기반에서 노출이 얼마나 널리 퍼졌는지에 관한 결론을 제한합니다.

이러한 한계가 핵심 엔지니어링 우려를 없애지는 않습니다. 운영 맥락을 보존하는 기능에는 민감한 데이터에 대한 명확한 정책이 필요합니다. 사용자는 마감 기한 중에 구현을 재구성하지 않고도 그 정책을 이해할 수 있어야 합니다.

Claude Code의 비밀정보 유출을 평가하는 팀이라면, 먼저 실제 워크플로가 만드는 승인 기록부터 확인해야 합니다. 합성 자격 증명을 사용해 무엇이 남는지 살펴본 뒤, 어떤 통제가 해당 자료가 공유 리포지토리에 도달하는 것을 막는지 검증하세요. 실제 노출로 문제가 불거지기 전에 소유권을 지정하세요. 민감한 값을 재현하지 않고도 동료가 따를 수 있는 절차로 결과를 보존하세요. 실제 자격 증명이 공유 자료에 나타나면, 그 자격 증명의 남은 권한이 담당 서비스 소유자가 가장 먼저 확인해야 할 질문입니다. 공급업체에는 실행뿐 아니라 저장까지 다루는 증거를 요구하세요. 가장 유용한 다음 검토는 한 가지 구체적인 질문에 답하는 것입니다. 승인된 작업이 끝난 뒤 어떤 민감한 정보가 남으며, 누가 그것에 접근할 수 있는가?