AI 에이전트가 작성한 코드를 실행하기 전에 확인해야 할 다섯 가지 사항
요약
AI 에이전트가 생성한 코드는 편리하지만, 사용자의 권한으로 실행되므로 보안 위험을 내포합니다. 본문은 에이전트가 작성한 코드를 실제 개발 환경에서 실행하기 전 반드시 확인해야 할 다섯 가지 주요 보안 취약점과 검증 방법을 제시합니다.
핵심 포인트
- 요청하지 않은 의존성(패키지) 추가 여부를 확인하세요.
- 신뢰할 수 없는 설정 명령어(`curl | sh` 등)가 포함되었는지 점검해야 합니다.
- 프로세스를 실행하는 모든 설정 파일(hooks, tasks.json 등)을 검토해야 합니다.
- 자동화 도구인 `am-i-hacked`와 `secure-semgrep`을 활용하여 보안 검사를 수행할 수 있습니다.
코딩 에이전트는 충분히 뛰어나서, 단순히 diff를 받아들이고 npm install을 실행한 다음 개발 서버를 시작하고 싶은 유혹을 느낍니다. 대부분의 경우 괜찮습니다. 문제는 그렇지 않은 시간도 있다는 것이며, 왜냐하면 에이전트는 사용자의 권한을 가지고 있고 사용자가 본 적 없는 텍스트까지 읽기 때문입니다.
제가 에이전트가 생성한 것을 실행하기 전에 확인하는 다섯 가지 장소가 있습니다.
1. 요청하지 않은 의존성 (Dependencies you didn't ask for)
어시스턴트는 때때로 존재하지 않거나, 실제 패키지 이름과 한 글자 차이가 나는 패키지 이름을 제안합니다. 공격자들이 이러한 이름을 등록합니다. package.json이나 requirements.txt에 새 항목이 추가될 때마다, 그것이 의도한 패키지인지 그리고 실제로 이력이 있는지 확인해야 합니다.
Advisory scanner (npm audit, OSV-Scanner)를 실행하는 것은 여전히 가치가 있지만, 이것들은 보고된 문제에 대해서만 알고 있습니다. 완전히 새로운 악성 패키지는 아직 어드바이저리(advisory)가 없습니다.
2. 어디선가 복사한 설정 명령어 (Setup commands copied from somewhere)
curl ... | sh, 새로운 postinstall 스크립트, 에디터 태스크 등입니다. 웹을 검색하는 에이전트는 신뢰할 수 없는 페이지가 실행하라고 지시하는 모든 것을 반복할 수 있습니다. 에이전트가 추가하거나 변경한 모든 스크립트 항목을 읽어야 합니다.
3. 프로그램을 실행하는 설정 파일 (Config that runs programs)
에이전트 후크(Agent hooks), MCP 서버 정의, .claude/settings.json, .mcp.json, .vscode/tasks.json, *.config.js 등이 있습니다. 이 모든 것은 프로세스를 시작하며, 그 어떤 것도 diff 검토에서
첫 번째 검사 자동화하기
이러한 목적을 위해 저는 두 가지 오픈 소스 도구를 유지하고 있습니다. 둘 다 npx로 실행되며 계정이 필요하지 않습니다.
**am-i-hacked**는 프로젝트를 악성 코드 징후(auto-run editor tasks, 다운로드하거나 디코딩하는 설치 스크립트, 난독화된 페이로드, 에셋으로 위장된 실행 파일, 유출 엔드포인트와 쌍을 이루는 캡처 코드, 그리고 프로젝트 자체의 AI 도구 설정)를 읽어 분석합니다.
npx am-i-hacked
개발 서버 앞에 배치하여 항상 실행되도록 할 수 있습니다:
{ "scripts": { "dev": "am-i-hacked && next dev" } }
**secure-semgrep**은 AI 에이전트 코드를 위한 번들 규칙을 사용하여 Semgrep을 실행합니다: 하드코딩된 제공자 키(hardcoded provider keys), exec로 전달되는 모델 출력, 시스템 프롬프트 내 사용자 입력, MCP 명령어 주입 및 도구 오염(tool poisoning), 위험한 에이전트 훅(risky agent hooks), SKILL.md 파일의 프롬프트 주입 등입니다. 또한 사용자의 스택에 대한 Semgrep 자체 보안 패키지를 추가합니다. 실행하려면 semgrep이 설치되어 있어야 합니다.
npx secure-semgrep -L ts -L node .
npx secure-semgrep -L ssrf . # opt-in SSRF rules
두 도구 모두 발견 시 종료 코드 1을 반환하므로 CI(Continuous Integration) 파이프라인에서 실패 처리됩니다.
이 도구들이 하지 않는 것들
두 도구 모두 에이전트가 무엇을 요청했는지 알지 못합니다. 스캔은 알려진 패턴을 찾을 뿐이며, 코드가 정확하거나 안전하다는 것을 증명하지 않습니다. 두 도구 모두 설치된 node_modules를 스캔하지 않습니다. 또한 백신 프로그램도 아닙니다. 이들은 어디를 살펴봐야 할지 알려주는 첫 번째 검사일 뿐이며, 여전히 diff(차이점)를 읽어보는 것이 가장 중요한 확인 과정입니다.
AI 규칙이 무엇을 다루는지에 대한 표가 포함된 전체 가이드에서는 다음을 참고하세요: Is AI-generated code safe to run? How to check it first.
모든 것은 MIT 라이선스입니다: github.com/IsaacBell/secure-devtools.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기