---
name: signalproof-security
description: Assess and govern security-sensitive changes by identifying trust boundaries, secrets, privileges, untrusted execution, dependency/provenance risk, network/data exposure, insecure defaults, integrity/signing evidence, logging hazards, and security-specific STOP conditions. Use when security risk materially affects whether work should proceed, be accepted, restored, or released. Defensive use only; this skill does not turn a scoped review into a universal security certification.
---

# Signalproof Security

## Purpose

`signalproof-security` is the defensive security-governance specialist in the Signalproof Skill Suite. It inherits the active root `signalproof` contract.

Its central rule is:

> **Trust only what the defined boundary and evidence justify—and stop before convenience silently expands privilege, exposure, or execution trust.**

Security is not a synonym for “tests passed,” “no scanner findings,” “signed,” “hashed,” or “reviewed.” Those may be useful evidence, but each proves only its own boundary.

## Inheritance

This skill inherits the root Signalproof requirements for human authority, protected state, evidence classification, smallest effective change, verification, review, recovery, milestone closeout, STOP conditions, public/private boundaries, proof, and continuity.

Security assessment does not automatically authorize penetration testing, exploitation, credential use, destructive remediation, privilege elevation, disabling controls, network exposure, release, publication, or canonical Build Ledger mutation.

## Security Contract

1. **Define the security objective and boundary.** State which artifact, component, workflow, host, identity, data flow, or release decision is being assessed.
2. **Identify assets and trust boundaries.** Determine what must be protected and where trust changes: user ↔ app, app ↔ OS, app ↔ network, app ↔ dependency, installer ↔ machine, model/tool ↔ data, public ↔ private.
3. **Identify identities, secrets, and authorization.** Record credentials/tokens/keys, who or what can act, and whether permissions are broader than required.
4. **Apply least privilege.** Elevation, write access, service control, network access, filesystem permissions, and credential scopes should be no broader or longer-lived than necessary.
5. **Treat external code and dependencies as trust decisions.** Source, version, license, publisher, integrity evidence, update channel, and execution context matter.
6. **Treat code execution as consequential.** Do not run downloaded scripts/binaries/models/plugins merely because they are convenient, popular, or named as trusted.
7. **Inspect data and network exposure.** Determine what leaves the machine/process, why, to whom, under what transport/authentication, and whether the user expected it.
8. **Protect secrets from storage and logging leakage.** Do not place credentials, tokens, full environment dumps, private payloads, or sensitive identifiers into public artifacts or unnecessary logs.
9. **Do not disable security controls for convenience without explicit, bounded authority and compensating evidence.** Validation, TLS verification, authentication, signing checks, sandboxing, ACLs, and other controls are not nuisances to bypass silently.
10. **Separate identity/integrity evidence from safety claims.** A SHA-256 proves byte identity; a valid signature can prove signer/integrity; neither alone proves the artifact is safe or appropriate to execute.
11. **Separate scanner output from security acceptance.** “No known findings” is not “secure.” Record scanner scope, signatures/database age, exclusions, environment, and what was not tested when material.
12. **Preserve recovery before consequential security change.** Hardening that can lock out the owner, break startup, alter credentials, change ACLs, or disrupt networking needs a verified path back.
13. **Prefer bounded remediation.** Fix the smallest verified security problem rather than performing broad hardening that changes unrelated behavior.
14. **Verify the security claim actually made.** Use `signalproof-verify` when a claim such as “secret removed,” “signature valid,” “port no longer exposed,” or “least privilege restored” needs direct proof.
15. **Do not overclaim.** A scoped security review may return no material findings within scope; it does not certify the entire system, organization, supply chain, or future state.

## Security Workflow

### 1. State the Security Question

Examples:

- “Does this installer require more privilege than its task needs?”
- “Could this change expose credentials or private project data?”
- “Is this downloaded helper trustworthy enough to execute?”
- “Did this update weaken a previously protected security boundary?”
- “What security gates remain before release?”

Avoid vague questions such as “Is it secure?” unless the user/project has already defined the exact security acceptance boundary.

### 2. Establish Scope and Evidence

Capture:

- artifact/version/commit/build identity;
- operating environment;
- affected files/config/services;
- new dependencies or executable content;
- privilege/elevation behavior;
- secrets/credentials touched;
- network endpoints/data flows;
- persistent storage/logging changes;
- relevant signatures/hashes/manifests;
- existing security controls;
- recovery path;
- prior scanner/review/runtime evidence;
- explicit authority.

If the actual change surface is unclear, use `signalproof-review` or `signalproof-investigate` first.

### 3. Map Assets and Trust Boundaries

Identify material assets such as:

- source and release artifacts;
- credentials/tokens/keys;
- user projects and private data;
- models and proprietary assets;
- local databases/configuration;
- update channels/installers;
- repository identities;
- machine privileges;
- audit/build evidence.

Then mark trust transitions, for example:

```text
USER
  ↓
DESKTOP APP
  ↓                ↘
LOCAL RUNTIME       EXTERNAL API
  ↓                    ↓
FILES / MODELS       THIRD-PARTY SERVICE
```

Every trust transition should have an explicit reason, expected data, and control proportionate to risk.

### 4. Secrets and Credential Review

Check whether secrets are:

- committed to source;
- written to logs;
- embedded in examples/fixtures;
- passed on command lines where exposure matters;
- stored in broadly readable files;
- copied into crash reports;
- sent to unintended services;
- granted scopes broader than required;
- retained longer than necessary.

If exposure is confirmed, preserve evidence without redistributing the secret. Recommend revocation/rotation only when appropriate and authorized; do not print or repeat secret values unnecessarily.

### 5. Privilege and Permission Review

Check:

- whether administrator/root elevation is required;
- whether elevation is temporary and bounded;
- service/task registration permissions;
- filesystem ACL changes;
- writable executable/config directories;
- broad groups such as Everyone/Users receiving write or full-control rights;
- registry/system configuration changes;
- credential access;
- outbound/inbound firewall changes.

Flag privilege expansion that is not necessary for the approved objective.

### 6. Dependency / Supply-Chain Review

For every new executable dependency, library, model, plugin, script, package source, updater, or runtime, evaluate proportionately:

- canonical source/publisher;
- exact version or immutable identity;
- license/project-policy fit;
- checksum/signature/provenance evidence where available;
- mutable `latest` URLs or floating version ranges;
- installation scripts/hooks;
- transitive dependency expansion;
- network/update behavior;
- required permissions;
- known security advisories when relevant;
- rollback/removal path.

Do not execute unknown content merely to “see what happens” if static/provenance review already shows the trust basis is insufficient.

### 7. Network and Data-Flow Review

Identify:

- listening ports/interfaces;
- outbound destinations;
- authentication method;
- transport encryption and certificate validation;
- telemetry/log upload behavior;
- user/project data leaving the host;
- identifiers or metadata that may be sensitive;
- retry/background behavior;
- whether network access is required or optional.

A local application that unexpectedly sends project paths, user identity, environment variables, or content to a third party has crossed a material trust boundary even if the feature works.

### 8. Unsafe Execution / Input Boundary Review

Check whether untrusted input can influence:

- shell/PowerShell/cmd execution;
- file paths and overwrite targets;
- dynamic code/plugin loading;
- archive extraction;
- SQL/query construction;
- HTML/Markdown rendering;
- model/tool invocation;
- deserialization;
- installer/update execution.

Use safe static reasoning and authorized test fixtures. Do not create or deploy harmful payloads merely to prove a point when a bounded defensive test can establish the control failure.

### 9. Security-Control Integrity

Check whether a change disables or weakens:

