The chat responses are generated using Generative AI technology for intuitive search and may not be entirely accurate. They are not intended as professional advice. For full details, including our use rights, privacy practices and potential export control restrictions, please refer to our Generative AI Service Privacy Information. As this is a test version, please let us know if something irritating comes up. Like you get recommended a chocolate fudge ice cream instead of an energy managing application. If that occurs, please use the feedback button in our contact form!
Skip to content

Frequently asked questions

What's Vilocify?

The Vilocify Service constantly monitors a broad amount of information sources to discover and report new security vulnerabilities and corresponding security patches for a wide range of software and hardware components. You'll find more information about Vilocify in its Service Description page.

I didn't find the component I'm looking for in Vilocify Portal. What am I expected to do?

First, use the component search available in the Components tab in Vilocify Portal and search for different names your component might be also known as. It may help to search only for the name of the component and leave out the vendor name. For example, don't type github but only the name of the GitHub project you are looking for. If you don't find the component at all or the specific version is missing use the request form to request a new component. More information about component requests can be found in the Requesting a New Component page. It may take some days before your request is completed because every single request is manually verified. Once your component request is processed, you will be notified by email.

Can I add a wildcard component to my monitoring list?

Yes, we do have wildcard components that allow you to monitor a wide number of versions without the need to specify each version separately. Consider the following examples:

  • By adding Debian 11.x to your monitoring list you will receive all security advisories for Debian 11, without having to specify single update levels.
  • Adding Apache Tomcat 8.x allows you to install security updates of your Tomcat server without having to continuously update your list.
  • If you want to monitor Windows Server 2008 R2 regardless of its service pack level, you can use the component Microsoft Windows Server 2008 R2 All Versions.

Can I monitor "All Versions" of a specific component?

Yes, in most cases all versions of a component can be monitored. To monitor all versions of a certain component you can request the component with version "All Versions" through the request form in case it doesn't already exist in the Vilocify component catalog. "All Versions" components can reduce the effort of maintaining your monitoring lists, because you don't have to update the "All Versions" components on your list when new versions are used in your project. However, you might receive a larger number of less relevant notifications, since you will also receive notifications for versions that you might not be using. If the components on your monitoring list are relatively static, it might be better to use components in specific versions.

Why are Linux distribution packages and OpenShift container images only available in "All Versions?"

Generally, distributions only support the latest version of packages, and packages are updated frequently. Additionally, due to software dependencies, updating single packages/images is often not possible. As a result, most users usually take an interest in the latest version of a distribution package or a container image. Therefore, using "All Versions" avoids having to constantly update your monitoring lists. Don't worry if your package/image component wasn't mapped to the specific version, you will still receive relevant security notifications.

Tip

Linux distribution packages are available (or can be requested) for a specific distribution version, for example Debian 9 Package: bash, RHEL 8 Package: openssl, Ubuntu 22.04 Package: apache2, etc.

OpenShift container images are available (or can be requested) for a specific distribution version, for example OpenShift Container Image: rhel8/postgresql-12, OpenShift Container Image: lvms4/lvms-operator-bundle, OpenShift Container Image: odf4/odf-must-gather-rhel9, etc.

If you are monitoring the generic distribution packages without a distribution version like Debian Package: bash, RHEL Package: openssl, or Ubuntu Package: apache2, expect to receive more irrelevant notifications.

I want to receive security notifications for my Linux distribution. Do I need to add all the packages one by one?

No, there is no need to add single Linux packages to your monitoring list. For all the major versions, you should be able to find a component representing the distribution in its entirety. Examples for such components are:

Adding such components implies that you will receive all security advisories for the distribution, without having to specify single packages. If you can't find the desired Linux distribution, please feel free to request a new component.

I don't have time to maintain a monitoring list. What are my options?

As we publish over 15000 notifications every year, we strongly recommend creating and properly maintain monitoring lists with the desired components, in order to be notified only about security issues relevant to you. With usage of wildcard components, the required efforts should be minimal. If nonetheless this option isn't viable for you, there area few possible alternatives:

REST API: For advanced use cases, we offer a REST API which allows to retrieve information about components, monitoring lists, and notifications. For more details as well as a thorough documentation, please consult the REST API page.

Is there any kind of automation possible?

Yes, there is the Vilocify REST API available for automation.

A component I need to monitor has security-relevant information only in a protected customer area. How does Vilocify deal with that?

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 an existing one to a monitoring list) where this is the case, please open a ticket in our Support Portal 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.

Why is the CVSS base score for a CVE in a notification different from the National Vulnerability Database?

Vulnerabilities of notifications are scored in the context of the components that are assigned to a notification. Therefore, we preferably rely on the analysis of the actual vendor of a component instead of NVD. And a vendor sometimes scores the vulnerability differently than the original upstream CVSS of NVD (for example, a distribution package might use non-default compiler flags or non-default configuration of a component).

When will you provide CVSS version 4.0?

The Forum of Incident Response and Security Teams (FIRST) has officially announced CVSS version 4.0, the next generation of the Common Vulnerability Scoring System standard.

As of October 2024, SVM supports CVSS version 4.0. Vulnerability notifications in SVM will display CVSS version 4.0 for its vulnerabilities through both our Portal and service's API.

Note

We anticipate an industry-wide adoption of the latest version of the CVSS standard. To facilitate a smooth transition, our service will undergo an adaptation period until the end of October 2025. During this time, our notifications will include both CVSS version 3.1 and CVSS version 4.0 vectors fields. After the adaptation period, we will provide the CVSS version published by vendors.

Why do you not share the impact of a notification?

With the introduction of CVSS 4.0, our methodology for communicating vulnerability impact has evolved.

Previously, under CVSS 3.1, we derived and shared specific "impact" statements (for example, "Exposure of Sensitive information") based on direct interpretations of vector metrics, for example as the Confidentiality not set equal to None.

CVSSv4 makes the distinction between "vulnerable" and "subsequent" system impacts (in favor of the CVSSv3 Scope: Changed/Unchanged). Consequently, we no longer provide generalized "impact" categories as previously shared. The understanding of a vulnerability's potential effects is now captured and communicated through the CVSS 4.0 metrics themselves.

The vendor doesn't provide a CVSS version 3.¼.0. However, SVM notification includes both. How's the conversion done?

During the adaptation period between CVSS version 3.1 and CVSS version 4.0 standards, SVM will provide CVSS version 3.1 scores even when vendors only supply CVSS version 4.0. In such cases, SVM analysts evaluate the vulnerabilities and adapt the CVSS version 4.0 metrics to generate corresponding CVSS version 3.1 scores. This approach ensures consistency in the assessment and prioritization of vulnerabilities and security notifications by maintaining a common scoring system.

What's the difference between the packages available for purchase for Vilocify for customers outside of Siemens?

If you are a Siemens colleague, reach out to us for an agreement for vulnerability monitoring of your projects or product development. For our external customers, see the MLFB structure in the Service Description.

Who can I contact if I've additional questions not answered here?

  • Patch Installation issues: Contact your vendor support
  • For questions related to Vilocify, please open a support ticket.
  • If you are unsure whom to contact, feel free to contact us. We will forward your inquiry to the appropriate address if necessary.