소스 코드나 비밀 정보를 노출하지 않고 AI로 소프트웨어 취약점을 분류하는 방법

저장소 전체나 실제 인증 정보를 보내지 않고도 AI를 활용해 소프트웨어 보안 문제를 조사할 수 있습니다. 관련 동작을 보존하는 승인된 최소한의 예제를 준비하고, 시크릿과 무관한 개인 데이터를 제거하고, 승인된 처리 환경을 선택한 뒤, 모든 권고 사항을 적용하기 전에 검증하세요.

주요 위험은 채팅에 API 키를 붙여 넣는 것보다 더 광범위합니다. 소스 파일, 로그, 첨부 파일, 도구 통합, 실행 환경 모두 비공개 정보를 노출하거나 의도하지 않은 액세스를 발생시킬 수 있습니다. 이 가이드는 무엇을 가리고 어떤 맥락을 유지할지, 제안된 수정이 올바른지 판단할 때 어떤 증거를 보관할지 등 반복 가능한 개발자 분류 절차를 제공합니다.

AI 채팅에 절대 붙여 넣으면 안 되는 데이터는 무엇인가요?

일반적인 모델 대화에 실제 비밀번호, 개인 키, 세션 쿠키, 액세스 토큰, 복구 코드 또는 운영 환경 연결 문자열을 붙여 넣지 마세요. 인증 확인이나 데이터베이스 호출의 작동 방식을 설명하는 데 이런 정보는 필요하지 않습니다. 분석에 필요한 구조적 특성만 유지하는 명확한 가상 값으로 대체하세요.

비공개 코드와 취약점 세부 정보도 승인을 받아야 합니다. 저장소를 볼 권한이 있더라도 외부 서비스로 전송할 권한은 없을 수 있습니다. 고객 로그에는 버그와 무관한 식별자, 비공개 메시지 또는 요청 매개변수가 포함될 수 있습니다. 스크린샷과 첨부 파일을 포함해 자료를 공유하기 전에 확인하세요.

OWASP 시크릿 관리 가이드는 시크릿 수명 주기와 액세스 제어를 참고하는 데 유용합니다. 노출된 시크릿은 단순한 형식 오류가 아니라 액세스 문제로 다루세요. 정보가 공개되었다면 프롬프트를 수정하면 노출이 해결된다고 가정하지 말고, 조직의 폐기 및 사고 대응 절차를 따르세요.

이 글은 소유한 코드 또는 승인을 받은 프로젝트의 방어적 검토에 관한 것입니다. 공개 저장소나 누구나 볼 수 있는 웹사이트가 있다고 해서 다른 사람의 배포 시스템에 테스트를 실행할 권한이 있는 것은 아닙니다. 처음부터 검토 범위와 처리 권한을 명확히 하세요.

공유 전에 코드와 취약점 데이터를 어떻게 분류해야 할까요?

검토용으로 제안된 패키지의 간단한 목록을 작성하세요. 코드, 구성, 로그, 샘플 입력, 종속성 정보, 모델에 제공할 도구 액세스를 포함하세요. 파일이 저장된 디렉터리 이름에만 의존하지 말고, 무엇을 드러내는지와 누가 처리할 수 있는지를 기준으로 내용을 분류하세요.

확인된 사실, 추정되는 사항, 의도적으로 생략한 내용을 표시하세요. 예를 들어 엔드포인트 이름은 가상으로 바꿨지만 역할 확인과 호출 순서는 바꾸지 않았다고 설명하세요. 이렇게 하면 모델이 삭제된 부분을 애플리케이션 설계의 일부로 오인하지 않습니다.

AI 개선 수명 주기 설명에서는 이 준비 단계가 분류 및 패치 검증보다 앞에 옵니다. 관련된 Hy4 분석에서는 개발자가 모델의 안전성을 주장하더라도 비공개 코드를 업로드해도 되는지는 별도로 판단해야 하는 이유를 설명합니다. 데이터 사용 권한은 별개의 결정입니다.

표지: GitHub Docs, 코드 스캔 경고 스크린샷. CC BY 4.0에 따라 변경 없이 재현. 출처 및 맥락.

호스팅 서비스 대신 로컬 모델을 사용해야 할 때는 언제인가요?

