Of hacks and patches

It’s obvious that cybersecurity becomes a bigger concern every day. Stay in the cloud, and take responsibility for the open source software you use.

Getty Images

Outside the insurance industry, few people likely noticed that Lloyd’s of London “will no longer cover the fallout of cyberattacks exchanged between nation-states.” It would be easy to overlook, except that Lloyd’s is a major global insurer; its actions will have a ripple effect. It’s already the case that ransomware attacks across the globe have prompted Lloyd’s syndicate members to charge higher premiums while pulling back coverage for rank-and-file enterprises by nearly 50%.

Nor does it stop with insurance. A decade ago, then U.S. Secretary of Defense Leon Panetta warned that cyberterrorism was a national security threat. It could be a direct threat to infrastructure like dams or electrical grids, or it could be used to fund bad actors. By one estimate, North Korea pilfered nearly $400 million from crypto exchanges last year. Much of this hacking is made easier by the gaping holes we leave in security infrastructure due to poorly patched open source software.

We’re living in a time when everything can and will get hacked, at significant cost to those immediately and indirectly involved. What can we do?

Stay in the cloud

Kleiner Perkins investor Bucky Moore suggests that the clouds will be “disintermediated” by serverless providers like Vercel, nudging cloud providers to focus more on improving core “primitives” like compute, storage, etc. Perhaps. That’s something that former Better.com CTO Erik Bernhardsson recently posited as well, and it seems a reasonable analysis.

Even if we scrap the first part of Moore’s argument, it’s a safe bet that the clouds will keep investing in better services, including security. True, you don’t have to scroll back too far on tech news pages to find the last outage at Amazon Web Services, Microsoft Azure, or Google Cloud. The AWS outage in December 2021 that took down a big slice of the Internet was caused by a network device issue. In 2017 another outage was caused by an employee’s error. It’s very possible that some outages at AWS or other clouds are caused by bad actors who act with increasing sophistication.

The cloud providers are still a safer bet than trying to manage and secure all your own hardware and software infrastructure. Yes, you’re good. No, you’re not that good.

Nor is it time to try to achieve application resilience through multiple cloud providers. Multicloud is a great idea for your personal career; it’s not necessarily a great strategy for a company that probably struggles to master one cloud, much less three. Regardless, the point is that the clouds remain a good source of relative security in a world that is anything but secure.

Take responsibility for your dependencies

As Moore writes, many of the biggest security problems of the past year, including “Solarwinds, CodeCov, and Log4j, were commonly rooted in highly sophisticated actors using zero-day exploits to insert malicious code into their software, which was ultimately used to infiltrate the environments of end-users of that software.” There’s not much you can do to inspect Solarwinds’ code to ensure it’s all fine (frankly, no one really has the time and few have the capability to do so), but there is much we can do to ensure we’re working with trusted code.

One key way is to employ a zero-trust approach to security, as Kong CTO Marco Palladino has outlined. Zero trust is particularly critical as enterprises move to microservices-based architectures. It assumes there is no safe “inside the perimeter zone” and constantly checks the identity and rights of people, devices, and services. By defining security at the artifact level and not the repository (like in GitHub), we can digitally sign at the source and have the user of that artifact authenticate it.

That’s just part of the solution.

Given how prevalent open source has become in all software (proprietary, open source, etc.), another key aspect of security is to take ownership of this part of your software supply chain. No, this doesn’t translate to “email the maintainers of the open source software you depend on and make demands of them,” as a multibillion dollar company did recently to noted open source developer Daniel Stenberg. That’s bad form. It’s also not likely to get you what you want.

A much better way is to invest in the people who build and maintain the software upon which you depend. Sometimes that means paying the maintainers of those projects in some way, though not always. It turns out the motivations of the people who build open source software are diverse.

Another suggestion is to get involved. For developer Diego Elio Pettenò, this means “if I’m using a [open source] library and something is broken, it’s my problem to solve it, not insist on someone else to.” Not everyone can do this, of course, because not everyone will have the time or aptitude. But it’s irresponsible to depend on free software without taking steps to ensure the security of that software, which at a minimum involves keeping it updated and patched, and more broadly could (and should) involve finding ways to support those who create and maintain it.

In sum, security isn’t something that magically happens. Yes, building on relatively secure cloud platforms is a start, but it’s just that—a  start. To truly achieve software security, organizations need to look to new security models like zero trust, even as we get more involved in the open source communities that create so much of the software upon which our companies are built.