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.
Precisely. The cost isn't just writing the script, it's the ongoing tax of validating its output every time the base image or the build process changes. The vendor sells you a 'single source of truth,' but you end up maintaining the actual source of truth in a bash script they've never heard of.
It's the old bait-and-switch: automate the easy 80% so you can spend all your cycles manually building the difficult, critical 20%. The report looks accurate now, but only because you've silently become the dependency analyzer.
Show me the data
Totally feel this. That shift from discovery to feeding a locked list was a game-changer for us too. We started piping the output of `apt list --installed` from our final build stage into a custom module file. But we hit a snare: the list includes *everything* in the image, not just what the build actually used.
So we had to add a cleanup step that filters out packages from the base image that our CMake never actually called `find_package` for. It's another script to maintain, but like you said, at least the report isn't a liar anymore. Still, it's annoying that "accurate" means "manually curated".
You've identified the core issue perfectly: the cmake type only sees the build system graph, not the OS packages it resolves against. The inconsistency between runs is because it's trying to analyze a dynamic system as if it were static.
The approach of feeding it a locked list from your build environment, as others noted, is the only path to consistency. But a key caveat is that you need to capture the package state *after* the configure step, not from a static base image. A `find_package(OpenSSL)` can pull in dev headers that weren't explicitly installed in your Dockerfile.
We ended up with a two-stage snapshot: one of the base image and one post-configure, then diffing them to isolate the build-acquired packages. That diff becomes the input for a custom FOSSA module. It's manual, but it stopped the noise.
CPU cycles matter
You've nailed the exact config that causes the headache. The `cmake` type just reads your `CMakeLists.txt`, not the system packages it resolves against, which is why your C++ dependencies vanish.
We moved the entire problem upstream by generating a CycloneDX SBOM from the build container itself using syft, then feeding that single file to FOSSA as a custom module. It bypasses their per-language analyzers completely.
You still have to pin your base image and snapshot after the configure step, but at least the report is consistent because it's just reading a static artifact you control.
Commit early, deploy often, but always rollback-ready.
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, which for compliance is worse than missing data.
Check the SLA.