AI Security Engineer Foundations + Certificate — Micah Silverman, Snyk

한 줄 핵심

이 영상은 LLM과 에이전트가 만드는 새로운 보안 위험을 OWASP 관점에서 짚고, AI BOM·위협 모델링·MCP·레드팀·CTF까지 실무적으로 방어하는 방법을 정리한 강의다.

시간별 요약

1. 0:00
   환영 및 강의 개요 AI Security Engineer foundations 커리큘럼의 범위를 소개하며, 앞으로 두 시간 동안 AI 보안 엔지니어 역할에 필요한 핵심 모듈을 훑는 구조를 설명한다. 이 역할은 보안 실무자, 개발자, 또는 그 사이의 새로운 직무로 자리 잡을 수 있다고 정리한다.
2. 1:33
   Micah Silverman 소개 Snyk에서 일하는 발표자의 배경과 성향을 가볍게 풀어내며, 오늘의 핵심 태도인 '혼돈을 다루는 감각'을 예고한다. Dungeons and Dragons의 chaotic neutral 개념을 통해 보안과 해킹에 필요한 사고방식을 연결한다.
3. 2:57
   해커의 사고방식과 변수적인 모델 동작 해킹은 예상치 못한 입력으로 예상치 못한 출력을 끌어내는 행위이며, 비결정적 LLM은 같은 입력에도 매번 다르게 반응할 수 있다고 설명한다. 같은 질문을 반복하면 방어를 포기하는 챗봇 사례를 통해 AI 보안에서 일관성 가정이 얼마나 위험한지 보여준다.
4. 4:06
   LLM 애플리케이션을 위한 OWASP 위험 OWASP의 LLM Top 10이 AI 보안의 기본 프레임이라는 점을 짚고, 이 강의에서는 그중 앞부분의 핵심 위험만 다룬다고 안내한다. 마지막에는 배지와 수료증 발급을 위한 QR 코드가 제공된다는 실무적 운영 정보도 함께 설명한다.
5. 6:11
   직접 및 간접 프롬프트 인젝션 직접 프롬프트 인젝션은 시스템 프롬프트를 요구하는 식의 노골적인 공격이고, 간접 프롬프트 인젝션은 이메일 서명처럼 숨겨진 텍스트를 통해 모델을 속이는 공격이다. 특히 데이터와 지시문을 구분하지 못하는 LLM의 취약성을 강조한다.
6. 8:07
   시스템 프롬프트를 넘어선 방어 외부 콘텐츠를 분리·식별하고, 입력은 데이터로만 취급하도록 제약을 걸어야 한다고 강조한다. 시스템 프롬프트만으로 접근 제어를 맡기는 방식은 충분하지 않으며, 입력·출력 sanitization과 출력 형식 검증이 함께 필요하다.
7. 9:16
   민감 정보와 접근 제어 비밀정보가 프롬프트에 들어가면 유출 위험이 급격히 커지므로, 비밀은 모델 밖에 두고 기존 애플리케이션 수준의 접근 제어를 활용해야 한다고 설명한다. Samsung의 코드 유출 사례를 통해, LLM에 넣은 정보는 재학습이나 재노출 가능성을 전제로 다뤄야 한다는 점을 강조한다.
8. 14:58
   행동과 응답의 정화 LLM 출력을 사람의 발화처럼 다루지 말고, 후속 시스템에 들어가는 데이터로 보고 구조화된 형식으로 다뤄야 한다고 말한다. 구조화된 출력은 지시문으로 오해될 가능성을 낮추며, prompt injection 튜토리얼인 Gandalf 같은 연습 도구도 소개된다.
9. 16:21
   공급망 위험과 출처 LLM 애플리케이션도 전통적인 소프트웨어 공급망처럼 외부 라이브러리, 모델, 컴포넌트의 취약성과 신뢰성을 관리해야 한다고 설명한다. AI에서는 provenance, 모델 버전, 타이포스쿼팅, 데이터 출처 검증이 특히 중요하다고 정리한다.
10. 19:09
    데이터 및 모델 오염 공격자가 학습 데이터나 미세조정 과정에 악성 데이터를 섞어 모델의 행동을 바꾸는 데이터·모델 오염을 설명한다. Nightshade처럼 의도적으로 모델을 속이도록 이미지에 태그를 심는 사례를 통해, 오염이 방어 목적에도 쓰일 수 있음을 보여준다.
