╔══════════════════════════════════════════════════════════════════════════════╗
║                                                                              ║
║   ████████╗███████╗██╗     ███████╗███╗   ███╗ █████╗ ███╗   ██╗██████╗ ║
║   ╚══██╔══╝██╔════╝██║     ██╔════╝████╗ ████║██╔══██╗████╗  ██║██╔══██╗║
║      ██║   █████╗  ██║     █████╗  ██╔████╔██║███████║██╔██╗ ██║██║  ██║║
║      ██║   ██╔══╝  ██║     ██╔══╝  ██║╚██╔╝██║██╔══██║██║╚██╗██║██║  ██║║
║      ██║   ███████╗███████╗███████╗██║ ╚═╝ ██║██║  ██║██║ ╚████║██████╔╝║
║      ╚═╝   ╚══════╝╚══════╝╚══════╝╚═╝     ╚═╝╚═╝  ╚═╝╚═╝  ╚═══╝╚═════╝ ║
║                                                                              ║
║         Continuous Compliance Engine for Modern Infrastructure               ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝

"Compliance shouldn't feel like fighting a forest fire every quarter. It should be a quiet, continuous conversation between your infrastructure and your auditor."

• Why I Built This
• The Problem It Solves
• How It Works
• Architecture
• Features
• Control Coverage
• Tech Specs
• Security First
• Live Dashboard
• Quick Start
• CLI Reference
• Evidence Pipeline
• Alert Payload
• Roadmap
• What This Looks Like at Scale

I built trust-ledger because I got tired—really tired—of watching smart GRC teams burn cycles manually screenshotting AWS consoles every quarter.

You know the scene: three weeks before the audit, someone exports 47 CloudTrail logs, another person manually checks 200 IAM users for MFA, and someone else SSHs into production boxes to verify encryption at rest. Then everyone crowds into a Google Doc and tries to remember what "CC6.1" actually means.

I've worked with compliance teams at companies that treat security as an afterthought, and I've worked with teams that treat it as religion. Neither approach works well with quarterly audits. The first one fails audits. The second one spends so much time proving they're secure that they stop actually being secure.

The insight is simple: compliance is a continuous process, not a periodic event. If you can automatically collect evidence from your infrastructure every day, map it to every framework your auditor cares about simultaneously, and alert immediately when something drifts—you don't need to scramble. You just need to look at a dashboard.

That's what trust-ledger does. It's not a governance platform. It's not a risk register. It's the thing that lives in your infrastructure and quietly makes sure you're always ready for an audit—without you having to think about it.

The ROI isn't just time. It's confidence. When your evidence is collected automatically, your auditors trust it more. When your controls are mapped to every framework at once, you stop playing mapping games. When drift is detected in real-time, you fix problems before they become audit findings.

Think of trust-ledger like a security guard making rounds in a building:

1. Collect — Every hour (or on demand), trust-ledger walks through your AWS infrastructure with read-only API calls. It checks every door (IAM users), every camera (CloudTrail), every safe (S3 buckets), and every database (RDS). It doesn't touch anything—it just observes.

2. Record — Each observation becomes a timestamped evidence record in newline-delimited JSON. These live in your evidence/ directory, organized by date. Think of this as your security camera's DVR—immutable, searchable, forever.

3. Compare — When trust-ledger runs, it compares today's evidence against yesterday's. If an S3 bucket suddenly loses encryption, or an IAM user appears without MFA, that's a drift event. The system notices immediately.

4. Alert — When drift is detected, trust-ledger fires a structured webhook to Slack, PagerDuty, a SIEM, or any HTTP endpoint you configure. The payload includes what broke, when, and what to do about it.

5. Report — Need to show an auditor? Run trust-ledger report and get beautiful HTML, JSON, and CSV reports that map every finding to SOC 2, ISO 27001, and NIST 800-53 simultaneously.

The magic is in step 5—that's where the YAML mapping config lives. One collector checks one thing, but the mapper decides which controls it satisfies across every framework. Change the mapping, and your reports update instantly.

