The tls verify false security pattern fires on any verify=False keyword argument #3375

Summary

The tls_verify_false security pattern fires on any verify=False keyword argument, not only on an HTTP or TLS call. Code that passes verify=False to its own function gets a medium-severity "TLS certificate verification turned off" finding.

packages/core/src/repowise/core/analysis/security_scan.py:270

(re.compile(r"verify\s*=\s*False"), "tls_verify_false", "med"),

Mechanism

• The pattern is a bare regex over the masked line. verify is a common keyword for "check the result" in code that has nothing to do with TLS.
• This repo trips it: packages/server/src/repowise/server/services/refactoring_health.py:338, await load_fix_first(self._session, self._repository_id, limit=None, verify=False), where verify means "skip the live re-check of stored items".
• Other rules in the file already ask what is being called. exec_call comes from the AST for Python and from child_process bindings for JS (_call_findings, :755; _child_process_exec_calls, :154), and subprocess_shell_true is matched as a multi-line call because subprocess.<call>( and shell=True can land on different lines. tls_verify_false is the call-shaped rule still matching on the keyword alone.

Repro

from repowise.core.analysis.security_scan import scan_source
for src in ["queue = await load_fix_first(self._session, self._repository_id, limit=None, verify=False)\n",
            "x = session.get(url, verify=False)\n",
            "def f(sort=False, verify=False): pass\n"]:
    print([f["kind"] for f in scan_source("m.py", src)])

On main (1eb62ca):

['tls_verify_false']
['tls_verify_false']
['tls_verify_false']

The first and third are false positives. The second must stay a finding.

Impact

Findings feed the security view, the overview attention list and the commit gate (security_gate.py:106 prints "TLS certificate verification turned off" with the snippet). A medium finding on an ordinary function argument costs trust in the rule, and the user cannot tell why it fired.

Done looks like

• The finding requires an HTTP or TLS call context: verify=False is an argument of a call whose callee is a client entry point (requests / httpx / aiohttp / urllib3 verbs, request, Session, Client, AsyncClient, ClientSession, TCPConnector), or an ssl context built unverified. Decide whether an unresolved receiver (session.get(url, verify=False)) counts. Matching on the callee name instead of the receiver's type is the cheap rule, and the PR should say what it measured on a few real repos.
• A def f(verify=False) parameter default is never a finding.
• Python goes through the AST, as _call_findings does; other languages keep today's masked-line behaviour unless the PR measures otherwise.
• A change to what this rule reports is a scanner change, so it bumps SECURITY_SCANNER_VERSION (security_scan.py:44, currently 2) so update rescans existing indexes. One bump per release: check main's value first and do not bump twice if another scanner PR already did.
• Not a first issue: it needs a call-context rule that works across keyword and multi-line calls, plus a precision check on real code.

Tests

tests/unit/analysis/test_security_scan.py (the parametrised test_tls_verify_false_ignores_prose near :526): keep requests.get(url, verify=False) and add httpx.Client(verify=False) and a multi-line requests.post(\n url,\n verify=False,\n) as findings; add load_fix_first(..., verify=False) and a verify=False parameter default as non-findings.