Today syft generates SBOMs that best represent what we actually find. That being said there are use cases for changing what was found:

• the topology is too complicated and a simpler representation would be ideal.
• there is information missing that syft will never pick up on and it would be nice to be able to hint to syft what should be added or removed
• A previous run of syft had a configuration that resulted in a large SBOM (say capturing all files and digests) but we really only need a portion of the data there
• We are interested in a sub-selection of the package tree or set of packages, which would typically require crawling a graph via a description of the adjacency matrix and drop elements otherwise not observed during that crawl.

Users tend to write post-syft python scripts or large JQ queries to do these kinds of operations. Ideally, a user should be able to do these things without having to know about the target SBOM format (cyclonedx or spdx intricacies). In this way, this feels very similar to #564 .

I don't have a good proposal for what this could look like, but ideally it would have the following qualities:

• be accessible on the CLI / usable in scripts (something like syft edit ...)
• be performed on SBOMs already generated from syft (syft edit sbom.json)
• be performed on new SBOMs being generated (or allow syft scan ... | syft edit ...)
• acts as a scalpel for doing detailed operations (e.g. "drop packages with these properties" or "deduplicate packages via this heuristic") but also allows for expressing more complicated operations without requiring the user to write something that looks like code... so for example "flatten the package DAG keeping only direct dependencies" should require the user to know to iterate over packages and relationships.
• Talk in terms that do not require knowledge of a specific SBOM format shape, descriptions should stay at a high level and be applicable to all SBOM formats.