DryRun Security Summary

The patch improves the OSV scanner parser by enhancing vulnerability information extraction, input validation, mitigation details parsing, and adding comprehensive unit testing for security vulnerability tracking.

View PR in the DryRun Dashboard.

unittest_osv_scanner.log
unittest_test_parser.log

Sorry, here is the unittest test.
inittest_osv_scanner_new_pr.log

Could you also fix the ruff linter @4b75726169736859 ?

Could you also fix the ruff linter @4b75726169736859 ?

yes just after my work day

@4b75726169736859 This is looking great! Thank you! There are some linter errors, and the corresponding tests might need to be updated -- could you fix those? I think you solved a tricky problem well.

@4b75726169736859 This is looking great! Thank you! There are some linter errors, and the corresponding tests might need to be updated -- could you fix those? I think you solved a tricky problem well.

Of course, I’ll take care of it tomorrow if I have time; otherwise, in the following days.

I also have an issue with version management: to determine which version to fix based on the vulnerable version, I assumed the versions follow the x.x.x format, but they can be different.

This is a topic I need to address.

Thank you for working on this @4b75726169736859. I do have some concerns and a possible unpopular opinion.

I've recently done some work in Dependency Track where I had to handle all the different version constraints that the Composer ecosystem supports, such as -dev suffixes and dev- prefixes, versions based on branch names, etc.
See https://getcomposer.org/doc/articles/versions.md. When you look at the code of the Composer CLI it's almost impossible to follow what's going on and which regex matching has what outcome.

And that's just one ecosystem.

The risk is that we add code to Defect Dojo that is not 100% correct and may select the wrong fix version. Wouldn't it be easier and safer to just list all the fixed version ranges and let the user decide to which version he or she wants to update? Everything we add to DD has to be maintained and should have testcases. Sometimes it's better to keep it simple.

Glad to contribute to this project!

I have the same concern. Previously, I made a version that lists all the fixed versions, and it’s already ready.
I could replace the current version of the code with this one.

It’s true that I won’t be able to maintain this indefinitely, as it takes a lot of time.

I would have liked to bring this improvement to this parser.

It’s late here, I will most likely push my second, simplified version tomorrow.

Hi @4b75726169736859 I am going to close this out for right now, but please reopen it whenever you are ready 😄

Hi, sorry, I've been very busy...
It slipped my mind.

Here, I've made a few changes and pushed them to the fork.

Is it possible to reopen the pull request or do I need to create a new one?

Here's what it looks like.

Thanks 😊

@4b75726169736859 Thank you. Could you look at the Linting violations and update the unit tests to make them pass?

@4b75726169736859 Thank you. Could you look at the Linting violations and update the unit tests to make them pass?

Sure, no problem
I’ll be able to look at it on Monday ;)

This pull request contains potential security risks related to information disclosure through detailed vulnerability descriptions and possible URL injection vulnerabilities in reference handling, which could provide attackers with system insights or opportunities for link manipulation.

All finding details can be found in the DryRun Security Dashboard.