Data Models & Database Schema
Relevant source files
The following files were used as context for generating this wiki page:
The Fixops platform utilizes a multi-layered data architecture to manage security findings, application inventory, and automated penetration testing results. The system combines relational database schemas for persistence with structured Python dataclasses and Pydantic models for real-time analysis, reporting, and inter-service communication. This design supports the end-to-end DevSecOps lifecycle from initial requirement gathering to runtime security monitoring.
Sources: CLI_API_INVENTORY.md:300-330, scripts/generate_analysis.py:165-180
Core Persistence Layer
The persistence layer is structured to handle high-volume security artifacts. Fixops primarily uses relational storage (SQLite/SQL) to maintain the state of the security pipeline, findings, and audit trails.
Relational Database Schema
The database schema is designed around the lifecycle of a security scan. Key tables facilitate the ingestion of various formats (SARIF, SBOM, CVE) and the storage of derived decisions.
| Table Name | Description | Key Fields |
|---|---|---|
findings | Canonical storage for normalized security vulnerabilities. | id, rule_id, severity, category, source, location |
scans | Metadata regarding scan execution and tool provenance. | id, tool_name, timestamp, service_name, environment |
components | Inventory of software libraries and frameworks (SBOM data). | id, name, version, purl, licenses |
cves | Vulnerability intelligence feed data. | id, cvss, epss_score, is_kev, published_date |
decisions | Historical record of ALLOW/BLOCK/DEFER verdicts. | id, finding_id, verdict, confidence, rationale |
audit_log | Immutable trail of system and user actions for compliance. | id, action, user_id, resource_type, timestamp |
Sources: index/TREE.txt:50-60, CLI_API_INVENTORY.md:250-280, tests/e2e/comprehensive_e2e_test.py:1000-1050
Database Entity Relationship
The following diagram illustrates the relationship between core security artifacts and the results of the analysis pipeline.
This diagram represents the flow from application registration to the generation of a security decision based on scan findings and component analysis.
Sources: CLI_API_INVENTORY.md:330-350, tests/e2e/comprehensive_e2e_test.py:100-150
Advanced Penetration Testing Models
The Advanced Pentest Engine utilizes a set of sophisticated dataclasses to model complex attack scenarios, privilege escalation, and business impact. These models are used to quantify risk in financial terms and generate executive-level reports.
Risk and Impact Quantification
The engine quantifies risk through specialized models that combine technical severity with business context.
- ThreatIntelligence: Stores enriched data from NVD, CISA KEV, and EPSS feeds.
- BusinessImpactAssessment: Estimates financial risk based on records affected, downtime costs, and regulatory fine risks.
- CVSSv31Vector: A structured representation of CVSS components used for base score calculation.
Sources: fixops-enterprise/src/services/advanced_pentest_engine.py:125-250
Attack Modeling
Complex attack paths are represented through chained exploit and movement models.
These classes allow the engine to simulate multi-stage attacks beyond isolated vulnerabilities.
Sources: fixops-enterprise/src/services/advanced_pentest_engine.py:255-320
Pipeline and Stage Data Structures
Fixops organizes its data processing into discrete stages. Each stage produces a canonical JSON output stored in the RunRegistry.
Stage Output Manifests
The pipeline produces specific artifacts for each stage of the SSDLC:
| Stage | Output File | Description |
|---|---|---|
| Requirements | requirements.json | Policy and compliance goals. |
| Design | design.manifest.json | Threat models and architecture context. |
| Build | build.report.json | SBOM and component analysis. |
| Test | test.report.json | SARIF findings from SAST/DAST. |
| Deploy | deploy.manifest.json | IaC and deployment posture. |
| Operate | operate.snapshot.json | Runtime signals and KEV/EPSS status. |
| Decision | decision.json | The final automated verdict. |
Sources: CLI_API_INVENTORY.md:305-325
Asset and Application Inventory
The system maintains a comprehensive inventory of applications and customers, used to provide business context to technical findings.
Application Metadata
Applications are defined by their technical stack, criticality, and compliance requirements.
APPLICATIONS = {
"payment-gateway": {
"lang": "java",
"framework": "Spring Boot 3.2",
"runtime": "Kubernetes",
"cloud": "AWS EKS",
"criticality": "critical",
"data_classification": "PCI",
"internet_facing": True,
}
}
Sources: tests/e2e/comprehensive_e2e_test.py:105-120
Customer and Compliance Context
Inventory models include organizational structures like teams and compliance frameworks (PCI-DSS, SOC2, HIPAA).
| Entity | Attributes |
|---|---|
| Customer | Name, Cloud Provider, Region, Industry, Portfolio. |
| Team | Name, Description, Members, Roles (Admin, Analyst, Viewer). |
| Policy | Rules, Policy Type (Guardrail, Compliance), Action (Block, Alert). |
Sources: tests/e2e/comprehensive_e2e_test.py:75-100, CLI_API_INVENTORY.md:100-130
Conclusion
The Fixops data model is designed for end-to-end traceability, connecting raw scanner outputs to high-level business risk assessments. By utilizing a mix of relational tables for long-term audit storage and structured dataclasses for complex security logic, the platform ensures both performance and depth of analysis. The modular nature of these schemas allows for the integration of emerging threat intelligence feeds and automated testing tools like PentAGI.
Sources: scripts/generate_analysis.py:15-30, CLI_API_INVENTORY.md:330-345