An interpreted language is executed by a runtime rather than compiled ahead of time into native machine code. In practice, this usually makes development faster and experimentation easier, but it can also reduce runtime performance compared with compiled languages that are optimised for execution speed and system-level control.
How Interpreted Languages Work
An interpreted language is defined by how code reaches execution: the runtime evaluates source, bytecode, or an intermediate form at execution time instead of producing a fully native binary ahead of time. That runtime layer is what shapes portability, startup behaviour, and the trade-off between flexibility and raw speed.
This model can be direct source interpretation, virtual-machine execution, or just-in-time compilation inside the runtime. In practice, the label is often used broadly, so usage in the industry is still evolving across language communities and implementation styles.
Execution Model and Runtime Behaviour
The important distinction is not simply whether compilation happens, but where the final execution decision is made. Interpreted languages depend on a runtime to load code, resolve types or symbols, manage memory, and enforce language semantics while the program is running.
That runtime dependency usually makes the language easier to inspect, modify, and experiment with during development. It also means performance depends heavily on the interpreter or virtual machine, the quality of any JIT optimisation, and how often the program crosses runtime boundaries for dynamic dispatch or reflection.
Why Interpreted Languages Are Used
Interpreted languages are popular where iteration speed matters more than low-level control. They are common in scripting, glue logic, automation, prototyping, and application layers where developer productivity and portability outweigh the need for maximum execution speed.
Because the same source can often run across different operating systems with only a suitable runtime installed, teams may use interpreted languages to reduce distribution friction. That convenience can make them a strong fit for tools, orchestration, and rapidly changing business logic.
Trade-Offs and Practical Consequences
The main trade-off is flexibility versus predictability. A runtime can improve portability and development agility, but it can also introduce startup overhead, variable performance, and more dependence on the execution environment than a compiled binary would have.
For security and operations, the runtime becomes part of the trusted computing base. If the interpreter, standard library, dependency chain, or plugin mechanism is weak or misconfigured, the application inherits that exposure even when the source code itself is correct.
Risk and Threat Considerations
Interpreted languages often expand the attack surface because they rely on a rich runtime, dynamic features, and external packages. That flexibility can increase exposure to unsafe deserialisation, code injection, dependency compromise, and execution of untrusted input when developers treat the runtime as automatically safe.
Failure mechanism: Dynamic execution paths, permissive package ecosystems, and runtime evaluation of input can turn ordinary application features into code execution or supply-chain entry points.
Impact: A compromised runtime or dependency can lead to remote code execution, data theft, persistence, or broad application-level compromise, especially when the language is used in systems that process untrusted content.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Interpreted runtimes shape code execution and secure design decisions. |
| Recommendation — Constrain dynamic execution paths and review runtime-dependent design choices. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Runtime-evaluated input in interpreted languages directly affects code injection risk. |
| Recommendation — Validate untrusted input before it reaches runtime evaluation paths. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Interpreted-language applications depend on secure development and dependency handling. |
| Recommendation — Harden application build and dependency practices for interpreted code. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Interpreted-language ecosystems rely heavily on external packages and build provenance. |
| Recommendation — Verify artifact provenance and dependency integrity for runtime-delivered code. | ||
Practitioner Guidance
What to watch for: Treat the runtime, package manager, and update path as first-class security dependencies. Interpreted languages are easiest to use safely when teams know exactly which runtime version, libraries, and execution flags are allowed in production.
Governance implication: Ownership should include runtime patching, dependency review, and rules for dynamic features such as eval-like execution, plugin loading, and reflection. Those controls matter because they shape both operational stability and the practical security boundary of the application.
Related resources from NHI Mgmt Group
- Why should identity teams be cautious about natural-language queries over access data?
- Why does broad NHI language create risk for IAM programmes?
- Why does natural-language access create new risk in workload identity operations?
- How can teams decide whether to use SQL or natural-language-style tools for agents?
