Security Practices

This page describes how WitnessOps secures its own operations, where the trust boundaries still are, and what remains target-state only.

How WitnessOps Protects Its Own Operations

All execution flows through the runbook engine. There is no backdoor. No direct tool invocation. No shell escape hatch. If a tool runs, a runbook step authorized it. If no runbook step authorized it, it did not run inside the governance boundary.

Evidence is hashed at generation time. When a step produces output, WitnessOps hashes the artifact immediately. The hash goes into the manifest. Changing the artifact after the fact breaks the hash. Anyone comparing manifest hashes to artifact contents will detect the modification.

Tier 1 receipt bindings are explicit. The published WitnessOps evidence chain is M0 -> E0 -> P1 -> E2 -> R0 -> V0. R0.artifactHash covers the frozen R0 body projection. R0.tier1.executionHash covers the typed Tier 1 execution payload over M0, E0, P1, and E2. V0 recomputes both locally and checks that the embedded PV projection binds to the already-computed executionHash.

State files are append-only during execution. The execution state grows as steps complete. Steps are appended. Completed steps are not overwritten. If state is tampered with mid-execution, the append-only invariant is violated and detectable on inspection.

Security mailbox

The canonical WitnessOps security mailbox is the Microsoft 365 shared mailbox security@witnessops.com.

If Exchange Online plus addressing is enabled, security+witnessops@witnessops.com may be used as a receive-only alias for controlled Tier 1 token intake. The alias is optional and non-canonical. Governance and disclosure stay anchored to security@witnessops.com.

Key Management

WitnessOps uses Ed25519 keys for receipt signing. Current state:

Key generation. Keys are generated locally on the operator workstation using standard Ed25519 generation.

Key storage. Private keys are stored on the local filesystem. There is no HSM integration. There is no automatic rotation. The key lives where the operator puts it.

Key trust. Verification of a receipt signature requires the corresponding public key. There is no public key registry. Key distribution is manual. If you do not have the right public key, you cannot verify the receipt.

What this means. A compromised workstation means a compromised signing key. No rotation means the same key can span multiple engagements. A lost key breaks future verification against a fresh key.

See the target state below.

Responsible Disclosure

Report vulnerabilities to security@witnessops.com.

This shared mailbox is the canonical reporting address. security+witnessops@witnessops.com, when enabled, is not the canonical disclosure identity.

• Response within 72 hours.
• We will acknowledge the report, assign a severity, and provide an expected resolution timeline.
• No bounty program currently. We may establish one in the future.
• Do not disclose publicly before coordinating with us.

If you find a way to forge a receipt, bypass a gate without detection, or tamper with evidence without breaking hashes, we want to know immediately.

What WitnessOps Does NOT Protect Against

Compromised operator workstation. If the machine is owned, everything is owned. The engine, the tools, the keys, the evidence. WitnessOps assumes a trustworthy host. It cannot verify that assumption.

Malicious tool wrappers. An attacker with repo write access can replace a tool wrapper with a trojanized version. WitnessOps will invoke it, capture its output, and sign a receipt. The receipt will be valid. The output will be poisoned. WitnessOps does not verify tool binary integrity.

Network interception. Tool output traveling over the network — Nmap results, DNS responses, HTTP traffic — can be intercepted or modified. WitnessOps captures what the tool returns. If the tool received tampered data, WitnessOps records tampered data.

Operator collusion. Two operators who trust each other can approve each other's scope expansions and intrusive steps. The approval gate records who approved, but it does not enforce separation of duties unless configured to do so. Self-approval is only permitted when the workflow and external policy explicitly allow it.

Current State vs Target State

We believe in stating where we are, not where we wish we were.

The gap between current and target is real. We document it directly rather than implying it is already closed.

Trust Schema