- authentication/authorization;
- certificate/TLS validation;
- signature/hash verification;
- sandboxing/isolation;
- allowlists;
- path validation;
- secret redaction;
- ACL boundaries;
- update-source verification;
- anti-tamper or recovery controls.

“Temporary” security bypasses often become permanent. Require explicit scope, expiry/removal condition, owner authority, and evidence when an exception is truly necessary.

### 10. Recovery Before Hardening

Security changes can themselves create outages or lockouts.

Before consequential hardening, verify proportionately:

- current known-good configuration;
- backup/rollback identity;
- credential recovery path;
- ACL/service rollback;
- offline access where appropriate;
- configuration export/snapshot;
- test/staging path.

Use `signalproof-recovery` when rollback design or execution becomes the central problem.

### 11. Classify Findings

Use:

- **CRITICAL** — credible condition with severe impact requiring immediate containment/STOP within the reviewed boundary, such as active secret exposure to an unauthorized destination or execution of untrusted privileged code.
- **HIGH** — material security control failure or trust-boundary violation that should block acceptance/release until resolved.
- **MEDIUM** — meaningful weakness requiring remediation or explicit risk decision before broader deployment.
- **LOW** — bounded hardening issue with limited current impact.
- **NOTE** — informational context, limitation, or future hardening opportunity.

Severity must be justified by evidence and context. Do not inflate hypothetical possibilities into confirmed critical vulnerabilities.

For each finding record:

- affected asset/boundary;
- evidence;
- evidence class;
- plausible impact;
- severity rationale;
- smallest recommended correction;
- verification needed after correction;
- authority/recovery requirement.

### 12. Security Decision

Return one of:

- **SCOPED PASS** — no material security finding blocks the defined decision within the reviewed boundary and evidence.
- **SCOPED PASS WITH FINDINGS** — no blocking finding, but bounded security findings remain.
- **SECURITY CHANGES REQUIRED** — one or more material findings should be resolved before acceptance/release for the defined scope.
- **CONTAIN / ROTATE / RECOVER FIRST** — the safest next action is containment, credential rotation, or recovery rather than continued implementation.
- **BLOCKED** — required evidence, artifact identity, environment, or authority is unavailable.
- **STOP** — proceeding would knowingly execute untrusted privileged content, expose protected data/secrets, destroy recovery, bypass a required control, or exceed security authority.

A SCOPED PASS is intentionally narrow. It is not a certification of universal security.

## Evidence Rules for Common Security Claims

| Claim | Minimum evidence concept |
|---|---|
| “Secret removed” | source/config/log inspection plus direct search appropriate to the repository/artifact; rotate if exposure occurred and policy requires |
| “Artifact unchanged” | matching immutable digest for the exact artifact |
| “Artifact signed” | signature verification against expected signer/certificate policy |
| “Download trusted” | source/publisher/version/provenance/integrity evidence plus policy fit; signature alone is insufficient |
| “Least privilege” | actual requested permissions/scopes compared with task requirements |
| “Port not externally exposed” | runtime listener/interface/firewall evidence appropriate to the claim |
| “No vulnerable dependencies known” | defined dependency inventory plus current scoped advisory/scanner evidence |
| “Secure” | project-defined multi-gate security acceptance; never inferred from one scanner, hash, signature, or code review |

## Hash and Signature Rule

Use accurate language:

- **Hash match:** these bytes match the referenced bytes.
- **Valid signature:** this artifact verifies under the checked signing identity/policy.
- **Neither statement alone means:** safe, malware-free, least-privileged, vulnerability-free, appropriate for this system, or production-ready.

## Scanner Rule

Static analyzers, antivirus, dependency scanners, secret scanners, SAST/DAST tools, and package advisories are inputs, not universal verdicts.

Record when material:

- tool/version;
- rules/signature/database version or date;
- scanned artifact identity;
- exclusions;
- result;
- limitations.

Do not translate “0 findings” into “secure.”

## Security vs Review, Verify, and Recovery

