Staging has a self-signed certificate and a client that refuses to talk to it. The deadline is today, not the week it would take to get a real cert issued for an internal host. The fastest fix is one flag, and it works immediately.
The problem is where that flag lives. It is not a staging-only setting. It is a default on a client that every environment imports, including production.
Treat what follows as illustrative: the kind of change that raises the question, not a customer incident or heygrc telemetry.
The one flag
The client that calls an internal billing service is shared across environments, one file, one export. Staging's certificate does not validate, the request fails closed, and the fix that unblocks it is a single option on the agent.
export const httpsAgent = new https.Agent({ keepAlive: true,+ rejectUnauthorized: false, // staging cert is self-signed})Certificate verification is what makes TLS an authenticated channel rather than just an encrypted one. Turning it off does not make staging's cert valid, it makes the client stop checking whether any cert is valid, on every host it connects to. CC6.7 covers protecting data in transit, and SC-8 covers the confidentiality and integrity of transmitted information; neither control statement prescribes TLS or certificate-validation behavior as such, but disabling certificate verification weakens the confidentiality and integrity protections both are pointed at, because the client no longer authenticates the remote endpoint. The fix belongs in staging's environment configuration, a trusted local CA or a per-environment override, not in the client every environment shares.
Why the review does not catch it
The pull request title says something like 'fix staging billing client', and the diff is one added line inside a file named for an internal service, not a security module. A reviewer checks that the fix matches the description, staging billing calls work now, and approves. Nothing about the diff signals that the line changes behavior in production too, because the code has no environment check at all. The flag is unconditional, so it is not read as an environment-specific hack. It reads as a client option.
The pattern recurs in a specific shape: the change that ships to prod by accident is rarely in a prod file. It is in the file every environment imports, changed to solve one environment's problem.
What this can look like in an assessment
Nobody schedules an audit of `rejectUnauthorized`. What can get sampled is whether transmission of sensitive data is protected, and that question is not answered by confirming TLS is configured somewhere. A shared agent with verification off weakens the answer for every service that imports it, not just the one someone was trying to unblock.
The gap can sit there until someone happens to read that file for an unrelated reason, or until it shows up in a pen test as a certificate any attacker-controlled host can present. Neither is as cheap as catching it in the PR that introduced it.
The point
The worst compliance changes are not malicious and are not even careless in isolation. They are correct fixes for the problem in front of someone, applied at the wrong scope, in code that does not distinguish environments. 'Just unblock me' is a reasonable instinct in a shared file that has no idea it is shared.
heygrc reads the diff against the frameworks you carry and names the control a change like this touches, CC6.7 or SC-8, on the pull request, so the scope question gets asked before the flag ships everywhere.