만약 코드를 프로덕션(production)에 배포하면서 아무도 이를 너무 깊게 조사하지 않기를 조용히 바랐던 적이 있다면, 이 프로젝트는 당신을 위한 것입니다.

Strix는 실제 공격자가 하는 방식 그대로 당신의 애플리케이션에 자율 AI 에이전트(autonomous AI agents)를 실행하는 오픈 소스 도구입니다. 이 도구는 앱을 구동하고, 건드려보고, 침입을 시도하며, 취약점을 알려주기 전에 그것이 실제인지 증명합니다. SaaS 종속(lock-in)이 필요 없으며, 모의 해킹(pentest) 업체가 답변을 줄 때까지 몇 주씩 기다릴 필요도 없습니다.

이 글에서는 Strix가 실제로 무엇을 하는지, 기존에 사용하던 정적 분석 도구와 어떻게 다른지, 그리고 첫 번째 스캔을 어떻게 실행하는지에 대해 설명하겠습니다.

대부분의 "보안 스캐닝"이 가진 문제점

개발자들이 일상적으로 사용하는 대부분의 보안 도구는 두 가지 범주로 나뉩니다:

• 정적 분석 (SAST) — 소스 코드에서 위험한 패턴을 스캔합니다. 빠르지만 오탐(false positives)이 많으며, 앱이 런타임(runtime)에 실제로 어떻게 동작하는지는 알지 못합니다.
• 의존성 스캐너 (Dependency scanners) — 패키지 내의 알려진 CVE를 표시합니다. 유용하지만, 직접 작성한 비즈니스 로직 버그에 대해서는 아무것도 말해주지 않습니다.

이 중 어느 것도 실제로 애플리케이션을 _실행(runs)_하고 이를 공격(exploit)하려고 시도하지 않습니다. 전통적으로 이는 전문 모의 해킹가(penetration tester)의 업무였으며, 이들을 고용하는 것은 느리고 비용이 많이 듭니다.

Strix는 AI 에이전트에게 실제 해커의 툴킷(toolkit)을 제공하고, 사람이 하는 것과 동일한 방식으로 실행 중인 앱 인스턴스를 공격하게 함으로써 그 간극을 메우고자 합니다.

Strix가 실제로 하는 일

Strix 에이전트는 다음을 갖추고 있습니다:

• 요청(requests)과 응답(responses)을 검사하고 조작하기 위한 전체 HTTP 프록시 (HTTP proxy)
• 여러 탭에 걸쳐 XSS, CSRF 및 인증 흐름(auth flows) 등을 테스트하기 위한 브라우저 자동화 (Browser automation)
• 명령을 실행하고 대화형으로 테스트하기 위한 터미널 액세스 (Terminal access)
• 즉석에서 맞춤형 익스플로잇(exploits)을 작성하기 위한 Python 런타임 (Python runtime)
• 공격 표면(attack surface)을 매핑하기 위한 정찰 도구 (Reconnaissance tooling)
• 정적 및 동적 코드 분석 (Static and dynamic code analysis)

하나의 에이전트가 모든 것을 수행하는 대신, Strix는 "에이전트 그래프 (graph of agents)" 모델을 사용하여 여러 전문화된 에이전트가 앱의 서로 다른 부분에서 병렬로 작업하고 발견한 내용을 서로 공유할 수 있습니다.

결정적으로, Strix가 취약점을 보고할 때는 단순히 "이 라인이 의심스러워 보입니다"라고 말하는 패턴 매칭이 아니라, 익스플로잇 (exploit)이 실제로 작동함을 입증하는 실제 개념 증명 (proof-of-concept, PoC)을 함께 제공합니다. 이것이 보안 라벨이 붙은 린터 (linter)와 Strix를 구분 짓는 핵심적인 차이점입니다.

Strix는 다음과 같은 사항들을 탐지할 수 있습니다:

• 접근 제어 문제 (Access control issues) — IDOR, 권한 상승 (privilege escalation), 인증 우회 (auth bypass)
• 인젝션 공격 (Injection attacks) — SQL, NoSQL, 커맨드 인젝션 (command injection)
• 서버 측 결함 (Server-side flaws) — SSRF, XXE, 안전하지 않은 역직렬화 (insecure deserialization)
• 클라이언트 측 결함 (Client-side flaws) — XSS, 프로토타입 오염 (prototype pollution), DOM 문제
• 비즈니스 로직 버그 (Business logic bugs) — 레이스 컨디션 (race conditions), 워크플로우 남용 (workflow abuse)
• 인증 문제 (Auth issues) — JWT 취약점, 손상된 세션 관리 (broken session management)
• 인프라 설정 오류 (Infrastructure misconfigurations) 및 노출된 서비스

첫 번째 스캔 설치 및 실행

시작하기 전에 두 가지가 필요합니다:

1. Docker: 로컬에서 실행 중이어야 함 (Strix의 에이전트는 샌드박스 컨테이너 내부에서 작동합니다)
2. API 키: 지원되는 LLM 제공업체(OpenAI, Anthanthic, Google 또는 Ollama/LMStudio를 통한 로컬 모델)로부터 받은 키

설치 방법:

curl -sSL https://strix.ai/install | bash

