VNX-1099: Inconsistent Naming Conventions for Identifiers
Two functions or methods in the same scope of one file whose names differ only in convention (validate_token and validateToken), in Python and JavaScript/TypeScript.
| Field | Value |
|---|---|
| Rule ID | VNX-1099 |
| Severity | Low |
| SARIF level | note |
| Kind | sast |
| Languages | Python, JavaScript / TypeScript |
| CWE | CWE-1099 |
| CAPEC | CAPEC-66 |
| ATT&CK | T1190 |
| CWSS vector | CWSS:1.0/TI:L/AP:RU/AL:S/IC:N/FC:LT/RP:RU/RL:S/AV:L/AS:N/IN:A/SC:A/BI:L/DI:H/EX:L/EC:N/P:L |
| Tags | naming maintainability cwe-1099 |
| Source | internal/sast/rules/vnx-1099.rego |
Overview
VNX-1099 maps to CWE-1099: Inconsistent Naming Conventions for Identifiers. It reports the second of two function or method definitions in the same scope of one file whose names are the same words in different conventions, one snake_case and one camelCase: get_user and getUser, check_session and checkSession.
Why This Matters
The name no longer tells a caller which function it gets. In practice the two variants drift apart: one validates and the other does not, or a security fix lands in one and is missed in the other. A caller who types the convention they are used to gets whichever variant happens to use it.
Not reported: names that differ only by leading or trailing underscores (_fetch beside fetch), deliberate compatibility aliases whose body calls the other name, functions in different scopes (including methods of two separate classes), names that differ in more than convention, bundled third-party JavaScript, test files and comments. Mixing conventions across files, or in variables and classes, is not judged.
What Gets Flagged
def validate_token(token, secret):
return hmac.compare_digest(token, sign(secret))
def validateToken(token, secret): # FLAGGED
return token == sign(secret)
export function checkSession(req) { ... }
function check_session(req) { ... } // FLAGGED
Remediation
- Keep one function and one name; update callers.
- If an alias is needed for compatibility, make it a one-line call to the real implementation and mark it deprecated.
- For a confirmed false positive, add a
vulnetix-ignore: VNX-1099comment on the line.
References
Suppressing this rule
Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):
# nosec vnx-1099
// nosec vnx-1099
Or record an ignore rule: vulnetix ignore add --rule vnx-1099 --reason "...". See Suppressing findings.