OSV Scanner Remediation Feature

Skip to first unread message

Khai Tran

Nov 22, 2023, 1:10:35 PM11/22/23
to osv-d...@googlegroups.com, khaitranviet

I work for the Security Assurance team at Snap, and we are looking to beef up our dependency security story. We're evaluating potential vendors in this space, and came across this item in the OSV scanner roadmap: https://github.com/google/osv-scanner/issues/352. The last update about npm patching looks promising!

At Snap, we're evaluating open-source and commercial vendors for it. So we'll also be happy to help out with beta testing at scale (we have npm, gradle, pypi dependencies), or with development tasks to push this forward.


Oliver Chang

Nov 22, 2023, 11:33:48 PM11/22/23
to Khai Tran, osv-d...@googlegroups.com, khaitranviet
Hi Khai,

Thanks for reaching out! We are hoping to release https://github.com/google/osv-scanner/issues/352 early next year. Did you have any particular questions or comments about this? 

And generally, what kind of dependency security solutions are you looking for? We would also absolutely welcome collaboration to help push forward features, as all of our tools are completely open source. 


You received this message because you are subscribed to the Google Groups "osv-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-discuss/CAA_6P5w0xejxzdFWm2bJUAz%3Dm_-b-Cf5jN%2B9G%2B2UVPEV0ReoGA%40mail.gmail.com.

Khai Tran

Nov 27, 2023, 5:57:23 PM11/27/23
to Oliver Chang, osv-d...@googlegroups.com, khaitranviet
Hi Oliver,

Thanks for getting back to me. We're looking at tools that can help us generate pull requests for certain triaged vulnerabilities (could be based on EPSS or CVSS score, or require human judgement). Developers can see which tests/build errors are failing and fix them, otherwise just review & merge. We think this will help us maintain healthy patching pipelines for our projects. If that's successful, then we'll look at lowering the threshold for auto-patching.

If you folks are working on an experimental branch for npm or have beta versions, we'd love to try it out! For now we're evaluating if the solution:
  • requires build tools (npm, mavn, pip) to detect transitive dependency, and generate new lock files. This is helpful to determine if the patch generation can be run anywhere, or has to be run in the existing project's CI/CD pipeline to avoid build breakage
  • can provide structured output (which osv-scanner has) to parse/chain additional workflow
  • has flexibility in terms of choosing patching parameters. So far we've determined there are a few strategies we'd like to pursue:
    • direct version upgrade (similar to in-place lock file modification in your latest comment)
    • direct + transitive version update (similar to direct dependency bumps)
    • force version update/downgrade (specific to gradle, useful for when one of transitive dependency cannot be updated)
    • direct version downgrade/removed (in case of typosquatting or malware)

Reply all
Reply to author
0 new messages