Strix
취약점을 찾고 수정안까지 내는 오픈소스 AI 침투 테스트 도구
curl -sSL https://strix.ai/install | bash애플리케이션 취약점을 자동으로 탐색하고 수정 방향까지 제안하는 오픈소스 침투 테스트 도구입니다. 스캐너가 찾은 항목을 나열하는 데서 그치지 않고 재현 경로와 패치 후보를 함께 내놓습니다. 설치 스크립트 한 줄로 올리며 Apache-2.0 으로 공개돼 있습니다.
판단
이럴 때 씁니다
- 정적 분석의 오탐에 지쳐 실제로 동작하는 PoC 로 검증된 취약점만 받고 싶을 때
- 외주 모의해킹을 몇 주 기다리지 않고 사내에서 며칠 안에 점검을 끝내야 할 때
- OpenAPI·Swagger·Postman 명세가 있어 크롤링 대신 선언된 엔드포인트를 전수 점검하고 싶을 때
- PR 단위로 CI 에서 취약점을 걸러 프로덕션 반영 전에 막고 싶을 때
이럴 땐 쓰지 마세요
- Docker 를 띄울 수 없거나 LLM 제공자 API 키를 둘 수 없는 환경일 때
- 소스 코드만 훑는 가벼운 린트 수준이면 충분하고 동적 실행까지는 필요 없을 때
- 점검 대상에 대한 권한이 없을 때 — 실제 익스플로잇을 실행하므로 승인 없는 대상에 돌리면 안 됩니다
- 결과를 외부로 내보낼 수 없어 관리형 플랫폼 연동이 금지된 조직일 때
차별점
- 정적 분석과 달리 코드를 실제로 실행해 동작하는 PoC 로 취약점을 검증하므로 오탐이 적습니다.
- 정찰·익스플로잇·후속 침투를 나눠 맡는 다중 에이전트가 서로 발견을 공유하며 취약점을 연쇄시킵니다.
- HTTP 인터셉트 프록시, 브라우저 자동화, 파이썬 익스플로잇 샌드박스를 기본 탑재해 별도 도구 조합이 필요 없습니다.
- 로컬 오픈소스 CLI 와 관리형 클라우드가 같은 엔진을 쓰고, 코딩 에이전트용 스킬 4종을 별도로 제공합니다.
워크플로
- 01Docker 를 띄운 상태에서 설치 스크립트를 실행하고 STRIX_LLM 과 LLM_API_KEY 환경 변수를 설정합니다.
- 02strix --target 으로 로컬 디렉터리·GitHub 저장소·배포된 URL 중 대상을 지정해 첫 점검을 돌립니다. 첫 실행에서 샌드박스 이미지를 내려받습니다.
- 03결과는 strix_runs/<run-name> 에 쌓이고, strix view 로 로컬 대시보드를 열어 심각도·재현 절차·에이전트 그래프를 확인합니다.
- 04인증이 필요한 시나리오는 --instruction 으로 자격 증명을 넘기고, 소스와 배포본을 함께 볼 때는 -t 를 여러 번 지정합니다.
주요 명령
| 명령 | 설명 |
|---|---|
strix --target ./app-directory | 로컬 코드베이스를 대상으로 점검을 실행합니다. |
strix --target https://github.com/org/repo | GitHub 저장소를 내려받아 보안 리뷰를 수행합니다. |
strix --target ./openapi.yaml --target https://api.your-app.com | API 명세와 실제 베이스 URL 을 함께 지정해 선언된 엔드포인트를 전수 점검합니다. |
strix view | 가장 최근 실행 결과를 로컬 대시보드로 엽니다. |
npx skills add usestrix/strix | Claude Code·Cursor·Codex 에 점검·수정·CI 스캔 스킬 4종을 설치합니다. |
함정
설치 전에 확인하세요
- Docker 가 반드시 떠 있어야 하고 첫 실행에서 샌드박스 이미지를 내려받으므로 초기 실행이 느립니다.
- 실제 익스플로잇을 실행하는 도구입니다. 권한이 없는 대상에 돌리면 법적 문제가 되므로 점검 대상 승인 범위를 먼저 확정해야 합니다.
- LLM 제공자 API 키가 필요하고 점검 규모에 따라 토큰 비용이 발생합니다. 무료로 도는 스캐너가 아닙니다.
- strix view 는 127.0.0.1 랜덤 포트에 토큰 링크로 뜨며 파일을 그대로 읽습니다. 결과 디렉터리 자체가 취약점 정보를 담고 있으니 저장소에 커밋되지 않게 해야 합니다.
검토 메모
공식 문서·릴리스·공개 자료를 바탕으로 정리한 편집 메모입니다.
저라면 이 도구를 스캐너 칸이 아니라 필터 칸에 놓겠습니다. 취약점 후보를 나열하고 끝내는 대신 실제로 익스플로잇을 실행해 재현된 것만 남기기 때문에, 손에 쥐는 결과물의 성격이 검토 대기열이 아니라 처리 목록에 가깝습니다. 대신 도입 전에 반드시 먼저 하라고 권하고 싶은 일이 하나 있습니다. 점검 대상의 권한 범위를 문서로 확정하는 것입니다. 실제 공격을 수행하는 도구라 이 선을 흐린 채 돌리면 도구 문제가 아니라 조직 문제로 번집니다.
제가 가장 크게 걸린다고 보는 지점은 성능이 아니라 비용 구조입니다. 정적 도구는 아무것도 못 찾으면 비용도 들지 않습니다. 그런데 이쪽은 못 찾아도 토큰을 그대로 씁니다. protego.me 의 후기가 자기 사이트에 돌려 아무 소득 없이 약 17달러를 쓰고 Anthropic 키까지 자동 비활성화됐다고 적은 사례가 이 성질을 그대로 보여 줍니다. 그래서 저라면 전체 애플리케이션을 주기적으로 통째로 돌리지 않겠습니다. 평소에는 변경분과 새로 열린 엔드포인트로 범위를 좁혀 걸고, 전수 점검은 릴리스 직전에만 두는 쪽을 권합니다.
실력 자체를 의심할 필요는 없다고 봅니다. v0.4.0 이 XBEN CTF 과제 104개 중 100개를 블랙박스로 풀었고 모델 비용은 약 337달러로 보고됐습니다. 그럼에도 사람을 대체한다는 기대만큼은 접는 편이 낫습니다. 패턴이 정해진 취약점에는 사람보다 빠르고 싸지만, 결제 흐름을 우회하는 종류의 결함은 제품이 사용자에게 무엇을 약속했는지 알아야 비로소 보입니다. 그 영역은 자동화의 사각으로 남습니다. 같은 시기에 함께 올린 Bumblebee 와 짝으로 두면 역할이 깔끔하게 갈립니다. 그쪽은 설치된 것을 읽기만 하고, 이쪽은 실행해서 증명합니다.
비교
Bumblebee 가 설치된 패키지와 확장의 공급망 노출을 읽기 전용으로 점검한다면, Strix 는 애플리케이션을 실제로 실행해 취약점을 익스플로잇하고 검증합니다. 정적 스캐너가 내놓는 후보 목록 대신 재현 가능한 PoC 와 패치 후보를 받고 싶을 때 씁니다. 다만 Docker 와 LLM API 키가 전제라 가벼운 점검용은 아닙니다.
최근 변경
v1.5.3 에서 도구 없는 요청에 parallel_tool_calls 를 보내지 않도록 고치고, 버려진 브라우저 세션을 회수하며 컨테이너 이미지에서 환경 변수가 유실되던 문제를 바로잡았습니다.