# What Data Is Stored in the CyberStrikeAI SQLite Database Schema

> Discover what data CyberStrikeAI stores in its SQLite database including conversations tool executions attack chains vulnerabilities and knowledge base embeddings across 20 tables.

- Repository: [公明/CyberStrikeAI](https://github.com/Ed1s0nZ/CyberStrikeAI)
- Tags: api-reference
- Published: 2026-03-09

---

**CyberStrikeAI persists conversations, tool executions, attack-chain graphs, vulnerabilities, and knowledge-base embeddings across 20+ relational tables defined in [`internal/database/database.go`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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.

```go
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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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.