Marc Andreessen wrote a pretty famous blog more than 10 years ago now about how “software is eating the world.” This has been followed by declarations that various software development approaches are taking over, and by inference will take over the world too. One big example is Open Source software, while today it is how developers use microservices and containerization to build apps. Software has delivered services that the general population simply couldn’t imagine living without, and they demanded more of them, and they are willing to pay for them too.

Andreesen’s point was that all companies must now contend in the software marketplace, and that the quality of your software can literally make or break your business. For example, if you’re a bank with a beautiful, functional mobile app, while your competitors have bad apps or miss functionality, then you will take market share from them. If you’re a retail store with an online ordering system that is stellar, people will buy from you even if your prices are higher.

Building all this software with the aim of eating the world is what gets a lot of us up in the morning. It’s why we like solving those problems around how to design better systems that are more enticing to users or deliver better experiences. But it can lead to problems over time. Not only do we have to build these systems, but we have to manage and support them effectively too. This includes looking at security problems and potential vulnerabilities.

Historically, most of the software that organizations run is software they bought, and thus most of the “computer security” tooling and skill sets they have to revolve around securing third-party applications. The onus is on the vendors involved to ship us better versions if a vulnerability is discovered, for example. However, this mindset does not help around the applications that we build ourselves, particularly when it comes to modern apps that are built to use containers, cloud and microservices.

Andreesen’s point was that all companies must now contend in the software marketplace, and that the quality of your software can literally make or break your business. For example, if you’re a bank with a beautiful, functional mobile app, while your competitors have bad apps or miss functionality, then you will take market share from them.

Securing custom-built software isn’t the same

Today, custom-built software is eating the world because cloud and DevOps have made it much easier for businesses to build their own software, sometimes at a massive scale and ridiculous speed. These applications are what define and differentiate your service from your competitors, so you have to update them frequently to stay ahead. To build these services, developers will use containerisation and Kubernetes – according to the Cloud Native Computing Foundation, 96% of organisations are either using or evaluating Kubernetes to orchestrate and run their applications.

While Kubernetes can make it easier to run containers and manage them, it does not deal with issues in your business logic or faults in the code that are in your container images. It does not check that the packages you include in your containers are up to date and secure. And while it can deal with issues around scaling up or down based on workloads demands, it will not know when additional resources are being used by each container that actually doesn’t need to be consumed. The problem with the software you build is that you have no one but yourself to blame for either its poor quality or its tragic security.

These things can have drastic implications for the success of your now software-dependent business. The security tooling for software you built dates back only a couple of decades – for example, the Open Web Application Security Project (OWASP) was founded in 2001. The security operations for software you build on cloud and containers are even younger – in fact, we are actively pushing those frontiers today. The best practices around containers are still being developed so that developers can implement them in their applications and aim for security by design from the start.

There’s a particular catch with securing software you build in that you must find a way to achieve security without slowing down how you deliver business value, which is the whole point of building software at all. One security control that is famous for slowing down development is vulnerability management.

The problem with the software you build is that you have no one but yourself to blame for either its poor quality or its tragic security.

Not all vulnerabilities are created equal

If you’re used to securing software you bought, you run a scanner on your test environment (or if you like to live dangerously – production), and it spits out a thousand issues that no one knows how to fix. According to the Sysdig 2022 Cloud-Native Usage Report, more than half of cloud workloads are scanned for the first time in runtime. The painful outcome of this approach is that 75% of running workloads contain issues rated high or critical that are patchable vulnerabilities.

The simple answer is to shift security left in the software development pipeline. So you run a scanner instead on the artefacts in your CI/CD pipeline, long before you deploy to production, but you still find the same thousand issues, just sooner. While the idea of shift left security is a great idea, it does not survive contact with reality. Instead, we have to deal with this in more specific and targeted ways.

For example, one problem is that not all vulnerabilities are created equal. Out of the thousand issues that your vulnerability scan finds, which ones are serious showstoppers that demand immediate developer attention, and which ones can be dealt with later in a maintenance round-up update? The real world problem here is that the people who build software – developers – do not have the expertise to determine which of the problems must be fixed immediately and which can be delayed or ignored.

According to the Sysdig 2022 Cloud-Native Usage Report, more than half of cloud workloads are scanned for the first time in runtime. The painful outcome of this approach is that 75% of running workloads contain issues rated high or critical that are patchable vulnerabilities.

Next steps

So what can you do? Certainly, you should train your developers on writing more secure code in the first place. This will never be perfect – faults will be made, and security vulnerabilities can be introduced through dependencies much earlier in the supply chain, before a single line of your own code is written. However, making sure that developers are encouraged to use approaches like the OWASP Secure Coding Practices checklist can help to reduce the number of issues from the start.

Secondly, build program maturity by using security tools that are designed with developers in mind. This means providing your developers with tools that were built to secure the software you build, not just the software you buy. In particular, you should look at tools that discover potential vulnerability risk with full runtime context rather than those limited to static analysis and severity metrics. Whatever approach you take, this should integrate into your developer workflows and processes, so using the tools is just part of the overall approach, rather than a distinct point to work through.

One example of this in action is to understand how containers run and use the packages that we decide are needed. Many of the packages that get included within application artefacts are never executed in runtime. We include them because they might be needed in the future, or they are always included in default builds.

In practice, knowing what is really needed allows us to deprioritise any associated vulnerabilities because they pose a far lower risk than vulnerabilities in packages that do get loaded into memory. From a developer perspective, static analysis alone cannot provide this type of insight, but the results from a scanning tool that looks at runtime context can. This can reduce the number of total vulnerabilities that a developer must deal with considerably.

Shift left has been the mantra for application development and security for the past few years We certainly ought to shift left and adopt more security within our pipelines, but to do it effectively, we must make it easy for developers to fix the most critical security problems only. This is about making it easier to focus on specific problems, rather than wasting developer time pondering cyber risk overall, which is not their job and should remain with the security department. After all, we want our software to eat the world, not give us security indigestion.