The Problem

Security testing teams juggle dozens of standalone tools—scanners, exploit frameworks, C2 servers—with no unified orchestration layer. Running an engagement means switching between UIs, manually correlating results, and keeping audit trails by hand. CyberStrikeAI consolidates tool execution, agent-driven decision-making, and result tracking into one platform with a web console and MCP interface.

What This Does

CyberStrikeAI is a Go-based security testing platform. It exposes an MCP server (internal/mcp/server.go) over HTTP/SSE and stdio (cmd/mcp-stdio/main.go), a web dashboard (web/static/js/), and a C2 framework (internal/c2/listener_http.go) for authorized engagements. The internal/agent/ package drives an AI decision engine that routes tasks through predefined roles and skills.

The repo includes a Burp Suite extension under plugins/burp-suite/ and a collection of agent orchestration docs in agents/. It's a portfolio of five self-contained projects rather than a single codebase.

How It Is Wired

Execution starts at main in cmd/mcp-stdio/main.go:16, which reaches 402 functions. The server entry point is Run in internal/app/app.go:547, called from 11 places. mcpHandlerWithAuth (internal/app/app.go:530) handles HTTP requests and reaches 406 functions—the widest reach in the repo.

The shortest path to a side effect is main -> Load which calls os.ReadFile—one hop to the filesystem. Database access is two hops: Run -> tick -> ListC2Sessions calls db.Query. File writes happen via Serve -> handleConn -> handleTCPBeaconSession calling os.WriteFile.

Key modules and their blast radius:

  • internal/app/app.go — 12 functions, called from 50 files, calls into 60. Defines New, Run, Shutdown.
  • internal/handler/config.go — 56 functions, calls a model for inference and reads/writes files.
  • internal/handler/agent.go — 55 functions, reads/writes files and database.
  • internal/logger/logger.go — Info is called from 96 places; changing it affects nearly everything.

The import graph shows 29 internal modules with zero edges—no cycles, but also no hub structure. The risk is concentrated in the handler layer, not the module graph.

How To Use It

git clone https://github.com/moses-y/CyberStrikeAI
cd CyberStrikeAI
go build ./cmd/server
./server

Configuration lives in config.yaml at the repo root. The MCP stdio mode runs via go run ./cmd/mcp-stdio. There's no Dockerfile or CI configuration, so deployment is manual. The install-tools.sh script handles external tool installation.

Real-World Use

A security team runs an authorized penetration test: they start the server, configure an OpenAI-compatible model in config.yaml, and interact through the web console or an MCP client. The AI agent orchestrates tools from the 100+ integrated in tools/, tracks findings in the database, and manages C2 sessions for post-exploitation. Results land in the vulnerability management module with full audit trails.

Code Health & Issues

Static analysis found 150 issues: 44 high, 106 medium. The high-severity findings are concentrated in internal/app/app.go, internal/handler/agent.go, and internal/handler/config.go:

  • High — Deep nesting (35 occurrences): max indentation depth 9, hard to follow control flow.
  • High — Duplicated code blocks (467 repeated 6-line blocks across 94 files).
  • High — Oversized files (16): internal/app/app.go has 1,596 lines.
  • Medium — Empty catch blocks in web/static/js/c2.js, chat.js, dashboard.js.

No CI/CD pipeline exists—every change merges without a build gate. Dependency updates are manual; no Dependabot or Renovate config. The repo has a license and lockfile, and no committed secrets.

The Bottom Line

This is a substantial, working platform with real orchestration capability—the MCP integration and C2 framework are genuinely useful. The lack of CI and heavy code duplication make it risky to maintain, but for a security team wanting AI-driven testing with a web UI, it's a solid foundation. Forked from a 5,900-star project, it has real-world mileage behind it.