Define a modular naming convention for pipelines

[mjherzog]

• As we add more built-in pipelines for SCIO it is a good time to define some basic naming conventions that will help users quickly pick the best pipeline for a project. Some ideas are:
• Always start with a verb - most current pipelines follow this convention, except for deploy_to_develop, docker, docker_windows and root_filesystems
• Standardize usage of analyze, inspect or scan so that the user knows what output to expect.
• Need better name for scan_codebase_package to distinguish it from scan_codebase and scan_package

[pombredanne]

I like "Always start with a verb".
Here are suggestion on renaming some pipelines, following also discussions in #1034

Renaming candidates:

• deploy_to_develop -> analyze_d2d_java_and_javascript ???
• docker -> analyze_container or analyze_docker_image
• docker_windows -> analyze_windows_container or analyze_windows_docker_image
• root_filesystems -> analyze_root_filesystem_and_vm_image
• scan_codebase -> no change
• scan_package -> scan_single_package
• load_inventory -> replace with a load_scancode_scans
• inspect_manifest -> split to load_sbom and merge the package scan part from scan_codebase_packages in inspect_packages

[mjherzog]

Most of these make sense. Questions:

• For docker and docker_windows. Does our pipeline analyze other image/container types? Does the Docker image vs (runtime) container distinction apply in other cases? Is there a Windows image/container other than Docker?
• root_filesystem - Should this be "or" instead of "and" ?

[pombredanne]

We analyze docker images and OCI images. As for Windows not sure if there is anything but docker, but Microsoft calls these "Windows container" https://learn.microsoft.com/en-us/virtualization/windowscontainers/about/

root_filesystem - Should this be "or" instead of "and" ?

correct

[mjherzog]

So we should use the "image" terminology - Docker or OCI image - to be clear that we analyze the static image and not a running container.

[pombredanne]

See also #1034 (comment)

I think what we need mostly is a way to inspect a codebase for packages only.

1. inspect_manifest should inspect an archive, BUT
2. the archive may contain more than manifests, so we need really something different

Here is the plan I suggest:

• rename inspect_manifest to inspect_packages with a description that this inspects application package manifests and lockfiles and creates package and dependencies accordingly. Get it to do the equivalent of a scancode --package or the upcoming scancode --purl
• create a new pipeline resolve_dependencies that will resolve deps with inspectors (only on pypi for now) and only do this, nothing else (this will not have any steps otherwise)
• drop scan_codebase_packages that has a confusing name and would now be the same as inspect_packages

[tdruez]

Summary of the renaming suggestions:

Current name	New name	Notes
deploy_to_develop	map_deploy_to_develop	alternative: analyze_deployed_code
docker	analyze_docker_image
docker_windows	analyze_windows_docker_image
root_filesystems	analyze_root_filesystem_or_vm_image
scan_codebase_packages	inspect_packages	merged with inspect_manifest
scan_package	scan_single_package

No changes
find_vulnerabilities
inspect_manifest
load_inventory
find_vulnerabilities
populate_purldb
scan_codebase

[mjherzog]

These names look good. Specifically I agree that we should use map_deploy_to_develop instead of analyze_deployed_code because the latter does not explain the type of analysis.

[AyanSinhaMahapatra]

I've added a few more changes here wrt. scan_codebase_packages and inspect_manifest:

Current name	New name	Notes
scan_codebase_packages	inspect_packages	merged with SCTK part of inspect_manifest
inspect_manifest	resolve_dependencies	Has only the resolvers, just pypi for now
inspect_manifest	load_sbom	Just handles SPDX+CycloneDX+ABOUT files

This is at #1074

[AyanSinhaMahapatra]

Current state after #1074

[tdruez]

Renaming completed with #1074