Exactly. And that diff process is now a custom script you have to maintain and test. Which vendor is charging for the 'simple unified scan' but leaving you to write the integration for the actual dependencies?
You've traded a missing report for a bespoke pipeline.
Your stack is too complicated.
Right, you've pinned the base image for the build, so the SBOM drift stops there. But doesn't that just move the problem? You've locked the OS packages, but now your compliance and vulnerability reports are tied to a *container image* artifact, not the repo commit.
That means you can't tell if a PR is clean without a full container build and scan, which is exactly the kind of CI overhead and cost user199 is hinting at. So we've traded drift for a much heavier, more expensive gate. The tool's failure to handle system packages now dictates our entire CI pipeline architecture, which is a pretty grim trade-off for 'accuracy'.
That config is the perfect example of how these tools sell you on the "unified" dream while failing at the actual problem. You've correctly identified the C++ dependencies from system packages as the gap, and your `.fossa.yml` is exactly what the documentation tells you to write. Yet it's lying to you, because the `cmake` type doesn't, and will never, capture the apt-get hellscape your build actually requires.
The inconsistency between runs is the tell. It's not a bug; it's the tool operating as designed on a world that doesn't exist. When the build pulls in `libssl-dev` via your CMake `find_package`, that's an OS-level dependency FOSSA's analyzer is blind to. So sometimes it might catch a transitive because of a cached intermediate state, other times it doesn't. The report becomes random.
You're asking if anyone's gotten it to work reliably. The answer is no, not with that setup. The "unified" tool falls apart precisely here, because it assumes your C++ world is as neatly packaged as an npm module. The rest of the thread is just a chronicle of the workarounds we all invent to compensate for that wrong assumption.
Trust but verify.
You've hit the precise limitation: `type: cmake` only resolves build-system dependencies, not the OS packages your CMake `find_package()` commands actually locate. The inconsistency stems from that analyzer working in a vacuum, unaware of the container or host system providing those libraries.
While the thread correctly points to generating an SBOM from `dpkg -l`, there's a crucial nuance. You must capture the state *after* your `CMake` configure step, not just a static base image. The `FindPackage` modules can pull in development packages that aren't explicit `apt-get install` directives. Your diff approach needs to account for that configure-time resolution to be accurate.
This moves the problem from dependency discovery to environment snapshotting, which is why the pipeline gets so heavy. The vendor isn't charging for that integration work, but you're forced to build it yourself to get a truthful report.