4 ms·

It might sound like nitpicking but I find it dangerous to say vulnerability == CVE. CVEs are one source of information about potential vulnerabilities but they

It might sound like nitpicking but I find it dangerous to say vulnerability == CVE. CVEs are one source of information about potential vulnerabilities but they are amongst the least reliable these days. I've heard them being called Curriculum Vitae Enhancer. And Trivy itself uses more sources than just CVEs as well. With upcoming regulation like the Cyber Resilience Act we'll get even more sources of vulnerabilities. I believe the future will be/should be one of distributed sources for this information. Every vendor might want to be their own authoritative source of vulnerabilities. This is a long way of saying: Useful tool, congratulations on the launch! I'd suggest a change of name as you limit yourself with the current one.

heads 3y ago
(Not the author.) I’ve only really encountered CVEs when they have been mentioned on patches, usually Debian security updates. Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed? If action is required to be taken when vulns are published do we all have to just uninstall the thing until the bug gets fixed, lest we invalidate our corporate insurance policy? Will I have to cease my current policy of running Trivy, reading the CVE output, and then declaring (and making a git commit saying) “while this stdlib library technically supports CORBA and our OS technically supports IPX, we don’t use CORBA or IPX… or networking… or this library… so I’m ignoring this!”
- kylequest 3y ago
  Quite a few vulnerabilities don't have CVEs. You can find some of them in the Github Security Advisories.
- lars_francke 3y ago
  I'm not sure if you're replying to the correct thread? All I'm saying is that all CVEs are supposed to be vulnerabilities but not all vulnerabilities have a CVE. So, the name artificially limits the scope of the product. Trivy reports more than just CVEs
  - heads 3y ago
    It was directed at you as you seem to know what you are talking about!
    - lars_francke 3y ago
      I have been tangentially involved in the Cyber Resilience Act (CRA). I'm more an interested party than a real expert. We recently wrote a document on how we would like to approach our own vulnerability management process. It received a lot of comments and we'll gladly take more: https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlEEYV_Y-hfM8_SGKjGNz0 https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlE... To answer your questions then :) > Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed? Not all vulnerabilities get a patch, it's really up to the project. But this is what the CRA is about. In the commercial context it will require vendors to handle vulnerabilities by e.g. providing patches. And depending on which industry you are in you might also be required to install said patches. > If action is required to be taken when vulns are published do we all have to just uninstall the thing until the bug gets fixed, lest we invalidate our corporate insurance policy? I doubt it but it's a good idea to have a good overview of what you're running in your company. This extends to dependencies which might be included in things you're running. That is what SBOMs are meant for. They will be required in the future. > Will I have to cease my current policy of running Trivy, reading the CVE output, and then declaring (and making a git commit saying) “while this stdlib library technically supports CORBA and our OS technically supports IPX, we don’t use CORBA or IPX… or networking… or this library… so I’m ignoring this!” No. That is excellent! It will be formalized into a machine readable format. Currently often called a VEX statement: Vulnerability Exploitability Exchange. One popularish format for this is CSAF. But CycloneDX (an SBOM format) can also be used for this. Having this in a machine readable format makes it easier for users to consume the information. The tooling for this is not great yet, which is what our document above is about. Hope it helps. Happy to chat about this if you're interested. Reach out if you like. Details should be in my profile.
      - beardedwizard 3y ago
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]

heads 3y ago

(Not the author.) I’ve only really encountered CVEs when they have been mentioned on patches, usually Debian security updates. Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed? If action is required to be taken when vulns are published do we all have to just uninstall the thing until the bug gets fixed, lest we invalidate our corporate insurance policy? Will I have to cease my current policy of running Trivy, reading the CVE output, and then declaring (and making a git commit saying) “while this stdlib library technically supports CORBA and our OS technically supports IPX, we don’t use CORBA or IPX… or networking… or this library… so I’m ignoring this!”

kylequest 3y ago
Quite a few vulnerabilities don't have CVEs. You can find some of them in the Github Security Advisories.
lars_francke 3y ago
I'm not sure if you're replying to the correct thread? All I'm saying is that all CVEs are supposed to be vulnerabilities but not all vulnerabilities have a CVE. So, the name artificially limits the scope of the product. Trivy reports more than just CVEs
- heads 3y ago
  It was directed at you as you seem to know what you are talking about!
  - lars_francke 3y ago
    I have been tangentially involved in the Cyber Resilience Act (CRA). I'm more an interested party than a real expert. We recently wrote a document on how we would like to approach our own vulnerability management process. It received a lot of comments and we'll gladly take more: https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlEEYV_Y-hfM8_SGKjGNz0 https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlE... To answer your questions then :) > Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed? Not all vulnerabilities get a patch, it's really up to the project. But this is what the CRA is about. In the commercial context it will require vendors to handle vulnerabilities by e.g. providing patches. And depending on which industry you are in you might also be required to install said patches. > If action is required to be taken when vulns are published do we all have to just uninstall the thing until the bug gets fixed, lest we invalidate our corporate insurance policy? I doubt it but it's a good idea to have a good overview of what you're running in your company. This extends to dependencies which might be included in things you're running. That is what SBOMs are meant for. They will be required in the future. > Will I have to cease my current policy of running Trivy, reading the CVE output, and then declaring (and making a git commit saying) “while this stdlib library technically supports CORBA and our OS technically supports IPX, we don’t use CORBA or IPX… or networking… or this library… so I’m ignoring this!” No. That is excellent! It will be formalized into a machine readable format. Currently often called a VEX statement: Vulnerability Exploitability Exchange. One popularish format for this is CSAF. But CycloneDX (an SBOM format) can also be used for this. Having this in a machine readable format makes it easier for users to consume the information. The tooling for this is not great yet, which is what our document above is about. Hope it helps. Happy to chat about this if you're interested. Reach out if you like. Details should be in my profile.
    - beardedwizard 3y ago

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]