Requesting a New Component¶
With a huge amount of components in its database, chances are that most components you wish to add to your monitoring lists already exist within Vilocify. It can nonetheless happen that you are not able to find the desired component, e.g. because it is a rather obscure piece of software or a newly released version.
In such cases you are free to request new components through our request form. Once you submit your request, the Vilocify team will analyze it in order to ensure that a correct and reliable vulnerability monitoring is possible. This usually takes a few business days. Once your request is successfully processed, you will be alerted by email and can finally add the new component to your monitoring list. In case the Vilocify team was not able to successfully process your request, you will be alerted by email with clear instructions on how to proceed.
To ensure that the component request process runs smoothly, be aware of the following guidelines.
High Level Approach¶
The goal of our component request process is to add components to the Vilocify database in such a way, that they reflect the naming conventions used in official vendor advisories. This guarantees that we can reliably match relevant security information from the many sources in our monitoring, to the affected components. Failing to follow these conventions could lead to potentially missing out on relevant information.
Components Suitable for Security Vulnerability Monitoring¶
Not all components are suitable for security monitoring. It is therefore important to understand which types of components can be properly monitored.
Valid Components¶
- Valid are in general all components which are publicly visible, i.e. can be found or identified clearly by using an internet search engine such as Google for instance.
Only if a component is externally visible security vulnerability information can be expected from the various information sources.
Examples:
- Microsoft Windows 10 Version 22H2
- Red Hat Enterprise Linux Server 8
- Mozilla Firefox 109.0
- GNU glibc 2.37
- Cisco IOS Software 15
- ISC Bind 9.18.11
- DENX Software Engineering u-boot v2023.04-rc1 (see remark about beta versions further below)
- Hardware elements with the exact hardware model as well as the firmware / software version running on that hardware.
Examples:
- IOS XE on Catalyst 9200 Series Switches (All versions)
- SIMATIC S7-1510SP-1 PN CPU
- Drivers for a hardware component need to be explicitly defined.
They will not be automatically assigned to an operating system.
Examples:
- NVIDIA NVS300 Graphics Driver 191.87
- Alcor Micro USB Smart Card Reader Driver (All versions)
- Optional plug-ins, modules, add-ons and extensions for a framework, browser or software application need to be explicitly registered.
Examples:
- NuGet Package Newtonsoft.Json 13.0.2
- AdBlock Firefox AdBlock add-on 5.3.3
- Benjamin Trott Perl Module Crypt::DES_EDE3 0.01
- Packages from operating systems.
While Vilocify recommends monitoring operating systems as a whole, it is also possible to request specific packages of Linux distributions.
Packages can only be monitored for all versions but not version specific.
Packages can also be monitored for specific versions of distributions.
Examples:
- RHEL Package: telnet All Versions
- Debian Package: apt All Versions
- Debian 11 Package: bind9 All Versions
Invalid Components¶
- Basically all components which are not externally visible, i.e. cannot be found or identified clearly by using an internet search engine. If a component is not externally visible security vulnerability information cannot be expected from the information sources.
- Code-snippets due to lack of security advisories from the vendor.
- Individual file names or subcomponents which are installed on the system are not valid as new components for monitoring. For example
.jar
,.dll
,.exe
,.bin
,.ocx
. This is by far the most frequent reason for declined component request. Please make sure the desired components are mentioned as such on an official vendor page. Examples:- Microsoft Office DLL's 6.0.81 (correct: Microsoft Office 2007)
- commons-logging-1.1.1.jar (correct: Apache Commons Logging 1.1.1)
- sc.exe (correct: Microsoft Windows XP)
- A product family group needs to be split into individual components for monitoring. e.g. the product family "Siemens Simatic Net" needs to be split into the individual component or modules which are deployed or required for monitoring i.e. Industrial Ethernet SOFTNET-S7, SNMP OPC Server Basic, PROFINET SOFTNET PN IO, PROFIBUS S7-5613 and not the product family name "Siemens Simatic Net".
Create a Component Request¶
The form for requesting a new component can be opened from multiple points within the Vilocify Portal, e.g. by heading to the components tab of the Vilocify Portal and clicking on the "Request Component" button. Component requests sent via email will not be processed. There are multiple fields you need to fill in before being able to submit the request.
Vendor: The vendor is the company, organization, open-source community, or author of the desired component. Some vendors are obvious, e.g. Microsoft, Oracle, Red Hat, Adobe, Apache, but sometimes it is not clear how to define the vendor correctly. The following guidelines provide some guidance for such cases:
- If the component was not developed by a company, organization or open-source community, use the full author name as the vendor, e.g. Matt Johnston for the component Dropbear.
- If the company, organization, open-source community or author is unknown, use the website hosting the component, e.g. gmplib.org for The GNU Multiple Precision Arithmetic Library (GMP).
- GitHub, SourceForge, Maven, npm etc. are almost never valid vendors, as they simply are code repositories.
- Use official vendor pages to determine the correct vendor name.
Component Name: The component name is the name used to describe the software / hardware component as given by the vendor. The component name is not the name of an installation file, download file, binary file or subcomponent, i.e. not usually .jar, .dll, .exe, .msi files. The following rules are defined to name the "component name" field consistently for all types of components:
- Use the name exactly as used by the vendor to describe the component, e.g. in official product page or vendor advisories. Avoid component names not coming from official vendor pages.
- The full name should be used but an abbreviation can be added in brackets at the end of the component name. e.g. SUN Java Architecture for XML Bindings (JAXB).
- There is no need to include the vendor name in the "component name" field usually, only the component name is required e.g. Windows, not Microsoft Windows.
- Some components are written in different programming languages. In such instance, please specify the desired variety explicitly. Example: Xerces XML Parser (for Java) vs. Xerces XML Parser (for C++).
Version: The version field is for the version of the component. Use the following guidelines for the version field:
- The requested version must exist, and it should be possible to find hints of its existence on the vendor's website.
- The granularity of the requested version should match the granularity of the versions mentioned in official vendor's advisories. For example, it does not make sense to register Microsoft Internet Explorer 11.0.9600.18762 because Microsoft does not publish security bulletins on that level of granularity. Instead, Microsoft Internet Explorer 11 should be used.
- It is possible to request a wildcard version in order to monitor whole branches of a component. This is especially useful for components that receive frequent security updates that change its version. Instead of requesting e.g. Tomcat 8.0.31, Tomcat 8.0.32, Tomcat 8.0.33, etc. every few weeks, you can simply request Tomcat 8.0.x or even Tomcat 8.x.
- Some components can be installed on various operating system platforms. Please specify the required platform in the version section e.g. IBM WebSphere Application Server 7.0.0.21 for Windows, Adobe Acrobat Reader for Apple macOS.
- Do not enter multiple versions in the field for one component. A new component for each individual version needs to be created e.g. the following entry with multiple versions is incorrect: Microsoft Windows 7, 8, 2010 Server. Three new component requests are required: Microsoft Windows 7, Microsoft Windows 8, Microsoft Windows 2010 Server.
- Do not use letters like "v" or "version" in the version field if the vendor of the component does not explicitly also use this naming convention. Also do not add additional comments or information which the vendor does not use in the version part e.g. self-compiled bug fixes.
- Relational characters such as
>
,<
,>=
,<=
are not allowed as this may result in an unclear component assignment. - It is possible to request beta versions, release candidates, etc., in the same manner as any other stable version. However, please note that often times, vendors do not disclose vulnerabilities affecting such versions. As such, using these types of versions might result in a loss of information that is made available for stable versions.
URL: Link to the vendor's page where information about the component can be found. Use the following guidelines for the URL field:
- URL should point to a page where it becomes clear that the requested component (ideally including its version) really exists. If you cannot find an official page for the desired component, it might be an indication that the component request does not make sense.
- It is usually not sufficient to just add a vendor's top level domain, for example, https://www.suse.com/products/server/ should be used instead of just https://www.suse.com/ for the component SUSE Linux Enterprise Server (SLES).
- Avoid using non-official vendor links, e.g. re-seller sites, Maven or npm links, etc.
Security URL: Link to a web page where component specific security information like security advisories or security bulletins can be found, e.g. https://www.suse.com/support/security/ for SUSE products.
Some vendors provide security information only to customers with active support accounts, without making it available to the public. If you request a component (or add one to your monitoring list) where this is the case, please contact us at svm.ct@siemens.com so we may find a way to access this information. Failing to do so will result in Vilocify monitoring only publicly available information for that component.
Comment: An optional free text field that allows users requesting a new component to add any information that might facilitate the correct processing of the request.
Submitting a Component Request¶
Once you have filled in all the mandatory fields you can submit the request form by clicking on "Submit". The requested component will not be immediately visible within the Vilocify Portal. Instead, the Vilocify team will analyze your request, determining whether a reliable vulnerability monitoring is possible with the provided information. Once the Vilocify team processed your request, you will be informed by email. If the component request was successfully processed, you will be able to find the corresponding component within our Vilocify Portal, ready to be added to your monitoring lists as needed. In cases where it was not possible to add the desired components you will be informed as well, including information about why it was not possible to successfully process your request. You are then free to reply, providing additional information / clarification.
The date on which a component has been added to the Vilocify service is marked in the "Monitored Since" field visible within the Vilocify Portal and the Vilocify REST API. Vulnerabilities published before the "Monitored Since" date of a component might not be assigned to a component, i.e. the Vilocify service does not currently offer retrospective monitoring. You can search for an older version or an "All versions" of that component within Vilocify. If all this does not help, you need to search the Internet.