Supply‑Chain Advisory: MeshCentral Build Provenance & Dependency Review #7701
TheBigBear
started this conversation in
General
Replies: 1 comment
-
|
I also added an issue to track progress on this. #7702 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
During a local containerized build of MeshCentral using npm ci --omit=dev, we observed multiple dependency deprecation warnings, including OTP‑related packages and glob@10.5.0. While npm audit reports no known vulnerabilities, deprecation warnings indicate maintenance and future security risk rather than immediate compromise.
Additionally, no public CI/build logs or provenance attestations (e.g. SLSA, SBOM, signed builds) are published for MeshCentral releases. This limits our ability to independently verify how release artifacts are produced, beyond rebuilding from tagged source.
This issue documents:
observed supply‑chain signals,
an assessment of actual runtime risk in our deployment model,
and recommended follow‑up actions.
Observations
Local build output (npm ci --omit=dev) emits deprecation warnings for:
glob@10.5.0
@otplib/plugin-crypto@12.0.1
@otplib/plugin-thirty-two@12.0.1
@otplib/preset-default@12.0.1
No CVEs are reported by npm audit.
Lockfile handling
package-lock.json is present in the repository and was recently restored after being temporarily removed, specifically to support deterministic packaging workflows (e.g. NixOS, container builds).
This is a positive signal, but it also highlights that reproducible builds were not consistently enforced historically.
Lack of published build provenance
MeshCentral releases provide:
source tags and commit references,
release notes and change history,
but do not provide:
CI build logs,
dependency manifests (SBOM),
cryptographic attestations linking artifacts to source commits.
This is common for community OSS projects, but it is a relevant risk signal for security‑sensitive deployments.
Dependency‑Specific Risk Analysis
A. glob@10.5.0
What is known (verified):
glob@10.x is flagged as deprecated by npm.
A public advisory (CVE‑2025‑64756 / GHSA‑5j98‑mcp5‑4vw2) affects the glob CLI, specifically the -c / --cmd option, which can allow command injection when filenames contain shell metacharacters.
The advisory explicitly states that the core glob library API is not affected — the vulnerability is confined to CLI execution paths.
MeshCentral usage assessment:
Based on inspection of the public MeshCentral repository structure and dependency usage patterns, there is no evidence that MeshCentral invokes the glob CLI binary.
MeshCentral appears to use Node.js dependencies as libraries via require() / import, not shelling out to CLI tools.
There are no documented references in public docs or repo structure indicating use of glob -c or equivalent shell execution.
Conclusion (glob):
Risk is low in MeshCentral’s context, provided:
glob is used only as a library (not via CLI),
build scripts do not execute glob -c on untrusted filenames.
However, continued use of a deprecated version increases long‑term risk and complicates future audits.
B. OTP (otplib v12 plugins)
What is known (verified):
otplib v12 and its plugins are deprecated upstream in favor of v13, which is a rewrite using more modern, audited crypto primitives.
v12 plugins have seen no releases for several years, indicating maintenance stagnation.
No active CVEs are currently reported for v12.
Important contextual factor: Azure Entra ID OIDC SSO
In our deployment:
Primary authentication is Azure Entra ID (OIDC).
Authentication is enforced before MeshCentral via oauth2-proxy.
MeshCentral is not the identity provider.
Azure Conditional Access, MFA, device compliance, and risk‑based policies are enforced upstream.
Implications:
MeshCentral’s OTP functionality (TOTP/HOTP) is not in our primary auth path.
Even if MeshCentral’s OTP implementation were weak or misconfigured:
it would not bypass Azure Entra ID MFA,
it would not allow unauthenticated access to the service.
OTP risk is therefore defense‑in‑depth only, not a primary identity control.
Conclusion (OTP):
Operational risk is low in an Entra ID‑fronted deployment.
Maintenance risk is moderate:
deprecated crypto‑adjacent code,
potential future incompatibility,
increased audit friction.
This is a tech‑debt signal, not an immediate security incident.
Beta Was this translation helpful? Give feedback.
All reactions