Where cloud-native AppSec mistakes are made: Known vs. unknown vulnerabilities

Application Security leaders often make a foundational mistake when building their AppSec programs: they think from an inside-out perspective. This leads to stale, traditional approaches that often start with legacy vulnerability scanning tools that produce excessive noise, have too many false positives, and lead to your AppSec Engineers focusing on the wrong things and spending their valuable time on unimportant or redundant issues.

Any successful cybersecurity program needs to start from an attacker’s perspective. Put another way: you need to start where attackers are going to start! While this may seem intuitively obvious, it is hard to do. When you’re focused on defense, you have a greater understanding of the scope of your security risks and all of the things that could possibly go wrong, no matter how unlikely. It’s only natural to want to focus on remediating “vulnerabilities with high CVE scores that could lead to application compromise, second-guessing, and internal finger-pointing. The mistake with this line of thinking is that it is not aligned with the true risk to the business.

“Known” vs. “unknown” security weaknesses

What’s often overlooked as an essential concept is the difference between “known” and “unknown” security weaknesses.

Known security issues are simple. They include:

• A completely exposed S3 bucket
• An API that is missing authentication or authorization controls
• The use of open source software with published, high-severity CVEs

It is easy for attackers to identify and exploit these known vulnerabilities – and do so with minimal effort. Little skill is required to take advantage of known vulnerabilities and exploit code is readily available.

Unknown vulnerabilities are much more complex. Consider what it takes for an attacker to discover and exploit a zero-day vulnerability in custom code. Even with tools like Metasploit, taking advantage of a brand-new buffer overflow is non-trivial! It requires an order of magnitude more skill and security knowledge than the vast majority of would-be attackers. For this reason, attackers will always gravitate toward known weaknesses and vulnerabilities.

Modern cloud-native application composition

A cloud-native app as a “system” consists of open source libraries, multiple layers of dependencies, Infra as Code, scripts, cloud configurations, API gateway settings, and more. The custom code you write yourself is only a small portion of the application. The greatest surface area for mistakes is in the rest of the app! When AppSec leaders focus on statically analyzing their custom code as the centerpiece of their programs, they’re making a common – but critical – mistake! Legacy SAST tools drown AppSec professionals in false positives and incorrectly-prioritized alerts.

What this means for application security programs

When you think from an attacker’s perspective, you realize that too many Application Security programs are focused on the wrong things. They’re so worried about the complex “unknown” risks that they don’t spend the time required to address the simpler “known” risks.

Addressing these issues requires a risk-based approach to building an application security program. You can do this in six simple steps:

1. Define success. The first step in creating any type of program is to define success. In application security, too often key metrics include items such as # of open vulnerabilities, # of vulnerabilities remediated in the past 30 days, and mean time-to-resolution. But these are vanity metrics! Remediating the wrong vulnerability quickly is not a measure of success. These types of metrics allow people to have the illusion of showing progress or security but do not tie to any measurement your executives or Board of Directors care about.
2. Gain risk-based visibility. True application risk visibility requires clarity from end-to-end; from design to code to cloud. Data from all stages can help make better decisions early in the development process, improving security and reducing unnecessary rework.
3. Remediate the risks that matter. Relying on vulnerability scanning tools is fundamentally misguided because they lead to significant noise and false positives. Scan “findings” are assigned to people for remediation without any regard to the context that affects the real-world risk of the finding. Instead of viewing risk in terms of vulnerabilities, focus on the actual risks to your business. This requires an extensive understanding of context.
4. Automate code governance. Define and deploy workflows that automatically trigger the appropriate SDLC processes with the context needed to optimize each task. Automating your code governance will save time and ensure consistency, making it a win/win for security and development teams.
5. Approach the SDLC holistically. Looking at the SSDLC across processes and tools from a single pane of glass is required to make better, more contextual decisions.
6. Shift left and extend Right. Surfacing AppSec feedback earlier and embedding guardrails into developer workflows is the best practice for effectively scaling AppSec across development teams, but without context from runtime environments, feedback can be noisy.

Learn more about how Apiiro can help you build and scale a risk-based application security program here!