Perkembangan Artificial Intelligence (AI) mulai mengubah cara penetration testing dilakukan. Jika sebelumnya penetration tester harus melakukan reconnaissance, enumeration, vulnerability discovery, validasi, exploitation, dan dokumentasi secara manual menggunakan banyak tool, kini sebagian workflow tersebut dapat diorkestrasi oleh AI agent.

Salah satu proyek open-source yang menarik untuk dipelajari adalah Strix dari usestrix/strix di GitHub.

Strix mendeskripsikan dirinya sebagai open-source AI penetration testing tool yang menggunakan autonomous AI agents untuk menjalankan security testing secara dinamis, menemukan vulnerability, dan memvalidasinya dengan proof of concept. Repository ini menggunakan lisensi Apache-2.0, membutuhkan Python 3.12 atau lebih baru, dan pada pyproject.toml saat ini mencantumkan versi paket 1.6.2. GitHub

Yang menarik, Strix bukan sekadar vulnerability scanner yang menghasilkan daftar kemungkinan masalah. Arsitekturnya menggabungkan LLM reasoning, browser automation, HTTP proxy, terminal, Python sandbox, reconnaissance, static analysis, dynamic analysis, serta multi-agent orchestration untuk mencoba memvalidasi temuan secara aktif. GitHub

Artikel ini membahas Strix dari dasar, cara kerjanya, arsitektur, metode instalasi, penggunaan pada lab, local LLM, scan modes, output, keterbatasan, serta bagaimana teknologi seperti ini dapat ditempatkan dalam workflow AppSec modern.


Apa Itu Strix?

Strix adalah AI-powered penetration testing agent.

Konsepnya dapat digambarkan seperti:

Target
  ↓
Reconnaissance
  ↓
Analysis
  ↓
Hypothesis
  ↓
Testing
  ↓
Exploitation
  ↓
Proof of Concept
  ↓
Finding
  ↓
Report

Repository resminya menyebut bahwa Strix dapat melakukan reconnaissance, exploitation, dan validation serta mengorkestrasi beberapa agen AI yang memiliki tugas berbeda. GitHub

Dengan demikian, Strix lebih tepat dipahami sebagai:

LLM
+
Security Tools
+
Execution Environment
+
Agent Orchestration
+
Validation

daripada sekadar:

Chatbot

Mengapa Strix Berbeda dari Chatbot AI Biasa?

Chatbot biasa:

User
 ↓
Prompt
 ↓
LLM
 ↓
Text response

Strix:

Target
 ↓
AI Agent
 ↓
Tool
 ↓
Observation
 ↓
Reasoning
 ↓
Tool
 ↓
Observation
 ↓
Reasoning
 ↓
Finding

Artinya model dapat melakukan siklus:

Observe
→ Think
→ Act
→ Observe
→ Re-plan

Inilah karakteristik utama agentic security testing.

Dokumentasi Strix menyebut sistemnya menggunakan beberapa agen khusus yang dapat berkolaborasi, berbagi discovery, serta melakukan chaining vulnerability dan workflow lintas fase penetration testing. GitHub


Strix Bukan Sekadar SAST

Untuk memahami posisi Strix, penting membedakan beberapa pendekatan security testing.

SAST

Static Application Security Testing menganalisis source code tanpa menjalankan aplikasi.

Source Code
 ↓
Static Analysis
 ↓
Finding

OWASP mencatat bahwa SAST dapat sangat membantu dalam menemukan masalah tertentu pada source code, tetapi juga memiliki keterbatasan, termasuk kesulitan mendeteksi sebagian masalah authentication, access control, runtime configuration, serta kesulitan membuktikan apakah sebuah temuan benar-benar dapat dieksploitasi. OWASP Community

DAST

Dynamic Application Security Testing menguji aplikasi saat sedang berjalan. NIST mendefinisikan DAST sebagai pengujian keamanan aplikasi secara dinamis terhadap aplikasi yang sedang berjalan. NIST Computer Security Resource Center

Running Application
 ↓
Dynamic Tests
 ↓
Finding

Strix

Strix mencoba menggabungkan:

Static Analysis
+
Dynamic Analysis
+
LLM Reasoning
+
Exploit Validation

Repository resminya secara eksplisit mencantumkan kemampuan SAST + DAST serta dynamic exploit validation. GitHub

Namun ini tidak berarti Strix secara otomatis menggantikan seluruh SAST, DAST, manual penetration testing, atau security review.

Lebih tepat melihatnya sebagai lapisan tambahan dalam AppSec.


Mengapa AI Agent Menarik untuk Pentesting?

Penetration testing memiliki banyak pekerjaan berulang:

Recon
Enumeration
Request manipulation
Browser interaction
Source inspection
Testing hypotheses
Running tools
Reading output
Documenting findings

Agent dapat membantu mengorkestrasi sebagian aktivitas tersebut.

Strix menyediakan tool seperti:

  • HTTP interception proxy
  • browser automation
  • terminal execution
  • Python exploit runtime
  • reconnaissance dan OSINT
  • static dan dynamic code analysis
  • vulnerability knowledge base

GitHub

Secara arsitektur:

                   STRIX AGENT
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
   Browser          Proxy         Terminal
        │              │              │
        ▼              ▼              ▼
     Web App       HTTP Traffic      Code
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                    LLM
                       │
                       ▼
                 Decision / Plan

Tool yang Digunakan Strix

Dokumentasi resminya menjelaskan beberapa tool yang tersedia bagi agent. GitHub

HTTP Interception Proxy

Strix menggunakan Caido untuk manipulasi dan analisis request/response HTTP.

Secara konsep:

Browser
 ↓
Proxy
 ↓
Application

Agent dapat mengamati request:

GET /login HTTP/1.1
Host: example.local

kemudian menganalisis response:

HTTP/1.1 200 OK