flowchart TB
    subgraph CLI["CLI (cobra)"]
        run["run"]
        serve["serve"]
        report["report"]
        diff["diff"]
    end
    
    subgraph Engine["Collector Engine"]
        CE[Collector Interface]
        RDS[RDS Collector]
        S3[S3 Collector]
        IAM[IAM Collector]
        CloudTrail[CloudTrail Collector]
    end
    
    subgraph AWS["AWS APIs"]
        IAMAPI[IAM API]
        S3API[S3 API]
        RDSAPI[RDS API]
        CTAPI[CloudTrail API]
    end
    
    subgraph Mapper["Framework Mapper"]
        YAML[mappings.yaml]
        Map[Control Mapper]
    end
    
    subgraph Pipeline["Evidence Pipeline"]
        Writer[Evidence Writer]
        Evidence[evidence/ directory]
        API[REST API]
    end
    
    subgraph Alert["Webhook Notifier"]
        Webhook[HTTP Webhook]
        Slack[Slack]
        PD[PagerDuty]
    end
    
    CLI --> Engine
    Engine --> CE
    CE --> RDS
    CE --> S3
    CE --> IAM
    CE --> CloudTrail
    
    RDS --> RDSAPI
    S3 --> S3API
    IAM --> IAMAPI
    CloudTrail --> CTAPI
    
    AWS --> Mapper
    Mapper --> YAML
    
    Engine --> Pipeline
    Writer --> Evidence
    Evidence --> API
    
    Engine --> Alert
    Webhook --> Slack
    Webhook --> PD

Four purpose-built collectors continuously scan your AWS environment:

• CloudTrail Multi-Region: Verifies logging is enabled across all regions
• IAM MFA Enforcement: Confirms every console user has MFA enabled
• S3 Encryption at Rest: Checks every bucket for server-side encryption
• RDS Encryption: Validates encryption at rest for every database instance

Each collector runs in seconds and produces machine-readable evidence.

The YAML configuration maps each collector to multiple control frameworks simultaneously:

mappings:
  - collector: aws.iam.mfa_enforcement
    controls:
      - soc2: CC6.1
      - iso27001: A.9.2.3
      - nist: IA-2(1)

Change one line in the config, and your reports reflect the new mapping. No code changes needed.

Every run compares current state against the previous run. Drift events trigger webhooks instantly:

• S3 bucket encryption turned off
• IAM user created without MFA
• CloudTrail disabled in a region
• RDS encryption at rest removed

The built-in HTTP server serves a real-time control health dashboard:

trust-ledger serve --port 8080

Open http://localhost:8080 and see every control's current status. Refresh-free updates via the API.

The diff command shows exactly what changed between two runs:

trust-ledger diff --from 2024-01-01 --to 2024-01-15

Perfect for root cause analysis and audit explanations.

Generate reports on demand:

• HTML: Beautiful, dark-themed dashboard for auditors
• JSON: Machine-readable for automation
• CSV: Spreadsheet-compatible for analysis

=== Running AWS Evidence Collection ===

✓ aws.cloudtrail.multiregion ............ PASS
✓ aws.iam.mfa_enforcement ................ PASS  
✓ aws.s3.encryption_at_rest .............. FAIL
  → Enable default encryption for 1 S3 buckets
✗ aws.rds_encryption ..................... FAIL
  → Enable storage encryption for 1 RDS instances

Compliance Score: 2/4 (50%)

Drift detected! 2 controls failed.
Webhook fired to: https://hooks.slack.com/services/xxx

trust-ledger/
├── main.go                    # Entry point, just calls cmd.Execute()
├── cmd/
│   ├── root.go               # Root cobra command
│   ├── run.go                # `run` - collect evidence
│   ├── serve.go              # `serve` - start dashboard
│   ├── report.go             # `report` - generate reports
│   └── diff.go               # `diff` - historical comparison
├── collector/
│   ├── collector.go          # Collector interface + registry
│   ├── mock_collectors.go     # Test collectors with sample data
│   ├── aws_init.go           # AWS client initialization
│   ├── aws_rds.go            # RDS encryption collector
│   ├── aws_s3.go             # S3 encryption collector
│   ├── aws_iam.go            # IAM MFA collector
│   └── aws_cloudtrail.go     # CloudTrail collector
├── mapper/
│   ├── mapper.go             # Framework mapping logic
│   ├── framework_mapper.go    # Control ID resolution
│   └── mappings.yaml         # Control definitions
├── evidence/
│   ├── writer.go             # JSONL evidence writer
│   └── .gitkeep              # Directory marker
├── alert/
│   ├── drift.go              # Drift detection logic
│   └── webhook.go             # Webhook firing
├── server/
│   ├── server.go             # HTTP server setup
│   ├── handlers.go           # API handlers
│   └── templates/
│       └── dashboard.html    # Dashboard template
└── report/
    └── report.go             # Report generation (JSON/CSV/HTML)

trust-ledger is intentionally, aggressively read-only. It uses the AWS SDK to observe your infrastructure—it never creates, modifies, or deletes resources. The only writes happen to local JSON files in the evidence/ directory.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:ListUsers",
        "iam:GetLoginProfile",
        "iam:ListMFADevices",
        "s3:ListBuckets",
        "s3:GetBucketEncryption",
        "rds:DescribeDBInstances",
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus"
      ],
      "Resource": "*"
    }
  ]
}

This is the entire policy. No * on actions. No write permissions. No pass role. Just observation.

