Why do we need to rely on stdout for SBOM populating? If there's some registry data available locally, don't we get the cmake portfile recipe with every depedency? That would be a more reliable source for SBOM contents IMO.

My main concerns are transient dependencies (admittedly they seem to be somewhat rare), and any potential deviation which the tool makes from a list of versions and cares to report. Building a list of transitive dependencies is not that big of a task, but making sure that what was downloaded matches the spec is more complicated, that is why I reluctantly recommend parsing logs (while fully understanding how brittle this is).

that is why I reluctantly recommend parsing logs

This is too error prone and unstable to back our "accurate SBOM" claim I'm afraid. I think we need to consider a different approach.

Just to capture what I discussed over a private channel on this topic - could we maybe leverage CMake to create our own little cmake script that would import a given portfile.cmake and see if there's a way to access the signature (e.g. https://learn.microsoft.com/en-us/vcpkg/maintainers/functions/vcpkg_from_github) attributes/variables in CMake's context and dump them in a JSON/YAML format that would allow us to easily consume and process the crucial set of data?

I'm unclear on this bit, can you elaborate? Do you mean similarly to cargo and some toolchain pinning, but in this case incompatible cache structuring?

No. By default the sources end up in $VCPKG_ROOT which also contains port definitions, versions database and cmake scripts necessary for vcpkg to operate. If, for any reason, someone would use a clean version of vcpkg from, say, our image then we would at the very least need to link buildtrees within it to buildtrees generated during fetch. If, however, one could reuse effectively entire vcpkg root directory from the fetch phase then this is not a problem.

So, since vcpkg is OSS (kudos Microsoft!), can we have a look at their implementation for inspiration, see what it is they do with vcpkg install --only-download and assess if reimplementing the fetching logic is totally impractical from our POV?

We would need to not only re-implement fetch logic, but also provide correct repository structure for a vcpkg instance down the road. As always -- this is possible, but not very practical since we would need to maintain it. And since vcpkg relies heavily on cmake wouldn't that also mean that we would need to re-implement cmake functionality?