Informasi ini membantu agent membangun hipotesis mengenai behavior aplikasi.


Browser Automation

Strix memiliki automated browser untuk workflow seperti:

XSS
CSRF
Clickjacking
Authentication flow
Authorization testing

GitHub

Ini penting karena banyak vulnerability tidak dapat divalidasi hanya dengan membaca source code atau mengirim HTTP request sederhana.

Misalnya:

Login
 ↓
Session
 ↓
Role
 ↓
Browser state
 ↓
Application behavior

Agent yang dapat mengendalikan browser memiliki observasi yang lebih dekat dengan pengguna nyata.


Terminal dan Command Execution

Strix juga menyediakan shell/command execution dalam execution environment-nya. Repository menyebut terminal tersebut digunakan untuk exploit development dan post-exploitation. GitHub

Ini membuat:

LLM
 ↓
Command
 ↓
OS
 ↓
Result
 ↓
LLM

menjadi bagian dari workflow.

Karena kemampuan ini sangat powerful, isolasi execution environment menjadi aspek keamanan yang sangat penting.


Python Runtime

Strix menyediakan Python sandbox untuk menulis dan memvalidasi proof-of-concept exploit. GitHub

Artinya agent tidak hanya bisa mengatakan:

"Sepertinya ada SQL Injection."

tetapi dalam lingkungan yang sesuai dapat mencoba memvalidasi temuan secara langsung.

Konsepnya:

Hypothesis
 ↓
PoC
 ↓
Execution
 ↓
Observation
 ↓
Validation

Reconnaissance dan OSINT

Strix juga menyediakan kemampuan reconnaissance seperti:

attack surface mapping
subdomain enumeration
fingerprinting

GitHub

Workflow konseptual:

Domain
 ↓
Subdomain
 ↓
Technology
 ↓
Endpoint
 ↓
Potential Attack Surface

Ini membantu menghubungkan tahap reconnaissance dengan testing berikutnya.


Static dan Dynamic Code Analysis

Strix dapat melakukan:

Static Analysis

untuk memahami source code dan:

Dynamic Analysis

untuk melihat aplikasi pada saat runtime. Repository menyebut keduanya sebagai bagian dari capability AppSec Strix. GitHub

Hal ini penting untuk white-box security testing, karena agent tidak harus selalu blind terhadap source code.


Multi-Agent Architecture

Salah satu aspek paling menarik dari Strix adalah penggunaan graph of agents.

Alih-alih satu agent melakukan semuanya:

One Agent
   ↓
Everything

Strix dapat menggunakan agen spesialis:

                Coordinator
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      Recon       Web         Code
      Agent      Agent        Agent
        │           │           │
        └───────────┼───────────┘
                    ▼
              Exploit Agent
                    │
                    ▼
              Validation Agent

Repository resminya menyebut distributed pentesting, specialized agents untuk reconnaissance, exploitation, dan post-exploitation, serta dynamic coordination dan sharing of discoveries. GitHub

Konsep ini mirip dengan pembagian pekerjaan dalam red team.


Mengapa Multi-Agent Bisa Berguna?

Satu model memiliki context dan perhatian yang terbatas.

Dengan spesialisasi:

Recon Agent
→ attack surface

Web Agent
→ application behavior

Code Agent
→ source analysis

Exploit Agent
→ PoC validation

setiap komponen dapat fokus pada subproblem tertentu.

Namun multi-agent bukan jaminan bahwa hasil otomatis lebih akurat. Banyak agent berarti juga:

lebih banyak tool calls
+
lebih banyak state
+
lebih banyak context
+
lebih banyak kemungkinan salah koordinasi

Jadi orchestration sendiri menjadi bagian dari engineering.


Vulnerability Apa Saja yang Dapat Dicari?

Repository Strix saat ini mencantumkan cakupan seperti: GitHub

Broken Access Control
IDOR
Privilege Escalation
Authentication Bypass
SQL Injection
NoSQL Injection
OS Command Injection
SSTI
SSRF
XXE
Insecure Deserialization
RCE
XSS
Prototype Pollution
CSRF
Race Conditions
Payment Manipulation
Workflow Bypass
JWT
Session Fixation
Credential Stuffing Vectors

serta:

Infrastructure Misconfiguration
Cloud Security Issues
API Security
Rate Limit Bypass

GitHub

Cakupan ini juga relevan dengan OWASP Top 10:2025, yang mencakup Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software/Data Integrity Failures, Logging & Alerting Failures, dan Mishandling of Exceptional Conditions. OWASP Top 10


Strix dan Validasi Exploit

Ini merupakan konsep utama Strix.

Scanner tradisional dapat menghasilkan:

Potential SQL Injection

Strix bertujuan melanjutkan:

Potential vulnerability
 ↓
Try validation
 ↓
Proof of Concept
 ↓
Confirmed finding

Dokumentasi proyek mendeskripsikan pendekatan ini sebagai validated findings with proof-of-concept. GitHub

Namun istilah "validated" tetap perlu dipahami secara hati-hati.

Validasi otomatis tetap bergantung pada:

target
scope
model
tools
execution environment
test coverage

Jadi:

No finding

bukan bukti matematis bahwa:

No vulnerability exists.

Exit Code Strix

Headless mode Strix memiliki exit code khusus: GitHub

0
→ selesai tanpa vulnerability tervalidasi
1
→ fatal error
2
→ vulnerability ditemukan

Tetapi dokumentasi juga memberikan peringatan yang sangat penting:

Exit code 0 bukan bukti bahwa coverage sudah lengkap.

Jika scan berhenti karena budget atau turn limit, hasil bisa tetap menghasilkan exit code 0 dalam kondisi tertentu. Karena itu run.json, coverage report, budget, dan status run harus diperiksa sebelum menyimpulkan bahwa aplikasi "bersih". GitHub

Ini adalah prinsip penting dalam automated security testing:

