Evidence Lake & Provenance
Relevant source files
The following files were used as context for generating this wiki page:
The Evidence Lake & Provenance system within FixOps serves as a centralized, immutable repository for all security decision artifacts, scan results, and verification trails. Its primary purpose is to provide a "Decision & Verification" foundation that enriches scanner outputs with business context and threat intelligence to reach a consensus decision, which is then persisted for audit, forensics, and reproducibility.
This system ensures that every security verdict (ALLOW, BLOCK, or DEFER) is backed by a cryptographically signed evidence bundle. These bundles include the full multi-LLM reasoning trail, MITRE ATT&CK mapping, and SLSA-compliant provenance data, enabling enterprise-grade audit trails and zero-trust architecture readiness.
Sources: frontend/src/pages/EnhancedDashboard.jsx:183-191, samples/api-examples/demo-scenarios/evidence/evidence-bundles.json:1-10
Architecture and Data Flow
The architecture follows a pipeline model where ingestion leads to normalization, followed by enrichment, analysis, and finally, the persistence of the entire state into the Evidence Lake.
The flow ensures that by the time a decision is made, all supporting data is collected and packaged. The Evidence Lake stores consensus details and LLM reasoning snippets with traceable evidence IDs.
Sources: frontend/src/pages/EnhancedDashboard.jsx:183-194, scripts/demo_orchestrator.py:10-25
Evidence Lake Structure
The Evidence Lake is identified by a unique ID and associated with a specific organization. It implements automated retention policies tailored to various compliance frameworks.
Retention Policies
| Framework | Retention Period (Years) |
|---|---|
| PCI DSS | 7 |
| SOX | 7 |
| HIPAA | 6 |
| GDPR | 5 |
| Default | 7 |
Integrity Verification
To prevent tampering, the lake employs SHA-256 hashing and Merkle Tree structures. The verification status is tracked globally across the lake to ensure the validity of all stored bundles.
Sources: samples/api-examples/demo-scenarios/evidence/evidence-bundles.json:2-19
Evidence Bundles
Evidence bundles are the discrete units of storage within the lake. Each bundle represents a specific security event, such as a vulnerability assessment or a remediation verification.
Bundle Components
- Signatures: RSA-4096 signatures ensure the authenticity of the bundle, including a full certificate chain (Signing Cert -> Intermediate CA -> Root CA).
- Integrity Hashes: Content hashes, manifest hashes, and Merkle roots are stored per bundle.
- Contents:
scan_results: SAST, DAST, SCA, Container, and Cloud scans.analysis_results: Reachability analysis, risk graphs, and correlation reports.decision_records: Multi-LLM consensus, policy evaluations, and risk scores.compliance_artifacts: Framework-specific assessments (SOC2, HIPAA, etc.).
Sources: samples/api-examples/demo-scenarios/evidence/evidence-bundles.json:23-85, web/apps/findings/app/page.tsx:300-325
Provenance and Attestation
FixOps implements SLSA (Supply-chain Levels for Software Artifacts) v1.0 and in-toto statements to provide comprehensive provenance for security decisions.
Attestation Logic
The system generates in-toto statements that link subjects (e.g., a specific application or microservice) to predicates (e.g., a vulnerability scan attestation).
SLSA Metadata
The provenance data includes:
- Build Type:
https://fixops.io/provenance/v1 - Invocation: Config source URI, entry point (e.g.,
fixops-pipeline.yml), and parameters. - Materials: Cryptographic digests (SHA-256) of all source materials used in the decision process.
Sources: scripts/demo_orchestrator.py:410-455, samples/api-examples/demo-scenarios/evidence/evidence-bundles.json:98-160
Remediation Verification
A critical feature of the Evidence Lake is the remediation_verification bundle type. This captures the transition of a vulnerability from an "Open" to "Resolved" state.
| Field | Description |
|---|---|
before_state | Vulnerability details, component version, and initial scan date. |
remediation_action | Action type (e.g., upgrade), target version, actor, and Jira ticket ID. |
after_state | Rescan date and resolution status. |
verification_scan | Tool used (e.g., Snyk) and the verification result. |
Sources: samples/api-examples/demo-scenarios/evidence/evidence-bundles.json:170-210
Implementation Details
Evidence Store Interaction
The system provides a CLI and API surface for retrieving evidence bundles. The get-evidence command allows users to extract bundles from pipeline results for external auditing.
# Example CLI usage to retrieve evidence
python -m core.cli get-evidence --result path/to/result.json --destination ./audit_logs
Attestation Generation Snippet
The following logic illustrates how the EvidenceAttestor constructs the SLSA provenance:
# scripts/demo_orchestrator.py:410-435
def generate_attestation(self, run_id, findings, run_trace):
provenance = {
"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": "https://slsa.dev/provenance/v1.0",
"subject": [{"name": f"fixops-run-{run_id}", "digest": {"sha256": hash}}],
"predicate": {
"buildDefinition": {
"buildType": "https://fixops.io/BuildType/v1",
"externalParameters": {"scanners": scanners, "total_findings": len(findings)}
},
"runDetails": {"builder": {"id": "https://fixops.io/demo-orchestrator/v1"}}
}
}
return {"provenance": provenance, "signature": self._sign_payload(json.dumps(provenance))}
Sources: CLI_API_INVENTORY.md:45-52, scripts/demo_orchestrator.py:410-450
Summary
The Evidence Lake & Provenance system is the immutable ledger of the FixOps platform. By combining high-entropy cryptographic signatures, SLSA-compliant provenance, and detailed multi-LLM reasoning trails, it transforms ephemeral security scans into permanent, verifiable records. This architecture supports complex regulatory requirements and provides the transparency necessary for modern DevSecOps governance.