클론 전에 GitHub 저장소를 점수로 살펴보는 AWS 에이전트를 만들었습니다

RepoPilot은 공개 GitHub 저장소의 설치 단계와 활동 정보를 분석해 0~100점으로 평가하고, 위험 신호와 첫 실행 절차를 안내합니다. 점수 산정은 Python 규칙으로 처리하고 Amazon Nova Pro는 결과를 설명하는 데만 사용합니다. 작성자는 압축 파일이나 바이너리 안쪽까지 검사하지 않는 한계도 밝힙니다.

주제: 보안 개발 도구 AWS

에디터 노트

RepoPilot의 점수는 안전 판정이라기보다 설치 전 위험 신호를 정리하는 도구로 읽어야 합니다. 작성자는 점수 계산을 언어 모델에서 분리하고 설치 명령의 위험 패턴을 규칙으로 검사하며, ollama/ollama 사례에서도 악성 판정과 원격 스크립트 실행 경고를 구분합니다. 다만 압축 파일과 바이너리 내부는 검사하지 않고 평판 정보는 새 릴리스의 변화를 늦게 반영합니다. 댓글은 점수의 책임 문제와 프롬프트 인젝션 가능성을 묻고, 코드가 거의 없는 저장소의 평가 방식도 질문합니다. 본문에는 특정 패턴을 차단한다고 적혀 있지 않아 현재 설명된 기능은 경고와 실행 안내에 한정됩니다.

AI 요약

AI 코딩 도구가 추천한 GitHub 저장소를 바로 클론하거나 설치하는 관행이 공급망 공격의 통로가 될 수 있습니다. 글은 Island가 FakeGit이라고 부른 캠페인에서 악성 저장소 약 7,600개와 가짜 프로필 약 6,600개가 발견됐고, 릴리스 파일 다운로드가 1,400만 건을 넘었다고 설명합니다. 그중 800개 이상은 AI 스킬이나 MCP 서버를 가장했습니다. Island의 테스트에서는 Claude Code, Gemini, ChatGPT가 사용자가 링크를 주지 않았는데도 악성 저장소를 추천한 사례가 있었다고 합니다.

RepoPilot의 점수와 검사 방식

RepoPilot에 저장소 경로를 입력하면 0~100점으로 점수를 매기고 위험한 설정 단계와 주요 문제를 표시합니다. 점수는 안전성 30%, 신뢰도 25%, 유지보수 20%, 성숙도 15%, 문서화 10%의 다섯 항목으로 나뉩니다. 안전성 항목은 설치 절차에서 악성코드에 악용될 수 있는 패턴을 살피며, 치명적인 문제가 하나라도 나오면 전체 등급에 상한을 둡니다. 신뢰도 항목은 별 수와 저장소 나이의 관계, 포크와 기여자 정보 등을 확인해 가짜 별 패턴을 찾습니다. 유지보수는 최근 커밋과 이슈, 릴리스 주기를 보고 성숙도는 저장소 나이와 기여자 수 등을 반영합니다. 문서화는 README의 상세도와 라이선스, 예제를 확인합니다.

점수만 내놓고 끝내지 않습니다. 저장소를 클론해 실행하는 순서를 제시하고 필요한 도구 버전도 알려줍니다. 명령이 실패하면 오류 원인과 다음 조치를 쉬운 문장으로 설명합니다. 사용자 이름을 입력하면 개발자 프로필과 주요 저장소도 별점 순으로 보여줍니다.

AWS 구성과 개발 과정

웹 에이전트는 AWS Lambda의 Python 3.12에서 실행하고 Amazon API Gateway로 웹 UI와 연결합니다. 추론과 설명에는 Amazon Bedrock의 Amazon Nova Pro를 쓰며, 로컬 CLI에는 Strands Agents SDK를 사용합니다. 일곱 개의 순수 Python 도구가 데이터를 모으고 점수 엔진이 결과를 계산합니다. 언어 모델은 도구가 만든 사실을 설명할 뿐 점수를 결정하지 않습니다. 글쓴이는 점수와 위험 표시, 버전 감지를 AWS 없이 단위 테스트할 수 있도록 이 구조를 택했다고 설명합니다.