No finding
≠
No vulnerability

Scan Modes

Strix memiliki tiga mode:

Quick
Standard
Deep

GitHub

Quick

Digunakan untuk:

CI/CD
Pull Request
Smoke Test

Durasi biasanya:

menit

Command:

strix --target ./app --scan-mode quick

Standard

Digunakan untuk:

Routine Security Review
Pre-release Validation
Development Milestone

Dokumentasi menyebut durasi sekitar:

30 menit - 1 jam

Command:

strix --target ./app --scan-mode standard

Dalam mode white-box, source-aware mapping dan static triage digunakan untuk membantu menentukan jalur validasi dinamis. GitHub


Deep

Deep merupakan mode paling menyeluruh.

Digunakan untuk:

Comprehensive Security Audit
Pre-production Review
Critical Application

Dokumentasi Strix menyebut durasi dapat berada pada kisaran 1 sampai 4 jam, tergantung kompleksitas target. Deep mode juga menjadi default dan dirancang mengeksplorasi edge cases, chained vulnerabilities, serta attack paths yang kompleks. GitHub

Command:

strix --target ./app --scan-mode deep

Target Apa Saja yang Bisa Diuji?

Strix mendukung berbagai jenis target. GitHub

Local Codebase

strix --target ./app-directory

Cocok untuk:

white-box assessment
developer workflow
local testing

GitHub Repository

Strix juga menerima repository GitHub sebagai target:

strix --target https://github.com/org/repo

GitHub

Pastikan repository tersebut memang:

milik Anda
atau
Anda memiliki izin untuk melakukan security testing

Live Web Application

Untuk aplikasi web yang berada dalam scope:

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

Dokumentasi resmi mendukung live web application sebagai target. GitHub

Dalam konteks nyata, jangan memasukkan website publik secara sembarangan.


Multiple Targets

Strix juga mendukung beberapa target:

strix -t https://github.com/org/repo -t https://your-app.com

Ini berguna ketika melakukan white-box assessment yang menghubungkan:

source code
+
running application

GitHub


API Security Testing

Strix dapat menggunakan:

OpenAPI
Swagger
Postman
GraphQL

untuk membantu mengarahkan pengujian API.

Contoh resmi:

strix --target ./openapi.yaml --target https://api.your-app.com

GitHub

Keuntungannya adalah agent tidak harus hanya mengandalkan crawling.

Dengan OpenAPI:

Specification
 ↓
Endpoints
 ↓
Parameters
 ↓
Authentication
 ↓
Testing

Cakupan endpoint dapat lebih terstruktur.


Cara Install Strix

Repository saat ini menyediakan dua jalur instalasi CLI yang umum.

Metode Installer

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

Metode pipx

pipx install strix-agent

Keduanya tercantum dalam quick start resmi. GitHub


Persyaratan Sistem

Menurut pyproject.toml, Strix membutuhkan:

Python >= 3.12

dan menggunakan Docker sebagai runtime default. GitHub

Quick start resminya juga mensyaratkan:

Docker running
LLM API key

untuk konfigurasi model cloud. GitHub


Instalasi di Kali Linux

Contoh:

python3 --version

Pastikan:

Python 3.12+

Kemudian:

pipx install strix-agent

Cek:

strix --version

Setelah itu pastikan Docker:

docker --version

dan:

docker ps

dapat berjalan.


Instalasi di Ubuntu

Prinsipnya sama:

python3 --version
pipx --version
docker --version

kemudian:

pipx install strix-agent

atau installer resmi:

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

Instalasi di Windows

Karena Strix membutuhkan Docker dan Python, Windows dapat menggunakan environment seperti:

Windows
 ↓
Docker Desktop
 ↓
Python / pipx
 ↓
Strix

Pastikan Docker Desktop sedang running sebelum scan.

Karena dokumentasi proyek mendeskripsikan Docker sebagai runtime yang digunakan, jangan menganggap instalasi CLI saja sudah cukup. GitHub


Konfigurasi LLM

Strix menggunakan LiteLLM untuk kompatibilitas provider, sehingga dokumentasinya mencantumkan dukungan terhadap lebih dari 100 provider/model backend. GitHub

Konfigurasi sederhana:

export STRIX_LLM="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="your-api-key"

Dokumentasi quick start saat ini juga mencantumkan beberapa model yang direkomendasikan untuk hasil terbaik seperti model GLM, GPT, dan Claude tertentu. GitHub

Nama model dan rekomendasi tersebut dapat berubah mengikuti perkembangan provider, sehingga sebaiknya selalu merujuk dokumentasi Strix terbaru.


Apakah Strix Bisa Menggunakan Local LLM?

Bisa.

Ini salah satu fitur menariknya.

Dokumentasi resmi menyediakan panduan untuk:

Ollama
LM Studio
vLLM
OpenAI-compatible server

Contoh Ollama:

ollama pull qwen3-vl

kemudian:

export STRIX_LLM="ollama/qwen3-vl"
export LLM_API_BASE="http://localhost:11434"

GitHub


Strix + Local LLM

Arsitekturnya:

                 LOCAL MACHINE

┌──────────────┐
│ Strix        │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Ollama       │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Local LLM    │
└──────────────┘

Untuk privasi, model lokal memberikan keuntungan karena data dapat tetap berada di komputer sendiri.

Dokumentasi Strix secara eksplisit menjelaskan bahwa local models memungkinkan security assessments dilakukan secara lokal dan dapat digunakan untuk environment yang sensitif atau air-gapped. GitHub


Tetapi Local LLM Tidak Otomatis Lebih Baik

Strix memberikan catatan yang sangat penting:

local models tertentu, terutama model di bawah sekitar 70B parameter, dapat kesulitan dengan agentic tasks yang kompleks.

Dokumentasi menyebut trade-off:

