Source-to-Code Conversion

A security-sensitive transformation where application input is turned into executable source text and compiled at runtime. The risk is not the presence of a parser, but the moment untrusted data becomes code under the privileges of the running process.

Expanded Definition

Source-to-code conversion is not just parsing or template rendering. It is the point where external input is transformed into executable source text, then compiled or interpreted with the privileges of the current process. In NHI security, that privilege boundary is critical because secrets, tokens, and service identities can be used to generate code paths that the operator did not intend.

Definitions vary across vendors when this pattern appears inside low-code builders, dynamic scripting, code generators, or agent workflows. NHI Management Group treats the term narrowly: the security event begins when untrusted data can alter executable logic, not merely when it is displayed, validated, or stored. That distinction aligns with control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where code integrity and least privilege must be preserved.

Source-to-code conversion is often confused with safe parameterization or server-side templating, but those mechanisms do not become dangerous until the input can change executable instructions. The most common misapplication is treating any runtime code generation as equivalent to ordinary input handling, which occurs when developers assume the parser itself is the only trust boundary.

Examples and Use Cases

Implementing source-to-code conversion rigorously often introduces design and testing constraints, requiring organisations to weigh developer flexibility against the risk that attacker-controlled input becomes executable logic.

• Generating a script from an API payload, then running it under a service account that has access to secrets or infrastructure APIs.
• Building SQL, shell commands, or configuration code from request data instead of using strict data structures and fixed command templates.
• Compiling policy, workflow, or agent tool instructions at runtime, where a compromised token can alter the generated execution path.
• Using machine keys or hard-coded credentials in a conversion pipeline, as seen in ASP.NET machine keys RCE attack and Gladinet Hard-Coded Keys RCE Exploitation.
• Embedding untrusted text into generated source during CI/CD, then compiling it with the build identity instead of a restricted sandbox.

For implementation patterns that reduce exposure, teams often cross-check language-specific guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls and then map the runtime generation step to explicit approval and isolation controls.

Why It Matters in NHI Security

Source-to-code conversion is especially dangerous in NHI environments because machine identities often hold broad permissions and can reach secrets, pipelines, and deployment targets. When input becomes code inside that trust domain, compromise scales quickly from a single malformed request to privileged execution. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes any code-generation path reachable by those identities a high-value target.

Used carelessly, the pattern turns every integration into a potential execution surface. It also complicates governance because auditors must reason about both the origin of the data and the authority of the runtime identity. That is why teams should treat generated source as an identity-bound artifact, not as inert text, and verify where it is compiled, what it can access, and whether its inputs are constrained.

Organisations typically encounter the real impact only after a malicious payload compiles successfully or a service account is abused to pivot through the build path, at which point source-to-code conversion becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why is hardcoding credentials into source code so dangerous?
• Why do secrets in source code create NHI governance problems?
• How should security teams protect source code repositories from identity abuse?
• Why do source code systems need behavioural monitoring?