Skip to content

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.

Updated 02 Nov 2026Checked against cli@de9b52a
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

  1. Review each flagged line and determine whether the pattern represents a real instance of CWE-1064 or a false positive.
  2. Replace the flagged construct with a documented safe alternative appropriate to your language and framework.
  3. For confirmed false positives, add a # vulnetix-ignore: VNX-1064 comment on the line.
  4. Ensure equivalent test coverage exists to prevent regression.

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-1064
// nosec vnx-1064

Or record an ignore rule: vulnetix ignore add --rule vnx-1064 --reason "...". See Suppressing findings.

Edit this pageSources: cli/internal/sast/rules/vnx-1064.rego, cli/internal/sast/docs/vnx-1064.md
esc
↑ ↓ move↵ openSearches in your browser. A key like autonomy.max or a code like threshold_required jumps straight to it.