min6.dev
KO|EN

Find Vulnerabilities by Using AI 1

17 min read

Introduction

처음은 그냥 Bug bounty가 닫히고 있는 시점에, CVE 하나는 발급받고 싶다는 마음으로 시작하였다. 무작정 오픈소스를 다운받고, Claude-Code에게 Security.md를 읽고 기존 CVE를 분석/분류를 해보라고 시켰으며 당연하다는 듯이 기존 CVE와 비슷한 취약점 후보들을 여럿 받았다.

그러나 실제로 구현하여 검증하는 과정에서 여러 이유로 취약점이 아님을 확인하였다. 토큰을 이렇게 의미없이 날리고 보니, 단순 정적 소스코드 분석으로 찾는것은 한계가 있다고 판단하였고 오픈소스 취약점 분석 Flow를 만들고 필요하다면 Local LLM과 MCP tool도 사용하자는 생각을하게 되었다.

마침 취약점을 찾고 싶은 오픈소스 후보군 중에 Flowise라는 AI플로우 오픈소스가 있었고, 처음에는 Flowise 사용해서 Flowise 취약점 찾기라는 프로젝트 재미있을 것 같아 수행하게 되었다. 다만 Local LLM의 성능과 디버깅의 어려움으로 인해 추가 학습 및 다른 방향을 찾으며 진행하게 되었다.

1) Test1 : Flowise & Local LLM(Qwen3:14b)

Settings

  • Flowise In docker container
  • Ollama
  • Local llm model Qwen3:14b
    • almost opensource llm model do not support tool calling or standard of MCP tool calling
    • 세팅하면서 오히려 상용 LLM 서비스들이 얼마나 대단한지 알게됨
  • Burp Suite MCP
    • MCP bridge to Flowsie container (AI handmade, 주어진 프록시와 burpsuite는 정해진 데이터형식을 따라야하는데, qwen의 tool calling 형식과 안 맞아서 proxy를 만듦)

Flowise

  • Custom MCP node ⇒ Tool agent Node의 Tools
    • Custom MCP node 는 직접만든 bridge를 통해 Burp MCP 를 call함
  • Ollama Node ⇒ Tool agent Node의 Tool calling chat model
    • Qwen3:14b, Context Window 16k 토큰으로 세팅
  • Buffer Memory ⇒ Tool agent Node의 Memory

Test1 Challenging

  • Local LLM 성능
    • 토큰 수가 부족하여 맥락파악이 어려움.
    • 상용모델과 달리 MCP tool 사용이 능수능란하지 않음, tool calling 을 지원하는 모델도 별도로 존재.
    • 그 와중에 거의 뜨거워지지 않던 내 맥북이 뜨거워짐을 느낌
  • llm 서비스 설계 능력 부족
    • 상용 LLM의 사용을 줄이고 싶은 니즈로 시작했으나, 결국 agent를 어떻게 다룰 것인지, 어떤 llm model이 적합한지 등 전반적인 학습이 부족함.
    • 부족한 상태에서 MCP 도구에 대한 부분까지 하네스하는 것은 매우 어려움을 깨달음
    • Ollama에서 하네스를 어떻게 진행하는지 전혀 몰랐음

⇒ 더욱 작은 목적을 세우고 진행해야 함을 깨달음 ⇒ 취약점 분석 자체에 방법론을 차근차근 세우는 것이 필요한데… 그 부분을 로컬모델로 돌리기 위해서는 많은 고민이 필요할 것 같음. Test2에서는 AI를 공부하면서 익숙해질겸 좀 단순한 문서화 작업을 진행해보기로 결정함

2) Test2 : Change LLM Model(gemma4:e4b) & Specify the purpose to use Local LLM

Test2 Project Goal : AI 취약점 보안성 검토 항목 만들기

기존에 NotebookLM으로 AI 보안성 검토 항목을 만들어보았는데, 근거 조항을 가져 오는게 불안정했음 Claude에게 전적으로 맡겨도 불완전할 것이라 판단하여 초안 생성 및 최종 검토는 클로드에 맡기되, Local LLM으로 RAG생성하여 근거를 정확하게 가져오고, 단순 반복 업무는 local llm을 써보도록 함

