Dynamic IT environments have made application security more complex than ever. Learn how your organization can create software quickly and securely.
Application security is a software engineering term that refers to several different types of security practices designed to ensure applications do not contain vulnerabilities that could allow illicit access to sensitive data, unauthorized code modification, or resource hijacking.
While this mission is easy enough to understand, applications aren’t as simple as they used to be, and ensuring they are secure has become more challenging. Modern software development environments require a new approach to application security (AppSec) to build and deliver software both quickly and securely.
The problem with the traditional approach
Part of what contributes to the complexity of modern applications is they are often more assembled than they are written. Today’s cloud-native applications are predominately built from open-source components, or packages, strung together with a small amount of custom code. While this approach helps organizations deliver applications faster and more efficiently, it has made AppSec more complex than ever, creating blind spots and uncertainty about vulnerabilities within cloud-native applications. Gartner cites research that indicates more than 70% of applications contain flaws resulting from embedded open-source software.
These changes have had a tremendous impact on how applications need to be secured. To understand this change and the shift required to address it, we first have to understand what traditional AppSec is all about.
Application security tests and what they do
Application security used to be a function performed by the security team. Once an application passed all the functional tests, and before it moved into production, it was put through a gauntlet of security tests. Security teams would use one or more of the following types of application security tests (ASTs):
Here are some of the most common types of AST:
- Static (SAST): This type of AST uses solutions that scan source code for security vulnerabilities such as buffer overflows or SQL Injection flaws.
- Dynamic (DAST): In contrast to SAST, DAST examines applications from the outside, looking for vulnerabilities such as Cross-Site Scripting and Command Injection. The source code isn’t needed to perform DAST, as the application is inspected while it is running.
- Interactive (IAST): IAST combines SAST and DAST together and improves on them by instrumenting applications to support deeper vulnerability analysis beyond exposed surfaces. IAST only works with languages that have a virtual runtime environment, such as Java, C#, Python, and Node.js.
- Runtime application self-protection (RASP): Unlike the other types of tests, RASP runs on the inside and observes what the code is doing. RASP can identify both vulnerabilities and malicious activities. Certain forms of RASP can actually shut down malicious activities once they are detected.
- Software Composition Analysis (SCA): This function is sometimes included within a SAST tool, but more often it is a separate tool that allows software developers to assess open-source code for vulnerabilities and for overly strict licensing requirements.
Once an application moves into the production environment, teams usually use other tools to monitor the applications. These include vulnerability scanners and network detection and response systems designed to detect attacks.
So, why is all this important?
Traditional approaches to AppSec served well for a time, but they simply can’t keep up with today’s accelerated SDLC and the complex nature of cloud-native applications.
In past years, most security testing took place post-development. But rising complexity and interdependency among the components of modern applications means that by the time development is complete, any error or vulnerability can be firmly ingrained, making fixes difficult and time-consuming. As application security shifts left to address this issue, organizations have tried to retrofit traditional AST methods to operate as part of a DevOps tool chain.
Results, unfortunately, have been mixed.
How open-source packages have changed the game
Besides efficiency issues, most traditional AppSec tools are unable to properly assess the risk of open-source packages. The tools tend to report every vulnerability they detect, whether or not the application actually uses the open-source package or library. If the application does not use the open-source package, it cannot be attacked, and the vulnerability is, therefore, not a legitimate risk. The result is a long list of vulnerability alerts that may or may not expose actual risk, and one of the following will happen:
- The project will slow down while the developers stop to fix every vulnerability reported by the AST tool
- The developers will ignore the security test results and push the application to production, hoping that an exploitable vulnerability won’t get attacked
We need a better approach.
An automatic and intelligent application security solution
To keep pace with cloud-native technologies and ensure adequate application security in both pre-production and production environments, organizations can’t rely on conventional approaches and manual processes. They need a solution with AI and automation at the core to provide real-time detection and alerting, eliminate blind spots, and identify new post-deployment risks. That’s where Dynatrace comes in.
With the release of its Application Security Module, Dynatrace has extended the automation, AI, and scalability of the Software Intelligence Platform to cover modern cloud application use cases that scale across even the broadest, most complex cloud architectures.
The Application Security module includes the Dynatrace AI engine, Davis, which helps developers prioritize security issues while eliminating false positives. Application Security enables DevSecOps teams to innovate at the speed required by the business so they can release software quickly and securely.