This article aims to articulate acceptance criteria for submitting software to be covered by SVR and SVM, as well as the rationale behind such. It is important to note that our Research team validates vulnerabilities, and this means it is necessary to obtain and analyze the software in question. When the software is end of life, or very old, it is often unavailable and (more importantly) not managed by the vendor to make official claims as to its status.
EOL/EOS Software Versions
Software versions that have reached End of Life, or End of Service, will not be added to our product database. We cannot reliably obtain and validate such versions of products and as they are no longer supported should be viewed as an inherent risk to your environment. We recommend upgrading or replacing such versions regardless of what stale vulnerability references may or may not exist.
Antiquated Software Versions
Software that has not seen any updates in a year or more is considered inherently insecure. Stale code is a red flag highlighting poor support. We encourage replacing such titles regardless of what stale vulnerability references may or may not exist.
Unofficial Software Versions
Alpha, Beta, and test software (or similar) are not suitable for a production environment and thus cannot be seen as properly secured/supported, and so we recommend considering such inherently insecure.
Software Not Generally Available
A product to be tracked must be a proper, usable product for a wider audience (meaning it can be bought or acquired by anyone who desires it). Product documentation or other evidence to support it is a proper product may be requested for confirmation. Some recent reporting on the product from the vendor should exist. Software with extremely limited releases like customized products is ineligible.
Insignificant Open Source Branches
Forks of open-source projects are only considered projects in their own right if the codebase significantly diverts from the forked project (some 10% difference or more).
Software Already Tracked as Part of Software
Should a requested product already be tracked via another product (e.g. Cisco hardware versus OS), then we will not add the additional product. In such a case, one should refer to the currently tracked product.
We track Linux distribution packages, that get distributed via the Linux distribution itself, through the main Linux distribution as a product, and thus these packages are not considered products in their own right (e.g. OpenSSL package in RHEL 8 is not considered a product on its own, the product is RHEL 8).
SaaS or Cloud Products
Cloud-based / SaaS products where there is no patching action for the customer to resolve vulnerabilities are currently not currently tracked by our Research team at this time.