Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Incorrect Vulnerability Assesment for versions later than specified in description



  • I saw in Inedo that PGV-2330205 and PGV-2425402 are applied to 'all' version of SheetJS
    https://security.inedo.com/vulnerability/details/PGV-2330205 and https://security.inedo.com/vulnerability/details/PGV-2425402

    While as per descriptions in both articles, if you already use version 0.19.2 (or later) for PGV-2330205 and 0.20.2 (or later) for PGV-2425402, the vulnerabilities are supposed to be fixed already, but the package in my Proget server is still displaying vulnerabilities , specifically in my case in version 0.20.3 . I know how to suppress them for entire versions of SheetJs but I think this probably should be addressed for inedo for everyone. I do not know if it is possible to suppress for just specific package or package version, ideally matching SemVer.

    Also note that previously I tried to use expiration for reassessing vulnerability and it seems it is unable to set the expiration and it was complaining about time format.


  • inedo-engineer

    Hi @aristo_4359 ,

    This will happen from time to time and there's no great solution to fixing it.

    The underlying issue is simple actually; the source data is incorrectly coded, and systems like PGVD that rely on that will display incorrect results.

    Since sources routinely update data (and they may fix this... if you ask), PGVD will also update the ingested data. So it becomes quite complicated to try to "override" incorrect data, even though it's so obvious from reading the description and looking at it.

    Without getting into too many details, here is how they encoded this at the source:

    "database_specific": {
       "last_known_affected_version_range": "< 0.19.3"
    }
    

    Compare this to another vulnerability at the same source, and you will see this is the correct encoding:

    {
       "last_affected": "2.0.13"
    }
    

    Given the infrequency that this happens, and the fact that it's an old, low-risk vulnerability (we would rate this as a "2 out of 5" on our upcoming scale FYI), we don't think it's worth worrying about.

    Thanks,
    Alana


Log in to reply
 

Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation