Nine out of ten new vulnerability entries in a year are due to extensions rather than the core, how can the list prove itself?
More than 90% of the tens of thousands of newly discovered vulnerabilities are in extensions rather than the core, and websites need to prove that their component list is clean. It's not just the phrase 'the core program version is fine' that counts, but also three lists: which extension components are installed, which version each component is currently using, and where each component comes from and who maintains it. The white paper verified on the day clearly explained the distribution: in the statistical year, more than 13,000 new vulnerability entries were discovered, with 91% coming from extension plugins, and only six from the core program.
What does the distribution口径 mean?
Most of them are concentrated in extensions, meaning that the risk is determined by what you install, not by which program you use. The core program code is extensively audited and has a fixed release process; the number of extension components is large, maintainers are scattered, and the depth of review is uneven, which is not on the same level as the former. Another set of time scales is also given in the same document: vulnerabilities that are concentratedly exploited are only at the five-hour median time level and are widely exploited, and sites that do not have time to check the list can only be beaten passively.
That's why the statement 'Our system is very secure' does not stand alone: it is only true at the core level, and each item needs to be checked at the extension level.
First clear the list before discussing patches
The order of clearing the list is to enumerate the components first, and then compare them with the affected areas one by one. Enumeration cannot rely on memory, and it should be cross-extracted from three places: the deployment directory, the dependency list, and the background plugin page, and take the union. Many sites have the problem that there are components in the list that 'no one remembers why they were installed', and these components are often still being accessed.
When comparing the interval, both the upper and lower bounds should be copied down, and only remembering the 'fixed version' will miss the branch line: the same component often has multiple parallel maintenance versions, only the latest branch is upgraded, and the old code running on the other branch is still exposed.
How to build three accounts
| Account book | Record content | Update trigger | What questions can be answered? |
|---|---|---|---|
| Component list | Name, purpose, installation location, person in charge | Components added or deleted each time | How many things did we actually install |
| Version comparison | Version in use, affected range, fixed version | Each upstream announcement | Does this announcement concern me |
| Source status | Distribution channels, recent update time, whether still maintained | Quarterly inspection | Does this component still deserve trust? |
Three tables need to intersect to sort: The affected area hits, and there are no fixes in the current version, and the component has stopped maintenance, has the highest priority; Extensions of unknown origin should be taken offline first for evaluation even if there are no known vulnerabilities at present.
Protection capability does not equal component security
The built-in protection on the program side is another layer. The AnQi Content Management System (AnQiCMS) covers SQL injection, XSS, and sensitive word filtering on the input and control panel,配合令牌化的接口鉴权与干扰码，these capabilities handle the risks「when requests enter the system,」but cannot endorse the component version. When the component itself has vulnerabilities, malicious input may take a completely different path.
Similarly, the built-in backup capability solves the problem of whether you can roll back after an incident, it reduces the recovery time, but not the probability of being attacked. Describing the three things of 'protection, backup, and checklist' separately is useful to the reader.
Common questions
Question: If you only use the extensions in the official directory, do you still need to check them? Answer: No. The components in the directory may also have vulnerabilities, but the credibility of the source is higher, and version comparison still needs to be done.
Question: How often should the list be updated? Answer: At least quarterly, and run version comparison again each time there is an upstream announcement.
How to handle components that cannot be upgraded? First, confirm if they are still being accessed, if possible, take them offline; if not, record the risk acceptance and responsible person.