VNX-1064: Invokable Control Element with Signature Containing an Excessive Number of Parameters
Java method and constructor declarations with more than seven parameters, counted across line breaks with annotations and generic arguments removed; @Override and @ParameterizedTest methods are skipped.
| Field | Value |
|---|---|
| Rule ID | VNX-1064 |
| Severity | Low |
| SARIF level | note |
| Kind | sast |
| Languages | Java |
| CWE | CWE-1064 |
| 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 | excessive-params maintainability java cwe-1064 |
| Source | internal/sast/rules/vnx-1064.rego |
Overview
VNX-1064 maps to CWE-1064: Invokable Control Element with Signature Containing an Excessive Number of Parameters. Java: a method or constructor declaration (package-private constructors included) with more than seven parameters (the CISQ maintainability threshold). The declaration is read across line breaks, with annotations, string literals and generic type arguments removed before parameters are counted, so Map<String, Integer> m is one parameter. Such signatures are hard to call correctly (adjacent parameters of the same type are easily swapped) and usually mean a parameter object or builder is missing. Not reported: @Override methods, whose signature is imposed by the supertype or framework callback they implement (the supertype’s own declaration is reported when it is scanned), @ParameterizedTest methods, whose parameters are the columns of their data source, calls and constructor invocations with many arguments, declarations of seven or fewer parameters, record headers (their components are fields), varargs counted as one parameter, and comments or string literals.
Why This Matters
This weakness class (Invokable Control Element with Signature Containing an Excessive Number of Parameters) creates a concrete exploit surface: the rule searches for the concrete source-level patterns most commonly associated with CWE-1064 and surfaces them for review. Each finding should be evaluated in context, the rule catches the pattern, not the context.
What Gets Flagged
// FLAGGED: eight parameters
public Invoice create(String customer, String currency, long amount, int days,
boolean draft, Locale locale, ZoneId zone, String note) { ... }
Not flagged: an @Override of a callback such as Android’s nine-parameter onLayoutChange(...), a @ParameterizedTest method, declarations with seven or fewer parameters (Map<String, Integer> m is one), calls with many arguments, record headers, and varargs counted as one parameter.
Remediation
- Review each flagged line and determine whether the pattern represents a real instance of CWE-1064 or a false positive.
- Replace the flagged construct with a documented safe alternative appropriate to your language and framework.
- For confirmed false positives, add a
# vulnetix-ignore: VNX-1064comment on the line. - Ensure equivalent test coverage exists to prevent regression.
References
- CWE-1064: Invokable Control Element with Signature Containing an Excessive Number of Parameters
- OWASP Top 10
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-1064
// nosec vnx-1064
Or record an ignore rule: vulnetix ignore add --rule vnx-1064 --reason "...". See Suppressing findings.