The dashboard runs on localhost by default. For production deployment:

• Bind to internal network only: trust-ledger serve --host 127.0.0.1
• Put behind your existing auth proxy (nginx, OAuth2, etc.)
• The /controls endpoint returns only control status—no sensitive data

Only three production dependencies:

1. github.com/aws/aws-sdk-go-v2 — AWS API access, maintained by Amazon
2. github.com/spf13/cobra — CLI framework, community standard
3. gopkg.in/yaml.v3 — YAML parsing, no runtime dependencies

Everything else is stdlib. No hidden dependencies. No mysterious middleware.

╔══════════════════════════════════════════════════════════════════════════════╗
║                         🔐 Trust Ledger Control Dashboard                    ║
╠══════════════════════════════════════════════════════════════════════════════╣
║                                                                              ║
║  Compliance Score  ████████████████░░░░░░░░░░░░  50%                          ║
║                                                                              ║
╠══════════════════════════════════════════════════════════════════════════════╣
║  CONTROLS                                STATUS       LAST CHECKED          ║
╠══════════════════════════════════════════════════════════════════════════════╣
║  ☑ CloudTrail Multi-Region                      ✓ PASS      2024-01-15 14:32    ║
║  ☑ IAM MFA Enforcement                         ✓ PASS      2024-01-15 14:32    ║
║  ☑ S3 Encryption at Rest                        ✗ FAIL      2024-01-15 14:32    ║
║      → bucket-audit-logs missing encryption                                   ║
║  ☑ RDS Encryption                               ✗ FAIL      2024-01-15 14:32    ║
║      → db-prod-01 missing encryption                                         ║
╠══════════════════════════════════════════════════════════════════════════════╣
║  Last Evidence Collection: 2 minutes ago                                    ║
║  Next Scheduled Run: 58 minutes                                             ║
╚══════════════════════════════════════════════════════════════════════════════╝

{
  "generated_at": "2024-01-15T14:32:00Z",
  "compliance_rate": 50,
  "total_controls": 4,
  "passed": 2,
  "failed": 2,
  "controls": [
    {
      "id": "aws.cloudtrail.multiregion",
      "name": "CloudTrail Multi-Region",
      "status": "PASS",
      "last_checked": "2024-01-15T14:32:00Z",
      "remediation_hint": null,
      "frameworks": ["SOC2 CC7.2", "ISO27001 A.12.4.1", "NIST AU-2"]
    },
    {
      "id": "aws.iam.mfa_enforcement", 
      "name": "IAM MFA Enforcement",
      "status": "PASS",
      "last_checked": "2024-01-15T14:32:00Z",
      "remediation_hint": null,
      "frameworks": ["SOC2 CC6.2", "ISO27001 A.9.2.3", "NIST IA-2"]
    },
    {
      "id": "aws.s3.encryption_at_rest",
      "name": "S3 Encryption at Rest",
      "status": "FAIL",
      "last_checked": "2024-01-15T14:32:00Z",
      "remediation_hint": "Enable default encryption for bucket-audit-logs",
      "frameworks": ["SOC2 CC6.7", "ISO27001 A.10.1.1", "NIST SC-13"]
    },
    {
      "id": "aws.rds.encryption",
      "name": "RDS Encryption",
      "status": "FAIL",
      "last_checked": "2024-01-15T14:32:00Z",
      "remediation_hint": "Enable storage encryption for db-prod-01",
      "frameworks": ["SOC2 CC6.7", "ISO27001 A.10.1.1", "NIST SC-13"]
    }
  ]
}

• Go 1.22+ installed
• AWS credentials configured (env vars, ~/.aws, or EC2 role)
• Read-only IAM credentials (policy provided above)

# Clone and build
git clone https://github.com/trust-ledger/trust-ledger.git
cd trust-ledger
go build -o trust-ledger .

# Verify
./trust-ledger --help

# 1. Run evidence collection (dry-run with mock data)
./trust-ledger run --dry-run

# 2. Run with real AWS (requires credentials)
./trust-ledger run

# 3. Start the live dashboard
./trust-ledger serve --port 8080

# 4. Generate compliance reports (JSON, CSV, HTML)
./trust-ledger report --dry-run -o ./reports

# 5. Compare evidence between dates
./trust-ledger diff --from 2024-01-01 --to 2024-01-15

trust-ledger - Continuous Compliance Engine

Usage:
  trust-ledger [command]

Available Commands:
  run       Run evidence collection from AWS
  serve     Start the live control dashboard
  report    Generate compliance reports (JSON, CSV, HTML)
  diff      Compare evidence between time periods
  help      Help about any command

Flags:
  -h, --help   help for trust-ledger

Run 'trust-ledger [command] --help' for more information on a command.

Run evidence collection from AWS

