Should organisations prioritise runtime execution controls over more package pinning?

What changes when package pinning is not enough

Package pinning is still useful, but it only constrains what you intend to install. It does not stop a malicious or compromised package from doing harm once it is present on the host, in the container, or inside the application process. That is why runtime execution controls matter: they reduce the impact of code that has already crossed the install boundary.

In practice, the decision is not “pinning or runtime controls”, it is “where do you want the failure to be contained?” Pinning, provenance checks, and trusted publishing reduce the chance of accepting a bad dependency. Runtime controls constrain what that dependency can touch if validation fails or if a trusted package is later poisoned upstream. The LiteLLM PyPI package breach is a useful reminder that compromise can turn into credential exposure after the package is already in the supply chain.

The strongest operational pattern is layered defence. Use pinning to make dependency changes deliberate, use provenance and trusted publishing to reduce package tampering risk, and use runtime controls to limit filesystem access, network reach, child-process spawning, and secret access. If the package is ever allowed to run, the runtime policy becomes the last line that still has a chance to stop persistence and exfiltration.

Why runtime controls are the decisive layer after install

Runtime execution controls are decisive because they address what the package can do, not just what version it is. A pinned dependency can still execute malicious code during import, post-install hooks, test-time execution, or normal application startup. Once execution happens, the attacker is no longer relying on package selection alone, they are relying on whatever the runtime will permit.

That is especially important for secrets and persistence paths. A poisoned package often tries to read environment variables, discover cloud credentials, reach metadata services, write startup files, schedule tasks, or call out to a staging host. Runtime guardrails that block outbound network access, deny unexpected writes, and restrict secret access can sharply reduce those paths even when the package itself is not detected immediately. NIST SP 800-190 Container Security is directly relevant here because it treats image, registry, orchestrator, and runtime risk as separate control points rather than assuming build-time controls are sufficient.

Pinning also tends to fail more quietly than people expect. It is effective against drift, but it does not help when the pinned artifact is the wrong artifact, when a maintainer account is compromised, or when the package’s own behaviour becomes the attack path. Runtime controls reduce the blast radius of those cases by making execution permissions explicit and narrow.

How to combine pinning and runtime control without over-rotating on either

Use pinning to stabilise the supply chain, then verify that runtime policy matches the actual privileges the application needs. If a service only needs outbound access to one API and read-only access to one secret, its runtime should reflect that minimal envelope. If the application truly needs broad capabilities, treat that as an exception and justify it explicitly rather than assuming dependency hygiene is enough.

In containerised and cloud-native environments, the practical question is whether the package can still perform harmful actions even if its artefact was approved. That means checking seccomp, AppArmor, SELinux, container escape exposure, shell availability, service account scope, network egress, and secret injection paths. OpenSSF is a useful discovery point for supply-chain hardening practices, but the underlying control choice remains the same: reduce install-time exposure, then constrain execution-time damage.

Where teams get into trouble is treating dependency management as the whole control plane. Package pinning reduces uncertainty, but it does not enforce least privilege at runtime. If your runtime can still read all secrets, reach the internet freely, or modify persistence locations, a poisoned package has plenty of room to operate.

Practitioner Guidance

What to prioritise: If you can only improve one area quickly, focus on the runtime paths that secrets and persistence rely on, because those controls still help after a bad package is already installed and running.

What to verify: Confirm that the application only has the network, filesystem, process, and secret-access rights it genuinely needs. If the package can reach credentials or persistence mechanisms it should not need, the runtime policy is too loose even if dependency pinning is perfect.

Decision rule: If the concern is “can we avoid ever installing a bad dependency?”, strengthen pinning and provenance. If the concern is “what happens if a bad dependency runs anyway?”, prioritise runtime execution controls first, because they are the containment layer that still matters after supply-chain failure.

Practitioner takeaway: Dependency pinning reduces the chance of compromise, but runtime control determines whether compromise becomes a contained event or a full environment problem.

Related resources from NHI Mgmt Group

• When should organisations prioritise runtime guardrails over model-focused AI controls?
• When should organisations prioritise runtime AI controls over static approvals?
• When should organisations prioritise runtime privacy controls over governance documentation?
• When should organisations prioritise static discovery over runtime-only AI security controls?