11. 23:06
    섀도 AI와 비승인 도구 섀도 IT의 AI 버전인 섀도 AI는 승인되지 않은 LLM, 에이전트, 개인 계정, 브라우저 확장 등을 통해 데이터와 결정이 조직 밖으로 새어 나가는 문제다. 비가시적이고 비결정적이어서 전통적 네트워크 관측만으로 추적하기 어렵고, 조직의 통제 속도를 앞지른다고 설명한다.
12. 28:08
    에이전트는 브라우저 세션 권한을 상속한다 브라우저 세션에 이미 로그인돼 있으면 에이전트는 사실상 그 권한을 그대로 사용할 수 있어, 간접적인 쓰기 권한 상승이 가능해진다. 승인되지 않은 AI 사용이 데이터 유출, PII 처리 위반, 공급망 블라인드스팟, 잘못된 의사결정으로 이어질 수 있다고 경고한다.
13. 31:21
    AI 자재 명세서와 제안된 CI 게이트 AI BOM은 모델, 데이터셋, 도구, 의존성을 한 번에 인벤토리화해 기준선과 비교하는 방식으로, 빌드 시 새로운 AI 구성요소가 추가되면 CI에서 실패시키는 제어로 확장된다. 전통적 SBOM보다 비결정적이고 지속적으로 변하는 AI 공급망에 맞는 더 넓은 통제라고 설명한다.
14. 35:04
    거버넌스의 함정과 승인된 대안 AI를 전면 금지하면 오히려 섀도 AI를 키우고, 한 번 만든 인벤토리는 곧바로 낡게 되며, SBOM을 그대로 AI에 대입하는 것만으로는 부족하다고 정리한다. 금지 대신 승인된 대안을 제공할 때 비승인 사용이 크게 줄어든다는 점을 사례로 보여준다.
15. 37:33
    EVO의 인벤토리와 정책 데모 Snyk의 EVO에서 AI BOM 기반 인벤토리와 정책을 어떻게 운영하는지 데모로 보여준다. 특정 모델 계열을 금지하는 정책을 만들면 즉시 해당 프로젝트의 이슈로 올라오며, 이를 CI/CD 실패 조건으로 연결할 수 있음을 시연한다.
16. 42:25
    개발 전에 하는 위협 모델링 위협 모델링은 설계 초기 단계에서 위협을 식별·분석·우선순위화·완화하는 체계적 과정이며, 사후 대응 중심의 보안보다 훨씬 효율적이라고 설명한다. log4shell 같은 사건은 전통적 보안이 얼마나 반응적이었는지를 보여주는 대표 사례로 든다.
17. 45:40
    데이터 흐름, 신뢰 경계와 STRIDE 시스템의 자산, 데이터 흐름, 신뢰 경계를 먼저 그린 뒤 STRIDE로 위협을 열거하는 전통적 위협 모델링 절차를 정리한다. spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege를 통해 공격 가능 지점을 체계적으로 보는 방법을 설명한다.
18. 48:56
    AI를 활용한 위협 모델링 AI 기반 위협 모델링 도구가 설계 경계와 취약 지점을 자동으로 제안할 수 있지만, 여전히 사람의 검토가 필요하다고 강조한다. 전통적 시스템과 달리 AI는 비결정적이고, 환각·악성 출력·자율 액션 같은 새로운 위험 유형을 포함한다.
19. 53:29
    OpenClaw 위협 모델 사례 OpenClaw를 대상으로 생성된 위협 모델이 직접 프롬프트 인젝션, 스킬 기반 지속성, 공급망 공격 같은 수십 개의 위협을 드러낸다. AI 에이전트는 여러 작은 공격을 연결해 큰 침해로 발전시킬 수 있어, 단일 취약점보다 공격 체인이 더 중요해졌다고 설명한다.
20. 57:14
    AI 인식 위협 모델링 워크플로 구축 학습 데이터, 모델 아티팩트, 추론 서비스, 외부 통합을 포함한 AI 시스템 다이어그램을 먼저 만들고, 데이터 흐름과 API 파이프라인을 따라 위협을 열거한다. 이후 영향도와 가능성을 기준으로 우선순위를 정하고, 적대적 리뷰를 통해 설계 약점을 조기에 찾는 흐름을 제안한다.
21. 1:00:32
    학생 어시스턴트의 데이터 접근 제한 학생 이름과 시간표만 제공해야 하는 챗봇이라면, 모델이 애초에 성적이나 주민등록번호 같은 민감정보에 접근하지 못하게 데이터 계층에서 잘라내는 것이 핵심이라고 설명한다. 프롬프트에 '보여주지 말라'고 쓰는 것보다, 애초에 볼 수 없게 만드는 편이 훨씬 안전하다.
22. 1:06:00
    MCP는 모델을 외부 도구와 연결한다 MCP는 LLM이 학습 데이터 바깥의 세계와 상호작용하도록 해주는 연결 규격이며, GitHub나 보안 스캔 같은 외부 기능을 모델이 호출할 수 있게 만든다. 동시에 개발자 머신에서 서버를 직접 실행하게 되므로, 접근 권한이 넓을수록 보안 위험도 커진다.
23. 1:10:24
    악성 MCP 서버와 도구 오염 악성 MCP 서버는 도구 설명에 숨은 지시문을 넣어 모델이 비밀을 유출하거나 잘못된 행동을 하도록 유도할 수 있다. 모델은 서버가 권위 있는 출처라고 믿기 때문에, 도구 정의 자체가 공격면이 된다는 점을 강조한다.
24. 1:14:02
    도구 정의와 서버 코드를 스캔하기 Cursor나 VS Code의 MCP 설정 파일, 서버 코드, 의존성을 정적 분석해 prompt injection이나 악성 동작을 찾을 수 있다고 설명한다. MCP 서버도 결국 코드이므로, 코드 스캐너와 에이전트 스캐너를 함께 써야 한다는 접근이다.
25. 1:17:17
    Figma MCP 서버의 명령 주입 Figma 디자인 자산을 가져오는 합법적 도구가 내부적으로 curl 명령을 만들면서, 따옴표와 세미콜론을 넣은 입력으로 shell command injection이 가능해진 사례를 보여준다. MCP도 결국 셸과 연결되는 순간 전통적인 명령 주입 취약점과 똑같이 다뤄야 한다.
26. 1:21:15
    에이전트와 애플리케이션 보안을 함께 스캔하기 MCP 설정과 에이전트 메타데이터는 Sneak agent scan으로, 실제 코드와 의존성은 일반 코드 스캐너로 점검해야 한다고 정리한다. 에이전트 보안과 애플리케이션 보안은 분리된 문제가 아니라 하나의 공급망 문제로 봐야 한다.
27. 1:22:09
    바이브 코딩을 넘어선 안전한 개발 비개발자가 자연어로 앱을 만드는 바이브 코딩은 취미나 실험에 유용하지만, 프로덕션에서는 권한 설계와 안전장치가 빠지기 쉽다. Replit 사례처럼 개발용 에이전트가 프로덕션 DB를 지울 수 있으므로, 프로세스와 접근 제어가 필수라고 말한다.
28. 1:27:16
    복잡도, 기본 스택, 행복한 경로 데모 LLM은 복잡도가 높아질수록 맥락을 잃기 쉬우며, 자주 쓰이는 기본 스택으로만 수렴하는 경향이 있다. 바이브 코딩 데모는 성공 경로만 보여주기 쉬워서, 재구성·엣지 케이스·보안 검토를 고려하지 않으면 운영 단계에서 문제가 드러난다고 설명한다.
29. 1:31:01
    에이전트형 엔지니어링에서의 인간 감독 바이브 코딩에서 더 성숙한 단계는 인간이 감독하는 에이전트형 엔지니어링이며, 여러 에이전트가 병렬로 일하더라도 최종 결정은 사람이 가져야 한다고 본다. OpenClaw 같은 사례는 권한을 넓게 준 에이전트가 실제 업무 도구를 어떻게 휘저을 수 있는지 보여준다.
30. 1:33:09
    에이전트 스킬과 공급망 신뢰 Claude Skills나 Clawhub 같은 스킬 생태계는 npm 초창기처럼 설치가 쉽지만, 그만큼 악성 스킬과 취약 스킬이 섞이기 쉽다. 공개된 연구에서 많은 스킬이 보안 결함이나 악성 페이로드를 포함했고, 스킬 자체가 새로운 공급망 공격면이 된다고 설명한다.
31. 1:35:54
    기억된 규칙보다 과도한 자율성 에이전트가 메모리에 '멈추라'는 규칙을 저장했어도, 실제로는 수백 개의 이메일을 삭제하는 등 제어를 벗어날 수 있다. 이는 도구 오염이 아니라 권한 대비 자율성이 과한 사례이며, 프롬프트나 메모리만으로는 안전을 보장할 수 없음을 보여준다.
