Survey

SANS Application
and API Security
Survey 2024
Written by David Hazar and Matt Bromiley
June 2024

©2024 SANS™ Institute

Executive Summary
The velocity at which companies are building and changing applications seems to be increasing
each year. Technologies such as containers, services in the cloud such as Kubernetes, development
methodologies such as DevSecOps, design patterns such as microservices, and coding assistance
through generative AI (GenAI) have enabled development and operations teams to keep apace.
Although security testing capabilities have also improved, the value of individual testing
capabilities has changed in response to increased threats and changing application architectures.
Application and API security is not quite as ubiquitous as infrastructure vulnerability management
when looking at what is included in organizations’ security programs. However, it is becoming
more and more important as cloud platforms, serverless, zero trust, and other security efforts
have helped to mitigate more of the infrastructure threats. Application and API vulnerability
identification is more complicated than infrastructure vulnerability identification and requires a
more diverse toolset, which can lead to more complexity and frustration during the rollout of an
application security program, as well as later, as it continues to operate. Although complicated,
applications and APIs have become the lifeblood and gatekeepers of many organizations’ most
sensitive information—so applications and APIs cannot be ignored.
In this survey, we asked participants to tell us about where they are getting the most value from
their application security program by trying to better understand which identification technologies
or processes have been most effective or have provided the most value based on the application
architecture. It was interesting that manual penetration testing scored high in nearly every category
for value even though it tends to be the most expensive and time-consuming type of testing.
One possible explanation for the high scores given for manual penetration testing is that
automated tools struggle to cover a variety of different types of vulnerabilities such as broken
access control and business logic flaws. They are prone to more false positives because
penetration test findings are pre-validated. When humans are involved in the testing process,
they can understand better how the application is supposed to function and, with this additional
context, can find ways to circumvent the intended functionality. Another explanation could be that
the prevalence of this type of testing is higher due to specific compliance requirements. Finally, it
could also be that this type of testing is historically less reliant on in-house resources, and many
organizations perform it without having fully implemented a formal application security program
(which is less common for the other testing types).
Software Composition Analysis (SCA) has emerged from relative obscurity over the last decade
to become one of the easier, cheaper technologies to integrate into the software development
lifecycle. Although it is not perfect, it tends to not be as cumbersome to implement and maintain
as other testing technologies, which aligns with the results of our survey.
Static Application Security Testing (SAST), Software Composition Analysis, and Dynamic Application
Security Testing (DAST) came out at the top of many questions in our survey. Although they weren’t
always rated the highest in terms of value for each of the different application types, they are
easier to implement, maintain, and get support for from development teams than some of the
other testing methods.
One clear finding from the survey was that it is important to test throughout the application
lifecycle using a variety of methods. Although testing early continues to be important, having
visibility into and being able to monitor and test deployed applications is still critical.

SANS Application and API Security Survey 2024 2

Survey Demographics
For this survey, a larger percentage of respondents came from organizations providing
security, technology, and application development services, followed by finance and
education. When asking about staffing within the respondents’ organizations, application
developers and software engineers tended to be found in greater numbers than other roles,
with security and operational roles having fewer numbers.

For organization size, the respondents leaned a little bit toward small to midsize, but
large to extremely large enterprises still made up a good percentage. Looking at survey
respondents, security-oriented roles garnered the top three spots, followed by application
developers and business managers. Many respondent organizations had headquarters in
the United States and Europe, but more than 20% had operations in almost all regions of
the world (see Figure 1).

Top 4 Industries Represented Organizational Size

Small
Cybersecurity (Up to 1,000)

Small/Medium
(1,001–5,000)
Technology
Medium
(5,001–15,000)
Application
development Medium/Large
(15,001–50,000)

Banking and Large

(More than 50,000)
finance
Each building represents 10 respondents.
Each gear represents 5 respondents.

Operations and Headquarters Top 4 Roles Represented

Security administrator/
Ops: 85 security analyst
HQ: 14 Ops: 82
HQ: 13
Ops: 88
HQ: 25 Product security

Security architect
Ops: 183 Ops: 59
HQ: 163 HQ: 2

