How should teams review React Native apps when Hermes bytecode hides the source code?

Why Hermes Bytecode Changes the Review Problem

Hermes is an execution format, not a readable source package. When a React Native app ships Hermes bytecode, reviewers lose the normal ability to inspect branching, module structure, and application logic directly, so the question becomes whether the bytecode can be reconstructed into a faithful intermediate form that supports real analysis. That shifts the task from basic inspection to recovery of behaviour.

For security review, the practical issue is not whether bytes can be viewed, but whether they can be interpreted well enough to answer questions about data flow, privilege boundaries, hidden conditionals, or unsafe feature exposure. A reviewer who only sees instruction fragments may miss logic that matters for fraud, leakage, or abuse.

Hermes bytecode therefore creates a visibility gap. The app may still be reviewable, but the review method has to match the artifact: compare the recovered structure, not just the raw disassembly, against the behaviour you expect from the app’s UI, API calls, and trust boundaries.

What Deterministic Decompilation Adds

Deterministic decompilation is valuable because it tries to recover stable structure from the bytecode, which is what teams need when they are checking actual program behaviour rather than isolated instruction sequences. In practice, that means reconstituting functions, branches, and module relationships closely enough to reason about control flow and sensitive operations.

This matters because security review often depends on context. A line-by-line instruction listing can show that something happens, but not always why it happens, what condition gates it, or whether the action sits inside a broader code path that changes its risk. When the goal is assurance, the reconstructed program shape is usually more useful than an unstructured dump.

Deterministic output is also important for repeatability. If the same artifact produces the same recovered structure, reviewers can diff versions, confirm whether a suspicious path is new, and separate actual code changes from tooling noise. That makes review more defensible when teams need to explain findings to engineering or governance stakeholders.

How Teams Should Review a Hermes-App Build

The safest approach is to treat Hermes review as a layered workflow. Start with bytecode analysis to establish what the build contains, then use decompilation when the question depends on control flow, module boundaries, or business rules. If the recovered structure is incomplete or ambiguous, continue validating against runtime behaviour, network calls, and source-level expectations from the app’s own interfaces.

Teams should also define the review objective up front. If the goal is simple triage, disassembly may be enough to identify obvious imports, strings, or suspicious call patterns. If the goal is security assurance, access control review, or data-handling validation, the recovered structure has to be good enough to support those judgments, otherwise the review is still operating with blind spots.

For deeper inspection, the most useful questions are whether the bytecode exposes hidden feature flags, alternate execution paths, hard-coded endpoints, unsafe storage of secrets, or logic that changes behaviour by environment or user state. Those are the places where Hermes visibility limits most often affect whether a reviewer can make a sound conclusion.

Risk and Threat Considerations

Hermes can raise review risk because obscured logic makes it easier to miss sensitive behaviour, weak trust assumptions, or embedded secrets during assessment. That does not mean the app is automatically unsafe, but it does mean superficial inspection leaves more room for false confidence, especially when teams rely on an unreadable artifact as if it were full source.

Failure mechanism: Reviewers rely on disassembly fragments or partial reconstruction, miss the higher-level program structure, and fail to spot data exposure paths, conditional abuse cases, or code paths that only appear under specific runtime states.

Impact: Security teams may sign off on an app without understanding how it behaves in edge cases, which can delay findings about information disclosure, policy bypass, or logic flaws until after release.

Practitioner Guidance

What to verify: If the review question is about behaviour, insist on a decompilation result that preserves function boundaries, branching, and module relationships well enough to explain why a path exists, not just that instructions exist. If the output cannot support that level of reasoning, treat it as triage evidence, not assurance evidence.

Decision rule: Use disassembly for rapid screening, but switch to deterministic decompilation whenever the conclusion depends on business logic, privilege-sensitive code, or anything that changes meaning with control flow. That is the point where a partial view becomes operationally risky.

Practitioner takeaway: Hermes bytecode review is only trustworthy when the method matches the question, meaning the team should recover structure whenever the security decision depends on understanding behaviour rather than merely observing instructions.

Related resources from NHI Mgmt Group

• How should security teams review React Native apps when source code is not available?
• How should security teams combine AI-native scanning with deterministic SAST for code review at scale?
• What breaks when security teams review source code but ignore compiled artifacts in agent workflows?
• What breaks when teams rely on manual code review alone for open source package safety?