Last updated at Fri, 29 Dec 2023 20:05:47 GMT
This is part two of a three-part series in our All in on AppSec Series.
In part one of our series, we looked at the problems companies face when it comes to creating an application security program and the various solutions for each. We also discussed how the structure of your software development lifecycle (SDLC) can be improved to produce better and safer software using application security best practices. In this post, we’re taking a look at the various application security testing technologies and how to determine which is best for your organization.
Application testing technology is not new
The industry has actually been using these tools for quite a while, but we just haven’t used them for security testing until recently. For decades, quality engineering teams have written unit tests using technologies such as headless browsers to test the functionality of the business logic within an application. We can leverage many of these same tools to write tests that are specific to security vulnerabilities. Using a list like the OWASP Top 10, we can write and automate these tests to scan applications for the most common web application vulnerabilities.
As an industry, we are also getting better at utilizing larger, heavier tools such as application scanners that leverage CI/CD tools like Jenkins to perform dynamic scans via APIs. Based on the results of each scan, we can determine within the CI/CD pipeline whether an application, feature, or set of features is ready for production.
If your organization is just getting started with application security, start by looking at what your development team already has in place and leverage that. If you have a quality assurance program or a CI/CD process, begin there. However, if you have an established security team, you may have static and/or dynamic testing technology that you can leverage.
Security-specific testing: Dynamic testing (DAST) and static testing (SAST)
When it comes to application security testing specifically, there are two main categories:
- Testing the source code of an application (referred to as static testing, or SAST)
- Testing the running version of the application interacting with content accessible by a client/browser (referred to dynamic application security testing, or DAST)
Most developers are familiar with SAST, but with advancement in SDLCs, DAST has become just as important. In the past few years, as more and more companies have moved toward agile development practices, it’s become imperative that security testing keep pace with software builds and releases in order to ensure applications are secure. To do this, application security testing needs to be built into the SDLC, allowing developers to test code before it ever reaches production. This is where DAST comes in.
In practice, this means that when a developer commits code and the build process runs, the application is scanned automatically. Depending on the results of the test, the developer can go back and make changes before that code is pushed to production.
This is becoming the preferred way to test applications, as it’s far cheaper and more efficient to do so rather than when code is already in production. In this scenario, both SAST and DAST solutions would be appropriate and are often utilized in tandem.
Advancements in application security testing
Interactive application security testing
For many organizations, static and dynamic testing capabilities are both required. This has led to the emergence of interactive application security testing (IAST), which tests whether known vulnerabilities in code are exploitable in the running application. While IAST tools work well in agile and DevOps environments and can reduce the number of false positives, the tool introduces a level of sophistication that only experienced security, QA, development, and product teams should take on.
Before adoption, organizations should seek buy-in from all stakeholders in the application development and security process and agree that an IAST tool is needed, teams are proficient enough to use the tool effectively, and that its benefits outweigh any drawbacks.
Runtime application security protection (RASP)
Another form of application security is runtime application security protection (RASP). RASP monitors an application’s behavior and context of the behavior to identify and protect against threats in real-time without human intervention. More or less, it accepts and reads traffic and behavior requests that hit an application and decides whether it needs to take action based on what that traffic is doing.
When considering a RASP solution, organizations should understand the potential impact RASP may have on application performance. Some tools may cause latency, which will affect end-user experience. Organizations should also consider the goal of RASP, which is to shield an application from exploitation. The tool does not help remediate the vulnerabilities that exist within the application.
Investing in application security testing
Web applications are the bread and butter of many organizations today, so keeping them secure not only safeguards company data, but customer data, too. That’s why it’s so important to choose the right technology for you.
While there are upfront costs of any application security testing solution, the long-term benefit greatly outweighs them. As you make your decision, here are a few points to consider:
- If you are running legacy apps, traditional SAST or DAST solutions are more applicable and should be leveraged in building a robust application security program.
- For organizations that have already have a strong application security program, IAST becomes desirable and beneficial.
- RASP solutions detect and block threats that can lead to vulnerability exploitation until the vulnerability can be remediated.
- Whether you're using SAST or DAST, you need to consider the time investment for building, tuning, and maintaining each solution. This means you need the right individuals to set it up, whether that be third-party or in-house personnel.
- If you have the time, resources, and experience to implement and maintain IAST, it can become a component of the app itself for close monitoring and reducing the need to manage a SAST or DAST separately. However, don’t forget you may need to get additional buy-in for these more sophisticated integrations and that you’ll need to make sure they won’t create any unwanted performance impact.
In the long run, whichever option you choose, you will see immense benefits in the form of better-quality code, fewer bugs and sprints to fix them, and more time to focus on building features. Being proactive with security is always the best approach, as it can limit exposure to vulnerabilities when they’re found early on, shorten the time to respond, and build a security-minded culture across your organization. Being reactive, on the other hand, can cause stress, increase costs, and negatively affect different teams and applications. In a world where time is of the essence and secure, trustworthy products can make or break a business, being proactive is non-negotiable.
As a reminder, you can always start with a basic approach (in fact, we recommend this) and build and improve upon it over time. This will allow you to learn as you go and not get in over your head too fast with something you can’t maintain right now.
Seeing application security as a competitive differentiator
Without a doubt, good application security testing practices can set you apart as a vendor. Many companies today put a lot of weight into their vendors’ level of security, so if you can prove that you have a solid application security program and that it’s an absolute priority, you will have a higher likelihood of winning new customers over organizations that don’t take it as seriously.
Application security isn’t just about building better applications and code—it’s also about assuring your customers that you have excellent software that has been rigorously tested. This can set you apart and become an incredible business driver.
