-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug - Legacy Mend Parser - Locations - type character varying(4000) error #11340
Comments
@testaccount90009 Based on my reading of ☝️ especially the last paragraph, it seems like choosing to use
Having read the above and the Slack posts, I think it would be better to reduce the path to a size that fits the DB's 4000 varchar limit plus put the full details into something that can accept more data and doesn't tend to be used for deduplication. For example, you could remove characters off the front of the path until the path is within the DB limit - or you can get fancy and take off a few more characters so you can add If the length of path is > 4000
Additionally add the unmodified value of path to Finding's
This preserves data from the parsed file while:
|
@mtesauro hope your holidays went well! I think those are great suggestions and I will work to implement the Location in the steps_to_reproduce as mentioned. With the legacy SCA output it seems that a vuln can exist in multiple locations and adding to the 'Locations' does not cleanly map the comma separated values into something human readable in the UI. I'll work on a PR with the changes - at the same time I add SAST for the Mend Platform, now that I'm back from vacation. Thank you again for those suggestions! |
@mtesauro I have a PR I am working on that will fix the Locations and pass to steps_to_reproduce instead. This will likely be accompanied by Mend Platform SAST logic for the parser as well. I have a no finding, one finding, and many findings set of json files that have been scrubbed and I will provide those + unit tests after I figure out my GitHub errors for trying to fork / clone / check out the dev branch of DefectDojo. In that PR I will link this Issue + the Slack discussion, and tag you if it's ok. |
#11366 This issue / bug is what I described in my latest comment with encountering errors cloning the repo onto a Windows system. |
@testaccount90009 Yeah, sorry that that impacted you - as I noted in that issue, we've got a PR we'll merge and get in the next release. Sorry to delay you on your PR work. |
@mtesauro no problem sir, I appreciate you and team! I believe I can continue to address this now. You are rockstars, thank you! I should have a new PR submitted soon that I'll link here to fix the 4000 char limit and do something as you've mentioned. |
Slack - https://owasp.slack.com/archives/C2P5BA8MN/p1732583494245009
It's possible when getting Mend Legacy SCA JSON Project vulnerabilities from 1.4 API that Locations will contain many values and error out the Locations 4000 char limit based on the current join. I will make a slight change to the Mend parser that will hopefully reduce the likelihood of this happening.
If you check Mend unit test and scan files, you can see the difference between legacy and platform json schemas. Legacy consists of all Vulnerabilities with a Library as an attribute. Platform consists of all Libraries with vulnerabilities as an attribute.
This means that for Platform the Locations will not be the same style as Legacy Locations.
To confirm, I do not encounter the 4000 char limit error for Locations on Platform schema style imports - only the Legacy style.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
Upload the report
Deployment method (select with an
X
)Environment information
I will raise a PR to make the change that should solve this fix, but I welcome feedback from the community on the proposed change of 'path' to be replaced with 'dependencyFile' and this should impact only the Legacy parser.
However, instead of 'path' referencing the offending .jar file, it will instead reference the 'dependencyFile' which is typically build.gradle, as an example. When taking into consideration 'Vulnerabilities' in SCA and Direct vs Transitive inclusions -- this can be tricky. Technically the build.gradle is where the issue exists, but the vulnerability is in the offending .jar file.
The text was updated successfully, but these errors were encountered: