Last updated at Sat, 09 Dec 2023 23:13:10 GMT

With web-based attacks on the rise, application security is a hot topic today. And we’re not even talking zero-day attacks, but tried-and-true SQL injections (SQLi), cross-site scripting (XSS), and other methods that have been around for quite a while. Although web apps are the bread and butter of so many companies today, they are often not given the same security protections as other parts of the IT environment.

Because of this, we will discuss all things web applications and how to select the right application security solution to keep them safe from attack.

The security risks of today’s web applications

Development teams have adopted fast release cycles and continuous development, so they don’t have time to write and build code from scratch, making apps complex and often unable to be scanned by traditional web scanners. If a scanner is built to detect name and value pairs and is presented with a web app with a modern web framework, it might not be able to scan it and could require manual intervention—that is, if that person knows what to look for. In addition to that, functionality spread across APIs, microservices, and other components makes it difficult to see these parts as one cohesive application.

Another result of rapid development cycles that adds complexity to security is the reuse of code from open source libraries, but if that kit has a known vulnerability in it and you unknowingly introduce it into your environment, you could open your organization up to more risk. Furthermore, development teams often set up new apps and systems using their default configurations as a way to run fast, but these can create holes in your security posture. With many opportunities to introduce risk to the environment, web apps need proper security.

4 modern approaches to application security testing and protection

Now that you know why web apps need the right security layers in place, how do you choose the right solution? With different tools built for different use cases, we’ll cover the top three appsec solutions below and the criteria in which you can evaluate which one is right for you.

Static application security testing (SAST)

SAST solutions have been around for a while now, with several pros and cons:

Pros:

  • Fixes vulnerabilities at their source (earlier in the SDLC, where it’s easier to fix them) by signature-mapping lines of code that are known to present risk
  • No impact on the production environment
  • Encourages good code hygiene by integrating directly into the dev environment
  • Valuable for secure development practices

Cons

  • Requires different implementations for different languages or frameworks
  • Difficult to manage if you’re not on the dev team
  • Difficult to deploy at scale
  • Not a substitution for building applications with security in mind
  • Doesn’t run during application runtime

Dynamic application security testing (DAST)

DAST tools take a modern approach to SAST, with several more benefits:

Pros:

  • Easy to deploy and manage and doesn’t require the dev team to get involved
  • Not bound by a particular language or technology, enabling you to run one DAST for everything
  • Fewer false positives than SAST and designed to tune out noise so you can zero in on real threats
  • Simulates attacks like an attacker and finds vulnerabilities that SAST tools cannot
  • Integrates into the CI/CD pipeline to provide code and build checks along the way

Cons:

  • Dev teams are often not convinced of the value of DAST, since the results often mean more work for them
  • If it’s only run in production, you may not catch vulns in time
  • Cannot scan source code

Interactive application security testing (IAST)

A combination of SAST and DAST capabilities, IAST can come in many flavors—either a combination of the two that presents both results, or able to aggregate and correlate results to see vulnerabilities from both perspectives.

Pros:

  • Can correlate vulns found after build with lines of code
  • Improves accuracy of SAST solutions by incorporating results from runtime analysis

Cons:

  • Not yet widely adopted due to cost
  • Requires expertise to implement and run
  • Lacks combined coverage across certain languages and frameworks
  • Requires deployment of an agent and dev buy-in

Runtime application self-protection (RASP)

RASP enables the app to defend itself not by scanning but by running alongside the app.

Pros:

  • Identifies and blocks threats in real-time without human intervention (bypasses needing to interrogate the router, since it lives on the app itself)
  • Watches the application at runtime to see what actions take place (rather than trying to predict them) and can block requests that may be indicative of a zero-day attack
  • Significantly fewer false positives than traditional WAFs.

Cons:

  • Not widely adopted due to being a newer technology.
  • Requires deployment of an agent.
  • Could block revenue-generating traffic if misconfigured.

