3 Critical Steps for Application Security Teams in 2024

Originally published by CrowdStrike.

As application security teams head into a new year, these are the key issues they should keep in mind and steps they must take to defend their custom software applications.

Software development practices are rapidly changing, and so are the methods adversaries use to target custom applications. The rise of loosely coupled applications, along with an impressive increase in code deployment speed, has resulted in a growing attack surface with more software architecture and imported dependencies. Application security (AppSec) teams are often outnumbered by software developers and struggle to keep up with frequent code changes. All of these factors create new opportunities for adversaries, who take advantage of the side effects of fast software development to exploit custom applications.

In this blog, we examine the issues application security teams face and the steps they must take to align with their software engineer counterparts and defend custom applications in the year ahead.

Analyze Code Changes, Data Flows and APIs

Attack vectors in 2024 will likely extend beyond login forms and unsanitized data inputs. Application programming interfaces (APIs) are the primary method of transporting data in a microservices architecture. As organizations have rapidly adopted cloud services, the abundance of APIs has expanded the attack surface across the internet. Application security teams must see and understand the parameters and security posture for all APIs in their ecosystem.

When software applications transport data via API, it’s broken into multiple parameters. Using an input form as an example, common parameters may include “first_name,” “last_name” and “email.” It’s difficult to catalog and track all parameters passed via API in a microservices backend. Developers commonly document their APIs manually using OpenAPI, but any manual approach is prone to errors — especially as APIs evolve over time. Automatic API documentation, including sensitive parameter detection, is vital in 2024.

Software development practices are another concern. Many development teams create APIs for testing purposes, and sometimes these prototype APIs accidentally make their way to production and become available to the world. Without automated detection of production APIs, these unrecorded interfaces exist as “shadow APIs,” which are APIs unknown to the greater organization.

As a direct result of API sprawl, prominent breaches have stemmed from simple mistakes like missing authentication and broken authorization in APIs. Some of these errors exist at the time of initial deployment, but many are introduced in future releases. Application security teams must maintain a constant understanding of which APIs perform business-critical functionality or contain sensitive data to address this problem. As software changes over time, AppSec teams must ensure their important APIs are regularly tested and analyzed.

Maintain a Software Bill of Materials

A software bill of materials (SBOM), a regular talking point in modern software, is a complete list of the software frameworks and libraries imported into a software application. These libraries and frameworks are code projects imported by developers to “abstract away” pieces of business logic. Using pre-existing code allows developers to focus on new problems rather than reinventing something that already exists.

An important concept to understand in relation to SBOMs is the idea of “transitive dependencies.” These are software components imported indirectly as a result of another framework or library being dependent on it. When a single software package is introduced to an application, it may bring with it a massive number of other software packages. This concept of transitive inheritance can introduce a deep list of software libraries running in memory — many of which the software developer and greater organization are unaware.

The inclusion of these software packages, both known and unknown, quickly becomes dangerous when newly discovered and exploited vulnerabilities introduce risks that organizations are not aware of. Organizations must maintain an accurate SBOM to easily understand when zero-day vulnerabilities present an immediate risk to their assets. This is especially critical as organizations’ software architecture expands and imported dependencies increase, creating a larger attack surface to monitor.

Mitigate and Patch Vulnerabilities Under Attack

It’s vital for security teams to know when common vulnerabilities and exposures (CVEs) are exploited in the real world so they can evaluate their exposure and patch accordingly. Many organizations have historically prioritized vulnerability patching using the Common Vulnerability Scoring System (CVSS), which estimates the amount of damage an attacker can inflict using the vulnerability.

In 2024, the application security industry is expected to continue the trend of shifting away from reliance on raw CVSS scores in favor of alternatives that incorporate attack likelihood. For example, there is the Exploit Prediction Scoring System (EPSS) rating, which uses machine learning to predict if a particular CVE will be exploited. The U.S. government maintains a Known Exploited Vulnerability (KEV) catalog that lists vulnerabilities known to be exploited in the real world. Additionally, cybersecurity companies use data from their in-house threat intel teams to identify vulnerabilities exploited in the wild.

AppSec teams can leverage a combination of EPSS, KEV and vendor-provided threat intel information to isolate actively exploited vulnerabilities in their environment. With the large number of vulnerabilities circulating, including library vulnerabilities, it is important for AppSec teams to use the appropriate measure to prioritize which vulnerabilities require attention.

The Modern Application Security Tooling Strategy

Traditional application security tools — including static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) — are designed to hunt for individual vulnerabilities. These tools are effective at their intended purpose of discovering vulnerabilities; however, they are not built to understand software architecture and are not effective at prioritizing vulnerabilities based on business risk.

This is where application security posture management (ASPM) comes in. ASPM tools understand software architecture. By analyzing all data flows and APIs in production, ASPM tools can generate insights about each detected risk. This architectural understanding allows ASPM tools to intelligently prioritize vulnerabilities based on three criteria:

1. The impact severity of a vulnerability (e.g., CVSS rating)
2. The probability of exploit (e.g., internet-facing microservice)
3. The material business impact (e.g., personally identifiable information exposure)

Furthermore, ASPM tools determine the software packages that exist in production, allowing application security teams to see a complete SBOM for their custom developed applications.

Combining the vulnerability hunting expertise of long-standing tools like SAST, DAST and SCA with the prioritization capabilities of ASPM allows application security teams to effectively complete each step listed here to achieve a stronger application security posture. By implementing these tools and adding runtime protection to stop attacks in real time, AppSec teams can enforce their robust application security strategy in 2024.