ESG Survey Report Finds AI, Secrets, and Misconfigurations Plague AppSec Teams

Find out how your peers are managing application security challenges. 

Application development is changing and evolving rapidly, and attacker tactics are evolving along with it. Application security needs to adapt as well, but is struggling to keep up, both with the pace and change of development, and with the attackers.

A just-published survey report from TechTarget's Enterprise Strategy Group (ESG), Modernizing Application Security to Scale for Cloud-Native Development, based on a survey of 350 IT and cybersecurity professionals and application developers, explores this challenge and the strategies, tools, and investments security and development teams are leveraging in their quest to address it.

We share a few notable findings below.

Evolution of application development causing security headaches 

When asked about the top challenges for AppSec teams supporting cloud-native dev processes, respondents cited the following as the most vexing:

• Understanding and managing risk related to use of GenAI (45%)
• Measuring and improving AppSec program effectiveness (42%)
• Understanding developer environments and assets to effectively manage security (41%)

These challenges align with what we hear in conversations with security teams across industries.

Generative AI in particular comes up a lot these days. Although it gives developers an easier way to produce code at scale, it also causes problems for security teams trying to figure out where and how it’s being used.

In addition, it:

• Creates a lower barrier of entry, allowing non-technical users to leverage tools such as GitHub Copilot to produce code.
• Generates code with vulnerabilities, just like code created by developers.
• Could include code licensed by another organization. This puts an enterprise at legal risk of stealing intellectual property.
• Often leverages old recursive patterns that developers have stopped using, but that are still on the Internet.

Secrets and misconfigurations top the cybersecurity incidents list 

When asked which cybersecurity incidents respondents had experienced in the last 12 months related specifically to internally developed cloud-native applications, the top two answers were:

• Secrets stolen from a source code repository (32%)
• Exploit of a misconfigured cloud service (31%)

These stats line up with what we see in our interactions with customers and prospects here at Legit. We frequently uncover exposed secrets and misconfigured build assets.

Why do these two issues emerge so often now?

Misconfigurations

With the software development factory becoming more complex and automated, there are increasing opportunities for misconfigurations to create risk. For example, misconfigured build servers is a common problem that creates significant vulnerabilities. Build systems are essentially automated, implicitly trusted pathways straight to the cloud, yet most aren’t treated as critical from a security perspective. In many cases, these systems — like Jenkins, for example — are misconfigured or otherwise vulnerable and unpatched.

Oftentimes, development tools are over- privileged because they’re easier to integrate if users have full access. In some instances, organizations spin up an open-source development server and then allow admin access to everything. They’re not worried about misconfigurations; they’re focused on application vulnerabilities.

In fact, this type of misconfiguration was the source of the SolarWinds and the Codecov attacks.

Avoid these types of miconfigurations by enabling branch protection and enforcing code reviews (where the reviewer is not the committer).​ ​ 

In addition, make sure server-level defaults are set according to secure best practices​. 

Secrets

Modern apps also require hundreds of secrets to function (API keys, third parties, cloud credentials, etc.). At the same time, developers are pushed to innovate and develop code as fast as possible, frequently leading to shortcuts intended to drive efficiency and speed. One of those shortcuts is using secrets in development to accelerate testing and QA.

The problem is that it’s very easy for these secrets to remain exposed. For example, a developer may test a piece of code with a key. When it works, they move it into production without removing that key. They either forget, or the key works and they don’t want to adjust it. This practice and others like it lead to a continuously growing and significant source of risk to the organization.

Legit Security has found an average of 12 secrets submitted per 100 repositories every week. And according to IBM’s 2023 Data Breach Report, secret leak risks are the second most common initial attack vector.

Avoid secrets exposure by focusing first on SaaS services keys (e.g., AWS access keys), since if code is leaked, credentials to SaaS services are immediately usable if they are valid, whereas internal credentials require attackers to also have network connectivity.​ 

In addition, use least-privilege practices to limit access to source code, continually scan for secrets, and rotate and remove secrets that are found. 

Get full survey results 

Get more details on the application security challenges your peers are facing and how they are addressing them in the ESG Survey report: Modernizing Application Security to Scale for Cloud-Native Development.