The total number of vulnerability libraries is increasing day by day, should the webmaster pay attention to the total amount or the increase?
The total number of vulnerability libraries is increasing day by day, should the webmaster focus on the total amount or the new ones? The answer is to focus on the new ones, but to pay attention to the 'new ones related to this site'. The total amount answers the ecological level question - the scope of collection is expanding, and vulnerability mining is accelerating;It cannot answer the specific situation of any site because more than 90% of the entries in the library have nothing to do with what you have installed. The page of the vulnerability library reviewed that day states: This vulnerability library for the WordPress ecosystem has a cumulative total of over 55,900 entries, including over 18,000 entries with缓解 rules already established, over 13,000 entries marked as having no official patch, and over 900 entries still in the diagnosis stage.
What questions do the two口径 respectively answer
The total amount is suitable for viewing once a quarter. Its changes indicate three things: whether the collection range of the library has expanded during this period, which type of component is covered more, and whether the relative proportion of official patches and mitigation rules has changed. These are trend information, not action instructions.
Add suitable for scanning every day or every two days, but only look at one question: Whether the component name appears in your list, and whether the version you installed falls within the affected range. The rest are irrelevant to this week's work. Mixing the two together is easy to make two mistakes: seeing an increase in total and panicking to upgrade in bulk, or ignoring the truly hit new entries because 'they are all old entries.'
Why can't the total be used directly as a risk indicator
Three reasons. Firstly, the library is cumulative across versions, and many entries correspond to old branches that have been eliminated; secondly, the same defect may be collected repeatedly from multiple sources, and the number of entries does not equal the number of independent risk items; thirdly, the entries contain a large number of paths that require specific conditions to be established, and theoretical feasibility and those already in the wild are two completely different levels of handling priority. The proportion of the triage stage and the absence of official patches should also be taken into consideration: even if there are a large number of entries without patches, all that can be done is to tighten the access scope and add alerts, which should not be queued in the same column as entries with patches that can be installed immediately.
How to filter out related entries on this site
The premise of filtering is to have a list. The list should be able to be exported regularly: the main version of the program, the name and version of each component in use, and the anonymous accessible address. Manual flipping of the background will miss, and a more stable approach is to go through the interface for batch verification - The AnQiCMS (AnQi CMS) interface document covers high-frequency capabilities such as document list and details, categories and tags, system and settings reading, etc. API calls can retrieve the in-use components and versions at one time, and then compare them with the search results of the vulnerability library; this step can also be配合 with the full-text search entry on the site, to check suspicious wording and old drafts at one time.
After filtering, only three fields are retained: component name, current version, and impact range. Only when the three fields match will it enter the disposal queue.
After filtering, what order should be disposed of?
Sort by whether it can be triggered anonymously, not by the entry time of the item. The first tier is anonymous and has been in the wild, to be handled on the day; the second tier is anonymous and theoretically feasible, to be scheduled into the nearest maintenance window; the third tier requires a background account or privileged role, to first tighten the account and permissions, and then wait for the window; the fourth tier requires custom code to be established, to be recorded and observed.
No matter which level, there must be an available backup before taking action - ensuring that data (including static files) is backed up and can be restored is the premise for making 'take a look first' a safe practice. Measures such as SQL injection and XSS protection at the program level, JWT authentication on the interface side, and sensitive word filtering and anti-crawling interference code on the content side can reduce the scope of impact, but they cannot replace the upgrade and rollback plan.
Common questions
Should I subscribe to all vulnerability updates?No. Subscribe to the results pushed according to the component list matching, and the unmatched entries are just noise.
What does a sudden jump in the total amount indicate?Generally, the library confirms whether there are components from this site in the newly added ones before complementing the historical collection or expanding the coverage range, and then judges whether it affects itself.
Should entries without official patches be followed separately?Yes. They should enter the tracking list and be handled uniformly after the patch is released, during which access restrictions and log alerts are used.