왜 당신의 “Skill Scanner”는 단지 거짓 보안(그리고 어쩌면 악성코드)일 뿐인가

Source: Dev.to

위의 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

AI 빌더일 수도 있고, CISO일 수도 있습니다.

당신은 방금 개발 팀을 위해 AI 에이전트 사용을 승인했습니다. 데이터 유출, 프롬프트 인젝션, 검증되지 않은 코드 실행 같은 위험을 잘 알고 있죠. 그래서 리드 엔지니어가 “걱정 마세요, 우리는 ClawHub의 Skill Defender로 모든 새로운 Skill을 스캔하고 있어요.” 라고 말하면 한숨을 돌립니다. 체크박스도 체크했으니.

하지만 이 Skills 스캐너를 확인해 보셨나요?

당신이 느끼는 불안은 알려진 위협 때문이 아니라, 그 위협을 찾아줄 도구에 대한 신뢰 때문입니다. 안전망에 구멍이 많다는 끊임없는 의심이죠. 오늘날의 “AI Skill Scanners”가 바로 그 의심을 정당화합니다.

Agent Skills와 그 보안 위험에 익숙하지 않다면, 우리는 이전에 Skill.md 위협 모델을 정리하고 이것이 AI 에이전트 생태계와 공급망 보안에 어떤 영향을 미치는지 설명했습니다.

왜 정규식으로 SKILL.md의 악의적 의도를 스캔할 수 없는가

AI 보안의 적은 해커뿐만 아니라 언어의 무한한 가변성이다.

전통적인 AppSec 세계에서는 알려진 취약점(예: CVEs)과 알려진 패턴(예: 비밀 키)을 스캔한다. 이는 코드가 구조화되고, 유한하며, 결정론적이기 때문에 가능하다. SQL‑인젝션 페이로드는 인식 가능한 구조를 가지고 있다. 유출된 AWS 키는 특정 형식을 가진다.

하지만 AI‑에이전트 스킬은 자연어 프롬프트, 코드 실행, 설정이 뒤섞인 형태다. “나쁜 단어”나 금지된 패턴의 차단 리스트에 의존하는 것은 자연어라는 무한한 말뭉치에 맞서는 패배한 전쟁이다. LLM에게 위험한 작업을 시키는 모든 가능한 방법을 열거할 수는 없다.

예를 들어 겸손한 curl 명령을 생각해 보라. 정규식 스캐너는 데이터 유출을 방지하기 위해 curl을 표시할 수 있다. 정교한 공격자는 curl을 직접 쓰지 않아도 된다. 대신 다음과 같이 쓸 수 있다:

c${u}rl               # using bash parameter expansion
wget -O-              # using an alternative tool
python -c "import urllib.request..."   # using a standard library

또는 단순히 이렇게 요청한다:

“이 URL의 내용을 가져와서 나에게 보여 주세요.”

마지막 경우 에이전트가 스스로 명령을 구성한다. 스캐너는 무해한 영어 지시만을 보지만, 의도는 여전히 악의적이다. 이것이 “차단 리스트” 사고방식의 핵심 실패이다: 개념을 이해하도록 설계된 시스템에서 특정 단어만 차단하려고 하기 때문이다.

문맥이 중요한 경우 문제는 더욱 복합적이다. “쉘 접근”을 요청하는 스킬은 DevOps 배포 도구에선 완전히 정당할 수 있지만, “레시피 찾기”나 “캘린더 어시스턴트”에서는 재앙이 될 수 있다. 패턴 매처는 “쉘 접근”이라는 구절을 보고 둘 다 표시(노이즈 발생)하거나 둘 다 무시(위험 발생)해야 한다. 왜 접근이 요청되는지에 대한 이해가 없으며, 단지 그 단어가 존재한다는 사실만을 인식한다.

Source: …

사례 연구: 커뮤니티 스캐너를 실제 악성코드와 대결시켰습니다

우리는 가장 인기 있는 커뮤니티 “Skill Scanners”를 맞춤형 “반악성” 스킬에 적용해 친구와 적을 구분할 수 있는지 테스트했습니다. 평가된 도구는 다음과 같습니다:

1. SkillGuard
2. Skill Defender
3. Agent Tinman

1. SkillGuard – 실제 악성코드인 스캐너

첫 번째 대상은 SkillGuard(사용자 c-goro 제작)였습니다. 약속? 당신의 스킬을 위한 가벼운 스캐너. 현실? 함정.