Usage:
  trust-ledger run [flags]

Flags:
  -d, --dry-run   Run with mock collectors (no AWS required)

Examples:
  trust-ledger run                      # Collect from real AWS
  trust-ledger run --dry-run            # Test with mock data

Start the live control dashboard

Usage:
  trust-ledger serve [flags]

Flags:
  -p, --port int   Port to listen on (default 8080)
  -h, --host string   Host to bind to (default "localhost")

Examples:
  trust-ledger serve                    # Start on localhost:8080
  trust-ledger serve --port 9000        # Custom port

Generate compliance reports in multiple formats

Usage:
  trust-ledger report [flags]

Flags:
  -o, --output string   Output directory (default "reports")
  -d, --dry-run         Generate with mock data

Examples:
  trust-ledger report                    # Generate from AWS
  trust-ledger report --dry-run          # Test with mock data
  trust-ledger report -o ./audit-q1      # Custom output dir

Compare evidence between time periods

Usage:
  trust-ledger diff [flags]

Flags:
  -f, --from string   Start date (YYYY-MM-DD)
  -t, --to string     End date (YYYY-MM-DD)

Examples:
  trust-ledger diff --from 2024-01-01 --to 2024-01-15

evidence/
├── 2024-01-13/
│   ├── 1705147200000000000.jsonl   # 10:00 AM
│   ├── 1705150800000000000.jsonl   # 11:00 AM
│   └── ...
├── 2024-01-14/
│   ├── 1705233600000000000.jsonl   # 10:00 AM
│   ├── 1705237200000000000.jsonl   # 11:00 AM - DRIFT EVENT
│   └── ...
└── 2024-01-15/
    ├── 1705320000000000000.jsonl   # 10:00 AM
    └── ...

Drift event detected on 2024-01-14 at 11:00 AM—one of the S3 buckets lost encryption.

{
  "collector_id": "aws.s3.encryption_at_rest",
  "resource_arn": "arn:aws:s3:::bucket-audit-logs",
  "status": "FAIL",
  "collected_at": "2024-01-14T11:00:15.321Z",
  "raw_snapshot": {
    "bucket_name": "bucket-audit-logs",
    "encryption_enabled": false,
    "bucket_region": "us-east-1"
  },
  "remediation_hint": "Enable default encryption for bucket-audit-logs"
}

When drift is detected, trust-ledger fires this webhook:

{
  "event_type": "drift_detected",
  "timestamp": "2024-01-14T11:00:15.321Z",
  "collector_id": "aws.s3.encryption_at_rest",
  "control_name": "S3 Encryption at Rest",
  "status": "FAIL",
  "previous_status": "PASS",
  "resource_arn": "arn:aws:s3:::bucket-audit-logs",
  "remediation_hint": "Enable default encryption for bucket-audit-logs",
  "frameworks": [
    {"framework": "SOC2 TSC", "control_id": "CC6.7"},
    {"framework": "ISO 27001", "control_id": "A.10.1.1"},
    {"framework": "NIST 800-53", "control_id": "SC-13"}
  ],
  "run_id": "1705237215321000000"
}

This payload is compatible with:

• Slack — Post to channel via incoming webhook
• PagerDuty — Create incident from event
• Tines — Trigger automation workflow
• Jira — Create security issue

The roadmap isn't just features—it's the architecture for a complete compliance automation platform. Each phase builds on the previous one without breaking existing functionality.

I want to be direct with you about what this project represents.

This isn't a demo. This is a production architecture sketch—built the way I'd build it if I were leading the compliance engineering team at a company like 1Password.

You know 1Password recently launched their Extended Access Management (XAM) platform, and they have a public partnership with Drata for continuous compliance. That's the market trust-ledger lives in. Every company building infrastructure today needs something like this—not because they want to, but because their auditors demand it.

If I were hiring for a GRC platform team, I'd want to see:

1. An engineer who understands the problem deeply — not just "compliance is important," but why quarterly audits fail, what evidence looks like, and how mapping frameworks actually works.
2. An engineer who builds real things — not a tutorial, not a hello world, but something that actually runs, collects real data, and produces usable output.
3. An engineer who thinks about security first — read-only design, minimal IAM, no credentials on disk, immutable evidence.
4. An engineer who ships complete experiences — a dashboard, reports in multiple formats, webhooks that work with existing tools.

This project checks every box.

The architecture scales horizontally—add more collectors, map to more frameworks, run in more accounts. The evidence pipeline is append-only, which means it works with any object storage backend. The webhook system integrates with any incident management tool. The mapping is data-driven, not hard-coded, so you can adapt to new frameworks without code changes.

If you're building a compliance platform, or if you're hiring someone who can—this is the foundation I'd start with.

MIT License — Copyright 2024 Webber