Overview

Aqua is introducing two new vulnerability lifecycle attributes to provide more accurate visibility into when vulnerabilities are first discovered, while preserving complete backward compatibility with the existing First Found Date field.

This feature is available in SaaS U11 and On-Prem U46. Migration is performed during the release rollout.

What is changing

The existing First Found Date attribute remains unchanged and continues to function exactly as it does today, ensuring no impact to existing reports, dashboards, integrations, or automation.

Two new attributes are being introduced:

  • First Found Date v2 (Repository First Found Date) — indicates when a vulnerability was first detected within a specific repository
  • Global First Found Date — indicates when a vulnerability was first detected anywhere across the customer's environment, regardless of repository or registry

To support these capabilities, a background database migration will create and populate new schema objects without modifying existing vulnerability data.

Why this change is being made

Customers have reported limitations with the existing First Found Date attribute, including:

  • The First Found Date can reset after CI/CD or UI rescans once scan retention has expired, even when scanning the same image digest
  • Rescanning an unchanged image updates the First Found Date, making it difficult to determine when a vulnerability was originally introduced
  • Inconsistent First Found Date values across reports, exports, dashboards, and vulnerability views

Rather than changing existing behavior, Aqua is introducing two new attributes that provide more accurate vulnerability lifecycle tracking while maintaining full backward compatibility.

The new attributes enable customers to:

  • Track when a vulnerability first appeared within a repository
  • Understand when a vulnerability was first introduced anywhere across the environment
  • Improve vulnerability triage, reporting, and remediation prioritization
  • Continue using existing dashboards and integrations without modification

Customer impact

This enhancement is fully backward compatible.

  • Customers can continue using the existing First Found Date attribute without any changes
  • Following successful migration, two additional attributes become available through the API and export functionality
  • Existing reports, dashboards, integrations, SLA-based suppressions, and automation relying on the current First Found Date remain unaffected
  • Migration is non-disruptive — if migration does not complete successfully, existing functionality continues to operate normally

Required customer action

SaaS customers

  • No action is required
  • Scanner versions in the customer environment must be upgraded to the latest
  • Migration will be performed by the Aqua SRE team during the scheduled release rollout

On-Prem customers

Customers should:

  • Upgrade to the supported release before enabling the feature
  • Schedule an appropriate maintenance window for the migration
  • Take a database backup before starting the migration
  • Ensure sufficient database storage is available for the new schema
  • Enable the migration feature flag and complete the migration before enabling the First Found Date feature
  • After migration completes successfully, upgrade all scanners to the latest supported version

This ensures newly discovered vulnerabilities correctly populate both Repository First Found Date (FFD-R) and Global First Found Date (FFD-G). Environments running a mix of older and newer scanner versions may observe inconsistent population of the new attributes until all scanners have been upgraded.

Frequently Asked Questions

Q: Will the existing First Found Date change?

A: No. The existing First Found Date attribute remains unchanged and continues to function as it does today.

Q: What are the new attributes called?

A: First Found Date v2 (Repository First Found Date) and Global First Found Date.

Q: Is migration disruptive?

A: No. Migration is non-disruptive. If migration does not complete successfully, existing functionality continues to operate normally.

Q: What should On-Prem customers do before migration?

A: Upgrade to the supported release, schedule a maintenance window, take a database backup, and ensure sufficient database storage is available.

Q: Do scanners need to be upgraded?

A: Yes. After migration, upgrade all scanners to the latest supported version to ensure new vulnerabilities correctly populate FFD-R and FFD-G.