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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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.
Diskusi & Komentar