SBOM Scan API caching
## Problem to solve
Currently, SBOM scans are triggered regardless of whether a project's dependencies have actually changed. This leads to unnecessary resource use and complexity. By implementing caching we can significantly reduce the number of unnecessary scans while maintaining security coverage.
## Proposal
The current SBOM scanning process:
- Triggers scans on every pipeline run, regardless of dependency changes (e.g. Gemfile.lock updated)
- Processes identical dependencies and generates same results
- Wastes computational resources by triggering the dependency detection in the analyzer and scan in the rails application.
Analyzer dependency change detection would run into problems because even when all components are the same, a new advisory may have been issued which would require a re-scan. Serving a cached scanning result is closer to what we can accomplish in the next iteration with the Sbom Scanning API.
epic