Ross Haleliuk challenges a deeply entrenched assumption in the cybersecurity industry: that solving security problems requires building a security company. In an era where venture capital chases the latest threat detection tool, Haleliuk argues that the most profound security gains often come from products that never marketed themselves as security solutions at all. This is not just a pitch for a different business model; it is a fundamental rethinking of how risk is actually reduced in modern organizations.
The Byproduct Advantage
Haleliuk begins by dissecting the traditional approach to security sales. He notes that most founders assume the path to solving a security problem is to "build a security product, market it to CISOs, and go after the security budget." He argues this is often the "hardest, slowest, and least successful route." Instead, he introduces a critical distinction between "security as the product" and "security as a byproduct."
When security is the product, the pitch is fear-based. Haleliuk writes, "Hey CISO, if you don't buy what we are selling, you'll get breached and/or fail a compliance audit." This creates a transactional relationship where security is a cost center. Conversely, when security is a byproduct, the customer buys the tool for productivity, speed, or user experience, and the security benefit arrives as an inevitable side effect.
"Security as a byproduct means the customer buys your product for a different primary reason... and the security benefit is real, measurable, and in some cases far greater than what a traditional security product could deliver."
This framing is compelling because it aligns with how humans actually make decisions. People do not wake up wanting to be secure; they wake up wanting to work faster or collaborate better. Haleliuk's argument lands because it shifts the focus from the buyer's anxiety to their actual goals.
Case Studies in Unintended Security
To prove his point, Haleliuk walks through five distinct examples where non-security companies inadvertently created massive security improvements. He starts with Chromebooks. The pitch was never about ransomware resistance; it was about a "cheap, easy, low-maintenance laptop." By stripping away local storage and restricting software installation, Google removed the attack surface that plagues traditional PCs.
Haleliuk suggests that aside from multi-factor authentication, "getting people to use Chromebooks is probably the single most impactful change companies can make that would lead to better security." Critics might argue that Chromebooks lack the flexibility required for complex engineering workflows, but Haleliuk acknowledges this trade-off while maintaining that the security outcome is superior.
The argument extends to communication tools. Haleliuk contends that Slack has done more to stop phishing than all dedicated email security vendors combined. They achieved this not by filtering bad emails, but by "getting rid of internal email as a primary communication channel altogether." The security benefit was invisible but powerful: fewer malicious links and spoofed messages reached employees because the primary attack surface was simply removed.
"Nobody needed a security awareness training session to understand why Slack was better than Outlook. People wanted faster, searchable conversations... The security benefit was invisible but powerful."
Similarly, Haleliuk points to compliance automation tools like Vanta and Drata. While compliance is not identical to security, these platforms function as sales enablement tools. Startups buy them to close deals with enterprises, not to satisfy a CISO. The side effect is that startups implement real controls like access reviews and encryption. Haleliuk notes that "without the sales incentive, many companies wouldn't even do the bare minimum."
Even identity management giant Okta started as a productivity play. Its early pitch was about a "single password to remember" and reducing helpdesk tickets. The architecture that enabled this convenience also eliminated credential sprawl. Users adopted it for ease, but the organization gained robust identity security "for free."
Finally, he highlights Chainguard, which solves the developer pain of patching container images. The pitch is not "be more secure," but "your security team keeps asking you to patch containers. Imagine never having to deal with that again." By solving a workflow problem, they achieve a security outcome that traditional vulnerability scanners often miss.
The Failure of Misaligned Incentives
Haleliuk is careful to outline why this approach fails when executed poorly. The core failure mode is misunderstanding incentives. He illustrates this with Chainguard again. If the company tried to sell developers a product that "makes their container images more secure," they would fail. Developers do not care about security; they care about shipping code.
"Developers don't care about security, so a product aimed at developers can't pitch better security; it has to pitch what they care about."
This is a crucial insight for the industry. Haleliuk argues that "shift left" initiatives often fail because they force developers to run security scans when their primary incentive is speed. Security must be the "inevitable side effect of solving some other, primary pain." If the value proposition is about security, the wrong buyer is targeted, and the product stalls.
Applying the Mindset to Emerging Threats
The piece concludes by applying this framework to emerging challenges like AI-generated code and deepfakes in hiring. Haleliuk suggests that the solution to insecure AI code won't come from a "next-gen code-scanning tool" sold to security teams. Instead, it will likely come from developer platforms that embed vulnerability detection directly into the coding process, adopted for productivity.
Similarly, regarding the rise of deepfakes and the risk of hiring bad actors, Haleliuk questions whether a dedicated security solution is the answer. He asks, "What if someone could reinvent the whole hiring experience, so that it's simpler, better, more streamlined, more automated, and by default more secure?" The buyer would be the HR leader, not the CISO. He posits that the solution will come from a founder who builds a modern hiring experience that just happens to be secure, rather than a founder building "security for hiring."
"To achieve a security outcome, founders don't necessarily have to build a security company."
Bottom Line
Ross Haleliuk's argument is a necessary correction to an industry obsessed with selling fear to CISOs. The strongest part of this piece is its demonstration that the most effective security controls are often those that users adopt willingly because they solve a different problem entirely. However, the argument's biggest vulnerability lies in the assumption that all security problems can be solved this way; some threats, particularly advanced persistent threats, still require dedicated, specialized defense. Readers should watch for how this "byproduct" mindset reshapes the next generation of enterprise software, where security is no longer a feature to be bought, but a standard to be built in.
To achieve a security outcome, founders don't necessarily have to build a security company.