어떤 모델이 에이전트를 구동할지 설정합니다:

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

그 다음 타겟을 지정합니다:

strix --target ./app-directory

끝입니다. 처음 실행하면 샌드박스 Docker 이미지를 가져온 다음 테스트를 시작합니다. 결과는 strix_runs/<run-name>에 저장됩니다.

Strix는 첫 실행 이후 설정을 기억하여 ~/.strix/cli-config.json에 저장하므로, 매번 환경 변수를 설정할 필요가 없습니다.

로컬 폴더 그 이상

Strix는 사용자의 컴퓨터에 있는 디렉토리를 스캔하는 것에 국한되지 않습니다. 타겟을 지정하는 몇 가지 다른 방법은 다음과 같습니다:

# GitHub 리포지토리를 직접 검토
strix --target https://github.com/org/repo

...

앱에 로그인이 필요한 경우, Strix에 자격 증명 (credentials)을 전달하여 인증된 흐름 (authenticated flows)을 테스트하도록 할 수 있습니다:

strix --target https://your-app.com \
  --instruction "Perform authenticated testing using credentials: user:pass"

또한 일반적인 전체 스캔 대신 특정 관심 사항에 집중하도록 유도할 수도 있습니다:

strix --target api.your-app.com \
  --instruction "Focus on business logic flaws and IDOR vulnerabilities"

더 자세한 교전 규칙 (rules of engagement), 범위 (scope), 또는 제외 사항 (exclusions)을 설정하려면, 한 줄 명령 대신 파일을 전달하세요:

strix --target api.your-app.com --instruction-file ./instruction.md

헤드리스 (Headless) 실행

Strix를 대화형이 아닌 자동화된 작업의 일부로 실행하려면, 비대화형 모드 (non-interactive mode)를 사용하세요:

strix -n --target https://your-app.com

이 모드는 발견 사항을 실시간으로 출력하며, 취약점을 발견할 경우 0이 아닌 상태 코드 (non-zero status code)로 종료됩니다. 이를 통해 실제 취약점이 발견되었을 때 빌드를 실패하도록 만드는 과정을 간편하게 처리할 수 있습니다.

CI/CD에 연결하기

이 지점이 Strix가 팀에게 진정으로 유용해지는 부분입니다. 보안 스캔을 가끔 실행하는 대신, 모든 풀 리퀘스트 (pull request)마다 실행하여 보안에 취약한 코드가 병합 (merge)되기 전에 차단할 수 있습니다.

최소한의 GitHub Actions 설정:

name: strix-penetration-test

on: 
...

이를 설정할 때 참고할 몇 가지 실무적인 사항입니다:

• checkout 단계에서 fetch-depth: 0을 사용하세요. PR 실행 시 Strix는 변경된 파일에 대해서만 빠른 검토 범위를 자동으로 지정하는데, 차이점 (diff)을 정확하게 해결하려면 전체 git 히스토리가 필요합니다. 만약 해결할 수 없다면 --diff-base를 명시적으로 전달하세요.
• LLM 자격 증명은 일반 환경 변수가 아닌 GitHub secrets에 저장하세요.

알아두면 좋은 설정 옵션

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

...

어떤 모델로 실행할지에 대해서, 현재 프로젝트에서는 다음 모델들을 권장합니다:

• OpenAI GPT-5.4 (openai/gpt-5.4)
• Anthropic Claude Sonnet 4.6 (anthropic/claude-sonnet-4-6)
• Google Gemini 3 Pro Preview (vertex_ai/gemini-3-pro-preview)

또한 Vertex AI, Bedrock, Azure 및 로컬 모델을 지원합니다. 셀프 호스팅 (self-hosted) 환경에서 실행하고자 한다면 LLM providers docs를 확인해 볼 가치가 있습니다.

워크플로우에서의 위치

Strix가 여러분이 이미 사용 중인 도구들과 어떻게 병행될 수 있는지 생각해보는 합리적인 방법은 다음과 같습니다:

도구 유형	탐지하는 것	놓치는 것
SAST / linters	위험한 코드 패턴	런타임 (Runtime) 동작, 비즈니스 로직
...

Strix는 코드 리뷰나 중요 시스템에 대한 완전한 전문 펜테스트 (professional pentest)를 대체하는 것은 아닙니다. 하지만 공격자가 앱을 공격하기 전에 실제로 앱을 익스플로잇 (exploit)하려고 시도하는 빠르고 반복 가능한 계층으로서, 정적 도구 (static tooling)가 구조적으로 채울 수 없는 공백을 메워줍니다.

직접 사용해보기

운영 중인 앱 대신 먼저 일회성 프로젝트를 대상으로 실행해보고 싶다면, 이는 감을 잡기에 합리적인 방법입니다. 작은 로컬 프로젝트를 생성하고 Strix를 그곳으로 지정하여 무엇을 찾아내는지 확인해 보세요.

유지 관리자로부터 전달된 중요한 주의 사항이 있습니다: 반드시 본인이 소유하거나 테스트에 대한 명시적인 권한을 가진 애플리케이션만 테스트하십시오. 윤리적이고 법적인 책임을 지고 사용하는 것은 사용자의 책임입니다.

Repo: github.com/usestrix/strix