We should be able to produce Software Bill of Materials (SBOM) for the images that are built by Buildah.

In RHTAP's buildah task, the syft command is run from an AppStudio image image, both against the contents of the image and against the build contexts that were used to create it, to generate SBOMs in CycloneDX format. The produced JSON documents are merged, and the result is stored both in the image as a file named "/root/buildinfo/content_manifests/sbom-purl.json", and pushed to a registry as an artifact by running "cosign attach sbom --sbom ... --type cyclonedx imageReference".

While buildah isn't itself a pipeline, the RUN instruction can be given access to build contexts and the rootfs of another image, and that's enough for us to be able to approximate the results of the pipeline. Given a Containerfile, something like this should produce a comparable set of files for us to work with:
{{
... (provided Containerfile, through the target stage, for this example declared "... AS finalStageAlias")
FROM ubi9-micro AS syftWithShell
COPY --from=ghcr.io/anchore/syft / /
RUN --mount=type=bind,from=finalStageAlias,src=/,dst=/image syft packages dir:/image --output cyclonedx-json --file /spdx-image.json
RUN --mount=type=bind,src=/,dst=/buildcontext syft packages dir:/buildcontext --output cyclonedx-json --file /spdx-buildcontext.json
(repeat for all defined build contexts)
...
}}
At that point, buildah would be able to dig out the various documents, merge them in a way comparable to the way the pipeline does with a python script, and save the document to a file. It could then build an image derived from `finalStageAlias` which ADDs the generated file in the right location. It should also be able to save the file to a specified location, in anticipation of our figuring out how to pull, store, and push image artifacts from and to image registries.

For `buildah build`, this would take the form of a new `--sbom` flag which takes a list of key=value arguments, offering at least these:

• a way to specify or override the image name (the default being one we've mirrored to quay.io, or the AppStudio one)
• a way to specify that we should exec a `syft` command that isn't in an image, but is just on the host somewhere in $PATH
• the optional local filepath where the final SBOM should also be written
• the optional local filepath where the final SBOM should also be written as an OCI artifact with the SBOM as inlined data

For `buildah commit`, the `--sbom` flag would also include an option, which could be provided more than once, pointing to a directory to treat as a build context (i.e., scan it, and merge the produced SBOM in along with others).

We'll need to flag down someone who is more familiar with how `buildah source` is used to specify if `buildah source add` should be scanning files which are passed to it, and how they should be stored.

Implementation-wise, the layer blob with the new file would be generated in-memory and appended to the list of layers during commit, rather than being handled by creating a new working container, using the Add() APIs, and committing the result.