Skip to main content

​
Architecture Overview

The Evidence API is built on a modern, scalable architecture that processes compliance evidence from multiple sources and generates comprehensive security assessments aligned with NIST frameworks.

​
Core Components

The system consists of several key layers:
  • API Gateway: Axum-based REST API with CORS, authentication, and routing
  • Authentication Layer: Customer key-based authentication via PostgreSQL
  • Evidence Sources: Multi-format ingestion (Terraform, Azure, Firmware, FIPS)
  • Evidence Lake: DuckDB in-memory analytical database with normalized schema
  • Compliance Assessors: NIST framework evaluation engines
  • Output Formats: OSCAL, JSON, YAML, and Mermaid diagram generation

​
Data Flow

Evidence flows through the system in the following stages:
  1. Client submits evidence via HTTPS POST with base64-encoded payload
  2. API Gateway validates authentication via X-Customer-Key header
  3. Appropriate Evidence Source parses the input format
  4. Source Adapter normalizes data to the Evidence Lake schema
  5. DuckDB stores evidence in structured tables (system_metadata, asset_inventory, sboms, configs_posture)
  6. Compliance Assessors query the lake and map findings to NIST controls
  7. Output Formatters generate the requested response format
  8. Client receives assessment results with artifacts

​
Architecture Diagram

​
Component Details

​
API Gateway (Axum)

The Axum-based API gateway serves on port 8080 and handles:
  • HTTPS request routing
  • CORS configuration for web clients
  • Authentication middleware integration
  • Request/response transformation

​
Authentication

Authentication uses a custom X-Customer-Key header validated against PostgreSQL:
  • Customer accounts stored in PostgreSQL
  • API keys associated with customer records
  • Middleware validates keys before processing requests

​
Evidence Sources

The system supports multiple evidence input formats:
  • TerraformSource: Parses Terraform state files to extract infrastructure configuration
  • AzureSource: Integrates with Azure Graph API using Workload Identity Federation
  • FirmwareSource: Analyzes firmware binaries for security characteristics
  • FIPS ZIP Source: Processes multi-evidence FIPS compliance packages

​
Evidence Lake (DuckDB)

DuckDB provides an in-memory analytical database with normalized schema:
  • system_metadata: Operating system details, FIPS mode status, cryptographic modules
  • asset_inventory: Compute instances, storage resources, network configurations
  • sboms: Software bill of materials with components and libraries
  • configs_posture: Security policies and cryptographic configuration

​
Compliance Assessors

Six specialized assessors map evidence to NIST frameworks:
  • NIST 800-53: Security and privacy controls for information systems
  • NIST 800-171: Protecting Controlled Unclassified Information (CUI)
  • NIST 800-172: Enhanced security requirements for CUI
  • NIST 800-193: Platform Firmware Resiliency guidelines
  • FIPS 140-2/3: Cryptographic module validation
  • NIST CSF 2.0: Cybersecurity Framework core functions

​
Output Formats

Assessment results are available in multiple formats:
  • OSCAL JSON: Open Security Controls Assessment Language for FedRAMP and GRC tools
  • JSON Assessment: Native structured format for programmatic consumption
  • YAML Assessment: Human-readable format for review and documentation
  • Mermaid Diagrams: Control flow and architecture visualizations

​
Technology Stack

  • Web Framework: Axum (Rust)
  • Application Database: PostgreSQL
  • Analytics Engine: DuckDB (in-memory)
  • Authentication: Custom header-based with PostgreSQL backend
  • Cloud Integration: Azure Graph API with Workload Identity Federation