데이터 정책과 기술적 제약에 허용되는 환경을 사용하세요. 관련 데이터 처리 조건, 보존 제어, 지역 및 조직의 승인이 작업에 적합하다면 호스팅 서비스를 사용할 수 있습니다. 맥락을 통제된 환경 안에 유지해야 하고 모델이 범위가 제한된 검토를 충분히 수행할 수 있다면 로컬 모델이 유용할 수 있습니다.

두 라벨 중 어느 것도 보안 평가를 완성하지 않습니다. 로컬 런타임도 네트워크 API를 노출하거나, 프롬프트를 로그에 기록하거나, 타사 확장 기능을 불러오거나, 도구가 외부 서비스에 접근하도록 할 수 있습니다. 호스팅 코딩 도구는 붙여 넣은 텍스트보다 더 많은 저장소 맥락을 가져올 수도 있습니다. “로컬”은 격리되어 있고 “엔터프라이즈”는 모든 사용이 승인되었다고 가정하지 말고, 데이터와 작업의 전체 경로를 추적하세요.

작은 실험이라면 정제된 코드 발췌본과 쓰기 도구 없이 시작하세요. 모델의 설명을 코드 관리자의 이해와 비교하세요. 더 넓은 맥락이 필요하면 의도적으로 범위를 넓히고 그 이유를 기록하세요. 맥락 부족 문제를 한 번에 저장소와 파일 시스템에 대한 무제한 접근 권한을 부여해 해결하지 마세요.

비공개 문서 작업 흐름에서 외부로 나가는 정보 제어하기 가이드에서는 데이터 경로를 살펴보는 관련 관점을 제공합니다. 코드 분류에서도 같은 질문을 할 수 있습니다. 어떤 콘텐츠를 읽고, 어디서 처리하며, 무엇이 로그에 남고, 어떤 연동 기능이 결과를 받을 수 있나요?

유용한 맥락은 유지하면서 비밀 정보를 어떻게 가릴 수 있나요?

민감한 값 대신 관계를 보존하세요. 권한 부여 예시에는 소유권이 다른 사용자 두 명이 필요할 수 있지만, 실제 이름이나 계정 식별자는 필요하지 않습니다. 구성 문제를 보여주려면 인증이 활성화되어 있는지 나타내야 할 수 있지만, 실제 비밀번호나 서명 키까지 보여줄 필요는 없습니다.

패키지 전체에서 일관된 가명 이름을 사용하세요. 코드 예시에 사용자가 test_user_a로 나온다면 샘플 기록과 예상 결과에서도 같은 이름을 유지하세요. 일관성 없는 비식별화는 실제로 없는 버그를 만들거나 검토의 핵심인 관계를 숨길 수 있습니다.

덜 눈에 띄는 위치도 살펴보세요. 쿼리 매개변수가 포함된 URL, 인증 헤더, 예외 메시지, 주석, 픽스처 파일, 노트북 출력, 아카이브, 스크린샷 등이 여기에 해당합니다. 비밀 정보 스캐너가 도움이 될 수는 있지만, 모든 업무상 민감한 정보를 판별하거나 사용자 지정 토큰 형식이 탐지될 것이라고 보장할 수는 없습니다. GitHub의 비밀 정보 스캔 문서에서는 자동 탐지의 한 계층을 설명합니다.

정보를 정제한 뒤 두 가지를 확인해 달라고 담당자에게 요청하세요. 패키지에 불필요한 정보가 노출될 수 있는가? 관련 동작을 여전히 재현할 수 있는가? 정제된 예시가 더 이상 애플리케이션을 나타내지 못한다면 불완전하다고 표시하세요. 재현이 깨진 상태에서 확정적인 보안 결론을 내리지 마세요.

AI 도구에 꼭 필요한 최소한의 접근 권한만 부여하려면 어떻게 해야 하나요?

컨텍스트를 읽을 권한과 시스템을 변경할 권한을 분리하세요. 초기 분류 단계에는 쓰기 권한이나 네트워크를 사용할 수 있는 셸이 필요하지 않은 경우가 많습니다. 도구가 저장소를 살펴봐야 한다면 전용으로 정제된 체크아웃을 제공하거나 플랫폼에서 지원하는 범위 내에서 읽기 권한을 최소화하세요. 운영 환경 자격 증명은 해당 환경 밖에 보관하세요.

