Cyber Security

WP HoloDev includes a dedicated Cyber Security mode for reviewing and improving the security of software projects. It works with the code and configuration inside the current project, so it can be used for WordPress development as well as other application and software projects.

Cyber Security mode can inspect source code, trace endpoints and callers, review authentication and permissions, check dependencies, look for exposed secrets, examine filesystem and command handling, and run the security tools and validators available to the project.

You can use it for a read-only security audit, ask it to investigate a specific concern, or authorise it to correct confirmed problems and run the relevant regression checks afterwards. The scope of the task remains under your control.

Security work uses the same project boundaries, permissions and execution controls as the rest of WP HoloDev. Tools and specialist security capabilities can be selected automatically when they are relevant, while Model Assignment and Agent Level continue to control which models may be used and whether specialist reviewers can be involved.

Cyber Security mode is designed for defensive security work on projects you are developing or authorised to review.

Security Review Built Around the Project

Cyber Security mode works from the actual project rather than treating security as a checklist applied in isolation. It can inspect source files, configuration, dependencies, routes, permissions, data handling and the relationships between different parts of the codebase.

This makes it useful for both broad security reviews and targeted investigations where you already know which part of the application needs attention.

Review the Whole Project

You can ask for a general security review of the current project and allow WP HoloDev to identify the areas that deserve closer inspection.

This can include authentication, authorisation, input handling, output escaping, database access, filesystem operations, network behaviour, command execution, dependencies and exposed secrets.

Investigate a Specific Risk

You can also narrow the work to one area, such as a REST endpoint, authentication flow, upload handler or piece of database logic.

For example:

Trace this endpoint from registration to every caller and check the permissions, validation and data exposure.

Read-Only Audits or Authorised Remediation

Security review and security remediation are treated as separate intentions.

Read-Only Security Review

If you ask for an audit or review without requesting changes, WP HoloDev can inspect the project and report its findings without modifying the source.

This is useful when you want to understand the current security state before deciding what should be changed.

For example:

Perform a read-only security audit. Do not modify anything. Report only confirmed findings with evidence.

Fix Confirmed Problems

If you authorise remediation, confirmed issues can be corrected using the normal project editing and validation tools.

The work can then be checked again to make sure the correction resolves the original problem without introducing a new regression.

For example:

Fix the confirmed security findings only. Do not change unrelated code and run the relevant regression checks afterwards.

Automatic Security Tool Selection

You do not need to choose every security tool manually before starting a review.

Cyber Security mode can select relevant inspection, search, validation and testing capabilities automatically as the investigation develops.

Repository Inspection

Project files, symbols, references and dependencies can be inspected to establish where sensitive behaviour is implemented and how different parts of the codebase connect.

Endpoint and Caller Analysis

Routes, callbacks and callers can be traced so a security-sensitive entry point is reviewed in context rather than as a single isolated function.

Dependency Checks

Supported dependency audit tools can be used where the project provides the required package information and tooling.

Secret Scanning

Projects can be checked for credential-shaped values and other sensitive material that should not have been committed to source or included in distributable files.

Deterministic Security Validation

Where available, security validators can supplement source review with repeatable checks against the project.

Automatic tool use remains subject to the same project boundaries and permissions as any other WP HoloDev task.

Authentication and Authorisation Review

Access-control mistakes are often more serious than ordinary coding errors, so Cyber Security mode can focus specifically on who is allowed to perform an action and where that decision is enforced.

Authentication

Authentication flows can be traced to check how users, sessions, tokens or other identities are established and trusted.

Authorisation

Permission and capability checks can be reviewed to make sure sensitive operations are not available simply because a request reached the correct endpoint.

Privilege Boundaries

The review can look for places where low-privilege users, unauthenticated users or untrusted input may cross a boundary that should require additional authority.

WordPress Permissions

In WordPress projects, this can include capability checks, nonces, REST permission_callback logic, AJAX permissions and administrative actions.