Ops: 36 Application developer

Ops: 53 HQ: 4
Ops: 57
HQ: 14
HQ: 13 Each person represents 5 respondents.

Figure 1. Key Demographic Information

SANS Application and API Security Survey 2024 3

 Does your organization develop and
Survey Results and Key Findings support applications and/or APIs?

About 80% of the respondents indicated that their organization

developed and supported applications or APIs. These are the 12.5%
respondents who were included in the full survey. See Figure 2.
7.7% Yes
Although traditional form-based web applications still make up
No
slightly more than 60% of our applications, REST APIs are close behind
at 56%, followed by single-page web applications at 48%. In addition, 79.8% Unknown/unsure

the other application types are still well represented, with even SOAP
APIs and GraphQL APIs coming in at over 20%. This points to continued
and increasing diversity in the application development and security
ecosystem and highlights the need for a diverse set of solutions for Figure 2. Development and Support of
securing our custom-developed software. See Figure 3. Applications and/or APIs

About 35% of respondents consider

more than half of their applications
What types of applications and/or APIs are developed and supported by your organization?
or APIs to be microservices, while Select all that apply, but you need to select at least one.
11% said they had less than 60.1%
60%
10%. These statistics may be 55.6%

highlighting a trend away from 50% 48.0%

46.0%
43.9%
monolithic applications to smaller 40%
applications and APIs. Adding to this
30% 28.8%
hypothesis, the numbers for APIs
20.2%
are only slightly lower than those 20%

for microservices, which aligns with 10%

the fact that many microservices 1.5%
0%
are designed as APIs. Containers are Traditional REST API Single-page Installable Native SOAP API GraphQL API Other
form-based web web (thick client) mobile
more widely used than serverless application application application application

functions for running APIs, but Figure 3. Supported Applications and/or APIs
surprisingly not by an extremely
large margin. See Figure 4.

What percentage of your APIs are run in containers or as serverless functions?

In containers As serverless functions

16%
14.9% 14.4%
14% 13.7% 13.8%
12.1%
12%
10.5% 10.5% 10.6%
10% 9.5% 9.6% 9.5%
9.0%
8.4% 8.5%
8%
6.9% 6.9% 6.8%
6% 5.8%
4.7%
4% 3.7%
2.6%
2.1% 2.1%
2% 1.6% 1.6%
0.0%
0%
0% 1–10% 11–20% 21–30% 31–40% 41–50% 51–60% 61–70% 71–80% 81–90% 91–99% 100% Unknown/
unsure

Figure 4. API Usage in Containers vs. Serverless

SANS Application and API Security Survey 2024 4

The most interesting statistics for us were
Which application security testing technique provides the most value when
those related to the value associated with using testing your application types? Select your top choice for each application type.
different testing techniques across different
Manual code review Interactive Application Security Testing
application and API types. See Figures 5 and 6. Threat modeling (IAST)

Bug bounty programs  ynamic Application Security Testing

D
We personally knew the value associated with (DAST)
Red teaming
manual testing, but it was great to see that Static Application Security Testing (SAST)
Manual penetration testing
Software Composition Analysis (SCA)
acknowledged in the survey results. Manual  untime analysis/testing/protection tool
R
(e.g., runtime application self-protection
testing is costly and time consuming relative [RASP], runtime API security)
to other testing methodologies; however, the 1.6%
0.5%
additional understanding and insight that 1.6%
0.0%
humans can provide into how an application’s 3.1%
GraphQL API 3.6%
logic or authorization controls are supposed 2.1%
3.1%
to work versus how they actually work is 3.1%
1.0%
invaluable. 1.6%
2.1%
As mentioned earlier, because the tests are 2.6%
1.0%
14.6%
pre-validated by the testing team, there is REST API 8.3%
4.7%
much less noise associated with these findings. 9.4%
7.3%
This can help streamline remediation efforts 3.6%

for development teams because they are not 0.0%

0.0%
required to do as much of their own triage 1.6%
2.1%
5.7%
or analysis to determine if the risk is real. In SOAP API 3.6%
2.1%
addition, newer services such as penetration 4.7%
4.7%
testing as a service (PTaaS) may streamline the 1.6%