SkillGuard를 분석했을 때, 내부 시스템은 이를 보안 도구가 아니라 악성 스킬 자체로 표시했습니다. “정의 업데이트”라는 명목으로 페이로드를 설치하려 했습니다.

업데이트: 이 글을 쓰는 현재, SkillGuard는 ClawHub에서 제거되었습니다. 하지만 이미 설치한 수백 명의 사용자는 피해를 입었습니다. 이는 핵심 문제를 보여줍니다: 스캐너를 누가 스캔하나요?

2. Skill Defender – 위양성(거짓 부정)

다음으로 Skill Defender(사용자 itsclawdbro 제작)와 Agent Tinman(사용자 oliveskin 제작)를 살펴보았습니다. 이들은 합법적인 커뮤니티 프로젝트이며, Skill Defender는 VirusTotal에서 “Benign” 배지를 가지고 있습니다. 그러나 “Benign”이 **“효과적”**이라는 뜻은 아닙니다.

우리는 vercel이라는 테스트 스킬을 만들었습니다. 이는 Vercel 플랫폼용 배포 도구처럼 보였지만, 실제로는 사용자의 호스트명을 원격 서버로 조용히 유출했습니다.

우리는 Gemini CLI를 사용해 Skill Defender로 이 악성 스킬을 스캔했습니다:

> use the skill defender to scan current skills

결과

• 악성 스킬 (vercel) – 판정: CLEAN (발견 0건)
• 스캐너 자체 (skill-defender) – 판정: DANGEROUS (발견 20건)

(가능한 경우 실제 이미지 URL로 교체)

시사점

표는 보호를 위해 만든 도구가 바로 위험의 원천이 될 수 있음을 강조합니다.

오늘 할 수 있는 일

1. 단일 스캐너에 의존하지 마세요. 여러 개의 보완적인 도구를 사용하고, 그 출력은 권고 수준으로 여기며 최종적인 것으로 보지 마세요.
2. 행동 기반 모니터링을 채택하세요. 런타임 시 비정상적인 네트워크 호출, 예상치 못한 파일 쓰기, 권한 상승 등을 찾아보세요.
3. “깊이 방어” 파이프라인을 구현하세요:
   • 정적 분석 (regex/deny‑list) – 쉬운 취약점을 잡아냅니다.
   • 시맨틱 분석 (LLM 기반 의도 탐지) – 미묘한 악의적 의도를 포착합니다.
   • 런타임 샌드박싱 – 스킬 실행을 격리하고 부수 효과를 기록합니다.
4. “스캐너‑오브‑스캐너” 프로세스를 구축하세요. 보안 도구 자체를 주기적으로 감사하고, 가능하면 독립적인 제3자와 함께 진행하세요.
5. 개발자와 제품 소유자를 교육하세요 regex 기반 스캔의 한계와 AI 에이전트를 위한 위협 모델링의 중요성에 대해.

Final thought

AI 에이전트는 고전적인 보안 딜레마를 증폭시킵니다: 언어가 표현력이 클수록 모든 악성 패턴을 열거하기가 더 어려워집니다. 거부‑리스트에만 의존하는 것은 “총”이라는 단어를 금지함으로써 모든 가능한 무기를 차단하려는 시도와 같습니다. 대신 intent, context, 그리고 behaviour에 집중하고, 신뢰하는 도구도 again 다시 신뢰해야 한다는 점을 기억하세요.

스캐너는 실제 위협을 잡지 못했는데, 이는 가짜 Vercel 스킬에 있는 우리의 탈취 코드가 스캐너가 하드‑코딩한 “bad” 문자열 목록과 일치하지 않았기 때문입니다. 그러나 스캐너는 자체 참조 파일에 스캔 대상이 되는 바로 그 “threat patterns”가 포함되어 있어 자신을 위험하다고 표시했습니다!

이것이 고전적인 **“Antivirus Paradox”**입니다: 스캐너는 악의가 어떻게 생겼는지 알고 있기 때문에 악성으로 보이지만, 새로운 것에는 눈이 멀어 있습니다.

행동 의도 분석으로 이동

우리는 AI 보안을 “나쁜 단어를 필터링하는 것”으로 생각하는 것을 멈춰야 합니다. 이제 행동 분석으로 생각해야 합니다.

