-
Notifications
You must be signed in to change notification settings - Fork 1.8k
push_to_jira: fix pushing to JIRA during import/reimport in asynchronous mode #13916
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
push_to_jira: fix pushing to JIRA during import/reimport in asynchronous mode #13916
Conversation
|
This pull request logs the full DRF serializer
Information Disclosure via Debug Logging in
|
| Vulnerability | Information Disclosure via Debug Logging |
|---|---|
| Description | The code logs the entire context dictionary at the debug level. In a Django REST Framework (DRF) environment, this context typically contains the DRF request object. When the request object is converted to a string for logging, it includes all request headers, which results in the sensitive Authorization header (containing API keys or JWTs) being written to the application's debug logs. |
django-DefectDojo/dojo/api_v2/serializers.py
Lines 2284 to 2287 in ec2c764
| logger.debug(f"process_scan called with context: {context}") | |
| start_time = time.perf_counter() | |
| importer = self.get_importer(**context) | |
| context["test"], _, _, _, _, _, _ = importer.process_scan( |
All finding details can be found in the DryRun Security Dashboard.
mtesauro
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved
added significant changes to the PR
mtesauro
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved
b3049f9
into
DefectDojo:bugfix
Findings weren't pushed to JIRA during import/reimport when postprocessing was happening in the background (default behaviour, unless
block_executionwas set toTrue). Bug was introduced in 2.53.0.This was not caught by our unit tests as these run in synchronous mode.
During debugging I added some logging helpful for troubleshooting, let's leave that in place for now via this PR.