Gemma4:e4b

  • 모델 메모리 제한 : 내 맥북프로는 VRAM과 RAM을 같이 쓰고 24GB임. IOS랑 다른 작업들을 동시에 진행하기 때문에 메모리 공간이 여유있는 편이 아님을 알게됨. 모델 자체가 무거울 경우 컨텍스트의 제한이 걸리고 답변이 매우 느리거나, 답변이 산으로 갈 수 있음.
  • llm은 물론 성능이 중요하지만, 이미 성능에 제한이 걸린 local llm에서는 하네스가 오히려 중요하다는 생각.
  • 속도 : 모바일용/온디바이스 용으로 나온 e4b를 사용하여 빠른 속도를 지향.

Thinking

Flow

  • Step1 (Claude) : PDF to Text python Script 생성
> **참고자료**
> - `KISA` : 인공지능(AI) 보안안내서 (과기정통부·KISA, 2025.12)
> - `NIS` : AI보안 가이드북 (국가정보원, 2025.12)
> - `FSI-AG` : AI 에이전트 아키텍처에서 인증 및 권한관리를 위한 보안고려사항 (금융보안원, 2025.09)
> - `FSI-GL` : 금융분야 AI 보안 가이드라인 (금융보안원, 2023.04)
> - `FSC` : 금융분야 AI 개발·활용 안내서 (금융위원회, 2022.08)
> - `AI기본법` : 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법 (2026.01.22)
> - `AI시행령` : 인공지능기본법 시행령 (2026.01.22)
  • Step2 (Claude) : WIKI 구조 생성
  • Step3 (Claude) : Gemma e4b용 프롬프트 생성 (gemma context 길이에 맞게 잘라서 파일 요약)
  • Step4 (Gemma4) : WIKI 제작 (참고자료 txt 파일 참조)
  • Step5 (Claude): WIKI 자료를 참고로 하여 보안성 검토 항목 초안 md파일 작성
  • Step6 (Claude , Gemma4) : 최종 마크다운 표 검토
    • bge-m3:latest (로컬) — RAG 생성
      • 원문 기반 참조하여 RAG 생성
    • gemma4:e4b (로컬) — 무거운 반복업무
      • WIKI를 기반으로 RAG를 기반으로 md 파일 Scoring(실제 보고서에 있는지, 적합한지)
    • Claude Sonnet 4.6 — RAG 설계,Gemma4:e4b에 계산업무 분배, 최종 리포트 검토 및 수정
      • 최종 마크다운 품질 검토 (RAG를 이용한 Scoring을 참조하여)

Scoring 결과) Scoring을 통하여 부분충족으로 잡힌 두가지 항목임. 항목을 잘 뽑았는지는 미지수지만 일단 사유가 꽤나 논리적이긴 함.

Test2 결과 (심의 및 취약점 점검 체크리스트)

3) Find Vulnerabilities by Using AI

Find Vulnerabilities by Using AI

앞서 두 번의 테스트1,2를 통해 얻은 것을 정리하고 3)을 진행할때 사용해보고자 했다. 엄청난 것은 아니지만 실제로 느낀 점을 정리하자면 아래와 같다.

  1. 목적이 매우 명확하고 단순, 반복적인 업무에만 Local llm을 사용
  2. 사고 및 추론이 필요한 경우는 무조건 상용 AI를 사용
  3. MCP 연동은 쉬울 수록 좋다.
  4. 의미기반 검색, 원본 검증이 필요할 땐 RAG도 좋음
  5. AI Agent Flow 툴(Flowise, n8n 등)의 필요한 이유는 알겠으나, 디버깅이 중요하다면 단순 호출이 더 편리함
  6. HIL(Human In the Loop) 는 Claude Pro를 쓰는 나에게 생각보다 필요함 (클로드 생각보다 멍청함)
  7. 무작정 기존 패치로그를 기반으로 찾는 것만으로는 의미있는 취약점을 찾는 것은 어려움
  8. caveman skills는 token을 매우 아껴준다
  • 처음에는 Dify라는 오픈소스를 분석할 때, 기존 소스코드를 RAG으로 구축하고, 기존 security diff(Before Code)로 검색을 하면 되지 않을까 했지만 AI를 잘 이해하지 못한 채 생각한 부분이었다. 문맥상 유사성이 코드 구조의 유사성을 의미하지 않는다.
  • Dify, plane, n8n, langflow 등의 오픈소스 점검을 진행했고, 조금씩 고쳐 현재의 FLOW는 아래와 같다.

Problem Definition

  • 타겟: 끌리는 오픈소스
  • 성공 기준: 재현 가능한 PoC + 취약점 제보 + CVE 번호 획득

Flow

각 Phase 진행 시에는 phase 폴더 내 어떤 것을 진행하였는지 기록함. 세션이 끊기거나, 후보군을 찾을 때 중복되는 것을 방지 할 수 있음.

  • Phase1. 환경 구축

    • 환경 구축을 1번으로 진행함.
    • 부족한 FLOW 설계 능력도 있지만, 해당 오픈소스가 어떤 서비스인지 이해가 먼저 필요하다고 판단됨.
    • Docker / AWS 로 구축하고 계정이 있는 경우 계정도 여러 권한으로 세팅해 봄
    • 오픈소스 구조를 간단하게 파악하면서 오픈소스 구조에 대한 readme를 작성

  • Phase2 취약점 정보 탐색

    • 기존 취약점 탐색
      • github api를 활용하여 github security advisory 및 security commit 로그를 확인
      • 취약점을 포맷에 맞게 저장함 ([CVE/GHSA ID] | [유형] | [영향모듈] | [취약패턴] | [수정 방법])
      • 유형별로 카운팅을 하여 우선순위로 삼음
    • 취약점 나올 가능성 높을 것이라 생각하는 부분 확인
      • 신규 기능
      • 신규 파일
      • 공격면 grep ( file/upload/request 등)

  • Phase3 정보 기반 취약점 후보군 위치 탐색 + 심층분석

    • phase2 기존 취약점 우선 순위 순+phase 2 신규 파일에서 찾은 부분에 대한
      • CVE에서 코드 특성 추출하여 grep
      • semgrep
    • 위로 찾은 취약점 후보군을 Claude가 심층분석함
    • 함수 input 값이 어디서 넘어오는 것인지 확인함
    • 최종 취약점 후보군을 만듦

  • phase4 By design filter

    • 취약점을 찾다보니, Security.md에 ~은 Out of Scope 아니면 issue에 제기한 문제에 대해 maintainer가 이건 by design이다 명시한 경우들이 있다.
    • Security.md나 찾은 취약점 후보군과 관련된 디자인을 검토하도록 했다.

  • phase5 취약점 POC

    • 찾은 취약점 후보군을 실제로 POC 진행할 계획을 세운 뒤 허락
    • 추가 진행 중 사람의 도움이 필요하면 말하라고 했음.

취약점을 3건 제보했으며, 기다리는 중…(06/09)

  • 취약점 보고에 대한 응답이 오거나 하면 해당 보고서에 대해 세부 정리 진행 예정.

이번 프로젝트를 진행하며 느낀점

  • AI 활용 시 성능만큼 하네스가 매우 중요

    • AI를 사용하는 목적을 명확히 정의해야함
    • 해당 목적을 이루기 위한 output 및 input 형태를 고정 필요
    • AI 병목 지점 파악 및 프롬프트나 메모리 제어 (쓸데없는거에 계속 waiting )
      • 조금 돌아가는 건 괜찮으나 일이 진행되지 않는 걸 못기다리면 프로젝트 md나 별도의 workflow로 5분마다 실제로 기다릴만한 업무인지 검토하여 아니면 로그 찍으면서 진행할 필요 있음
    • 위의 문제정의를 명확히 하고 + 여러 agent를 돌릴 토큰(재력)이나 컴퓨팅파워가 있으면 agentic engineering이 어느정도 가능하지 않을까 싶다..

  • AI agentic engineering 기능에서 나오는 문제점

    • 물론 중요했던 인증/인가 이지만 server to server 통신이 많아져서, 클라이언트 인증 뿐만 아니라 모든 종단감 검증에서 취약점이 나올 확률이 늘어남.

  • AI 의 risk 판단을 할 수 있는 방법론(실질적인 점검법)을 고려해보거나, 아니면 설계 시 LLM의 결과로 떨어지는 값들의 통제에 대한 설계를 하는 능력이 필요함(하네스)

  • AI를 통한 오픈소스 분석은 가능하나, 추후에 담당자로서 AI를 사용하여 사내 시스템의 취약점을 찾는 일에는 회의적임. 취약점 후보군은 엄청 나올 거고 그걸 검수하는 사람만 죽어남. 이번 프로젝트도 10개의 취약점 중 유의미한 걸 검증하는데 약 30시간은 소요한 듯,,,

  • AI를 활용한 Triage를 진행하고, 구조적으로 취약점을 제거하는 Software Architecture 적인 능력이나 Cloud/Container의 어려 권한 인증을 관리하는 능력 등이 중요해질 것 같음