How to choose the right application security tool

By now, you may have already gained some clarity on which appsec solution is right for you. It’s important to consider other aspects of the business that this decision could impact, such as IT, compliance, legal, security maturity, and overall corporate strategy considerations. Think about how the application security solution you choose could support all of these areas.

To know for sure, we recommend trying a few solutions on for size to see how they work in your environment and evaluate them with the following criteria:

  • Do I have complete coverage/visibility across the entire application, even non-navigable parts like the API and microservices?
  • Once I get results, what can I do with them? Is there a process to share them with the development team or work with a vendor?
  • How do I manage security data across all my apps? Do I need to dedicate a team to it, create a flow chart, or get another solution to manage all the scan data?
  • Can I catch vulnerabilities earlier (pre-production) to reduce headaches and costs later?

Start where you are: 3 common use cases

A major factor that plays into which appsec solution is right for you is where you are in your security maturity. Below are the three phases of security maturity when it comes to application security, along with guidance on what solutions are most appropriate at that phase.

Use case 1: “I’m not sure where to start, but I need SOMETHING:

You’re new to application security and are starting to build a program but don’t yet have visibility to the development process.

Critical needs:

  • Vulnerability scanning
  • Assess and report on risks
  • Demonstrate level of compliance

Where to start:

  • Managed services: You can pick programs that offer white-glove service or can help you bring this in-house.
  • Penetration testing: If you need to be in compliance, you’ll either need to schedule regular penetration tests with a vendor or put in place your own tests so you can continuously improve your security posture. Learn more about Rapid7’s pen testing services.
  • Consultative services: Many companies new to security will partner with companies like Rapid7 to build out their appsec program. It’s like having a CISO in a box!
  • Ad-hoc DAST scanning: Leverage a solution like InsightAppSec to run continuously against your apps
  • Begin building relationships with the dev team: This is especially important if you have plans to implement DevOps or SecOps in the future.

Use case 2: “I want to do more with what I have”

You have a defined application security program and the beginnings of a DevOps program but no true CI/CD or cross-departmental alignment yet. You also don’t have a dedicated appsec team yet, but you may have some dedicated appsec engineers helping out in the interim.

Critical needs:

  • Scheduling
  • Advanced searching/reporting
  • Vulnerability validation
  • Ticketing/SDLC integration

Where to start:

  • Consider DAST scan efficiency: Decide if hosting it in your environment or on the cloud is more efficient.
  • Combine forces: Use SAST and DAST together by potentially leveraging IAST.
  • Look at shifting left with DAST scanning: Let the development team experiment with scanning themselves through SDLC integrations or working with them on reading the results.

Use case 3: “I want to take it to the next level”

Application security is critical to your business, and you have a DevOps team that either runs security or is closely aligned with the InfoSec team. You’ve implemented CI/CD practices and are open to new approaches.

Critical needs:

  • Integration with CI/CD tools
  • Robust API
  • Real-time mitigation
  • Data export

Where to start:

  • Fully integrate with build automation platforms like Jenkins to execute DAST scans immediately following a build. Implement pass/fail build logic based on scan results.
  • Automate SAST/DAST results correlation for deeper insights.
  • Implement runtime visibility (RASP).
  • Automated/incremental validation.
  • Application discovery

Implementing your appsec program

Application security isn’t necessarily hard, but the landscape can be confusing with so many solutions to choose from. It’s important to do what’s best for your organization, and that starts with knowing your goals and the resources you have to allocate to them. The bottom line is that you want to be able to find and remediate vulnerabilities as early as possible to reduce costs and save time—while keeping your organization secure.

InsightAppSec, our cloud-managed DAST solution, can run multiple scans across multiple applications. You can host it on-premises or in the cloud and schedule scans at intervals of your choosing. It then gives you detailed descriptions of what it found, as well as guidance on what to do and visibility into the remediation process.