Trivy: Implement Caching and Fallback Mechanism for Trivy Database Fetches

[JasonPierce]

This enhancement will ensure continuous operation of the security scan workflow, reducing the potential disruptions caused by Trivy’s rate limits. When rate limits are reached on Trivy’s database fetches, we propose adding a caching and fallback mechanism. This ticket outlines the enhancements needed to minimize workflow disruptions caused by Trivy’s public rate limits and to ensure continued scanning even if the database is temporarily inaccessible.

Requirements:

1. Caching Mechanism

   • Implement a caching mechanism to store the last successful Trivy database fetch locally or in a shared location accessible by the workflow.
   • Cache should be refreshed only when a new database fetch is successful.

2. Fallback to Cached Database

   • If the Trivy database fetch fails due to rate limits or other network issues, the workflow should fallback to the cached database.
   • Ensure the fallback mechanism does not bypass genuine security vulnerability scans; it should only be triggered when there is an inability to fetch a new database.

Acceptance Criteria:

1. When a database fetch is successful, it is stored in the cache and made accessible for future scans if needed.
2. The workflow should automatically fallback to the cached database if the fetch fails due to rate limits or connectivity issues, preventing workflow failure due to database access issues.
3. Update project documentation to include caching and fallback configuration steps and conditions under which the fallback will be activated.