Security Architecture

The CleanShift agent runs as root because server-level security scanning requires access to all user home directories, system configurations, and WordPress database credentials. This is not optional — a non-root agent cannot perform the deep filesystem and database inspection that makes CleanShift effective.

Least-Privilege Design

• The agent only reads files and databases during scanning. Write operations only occur during explicit remediation, which requires a paid tier and explicit opt-in from the operator.
• The agent does not open inbound network ports. All communication is outbound-only via HTTPS/WSS.
• The configuration file is stored at /etc/cleanshift/config.json with 0600 permissions (root-only readable).

The agent performs all scanning locally on your server. Only extracted metadata leaves the machine:

1. Agent scans the filesystem and databases locally.
2. Metadata (hashes, paths, ownership, plugin versions) is extracted.
3. Metadata is transmitted to the CleanShift API via TLS 1.2+ (HTTPS).
4. API matches metadata against the Indicator of Compromise (IoC) database.
5. Results are displayed in the dashboard and returned to the CLI.

Guard Plugin (WordPress mu-plugin)

The Guard mu-plugin operates entirely locallywithin WordPress. All runtime logs are stored in the site's own database and are not transmitted to the CleanShift API unless explicitly triggered by the operator (e.g., sharing a support snapshot).

Before any remediation action, CleanShift creates a timestamped backup of the affected file or database entry. Remediation is never destructive — it is always reversible.

• Backups stored locally at /var/cleanshift/backups/ with automatic 30-day retention.
• Manual rollback via CLI: cleanshift rollback --scan-id <ID>
• Dry-run mode available before any remediation: cleanshift remediate --dry-run
• All remediation actions are logged to /var/log/cleanshift/remediation.log with full before/after audit trail.

CleanShift uninstalls cleanly with a single command:

What Gets Removed

• ✅ Agent binary
• ✅ Configuration file (/etc/cleanshift/config.json)
• ✅ Cron jobs
• ✅ Guard mu-plugin from all detected WordPress sites

What Gets Preserved

• ❌ Backup files — preserved for safety. Use the --purge flag to remove them.
• ❌ Scan result history — use --purge if you want these deleted as well.

The uninstall process does not modify any WordPress files, databases, or server configurations beyond what CleanShift itself installed.

• Intelligence updates (signature databases) are verified with SHA-256 cryptographic hashes before being applied. Tampered or corrupted updates are rejected automatically.
• Agent updates are distributed exclusively via the official installer script from get.cleanshift.osg.co.in.
• Remediation playbooks are versioned and auditable — no arbitrary code execution is performed on your server.

• All agent actions are logged locally at /var/log/cleanshift/agent.log.
• All dashboard authentication events are logged server-side.
• Remediation actions include: timestamp, affected file or database entry, action taken, backup location, and operator identity.
• Logs are never transmitted to the CleanShift API unless explicitly shared for support purposes.

• Agent communicates outbound-only — no inbound ports are opened on your server.
• All API communication uses TLS 1.2+ (HTTPS).
• WebSocket connections use WSS with token-based authentication.
• API enforces CORS restrictions, SSRF protection, and rate limiting.
• No third-party tracking or analytics scripts on the CleanShift dashboard.