Introducing Qwiet AI AutoFix! Reduce the time to secure code by 95% Read More

These days, when we talk about attacks, we are talking about endpoints—those pinpoint openings that allow adverse entities to hack into our computer systems. The endpoints vary in attack surface: some are accessed through phishing, while others are achieved through bounties. But however they are reached, they loom large among cybersecurity professionals, with a tangibility that exceeds their true threat.

If we are honest with ourselves, and if we think about how systems are constructed in this second decade of the 21st century, the endpoint is the outcome, not the source. The vulnerabilities we’ve been discussing originate upstream: before becoming an endpoint, they start as source code written by a developer and then pushed into the CI/CD of choice and uploaded into the Cloud, thereby increasing the potential attack surface.    

In our talk, we discuss how code is the new attack vector in our open source world, and offer strategies to help your organization navigate the current landscape—without the usual scare tactics, and with a mindset of doing more with less.

Code is the new attack vector

But before we get ahead of ourselves, let’s be clear about code as the new attack vector. What we’re saying is the old days are over. Engineers in the legacy world used to write 90% of the code deployed into your datacenter and then serve your customers. Today, open source code powers 97 percent of all applications (source: GitHub’s Octoverse report).

The ubiquity of open source code means several things from a security perspective.

First, it means that risk is proliferated along with the code that contains it. If a developer made a mistake, or overlooked a protocol, that is now everyone’s problem.

Second, many organizations are using open source components in ways they were never intended. Components meant for specific, on-premise use-cases are running on the Public Cloud. No shame here for overclocked developers grabbing pre-cooked code to keep their systems running, but the off-brand use does create another level of vulnerability.

Third, and most concerning, there are cataclysmic events where an exploit into someone else’s system creates a problem on your (and innumerable other systems) because of shared code.  SolarWinds is perhaps the best example of this type of exploit, which has become the go-to strategy of a new generation of bad actors: gaining access to multiple systems and lingering for months undetected, gathering customer data and other business-critical information.

Think geometrically, not linearly

The idea that a simple feature on your (or someone else’s) remote system can turn into a vulnerability and be weaponized to exploit sensitive assets is enough to give anyone nightmares. As defenders, we ask ourselves what is the best defense against a threat that can come from any direction.

The typical response is to quantify the threat according to incumbent methods. We run our instruments and, in return, we get a ton of vulnerabilities. The vulnerabilities tell us something is wrong, but not necessarily what to do. The situation is analogous to being on the freeway and being told there is an accident, without being told if there’s any impact to you and your journey.

The lists offer a solution that is linear in a literal sense. The systems that produce them are based on NVD, CVSS, EPSS, OWASP and other standards. From their relative standpoint, they’re saying the right thing.

But from an objective standpoint, they’re blinded.

For