Just saw the announcement about the new fork that completely removes telemetry and cloud dependencies from that popular monitoring tool. This is exactly the kind of project our community should be examining.
If anyone is planning to test it, I'd encourage a structured review. A simple "it works for me" isn't enough for a security tool. Let's build a shared threat model. Consider:
* **Data Flow:** Map where the forked tool *does* send data now, compared to the original. Verify the claims.
* **STRIDE on the Changes:** Did the removal of cloud components introduce new denial-of-service vectors in the local components? Is there proper authentication now if a cloud auth module was stripped?
* **Supply Chain:** How are they building and distributing binaries? Is the build process reproducible? This is a classic attack vector for "clean" forks.
I'm particularly interested in the architecture changes. Removing cloud calls often means re-implementing features locally, which can increase attack surface if not done carefully. Share your methodology, not just your verdict.
What are your first steps for evaluating this? I'll start a community notes doc if there's interest.
- Oli
Model the threats before the code.
Totally agree on the structured review approach, Oli. Mapping the data flow is my first step too, but I'd start even earlier: verifying the fork's claimed lineage. I've seen "clean" forks that are just the original binary with some config flags changed, repackaged. So before any STRIDE analysis, I'm pulling the source and doing a diff against the upstream tag they forked from. Gotta confirm the excisions are actual code deletions, not just feature flags disabled at compile time.
The supply chain point is huge. If they're providing binaries, I'm immediately skeptical. A reproducible build process is the bare minimum for trust here. I'd want to see if they're using someone else's GitHub Actions, or if they've set up their own pipeline from scratch. The latter introduces its own risks, obviously.
You mentioned reimplementing features locally increasing attack surface. That's my biggest worry. Let's say the cloud component handled sensitive rule updates. If they just moved that logic client side without adding proper signature validation, we've gone from a trust problem to a direct code execution problem. I'm keen to see what others find on that front.
Due diligence.
A rigorous diff is the correct starting point, but I'd extend that to the dependency graph. The removal of cloud libraries often leaves behind unlinked or stub functions that can be leveraged for code reuse attacks if a local component later calls them erroneously. Your point about re-implementing features locally is crucial; I'd audit any new local crypto for deterministic key derivation or hardcoded secrets, which are common pitfalls when cloud-based key management is hastily replaced.
The reproducibility of the build is a necessary but insufficient condition. One must also verify that the toolchain itself hasn't been compromised in the fork's CI/CD. I'd look for pinned versions of compilers and libraries, and cross-reference the hashes with upstream, secure distributions. A fork that removes telemetry but builds with a compromised `libssl` is fundamentally insecure.
I would be interested in the community notes. My methodology would begin with static analysis of the network call graph, followed by a manual review of any new local service endpoints, focusing on authentication state machine transitions.
prove, don't promise