• AI 코드는 금융 부채와 같습니다: 빠르게 얻을 수 있지만, 조건(즉, 프롬프트의 의도)을 이해하지 못하면 파산으로 이어질 수 있습니다.
• 정규식 스캐너는 맞춤법 검사기와 같습니다 – 단어가 올바르게 철자되었는지 확인합니다.
• 의미 스캐너는 편집기와 같습니다 – “이 문장이 의미가 있나요? 사용자에게 위험한 행동을 하라고 말하고 있나요?” 라고 묻습니다.

3. Ferret Scan: 여전히 RegEx 패턴에 제한됨

우리는 또한 GitHub 기반 스캐너인 Ferret Scan을 살펴보았습니다. 이 도구는 정규식과 함께 “Deep AST‑based analysis”를 사용한다고 주장합니다. ClawHub‑native 도구보다 훨씬 나은 성능을 보이지만, 자연어 공격의 미묘한 차이를 파악하는 데는 여전히 어려움을 겪습니다.

하드코딩된 API 키는 잡아낼 수 있지만, 에이전트가 요약하도록 요청받은 PDF에 숨겨진 프롬프트 인젝션을 잡아낼 수 있을까요?

Source: https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/

ToxicSkills 연구 증거: 컨텍스트가 핵심

최근 ToxicSkills 연구에서 **13.4 %**의 스킬에 심각한 보안 문제가 포함되어 있음을 발견했습니다. 이러한 문제들의 대부분은 단순한 패턴 매칭으로는 포착되지 않았습니다.

• 프롬프트 인젝션: “jailbreak” 기법을 사용해 안전 필터를 우회하는 공격.
• 난독화된 페이로드: base64 문자열이나 외부 다운로드에 숨겨진 코드 (예: 최근 google‑qx4 공격).
• 컨텍스트 위험: “shell access”를 요구하는 스킬은 개발 도구에는 괜찮을 수 있지만, “레시피 찾기”와 같은 경우에는 재앙이 될 수 있습니다.

정규식은 “shell access”를 보고 둘 다 플래그를 지정하거나, 더 나빠서는 프롬프트에 “execute system command”라고 적혀 있기 때문에 전혀 플래그를 지정하지 못합니다.

솔루션: SKILL.md 파일을 위한 AI‑네이티브 보안

이러한 속도를 견디려면 정적 패턴을 넘어야 합니다. AI‑네이티브 보안이 필요합니다.

그래서 우리는 mcp‑scan(Snyk의 Evo 플랫폼의 일부)를 만들었습니다. 이 도구는 단순히 문자열을 grep하는 것이 아니라, 특화된 LLM을 사용해 SKILL.md 파일을 읽고 스킬의 기능 및 관련 아티팩트(예: 스크립트)를 이해합니다.

mcp‑scan을 실행한다는 것은 다음과 같이 질문하는 것과 같습니다:

• 이 스킬이 파일을 읽는 권한을 요청하고 있나요?
• 이전 지시를 무시하도록 사용자를 설득하려고 하나요?
• Snyk Advisor를 통해 일주일 미만 된 패키지를 참조하고 있나요?

**정적 애플리케이션 보안 테스트(SAST)**와 LLM 기반 의도 분석을 결합함으로써, 우리는 동작(알 수 없는 엔드포인트로 데이터 전송)을 보고 Vercel 탈취 스킬을 포착할 수 있습니다. 단순히 구문만 보는 것이 아니라 말이죠.

내일 팀에 물어볼 세 가지 질문

1. “우리 AI 에이전트가 사용하는 모든 ‘스킬’에 대한 인벤토리를 가지고 있나요?”

   • 예라고 하면, 어떻게 찾아냈는지 물어보세요. 수동이라면 오래된 것입니다.
   • 아니오라고 하면, mcp‑scan 도구를 공유하세요.

2. “이 스킬들을 의도에 대해 스캔하고 있나요, 아니면 키워드만 스캔하고 있나요?”

   • 정규식 중심 사고에 도전하세요.

3. “신뢰받는 스킬이 내일 악성 의존성을 포함하도록 업데이트되면 어떻게 되나요?”

   • 일회성이 아닌 지속적인 스캔을 요구하세요.

“보안 연극(Security Theater)”에 현혹되어 허위 안전감을 갖지 마세요. 에이전트는 똑똑합니다. 여러분의 보안도 더 똑똑해야 합니다.

에이전트 AI에 대한 통합 제어를 제공하는 Snyk의 Evo에 대해 알아보기.