Fix product.html column sizing with autoWidth: false. Same as here https://github.com/DefectDojo/django-DefectDojo/pull/13835

[testaccount90009]

Same as this PR, just in the product area instead of findings. The formatting drives me mad lol

#13835

Edit to update -- also found in Engagements All -> Closed (bottom of page) - bad formatting.

[dryrunsecurity]

🔴 Risk threshold exceeded.

This pull request makes sensitive edits to multiple core files (dojo/importers/base_importer.py, dojo/filters.py, dojo/finding/views.py, and dojo/utils.py) and introduces an information disclosure issue where get_visible_scan_types() exposes all active scan types to any authenticated user with product/engagement access; it also uses unvalidated workflow input release_number as the ref in .github/workflows/release-x-manual-docker-containers.yml, allowing a repo write attacker to run arbitrary code with workflow secrets.

🔴 Configured Codepaths Edit in dojo/importers/base_importer.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/filters.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/finding/views.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/utils.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/utils.py

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

Untrusted Input in GitHub Actions Workflow in .github/workflows/release-x-manual-docker-containers.yml

Vulnerability

Untrusted Input in GitHub Actions Workflow

Description

The GitHub Actions workflow '.github/workflows/release-x-manual-docker-containers.yml' uses the release_number input directly as the ref for the actions/checkout step without any validation. An attacker with write access to the repository can trigger this workflow_dispatch event and provide an arbitrary Git reference (e.g., a malicious branch, tag, or commit hash) to the release_number input. This allows the attacker to execute arbitrary code in the context of the workflow runner, which has access to sensitive secrets like DOCKERHUB_TOKEN and DOCKERHUB_USERNAME.

django-DefectDojo/.github/workflows/release-x-manual-docker-containers.yml

Lines 63 to 64 in 3fbb770

	ref: ${{ inputs.release_number }}

Information Disclosure of Scan Types in dojo/finding/views.py

Vulnerability

Information Disclosure of Scan Types

Description

The get_visible_scan_types() function, used in the ListFindings view, retrieves all active Test_Type objects without performing any authorization checks. While the ListFindings view itself has authorization checks (Permissions.Product_View or Permissions.Engagement_View), the get_visible_scan_types() function does not filter the scan types based on the user's permissions. This means any authenticated user with access to a product or engagement can view a list of all active scan types configured in the system, regardless of whether they have specific permissions to create or manage those scan types. This could reveal internal security tooling and capabilities to unauthorized users.

django-DefectDojo/dojo/finding/views.py

Lines 306 to 309 in 3fbb770

	"visible_test_types": get_visible_scan_types(),
	}
	# Look to see if the product was used
	if product_id := self.get_product_id():

We've notified @mtesauro.

---

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

[testaccount90009]

Should I rebase against bugfix, or is dev -> bugfix the correct approach? Sorry, it's been a while since I've contributed.

[testaccount90009]

Update - I found this problem in the engagements_all.html file as well at the bottom under 'Closed Engagements' it has bad formatting.

[valentijnscholten]

Thanks. Looks like the PR needs a rebase or cherrypick of your sommit onto the bugfix branch.

[testaccount90009]

Thanks. Looks like the PR needs a rebase or cherrypick of your sommit onto the bugfix branch.

Will do - not sure what happened.

[testaccount90009]

If it's easier to just cherry pick these commits in a different PR and close this PR, that's fine. Think I have some Git issues going on, if that merge didn't fix it. Been a while since I've used that system - so it may need some cleaning up locally.

[testaccount90009]

Found the issue, I'll open a fresh PR and get rid of this noise - apologies.