If your users are productive, chances are so is the company that pays both your salaries. If your users have to fight their infrastructure people to get their jobs done, you company will fail to effectively compete against those companies that don't.
It astounds me that so few security people understand what their purpose is: Your purpose is to assist the company you work for to keep on existing, and even make a profit. If you disempower those that are most effective in helping the company do what it does you're effectively destroying your own livelihood, and everyone else that is dependent on it.
Productivity means nothing in the face of data exfiltration. You only have to fail once at guarding a password in order to be completely compromised. If we seem tightly wound, it's because we have fully internalized and grok the stakes of our efforts and the entailment of failure.
"Our infrastructure sucked, so I used an insecure tool to leak our credentials to third parties, because I couldn't be productive otherwise!" is not really a valid excuse in this light, since there's no amount of productivity which offsets data exfiltration.
And you harm security if you're being sufficiently inflexible that staff see it as essential to circumvent your security measures to be able to do their job. Because they will almost certainly manage to do so.
As such, if you hurt productivity enough, you are also going to be failing at protecting company data by making people find alternative solutions, and you're not likely to get permission to go far enough to stop it unless you're working in a field where security clearance is the norm.
If the dev team needs something like ngrok, the security team has failed to provide proper tools.
If the dev team goes ahead and uses ngrok without consulting the security team, the dev team has likely committed an awful security breach.
The dev team and the security team need to think of each other as being on the same team, and talk to each every day about what they want and need.
just don't use your company's name in the domain name, make it something obscure.
If you're dismissing it as a security nightmare without considering why someone would want to use it and trying to figure out how to make it work or come up with alternatives, then you're failing your mission IMO. There's ways of securing ngrok... you can self host, put it behind a firewall, and whitelist services. It may still open a potential attack vector, but so does the mere existence of connecting to the internet. It's a balancing act, we should all be familiar with.
I don't see where this follows from. "private repos" and "testing" implies "local testing" for me. If that implication does not hold, the development workflow is seriously screwed. (Don't tell me there is no money for a local test setup when you have dedicated IT security.)
And in my experience, more often than not, it is screwed because someone decided to use some other flashy tool without realizing the security implications.
If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.
Wouldn't that still be the same, considering ngrok is just doing the tunneling. In this case, ngrok is your trusty hoster. You can park your trust into your own VM in Digital Ocean, or you can park it at ngrok.
your laptop is a very different environment from production: there are probably different protections, firewalls, monitoring, etc in place. additionally, while your laptop (hopefully) doesn't have direct access to production databases, you probably have stuff lying around that you wouldn't want an attacker to get their hands on: sensitive work documents, your Chrome cookies just sitting in a sqlite database somewhere, source code for all the repositories you have checked out locally (not just the one app that has the exploit).
I don't agree that "using ngrok is not a security risk".
if the only thing on the line is low-value things like whatever is on your personal laptop (or even whatever is on a spartan vanilla ubuntu VM that your app is running in), then maybe it's not a very big gamble.
if the laptop has corporate secrets on it or it can be used as by an attacker to pivot into company internal systems through the VPN you're also connected to, however, that's a completely different story.