Package caches are global and remain on the CxFlow instance after an SCAResolver scan

[nleach999]

Description

Related to issue #1129.

My testing was limited to Python and pip but this is going to be an issue for most build tools. When dependencies are resolved, the downloaded dependencies are globally cached unless caching is explicitly turned off. It would be undesirable to have the storage of the CxFlow webhook endpoint instance growing unconstrained.

Additionally, Python presents somewhat of a problem. During dependency resolution, any requirements.txt that don't explicitly state a version requirement of a package (e.g. it is common to not define the version in order to always fetch the latest version) will not perform an upgrade if a package is in the global cache. This means that there is a potential for false-negatives as packages and their transitive dependencies remain at older versions until the CxFlow endpoint is restarted.

It would be possible to pass --upgrade or --no-cache-dir as custom parameters for pip except issue #1189 makes this a little difficult.

Configuring parameters for each build tool to avoid caching is likely not desirable. This is (usually) not an issue in a CI/CD pipeline since the stage where dependencies are resolved is an ephermal execution context. Anything written at the time of execution is deleted when the computation resources for the build stage are cleaned up.

Keep in mind that since the caches are global, deleting them without consideration of other threads of execution for scan orchestrations won't be desirable.

Expected Behavior

Any local files are purged after successful scans.

Actual Behavior

Package cache files remain on the CxFlow container.

Reproduction

1. Perform an SCAResolver scan.
2. Open a shell on the running CxFlow instance.
3. Execute ls -lR ~/.cache/pip to view the package cache.

Environment Details

CxFlow 1.6.39 running in webhook mode