Local Model
→ privacy tinggi
→ cost model bisa rendah
→ setup lebih kompleks
→ reasoning/agentic performance dapat lebih rendah

sedangkan:

Cloud Model
→ reasoning lebih kuat pada model tertentu
→ setup lebih sederhana
→ data diproses provider
→ biaya bisa berbasis penggunaan

GitHub

Jadi pemilihan model bukan sekadar soal "model terbesar".

Yang diperlukan adalah:

reasoning
+
tool calling
+
context management
+
self-correction

Mengapa Tool Calling Penting?

Agent pentesting tidak cukup hanya menghasilkan teks.

Ia harus dapat:

call browser
call proxy
call shell
call Python
inspect file
analyze response

Secara konseptual:

LLM
 ↓
Tool Call
 ↓
Tool Execution
 ↓
Result
 ↓
LLM

Jika tool calling buruk:

Agent reasoning
↓
Tool call malformed
↓
scan gagal

Karena itu model local yang memiliki benchmark chat bagus belum tentu otomatis menjadi model yang bagus untuk autonomous pentesting.

Strix sendiri mendokumentasikan bahwa agentic capabilities seperti multi-step planning, tool use, dan self-correction merupakan kebutuhan penting. GitHub


Contoh Scan Pertama

Misalnya Anda mempunyai aplikasi lokal:

./my-flask-app

jalankan:

strix --target ./my-flask-app

Strix akan menggunakan sandbox Docker dan membuat directory hasil:

strix_runs/

Repository resmi menjelaskan bahwa image sandbox akan di-pull otomatis pada first run dan hasil disimpan di strix_runs/<run-name>. GitHub


Mengapa Docker Sandbox Penting?

Strix menggunakan:

Docker Sandbox

untuk execution environment.

Konsepnya:

Host
 │
 │
 ▼
Strix
 │
 ▼
Sandbox Container
 │
 ├── Browser
 ├── Tools
 ├── Runtime
 └── Target interaction

Ini memberikan boundary tambahan dibandingkan mengeksekusi seluruh aktivitas agent langsung pada host.

Tetapi sandbox bukan jaminan keamanan absolut.

Dokumentasi tetap mengingatkan bahwa Strix secara aktif menguji target yang diberikan sehingga target harus berada dalam scope yang sah. GitHub


Melihat Hasil Scan

Setiap run disimpan pada:

strix_runs/<run-name>/

Artifact utama yang didokumentasikan Strix antara lain:

