• Move the config file from a per-user location, to per-project top level. In case of different needs per project.
• Don't generate or overwrite the cicada config when updating the index cache.

For faster development.

Remove all junk files resulting from running cicada.

This makes it easier for Docker users to inject cicada into containers, which may not have the unzip binary installed, and may even lack access to a package manager. Many more Linux environments provide tar by default than unzip.

https://endoflife.date/

This will require mapping between GOOS strings and endoflife.date strings. For example, "darwin" -> "macos".

We will also need to add some code to identify which particular Linux distribution is in use, for "linux" GOOS environments.

Add an option to silence warnings for known support issues with stock, system level components that often come bundled with operating systems. When -quiet is applied, then we silence any warnings about system binaries.

Only base operating system versions, and out of band packages, will trigger warnings. For example, stock Apple ruby may be ignored, but not Homebrew or RVM or rbenv Ruby.

This capability will help cicada to ensure that all warnings emitted are actionable. Because stock, system level components are not themselves very actionable. Only a major OS upgrade can fix these problems.

For example, a user PATH overriding stock Apple Ruby with RVM to serve an application, may still be vulnerable in terms of the total attack surface on the host. Yet nothing can be done about the stock portion of the attack surface until Apple provides a new OS.

Another common example involves semipermanent non-LTS versions of stock Python on Linux. Conceivably, the OS package registry may provide a Python update to get back on LTS track, without necessitating a major OS upgrade. The odds of that happening are small, but -quiet may be left default off for such uses.

Planning to alias cicada as -quiet locally, and run the full, loud scan in CI/CD, especially regarding container builds. It's easier to use pyenv locally + modern Python base images, and cicada should be flexible enough for both kinds of environments.

Ultimately, we leave any questions about flag consistency up to the user. But we should afford simple options for blocklisting inactionable results, so that cicada does not become a nuisance. Heh.

The standard Go executable path lookup function can provide the information we need to distinguish between stock versus out of band packages. We can maintain a relatively short list of stock binary directories for macOS, other UNIXen, and Windows, so that entries there can be skipped for scanning on -quiet.

If a user manually places a custom binary in a stock directory, that is considered bad form. Use /opt, or ~/bin, or ~/Applications, or some other conventional place for non-stock binaries.

To be clear, only OS first party package managers are considered to provide system, stock, or other silencable packages. Any package manager that requires intervention to add itself onto an OS is out of band. apt and yum and emerge and App Store and friends manage stock apps. Homebrew and RVM and nodenv are out of band.

Binaries placed in stock PATH directories by stock RubyGems, stock NPM, or stock pip, etc., may be considered stock packages and elegible for exclusion by -quiet. If the binary is placed elsewhere, it may not be silenced by -quiet.

Pending package-url/purl-spec#161

Use Syft to retrieve the live component versions.

https://github.com/anchore/syft

This keeps random directories cleaner, instead of dropping .cicada subdirectories wherever cicada runs.

And support multi-stage builds.

https://github.com/xeol-io/xeol

We are currently passing through semver validation errors as is, which don't even say the string that caused the error.

In the event of a semver parse error, then our application should report the specific component name and the version string.

This helps users to troubleshoot querying issues, such as subtle regexp quirks.

Relates to #14.

For Darwin users, ignore any LTS findings. Because Apple continues to depend on dead, bitrot tools.

• Snyk
• NPM
• RubyGems
• Python safety
• Dependabot

Insert platform relevant cicada executable a container, generate report from there.

Relates to #16

Pending https://pkg.go.dev/github.com/mcandre/cicada

https://www.phoronix.com/news/Linux-6.6-Goes-LTS

Don't require users to have a configuration file, when no customizations are needed.

This makes it easier to run cicada overall, but especially in containers and VM's, which may require additional effort to ferry configuration files into the guest.

I have downloaded cicada-0.0.8.zip and am trying to execute the binary on Linux Cent OS 7.
When i run ./cicada i get the following output and nothing else: 'Invalid Semantic Version'

The cicada.yaml contains the following lines:

debug: true
lead_months: 1

version_queries:
mongodb:
command: ["mongod", "--version"]
pattern: "^db version v(?P[0-9\.]+)$"