GitHub의 개인용 액세스 토큰 안내에서는 토큰 유형과 권한 제어를 설명합니다. 자격 증명을 실제 작업과 저장소에 맞추고, 적절한 만료 기간을 설정한 뒤 승인된 비밀 정보 저장소를 사용하세요. 프롬프트, 명령 예시, 커밋 또는 공유 검토 첨부 파일에 토큰을 넣지 마세요.

지침과 강제를 구분하세요. 에이전트에게 비공개 디렉터리를 무시하라고 요청해도 그 디렉터리를 읽을 수 있는 권한이 사라지는 것은 아닙니다. 제한된 마운트, 별도 계정 또는 격리된 런타임을 사용하면 문구만으로는 불가능한 경계 강제가 가능합니다. 선택한 메커니즘이 도구의 실제 운영 권한에 부합하는지 확인하세요.

외부 자료에는 작업과 상충하는 지시가 포함될 수 있습니다. OWASP의 프롬프트 인젝션 개요에서는 검색된 콘텐츠가 보안상 문제가 되는 이유를 설명합니다. 저장소 주석, 이슈 텍스트, 로그는 분석할 증거로 취급하고, 에이전트가 접근할 수 있는 비밀 정보나 시스템의 범위를 바꾸도록 두지 마세요.

AI 권고 사항을 안전하게 검증하려면 어떻게 해야 하나요?

합성 데이터를 사용하고 시작 리비전이 명확한 일회용 환경을 사용하세요. 모델에 제안된 보안 속성과 권고 사항을 뒷받침하는 증거를 설명해 달라고 요청하세요. 설정을 변경하거나 검사를 제거하라는 제안은 보안 관련 답변에 포함되었다는 이유로 수용하지 말고 소프트웨어 변경 사항으로 평가해야 합니다.

다음 준비부터 검증까지의 순서를 따르세요.

1. 저장소와 검토 작업의 소유자가 본인이거나 명시적인 승인을 받았는지 확인하세요.
2. 최소한의 재현 사례를 준비하고, 별도의 원본 사본은 수정하지 않은 상태로 보관하세요.
3. 인증 정보, 개인 데이터, 관련 없는 기밀 컨텍스트를 제거하세요.
4. 승인된 모델 환경을 선택하고, 실용적인 경우 읽기 전용의 제한적인 접근 권한부터 시작하세요.
5. 코드 참조와 가정을 독립적으로 확인하면서 설명을 검토하세요.
6. 후보 패치는 격리된 테스트 환경에만 적용하세요.
7. 금지된 동작과 계속 허용되어야 하는 정당한 동작을 모두 테스트하세요.
8. 결정, 필요한 수정 사항, 통합을 승인할 수 있는 사람을 기록하세요.

테스트를 실감 나게 만들겠다고 모델에 프로덕션 데이터를 제공하지 마세요. 중요한 것은 입력, 제어, 결과 간의 관계입니다. 합성 테스트 픽스처를 사용하면 실제 고객 기록을 노출하지 않고도 소유권, 역할별 차이, 누락된 값을 나타낼 수 있습니다.

다음 승인 단계는 agentic-autofix 검토 가이드에서 다룹니다. 재현하거나 검토할 수 없는 권고 사항은 미해결 상태로 두어야 합니다. 원래 경고가 긴급해 보인다는 이유만으로 이를 조용히 프로덕션 수정 사항으로 적용해서는 안 됩니다.

감사 및 사고 대응을 위해 팀은 무엇을 기록해야 하나요?

불필요한 비밀 정보를 보관하지 않으면서 의사결정을 이해하는 데 필요한 증거를 충분히 보관하세요. 유용한 항목에는 발견 사항 식별자, 소스 리비전, 처리 환경, 민감 정보를 제거한 컨텍스트 설명, 확인 가능한 경우 모델 또는 서비스 버전, 권고 사항, 테스트, 검토자, 최종 처리 결과가 포함됩니다. 민감한 취약점 기록은 적절한 접근 권한이 설정된 승인된 위치에 보관하세요.

모델이 볼 수 없었던 내용을 기록하세요. 하나의 헬퍼 함수만을 바탕으로 한 분석과 해당 함수의 호출부 및 설정까지 검토한 분석은 범위가 다릅니다. 결과가 가정에 따라 달라진다면 해당 가정을 의사결정 기록에 남기세요. 그렇지 않으면 나중에 보는 사람이 제한적인 결론을 애플리케이션 전체에 대한 보증으로 해석할 수 있습니다.

