Yes. If a supply chain review only covers the signed package or installer, it can miss the files that actually run at execution time. Teams should review adjacent runtime components, search paths, and deployment locations as part of provenance and endpoint control, because the attack often succeeds without altering the vendor’s primary binary.
How sideloaded DLLs fit into provenance reviews
Yes, because provenance is not just the signed package you downloaded, it is the full set of components that can execute once the application starts. Sideloaded DLLs are part of that execution chain when they are loaded from adjacent directories, search paths, or deployment locations, so a review that stops at the installer can miss the real attack surface.
That matters because provenance review is meant to answer a practical question: what code can this software actually run in its deployed state? If a benign vendor binary loads a nearby library at runtime, the trust decision has to extend to that library and the loading conditions, not just the primary executable.
Why adjacent runtime components change the trust decision
software provenance is often framed around build artifacts, signatures, and release integrity, but sideloading shifts the control point to runtime resolution. The key issue is not whether the original package was authentic, it is whether the execution environment allows a different file to be substituted, discovered first, or dropped into a writable path that the process will trust.
That is why teams should review search order, working directories, plugin folders, updater paths, and any location where an attacker or untrusted process could plant a library. SLSA is useful here because it formalises build provenance, but sideloading shows that build integrity alone does not finish the job if runtime loading remains uncontrolled.
For defenders, the review scope should include the executable, its dependent libraries, and the deployment permissions around those files. If a binary is signed but it runs unsigned or untracked code from the same folder, the provenance boundary is already wider than the installer review suggests.
What good provenance review looks like in practice
A useful review starts by mapping what actually loads at execution time, then asks whether each component is expected, pinned, and protected. That includes checking whether the process loads libraries from safe locations, whether DLL search order is predictable, and whether application directories are writable by low-privilege users.
What to verify: confirm the full runtime dependency set, not just the package manifest. Validate which directories are searched, whether library names can be shadowed, and whether the host enforces permissions that prevent unauthorized file placement.
What to measure: track how many production applications rely on implicit runtime discovery, writable loading paths, or unmanaged plugin directories. Those patterns often indicate where provenance review is too narrow and where endpoint hardening is needed.
Common mistake: treating code signing as a substitute for environment control. Signing can prove origin for the main artifact, but it does not prevent a process from loading a malicious sidecar DLL if the filesystem and execution policy allow it.
Risk and Threat Considerations
Sideloaded DLLs create a classic trust-boundary failure: the vendor binary may be legitimate while the library it loads is not. Attackers favor this pattern because it can preserve the appearance of a trusted process while silently changing its behavior, especially when defenders only inspect the primary executable or software bill of materials.
Failure mechanism: a malicious or substituted DLL is placed where the application will load it first, or the process is steered into loading it through search-order abuse, writable paths, or deployment gaps. The original signed binary stays untouched, so traditional provenance checks may pass even though execution is compromised.
Impact: the attacker can gain code execution inside a trusted process, bypass simple allowlisting assumptions, and reuse the application’s permissions, network reach, or user context. At scale, this becomes a deployment and endpoint integrity problem, not just a packaging problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain levels for software artifacts | Build provenance is central to reviewing shipped code and dependencies. |
| Recommendation — Map runtime-loaded components into provenance controls and require protected, traceable artifact paths. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Integrity controls address unauthorized code substitution at execution time. |
| Recommendation — Validate loaded modules and restrict unauthorized changes to executable and library paths. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Software asset inventory must include runtime components beyond the installer. |
| Recommendation — Inventory runtime libraries and plugins so sideloaded components are visible to review and control. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Configuration management covers trusted paths and execution-location hardening. |
| Recommendation — Control application directories and load paths as part of secure configuration management. | ||
Practitioner Guidance
What to prioritise: treat runtime load paths as first-class provenance data. If the application can load code from any location outside a tightly controlled trust set, review that location with the same rigor you apply to the signed package.
Decision rule: if a library or plugin can influence execution without being covered by the original release artifact, include it in provenance review and endpoint hardening; if it cannot be controlled, assume the trust boundary is incomplete.
What good looks like: the application loads only expected components from protected directories, writable paths are removed from the trust chain, and operations can explain every executable file that may run in the deployed environment.
Practitioner takeaway: provenance review should answer “what code can run here?” rather than “what did we ship?”, because sideloading exploits the gap between those two questions.
Related resources from NHI Mgmt Group
- When should security teams treat NHI governance as part of compliance work?
- How should security teams use compliance management software for access reviews?
- Should security teams treat field mapping as part of authorization design?
- What do security teams get wrong about provenance in software delivery?