Compliance scores computed live, not hardcoded.
/api/compliance/status checks 15 NIST controls and 14 IEC controls against actual environment variables, log entries, and configuration. Scores move the moment mTLS is enabled or the authority token is set.
15 controls assessed
Chapters 4–7: Asset Management, Network Security, Anomaly Detection, Audit & Incident Response. Each maps to a real SILDA mechanism, segmentation, the SHA-256 chain, the device registry, virtual patching.
14 controls, FR1–FR7
All seven Foundational Requirements individually tracked: Identification & Authentication, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response, Resource Availability.
31 techniques in library
Base coverage against 109 total ICS techniques, plus a live count of techniques actually observed in your anomalies.jsonl, not a theoretical maximum.
The gap analysis we show ourselves.
A compliance page that only shows green checks doesn't survive due diligence. Here's what's roadmap, not shipped.
| Priority | Gap | Maps to |
|---|---|---|
| High | mTLS client certificates | IEC 62443 SL-3, add ca_cert_pool to config.yaml |
| High | HA failover | NERC CIP-009, deploy a second SILDA node |
| Medium | Native OT protocol deep inspection (Modbus/S7/DNP3 frame parsing) | Currently covered at the network layer by the Go proxy's WAF and virtual patching engine |
| Medium | Encrypted-at-rest log storage | IEC 62443 DC-4 |
| Low | Post-quantum cryptography | NIST PQC, requires Go 1.24+ |
| Low | Hardware TPM attestation for the Ed25519 key | Roadmap |
Every entry is linked to the one before it.
Each record in anomalies.jsonl carries entry_hash (SHA-256 of the event) and prev_entry_hash (SHA-256 of the previous entry). Tampering with any single record breaks the chain and is immediately detectable, no separate integrity database required.
When cryptography>=41.0.0 is installed, every entry also carries an Ed25519 signature and public key, generated on first run and never transmitted anywhere.
The dashboard protects itself the same way it protects your network.
Locked out after repeated failures
8 wrong passwords locks that client out for 5 minutes, a basic but real defence against credential brute-forcing, applied to SILDA's own login, not just the assets it protects.
Session-based, not indefinite
A successful sign-in issues a 12-hour cookie session. Nothing stays authenticated forever by default.
Two modes, same control
Local deployments use HTTP Basic Auth on the dashboard route. Cloud deployments enforce a full sign-in page on every route, not just the dashboard entry point.
Security assurance commitments.
- •Does not phone home, no telemetry, no license server, no update checks
- •Does not write outside its own directory, persistent_logs/ only
- •Opens no ports beyond 8080 (proxy), 5000 (dashboard internal), 443/8443 (HTTPS via Caddy)
- •No internet access except the optional CISA TAXII feed, on by choice
- •Agentic investigation runs fully on-prem, no incident data reaches an external LLM API
- •Package integrity verified via published SHA-256 manifest before you ever run it
Where to look when you need more than a page.
Responsible disclosure
Found a security issue in SILDA itself? We want to hear about it before anyone else does. Reach the security team through the contact form and mark it "Security disclosure", we acknowledge within one business day.
Source access for review
Technical due diligence gets direct access to the source, not just a summary. The whole point of a cryptographic forensic chain is that it's meant to be checked, not taken on faith.
Data handling
SILDA does not phone home and does not transmit operational data anywhere by default. Anything that leaves a site, federation statistics, an optional CISA feed lookup, is opt-in and documented above.