Include attribution for known security vulnerabilities

[ethcryptodev]

Very quick question:

Some script on my site https://www.lockebridge.com is throwing a Medium severity Best Practices penalty for using a vulnerable library version of Bootstrap (3.3.7) when ran through Lighthouse. I need to know how to easily find out what script or asset is at fault that is using this library so I can update the offending plugin or theme code.

As a feature request, it would be nice if Lighthouse provided the name and reference in the results to the offending script that is being called which is using the vulnerable library throwing the penalty as a column and result. I would argue a direct reference to the offending script is of much greater significance to users as a displayed result to help fix the problem than the vulnerability count column if one had to choose between these two.

Any help would be tremendously appreciated!

[patrickhulce]

Thanks for filing @strayangelfilms!

Just as an FYI, it's highly unlikely that we'll be able to do this anytime soon. Detecting the library usage is done via global scope inspection currently, and we have no clue what specific script touched global scope to make it that way. The developer is the person in the best position to know which of their scripts it could have come from.

AFAICT, bringing this functionality to LH would require a total rewrite of the library detection (which is currently done by a 3P library) to examine source code/track stacks/something fancy it doesn't do currently.

[ethcryptodev]

@patrickhulce Thank you for exploring this in detail, it is much appreciated.

For many sites or apps where they're literally custom coded by a dev actually compiling scripts and their root libraries, obviously this isn't necessary, but for 50% of the web running on WordPress or a CMS that are now using Lighthouse to score ranking / SEO / performance, any tool that can help figure out what script has called the vulnerable library would be a godsend so individual theme / plugin / component updates can be easily assessed and appropriate remediation applied.

[rockeynebhwani]

@strayangelfilms / @patrickhulce - Is it not possible to use something like this - https://retirejs.github.io/retire.js/?

[patrickhulce]

Would you mind elaborating on how that would help @rockeynebhwani? We already have the same functionality to identify the vulnerabilities themselves, this issue is requesting specifically how they got onto the page, which AFAICT is not solved by any of these in a web context.