When Dick Fosbury won the Olympic gold medal in the high jump in Mexico City in 1968, it was the first time that most of the world had ever seen his style of jumping, and it revolutionized the sport. What appeared to be novel at the time - jumping while leading with his back, instead of the conventional forward-facing straddle or roll - was soon copied pervasively. At the next Summer Olympics in 1972, 28 out of 40 high jumpers used the ‘Fosbury Flop’, the technique popularized by Fosbury. Today, it is the dominant high-jumping technique, as the physics and biomechanics of this style of jumping are superior.
The keys that unlocked this superior performance? An environmental change, and a bold innovator who took advantage of that shift. In the following paragraphs, we’ll see how that relates to the quantum leap that is now occurring in application security for modern distributed applications…. what’s commonly referred to as cloud-native applications.
When Fosbury was in high school, the high jump landing pit at his school was made of wood chips and sawdust. Just before his junior year, his school became one of the first to replace the chips and sawdust with a foam landing pit. That gave Fosbury the harebrained idea to try jumping backwards, landing on his back and neck, instead of the forward technique that was prevalent at the time. His technique would have been impossible before the introduction of that foam pit, or at the very least, extremely painful and potentially career-ending.
What is the shift in application security that parallels the change in high jumping? Software observability can be considered the ‘foam pit of AppSec’. Its introduction into the application security use case enables a superior approach to securing modern, distributed applications. By leveraging observability for application security, companies are realizing massive reductions in their lost lists of vulnerabilities due to the elimination of noise and false positives. They’re also reducing their application security testing tool costs by not having to deploy multiple, disjointed tools, and realizing savings in AppSec-related operational costs.
Software observability enables practitioners to gain insight into the performance and behavior of application systems, especially in complex distributed environments. In practice, it involves collecting and analyzing data from a variety of different sources such as application logs, metrics, and traces in order to provide a comprehensive view of the application’s behavior, and also to identify any potential issues in the system.
The idea of application observability first emerged in response to the changes in application architecture. Modern day application systems have become increasingly distributed and complex, making it more difficult to identify and diagnose issues in the application. Observability was originally developed to help bridge the gap between developers and operations teams, and enhance collaboration between them so they could build and maintain resilient and scalable application systems more effectively.
Observability is enabled by telemetry, the collection of data that’s generated at endpoints and services in cloud-based application deployments. In these modern systems, activity data is collected from application and cloud infrastructure components, as well as containers, open-source tools, and microservices. Observability exists to understand what is happening between the technologies, across these environments, and to provide rich data that will enable us to detect and fix issues so that we can maintain our systems working optimally and reliably.
There are a number of use cases for observability, including, but not limited to the following:
Debugging Software: By analyzing logs, metrics, and traces, developers can use observability to identify bugs in code and to diagnose them so they can find the cause of the issues and fix them faster.
Optimizing Software Performance: Developers can identify bottlenecks using observability so they can optimize their application. Through the analysis of metrics and tracing the flow of calls through the system, observability enables application engineers to identify components that are slow or inefficient, and make changes that will improve their performance.
Improving Software Security: With modern, distributed applications, application observability can be used to improve application security and address the myriad problems of using outdated AppSec technologies to test and secure modern applications. Application security engineers and development teams can benefit from using the logs, metrics and traces to reveal applicable insights that were simply not available to them before, to reduce noise, surface the most relevant and pressing security issues, and lower operational expenses related to application security.
The composition of application vulnerabilities has changed as a result of the shift from monolithic applications to cloud native applications. In the days of yore, an application was a giant chunk of code deployed on a bare metal server, and the source and sink for vulnerabilities resided in the same code. Legacy Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) tools were developed in response to the security needs of this application architecture. Today, the source and the sink - the origin point and the vulnerable service - cross microservices, and are affected by the infrastructure configurations.
DAST tools take a closed-box approach, interacting with the application through a web frontend to identify possible application vulnerabilities by injecting a malicious payload into that box, then looking for anomalous behaviors. DAST tools are blind - they have no information about the code inside, so they don’t know how that anomalous behavior, which might not be a real vulnerability to begin with (a big problem in itself, resulting in false positives), is connected to any of the code inside. This is among their shortcomings.
SAST tools, on the other hand, take an open-box approach (i.e. it sees the actual code), scanning the code before it’s compiled. However, with distributed applications, SAST tools have no ability to understand the important runtime context i.e. they only see what’s within the component that they scanned, and miss any vulnerabilities that occur when the components communicate with each other at runtime.
Observability allows us to dissolve the walls of these boxes to eliminate the blind spots of traditional SAST and DAST tools, and finally see the path that vulnerabilities take from their origin point - a publicly–facing API, across one or more microservices, into a vulnerable microservice, even if that vulnerable microservice doesn’t have an externally-facing API. The other end of that path? The specific line of code that needs to be remediated. This runtime component of the analysis is critical in removing the blind spots that exist in application security tools from the past - your legacy SAST and DAST tools. Observability also helps to reveal whether a custom code vulnerability can actually be accessed from the Internet or not. If it can’t, then we can eliminate it from consideration when prioritizing vulnerabilities that need to be remediated.
For Software Composition Analysis (SCA) tools, observability allows us to know with certainty whether a vulnerable open source or third party package is actually exploitable, because it can help us determine whether the package is accessible from the Internet, and whether the package is actually used at runtime. In practice, only 3-5% of vulnerable packages that are discovered by SCA tools fit both these criteria, so observability unlocks a massive improvement in efficiency for application and application security teams.
In the same way that foam pits enabled athletes to accomplish so much more in the sport of high-jumping, observability is unlocking many more insights for application security. With better visibility into all the inner workings of modern applications - code, container, cloud, cluster and their connections and communications, much more thorough and robust analyses can be performed to improve all metrics associated with application security - number of false positives, number of false negatives, time to remediation, tool costs, and operational costs.
While the use of observability in AppSec is still nascent, the results from its use portend the future for securing modern distributed applications. Just like the wood chips and sawdust of yesteryear’s high-jumping, legacy SAST, DAST and SCA are an anachronism in modern day application security. It’s time to fully embrace observability for securing these applications, and finally break through the limits imposed by an outdated way of doing things. The prize? Lower tool costs, lower operational costs, and better application security.
Our CTO, Ron Vider presented to an audience of over 1200 people at KubeCon Europe in Amsterdam on the topic of using observability, through the use of OpenTelemetry, for application security. Watch the video to learn more.
