Why this verdict
- suspicious: finding skill:skills/performing-phishing-simulation-with-gophish:skills/performing-phishing-simulation-with-gophish/scripts/process.py:40:CRED
Security findings 1
Credential access
highContextual risklow confidenceprocess.py's GoPhishClient defaults verify_ssl to False, so any instantiation that omits the flag sends the GoPhish API key and SMTP sending-profile credentials to the configured API URL over unverified TLS.
verify_ssl: bool = False
vector:code
Counter-argument considered
Against refutation holds: the shipped client genuinely defaults verify_ssl to False and wires the env-sourced GoPhish API key into an Authorization header on a session with certificate verification disabled; disabling TLS verification for credential-bearing requests is not among the accepted carve-outs, and the declared claims cover only SMTP profile fields, never disclosing the API client's unverified TLS. The strongest defense (self-signed GoPhish admin certs making it necessary) is not supported by any cited evidence, so the finding stands as a low-severity contextual risk.
Open questions 1
What the analysis could not settle from the code alone.
[file request skills/performing-phishing-simulation-with-gophish/process.py] Does process.py only pull campaign data via the GoPhish API and write analytics reports locally, or does it send data to external destinations, handle credentials beyond the GoPhish API key, or execute downloaded code?
Code execution
Refuted findings 2
Candidates the review stage examined and rejected, kept for transparency.
Code execution
criticalRefutedlow confidenceSKILL.md instructs the agent to download the GoPhish release binary via a mutable 'latest' GitHub releases URL and execute it (wget, unzip, chmod +x, ./gophish), a download-to-execute chain that is vendor-official and version-named but resolved through an unpinned 'latest' endpoint.
wget https://github.com/gophish/gophish/releases/latest/download/gophish-v0.12.1-linux-64bit.zip
Why it was refuted
The strongest case against: the wget resolves a version-named asset (gophish-v0.12.1-linux-64bit.zip) from the vendor's own official repository and sits in a fenced block under an overt deploy heading, matching the vendor-installer-in-fenced-install-docs and declared-core-capability (deploy GoPhish) carve-outs, so the unpinned-'latest' framing does not establish undeclared or third-party harm. The strongest case for it (mutable endpoint) is answered by the version-pinned asset name; harm and undeclared fail, so the finding dies despite a real instruction chain.
Supply chain
highRefutedlow confidenceStep 1 of the workflow instructs the agent to pull the unversioned gophish/gophish Docker image and download the GoPhish binary from the vendor's mutable releases/latest URL, fetching deployment code without a pinned version.
wget https://github.com/gophish/gophish/releases/latest/download/gophish-v0.12.1-linux-64bit.zip
Why it was refuted
Against: the docker pull targets the vendor's own official gophish/gophish image and the wget a version-named vendor release asset, both inside a fenced block at the overt 'Step 1: Deploy GoPhish' step of the declared deployment workflow (vendor-installer-in-fenced-install-docs and declared-core-capability carve-outs). For it: the image tag is unversioned, but an unversioned tag on the official vendor image is supply hygiene, not an undeclared harmful fetch, so harm and undeclared fail.
Coverage gaps 3
Parts of the artifact the static analysis could not fully examine.
ledger_finding_without_valid_finding run 1: behavior-chains.0 SRC:c288e033348dffcd
ledger_finding_without_valid_finding run 1: behavior-chains.0 SRC:dd690ccbf262f1c3
invalid_judge_finding behavior-chains.0
