Support selectively enabling/disabling individual plugins

[another-rex]

Overview

Currently OSV-Scanner provides 2 presets of extractors, one for source lockfile scanning and one for artifact scanning. We want to add support for flags/config options that enable users to selectively choose which plugins and extractors to enable beyond the preset enabled extractors.

Details

This can be implemented as a list of extractors we can choose to enable, and we have pre-made presets names which allows you to enable a large number of plugins all at once.
By default, if no flag is passed in, we use the current presets we have. Once the user chooses plugins to enable, the presets no longer apply and only what the user selects are enabled.

If the user wants to keep the existing plugins, and just add on another plugin themselves, they can do that by choosing the original preset name + the new extractor.

CLI wise this can be implemented similar to how --call-analysis is implemented, instead with --plugins and --no-plugins (naming could use some work)

Tasks:

• Create Plugin Lists: We need to create a list of all available plugins (combine the existing All list in OSV-Scalibr with OSV-Scanner specific plugins), and also lists of presets
• Implement CLI interface change (similar to the --call-analysis and --no-call-analysis flags)
• Implement Enabling and disabling the plugins
• Update DoScan() API to accept list of enabled plugins.

[G-Rath]

@another-rex is the initial goal to support being able to enable most plugins/extractors arbitrary regardless of context, or to just control which ones are enabled at the appropriate time they'd be used?

From what I've seen so far even though we technically have the presets you've described, they're used in completely different places: artifact is used with scanner.ScanContainer while lockfile is used with ... eventually extractor{}.Extract from the looks of it?

Personally I think in the long run we should support mostly arbitrarily enabling of extractors (i.e. I can choose to run the nodemodules extractor on my host if I want), but for now unless I've missed something the far easier thing to support would be restrict the extractors to the specific situations we allow, and just decide which are enabled by on the list from the user

[another-rex]

Yes the goal is to support arbitrary plugins regardless of context.

Scalibr plugins has a Requirements() function which determines which context it can be ran in, so we'll need to check this, but that can be a follow up PR. Generally enabling a plugin that doesn't fit the requirements will just have that plugin not do anything.

// Capabilities lists capabilities that the scanning environment provides for the plugins.
// A plugin can't be enabled if it has more requirements than what the scanning environment provides.
type Capabilities struct {
	// A specific OS type a Plugin needs to be run on.
	OS OS
	// Whether network access is provided.
	Network Network
	// Whether the scanned artifacts can be access through direct filesystem calls.
	// True on hosts where the scan target is mounted onto the host's filesystem directly.
	// In these cases the plugin can open direct file paths with e.g. os.Open(path).
	// False if the artifact is not on the host but accessed through an abstract FS interface
	// (e.g. scanning a remote container image). In these cases the plugin must use the FS interface
	// to access the filesystem.
	DirectFS bool
	// Whether the scanner is scanning the real running system it's on. Examples where this is not the case:
	// * We're scanning a virtual filesystem unrelated to the host where SCALIBR is running.
	// * We're scanning a real filesystem of e.g. a container image that's mounted somewhere on disk.
	RunningSystem bool
}

I think there shouldn't be that much difference between limiting it to lists or allowing the user to use the All list in osv-scalibr (+the ones in osv-scanner).