doc: document the required directory structure for git repo and the requirement that a container must be running on k8s cluster

[samcornwell]

Preamble:

When I first tried out installing this app, I manually generated a single sbom and put it in a repo. I was getting an empty results.json file. I hacked the code and enabled debugging output from the grype library. I found from the grype debug output that it was in fact running on my sbom and finding vulnerabilities, so I figured that the results were being filtered out for some reason. I ran the code through a debugger, and I found the function which extracted the "ImageID" from the file path, which puzzled me at first. It would always return ., which wouldn't match any containers in kubernetes. Then when I was looking at the sbom-operator, and saw the directory structure that it used. It then dawned on me that this directory structure was a requirement for vulnerability-operator to function correctly. My initial thought was that I should modify the code to extract the imageID from the sbom, but given the different sbom types and even differences between schemas of the same type (syft for example), this may take some effort to ensure this is done in a robust way.
Also it was not clear to me from the documentation that the results are also filtered out if there are no matching containers in the cluster. It would be nice at some point that the scanning of sboms could be decoupled from actively running containers in a cluster. For example, if I want to just scan all of the images in my registry that I have created sboms, or even just sboms that I have generated from a list of images that I have a particular interest in. I may open an issue for this at some point, but for the time being the functionality of scanning my cluster images is a very nice start.

Request:

Document that required file structure. Perhaps even just a link to the sbom-operator README.md indicating that this is the required file structure.

Document the fact that there must be containers using your scanned images in order for vulnerabilities to show up in your reports/metrics.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label with /remove-lifecycle stale or comment or this will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label with /remove-lifecycle stale or comment or this will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label with /remove-lifecycle stale or comment or this will be closed in 5 days.