실용적인 완료 체크리스트는 다음과 같습니다.

• 컨텍스트 패키지에는 유효한 인증 정보나 관련 없는 개인 정보가 포함되어 있지 않습니다.
• 처리 환경과 연동 도구는 해당 자료에 사용하도록 승인되었습니다.
• 권장 사항은 근거 없는 참고 자료에 의존하지 않고 증거를 제시합니다.
• 패치의 범위가 명확하고, 검토를 거쳤으며, 유의미한 테스트와 연결되어 있습니다.
• 해결되지 않은 한계와 운영상 후속 조치에는 담당자가 지정되어 있습니다.
• 임시 권한과 보존된 자료에는 명확한 정리 또는 보존 정책이 있습니다.

시크릿이 실수로 공개되면 비밀 정보가 포함되지 않은 사고 기록을 보존하고 적절한 대응 절차를 따르세요. 승인된 내부 채널을 통해 영향을 받은 인증 정보와 노출 경로를 파악하고, 해당 정보를 폐기하거나 교체한 뒤 관련 활동을 검토하세요. 민감한 정보였는지 물어보려고 시크릿을 다른 AI 채팅에 복사하지 마세요.

최종 기록에는 해당 사항이 검증되었는지, 기각되었는지, 아니면 미해결 상태로 남았는지가 명확히 드러나야 합니다. ‘AI 검토 완료’만으로는 의미 있는 상태를 나타내지 못합니다. 상태에는 엔지니어링 결정과 누군가가 책임을 지기로 한 근거가 설명되어야 합니다.

추가 도구를 연결하기 전에 개인 에이전트 권한 체크리스트를 확인하세요. 더 큰 컨텍스트 창이 파일 시스템이나 계정에 더 광범위한 접근 권한을 부여하는 이유가 되어서는 안 됩니다.

자주 묻는 질문

API 키를 별표로 바꾸는 것만으로 충분한가요?

반드시 그런 것은 아닙니다. 다른 파일, 로그, URL, 스크린샷, 대화 기록에 민감한 자료가 포함되어 있을 수 있습니다. 전체 검토 자료와 도구가 자동으로 가져오는 컨텍스트를 확인하세요.

로컬 모델이 정보를 유출할 수 있나요?

로컬 모델도 프롬프트를 기록하거나, 엔드포인트를 노출하거나, 도구를 통해 데이터를 전송하는 시스템의 일부일 수 있습니다. 추론이 이루어지는 위치만 믿지 말고 런타임, 통합, 권한을 검토하세요.

마스킹 때문에 문제를 이해하는 데 필요한 세부 정보가 사라지면 어떻게 하나요?

관련 관계가 동일한 합성 예시를 만들거나, 필요한 컨텍스트를 다룰 수 있도록 승인된 환경에서 검토하세요. 남아 있는 불확실성은 표시하세요.

시크릿 스캔만으로 패키지를 안전하게 공유할 수 있음을 입증할 수 있나요?

아니요. 탐지 범위에는 한계가 있고, 비즈니스에 민감한 정보가 항상 인증 정보인 것은 아닙니다. 자동 스캔은 컨텍스트 검토 및 권한 검토를 보완하는 수단이어야 합니다.

AI가 자체 보안 패치를 병합하도록 허용해야 할까요?

초기 워크플로에서는 통합을 사람의 검토와 저장소 제어 아래 두세요. 이후 자동화를 도입하려면 명시적인 승인, 유의미한 테스트, 명확히 정의된 범위가 필요합니다.

결론

안전한 AI 취약점 분류는 승인된 소규모 증거 자료로 시작해 문서화된 엔지니어링 결정으로 마무리됩니다. 비밀 정보를 보호하려면 눈에 보이는 프롬프트뿐 아니라 파일, 도구, 로그, 권한에도 주의를 기울여야 합니다.

가능한 경우 합성 컨텍스트를 사용하고, 격리된 환경에서 권장 사항을 검증하며, 검토 권한과 배포 권한을 분리하세요. 이렇게 하면 범위가 좁은 보안 문제를 불필요한 접근이나 정보 공개로 확대하지 않으면서 AI가 조사에 도움을 줄 수 있습니다.