Show whether dependency is transitive

[theinfosecguy]

Is there a way we can find if a dependency is transitive or not?

[oliverchang]

Hi! Can you please elaborate?

Do you mean a boolean flag of some source in our JSON output indicating if a vulnerability is in a direct dependency or not?

[HarelMil]

@theinfosecguy +1 @oliverchang In my opinion it would be great not just to outline as boolean whether it is a direct or transitive, but to indicate the depth of the dependency tree. This will be very useful for mitigation strategy (direct or low depth can be better influenced than a deeper depth).

[theinfosecguy]

@oliverchang Not just a boolean flag but a vulnerable function and dependency tree as well. Is there a way to achieve this?

[oliverchang]

That certainly sounds doable. Sounds like what we'd like here is some output that indicates the vulnerable dependency chain that led to a finding (including function level info if we have that)?

[theinfosecguy]

Thanks, @oliverchang!! Having a check for direct dependency would be an amazing feature.

[agmond]

That certainly sounds doable. Sounds like what we'd like here is some output that indicates the vulnerable dependency chain that led to a finding (including function level info if we have that)?

@oliverchang I'd be very happy to see the chain of packages that led to a finding!

[oliverchang]

With the deps.dev API becoming open and available, this could be potentially a lot easier for us to implement now!

[oliverchang]

To track the concrete FR: this is around adding some ability to visualise the dependency chain(s) that leads to a vulnerable package. This could be either output as a JSON, and/or visualised as a graph image.

@theinfosecguy @agmond @HarelMil can you talk about a bit more about how you plan to use the dependency trees this would potentially generate? This would help us a bit more in prioritising/shaping how this actually looks.

(https://github.com/google/osv-scanner/issues/352 may also be interesting for folks in this thread to follow).

[agmond]

Thanks @oliverchang. Yesterday I already started exploring deps.dev as well.

As for my use case (and it connects to the remediation efforts as well): Currently, OSV-Scanner scans lock files (e.g. package-lock.json), which are auto-generated files, and marks some sub-dependencies as vulnerable. I want to connect the vulnerable sub-dependency to the root of the tree (i.e. to the package that appears in the package.json file), and then raise an alert on the relevant line in the package.json file (which is the file where the root cause of the vulnerability was introduced, and this is the place that should be edited to remediate the issue).

Another relevant issue I opened is https://github.com/google/osv-scanner/issues/150

[HarelMil]

@oliverchang Sure.

TL;DR - Direct/indirect and dependency depth are great indicators for prioritizing vulnerable package remediation processes at scale.

Dependency depth will be an excellent indication for understanding the possibility of patching the vulnerable package, which will affect the priority of addressing the specific vulnerable package.

Applying a fix (if available) is easy and straightforward when it is a direct package, but for indirect packages, it is a different story.

If the depth is relatively "shallow" the probability of applying a fix by contacting the chain of package maintainers is doable. However, when the depth is deep, the probability to apply an actual fix decreases significantly.

When you have a significant amount of vulnerable packages, it may be a great help.

[agmond]

Hi, Is there any update on this issue? Thanks!

[oliverchang]

Hi @agmond, thanks for the continued interest. We're actively working on this as part of #352. We'll have more to share in the coming months!

[agmond]

Thank you, @oliverchang. Can this feature (returning the dependency chain(s) that leads to a vulnerable package) be released as soon as it is ready, even before the full remediation feature?

[oliverchang]

Sorry for the slow response. The dependency chain feature is closedly tied to the full remediation feature, which we're actively working on. We're working through the necessary steps to release such a feature, because it involves a bit of coordination with the deps.dev team.

[oliverchang]

For folks following here, check out https://github.com/google/osv-scanner/issues/352#issuecomment-1820008675 which this feature is closely related to.

Transitive dependency depth is one of the capabilities that will be added as part of the guided remediation feature we're aiming to launch Q1 next year. Sorry for the delays!

[github-actions[bot]]

This issue has not had any activity for 60 days and will be automatically closed in two weeks