How Secure Are the Companies We Trust? A BSides Mumbai Panel on Big Tech, Open Source & Privacy

This article recaps the closing panel discussion, "How Secure Are Our Trusted Companies?", at BSides Mumbai 2024 - featuring the day's speakers: Pavan Karthick and Gaurav Gogia (threat intelligence and malware research), Palak Bansal and Farhad Sajid (macOS/product security), and Ravi Rajput (automotive and vulnerability research). You can watch the full discussion on YouTube.

Here is an uncomfortable fact the panel opened with: Google, Microsoft, and Apple produce more CVEs than almost anyone. Every bug-bounty hunter knows their hall-of-fame counts. The only real difference between Big Tech and a small company, the moderator argued, is that the giants are transparent about how often they get hacked - they keep public registers - while smaller companies simply don't disclose. So if the software we trust most is also the most-reported-vulnerable, the natural question is: are we safer staying with it, or should we all move to open source? The BSides Mumbai 2024 closing panel spent 30 minutes pulling that question apart, and the honest answer was messier than either side wants to admit.

Key Takeaways

• Privacy and security are not the same thing - and you usually trade one for convenience. Maximum privacy means a VM, Tor, and painfully slow Facebook; maximum ease of use means handing over your data.
• "Open source = secure" is a myth. The XZ Utils backdoor and SolarWinds showed that supply-chain compromise can hide in trusted dependencies for months, and most developers never audit their transitive dependencies.
• Your security is ultimately your responsibility. Whether you run Microsoft's stack or self-host open source, the panel's blunt consensus was that choosing software is an active decision you own - not something the vendor guarantees for you.

Big Tech vs Open Source: The Legality Argument

The first panelist reframed the debate around accountability. Fortune 100/500 companies must comply with SOX, GDPR, PCI-DSS, and a stack of European and UK laws - stringent regimes that fine hard when something goes wrong. Open-source projects, by contrast, typically ship under MIT or GPL licenses with no such obligation. Given a choice between a product backed by a regulatory body that will be penalised for failures, and one with a permissive license and no accountability, most people (and enterprises) will pick the governed option. That doesn't make Big Tech more secure - it makes it more answerable.

A counterpoint landed immediately: Chrome, the world's most-used browser, shipped eight critical RCE CVEs - and if a capable threat actor had chained them, every Chrome user was exposed. But then there's XZ Utils, where an attacker patiently gained maintainer access to a critical open-source dependency for a year before nearly landing a backdoor into countless systems. Both scopes are enormous. Neither model is safe by default.

Privacy vs Usability: You Can't Max Both

The panel drew a sharp line between privacy and security. If you truly want privacy, you won't use Chrome at all - you'll accept the usability hit. One panelist put it memorably: crank privacy to the maximum and you'll "open a VM, run it through Tor, get 2 kbps, and finally open Facebook." Crank usability to the maximum - instant sign-in, no prompts, one-tap access - and your privacy drops through the floor, because those same tracking mechanisms are what make the experience seamless. The genuinely unsettling part, the panel noted, is how few of us read the terms and conditions we accept: you search for something, and Amazon shows it, and it surfaces in your ads. Deciding what data you're willing to share is the real first step.

The Quality Trade-off - and Why It Isn't Simple

Money matters. A panelist argued that open-source products sometimes suffer on quality, not because the developers are bad, but because there simply isn't the funding a trillion-dollar company can pour into research. Microsoft's Common Log File System is a core Windows component riddled with issues precisely because it was optimised for performance over security - yet the same company funds cloud research at a scale open source can't match. The trade-off: a high-quality product guaranteed to exist for decades, versus an open-source one that may or may not stay maintained.

But scale cuts both ways. A "dumber" open-source OS with fewer features has a smaller attack surface - fewer features, fewer things to exploit. The panel used Windows NTFS Alternate Data Streams as the example: a well-intentioned feature (built for Mac/Apple file compatibility) that doubles as a data-smuggling and exfiltration primitive. Good features can be actively exploitable.

Supply Chain: The Risk Almost Nobody Audits

The most practically useful segment was on supply-chain security. The panel's challenge to the room: when did you last look into your node_modules to see which transitive dependencies your dependencies pull in? Almost nobody does - whether it's Node.js, Python, .NET, or Java. That blind spot is exactly how Log4Shell hurt organisations that weren't even directly using Log4j: a nested dependency was. The takeaways were concrete:

• Learn about SBOMs (Software Bill of Materials) - know every library you ship and everything those libraries pull in.
• Remember SolarWinds and XZ - supply-chain attacks can hit closed and open source, and may be marginally easier to slip into open source.
• Big vendors patch fast because regulation forces them to; an unpaid open-source maintainer may get to it "tomorrow."

Adoption Rate: Why Attackers Target What They Target

Drawing on his experience writing zero-days, Ravi Rajput made a point that reframes "which OS is safest": attackers optimise for reach. You write malware for whatever the masses use. That's why hacking Chrome beats targeting a niche app, and why the rise in Apple-focused threats tracks the fact that high-net-worth individuals use Apple devices - not that macOS is inherently less secure. Windows has more malware than macOS largely because researchers have spent more time on it. Pegasus targeting WhatsApp was the same logic: adoption rate.

The Government Question: Encryption vs Subpoenas

The panel closed on the limits of privacy against state power. End-to-end encryption means even the provider can't read your data - which is why WhatsApp has threatened to exit markets that demand it break encryption. But in jurisdictions with subpoena power, providers - even Apple, in cases where unlocking a device would solve a heinous crime - can be legally compelled. The dilemma the panel raised: do it once, and nothing stops the government asking again. "The key maker can still break the lock." Against a determined state actor, "the big daddy is the biggest problem," not the small threat actors.

Frequently Asked Questions

Is open-source software more secure than proprietary software?

Not automatically. The panel dismantled the "open source = secure" assumption using XZ Utils and SolarWinds. Open source offers transparency and the ability to audit and recompile (Brave building privacy on top of Chromium was the example), but it can also carry unaudited, under-maintained dependencies. Proprietary software has funding and regulatory pressure to patch quickly, but you can't inspect it. Each has real trade-offs.

Should I stop using Chrome for privacy?

One panelist framed it as a suggestion, not a mandate - Chromium-based Brave blocks trackers and gives better privacy, and privacy-focused options like the Tor Browser exist. But another panelist's realism cut through: given enough time and motivation, almost anything is hackable, and zero-days appear across nearly all software. Privacy is about deciding what you're willing to expose, not finding an unhackable tool.

Who is responsible for my security - the vendor or me?

The panel's repeated answer: you are. Whether you rely on Microsoft or self-host open source, choosing software is an active decision you own. Don't run pirated software; don't breach others' privacy agreements; keep your systems patched. "Security lies in your own hands."

Summary

The companies we trust most ship the most vulnerabilities - but they're also the most transparent and the most accountable, bound by GDPR, PCI-DSS, and regulators that fine failure. Open source offers freedom and auditability but no guarantee of quality, maintenance, or a clean supply chain, as XZ Utils and SolarWinds proved. The BSides Mumbai 2024 panel didn't crown a winner, because there isn't one: privacy trades against usability, quality trades against freedom, and reach - not inherent weakness - decides what attackers target. The one thing every panelist agreed on is the thread that ties this whole blog series together: your security is a decision you actively own, so make it deliberately - audit your dependencies, read the terms, patch your systems, and don't outsource the responsibility along with the software.

About the Panel

The panel brought together the technical speakers from BSides Mumbai 2024: Pavan Karthick M and Gaurav Gogia, who spoke on threat intelligence and malware research; Palak Bansal and Farhad Sajid of Honeywell, who presented on macOS dylib injection; and Ravi Rajput, automotive and vulnerability researcher and author of AutoHackOS. Their individual talks are written up across this blog - see the BSides 2024 tag for all of them.

Watch the Full Discussion

Want the complete panel, including the audience Q&A on GitHub ownership, GDPR fines, and open-source browsers? Watch the full BSides Mumbai 2024 session below.