A practical guide to reviewing eval, innerHTML, command execution, SQL construction, weak crypto, and embedded-secret signals in context.
The correct role of a pre-scan
A lightweight in-browser pre-scan exposes selected syntax patterns with line numbers. Before a pull request, flags for eval, innerHTML, child_process, dynamic SQL, weak hashes, or secret-like constants can direct attention quickly.
Regex cannot understand data flow, framework sanitization, authorization, dependency versions, or runtime behavior. A finding is not automatically a vulnerability, and a clean scan is not approval. Triage should point to review, not replace it.
Trace source, transformation, and sink
Manual review identifies a user input, API response, file, or environment value as a source. It follows validation, normalization, and authorization until the value reaches a DOM, SQL, shell, filesystem, or logging sink. Risk belongs to the whole path, not only a function name.
innerHTML may receive a trusted constant yet create XSS with uncontrolled input. SQL may contain a fixed identifier while values still require parameters. For each finding, document controllability, validation or encoding, and the target context.
- Identify the source and trust boundary.
- Trace transformations in order.
- Find a context-specific safe API for the sink.
- Reproduce both attack and safe cases in tests.
Secrets and cryptography need special handling
Even when a token-like string is a demo, assume a real secret might exist in history. Deleting it is insufficient: revoke or rotate at the provider, assess propagation into logs and artifacts, and move the value to a secret manager or protected CI variable.
MD5 and SHA-1 can be unsuitable in security contexts, and fast general hashes are not password-storage functions. Choose algorithms from the data type, threat model, and current platform standard. A regex scanner cannot verify a cryptographic design.
Build a layered release gate
Local triage moves feedback earlier. CI should add language-aware SAST, secret scanning, dependency or SBOM checks, and tests. High-risk authentication, payment, file, and command paths deserve manual security review.
Give every scanner time and size limits, explainable rule identifiers, and a false-positive path. Prioritize by severity, confidence, and impact. If a gate can block release, its ownership and exception process must also be auditable.
Sources and verification
The following primary and official documentation was checked for this guide. Review each source's current version and change date as well.
Content is checked against visible ByteQuant product behavior and the listed primary sources where available. It is general information, not legal or security advice.