Asset-first application security: What is it and how can it help

Most application security strategies focus on lowering vulnerability count: identifying security issues throughout the software development lifecycle (SDLC) and fixing them. But within a complex software environment, it’s hard to decipher if each of these vulnerabilities is actually a risk to the organization or if it’s simply a redundant or false alert. For example, a cloud misconfiguration in a sandbox might not matter to a business in the long run because it’s unrelated to mission-critical applications and separated by other layers of security. Each security issue requires context to understand the risk it poses to the organization. This has led to new approaches to security, as well as new tools to enable that approach, in the form of ASPM.

An asset-first approach views security through a business lens, securing all assets based on their intended purposes. In this article, we’ll cover the basics of asset-first application security, including:

• The definition of an “asset”

• How asset-first application security works

• Why asset-first AppSec matters

• How to conduct an application security gap analysis

• Snyk’s approach to asset-first AppSec

What is an asset?

An “asset” is any component, entity, or activity inside the application security environment that requires security controls. In a typical software supply chain, teams deal with the following types of assets:

• source code

• dependencies

• container images

• services

• endpoints

• hosts

• development teams

What is asset-first application security?

An asset-first approach means filtering all application security activities through a business lens. This contextual information lets teams filter through security data and secure what matters most. Asset-first application security also makes typical security activities, such as secrets management, vulnerability scanning, and DevSecOps, much more targeted to the company’s needs and priorities.   

An asset-first application security approach involves three steps: mapping assets to understand what’s within the AppSec team’s purview, looking at issues through the map's context, and prioritizing security controls based on this deep, contextual information.

Why does asset-first application security matter?

Many of today’s teams get overwhelmed and confused by the sheer volume of vulnerabilities within their environments. An asset-first approach simplifies AppSec by meaningfully quantifying risks rather than chasing down vulnerabilities solely based on severity levels. This approach to securing the software supply chain provides benefits for the following teams:

Executives

Asset-first AppSec provides executives with relevant, contextual data for decision-making and risk calculations. For instance, a report that an environment has “200 critical vulnerabilities” is not actionable for the leadership team. Instead, an asset-first approach focuses on big-picture priorities, reporting information like, “Our top asset is vulnerable to five different risks.”  These specifics enable the executives to target initiatives that will make a genuine difference instead of reacting to an indefinitely long list of security issues.

Application security teams

AppSec teams can’t protect what they don’t know about, and they are consistently outnumbered by developers. By prioritizing asset discovery and inventory management, an asset-first approach empowers AppSec teams to identify gaps in visibility and tool coverage. It also allows the teams to find business-critical assets and assign automatic prioritization to them, helping them to save time, and focus on the issues that really matter to their business. 

Developers 

Nowadays, developers are responsible for several areas of the software supply chain, including cloud infrastructure, containers, third-party resources, and first-party code. Because they hold so much responsibility, they need support for fixing various security issues across the SDLC. 

Without an asset-first approach, these responsibilities become very overwhelming to developers. They can’t tell where a security issue resides; it could be inside a mission-critical app that they must secure as soon as possible or an internal-facing app that doesn’t contribute to the attack surface. In addition, developers don’t know if their security controls are flagging the same vulnerability from two different angles (e.g., in the cloud and the IaC), and they don’t know where to go to fix the root cause. This non-contextual approach leads to alert fatigue and frustration.

An asset-first approach makes this level of responsibility much less overwhelming by empowering developers to tackle security issues in context. As a result, it takes a fraction of the time to identify who owns the asset in question and make quick, targeted fixes. This asset-first mindset also enables AppSec and developers to speak in a unified language about security.

Application security gap analysis

A gap analysis helps teams understand which assets they’re already securing and where they need to add additional security controls. It enables them to allocate resources to the projects that matter most and not waste time on redundant or irrelevant activities. An application security gap analysis can involve the following tasks:

Inventorying assets

Your teams must understand what they own and classify these assets in context. Automation is often the best option for keeping tabs on all existing assets.

Understanding existing controls

What is your team already doing to secure assets? To answer this question, your teams must analyze all existing security controls, including activities such as code reviews and penetration tests, tools such as static application security testing (SAST) and software composition analysis (SCA) solutions, and initiatives like security champion programs and secure code training.

Measuring success

After creating an exhaustive list of existing security controls, teams should test each according to its function and purpose. For example, you could measure a vulnerability scanner's success rate by calculating the percentage of critical vulnerabilities resolved within essential apps. And you could measure the success of a security champion program by analyzing its adoption rate.

Snyk ASPM’s asset-based model

Our approach to ASPM empowers developers to work fast and stay secure. Because today’s apps are so complex, securing applications without slowing down development pipelines requires meaningful prioritization. Asset-based application security enables security control triaging based on business context and potential risk in the real world versus the count or severity of vulnerabilities alone. It also makes it easier for security teams to build out automated guardrails and workflows. 

To gain this level of context, Snyk approaches ASPM in three stages:

• Discovering and classifying assets, using policies to classify each asset based on business criticality.

• Implementing security controls based on each asset’s classification.

• Prioritizing issues related to assets that pose more risk to the organization.

To learn more about implementing an application security strategy with Snyk, check out our Complete guide to AppSec.