Will It Vibe?Process-wide TLS certificate validation disabled
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 25 points from that category, once per scan, no matter how many places it turns up.
What it detects
ServicePointManager.ServerCertificateValidationCallback is assigned a callback that unconditionally returns true, disabling certificate validation for every HTTPS/TLS connection made by the process, not just one client.
Why it matters
ServicePointManager.ServerCertificateValidationCallback is a process-wide setting: assigning it a callback that always returns true disables certificate validation for every HTTPS and TLS connection the process makes from that point on, not just the one client that seemed to need it. Any connection made afterward, including ones that have nothing to do with the original problem, silently accepts any certificate, opening the door to man-in-the-middle attacks across the whole application.
How to fix it
Remove the callback so default certificate validation applies. If a specific connection legitimately needs a custom trust decision (an internal CA, a self-signed cert in a dev environment), scope it to that one connection using HttpClientHandler.ServerCertificateCustomValidationCallback instead of the process-wide ServicePointManager callback, and validate the certificate's thumbprint or chain against a known-good value rather than returning true unconditionally.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo