Potential workaround for FortiClient issues

[reiniercriel]

Summary by Aikido

Security Issues: 0	🔍 Quality Issues: 1	Resolved Issues: 0

⚡ Enhancements

• Bypassed TCP interception for FortiClient startup helper processes during proxy decisions
• Added identifier and process-path checks to detect FortiClient helper binaries

^{More info}

[aikido-pr-checks]

Final return uses a combined &&/|| expression; split into guard checks (check starts_with first, then return on ends_with cases) to clarify control flow.

Show fix

Suggested change

	path.starts_with("/Library/Application Support/Fortinet/FortiClient/bin/")
	&& (path.ends_with("/ztnafw") || path.ends_with("/epctrl") || path.ends_with("/fctupdate"))
	if !path.starts_with("/Library/Application Support/Fortinet/FortiClient/bin/") {
	return false;
	}
	path.ends_with("/ztnafw") || path.ends_with("/epctrl") || path.ends_with("/fctupdate")

Details

✨ AI Reasoning
​The function computes 'matches_identifier' and uses early returns for several failure cases, but ends with a compound boolean return that mixes starts_with and multiple ends_with checks. This creates a moderately complex final condition that would be easier to read if split into explicit guard clauses (e.g., early-return false when the path doesn't start with the prefix, then check ends_with variants). The problematic expression increases cognitive load compared to simple guard-style checks.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}