Input, Output and Data Handling

Cyber Security mode can review the way data enters the application, how it is processed and where it is ultimately used.

Input Validation

Request parameters and external data can be checked for appropriate validation before they are used by security-sensitive code.

Sanitisation

Stored or transformed values can be reviewed to make sure sanitisation matches the type of data being handled rather than relying on a generic filter everywhere.

Output Escaping

Output can be checked at the point where it enters HTML, attributes, URLs, JavaScript or other output contexts.

Database Access

Queries and persistence logic can be inspected for unsafe SQL construction, incorrect assumptions about trusted values and unnecessary data exposure.

Filesystem, Command and Process Security

Projects that read files, write files, extract archives or launch commands need stronger boundaries than ordinary application logic.

Filesystem Operations

Path construction and file operations can be reviewed for traversal, unsafe joins, symbolic-link or reparse-point escapes and unintended access outside the expected workspace.

Archive Handling

ZIP and archive code can be reviewed for unsafe paths, absolute destinations, suspicious links, extraction races and other common archive problems.

Command Execution

Code that starts external programs or builds command lines can be inspected for injection risks, uncontrolled arguments and unnecessary host-machine authority.

Temporary Files

Temporary-file handling can be reviewed for unsafe locations, predictable names and race conditions where relevant.

Network and Browser Security

Applications that fetch URLs, connect to external services or automate browser activity can expose a different set of risks from ordinary local code.

Outbound Requests

Network destinations and URL handling can be reviewed for unsafe schemes, private or reserved targets, embedded credentials and server-side request forgery risks.

Redirects

Redirect logic can be checked to make sure untrusted input cannot send users or backend requests to arbitrary destinations.

Browser Workflows

Where browser testing is available, security-sensitive interfaces can be exercised to check login behaviour, permissions, error handling and other runtime behaviour that is difficult to establish from source alone.

External Services

MCP and other external capabilities remain subject to WP HoloDev's network and permission controls while Cyber Security mode is active.

Dependency and Supply-Chain Review

Security problems do not always originate in the project's own source code.

Dependency Audits

Supported package managers and dependency audit tools can be used to identify known security problems where the required project metadata and runtime are available.

Package Configuration

Dependency files can also be reviewed for risky scripts, unexpected sources, broad version ranges and other configuration that deserves attention.

Third-Party Code

Bundled libraries and externally sourced code can be identified during repository analysis so they are not automatically mistaken for first-party project code.

Unavailable Checks

If a dependency scanner or package runtime is not available, WP HoloDev reports the check as unavailable rather than presenting it as passed.

Secrets and Sensitive Information

Credentials and private configuration can cause serious problems when they find their way into source control, logs or release packages.

Credential-Shaped Values

Security review can look for API keys, tokens, passwords and other values that resemble credentials.

Configuration Files

Environment files, configuration files and development fixtures can be inspected for sensitive information that should not be distributed.

Logs and Diagnostics

Logging code can be reviewed to make sure credentials, session values or other sensitive information are not being recorded unnecessarily.

Release Content

When reviewing a project for release, security checks can also consider whether sensitive development files or secrets are being included in distributable output.

Independent Security Review

Where Agent Level allows it, security work can include a separate reviewer rather than relying entirely on the same agent that performed the main investigation or remediation.

Security Reviewer

A specialist security reviewer can inspect authentication, permissions, input handling, data exposure and other security-sensitive areas.

Review After Remediation

A completed security fix can be reviewed independently before the job is considered finished.

Agent Level Full

Full allows specialist reviewers to be created when they are useful to the task.

Agent Level Low

Low allows up to four logical specialist agents across the complete job.

Agent Level None

None keeps all model-backed security work with the main agent. Native security tools, repository inspection and validators remain available.

Model Control in Cyber Security Mode

Cyber Security mode does not force a particular provider or model.

The normal Model Assignment settings continue to apply.

