What Data Is Stored in the CyberStrikeAI SQLite Database Schema

CyberStrikeAI persists conversations, tool executions, attack-chain graphs, vulnerabilities, and knowledge-base embeddings across 20+ relational tables defined in internal/database/database.go.

CyberStrikeAI is an open-source AI-driven penetration testing framework that uses SQLite as its primary persistence layer. All runtime data—from chat messages to vulnerability discoveries—is stored in a single SQLite file (or a secondary file for the knowledge base), with schema definitions located in internal/database/database.go.

Core Conversation and Message Data

The foundation of the CyberStrikeAI SQLite database is the conversation layer, which captures all interactions between the user and the AI.

Conversations Table

The conversations table stores metadata for each chat session. Key columns include id, title, created_at, updated_at, last_react_input, last_react_output, and pinned. This table is defined at lines 45-53 and 59-71 in internal/database/database.go.

Messages Table

Individual messages are stored in the messages table with columns for id, conversation_id, role, content, mcp_execution_ids, and created_at. This structure links every message to its parent conversation and tracks which tool executions (MCP) were triggered during that message turn (lines 55-64).

Process Details Table

For debugging and auditing, the process_details table records fine-grained events generated while processing a message, such as tool calls and AI reasoning steps. Columns include id, message_id, conversation_id, event_type, message, data, and created_at (lines 67-78).

Tool Execution and Performance Metrics

CyberStrikeAI tracks every external tool invocation and aggregates performance statistics to optimize future runs.

Tool Executions Table

The tool_executions table logs each external tool run (e.g., vulnerability scanners) with columns for id, tool_name, arguments, status, result, error, start_time, end_time, and duration_ms (lines 81-93).

Tool Statistics Table

Aggregate metrics per tool are maintained in the tool_stats table, tracking tool_name, total_calls, success_calls, failed_calls, last_call_time, and updated_at (lines 96-104).

Skill Statistics Table

Similarly, the skill_stats table records usage statistics for defined "skills" (custom AI routines), with columns mirroring the tool stats structure (lines 107-115).

Attack-Chain Graph Representation

A unique feature of the CyberStrikeAI SQLite database is its native support for storing attack-chain graphs that visualize the progression of a penetration test.

Attack Chain Nodes Table

The attack_chain_nodes table stores graph nodes representing discrete actions such as "Port Scan" or "Exploit". Columns include id, conversation_id, node_type, node_name, tool_execution_id, metadata, and risk_score (lines 118-129).

Attack Chain Edges Table

Relationships between nodes are captured in the attack_chain_edges table, which defines directed edges with id, conversation_id, source_node_id, target_node_id, edge_type, and weight (lines 132-144).

Vulnerability and Batch Task Management

The database schema supports structured vulnerability tracking and asynchronous batch processing.

Vulnerabilities Table

Discovered vulnerabilities are stored in the vulnerabilities table with comprehensive fields: id, conversation_id, title, description, severity, status, vulnerability_type, target, proof, impact, recommendation, and timestamps (lines 185-200).

Batch Task Queues and Tasks

For mass scanning operations, the batch_task_queues table manages queue metadata (id, title, status, created_at, started_at, completed_at, current_index), while the batch_tasks table stores individual tasks with id, queue_id, message, conversation_id, status, timestamps, error, and result (lines 204-227).

Knowledge Base and Retrieval Logging

CyberStrikeAI supports an optional standalone knowledge base database in addition to the main SQLite file.

Knowledge Base Items and Embeddings

When initialized via NewKnowledgeDB, the system creates knowledge_base_items (storing documents with id, category, title, file_path, content, timestamps) and knowledge_embeddings (storing vector chunks with id, item_id, chunk_index, chunk_text, embedding, created_at for similarity search) (lines 22-41).

Knowledge Retrieval Logs

Both database instances maintain a knowledge_retrieval_logs table tracking AI knowledge base queries with id, conversation_id, message_id, query, risk_type, retrieved_items, and created_at. The knowledge DB version lacks foreign-key constraints compared to the main DB version (lines 44-53 and 148-158).

Database Initialization and Schema Location

The schema is defined in internal/database/database.go and initialized through two constructors: NewDB for the main operational database and NewKnowledgeDB for the standalone knowledge base. Both functions accept a file path and a Zap logger, executing SQL DDL statements to create the tables described above if they do not exist.

import (
	"log"

	"go.uber.org/zap"
	"CyberStrikeAI/internal/database"
)

func main() {
	logger, _ := zap.NewProduction()
	db, err := database.NewDB("./data/cyberstrike.db", logger)
	if err != nil {
		log.Fatalf("DB init error: %v", err)
	}
	defer db.Close()
	// db now contains all tables listed above
}

Summary

• CyberStrikeAI uses SQLite as its primary persistence layer, storing all operational data in a single file (or a separate file for the knowledge base).
• The schema in internal/database/database.go defines 20+ tables covering conversations, messages, tool executions, attack-chain graphs, vulnerabilities, and batch tasks.
• Specialized tables track AI reasoning steps (process_details), aggregate tool performance (tool_stats, skill_stats), and knowledge retrieval patterns.
• Attack-chain visualization is supported through native graph tables (attack_chain_nodes and attack_chain_edges).
• An optional knowledge base database stores document chunks and vector embeddings for similarity search.

Frequently Asked Questions

What file path does CyberStrikeAI use for its SQLite database?

By default, the application accepts any path passed to NewDB, but the configuration typically points to ./data/cyberstrike.db for the main database and ./data/knowledge.db for the knowledge base, as shown in the initialization examples.

Does CyberStrikeAI support database migrations or schema versioning?

The source analysis shows that NewDB and NewKnowledgeDB execute raw DDL statements to create tables if they do not exist, but there is no explicit migration framework or version table shown in the current schema. Schema changes would likely require manual migration scripts.

How does CyberStrikeAI store vector embeddings for similarity search?

Vector embeddings are stored in the knowledge_embeddings table within the knowledge base database. Each row represents a chunk of a document with chunk_index, chunk_text, and an embedding column (likely serialized bytes or text) that supports similarity search operations.

Can the attack-chain graph be reconstructed from the SQLite database?

Yes, the attack_chain_nodes and attack_chain_edges tables store the complete graph structure. By querying nodes filtered by conversation_id and joining with edges on source_node_id and target_node_id, you can reconstruct the directed attack chain for any penetration testing session.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}