effort, lower the cost associated with engaging 1.0%

1.0%
0.5%
in manual testing activities, and fit better into 1.6%
10.4%
agile development methodologies. Many of Native mobile application 7.3%
4.2%
these firms have also gotten much better at 6.8%
5.7%
providing findings in a consumable format that 4.7%

is more easily integrated into the development 1.0%

1.6%
1.0%
workflow and backlog management tools, which 4.2%
8.9%
has been a struggle in the past. Single-page web application 4.7%
3.1%
5.2%
The survey shows that DAST tools are viewed 11.5%
5.2%
as the most valuable form of testing for
2.1%
traditional form-based web applications and 0.0%
0.5%
3.6%
are the most effective automated tool for API Traditional form-based 12.0%
web application 7.3%
testing. This makes sense, because form-based 4.7%
13.0%
web applications are much easier to spider 11.5%
4.2%
to determine what requests and parameters
2.1%
must be evaluated during the testing phase. 1.0%
1.0%
2.6%
Alternatively, single-page web applications can 5.7%
Installable (thick client) application 8.3%
be written in a myriad of ways using numerous 4.2%
5.2%
JavaScript libraries or even using company- or 6.8%
7.8%
developer-specific JavaScript. This can make 0% 2% 4% 6% 8% 10% 12% 14% 16%

Figure 5. Value of Techniques When Testing Application Types (1 of 2)

SANS Application and API Security Survey 2024 5

it more difficult for scanners to properly
Which application security testing technique provides the most value when
identify all the requests and parameters testing your application types? Select your top choice for each application type.
throughout the applications, because it
GraphQL API Single-page web application
requires them to be able to interpret and REST API Traditional form-based web application
understand all these coding formats, which, SOAP API Installable (thick client) application

we have seen, can be a struggle. If you have Native mobile application

good test coverage, you can usually train the 1.6%

1.6%
scan engine using these tests. Some vendors 0.0%
Manual code review 1.0%
1.0%
have focused heavily on updating their 2.1%
2.1%
scan engines to support newer application
0.5%
designs, but not all have kept pace. 2.1%
0.0%
Threat modeling 1.0%
We have worked with companies that have 1.6%
0.0%
successfully run scans that take hours to 1.0%

run and produce results, only to find that, 1.6%

2.6%
when we look at the details of the scan 1.6%
Bug bounty programs 0.5%
1.0%
requests being made to the application, they 0.5%
1.0%
are not even valid requests. Parameters are
0.0%
being submitted to the wrong pages or not 1.0%
2.1%
being submitted at all. With any automated Red teaming 1.6%
4.2%
testing tool, validation of the results and 3.6%
2.6%
what was scanned is important. Although it 3.1%
14.6%
is easy to get some coverage for discoverable 5.7%
Manual penetration testing 10.4%
websites and services, successfully and 8.9%
12.0%
safely using DAST technologies requires 5.7%

organizations to thoroughly configure and 3.6%

Runtime analysis/testing/ 8.3%
3.6%
update scan profiles for each application protection tool (e.g., runtime 7.3%
application self-protection [RASP], 4.7%
to ensure adequate coverage and to avoid runtime API security) 7.3%
8.3%
impacts to the application. Even though
2.1%
it is recommended to use DAST tools 4.7%
Interactive Application Security 2.1%
in non-production environments, if the 4.2%
Testing (IAST) 3.1%
4.7%
designated test environment is shared, 4.2%
impact to application availability still affects 3.1%
9.4%
the organization’s velocity. Keep in mind Dynamic Application Security 4.7%
6.8%
that back-end and other asynchronous Testing (DAST) 5.2%
13.0%
processes might be included as part of your 5.2%

application. Because these components of 3.1%

7.3%
4.7%
your application are not directly exposed or Static Application Security Testing 5.7%
(SAST) 11.5%
accessible by the front end, they are rarely 11.5%
6.8%
visible to your DAST tools. Despite some
1.0%
of these implementation considerations, 3.6%
Software Composition Analysis 1.6%
4.7%
DAST remains an important part of any (SCA) 5.2%
4.2%
testing program and is not as prone to false 7.8%
positives as some other automated tools. 0% 2% 4% 6% 8% 10% 12% 14% 16%

