Clean trivy cache after each cycle

[moukoublen]

Summary of your changes

Clean trivy cache after each cycle

Trivy artifact.NewRunner calls initCache.

Depending on the provided configuration, the latter (initCache) could either return a runner or the error SkipScan (and nil runner).

In case one of the below flags is true, the artifact.NewRunner will perform the relevant clean/reset operation and return SkipScan.

• CacheOptions.ClearCache
• DBOptions.Reset
• MisconfOptions.ResetPolicyBundle

This means that:

1. The clean/reset operations are embedded inside initCache, called inside artifact.NewRunner. We cannot execute them standalonely.
2. When at least one on those flags are true, the clean/reset operation takes place and returns SkipScan and nil runner, which means we cannot set the flags and get a valid runner with a single call (that's why I created a separate function ClearCache in my code changes).
3. initCache could perform only one of each clean/reset operation and then return SkipScan, which means we cannot perform a single artifact.NewRunner call and init all of those flags to true and expect all those clear/reset operations to run. We need to do one at a time (that's why I created the loop inside ClearCache in my code changes).

Screenshot/Data

Related Issues

Fixes: https://github.com/elastic/cloudbeat/issues/2142

Checklist

• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] I have added the necessary README/documentation (if appropriate)

Introducing a new rule?

• [ ] Generate rule metadata using this script
• [ ] Add relevant unit tests
• [ ] Generate relevant rule templates using this script, and open a PR in elastic/packages/cloud_security_posture

[github-actions[bot]]

:bar_chart: Allure Report - :green_heart: No failures were reported.

Result	Count
🟥 Failed	0
🟩 Passed	359
⬜ Skipped	33

[eyalkraft]

@moukoublen would that change mean we download the entire vuln DB for every cycle?

[moukoublen]

@eyalkraft I thought the DB is being downloaded on each cycle either way. But I will check and perhaps remove the db reset option.

@romulets I couldn't think of a way to test this, to be honest, other than the already existing test (constructor does not return an error). I couldn't think of a way to safely test that "ensure that the cache is cleared after init".

[moukoublen]

@eyalkraft

Apparently, one of the two databases being downloaded —the Java one— is cached for three days, so in that case, yes, we would lose that. The other one is downloaded on every run, no matter what.

example log

Repeater cycle triggered
Need to update DB
DB Repository: ghcr.io/aquasecurity/trivy-db
Downloading DB...

Java DB Repository: ghcr.io/aquasecurity/trivy-java-db:1
Downloading the Java DB...
The Java DB is cached for 3 days. If you want to update the database more frequently, the '--reset' flag clears the DB cache.

So I removed the {DBOptions: flag.DBOptions{Reset: true} and I will test again to verify that {CacheOptions: flag.CacheOptions{ClearCache: true}}, is enough (it should be).