Remove DebugPy

[Maffooch]

With the recent fiasco around missing pypi images for debugpy that broke out build/testing automation, an opportunity was created to evaluate if we wanted to support this behavior anymore

[sc-7129]

[dryrunsecurity]

DryRun Security Summary

The pull request covers various security-focused changes to the DefectDojo application, including the removal of remote debugging, updates to the development environment configuration, dependency management, and improvements to the Kubernetes deployment instructions.

Expand for full summary

Summary:

The code changes in this pull request cover various aspects of the DefectDojo application, including the removal of remote debugging functionality, updates to the development environment configuration, dependency management, and improvements to the Kubernetes deployment instructions.

From an application security perspective, the key points are:

1. Removal of Remote Debugging: The removal of the remote debugging functionality in the Django WSGI application is a positive change, as it reduces the potential attack surface and security risks associated with remote debugging.

2. Development Environment Configuration: The changes to the development environment configuration, such as stricter Python warnings, enabling debugging, and the use of default admin credentials, should be carefully reviewed to ensure that sensitive information is not exposed and that default credentials are not used in production.

3. Dependency Management: The updates to the project's dependencies, including the cryptography library, indicate that the team is actively maintaining the application's security posture by keeping dependencies up-to-date.

4. Kubernetes Deployment: The changes to the Kubernetes deployment instructions, such as the use of Kubernetes secrets for sensitive information and the option to enable TLS/HTTPS, demonstrate a focus on secure deployment practices.

Overall, the changes in this pull request appear to be security-focused, with the removal of remote debugging, improved dependency management, and secure Kubernetes deployment practices. However, it's important to thoroughly review the changes and ensure that any potential security implications are addressed before merging the pull request.

Files Changed:

1. dojo/wsgi.py: The changes remove the remote debugging functionality, which is a positive security improvement.
2. readme-docs/DOCKER.md: The changes simplify the documentation around remote debugging, which is a reasonable improvement.
3. docker/setEnv.sh: The script could benefit from additional security considerations, such as input validation and better handling of potential privilege escalation issues.
4. docker-compose.override.dev.yml: The changes focus on the development environment configuration, with potential security implications around debugging and default admin credentials.
5. requirements.txt: The changes indicate that the project is actively maintaining its dependencies, which is a good security practice.
6. readme-docs/KUBERNETES.md: The changes focus on secure Kubernetes deployment practices, such as the use of Kubernetes secrets and the option to enable TLS/HTTPS.

Code Analysis

We ran 9 analyzers against 7 files and 1 analyzer had findings. 8 analyzers had no findings.

Analyzer	Findings
Sensitive Files Analyzer	1 finding

Riskiness

🟢 Risk threshold not exceeded.

View PR in the DryRun Dashboard.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[mtesauro]

Approved

[kiblik]

Out of curiosity, may I know what was the fiasco? I haven't noticed any.

I use debug mode in docker-compose quite often during development. Not exactly debugpy but environmental variables used in docker-compose.override.debug.yml.
If you are removing docker-compose.override.debug.yml, may I ask to set PYTHONWARNINGS to error and DD_DEBUG to 'True' in all containers in docker-compose.override.dev.yml as it was set in docker-compose.override.debug.yml? Because dev will become the main development environment now.

[mtesauro]

@kiblik

Out of curiosity, may I know what was the fiasco? I haven't noticed any.

Perfectly reasonable to ask why - no problem.

The thing that happened earlier this week (Monday) and has happened several times in the past is:
(1) debugpy releases an update - can be a minor version bump (1.8.4 in the most recent cast) or release an update only for one architecture (arm64)
(2) Dependabot notices the update and does a PR, we merge it to dev
(3) debugpy yanks the release and the version disappears (this is what happened to 1.8.4). Sometimes they release a new one, sometimes the fall back to the old version. In Monday's case, 1.8.5 came out late on Tuesday (something like that)

Between 2 and 3 a dev tool not used directly by DefectDojo "the app" breaks building our containers and a bunch of GH Actions.

Since it was a dev thing that was breaking container building in GHA, we decided to yank it and have people manually install it if they used it.

I'm very willing to explore other options as long as they don't break GH Actions and accommodate people who don't use debugpy. In my and @Maffooch 's case, we didn't mind setting up debugpy manually when we needed it but I can see how that would be painful if you used it regularly.

Got any suggestions?

[kiblik]

@kiblik

Out of curiosity, may I know what was the fiasco? I haven't noticed any.

Thank you for the explanation

Got any suggestions?

I support the idea of dropping it and if somebody needs some deep troubleshooting, it is happening usually locally so anybody can add it ad-hoc.
Same idea (with dropping it) came to my mind when I added ruff T10. But I just "fix" it with noqa at that moment.

[Maffooch]

If you are removing docker-compose.override.debug.yml, may I ask to set PYTHONWARNINGS to error and DD_DEBUG to 'True' in all containers in docker-compose.override.dev.yml as it was set in docker-compose.override.debug.yml? Because dev will become the main development environment now.

Happy to do so, and great call 😄

[kiblik]

As I see changes from #10612, I just realized, that

django-DefectDojo/readme-docs/KUBERNETES.md

Lines 165 to 173 in 51cea97

	### Debug uWSGI with ptvsd
	You can set breakpoints in code that is handled by uWSGI. The feature is meant to be used when you run locally on minikube, and mimics [what can be done with docker-compose](DOCKER.md#run-with-docker-compose-in-development-mode-with-ptvsd-remote-debug).
	The port is currently hard-coded to 3000.
	* In `values.yaml`, ensure the value for `enable_ptvsd` is set to `true` (the default is `false`). Make sure the change is taken into account in your deployment.
	* Have `DD_DEBUG` set to `True`.
	* Port forward port 3000 to the pod, such as `kubectl port-forward defectdojo-django-7886f49466-7cwm7 3000`.

might be removed as well.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[Maffooch]

Good catch. Removed

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[fopina]

just got past this one and !devcon would have helped restore a debug environment without having yet another compose override 😄