Figure 6. Value of Techniques When Testing Application Types (2 of 2)

SANS Application and API Security Survey 2024 6

SAST and runtime analysis are the other higher value testing methodologies according to
our survey results. The runtime analysis technologies such as runtime application self-
protection, web application firewalls, and other API security technologies provide some of
the same benefits as DAST, but do not suffer from the same difficulties because they are
not required to spider or crawl the application to understand the threats. In addition, there
is value in seeing exactly how the application is being leveraged and for the inline runtime
tools being able to take action to block the threats.

SAST, when done early, can provide deep insight into an application regardless of type
as long as the language and underlying framework being utilized are supported by the
technology being leveraged. Depending on the number of languages and frameworks being
used by the organization, there may not be a one-size-fits-all solution. Many companies
rely heavily on a specific commercial
vendor while still having to support other Which testing techniques are most easily accepted by the development
commercial or open-source scan engines teams and the business? Please order from most easily accepted to least
accepted/liked by development teams and/or the business.
to get the rest of the coverage they need.
Software Composition Analysis (SCA) 2.9
Although that does add some complexity
EASIER TO ACCEPT

on the back end for consolidating and Static Application Security Testing (SAST) 2.9
Dynamic Application Security Testing
communicating results, the survey results (DAST)
4.1

show that due to how early you can Interactive Application Security Testing
(IAST)
4.7
integrate these tools, the ease with which Runtime analysis/testing/protection
tool (e.g., runtime application self- 5.3
they are integrated, the overall expense, and protection [RASP], runtime API security)

the level of support you can expect from Manual penetration testing 5.8
HARDER TO ACCEPT

development teams or the business if these Manual code review 6.9

tools are implemented properly, this still Red teaming 7.2

qualifies as a high-value security process. Threat modeling 7.5
For example, Figure 7 illustrates which
Bug bounty programs 7.6
testing techniques are most easily accepted 0.0 2.0 4.0 6.0 8.0
by development teams and the business. Figure 7. Techniques Most
Easily Accepted by Dev and
Some might question the ease and developer support associated with SAST, and we can
Business Teams
agree that historically SAST has been a bit painful. Nevertheless, the effort required by
development teams to integrate this type of scanning is becoming more minimal each year,
which we are confident factors into these results. The complexity of SAST can primarily
be attributed to the fact that these tools can generate thousands, if not hundreds of
thousands, of findings for larger applications when they are scanned for the first time.
One way to handle this is to treat and catalog the initial scan results differently. This
allows organizations to still track and acknowledge the technical debt associated with
these initial scan findings to more quickly implement the normal processes for dealing
with new findings from subsequent scans. This will allow development teams to better
understand the true workload associated with leveraging these tools in an ongoing manner
without the taint of these massive backlogs of vulnerabilities from years of development.
We cannot fail to acknowledge the noise associated with SAST where a large percentage
of the findings may be false positives, but if testing is automated and often, the effort to
triage and identify the real vulnerabilities can be easily worked into existing backlogs and
become just another task to be completed throughout the week. There are also promising
efforts to leverage AI to help reduce some of the noise associated with these scans.

SANS Application and API Security Survey 2024 7

The other advantage of treating the initial scan results as something different is that it
forces the organization to acknowledge the debt it has accumulated instead of forcing
programs and teams to try and deal with it on their own. This can lead to additional
funding, support, or resources for teams to help deal with this other backlog of issues
or at least help the business understand why features may not be completed as quickly
as they have in the past until the backlog is resolved. One other alternative that we
see for dealing with these initial scan results is to turn the task of triaging the issues,
or identifying which are real and which are false positives, into a game or internal
bug bounty program where employees can receive rewards for the effort they put into
reducing the debt. This can become a temporary side gig for those that need some extra
money or have some extra time and is an alternative to just adding it as another task
that teams must do without any compensation. We would caution against using this
approach for anything other than the initial scan results, and be sure to make that clear
to the participants.

We expected to see SCA score a bit higher in terms of value due to its ease of
implementation and the relatively small expense and maintenance associated with
this type of scanning. Although the ease and expense were acknowledged, we think the
value is lower because relative to other testing methods this has not been as widely
adopted until recently. The number of scanning options has exploded over the last 5
years as more and more organizations are leveraging third-party and open-source code
within their applications. In addition, with the inclusion of reachability analysis in many
of the newer versions of these products, we expect the adoption and satisfaction with
this technology to grow in the coming years. Reachability analysis adds context to the
scan results by helping the user determine whether the vulnerability in the included
library is “reachable” in their application code. Reachability could be determined by the
features or methods of the library being utilized or by the configuration of the library or
components within the library. For example, if the vulnerable method is never called in
your code, the vulnerability is still there but “not reachable.” If the vulnerability is only
triggered when a certain configuration option is set to “true” and it is set to “false” in
your application, then the vulnerability is also not reachable. This will allow teams to
better prioritize these upgrades.

One other finding of note is that other forms of human-led testing outside of manual
penetration testing were not listed by nearly as many organizations as valuable. These
testing methods consistently showed up at the bottom of the list in terms of ease of
automation, early implementation, acceptance by development teams, and expense. In
addition to these methods being cumbersome and expensive, it is possible that they
are not implemented as much outside of larger enterprises due to the complexity and
expense or even due to the lack of compliance requirements focusing on these types
of testing. Therefore, don’t let the results dissuade you from implementing these types
of testing, because they definitely have a place in your testing program and can provide
valuable results if implemented intelligently.

SANS Application and API Security Survey 2024 8

Finally, it appears that over 50% of organizations are implementing
Have you implemented runtime security protection
some form of runtime protection for their applications and APIs. See for any of your applications (e.g., RASP)?
Figure 8.

These total percentages break down as follows:

15.7%
• 54% for any of their applications
Yes
• 53% for any of their APIs
54.5% No
• 53% percent for implementing just-in-time authentication and 29.8%
authorization controls for any of their applications or APIs Unknown/unsure

Although there are cost, complexity, priority, and availability

concerns with implementing these types of controls, the increased
threats organizations are dealing with are starting to overcome some
Figure 8. RASP Implementation
of these concerns.

Summary and Final Recommendations

Application and API security can sometimes feel like the final frontier for security organizations.
We put it off because either other gaps are larger and more pressing, we lack understanding
of the risk, or we appreciate and understand the added complexity. However, the truth remains
that much of our most sensitive data is protected by these applications. Although the effort is
not trivial, it is vital that organizations take steps toward dealing with these risks. Start small
and iterate until you reach a level of risk your organization can tolerate. We recommend starting
with something extremely easy and inexpensive to implement like SCA, unless you have specific
compliance requirements that force you to start somewhere else.

Starting small gets teams used to receiving findings, triaging them, and working them into the
backlog. Then, move on to something very high value like manual penetration testing. Once
these processes are in place and functioning well, start to layer on other methods like SAST,
DAST, or runtime security testing, depending on your application architecture and design. Talk
to others to help you prepare to implement these testing processes. Make sure you understand
the common pitfalls so you can avoid them or at least communicate the pain ahead of time. For
example, make sure you have resources available to consult with the developers on how to fix
specific findings and that they understand that you will need their help reviewing the findings
for false positives in addition to fixing the true positives.

Pain can sometimes be easier to accept if you were warned ahead of time. Make sure these
warnings reach not only your stakeholders, but also their stakeholders. Talk about the benefit
these tests will have for the organization in terms of not only security, but also privacy and
availability, which tend to resonate a bit more with certain stakeholders. Help them see how
these processes can help provide stability, which allows the organization to achieve its other
business objectives. There will be setbacks, and expect complaints. Don’t let it get you down.
There will always be problems to solve, but by working together with development we can find
solutions to help us achieve the best possible results.

SANS Application and API Security Survey 2024 9

Sponsor

SANS would like to thank this survey’s sponsor:

SANS Application and API Security Survey 2024 10