The Sisyphean Task of Vulnerability Management
According to Greek mythology, Zeus punished Sisyphus for cheating death (twice!) by forcing him to roll a boulder up a hill only for it to roll down each time it neared the top; he had to repeat this action for eternity. The thought of the continuous, repetitious battle that Sisyphus waged against the weight of the boulder brings to mind the challenges facing today’s security teams.
Shift left scanning is not sufficient to mitigate the risk of constant attacks against software vulnerabilities in your application and infrastructure—it’s a worthwhile endeavor but, alone, it is not enough to stop the boulder from rolling back down the hill. Security teams need to be able to see threats to applications in production, across clouds, Kubernetes, serverless and more.
The Challenge: Hill Meets Boulder
The derivative nature of modern software and applications makes them complex. The perpetual iteration that comes from CI/CD makes software and applications ever-changing. These two central factors for security teams—complexity and constant change—are much like the hill and the boulder.
Complexity
Applications and software aren’t developed in isolation. Developers use many different open source and third-party components to construct their own unique products. There are definite benefits to using open source and third-party code as building blocks. The wide range of high-quality open source and third-party components gives development teams a way to innovate quickly to meet continued demands from consumers, stakeholders and shareholders.
But there’s also a downside. The more components that are woven together, the more complex the entity as a whole becomes. A single application can be made up of hundreds of microservices, each receiving updates at different cadences. Similarly, the dependencies of an application change quickly and pull in dependencies of their own. Just knowing what’s in the software or application that you deliver becomes a difficult task.
Constant Change
The CI/CD lifecycle has amplified the rate of change to software and applications. Many organizations have embraced this methodology to integrate and deliver smaller code changes more efficiently and frequently. Developers and DevOps teams add new features, enhance existing capabilities, correct defaults, fix bugs, accommodate integrations and make other changes on a constant basis. Some notable organizations reportedly deploy changes tens of thousands of times per day.
The ever-changing nature of software, coupled with the complexity of how it is architected, makes securing applications and the infrastructure they rely on a nearly insurmountable challenge.
Continuous Boulder Rolling: Never-Ending Vulnerabilities and Threats
In 2021, MITRE published 20,141 CVEs (up from 18,325 in 2020). Sonatype reported that in 2021, software supply chain attacks increased by 650%, up from a 430% increase in 2020. There are many other reports and surveys that offer similarly telling statistics. There are more risks now than ever before, and attacks against those risks continue to grow in number and severity.
Adding to the frustration is the fact that it takes time to find vulnerabilities. GitHub found that, on average, it takes four years to discover a software vulnerability (plus even more time to secure it). Tomorrow’s problems are already here—we just haven’t found them yet.
Additionally, the more you scan for vulnerabilities (and you should!), the more vulnerabilities you find. Addressing vulnerabilities is a never-ending endeavor that is already challenging for many organizations and will likely get more complex over time.
The Solution
Shift left initiatives help organizations secure the code they shipped into production.
Similarly, Software Bills of Materials (SBOMs) are on the rise to help bring to light if and where, in produced or consumed software, vulnerable components are present. But, just because you made the decision that your code was secure enough when you pushed it to production, or you were comfortable with the security level at the time the SBOM was published, does not guarantee that security persists as changes are introduced and components and their dependencies shift. With the dynamic nature of modern applications and infrastructures, how can organizations verify the security of the latest code that is now running in production?
One way to break free is by ensuring security teams have the visibility and relevant, contextual data they need to execute leading-edge threat detection, making it easier to find even the most subtle suspicious or malicious activities that indicate an attack is underway. This security observability approach offers true end-to-end visibility and context, from code through production, across all clouds and cloud modalities, and it should be the foundation of any modern security strategy. By adding runtime context and correlating this information with vulnerability indexes and indicators of attack and compromise, security teams will evolve beyond the constant boulder pushing, toward a new paradigm of exploitation management.
This level of visibility should also provide a way to generate a runtime SBOM—a subset of a standard SBOM created from only the applications, services, and infrastructure that are running right now in production. For example, of the 10,000 packages listed in a traditional static SBOM, how many are actually running and are at risk of being exploited right now? By understanding what’s in play, security teams can focus on the actionable subset of security issues that are most relevant.
It’s past time to take a new approach to application security. Using the power of telemetry, deep packet inspection, and correlational analysis to create better visibility and context, teams can stop rolling boulders uphill and instead use them to successfully defend against attacks.
