WordPress Static Security Scan: Vulnerability Intelligence and SAST From the Inside Out
Aegisify Static Security Scan gives WordPress teams two complementary ways to examine risk: Vulnerability Scan for software, hardening, exposure, operational risk, and dependency evidence when supported; and SAST Static Code Analysis for Agent-assisted review of WordPress PHP, JavaScript, Python, authorization patterns, and security-relevant code conditions.
What known and observable risks exist in this WordPress environment—and what security-relevant patterns exist inside the code and configuration that an external scan cannot reliably see?
How a Defensive Static Scan Moves From WordPress to Action
Open each stage to see the high-level flow. The assessment combines Aegisify cloud analysis with authorized Agent-side evidence and is designed to support repeatable review without exposing private WordPress internals on this public page.
Click a stage to expand
01Scope the Siteexample.com
02Choose the ViewVulnerability or SAST
03Collect EvidenceSaaS + Agent context
04CorrelateNormalize related signals
05PrioritizeRisk + workflow state
06VerifyRescan + focused retest
Static Security Scan Is the Defensive Family, Not a Single Check
Aegisify uses two complementary static assessments with different jobs: broad vulnerability and defensive-posture review, and deeper Agent-assisted code analysis.
The Vulnerability Scan is the recommended recurring starting point for broad defensive review. It is designed to answer broad questions about WordPress software risk, known vulnerabilities, dependency risk, hardening drift, externally visible exposure, site health, recovery readiness, and operational security. It combines the former defensive baseline with Agent inventory and WordPress vulnerability intelligence.
The Static Code Analysis assessment goes deeper into code and authorized WordPress context. It uses the connected Agent for internal source inspection and normalizes results from bundled PHPCS/WPCS analysis, Aegisify PHP and JavaScript rules, local Python rules where supported, WordPress-specific security checks, and authorization-oriented analysis.
Vulnerability Scan vs. SAST Static Code Analysis
Start with the profile that answers the question you actually need to resolve.
Vulnerability Scan
Use this for recurring WordPress risk review. It inventories core, plugins, themes, must-use plugins, package dependencies, update state, vulnerability matches, hardening conditions, API exposure, operational warnings, recovery signals, and related software-risk evidence.
SAST Static Code Analysis
Use this when code assurance matters. The Agent examines supported WordPress source locally, applies multiple static-analysis engines and WordPress-aware rules, then returns normalized finding metadata rather than full source-code bodies.
Software Risk + Code Risk
A vulnerability feed can tell you that a component version is associated with known risk. SAST can identify security-relevant implementation patterns in code. Running both gives a more complete static view without pretending either one replaces live dynamic testing.
What the Defensive Static Family Reviews
The assessment type determines which evidence layers are emphasized, while the overall static-security program is built around several connected evidence domains.
Core, Plugins, Themes, and Must-Use Components
Aegisify builds a WordPress software inventory and reviews version state, active and inactive components, update posture, integrity indicators, unsupported or abandoned software signals, and known vulnerability relationships where supported by the selected profile.
Package and Manifest Risk
The Agent can discover supported dependency manifests and lockfiles for Composer, Python, npm, Yarn, and pnpm. When the required local tooling and manifests are available, dependency-audit evidence can be collected and correlated with the SaaS vulnerability workflow.
WordPress Security Posture
Defensive checks cover categories such as login and registration posture, REST exposure, security headers, HTTPS/TLS, installation artifacts, sensitive configuration posture, file permissions, writable locations, public hints, and externally observable application-health conditions.
Files, Settings, and Drift
Where evidence is available, Aegisify can review integrity mismatches, suspicious file-change indicators, configuration drift, plugin activation changes, core integrity context, critical-file posture, and other changes that help distinguish a static inventory from a living environment.
Cron, Site Health, Recovery, and Defensive Controls
The defensive baseline includes operational signals such as scheduled-task health, Site Health warnings, application errors, backup and restore readiness, security-plugin visibility, firewall/edge visibility, and other conditions that affect the ability to operate and recover securely.
SAST and WordPress-Aware Review
The Static Code Analysis assessment adds code-level inspection for PHP, JavaScript, Python where supported, WordPress secure-coding patterns, REST and AJAX authorization signals, potential secret exposure, suspicious code patterns, and normalized rule evidence.
Why the Aegisify Audit Agent Matters
External observation is useful, but it cannot reliably see the complete WordPress software inventory, local dependency manifests, source files, privileged configuration state, or internal activity evidence.
Aegisify Establishes the Assessment Scope
For an authorized site such as example.com, Aegisify identifies the assessment type and the evidence categories needed for that review. The public documentation focuses on what is evaluated rather than reproducing authenticated application controls.
The Agent Performs Authorized Local Work
Agent-assisted work is tied to the registered, encrypted SaaS connection. The longer vulnerability and static-analysis tasks are queued locally as background work rather than forcing the browser to remain open. The Agent caches the completed report for SaaS to retrieve and correlate with the job.
Aegisify Normalizes the Result
The service correlates Agent and scanner evidence into a consistent findings model, records coverage and tooling status, and preserves enough historical context to compare what changed between assessments.
Activity Sensors and Telemetry Access Are Related—but They Are Not the Same Control
The Agent separates local event collection from permission to make supported telemetry available to SaaS.
WordPress Activity Log sensors determine which supported WordPress events are recorded locally. The Aegisify Audit Agent defines sensors across users, settings, plugins, themes, WordPress core, files, posts, taxonomy, comments, media, menus, options, and Aegisify Audit activity. Most sensors are enabled by default; four high-volume option-change sensors are disabled by default because they can be noisy.
Telemetry Access Control is the authorization layer for SaaS access. Telemetry sharing is customer-controlled and begins disabled until an administrator intentionally enables the supported categories needed for the engagement. Administrators explicitly enable the master control and the categories they approve, including software versions, integrity hashes, administrative inventory, cron/event inventory, backup/restore telemetry, snapshot differences, file-drift history, privileged configuration states, and optional log fetch permissions.
How to Use Static Security Scanning as a Repeatable Practice
The public workflow is simple: establish scope, collect authorized evidence, run the appropriate assessment, review findings, remediate, and verify.
The Goal Is Not More Alerts. It Is Better Security Decisions.
Aegisify turns the defensive scan into a workflow rather than a one-time report.
Findings remain associated with their assessment and site context so teams can triage, assign, remediate, accept, or verify risk according to their own security process. Static findings preserve code and rule context, while vulnerability findings preserve software, advisory, and dependency evidence.
Detailed findings can also carry remediation and closure guidance. AI-assisted remediation is available in the current defensive detail workflow, but it is explicitly advisory: administrators should review recommendations, back up affected files or configurations, apply changes through normal change control, and test again.
Common Questions About Aegisify Static Security Scanning
Is Vulnerability Scan the same as Static Code Analysis?
No. Vulnerability Scan is the broad recurring defensive assessment for software, hardening, exposure, operational risk, and optional dependency evidence. Static Code Analysis is the deeper Agent-assisted SAST profile for source and WordPress-aware code analysis. They overlap in contextual security posture but answer different primary questions.
Does the browser need to remain open for the scan?
No. Longer Agent-assisted work can continue independently of the browser page. Teams can return later to review the completed assessment and its findings.
Does Aegisify send full source code to SaaS for SAST?
The supplied Agent describes its static-analysis privacy mode as metadata-only. Static results exclude source-code bodies and return file metadata, rule identifiers, line ranges, and normalized evidence. This allows Aegisify to organize findings without treating full source files as the normal result payload.
Do I need to run both Vulnerability Scan and SAST every time?
No. Use Vulnerability Scan for routine software and defensive-posture review. Add SAST when custom code, application changes, release assurance, or a deeper code-level investigation justifies the additional analysis.
Do sensors automatically give SaaS access to every activity record?
No. Sensors control which supported WordPress events are collected locally. Telemetry Access Control separately determines whether supported telemetry or activity-log fetch access is authorized for SaaS. Telemetry access remains disabled until an administrator intentionally enables the supported access needed for the environment.