Policy as Data: A declarative language for endpoint compliance validation
Endpoint State Policy (ESP) is a platform-agnostic policy language that separates security intent from execution logic. Policies are written as structured data, not imperative scripts, making them inspectable, testable, and portable across different scanner implementations.
┌─────────────────────────────────────────────────────────────┐
│ ESP Policy Files │
│ (Security Intent as Data) │
└────────────────────────────┬────────────────────────────────┘
│
┌──────────────┴──────────────┐
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ Compiler │ │ Execution Engine │
│ │ │ │
│ • Syntax validation │ │ • Resolution engine │
│ • Type checking │ │ • Execution engine │
│ • Reference resolution│ │ • Strategy framework │
│ • Fail-fast design │ │ • Evidence generation│
└──────────────────────┘ └──────────────────────┘
│ │
└──────────────┬───────────────┘
▼
┌─────────────────────────────────────────────────────────────┐
│ Compliance Results │
│ (Repeatable, Auditable Evidence) │
└─────────────────────────────────────────────────────────────┘
Traditional compliance automation (SCAP/XCCDF) suffers from:
- Verbose, fragile XML — Policies are difficult to read, write, and maintain
- Tight coupling — Policy definition is intertwined with scanner implementation
- Poor extensibility — Adding new check types requires modifying the standard
- High cost — Authoring and maintaining policies requires specialized expertise
ESP addresses these problems by:
- Separating policy from execution — Policies describe what should be true, scanners decide how to check it
- Using a typed, validated DSL — Catch errors at compile time, not during scans
- Enforcing contracts — CTN types define clear interfaces between policies and implementations
- Human and machine readable — Policies are inspectable by auditors and parseable by tools
ESP focuses on technical controls — controls validated by inspecting endpoint state.
ESP policies describe what should be true, not how to check it. This separation enables:
- Policy authors to focus on security intent without implementation details
- Scanner implementers to optimize execution for their platform
- Auditors to inspect policies without reading code
- Organizations to share policies across different scanner implementations
The compiler enforces strict validation at compile time through a 7-pass pipeline:
- File processing with UTF-8 and size validation
- Lexical analysis with token limits
- Syntax validation and AST construction
- Symbol discovery and table building
- Reference resolution and cycle detection
- Semantic analysis and type checking
- Structural validation and limit enforcement
Errors are caught before execution, not during a scan. Security limits are baked into the binary at compile time (SSDF compliant).
The runtime engine operates within strict boundaries:
- Whitelisted command execution — Only approved commands can run
- Deterministic evaluation order — Same policy produces same results
- Repeatable evidence generation — Collection methods are documented
- No code injection — Policies cannot execute arbitrary code
ESP enforces trust boundaries at every stage:
┌─────────────────────────────────────────────────────────────────────┐
│ UNTRUSTED INPUT TRUST GATE TRUSTED OUTPUT │
│ │
│ ┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ .esp files │────▶│ Compiler │────▶│ Validated AST │ │
│ │ (untrusted) │ │ (7-pass check) │ │ (trusted) │ │
│ └─────────────┘ └─────────────────┘ └────────┬────────┘ │
│ │ │
│ ┌────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ Constrained Execution │ │
│ │ • Contract-bound collectors │ │
│ │ • Whitelisted commands │ │
│ │ • Deterministic evaluation │ │
│ └──────────────────┬──────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ Controlled Disclosure │ │
│ │ • Attestations (network-safe) │ │
│ │ • Full results (local-only) │ │
│ │ • Audit logging (mandatory) │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
| Boundary | Threat Mitigated |
|---|---|
| Policy Input | Malformed/malicious policies |
| Compiler Gate | Unsafe policies reaching execution |
| Execution | Uncontrolled system access |
| Capabilities | Privilege escalation |
| Results | Information leakage |
📄 See ESP Trust Model for complete details.
- Rust 1.85+ (rustup.rs)
- Linux/macOS: OpenSSL development libraries (
libssl-devon Ubuntu,opensslon macOS) - Windows: No additional dependencies (uses native CNG)
This repository includes a VS Code Dev Container for fast setup:
- Install Docker Desktop and VS Code
- Install the Dev Containers extension
- Clone and open in VS Code:
git clone https://github.com/CurtisSlone/Endpoint-State-Policy.git code Endpoint-State-Policy
- Click "Reopen in Container" when prompted
# Build all crates
cargo build --workspace
# Run tests
make test
# Run linting
make lint# Compile a single file
cargo run -p compiler -- policy.esp
# Compile a directory
cargo run -p compiler -- policies/| Crate | Purpose |
|---|---|
| common | Shared types: AST, logging, configuration, results, FIPS 140-3 cryptography |
| compiler | Parse and validate ESP files through 7-pass pipeline |
| execution_engine | Resolution engine, execution framework, strategy system |
policy.esp
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Compiler │
│ File → Tokens → AST → Symbols → References → Semantics │
└────────────────────────────┬────────────────────────────────┘
│ Validated AST
▼
┌─────────────────────────────────────────────────────────────┐
│ Execution Engine │
│ Conversion → Resolution → Execution → Results │
└────────────────────────────┬────────────────────────────────┘
│
▼
Compliance Results
The compiler transforms ESP source through seven distinct passes:
| Pass | Module | Purpose |
|---|---|---|
| 1 | file_processor |
UTF-8 validation, size limits, encoding |
| 2 | lexical |
Token stream generation |
| 3 | syntax |
Grammar validation, AST construction |
| 4 | symbols |
Symbol table building |
| 5 | reference_resolution |
Cross-reference validation, cycle detection |
| 6 | semantic_analysis |
Type checking, runtime operation validation |
| 7 | validation |
Structural requirements, implementation limits |
The execution engine consumes validated AST and produces compliance results:
| Phase | Purpose |
|---|---|
| Conversion | Transform AST to execution types |
| Resolution | Variable substitution, SET expansion, dependency ordering |
| Execution | Data collection, state validation, evidence generation |
ESP can express technical controls from any framework with observable requirements:
| Framework | Example Use |
|---|---|
| NIST SP 800-53 / 800-171 | Configuration management controls |
| MITRE ATT&CK | Detection-oriented validation |
| DISA STIGs | Security configuration baselines |
| CIS Benchmarks | Hardening verification |
| Custom baselines | Organization-specific requirements |
ESP answers: "Is this endpoint in the required technical state?"
For building scanners that execute ESP policies, see the ESP Agent SDK:
🔗 github.com/scanset/ESP-Agent-SDK
The SDK provides:
- Reference CTN type implementations (file_metadata, file_content, tcp_listener, etc.)
- Collector and executor patterns
- Example agent application
- Contract development guide
ScanSet is building the Compliance Evidence Layer — infrastructure that produces cryptographically verifiable proof of compliance, continuously. We're seeking design partners to shape the orchestration and integration layers.
ESP is the policy engine. ScanSet is the infrastructure that operationalizes it:
┌─────────────────────────────────────────────────────────────────────┐
│ ScanSet Evidence Layer │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Policy │ │ Orchestration │ │ Trust │ │
│ │ (ESP Core) │────▶│ Layer │────▶│ Infrastructure │ │
│ │ │ │ │ │ │ │
│ │ • Compiler │ │ • Agent mgmt │ │ • Signing │ │
│ │ • Engine │ │ • Policy routing│ │ • Attestations │ │
│ │ • Contracts │ │ • Evidence flow │ │ • Verification │ │
│ └─────────────┘ └─────────────────┘ └─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Connectors │ │
│ │ │ │
│ │ • SIEM / SOAR │ │
│ │ • GRC Platforms │ │
│ │ • Threat Models │ │
│ │ • AI Agents │ │
│ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
- Early access to orchestration and trust infrastructure
- Custom connector development for your SIEM/SOAR (Splunk, Sentinel, ServiceNow, etc.)
- Direct input on API design and integration patterns
- Priority support during implementation
| Profile | Why You'd Be a Great Fit |
|---|---|
| Federal Contractors | FedRAMP/FISMA continuous monitoring, 3PAO evidence packages |
| Regulated SaaS | SOC 2 evidence automation, customer audit responses |
| Cloud-Native Teams | GitOps integration, CI/CD compliance gates |
| MSPs / MSSPs | Multi-tenant evidence collection, client reporting |
Compliance outcomes should be provable, not explained:
- Attestations flow to your SIEM — failed controls become security events
- SOAR playbooks trigger automatically — remediation closes the loop with signed proof
- Threat models update in real-time — attack paths light up when controls fail
- 3PAO audits become queries — not quarterly fire drills
📧 Contact: curtis@scanset.io
🌐 Learn more: scanset.io
We're not looking for customers yet — we're looking for partners who want to shape how compliance evidence infrastructure gets built.
| Command | Description |
|---|---|
make build |
Build all crates |
make test |
Run all tests |
make test-unit |
Run unit tests only |
make lint |
Run strict clippy checks |
make format |
Format code |
make docs |
Generate documentation |
make pre-commit |
Run all checks before commit |
| Document | Description |
|---|---|
| ESP Overview | Language introduction and concepts |
| Lexical Rules | Token definitions and lexical structure |
| Grammar EBNF | Formal grammar specification |
| Type System | Data types and type compatibility |
| Symbol Resolution | Symbol tables and reference resolution |
| Evaluation Semantics | Runtime evaluation rules |
| Meta Requirements | Structural requirements |
| Error Model | Error codes and handling |
| Canonical Schema | Output format specification |
| Trust Model | Security boundaries and trust |
| Configuration | Build and runtime configuration |
| Logging | Logging system specification |
| Crate | README |
|---|---|
| common | common/README.md |
| compiler | compiler/README.md |
| execution_engine | execution_engine/README.md |
| Platform | Cryptography | Status |
|---|---|---|
| Linux | OpenSSL FIPS | ✅ Full support |
| macOS | OpenSSL | ✅ Full support (requires Homebrew OpenSSL) |
| Windows | CNG (BCrypt) | ✅ Full support (native, no dependencies) |
Cross-compilation from Linux to Windows is supported without bundling OpenSSL.
- No code execution — Policies are data, not scripts
- Whitelisted commands — Only approved commands can execute
- FIPS 140-3 cryptography — Platform-native certified implementations
- Compile-time limits — Security boundaries baked into binary
- Mandatory audit logging — Security events always logged
For security vulnerabilities, contact curtis@scanset.io.
Apache 2.0 — See LICENSE for details.
ESP — Making endpoint compliance declarative, testable, and auditable.