Full Auto

Full Auto can select the lowest-cost available route that has the capabilities required for the security task.

A simple source review does not necessarily need the same model as a complex architecture or security investigation.

Semi-Auto

Semi-Auto lets you restrict security work to an allowlist of exact provider connections and models.

Manual

Manual keeps all model-backed security work on the exact provider connection and model you selected.

There is no silent model fallback in Manual mode.

Tools Are Separate From Model Assignment

Whichever Model Assignment setting you use, authorised native security tools and validators remain available to the job.

WordPress Security

Cyber Security mode is not limited to WordPress, but WordPress projects can make use of additional platform-specific knowledge and validation.

Nonces and Capabilities

Administrative and user-initiated actions can be checked for the appropriate nonce verification and capability checks.

REST API

REST routes can be traced and reviewed for permissions, argument validation and unnecessary exposure of private information.

AJAX and Admin Actions

AJAX callbacks and admin-post handlers can be checked for missing authentication, weak authorisation and unsafe request handling.

Database Queries

Direct database access can be reviewed for correct preparation, safe dynamic identifiers and appropriate handling of external input.

Output Security

Administration screens, frontend output and generated markup can be reviewed for correct contextual escaping.

Plugin Validation

Where appropriate, WordPress Plugin Check, WordPress Coding Standards and Holographic Plugin Check can supplement the security review.

Evidence-Based Findings

A useful security report needs more than a list of possible problems.

Confirm Findings Against the Source

Scanner output and automated findings should be checked against the actual implementation before they are treated as confirmed vulnerabilities.

Trace the Cause

Where possible, findings should identify the relevant code path and explain why the behaviour is unsafe.

Separate Confirmed Problems From Suggestions

A genuine vulnerability should not be presented in the same way as a general hardening suggestion or stylistic preference.

Recheck After Changes

If a confirmed issue is fixed, the relevant checks can be rerun to establish that the original problem is gone and that the change has not introduced another failure.

Security Work Stays Inside Project Boundaries

Cyber Security mode is intended for defensive work against projects you are developing or have permission to review.

Project Files

Filesystem tools remain restricted to authorised project locations.

External Targets

The mode is not intended to provide unrestricted access to unrelated websites, servers or networks.

Tools and Permissions

Security mode does not weaken command, filesystem, browser, network or MCP controls.

No Extra Authority From the Mode

Choosing Cyber Security changes the type of work being performed. It does not grant broader access to the computer or network.

Example Cyber Security Tasks

Complete Read-Only Audit

Perform a complete read-only security review of this project. Do not modify anything. Report only confirmed issues and include the evidence for each finding.

Endpoint Review

Find every externally accessible endpoint in this project, trace its callback and callers, and check authentication, permissions, validation and data exposure.

Secrets Review

Check the project for credentials, tokens, private configuration and other secrets that should not be present in source or release files.

Dependency Review

Inspect the project's dependencies and run the available dependency security checks. Separate confirmed vulnerabilities from checks that could not be run.

Filesystem Security

Review every place this project reads, writes, moves, deletes or extracts files. Check for traversal, link escapes, unsafe destinations and race conditions.

Remediation

Fix the confirmed high and medium security findings only. Preserve unrelated behaviour and run the relevant tests and security checks afterwards.

Independent Final Review

Review the completed security changes independently and report any remaining confirmed vulnerabilities or regressions.

Cyber Security Without a Separate Workflow to Learn

Cyber Security mode uses the same project, model and job controls as the rest of WP HoloDev.

You still choose Model Assignment and Agent Level in the normal way. Skills and tools can be selected automatically, and you can still use explicit commands when you want direct control.

The difference is the focus of the work: security-sensitive parts of the project are given priority, review-only requests remain review-only, and confirmed findings can be taken through remediation and validation when you authorise it.

Use Cyber Security mode when the question is not simply whether the code works, but whether it can be trusted to behave safely.