A software deployment model where one interpreter or application instance is installed for multiple users and can later be launched by higher-privilege accounts. This model can be efficient, but it also creates a larger trust boundary if users can affect any part of the installation path.
Expanded Definition
Shared system-wide installation refers to a software deployment model in which one interpreter, runtime, or application instance is installed once and reused by multiple users or workloads. In NHI and IAM environments, the term matters because that single install location can become a common trust boundary for secrets, scripts, plug-ins, and execution hooks. The shared model is not inherently insecure, but it changes the impact of path tampering, package poisoning, and permission drift: if a lower-privilege user can modify the installation tree, they may influence what a higher-privilege account executes later.
Definitions vary across vendors when the runtime is managed by endpoint tools, software distribution systems, or developer platforms, so the security meaning should be read operationally rather than as a product label. A useful comparison is with per-user installation, which reduces shared exposure but can complicate standardisation and patching. For broader identity governance context, NIST Cybersecurity Framework 2.0 frames this as a protection and access-control issue, even when the software itself is not an identity component. The most common misapplication is treating a shared install as equivalent to a user-owned application, which occurs when write access, update rights, or plugin paths are not separated by privilege level.
Examples and Use Cases
Implementing shared system-wide installation rigorously often introduces operational convenience but increases the need for strict filesystem controls, so organisations must weigh easier patching against a larger blast radius for tampering.
- A Python interpreter installed under a system path is launched by a scheduled task running as a service account, so a writable site-packages directory becomes an escalation path if permissions are loose.
- A shared IDE or code editor installed for all users loads extensions from common locations, creating exposure when an attacker places a malicious module before a privileged session starts. This pattern has been discussed in NHIMG research such as Code Formatting Tools Credential Leaks and Hard-Coded Secrets in VSCode Extensions.
- A container host installs one shared CLI tool for all developers, but the binary path is also used by automation, so any untrusted update mechanism becomes a supply-chain concern.
- A workstation image is managed centrally, yet users can modify temporary cache folders that the runtime later trusts, echoing the kinds of token exposure issues seen in the JetBrains GitHub plugin token exposure case.
- A package manager is installed system-wide to simplify support, while policy requires read-only install directories and separate writeable caches for each user group.
For implementation controls, the strongest external baseline comes from the NIST Cybersecurity Framework 2.0, especially where software integrity and least privilege intersect.
Why It Matters in NHI Security
Shared system-wide installation becomes an NHI issue when the software installed for convenience is also the execution surface for service accounts, automation agents, API clients, or developer tooling that touches secrets. Once a privileged process relies on that shared path, the boundary between software integrity and identity compromise collapses. In practice, a modified plugin, altered binary, or poisoned dependency can be enough to turn routine execution into credential theft or unauthorized tool use.
NHIMG research shows how often identity risk is amplified by weak operational discipline: 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% causing tangible damage. That context matters because shared installs often sit next to the same insecure files, caches, and build paths that expose secrets in the first place. The security lesson is not simply to install software carefully, but to ensure the install location, update channel, and execution context are all treated as governed trust boundaries. Organisations typically encounter the real impact only after a privileged job executes a tampered runtime or plugin, at which point shared system-wide installation becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared installs expand the trusted execution path for NHI tooling and service accounts. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when one install is reused by many users and automations. |
| NIST Zero Trust (SP 800-207) | SC-4 | Zero Trust requires every execution path to be treated as untrusted until validated. |
Restrict write access to shared runtimes and verify binaries before privileged execution.
