Skip to content

new parser ReversingLabs Spectra Assure #12476

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

Conversation

rl-maartenb
Copy link

Description
New parser for ReversingLabs Spectra Assure

Test results
unit tests exist

  • data in unittests/scans/reversinglabs_spectraassure/*
  • test in: unittests/tools/test_reversinglabs_spectraassure_parser.py

Documentation
Documentation added in

  • docs/content/en/connecting_your_tools/parsers/file/reversinglabs_spectraassure.md

Copy link

dryrunsecurity bot commented May 19, 2025

DryRun Security

This pull request reveals multiple potential security and performance risks in the ReversingLabs SpectraAssure parser, including information disclosure vulnerabilities, lack of input validation, potential JSON injection risks, and unhandled exceptions that could compromise the application's reliability and security.

💭 Unconfirmed Findings (9)
Vulnerability Potential Information Disclosure in Duplicate Finding Handling
Description In the ReversingLabs SpectraAssure parser, the _find_duplicate method returns the entire duplicates dictionary, which could potentially expose unnecessary finding information. This poses a risk of unintended information disclosure.
Vulnerability Lack of Input Validation in Hash Generation
Description The parser directly encodes and hashes input strings without proper sanitization or length validation, which could lead to performance issues and potential security vulnerabilities.
Vulnerability Unrestricted Finding Creation from External Data
Description Finding objects are created directly from external JSON data without validation, which could potentially allow malicious JSON injection and compromise the application's security.
Vulnerability Potential Information Disclosure via Logging
Description Extensive logging in the rlJsonInfo module might expose sensitive details about file paths, components, and vulnerability metadata, presenting a potential information disclosure risk.
Vulnerability Unhandled Exception in JSON Serialization
Description An unhandled exception in the serialization method could lead to unexpected application termination, potentially disrupting the parsing process.
Vulnerability Environment Variable Configuration Risk
Description The environment variable for garbage collection could potentially be manipulated, which might impact memory management and system performance.
Vulnerability Potential Type Annotation Error
Description Erroneous type annotation in the cve_info_node.py file could cause type checking or runtime issues during the parsing process.
Vulnerability Potential Unnecessary Iteration Over Empty Findings List
Description The test method contains unnecessary code execution when iterating over an empty findings list, which could impact test performance and clarity.
Vulnerability Hardcoded Test Expectations
Description Hardcoded test expectations in the unit tests could potentially mask parsing issues and reduce the effectiveness of the testing process.

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

@valentijnscholten
Copy link
Member

Thank you for the PR @rl-maartenb !

Could you take a look at the commit messages? They seem to have "Your Name" as author, which looks like there's something off?

Could you also take a look at the additional info on the unique_id_from_tool field in #12463? I wonder if the component: and dependency: prefix are really necessary?

@rl-maartenb
Copy link
Author

rl-maartenb commented May 20, 2025

Regarding: Could you take a look at the commit messages? They seem to have "Your Name" as author, which looks like there's something off?
yes that is an error on my side the proper .gitconfig for this tree was not used, also as i struggled to get the pr to pass the ruff linter i added some messy commits, all with the wrong email and identity, i will revoke the pr and make a fresh one with the proper email, when i am back next week. ( I will be in the Netherlands on a short holiday starting tomorrow. )

Regarding: Could you also take a look at the additional info on the unique_id_from_tool field in https://github.com/DefectDojo/django-DefectDojo/pull/12463? I wonder if the component: and dependency: prefix are really necessary?
Your feedbak is very helpfull, i will rework the unique id so that it actually become repeatable (the same) on every scan, currently it uses out internal uuid but that is different for each scan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants