Reimporting Trivy Scan report sets previously Active vulnerabilities to Active and Verified

[l4mdor]

Bug description
When reimporting a report from Trivy Scan, if there are a large number of vulnerabilities (~1000), if the vulnerabilities were previously Active, they are marked as Active, Verified. The error is reproduced through both the UI and the pipeline.

Manually, the Active or Verified markup options are not additionally set.

The error is reproduced only when importing a large number of vulnerabilities. With a small amount, such a problem is not observed.

This causes big problems when the system is configured to send vulnerabilities marked Verified to Jira. Then ~1000 tickets are sent to Jira.

Steps to reproduce
Steps to reproduce the behavior:

0. Set up integration with Jira to automatically send only Verified vulnerabilities
1. Select an existing engagement
2. Add a new test with scan type "Trivy Scan" with ~1000 vulnerabilities.
3. Go to the engagement and click on the colon next to "Trivy Scan" and select "Re-upload a Trivy Scan"
4. Select the same vulnerability file and upload

Expected behavior
Do not mark vulnerabilities as Verified when reimporting a large number of vulnerabilities, unless otherwise specified.

Deployment method

• Docker Compose
• Kubernetes
• GoDojo

Environment information

• Operating System: Debian GNU/Linux 12 (bookworm)
• Docker Compose or Helm version: docker compose v2.40.0
• DefectDojo version (see footer) or commit message: v2.51.0

Logs
n/a

Sample scan files
Trivy Scan image report with 1000 or more vulnerabilities

Screenshots

Additional context (optional)
n/a

[valentijnscholten]

DefectDojo version (see footer) or commit message: v2.51.0

Could you try to reproduce with the latest 2.56.2 version or the demo instance? A lot of changes have been made to reimport since 2.51.0.

[fsorkin]

DefectDojo version (see footer) or commit message: v2.51.0

Could you try to reproduce with the latest 2.56.2 version or the demo instance? A lot of changes have been made to reimport since 2.51.0.

I tested it on version 2.56.2. Here the situation is reversed. When reimporting, there is no problem. However, when importing vulnerabilities for the first time (~1000), if you do not set additional flags, the vulnerabilities are marked as Active, Verified. At the same time, I also tested a small number of vulnerabilities for the first import from another scanner, if you do not set additional flags, then the import is correct and the vulnerabilities are Active.

[valentijnscholten]

If you do not specify values for active or verified, the parser will decide the values. For Trivy this means in some cases verified becomes True:

django-DefectDojo/dojo/tools/trivy/parser.py

Lines 81 to 158 in ee5f04b

	def convert_trivy_status(self, trivy_status: str) -> dict:
	"""
	Determine status fields based on Trivy status
	From: https://trivy.dev/v0.54/docs/configuration/filtering/
	Trivy has a Status field based on VEX vulnerability statuses. Please not these are statuses based on the vulnerability advisories by OS vendors such as Debian, RHEL, etc.
	- `unknown`
	- `not_affected`: this package is not affected by this vulnerability on this platform
	- `affected`: this package is affected by this vulnerability on this platform, but there is no patch released yet
	- `fixed`: this vulnerability is fixed on this platform
	- `under_investigation`: it is currently unknown whether or not this vulnerability affects this package on this platform, and it is under investigation
	- `will_not_fix`: this package is affected by this vulnerability on this platform, but there is currently no intention to fix it (this would primarily be for flaws that are of Low or Moderate impact that pose no significant risk to customers)
	- `fix_deferred`: this package is affected by this vulnerability on this platform, and may be fixed in the future
	- `end_of_life`: this package has been identified to contain the impacted component, but analysis to determine whether it is affected or not by this vulnerability was not performed
	Note that vulnerabilities with the `unknown`, `not_affected` or `under_investigation` status are not detected.
	These are only defined for comprehensiveness, and you will not have the opportunity to specify these statuses.
	Some statuses are supported in limited distributions.
	| OS | Fixed | Affected | Under Investigation | Will Not Fix | Fix Deferred | End of Life |
	|:----------:|:-----:|:--------:|:-------------------:|:------------:|:------------:|:-----------:|
	| Debian | ✓ | ✓ | | | ✓ | ✓ |
	| RHEL | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
	| Other OSes | ✓ | ✓ | | | | |
	"""
	status_mapping = {
	"unknown": {
	# use default value for active which is usually True
	"verified": False,
	},
	"not_affected": {
	# false positive is the most appropriate status for not affected as out of scope might be interpreted as something else
	"active": False,
	"verified": True,
	"is_mitigated": True,
	},
	"affected": {
	# standard case
	"active": True,
	"verified": True,
	},
	"fixed": {
	# fixed in this context means that there is a fix available by patching/updating/upgrading the package
	# but it's still active and verified
	"active": True,
	"verified": True,
	},
	"under_investigation": {
	# no status flag in Defect Dojo to capture this, but verified is False
	"active": True,
	"verified": False,
	},
	"will_not_fix": {
	# no different from affected as Defect Dojo doesn't have a flag to capture will_not_fix by OS/Package Vendor
	# we can't set active to False as the user needs to risk accept this finding
	"active": True,
	"verified": True,
	},
	"fix_deferred": {
	# no different from affected as Defect Dojo doesn't have a flag to capture will_not_fix by OS/Package Vendor
	# we can't set active to False as the user needs to (temporarily) risk accept this finding
	"active": True,
	"verified": True,
	},
	"end_of_life": {
	# no different from affected as Defect Dojo doesn't have a flag to capture will_not_fix by OS/Package Vendor
	# we can't set active to False as the user needs to (temporarily) risk accept this finding
	"active": True,
	"verified": True,
	},
	}
	# default is to fallback to default Defect Dojo behaviour which takes scan parameters into account
	return status_mapping.get(trivy_status, {})