Lambda 배포 과정에서는 requests를 패키지에 포함했다가 함께 들어온 urllib3가 Python 3.12에서 제거된 모듈을 불러오는 문제를 겪었습니다. GitHub 정보를 가져오는 코드를 표준 라이브러리로 다시 작성해 패키지 크기를 400KB에서 13KB로 줄였습니다. 위험 탐지기는 처음에 문서에 적힌 127.0.0.1을 위험한 주소로 오인했습니다. 로컬호스트와 사설 IP 범위는 제외하고 공개 IP 설치 패턴은 계속 잡도록 수정했습니다. 테스트는 25개이며, 무작위 저장소 200개를 넣어 가중치 계산과 치명적 위험에 따른 점수 상한을 확인합니다.

시연 결과와 한계

배포된 Lambda로 Flask 저장소의 파일 236개를 가져와 98점, A 등급을 매겼습니다. Python 스택을 감지했고 pyproject.toml에서 Python 3.11 이상 조건도 읽었습니다. langchain-ai/langchain은 100점을 받았고 ollama/ollama는 공식 설치 절차의 curl 파이프 실행 때문에 D 등급을 받았습니다. 글쓴이는 Ollama를 악성 저장소로 판정한 것이 아니라 원격 스크립트를 셸에 바로 전달하는 설치 방식을 확인하라는 뜻이라고 구분합니다. @torvalds를 입력했을 때는 Linus Torvalds의 프로필과 저장소 별점 합계 약 26만 개를 보여줬습니다.

RepoPilot은 저장소 표면을 검사하며 압축 파일을 풀거나 바이너리를 분석하지 않습니다. 높은 점수도 안전을 보증하지 않습니다. 별점과 나이를 쌓은 저장소가 새 릴리스에서 악성으로 바뀌면 평판 정보가 실제 상태를 따라가지 못할 수 있고, 공격자가 계정을 오래 운영하면 가짜 별 탐지를 피할 수 있습니다. 작성자는 이 도구를 눈에 띄는 위험을 빠르게 찾는 점검으로 설명하며, 실제 권한을 부여해 실행할 코드라면 직접 검토하라고 덧붙입니다.

dev.to 반응

@alexcodebytes — AgentBaiting이라는 개념은 공격자가 에이전트를 침해할 필요 없이 에이전트가 읽고 신뢰하는 README만 작성하면 된다는 점에서 무섭습니다. 한 가지 짚고 싶은 점은 0~100점이 사용자 경험에는 좋지만 블랙박스라는 것입니다. 점수가 "82점, 실행해도 안전함"이라고 나왔고 사용자가 실행했는데 자격 증명을 훔쳐 간다면 누가 책임지나요? 언어 모델로 만든 도구가 저장소의 프롬프트 인젝션에 속을 수 있는데, "신뢰해도 안전하다"는 주장은 강합니다. 점수는 "직접 검토" 안내를 붙인 권고일 뿐인가요, 아니면 curl | bash, preinstall 스크립트, 난독화한 postinstall처럼 특정 패턴을 실제로 차단하나요?
@unfiltered_anshul — 가짜 저장소 7,600개라니 엄청난 숫자네요. 클론부터 하고 나중에 질문하는 습관은 사람들이 피해를 보는 전형적인 방식입니다. 저도 비슷한 습관이 있습니다. 예전에는 저장소를 클론하고 나서 확인했지만 이제는 먼저 README를 읽고 별점과 커밋 기록을 살펴봅니다. 클론 전에 저장소를 점수화하는 방식은 맞는 접근입니다. README는 훌륭하지만 실제 코드가 없는 저장소는 에이전트가 어떻게 처리하나요?

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