Plugin Architecture 101
Hoppr's core architecture utilizes plugins to perform tasks. Plugins are specified (and optionally configured) in the transfer
configuration file. All plugins should derive from the Hoppr plugin base class, which is described below:
tip
This plugin architecture overview builds on first principles discussed in Hoppr Processing 101.
Plugin Interface Functions​
Each Hoppr plugin runs one or more of the following methods, in order:
pre_stage_process
is run before any SBOM component processing. Initialization should be performed in this method.process_component
is run on each component of the consolidated SBOM.post_stage_process
is run after all SBOM components have been processed. Cleanup tasks should be performed here.
Plugin Variables​
required_commands
is a list of system dependencies (e.g.mvn
,git
) required for a plugin to executesupported_purl_types
is a list of PURLs a plugin can process. An empty list means a plugin should receiveALL
SBOM components inprocess_component
default_component_coverage
indicates how often each SBOM component should be processed. Defaults toOPTIONAL
bom_access
indicates if a plugin should be allowed to change the underlying SBOMs. Default isNO_ACCESS
, and we recommend always using the principle of least access
Plugin Types​
Plugins are grouped into categories based on their intended purpose. In most cases, these categories are simply convenient ways to refer to similar plugins, and is not actually reflected in the code.
- Collectors pull artifacts from various repositories and store them for later inclusion in bundles
- Processors modify the SBOM or its components
- Reports (coming soon) provide summary information about a portion of a Hoppr run
- Filters (coming soon) add or remove components in the delivered SBOM
- Bundlers take the artifacts copied by the collectors and package them in a bundle of some kind, suitable for transfer