Skip to content
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

🐛 fix trivyoperator tags #11276

Merged
merged 5 commits into from
Nov 22, 2024

Conversation

manuel-sommer
Copy link
Contributor

@manuel-sommer manuel-sommer commented Nov 17, 2024

Some TrivyOperator tags were empty

Copy link

dryrunsecurity bot commented Nov 17, 2024

DryRun Security Summary

The provided code changes focus on improving the handling and reporting of security findings and vulnerabilities detected by the Trivy security scanner, including optimizing the handling of metadata, enhancing the processing and reporting of detected secrets, expanding the vulnerability metadata captured, introducing a "uniformed" vulnerability ID, and filtering out any empty tags.

Expand for full summary

Summary:

The provided code changes focus on improving the handling and reporting of security findings and vulnerabilities detected by the Trivy security scanner. The key changes include:

  1. Optimizing the handling of the resource_namespace metadata in the Finding object, ensuring that empty strings are not added as tags.
  2. Enhancing the processing and reporting of detected secrets, with similar improvements to the handling of the resource_namespace.
  3. Expanding the vulnerability metadata captured in the Finding object, including details like vulnerability ID, severity, references, mitigation information, package details, and CVSS scores.
  4. Introducing a "uniformed" vulnerability ID to maintain consistency in vulnerability representation across the application.
  5. Filtering out any empty tags from the Finding object to maintain data integrity.

From an application security perspective, these changes demonstrate a focus on improving the overall security posture of the application by enhancing the quality and usefulness of the security findings and vulnerability data. The changes do not introduce any obvious security vulnerabilities, and they appear to be in line with industry-standard security practices and recommendations.

Files Changed:

  1. dojo/tools/trivy_operator/checks_handler.py: The changes in this file optimize the handling of the resource_namespace metadata in the Finding object, ensuring that empty strings are not added as tags.
  2. dojo/tools/trivy_operator/secrets_handler.py: The changes in this file improve the processing and reporting of detected secrets, with similar improvements to the handling of the resource_namespace.
  3. dojo/tools/trivy_operator/vulnerability_handler.py: The changes in this file expand the vulnerability metadata captured in the Finding object, introduce a "uniformed" vulnerability ID, and filter out any empty tags.

Code Analysis

We ran 9 analyzers against 3 files and 0 analyzers had findings. 9 analyzers had no findings.

Riskiness

🟢 Risk threshold not exceeded.

View PR in the DryRun Dashboard.

Copy link
Contributor

@mtesauro mtesauro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved

@manuel-sommer
Copy link
Contributor Author

@cneill , no resource_namespace shouldn't be a list here.
Before the fix an example:
grafik
After the fix, the same example:
grafik

@cneill
Copy link
Contributor

cneill commented Nov 19, 2024

Hm. I can't replicate this behavior with the exposed secrets scan report here. I get a single default tag either way. I didn't realize a single string was a valid input for the tags field. All the other parsers provide lists of tags (e.g. Dependency Check, Threat Composer, Meterian...).

Does your scan file differ in some way from the one in unittests?

@manuel-sommer
Copy link
Contributor Author

Hm, weird, I can't replicate it now. Maybe a different PR fixed this on the fly. If I can't replicate it, I will stick to your suggestion @cneill .

@Maffooch
Copy link
Contributor

@manuel-sommer I am not sure if this ready for merge or not. Let me know if you are ready for this one to go in 😄

@manuel-sommer
Copy link
Contributor Author

manuel-sommer commented Nov 20, 2024

Let's merge it @Maffooch . I tested it again today and found no bugs. In case I find another bug, I will submit a PR regarding trivy operator. I am actively testing it for soonish future use.

@Maffooch Maffooch merged commit 43833fa into DefectDojo:bugfix Nov 22, 2024
73 checks passed
@manuel-sommer manuel-sommer deleted the fix_trivy_operator_tags branch November 22, 2024 05:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants