The Einstein of cybersecurity still needs developer trust

This post is based on Mackenzie’s conversation with Arun Singh on The Secure Disclosure podcast. Listen to the full episode or watch below.

In leading security for major Australian fintechs, Arun Singh has learned that “You could be the Einstein of cybersecurity, but if you cannot influence the business, you’re no good.” Implementing a new security control developers hate influences the business, but not in a good way.

Singh learned this lesson early in his career, when he made the decision to remove local administrator rights across every workstation in the company. For 90% of users, it went fine. But the small cohort of software engineers who needed system-level access beyond just installing applications had their productivity completely destroyed. His team found the right compromise in days, but the trust took a year to rebuild. “Any time I’d go and talk to them about a new control, it was a hard-fought battle.” 

The problem compounds at scale. Mike Wilkes, Aikido Security’s Enterprise CISO, argues most enterprise security rollouts fail because they’re run like software deployments when they’re actually cultural changes. At 5,000 engineers, trust isn’t something you rebuild one conversation at a time.

The supply chain twist

Singh’s recent board conversations at Tyro have centered on supply chain attacks, and the conventional security wisdom that has been drilled into developers can, counterintuitively, make the problem worse. “We’ve been advocating for developers and other security folk to keep their packages and dependences up to date. It is something that we have ingrained in them for years. And threat actors have used that teaching to start compromising these companies.”

Singh’s team now advocates a 7-day cooldown period for any new package version. That means telling developers to do the opposite of what security has told them for years. You want to patch vulnerabilities, but not too fast. “We actually held workshops with our engineering teams to make them understand the reasons behind it. And once they got on board, it was great.”

A policy like that only works if developers trust the security team enough to follow it. If that trust has been already burned on a clumsy control rollout, a nuanced ask like “patch, but wait a week” is going to be ignored or worked around. Since trust is expensive to rebuild, the better strategy is to adopt tools that never spend it in the first place.

Frictionless security controls

How do you secure code without creating friction or burning developer trust? Singh’s answer is that the tools have to fit into developer workflows. He prioritizes two categories.

First, in-IDE vulnerability detection. “Something that can help scan code within the IDE and help pick up insecure patterns of code, or picks up secrets in code, or vulnerabilities as the engineers are in their zone working, is absolutely key. Having a tool that just scans post-commit, you’re already too late. You need to be in the workflow of the developer.” Aikido’s IDE integrations live where Singh says they need to, catching vulnerabilities, secrets, and insecure packages while developers are still in flow.

Second, developer device protection with enforceable policies that don’t kill productivity. His experience with existing tools in this category has been frustrating. “It’s always a duct tape contraption that’s sort of giving you some limited visibility. But even if you get the visibility, you can’t do anything about it.” What’s needed is a tool like Aikido Device Protection that catches malicious packages, browser extensions, and IDE plugins at install time, silently letting the safe ones through and blocking the rest before they cause damage. 

Developer trust is a finite resource

Attackers keep innovating, and security tooling has to keep up. That means there will always be another control to ask developers to implement. Developer trust is not unlimited, and every rollout that goes badly makes the next one harder. The security teams that scale are the ones that account for developer trust like a budget, and pick their tools and rollout strategies accordingly. 

{{cta}}