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 instance, standard X looks at your code but might not look at your open source. Standard Y might look at the condition on a path in your code, but not the open source and the infrastructure it’s using. The devil is always in such details, where a methodology can be generally correct, but fail utterly from a holistic standpoint.
Another failure, and one that strikes at our current economic situation, is the time and money lost chasing down a long list of vulnerabilities. A typical scan might turn up 100+ issues, but where do we start? How do we prioritize? There are tools on the market, like our new Blacklight feature, that help beleaguered teams whittle down the long list of vulnerabilities to less than a handful of true exploits that are threatening your organization.
The key here is to stop thinking in lists. Think geometrically, think the way attackers think. Lists only give you a part of the story. You have to look at the pathways where you can be exploited. This is what we mean by “Hacking Sec into DevOps.”
We will have a formal link to the presentation after the show. In the meantime, this has been a taste of what you will be getting on Wednesday, April 26, at 1:15 p.m.
