Common signs include unexpected bidirectional control characters, function names that contain visually confusing homoglyphs, and code lines that appear commented out or reordered only in the editor view. Another indicator is a mismatch between visual rendering and syntax highlighting versus actual parse or runtime behavior. These cues warrant automated inspection and manual verification.
How Trojan Source works in practice
Trojan Source is a source-code deception technique, so the most useful signs are the ones that show a mismatch between what a reviewer sees and what the compiler or interpreter actually receives. That usually means hidden Unicode control characters, visually confusable identifiers, or structure that appears reordered or commented out only in the editor. The code may look plausible to a human while parsing differently for the machine.
The strongest clue is not a single weird character by itself, but an inconsistency across tools. If syntax highlighting, editor rendering, linting, and parse results do not agree, the file deserves closer inspection. In practice, that is the point at which a visual review stops being trustworthy and you need character-level inspection.
For background on the attack pattern itself, MITRE ATT&CK Enterprise Matrix is a useful reference for understanding how adversary techniques are classified and how they map to detection and response work.
Where reviewers usually miss the deception
Trojan Source issues often survive normal review because they exploit assumptions in how code is displayed, not just how it is stored. A line can appear to end a comment when the underlying bytes make the comment boundary behave differently, or an identifier can look like a familiar function name while using homoglyph characters that are not the same code points. That makes human review especially vulnerable when the code is short, familiar, or copied from another file.
These problems are especially risky in repositories where developers rely on diff views, pasted snippets, or rendered markdown rather than inspecting raw source. The practical danger is that a malicious change can look like a harmless formatting edit, while the executable meaning changes underneath. If a file contains characters outside the expected language or encoding profile, treat that as a review trigger rather than a cosmetic oddity.
Trojan Source is also a code-integrity problem, not just a code-reading annoyance. For background on source-code exposure and repository abuse patterns, New York Times breach and GitLocker GitHub extortion campaign show how source-code trust failures and credential misuse can compound each other in real environments.
What to check before you trust the file
Use automated checks that surface invisible characters, suspicious Unicode ranges, and identifier collisions, then confirm the output with a raw-view inspection. A useful practice is to compare three views: the editor view, the diff or syntax-highlighting view, and the raw text or byte-level representation. If those disagree, the file should be treated as untrusted until the discrepancy is explained.
- Look for bidirectional control characters in comments, strings, and identifiers.
- Compare visually similar names against canonical spelling and code-point values.
- Inspect any line that appears commented out, reordered, or syntactically harmless only in one tool.
- Escalate files that pass linting but fail visual or parse consistency checks.
There is no universal standard for every review pipeline yet, but current guidance is to make this a repeatable verification step rather than a one-off forensic exercise. If the repository handles sensitive logic, pair static detection with code review rules that reject unexpected Unicode in executable paths. For broader secure-code handling and code-review hygiene, OWASP API Security Top 10 is a useful adjacent reference for authorisation and input-trust failures, and OWASP Cheat Sheet Series provides practical implementation guidance for defensive coding and review discipline.
Practitioner takeaway: Treat Trojan Source as a trust-break between visual review and executable source, and require an automated character-level check whenever a file contains unusual Unicode, unexpected formatting, or tool-specific rendering differences.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Trojan Source hides intent with deceptive Unicode and rendering tricks. |
| T1036 — Masquerading | Visually confusable names and reordered text mimic legitimate code. | |
| Recommendation — Detect obfuscation patterns in source changes and inspect raw text for hidden controls. Flag identifiers and comments that impersonate trusted names or normal code structure. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Improper Validation and Handling of Secrets | Trojan Source can conceal sensitive code paths and embedded secret-like material in source. |
| Recommendation — Scan source for hidden characters and enforce validation before code is accepted. | ||
Related resources from NHI Mgmt Group
- What are the signs that an open-source contribution campaign is being gamed rather than used for meaningful collaboration?
- What breaks when open source SSO is used without enterprise processes?
- How should security teams evaluate open-source cryptographic libraries used in identity flows?
- What breaks when source-IP allowlisting is used as the main trust signal?