[l4mdor]

If you do not specify values for active or verified, the parser will decide the values. For Trivy this means in some cases verified becomes True:

django-DefectDojo/dojo/tools/trivy/parser.py

Lines 81 to 158 in ee5f04b

 def convert_trivy_status(self, trivy_status: str) -> dict: 
     """ 
     Determine status fields based on Trivy status 

     From: https://trivy.dev/v0.54/docs/configuration/filtering/ 

     Trivy has a Status field based on VEX vulnerability statuses. Please not these are statuses based on the vulnerability advisories by OS vendors such as Debian, RHEL, etc. 

     - `unknown` 
     - `not_affected`: this package is not affected by this vulnerability on this platform 
     - `affected`: this package is affected by this vulnerability on this platform, but there is no patch released yet 
     - `fixed`: this vulnerability is fixed on this platform 
     - `under_investigation`: it is currently unknown whether or not this vulnerability affects this package on this platform, and it is under investigation 
     - `will_not_fix`: this package is affected by this vulnerability on this platform, but there is currently no intention to fix it (this would primarily be for flaws that are of Low or Moderate impact that pose no significant risk to customers) 
     - `fix_deferred`: this package is affected by this vulnerability on this platform, and may be fixed in the future 
     - `end_of_life`: this package has been identified to contain the impacted component, but analysis to determine whether it is affected or not by this vulnerability was not performed 


     Note that vulnerabilities with the `unknown`, `not_affected` or `under_investigation` status are not detected. 
     These are only defined for comprehensiveness, and you will not have the opportunity to specify these statuses. 

     Some statuses are supported in limited distributions. 

     |     OS     | Fixed | Affected | Under Investigation | Will Not Fix | Fix Deferred | End of Life | 
     |:----------:|:-----:|:--------:|:-------------------:|:------------:|:------------:|:-----------:| 
     |   Debian   |   ✓   |    ✓     |                     |              |      ✓       |      ✓      | 
     |    RHEL    |   ✓   |    ✓     |          ✓          |      ✓       |      ✓       |      ✓      | 
     | Other OSes |   ✓   |    ✓     |                     |              |              |             | 
     """ 
     status_mapping = { 
         "unknown": { 
             # use default value for active which is usually True 
             "verified": False, 
         }, 
         "not_affected": { 
             # false positive is the most appropriate status for not affected as out of scope might be interpreted as something else 
             "active": False, 
             "verified": True, 
             "is_mitigated": True, 
         }, 
         "affected": { 
             # standard case 
             "active": True, 
             "verified": True, 
         }, 
         "fixed": { 
             # fixed in this context means that there is a fix available by patching/updating/upgrading the package 
             # but it's still active and verified 
             "active": True, 
             "verified": True, 
         }, 
         "under_investigation": { 
             # no status flag in Defect Dojo to capture this, but verified is False 
             "active": True, 
             "verified": False, 
         }, 
         "will_not_fix": { 
             # no different from affected as Defect Dojo doesn't have a flag to capture will_not_fix by OS/Package Vendor 
             # we can't set active to False as the user needs to risk accept this finding 
             "active": True, 
             "verified": True, 
         }, 
         "fix_deferred": { 
             # no different from affected as Defect Dojo doesn't have a flag to capture will_not_fix by OS/Package Vendor 
             # we can't set active to False as the user needs to (temporarily) risk accept this finding 
             "active": True, 
             "verified": True, 
         }, 
         "end_of_life": { 
             # no different from affected as Defect Dojo doesn't have a flag to capture will_not_fix by OS/Package Vendor 
             # we can't set active to False as the user needs to (temporarily) risk accept this finding 
             "active": True, 
             "verified": True, 
         }, 
     } 

     # default is to fallback to default Defect Dojo behaviour which takes scan parameters into account 
     return status_mapping.get(trivy_status, {})

Thanks for the clarification. In version 2.52.6, the problem has been fixed, and if active vulnerabilities are reimported from Trivy, the statuses do not change from Active to Active, Verified.