I had rather to have automatic scanning within a defined planning (nearly as proposed at this time) but with the possibility to have a manual scanning, eg to verify if an update is safe.

This would be awesome. I believe that we already have some preliminary support for this in the agent, but we did not at all explore the data availability. So this one is on hold for now. But feel free to keep this thread updated with info about this and by all means remind us again around the end of the year

Updates for drivers is a very important feature! Where users can go to any app website and download and install a new version, for drivers this is a bit more complicated. Users have to search for the correct driver (correct hardware, correct OS, correct version like x64 or x32). Even I have problems doing this (so I don't investigate the time) and I would estimate my skills to quiet well. Next driver updates increase the stability of the system, increase the security and also offer new features. So in my opinion a driver scan is a very important feature!

@Tom: Glad that you like my idea. If you plan to implement it in the far future then I will move my posting and your reply to a separate topic in Suggestions.

@OLLI_S This is not exactly what you suggested, but there should be some overlap. In the VulnDetect we have added a new feature which allows us to "flag" Rules, Channels or Products. One of these flags is "Testing". Just to show the concept I've added the "Testing" flag to SecTeer CARMA - the EoL one. If you expand the row you can see that this is "Testing". "Testing" Rules are currently shown for all users, but the idea is to make this configurable. As we go through the rules we will add this flag to Rules / Products that we don't detect correctly yet. This is different from the "Untracked" flag that you unfortunately will see for products such as Opera and Vivaldi who don't release consistent security bulletins. The "Testing" flag is currently being, well, tested, so we may change the concept slightly at some point, but basically this is similar to "Under Review". So this is not a replacement for the "?", which indicates that we need to add a Specific Rule, because we for some reason don't extract a correct version number automatically.

The VulnDetect supports this, kind of. Some Rules has been updated and does show a "Recommended" version, even if the version you got isn't flagged as insecure or EoL. Right now we use the word "Recommended" in both cases. This will be changed, so that Insecure and EoL triggers "Recommended". And a different installed version than the latest known version from the vendor, will say "Suggested". When you see that the version we "Suggest" or "Recommend" is older or different from the one you just installed or updated to, then you are most welcome to send us a chat message, write a short message here on the forum or simply wait a day. We are (in most cases) "alerted" automatically when you have a newer version and it ends up on our automatic "to do list". Normally, these new or unknown versions are updated / added within a day, but feel free to ping us if you are impatient to have a Rule updated.

@tom No issue with IPV6 as far as I can see. IP adresses of systems on my personal LAN are reported using IPV6. Glad to see a product which does not prefer reporting IPV4 when both stacks are active. Regards.

@tom said in Create Log-Folder before Scanning: This is scheduled to be changed in one of the next two upcoming releases Glad that you want to fix this...

IE/Windows, Chrome, Firefox are using different proxy settings. Sometimes the proxy which should be used by browsers restricts the access to the internet (company policy). In this case applications has to use another proxy. So this feature is useful.

The intention is that after an installation users get a warning when there are known vulnerabilities. No matter how this is implemented. Think about the following scenario: A user installs the current version of an application (like web browser), but the application has vulnerabilities. The daily VulnDetect will start in some hours. Now the user browses in the web and gets infected or hacked (the vulnerability is abused). And after that he can see in the list of installed applications (in VulnDetect) that this software has vulnerabilities. So the user will be very upset, because VulnDetect does already know about the vulnerability but did not warn him in time! This could really be a problem for VulnDetect.

We do, we just didn't get around to that yet. We have a long list of stuff to do before we make that