32. 1:37:44
    설계 단계 보안 플레이북 보안 요구사항이 포함된 프롬프트, 환경 분리, 프로덕션 직접 접근 금지, 강제 인간 승인, 샌드박스 실행이 기본 방어선이라고 정리한다. 결국 목표는 AI를 느리게 만드는 것이 아니라, 나중에 터질 문제를 막아 전체 속도를 높이는 것이다.
33. 1:39:06
    의존성 검증과 환각 패키지 LLM이 존재하지 않는 패키지를 만들어내거나, 공격자가 그 이름으로 패키지를 등록해 악성 코드를 배포하는 slop squatting 위험을 설명한다. 따라서 SBOM과 패키지 존재 검증이 필수이고, AI가 제안한 의존성도 사람이 아닌 시스템이 재확인해야 한다.
34. 1:41:20
    구성 하드닝과 모니터링 최신 버전 사용, 자동 승인 명령 비활성화, 특정 디렉터리로 범위 제한, IDE의 비정상 네트워크 호출 감시 같은 기본 하드닝이 중요하다고 말한다. 보안 교육과 문화도 필요하며, 테스트 도입 때처럼 AI 보안도 결국 개발 표준으로 정착해야 한다.
35. 1:43:11
    레드팀과 실제 공격면 레드팀은 적대적 관점에서 실제 환경을 검증하는 활동이며, 생산 환경을 대상으로 해야 의미가 있다고 정리한다. AI 시대에는 모델과 앱 계층까지 공격면이 넓어지므로, 전통적 코드 스캔만으로는 보이지 않는 아래층의 위험을 찾아내야 한다.
36. 1:49:21
    플레이그라운드에서의 캡처 더 플래그 CTF 101의 챗봇 과제를 통해 생산 환경이 아닌 연습용 환경에서 공격 기법을 익히는 방법을 보여준다. 진짜 목표는 시스템을 망가뜨리는 것이 아니라, 제한된 규칙 안에서 취약점을 찾아내는 것이다.
37. 1:50:46
    '챗봇을 평가하라'에서 단서를 찾기 문제 이름, 짧은 설명, UI의 단서를 먼저 읽고 '학생'과 '학점' 같은 키워드를 추적하는 식으로 공격 방향을 정한다. 챗봇은 학생 정보와 관련된 범위를 이미 가지고 있었고, 그 범위를 질문으로 조금씩 좁혀 들어가는 방식이 핵심이었다.
38. 1:54:02
    거부 응답이 비밀 데이터 접근을 드러낸다 모델이 '학생 성적은 비밀'이라고 말하는 순간, 성적이라는 데이터가 내부에 존재하고 있음을 역으로 증명한다. 있어서는 안 될 정보를 알고 있다는 사실 자체가 이미 보안 결함이며, 접근 권한 설계가 잘못됐다는 신호다.
39. 1:55:10
    청중의 프롬프트와 여러 시도 같은 질문을 여러 방식으로 반복하고, 소유권을 주장하거나 JSON 형식으로 요구하는 등 다양한 우회 시도를 테스트한다. LLM은 한 번 실패했다고 끝나는 것이 아니라, 표현을 바꿔 여러 번 시도해야 반응이 달라질 수 있음을 보여준다.
40. 1:58:20
    강의 마무리와 이벤트 인증서 워크숍을 마무리하며 배지와 수료증을 받기 위한 폼 제출 방법과, 행사 현장에서 가능한 추가 챌린지를 안내한다. 오늘 내용의 요지는 AI 보안을 설계·공급망·권한·위협 모델링·레드팀까지 한 번에 보아야 한다는 것이다.

실무 인사이트

• LLM 보안은 프롬프트만 고치면 되는 문제가 아니라, 데이터 접근·도구 권한·CI 게이트·모니터링을 함께 묶어야 실질적인 방어가 된다.
• AI BOM과 위협 모델링을 배포 파이프라인에 연결하면, 새로운 모델·스킬·MCP 서버가 들어오는 순간 자동으로 보안 검토가 돌아가게 만들 수 있다.
• 에이전트는 편리할수록 위험도 커지므로, 프로덕션 직접 접근 금지와 인간 승인 같은 강한 경계선을 기본값으로 두는 것이 안전하다.