penetration_test_report.md
vulnerabilities/*.md
vulnerabilities.json
vulnerabilities.csv
findings.sarif
run.json

GitHub

Artinya hasil tidak hanya diberikan sebagai tampilan terminal.

Anda bisa menggunakannya untuk:

reporting
CI/CD
triage
automation
security management

Apa Isi penetration_test_report.md?

Ini biasanya menjadi file pertama yang dibaca.

Strix mendeskripsikannya sebagai executive report. GitHub

Secara konsep:

Target
↓
Executive Summary
↓
Findings
↓
Evidence
↓
Impact
↓
Remediation

Untuk engineering, file per-finding dapat memberikan informasi lebih detail.


File Vulnerability Individual

Folder:

vulnerabilities/

berisi satu file untuk setiap validated finding. Dokumentasi menyebut file tersebut memuat PoC dan remediation. GitHub

Konsepnya:

Finding
├── Description
├── Evidence
├── PoC
├── Impact
└── Remediation

Format semacam ini jauh lebih berguna dibanding:

"SQL Injection detected."

karena developer membutuhkan informasi untuk memperbaikinya.


JSON dan CSV

Strix juga menyediakan:

vulnerabilities.json
vulnerabilities.csv

GitHub

JSON cocok untuk automation:

Strix
 ↓
JSON
 ↓
Python
 ↓
Dashboard / Database

CSV cocok untuk:

Excel
Spreadsheet
Triage
Analisis

SARIF

Strix juga memiliki:

findings.sarif

yang digunakan untuk integrasi dengan GitHub code scanning atau ASPM. Dokumentasi skill resmi menyebut format yang digunakan adalah SARIF 2.1.0. GitHub

Ini menarik untuk workflow DevSecOps:

Git Push
 ↓
CI
 ↓
Strix
 ↓
SARIF
 ↓
Security Platform
 ↓
Developer

Strix dan CI/CD

Repository resmi saat ini menampilkan integrasi dengan:

GitHub Actions
GitLab
Bitbucket
Slack
Jira
Linear

serta pipeline CI/CD. GitHub

Konsepnya:

Developer
   ↓
Pull Request
   ↓
CI
   ↓
Strix
   ↓
Security Testing
   ↓
Finding?
 ┌───────┴───────┐
No              Yes
 ↓                ↓
Continue       Review/Fix

Strix juga menyediakan mode Quick yang memang ditujukan untuk CI/CD dan pull request validation. GitHub


Strix dari Sudut Pandang DevSecOps

DevSecOps berusaha memindahkan security testing lebih dekat ke software delivery lifecycle.

Tanpa automation:

Code
 ↓
Build
 ↓
Deploy
 ↓
Security Review

Dengan security automation:

Code
 ↓
Build
 ↓
Automated Security Testing
 ↓
Review
 ↓
Deploy

Strix dapat ditempatkan sebagai bagian dari lapisan tersebut.

Tetapi untuk aplikasi kritis, sebaiknya workflow tetap menggabungkan:

SAST
+
Dependency/SCA
+
DAST
+
AI Pentesting
+
Manual Review

karena tidak ada satu tool yang dapat memberikan coverage sempurna untuk semua jenis weakness.


Strix dan OWASP Top 10:2025

OWASP Top 10:2025 saat ini mencantumkan 10 kategori berikut: OWASP Top 10

A01 Broken Access Control
A02 Security Misconfiguration
A03 Software Supply Chain Failures
A04 Cryptographic Failures
A05 Injection
A06 Insecure Design
A07 Authentication Failures
A08 Software or Data Integrity Failures
A09 Security Logging & Alerting Failures
A10 Mishandling of Exceptional Conditions

Strix mencantumkan sejumlah kemampuan yang bersinggungan dengan kategori-kategori tersebut, seperti access control, injection, authentication, security misconfiguration, dan logging-related application testing. GitHub

Namun penting membedakan:

OWASP category

dengan:

Strix capability

Kesamaan kategori tidak berarti Strix menjamin seluruh CWE dalam kategori tersebut akan selalu ditemukan.


Contoh Workflow White-Box

Misalnya Anda memiliki:

Flask Application

directory:

my-app/
├── app.py
├── templates/
├── static/
├── requirements.txt
└── database.py

Jalankan:

strix --target ./my-app --scan-mode deep

Secara konsep agent akan:

Read Code
 ↓
Map Application
 ↓
Identify Inputs
 ↓
Identify Sensitive Functions
 ↓
Launch Application
 ↓
Test Dynamic Behavior
 ↓
Validate Interesting Paths
 ↓
Generate Findings

White-box scan dapat menggunakan source-aware triage untuk membantu menentukan jalur pengujian dinamis. GitHub


Contoh Workflow Black-Box

Misalnya Anda memiliki aplikasi staging:

https://staging.example.test

Jalankan:

strix --target https://staging.example.test

Agent tidak mendapatkan source code secara otomatis.

Workflow dapat menjadi:

Target
 ↓
Recon
 ↓
Fingerprint
 ↓
Crawl
 ↓
Browser
 ↓
HTTP Testing
 ↓
Hypothesis
 ↓
Validation

Ini lebih dekat dengan traditional black-box penetration testing.


Contoh Workflow API

Jika tersedia:

openapi.yaml

gunakan:

strix --target ./openapi.yaml --target https://api.example.test

Dengan demikian:

OpenAPI
 ↓
Endpoints
 ↓
Parameter
 ↓
Authentication
 ↓
Dynamic Security Testing

Dokumentasi resmi menyatakan bahwa pendekatan ini membantu Strix menguji endpoint yang dideklarasikan daripada hanya mengandalkan crawling. GitHub


Strix dan Authentication Testing

Aplikasi modern memiliki banyak flow:

Login
Register
Password Reset
MFA
OAuth
JWT
Session
Role

Strix mencantumkan authentication and session testing sebagai salah satu coverage area. GitHub

Misalnya:

User
 ↓
Login
 ↓
Session
 ↓
Role
 ↓
Authorization

Agent dapat berusaha memahami apakah boundary tersebut benar-benar diterapkan di server.

Ini sangat relevan dengan Broken Access Control, yang tetap menjadi A01 pada OWASP Top 10:2025. OWASP Top 10


Mengapa Business Logic Sulit?

Business logic berbeda dengan vulnerability teknis sederhana.

Misalnya:

Normal workflow

Cart
 ↓
Checkout
 ↓
Payment
 ↓
Order

Masalah bisa muncul jika:

Step A
 ↓
Step C
 ↓
Step B

atau:

Discount
+
Refund
+
Race Condition

menghasilkan state yang tidak seharusnya.

Strix mencantumkan race conditions, payment manipulation, dan workflow bypass dalam business-logic coverage. GitHub

Tetapi business logic merupakan salah satu area di mana context bisnis dan human judgment tetap sangat penting.


Apakah Strix Bisa Menulis Exploit?

Repository menyatakan Strix memiliki Python runtime untuk menulis dan memvalidasi PoC exploit. GitHub

Namun tujuan yang tepat adalah:

Validate Finding

bukan:

Attack unrelated systems

Dalam security assessment profesional, exploit development harus tetap berada dalam scope dan dilakukan dengan safeguards yang sesuai.


Apakah Strix Bisa Auto-Fix?

Repository resminya saat ini mencantumkan kemampuan auto-fix dan reporting, serta cloud workflow yang dapat menghasilkan security patch sebagai pull request. GitHub

Ini dapat menghasilkan workflow:

Finding
 ↓
Root Cause
 ↓
Suggested Fix
 ↓
Patch
 ↓
Retest

Tetapi prinsip pentingnya:

Jangan otomatis merge semua AI-generated security fixes.

Patch harus:

reviewed
tested
security validated

karena patch yang "memperbaiki" satu vulnerability masih dapat memunculkan regression atau masalah baru.


Local Strix + Local LLM untuk Privacy

Salah satu konfigurasi menarik:

Strix
+
Ollama
+
Local Model
+
Docker

Arsitekturnya:

              LOCAL MACHINE

┌───────────────────────────┐
│          Strix            │
├───────────────────────────┤
│       Docker Sandbox      │
├───────────────────────────┤
│          Ollama           │
├───────────────────────────┤
│       Local LLM           │
└───────────────────────────┘

Dokumentasi Strix secara khusus menyebut local model sebagai opsi untuk privacy-first dan air-gapped testing. GitHub

Ini menarik untuk:

internal code
confidential application
private network
sensitive source code

tetapi sekali lagi kualitas reasoning model menjadi faktor utama.


Kapan Sebaiknya Menggunakan Cloud LLM?

Cloud model dapat masuk akal ketika:

agentic reasoning
complex planning
tool use
self-correction

lebih penting daripada:

absolute data locality

Dokumentasi Strix sendiri merekomendasikan model cloud state-of-the-art untuk assessment kritis dan menyarankan local models ketika privacy merupakan prioritas utama. GitHub

Keputusan tersebut pada akhirnya bergantung pada:

Data classification
Compliance
Budget
Model capability
Network architecture
Risk tolerance

Apakah Strix Gratis?

Repository open-source Strix menyatakan bahwa mode open-source dapat berjalan secara lokal dengan Docker dan LLM key milik pengguna sendiri. GitHub

Jadi:

Software Strix
→ open source

tetapi:

Cloud LLM API
→ dapat dikenakan biaya

Jika menggunakan local LLM:

Model inference
→ dapat dilakukan lokal

sehingga biaya API dapat dihindari, tetapi tetap ada biaya hardware dan listrik.


Cara Menghentikan Scan

Karena agent dapat menjalankan banyak tool call, selalu sediakan cara menghentikan proses.

Dari sisi engineering:

Timeout
Budget
Max turns
Process cancellation
Docker cleanup

Strix sendiri memiliki configuration untuk:

LLM timeout
stream idle timeout
max tool calls per turn
context auto-compaction

yang tercantum pada konfigurasi internal proyek. GitHub

Ini merupakan contoh bahwa agent runtime management sama pentingnya dengan kemampuan LLM.


Budget dan Context

Agentic pentesting dapat menghasilkan context sangat besar:

HTTP responses
HTML
source code
terminal output
screenshots
logs

Strix menyediakan context management seperti:

auto compaction
tool output caps
maximum bytes
maximum lines

GitHub

Mengapa ini penting?

Karena:

Context terlalu besar
 ↓
LLM cost meningkat
 ↓
reasoning bisa terganggu

dan:

Tool output terlalu besar
 ↓
signal-to-noise ratio turun

Jadi context engineering adalah bagian penting dari AI pentesting.


Keterbatasan Strix

Walaupun pendekatannya menarik, jangan menganggap Strix sebagai "pentester yang tidak pernah salah".

Ada beberapa keterbatasan fundamental.

Model Dependency

Kinerja agent sangat bergantung pada kemampuan LLM melakukan:

reasoning
planning
tool calling
context management
self-correction

Dokumentasi local model bahkan secara eksplisit memperingatkan mengenai kelemahan model lokal pada agentic tasks tertentu. GitHub


Coverage Tidak Sama dengan Exhaustiveness

Strix memiliki banyak capability.

Tetapi:

Supported vulnerability
≠
guaranteed detection

Begitu juga:

0 findings
≠
zero vulnerabilities

Dokumentasi exit-code Strix secara eksplisit memberikan peringatan tentang coverage dan budget limit. GitHub


False Positive dan False Negative

Strix berusaha memvalidasi vulnerability melalui PoC.

Itu dapat mengurangi sejumlah false positive.

Namun:

No false positive ever

bukan klaim yang dapat dijamin.

Begitu pula:

No false negative

tidak realistis untuk automated security testing.

Setiap scanner dan agent memiliki:

false positives
false negatives
coverage gaps
environment limitations

Karena itu manual validation tetap penting.


Human Pentester Tetap Penting

AI agent dapat melakukan:

Enumeration
Testing
Automation
Correlation
PoC generation
Documentation

Tetapi manusia tetap dibutuhkan untuk:

scope
business context
risk interpretation
sensitive action
validation
creative reasoning
final judgment

Terutama pada:

Business Logic
Complex Architecture
Highly Privileged Systems
Production Environment

AI sebaiknya menjadi force multiplier, bukan alasan untuk menghapus seluruh proses security review.


Security Risk dari Autonomous Pentesting

Karena Strix memiliki:

browser
proxy
terminal
Python
network access

maka agent itu sendiri menjadi security-sensitive system.

Bayangkan:

Prompt
 ↓
Agent
 ↓
Command Execution

Jika target atau input mengandung prompt injection, agen bisa saja diarahkan melakukan tindakan yang tidak sesuai desain.

Karena itu autonomous pentesting harus menggunakan prinsip:

least privilege
sandbox
scope enforcement
network restriction
logging
approval

Ini sangat relevan dengan risiko indirect prompt injection yang dapat terjadi ketika agent membaca website atau file eksternal.


Jangan Menjalankan Strix ke Target Acak

README resmi Strix memberikan peringatan:

gunakan hanya terhadap sistem yang Anda miliki atau yang memiliki izin tertulis untuk diuji dan tetap berada dalam scope yang disepakati. GitHub

Ini sangat penting karena Strix bukan passive scanner.

Ia memang dapat:

actively test
actively exploit
actively validate

Jadi command:

strix --target https://example.com

tidak boleh dianggap sama dengan sekadar:

curl https://example.com

Gunakan Strix di Lab

Untuk belajar, buat environment:

Kali Linux
   ↓
Docker
   ↓
Vulnerable App
   ↓
Strix

Contoh target:

DVWA
OWASP Juice Shop
WebGoat
Custom Flask Lab
Custom API Lab

Workflow:

Lab
 ↓
Run Strix
 ↓
Observe
 ↓
Read PoC
 ↓
Understand Root Cause
 ↓
Fix
 ↓
Retest

Ini jauh lebih bermanfaat untuk pembelajaran.


Strix + Vulnerable Flask App

Misalnya Anda membuat:

from flask import Flask, request

app = Flask(__name__)

@app.route("/search")
def search():
    q = request.args.get("q", "")
    return f"<h1>Search</h1><p>{q}</p>"

app.run()

Jalankan secara lokal:

python app.py

Kemudian:

http://127.0.0.1:5000

Anda dapat menggunakan Strix untuk memeriksa aplikasi tersebut dalam lab.

Contoh:

strix --target http://127.0.0.1:5000 --scan-mode quick

Tujuan pengujian:

Understand finding
+
Observe request
+
Understand PoC
+
Fix source
+
Retest

Setelah Menemukan Vulnerability

Jangan langsung puas dengan:

Found

Gunakan:

Finding
 ↓
Root Cause
 ↓
Fix
 ↓
Unit Test
 ↓
Security Test
 ↓
Strix Retest

Misalnya aplikasi memiliki bug authorization:

User A
 ↓
GET /users/100

dan dapat mengakses:

User B

Perbaikan harus berada di server-side authorization logic, bukan sekadar menyembunyikan tombol pada frontend.

OWASP juga menekankan bahwa access control harus ditegakkan pada trusted server-side code dan default-nya deny. OWASP Top 10


Strix sebagai Security Regression Testing

Salah satu penggunaan yang menarik adalah:

Bug ditemukan
 ↓
Fix
 ↓
Strix
 ↓
Retest

Jika vulnerability tidak lagi dapat divalidasi:

Finding
→ fixed

Ini dapat dijadikan bagian dari security regression workflow.

Secara prinsip:

Security Test
+
Retest
=
Continuous Security

Strix dalam CI/CD

Contohnya:

Developer
   ↓
Pull Request
   ↓
GitHub Actions
   ↓
Strix Quick Scan
   ↓
SARIF
   ↓
Security Finding

Mode Quick memang ditujukan untuk pipeline dan PR validation. GitHub

Sedangkan:

Major Release
 ↓
Deep Scan
 ↓
Detailed Report

dapat menggunakan mode Deep.


Strix dan Security Report

Salah satu kelebihan workflow agentic adalah kemampuan mengubah aktivitas teknis menjadi report.

Hasil dapat terdiri dari:

Executive Report
Finding-specific reports
JSON
CSV
SARIF
Run metadata

GitHub

Ini memberikan pipeline:

Testing
 ↓
Evidence
 ↓
Finding
 ↓
Report
 ↓
Remediation

Cara Membaca Hasil Strix dengan Benar

Jangan hanya membuka:

severity: HIGH

Lihat juga:

What happened?
Why?
Evidence?
PoC?
Affected component?
Impact?
Remediation?

Jika ada:

SQL Injection

tanyakan:

parameter mana?
endpoint mana?
database context apa?
apakah benar exploitable?
apa evidence-nya?

Jika:

IDOR

tanyakan:

object identifier apa?
authentication state apa?
authorization check apa?

Dengan demikian output agent menjadi dasar analisis, bukan pengganti analisis.


Strix dan CVSS

Repository menyebut vulnerability knowledge base-nya menggunakan CVSS scoring dan klasifikasi OWASP. GitHub

Namun CVSS tetap harus dilihat sebagai representasi risk severity berdasarkan framework penilaian, bukan sebagai pengganti business impact assessment.

Misalnya vulnerability:

Medium CVSS

bisa memiliki dampak bisnis besar jika:

aset sangat kritis
data sangat sensitif
dipakai banyak pelanggan

Karena itu security report profesional perlu menggabungkan:

Technical Severity
+
Business Context

Strix dan OWASP WSTG

Untuk membuat workflow lebih terstruktur, Strix dapat dipadukan secara konseptual dengan OWASP Web Security Testing Guide.

Misalnya:

WSTG
 ↓
Testing Category
 ↓
Strix Automation
 ↓
Manual Validation

Ini memungkinkan tim menjaga methodology tetap terstruktur sekaligus menggunakan agent untuk automation.


Strix dan Penetration Testing Tradisional

Keduanya dapat dibayangkan:

Traditional Pentest
-------------------
Human reasoning
Manual tools
Custom workflow
Manual validation
Manual report
AI Pentesting
-------------------
LLM reasoning
Automated tools
Agent workflow
Automated validation
Automated report

Pendekatan modern dapat menjadi:

Human
+
AI Agent
+
Security Tools

sehingga manusia fokus pada:

scope
architecture
business logic
risk
final verification

sementara agent mengambil pekerjaan automation yang repetitif.


Roadmap Belajar Strix

Untuk mahasiswa cybersecurity atau pentester pemula:

Level 1
Linux
Networking
HTTP
Web fundamentals

        ↓

Level 2
OWASP Top 10
Burp Suite
Nmap
Web testing

        ↓

Level 3
Python
Docker
API
Authentication
Authorization

        ↓

Level 4
AI / LLM
Prompt
Tool Calling
Agentic Workflow

        ↓

Level 5
Strix
SAST + DAST
PoC Validation
Multi-Agent

        ↓

Level 6
DevSecOps
CI/CD
SARIF
Security Regression

Jangan langsung belajar Strix tanpa memahami web security.

Kalau tidak, Anda mungkin hanya melihat:

AI found vulnerability

tanpa mengetahui apakah hasil tersebut masuk akal.


Checklist Sebelum Menjalankan Strix

[ ] Target sudah memiliki izin
[ ] Scope sudah jelas
[ ] Environment benar
[ ] Docker berjalan
[ ] Python >= 3.12
[ ] LLM provider sudah dikonfigurasi
[ ] Budget / timeout ditentukan
[ ] Network access dipahami
[ ] Sensitive data diperhatikan
[ ] Scan mode dipilih
[ ] Hasil run disimpan
[ ] Finding diverifikasi
[ ] Remediation dilakukan
[ ] Retest dilakukan

Checklist Memilih Mode

Pull Request
→ Quick

Routine Security Review
→ Standard

Pre-Production
→ Deep

Critical Application
→ Deep
+
Manual Assessment

Deskripsi tersebut mengikuti penggunaan mode yang direkomendasikan dalam dokumentasi Strix. GitHub


Perintah Dasar Strix

# Install
pipx install strix-agent

# Version
strix --version

# Local codebase
strix --target ./app

# Live web app yang Anda miliki / berizin
strix --target https://staging.example.com

# Quick
strix --target ./app --scan-mode quick

# Standard
strix --target ./app --scan-mode standard

# Deep
strix --target ./app --scan-mode deep

# API
strix --target ./openapi.yaml --target https://api.example.com

Perintah tersebut mengikuti contoh yang didokumentasikan oleh proyek saat ini. GitHub


Perintah untuk Melihat Hasil

Setelah scan:

strix view

Untuk run tertentu:

strix view my-run-name

Strix menyediakan local web viewer yang menampilkan findings, live map agent team, dan historical runs. Viewer secara default bind ke 127.0.0.1; ketika di-expose ke interface lain, dokumentasi menyarankan berhati-hati terhadap tokenized link yang memberikan akses ke hasil run. GitHub


Strix Bisa Dipakai oleh Coding Agent

Ini salah satu perkembangan yang menarik.

Repository Strix menyediakan skills yang dapat diinstal ke coding agents seperti:

Claude Code
Cursor
Codex

menggunakan:

npx skills add usestrix/strix

GitHub

Dengan demikian workflow dapat menjadi:

Coding Agent
 ↓
Implement Feature
 ↓
Strix
 ↓
Security Test
 ↓
Finding
 ↓
Fix
 ↓
Retest

Ini mulai mendekati konsep:

AI-assisted DevSecOps loop.


Contoh Siklus Development Modern

Requirement
    ↓
AI Coding Agent
    ↓
Code
    ↓
Build
    ↓
Strix
    ↓
Security Findings
    ↓
AI Fix
    ↓
Strix Retest
    ↓
Human Review
    ↓
Production

Pada sistem seperti ini, security testing tidak lagi selalu menjadi tahap yang datang paling akhir.

Security dapat menjadi bagian dari development loop.


Apakah Strix Menggantikan Pentester?

Tidak otomatis.

Strix dapat mengotomatisasi banyak pekerjaan:

recon
enumeration
testing
validation
documentation

tetapi pentester manusia masih diperlukan untuk:

complex business logic
unusual architecture
risk interpretation
scope decisions
creative attack paths
final validation

Bahkan jika AI menjadi semakin baik, pertanyaan seperti:

"Apakah vulnerability ini benar-benar berdampak terhadap bisnis?"

tetap membutuhkan context yang mungkin tidak tersedia dalam code atau HTTP response.


Masa Depan AI Pentesting

Strix menggambarkan arah yang menarik:

Traditional Scanner
        ↓
AI-Assisted Scanner
        ↓
AI Agent
        ↓
Multi-Agent Security Testing
        ↓
Continuous AI Pentesting

Perubahannya adalah dari:

Detect

ke:

Understand
→ Test
→ Validate
→ Explain
→ Fix
→ Retest

Ini merupakan pergeseran penting karena security testing bukan hanya masalah menemukan pattern, tetapi memahami causal chain dari input menuju impact.


Kesimpulan

Strix adalah open-source AI penetration testing tool yang menggabungkan LLM agent, security tools, browser automation, HTTP interception, terminal execution, Python sandbox, static/dynamic analysis, dan multi-agent orchestration. Repository resminya menggunakan Apache-2.0 dan saat ini mencantumkan versi paket 1.6.2 dengan Python 3.12+ sebagai requirement. GitHub

Konsep utamanya dapat diringkas:

Target
 ↓
Recon
 ↓
Analyze
 ↓
Hypothesis
 ↓
Exploit
 ↓
Validate
 ↓
PoC
 ↓
Finding
 ↓
Report
 ↓
Fix
 ↓
Retest

Strix mendukung:

Local Codebase
GitHub Repository
Live Web Application
API
OpenAPI / Swagger
Postman

serta tiga scan mode:

Quick
Standard
Deep

GitHub

Salah satu karakteristik pentingnya adalah pendekatan validated findings. Strix berusaha tidak hanya menunjukkan bahwa sebuah pola terlihat mencurigakan, tetapi melanjutkan pengujian untuk memperoleh evidence dan proof of concept. Hasilnya dapat disimpan dalam Markdown, JSON, CSV, dan SARIF. GitHub

Strix juga dapat menggunakan local LLM melalui Ollama, LM Studio, atau OpenAI-compatible server, sehingga dapat menjadi pilihan untuk environment yang membutuhkan privacy dan data locality. Namun dokumentasi resminya sendiri mengingatkan bahwa kualitas local model untuk agentic reasoning dapat lebih rendah dibanding model cloud state-of-the-art tertentu. GitHub

Yang paling penting adalah memahami bahwa:

AI Pentesting
≠
Magic Scanner

dan:

No Finding
≠
No Vulnerability

Automated agent tetap mempunyai keterbatasan coverage, model dependency, false positive, false negative, dan keterbatasan context.

Karena Strix juga memiliki kemampuan untuk melakukan testing dan exploitation aktif, gunakan hanya pada sistem sendiri atau sistem yang secara eksplisit memberikan izin pengujian dan selalu pertahankan scope yang telah disepakati. GitHub

Pada akhirnya, Strix paling menarik bukan karena "AI bisa hacking sendiri", tetapi karena ia menunjukkan bagaimana AI agent dapat menjadi lapisan otomasi baru dalam application security:

Developer
   +
Security Engineer
   +
AI Agent
   +
CI/CD
   =
Continuous Security Testing

SIBRA SECURITY

Perkembangan AI pentesting membuka peluang untuk membuat security testing menjadi lebih cepat dan lebih terintegrasi dengan software development. Namun automated testing tetap perlu diimbangi dengan scope control, manual validation, vulnerability analysis, remediation, dan retesting.

SIBRA Security menyediakan layanan penetration testing, vulnerability assessment, security assessment, website security assessment, security hardening, website monitoring, serta konsultasi cybersecurity untuk membantu organisasi mengidentifikasi risiko dan memperkuat keamanan sistem mereka.

Untuk aplikasi modern, assessment dapat dikombinasikan dengan pendekatan seperti:

Reconnaissance
      ↓
Automated Security Testing
      ↓
Manual Validation
      ↓
Vulnerability Analysis
      ↓
Security Report
      ↓
Remediation
      ↓
Retesting

SIBRA Security membantu mengubah temuan teknis menjadi rekomendasi keamanan yang dapat ditindaklanjuti oleh tim development maupun IT.