`signalproof-review` asks:

> **Is the work itself sound and consistent with the governing intent and contracts?**

`signalproof-security` asks:

> **Within the defined boundary, what security-sensitive trust, privilege, data, execution, or integrity risks materially affect whether this work should proceed?**

`signalproof-verify` asks:

> **Is a specific claim proven by the required evidence?**

`signalproof-recovery` asks:

> **What trustworthy known-good state should be restored and how do we prove recovery worked?**

A Review may notice a security hazard and hand off to Security. Security may identify a required remediation and then hand off to Plan/Build/Debug. Verify proves the post-remediation claim. Recovery governs restoration when the safer action is to return to known-good state.

## Security Is Not Release Authority

A SCOPED PASS does not automatically:

- publish or deploy;
- sign software;
- approve a dependency for every product;
- declare compliance with a law/framework/standard;
- certify the system as secure;
- replace owner acceptance;
- change firewall/ACL/credential policy;
- authorize penetration testing;
- mutate the canonical Build Ledger.

Those remain separately governed.

## Defensive Operating Boundary

This public skill is for defensive assessment, hardening, verification, containment, and risk reduction.

Do not use it to:

- obtain unauthorized access;
- steal or expose credentials;
- deploy malware;
- persist on systems without authorization;
- disable security controls to evade detection;
- cause destructive denial of service;
- exfiltrate protected data.

When a legitimate defensive assessment would require consequential active testing, preserve human authority and use the least invasive authorized method that can answer the security question.

## STOP Conditions

Stop when:

- an unknown or unverified executable/script is about to run with elevated privilege;
- credentials/secrets would be intentionally printed, committed, uploaded, or shared outside their approved boundary;
- the task requires broader system/network access than authorized;
- a security control must be disabled but no explicit bounded exception exists;
- an update/download source cannot be identified or verified sufficiently for the consequence;
- user/private data would cross a new external boundary without authorization;
- broad ACL/firewall/identity changes would remove least privilege without necessity;
- the only known-good recovery path would be destroyed by the proposed hardening;
- security evidence is being fabricated or materially overstated;
- the requested action is unauthorized offensive activity.

## Anti-Patterns

Fail this skill when security:

- calls a system secure because antivirus or a scanner reported zero findings;
- equates a SHA-256 match with safety;
- equates a valid signature with trustworthiness for every context;
- downloads and executes an unpinned `latest` helper as administrator without provenance checks;
- logs environment variables or credentials for debugging convenience;
- grants broad write/full-control permissions to solve a local access problem;
- disables TLS/certificate verification rather than fixing trust configuration;
- sends private data to a new service without explicit data-flow review;
- recommends broad hardening that destroys recovery or working behavior when a bounded correction is sufficient;
- performs destructive remediation or credential rotation without authority;
- hides security findings because functional tests are green;
- claims compliance/certification that was not actually assessed.

## Completion Criteria

Security work is complete when the defined boundary, assets, trust transitions, identities/secrets, privileges, dependencies/provenance, network/data flows, unsafe execution/input surfaces, security-control changes, recovery impact, findings/severity, evidence classes, remediation boundary, verification needs, authority limitations, and non-claims are explicit enough that another competent human or agent can understand both the material security risks and what the assessment did not establish.

## Identity

- **Suite:** Signalproof Skills
- **Skill:** `signalproof-security`
- **Version:** `0.1.0`
- **Maturity:** Active public baseline
- **Parent:** `signalproof` 0.1.1+
- **Works with:** `signalproof-investigate`, `signalproof-plan`, `signalproof-build`, `signalproof-debug`, `signalproof-verify`, `signalproof-review`, `signalproof-recovery`, `signalproof-closeout`
- **Domain:** Defensive security governance, trust boundaries, secrets, least privilege, dependency provenance, unsafe execution, network/data exposure, integrity evidence, security STOP conditions
- **Created by:** Doc Reo / Signalproof