feat: allow to remove fields from vulnerability reports and omit empty fields by sathieu · Pull Request #2854 · aquasecurity/trivy-operator

sathieu · 2026-01-14T21:40:16Z

Description

I propose two changes to limit the problems of etcd max size reached (#757):

allow to remove some fields from the vulnerability report
omit (now) empty fields from produced resource

Before:

  vulnerabilities:
  - fixedVersion: 0.45.0
    installedVersion: v0.43.0
    lastModifiedDate: "2025-12-11T19:36:41Z"
    links: []
    packagePURL: pkg:golang/golang.org/x/crypto@v0.43.0
    primaryLink: https://avd.aquasec.com/nvd/cve-2025-47914
    publishedDate: "2025-11-19T21:15:50Z"
    resource: golang.org/x/crypto
    score: 5.3
    severity: MEDIUM
    target: ""
    title: 'golang.org/x/crypto/ssh/agent: in golang.org/x/crypto/ssh/agent'
    vulnerabilityID: CVE-2025-47914

After first commit (and trivy.additionalVulnerabilityReportFields=-Resource,-InstalledVersion,-FixedVersion,-PublishedDate,-LastModifiedDate,-Title,-PrimaryLink,-Score,-PURL):

  - fixedVersion: ""
    installedVersion: ""
    lastModifiedDate: ""
    publishedDate: ""
    resource: ""
    severity: MEDIUM
    target: ""
    title: ""
    vulnerabilityID: CVE-2025-47914

After both commits (and trivy.additionalVulnerabilityReportFields=-<same>):

  - severity: MEDIUM
    vulnerabilityID: CVE-2025-47914

Notes:

CRDs are changed, this needs to be added in release notes, as the CRD should be updated first
vulnerabilityID can't be removed. I can change this if you want
I haven't implemented Reduce the amount of vulnerability fields stored in the vulnerabilities report #442 (comment), as this breaks vulnid metrics
I've updated tests

Related issues

Fixes Reduce the amount of vulnerability fields stored in the vulnerabilities report #442
Related to Reconciler error: Large size VulnerabilityReports will failed create and remains scan jobs #757, but not closing as there is still a limit

Checklist

I've read the guidelines for contributing to this repository.
I've added tests that prove my fix is effective or that my feature works.
I've updated the documentation with the relevant information (if needed).
I've added usage information (if the PR introduces new options)
I've included a "before" and "after" example to the description (if the PR is a user interface change).

CLAassistant · 2026-01-14T21:40:25Z

All committers have signed the CLA.

sathieu · 2026-01-16T08:09:03Z

@simar7, @afdesk and others Please review 🙏 .

afdesk · 2026-01-16T08:51:24Z

Hi @sathieu
Thanks for your efforts!
I'll take a look at this PR tonight or on Monday

afdesk · 2026-01-19T08:48:17Z

+		value := !strings.HasPrefix(field, "-")
+		field = strings.TrimPrefix(field, "-")


i think we should run strings.TrimSpace before these calls to support a case -PublishedDate.

also it'd be great to have a test for this case.

Added strings.TrimSpace before removing prefix, with various tests: " -Resource,- InstalledVersion, - FixedVersion, - PublishedDate,[...]"

afdesk · 2026-01-19T08:51:42Z

+				FixedVersion:     true,
+				PublishedDate:    true,
+				LastModifiedDate: true,
+				Severity:         true,


there is a concern about Severity. it may affect on Summary.
so I suggest don't allow to exclude it. because I don't know a case when we need to exclude Severity. may be I miss something
WDYT?

Severity is now always kept (also in CRD, no omitempty).

afdesk · 2026-01-19T09:00:16Z

+	Title            bool
+	PrimaryLink      bool
+	Score            bool
+	PURL             bool


about PURL.
It seems PURL is too common name, because actually we can manage PkgPURL only, can't we?

Changed to PkgPURL. Thanks

afdesk · 2026-01-19T09:05:31Z

@sathieu Thank you very much for your effort and for submitting this PR — it’s greatly appreciated.

I’ve left a few inline comments to discuss some ideas.

I also have a small concern regarding backward compatibility. In particular, clients that previously relied on the presence of certain fields (even when they were empty) now need to be prepared for those fields to be omitted entirely.

Specifically, the handling of nil vs empty slices has changed: Links is no longer set when sr.References == nil. Previously, some code paths appeared to expect an empty slice ([]) instead.

This is likely not a critical issue, but it would be good to get feedback from the community and confirm that this change won’t cause unexpected behavior for existing consumers.

sathieu

Thanks @afdesk for your review.

About backward compatibility, we can use a new apiVersion (v1alpha2 or v1beta1 or v1), this will give safer approach to backward compatibility issues. This is documented here. A webhook will be needed to convert resources on-fly.

sathieu · 2026-01-19T20:24:10Z

+		value := !strings.HasPrefix(field, "-")
+		field = strings.TrimPrefix(field, "-")


Added strings.TrimSpace before removing prefix, with various tests: " -Resource,- InstalledVersion, - FixedVersion, - PublishedDate,[...]"

sathieu · 2026-01-19T20:34:08Z

+				FixedVersion:     true,
+				PublishedDate:    true,
+				LastModifiedDate: true,
+				Severity:         true,


Severity is now always kept (also in CRD, no omitempty).

sathieu · 2026-01-19T20:37:11Z

+	Title            bool
+	PrimaryLink      bool
+	Score            bool
+	PURL             bool


Changed to PkgPURL. Thanks

sathieu · 2026-01-23T14:39:04Z

@afdesk I have extracted the non-breaking bits in #2860.

Please tell what I should do for the omitempty. I think adding a new apiVersion would be the best path. What do you think about v1beta1?

Copilot

Pull request overview

This PR makes vulnerability reports more size-efficient and configurable to mitigate etcd max request size issues by allowing selected vulnerability fields to be omitted and by not serializing empty fields. It introduces a configuration-based mechanism to disable specific core vulnerability fields, updates the CRDs and docs accordingly, and ensures webhook and plugin behavior remains consistent with the new schema.

Changes:

Extend trivy.additionalVulnerabilityReportFields to support disabling core vulnerability fields (e.g., Resource, InstalledVersion, FixedVersion, dates, title, primary link, score, PURL), with new default behavior keeping them enabled.
Make several Vulnerability fields optional (omitempty) and adjust the Trivy plugin’s mapping from scan results to respect the new configuration, omitting disabled fields and not emitting empty values.
Update CRDs, Helm charts, static manifests, docs, and tests (Trivy config tests, plugin tests, and webhook reporter tests) to align with the new behavior.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
`pkg/vulnerabilityreport/io.go`	Introduces the expanded `AdditionalFields` struct, a `NewDefaultAdditionalFields` helper, and updates `GetVulnerabilitiesFromScanResult` to conditionally populate vulnerability fields based on config and omit unset date and PURL fields.
`pkg/plugins/trivy/config.go`	Changes `GetAdditionalVulnerabilityReportFields` to start from defaults and then enable/disable flags based on a comma-separated, optionally `-`-prefixed configuration list.
`pkg/plugins/trivy/config_test.go`	Expands tests to validate default behavior, additive configuration, full removal, and mixed add/remove scenarios for `additionalVulnerabilityReportFields`, asserting each `AdditionalFields` flag individually.
`pkg/plugins/trivy/plugin.go`	Refactors `ParseReportData` to compute `addFields` once and pass it into `GetVulnerabilitiesFromScanResult`, ensuring all results use the same configured field set.
`pkg/plugins/trivy/plugin_test.go`	Keeps `ParseReportData` behavior under existing configurations validated via `sampleVulnerabilityReport` / `sampleExposedSecretReport`, ensuring the new conditional field logic does not regress expected reports.
`pkg/apis/aquasecurity/v1alpha1/vulnerability_types.go`	Marks multiple `Vulnerability` fields (`resource`, versions, dates, `title`, `links`, `target`) as `omitempty`, enabling the API to omit them when unset and reducing serialized size.
`pkg/webhook/webhookreporter_test.go`	Updates the webhook payload expectation for vulnerability reports to reflect that only non-empty, non-omitted fields appear in the JSON body.
`docs/docs/vulnerability-scanning/trivy.md`	Documents that `additionalVulnerabilityReportFields` now supports both adding extra fields and removing core ones via `-`-prefixed names, listing the supported removable field identifiers.
`deploy/static/trivy-operator.yaml`	Adjusts the static VulnerabilityReport and ClusterVulnerabilityReport CRD schemas to drop core vulnerability fields from the `required` list, matching their new optional nature.
`deploy/helm/crds/aquasecurity.github.io_vulnerabilityreports.yaml`	Updates the Helm CRD for namespaced vulnerability reports to make the same fields optional in the schema.
`deploy/helm/crds/aquasecurity.github.io_clustervulnerabilityreports.yaml`	Updates the Helm CRD for cluster-scoped vulnerability reports to mirror the optional field behavior.
`deploy/helm/values.yaml`	Extends the Helm values description of `trivy.additionalVulnerabilityReportFields` to document both additive fields and removable fields with a leading `-`.
`deploy/helm/README.md`	Mirrors the values.yaml description in the chart README to explain how to disable specific vulnerability fields via `trivy.additionalVulnerabilityReportFields`.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

simar7 · 2026-02-04T19:26:25Z

I also have a small concern regarding backward compatibility. In particular, clients that previously relied on the presence of certain fields (even when they were empty) now need to be prepared for those fields to be omitted entirely.

About backward compatibility, we can use a new apiVersion (v1alpha2 or v1beta1 or v1), this will give safer approach to backward compatibility issues. This is documented here. A webhook will be needed to convert resources on-fly.

@sathieu I think we certainly need to version this. It will be backwards breaking change to my understanding (removing existing fields). As you mentioned, we also will need a webhook to convert the resources on the fly.

sathieu · 2026-02-13T08:00:03Z

@afdesk @simar7 This PR starts to be too big. Here is what I have done:

feat: allow to remove fields from vulnerability reports (feat: allow to remove fields from vulnerability reports #2860)
feat: reduce VulnerabilityReport size by omitting empty fields (i.e. v1beta1)
feat: conversion between v1alpha1 et v1beta1
feat: conversion webhook
feat: webhook cert configuration
👷 TODO inject certificate

I don't know how to handle the last item. Proposal:

make the CRDs templatable in the Helm chart (by moving from crds to templates)
mount secret in the deployment
support various ways to inject certificate:
- cert-manager (recommended): create a selfsigned Issuer, a certificate and inject in CRD (cert-manager.io/inject-ca-from)
- generate using genSelfSignedCert (default)
- pre-existing secret
- disable webhook (i.e no conversion, and no mount in the deployment)

WDYT? Can we mandate cert-manager for the static installation? How to handle OLM installs?

github-actions Bot added the feature label Jan 14, 2026

sathieu mentioned this pull request Jan 14, 2026

Reconciler error: Large size VulnerabilityReports will failed create and remains scan jobs #757

Open

sathieu force-pushed the trim-vulnreports branch from be96b31 to 9251aa4 Compare January 15, 2026 05:51

sathieu marked this pull request as ready for review January 15, 2026 05:51

sathieu requested a review from simar7 as a code owner January 15, 2026 05:51

sathieu force-pushed the trim-vulnreports branch from 9251aa4 to 25fc308 Compare January 16, 2026 19:26

afdesk requested changes Jan 19, 2026

View reviewed changes

sathieu force-pushed the trim-vulnreports branch from 25fc308 to caa0cb0 Compare January 19, 2026 21:01

sathieu commented Jan 19, 2026

View reviewed changes

sathieu force-pushed the trim-vulnreports branch from caa0cb0 to 8da4c79 Compare January 19, 2026 21:05

sathieu mentioned this pull request Jan 23, 2026

feat: allow to remove fields from vulnerability reports #2860

Open

5 tasks

sathieu force-pushed the trim-vulnreports branch from 8da4c79 to d9d4dd8 Compare January 28, 2026 20:45

simar7 requested a review from Copilot February 4, 2026 18:44

Copilot started reviewing on behalf of simar7 February 4, 2026 18:45 View session

Copilot AI reviewed Feb 4, 2026

View reviewed changes

sathieu added 5 commits February 13, 2026 08:26

feat: allow to remove fields from vulnerability reports

2385270

feat: reduce VulnerabilityReport size by omitting empty fields

f83c7bd

feat: conversion between v1alpha1 et v1beta1

78f6e27

feat: conversion webhook

a3a8897

feat: webhook configuration

5269b3d

sathieu force-pushed the trim-vulnreports branch from d9d4dd8 to 5269b3d Compare February 13, 2026 07:38

		value := !strings.HasPrefix(field, "-")
		field = strings.TrimPrefix(field, "-")

Conversation

sathieu commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related issues

Checklist

Uh oh!

CLAassistant commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sathieu commented Jan 16, 2026

Uh oh!

afdesk commented Jan 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

afdesk commented Jan 19, 2026

Uh oh!

sathieu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sathieu commented Jan 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

simar7 commented Feb 4, 2026

Uh oh!

sathieu commented Feb 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

sathieu commented Jan 14, 2026 •

edited

Loading

CLAassistant commented Jan 14, 2026 •

edited

Loading