WordPress Plugin & Theme Risk Intelligence: Know What Is Installed, What Is Risky, and What Changed
Aegisify Plugin & Theme Risk Intelligence combines current Agent-reported component metadata with exact-version defensive evidence, release information, observed health trends, and human-reviewable AI recommendations so WordPress teams can make better update and remediation decisions for sites such as example.com.
From WordPress Component Metadata to a Defensible Decision
The workflow separates metadata collection from scanning so customers can understand exactly where each piece of evidence comes from.
Click a stage to expand
01Select SiteOne authorized domain
02Fetch InventoryMetadata only
03Match Security EvidenceExact component/version
04Collect Release EvidenceVerified + declared sources
05Analyze HealthRisk + trend
06Act & VerifyUpdate + refresh
Fetching Plugin & Theme Details Does Not Run a Security Scanner
The current implementation enforces this boundary instead of relying on marketing language.
The Agent inventory action reads WordPress plugin and theme metadata and existing update state. The SaaS repository rejects the response unless it explicitly identifies the privacy mode as metadata-only and confirms that no scanner executed. That means inventory refresh itself does not run vulnerability, malware, static-code, dependency, or source-code scanning.
Security evidence enters the feature through correlation with other Aegisify workflows. Known-vulnerability records and mapped SAST counts are reused from the latest completed defensive assessment only when the current component identity and installed version match the defensive evidence precisely enough to be considered the same software state.
What Component Metadata Can Be Reviewed
Active and Inactive Plugins
The inventory records installed plugin identity, installed version, activation state, available-version information, auto-update state, repository signals, and other component metadata returned by the Agent.
MU Plugin Visibility
Must-use plugins are represented distinctly because their lifecycle differs from ordinary plugins. The normal remote update workflow does not treat a must-use component as a standard one-click plugin update.
Active, Parent, and Inactive Themes
The feature distinguishes the active theme, the parent of an active child theme where applicable, and inactive themes so operators can understand which code is directly in use and which remains installed.
Installed vs. Available
Current inventory can show whether a newer version is available and preserve the installed version used for security-evidence matching. That version context is central to avoiding stale vulnerability conclusions.
Verified WordPress.org Signals
When repository identity is established, Aegisify can use verified WordPress.org release information such as the current release version, update date, compatibility metadata, description, and release notes.
Public Vendor Release Evidence
The intelligence layer can also consider bounded public release URLs declared by the component. These sources are treated differently from verified WordPress.org evidence so source trust remains visible.
Vulnerabilities, Exploitation Context, and SAST Are Kept Traceable
A component risk decision is stronger when the user can see which evidence is documented and which conclusions are advisory.
Installed-Version Matches
The feature can surface vulnerability records associated with the exact installed component version from the latest completed defensive evidence set. Severity and documented advisory information remain attached to the security evidence.
KEV and EPSS Signals
Where the underlying vulnerability evidence contains them, Aegisify can surface known-exploitation status and exploitation-probability context. These signals help prioritize documented risk but do not replace environmental judgment.
Mapped SAST Findings
Regular plugins can show a count of mapped SAST findings from the same latest defensive evidence set when the component identity matches. A missing mapped SAST finding is not a guarantee that custom code is secure.
No “Zero Findings = Safe” Claim
The implementation explicitly avoids treating zero matched vulnerabilities as proof that a component has no security issue. Unknown, unpublished, configuration-dependent, or newly introduced risk can still exist.
A Health Score Is Decision Support, Not Certification
The current feature calculates an observed posture score from current component evidence and can compare that score with earlier successful analyses.
Observed health incorporates deterministic signals such as documented vulnerability severity, known-exploitation context where present, exploitation-probability evidence, update availability, security-update evidence, and component update posture. The result is represented on a 0–100 scale with a letter grade for easier scanning.
When earlier analysis exists, Aegisify can label the direction as new, stable, improving, or declining. This makes the component page useful for operational questions such as “Did the update improve the observed posture?” rather than treating the current score as a timeless rating.
Release and Risk Recommendations Are Bounded by Evidence
The AI layer is designed to explain controlled component evidence rather than substitute model memory for documented facts.
Build the Component Evidence Package
Aegisify combines the current component metadata, matched vulnerabilities, and bounded release sources. Verified WordPress.org data is distinguishable from component-declared public source material.
Generate a Human-Reviewable Analysis
The AI service can summarize risk, confidence, documented evidence, recommended action, whether a security update is supported by current evidence, latest release information, update significance, and notable release features.
Apply Deterministic Guardrails
The implementation includes post-analysis controls intended to prevent the AI output from contradicting documented vulnerability and update facts. AI can explain the evidence; it should not rewrite the source-of-truth evidence.
This Workflow Has a Specific Gemini Disclosure
The current SaaS implementation explicitly documents a Plugin & Theme Risk Intelligence exception that should be visible to customers.
For this feature’s AI analysis, SaaS may send component names, versions, component-declared release evidence, and matched vulnerability evidence to the configured Gemini service even when the broader attack-surface redaction setting is enabled. The code states that this exception is specific to Plugin & Theme Risk Intelligence and that the global setting remains unchanged for other AI workflows.
This is different from the Agent inventory fetch itself. The inventory fetch is metadata-only and does not run a scanner. The later AI analysis uses a bounded set of component and public/security evidence to create recommendations.
Six Signals Help Operators Find Components That Need Attention
Update, Refresh Inventory, Then Verify the Installed Version
The current implementation does not treat sending an update request as proof that the target changed successfully.
Only Supported Operators
The remote component-update action is restricted to users with the required domain-management authority and a current connected Agent.
Request the Supported Update
For an eligible plugin or theme with a current update available, Aegisify can ask the Agent to perform the WordPress-side update. Must-use plugins remain outside the normal update flow.
Refresh and Confirm Version
After the update, Aegisify refreshes component metadata and checks the resulting installed version against the expected available version. If verification fails, the workflow reports uncertainty instead of claiming success.
Prioritize the Component, Not the Noise
The implementation can identify priority components when current evidence shows a matched vulnerability, an available update, or a declining observed-health trend.
This gives agencies and WordPress operators a practical sequence: refresh metadata, review exact-version security evidence, inspect release information, analyze the components that need attention, decide whether an update or other remediation is appropriate, verify the new installed state, and then let later defensive evidence establish whether the risk actually changed.
Common Questions About Component Risk Intelligence
Does fetching plugin and theme details scan source code?
No. The current implementation requires the Agent response to identify the collection as metadata-only and to confirm that no component scanner executed. Vulnerability and SAST evidence comes from separate defensive assessment data.
Can an old vulnerability finding be carried onto a newly updated plugin?
The repository uses strict current-component identity and installed-version matching before reusing defensive evidence. The intent is to prevent stale findings from being inherited by a different software version through loose matching.
What does the health score mean?
It is an observed posture score based on current inventory, update state, and documented vulnerability evidence, with trend context when earlier analyses exist. It is not certification or a guarantee of security.
Does the AI use only WordPress.org data?
No. Release intelligence can use verified WordPress.org data when repository identity is established and can also consider bounded public release information declared by the component. The analysis preserves an evidence-trust distinction between source types.
What information may be sent to Gemini for this feature?
The current SaaS notice states that component names, versions, declared release evidence, and matched vulnerability evidence may be sent for Plugin & Theme Risk Intelligence even when the global attack-surface redaction setting is enabled. Organizations should evaluate that specific workflow against their data policies.