Call-time execution is malicious behaviour that triggers when a program invokes a library function, rather than during installation or update. This pattern is hard to catch with metadata checks alone because the package appears harmless until the caller reaches the relevant code path.
Expanded Definition
Call-time execution describes a supply chain attack pattern where malicious code stays dormant until a specific function is invoked, then executes only when the application reaches that code path. In software security, this matters because a package can pass basic review, dependency scanning, and even superficial sandbox checks while still containing hidden behaviour. The term is closely related to runtime-triggered malicious logic, but it is narrower than general malware detection because the activation point is tied to a library call rather than installation, update, or first launch.
Definitions vary across vendors and blog coverage, but the practical meaning is consistent: the risk sits in the interaction between the caller and the dependency, not just in the artifact itself. That is why call-time execution is easier to miss in environments that rely heavily on metadata, static package reputation, or version pinning alone. NIST’s NIST Cybersecurity Framework 2.0 is relevant here because it emphasises governance and risk management across software and third-party dependencies, not just perimeter controls. The most common misapplication is treating call-time execution as a packaging problem, which occurs when teams only inspect artifacts before deployment and never test the invoked code path.
Examples and Use Cases
Implementing controls for call-time execution rigorously often introduces more testing overhead and slower dependency adoption, requiring organisations to weigh rapid delivery against deeper runtime validation.
- A malicious utility library looks harmless during upload, but triggers credential exfiltration only when an application calls its parsing function.
- An internal build pipeline approves a dependency because its manifest is clean, yet the risky logic activates later when the app processes real user input.
- A software team uses NIST Cybersecurity Framework 2.0 aligned supplier reviews, then adds runtime testing to detect code that behaves differently at invocation time.
- A security analyst discovers that a package only launches its payload when a specific optional feature is enabled, which means normal smoke tests never exposed it.
- A dependency in a CI/CD pipeline passes signature verification, but the harmful branch executes only when an application’s library call reaches an uncommon error-handling path.
In practice, call-time execution is most often observed in software supply chain scenarios where attackers expect reviewers to focus on what a package is, rather than what it does after a call. That makes this pattern especially relevant for teams using secure build pipelines, code signing, and repository allowlists, because those controls can still miss logic that activates only under runtime conditions. Guidance from NIST Cybersecurity Framework 2.0 supports broader dependency risk management, but it does not replace runtime assurance. The key lesson is that trust in the package format is not the same as trust in the function behaviour.
Why It Matters for Security Teams
Call-time execution changes how defenders think about code trust. If teams only inspect installation events, they can miss malicious logic that remains inert until production traffic or a specific workflow activates it. That creates blind spots in AppSec, DevSecOps, and third-party risk management, especially where libraries are reused across services and their full call surface is never exercised in testing. For security teams, the issue is not just malware detection but assurance that a dependency behaves consistently across the paths that matter.
This concept also connects to identity security when libraries process secrets, tokens, session data, or service credentials at runtime. A dependency that looks benign at install time can still become the point where secrets are accessed, transformed, or exfiltrated during execution. Security teams should therefore pair package review with behavioural testing, provenance checks, and monitoring around sensitive function calls. Organisations typically encounter the operational impact only after a suspicious library call has already touched production data, at which point call-time execution becomes unavoidable to investigate.
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 surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 | Addresses supply chain risk governance for third-party software dependencies. |
| OWASP Non-Human Identity Top 10 | NHI-5 | Covers secret-bearing workloads where runtime library behaviour can expose credentials. |
| NIST SP 800-53 Rev 5 | SA-11 | Supports testing and verification of system components before deployment. |
| ISO/IEC 27001:2022 | A.5.19 | Addresses information security in supplier relationships and acquired components. |
| NIST AI RMF | Relevant where AI-enabled applications call libraries that can alter behaviour at runtime. |
Protect secrets used by applications and inspect libraries that handle them at runtime.
Related resources from NHI Mgmt Group
- Who is accountable when a critical platform flaw affects identity and code execution at the same time?
- What do security teams get wrong about hardening only install-time package execution?
- How should security teams handle package install-time execution in CI environments?
- How do security teams decide whether to block prompt injection at discovery time or at call time?
