A DevSecOps transformation usually leverages two main levers in order to be efficient: a change in culture and a change of tools. These two levers are complementary: the right tools without a cultural change, and a cultural change without the right tools, both scenarios could lead to massive failures.
We conducted approximately 50 interviews with organizations moving to a DevSecOps model, in order to know what tools they use, how they exercise them, and the results achieved so far. This blog post will dig into all that and much more.
Quite often, security testing is introduced at the last minute in the development phase, when changes are costly and bear a grave risk. Building secure and compliant applications is a challenge in today’s complicated digital ecosystem. When you embark on the journey to a secure application delivery, you can discover a number of budding technologies like SCA, SAST, DAST, IAST, WAF, RASP, on the way. Depending on your end goal and the maturity of your software development efforts, you need to decide which technology suits the needs of your DevSecOps team the best. A bit confused about the existing markets? Let us dive deep!
Static Application Security Testing (SAST): inspects source code from inside
Static Application Security Testing (SAST) is a white box testing approach. It examines the files containing the static source code, to find vulnerabilities early in the SDLC and make the code stronger. This saves development teams the expense of addressing the issues after deployment: the earlier you find a vulnerability, the lesser it costs to be fixed; it is what makes the DevSecOps approach so efficient.
However, SAST gives rise to a huge number of false positives, costing valuable time and effort. The tool uses semantic analysis where the tester needs to understand the semantics of the different programming languages used. It can detect memory issues, programming errors or SQL injections, but is not able to find all possible types of application security vulnerabilities in pre-production such as authentication or access control problems, configuration issues etc. Developers need to investigate further to determine if the detected weakness is a real risk, which makes this a daunting task. SAST is powerful, as long as you invest enough time to master the solution, and fine-tune it to avoid too many false positives.
Software Composition Analysis (SCA): provides visibility into project dependencies
Software Composition Analysis (SCA) helps developers scrutinize and handle open source and third party components in their applications, throughout the SDLC. When using a framework, hundreds of dependencies, with a high number of vulnerabilities, could be involved. Nowadays, manual tracking of dependencies is impossible due to the increasing complexity of applications. Automation is necessary, in order to scan the application source code and identify direct or indirect dependencies in it. This way, vulnerabilities can be found early on in the development and production phase. Once identified, they can be fixed with less costs and efforts.
SCA provides good insight but it can be nightmarish to track and correct all the vulnerabilities it spots. Unable to keep up with the influx of vulnerabilities, companies choose to prioritize the most critical ones. Nevertheless, before resolving a vulnerability, you should be able to identify it, which is why SCA is getting more popular amongst DevSecOps teams.
Dynamic Application Security Testing (DAST): tests application from outside
Dynamic Application Security Testing (DAST) is a black box testing approach. It examines the application by executing it in a production-like environment simulation and attempting to penetrate it from outside. This dynamic analysis helps find run-time vulnerabilities, also in third party code, towards the end of the SDLC.
However, DAST cannot identify the vulnerable lines of code that cause a security vulnerability and is oblivious to what is occurring inside the application. It is used in a preproduction environment, and once the application is in run phase. An application could be put in production when no more vulnerabilities are found. However, a new vulnerability could surface even after the application has been released. That is why it is important to use this tool in both stages.
Interactive Application Security Testing (IAST): monitors vulnerabilities in real time
Interactive Application Security Testing (IAST) is a glass box testing approach that blends aspects of both SAST and DAST. Like DAST, it detects and monitors vulnerabilities in real time, using continuous dynamic testing methods. In addition, like SAST, it analyzes the source code itself. It is performed from within the application while application is running during testing stage of the SDLC. It can also determine the exact lines of source code that cause a vulnerability, early on, allowing it to be fixed quickly. It moderates false positive rate, generates results that are more accurate, is scalable and can be automated.
However, it does not examine the whole code base, which means it does not deliver comprehensive coverage. It might not support the language and technology used in your organization, and affects the performance of the protected backend. Moreover, it only exposes the vulnerability but does not prevent the suspicious query in production. Many of the interviewed companies prefer to use SAST & DAST in tandem rather than using an IAST technology.
Runtime Application Self-Protection (RASP): protects applications in runtime
Runtime Application Self-Protection (RASP) analyzes the running application’s behavior and context to reveal attacks accurately in real time. It can differentiate legitimate requests from malicious ones, thus reducing false positives, and blocking actual threats.
However, a RASP solution is not agnostic, as it needs to be congruent with the language and technology stack in your organization. It rests on the application backend and has a detrimental effect on its performance and stability.
Fig: Complementarity of the tools in this overview and their capabilities for an organization’s holistic application security strategy
Therefore, SAST and DAST are not sufficient to ensure the security of your application. And classical WAFs, handled by production teams, protect only its run phase. What you need alongside, is a true DevSecOps solution that complements both SAST and DAST to protect your cloud native applications against major attacks, at all stages of the SDLC.
The next generation of Web Application Firewall: A Cloud Native Application Protection Platform
The WAF market has evolved to fit DevOps requirements by automating the deployment and scalability of application protection.
Rohde & Schwarz has introduced R&S®Trusted Application Factory, a modern cloud native application protection solution. This product, deployed as a container, can be directly integrated into the CI/CD pipeline of DevSecOps teams, and easily configured through configuration files, committed close to the application’s source code. Achieving interoperability within the CI/CD domain is key.
Thanks to its context description module, you can have the same context as a RASP, and use it with a large variety of programming languages, without affecting the application’s performance. Context description describes an application easily (i.e. its operating system, programming language, etc.) in order to have a tailored security policy per application.
Associated with SAST, DAST, SCA, and bug bounties, this technology lowers the time required to correct a vulnerability. It displays value upfront by testing the application in a preproduction environment, to protect it during run phase. In addition, custom rules, described in configuration files, can be injected to the container. It helps save time by virtual patching a vulnerability found by SAST, DAST or a bug bounty program.
Of course, there are many other interesting markets to explore, including emerging ones like API security testing and discovery, or serverless function security, which could address DevSecOps needs. Other products could be integrated into the CI/CD pipeline to augment the security level, like secret management, pre-commit hooks, etc.
SAST, SCA, DAST and cloud native application protection solutions are clear markets that allow organizations to shift left security to the build and test phase.
Furthermore, cloud native application protection solutions like R&S®Trusted Application Factory, not only protect the run phase of your application, but also offer tools during the build phase to augment the level of your applied security policy.