Webinar: Why Cloud-Native Applications and APIs Are at Risk

SCA is your front door lock, ASPM is a home security system

It is probably not a surprise to say the use of open source packages in application development is here to stay. Depending on what research report you have read, as there are so many, the percentage of the code in an application being open source is anywhere from 30% to 80% of the total application code. The use of open-source code is not a surprising statistic. As the speed of CI/CD pipelines increases, developers are looking for ways to write code quicker and not have to reinvent the wheel every time they need a basic type of functionality in their applications.

Due to the explosive growth in recent years of open source packages, development and security teams are doubling down on the usage of Software Composition Analysis (SCA). This doubling down ensures that the open-source packages in their applications are secure, up to date, and licensed correctly. The recent huge venture capital investments and valuations of SCA vendors prove that this technology is a valid one. To prove my point, Snyk raised $530 million and is valued at $8.5B.

So, all I need is SCA to secure my applications?

I think that SCA solutions are great at what they intend to do: ensure open source packages are secure and used correctly. But what about all the other services that make up an application architecture? I am talking above and beyond the web application and all the application services. Services like databases, message brokers, 3rd party applications, APIs, how they all communicate, and what data they process are critical to understanding. If you use an SCA solution, your open-source packages will be secure and compliant, but that doesn’t mean your application architecture is secure.

What SCA is good at

SBOM or Inventory of open source packages in use

SCA solutions are an automated and effective way to identify all the open-source packages in your application or repo. Most solutions even go into direct and transitive dependencies to identify open source packages you may not even know you are using.

Licensing Issues

The primary purpose of open source packages is to provide their functionality to everyone to save time and resources. There are, however, licensing requirements if you include specific open source packages in your commercial applications. SCA solutions alert you when there are issues with usage and licensing.

Identify Security Vulnerabilities in Open-Source Packages

One of the primary use cases for an SCA solution is identifying known vulnerabilities in an open-source package. Some even tell you if that vulnerable code can be called by other code in the application.

Open Source Policy Enforcement

SCA Solutions allow for open source usage policies to be created and managed. Policies in SCA are used for many things associated with open source packages. Issues such as approval processes for open source package usage or if they are part of an already approved list of packages.

Auto-updating of packages

Some SCA vendors even provide the ability to auto-update an open-source package if a newer or more secure version is available.

Gaps in SCA Solutions that ASPM Solves

A complete application SBOM

While SCA provides an SBOM of all the open-source packages, it does not offer a complete SBOM of the entire application architecture as ASPM does. ASPM SBOMs include all the open-source packages, APIs, Libraries, Data Sources, Data Types, and services. It is better to have one SBOM source of truth rather than multiple SBOMs that need continuous updating and comparison.

Real World Example: 

An ISV was getting inundated with requests to complete security questionnaires and provide product SBOMs from potential customers interested in purchasing their SAAS product. New releases and bug fixes of this SAAS product happened multiple times a week. The customer had to collect SBOM (including a SCA Solution’s SBOM) and CMDB information from multiple sources of record and combine them manually to answer these requests which was time consuming and resource intensive. Even after this effort was complete they were still not 100% positive the information was accurate. By using the dBOM provided by Bionic’s ASPM Platform they were able to provide this information in minutes instead of days.

Identify Security Violations for the entire application architecture

Having a solution that looks at one aspect of risk in your application is not a complete picture. Threats and vulnerabilities are typically multi-level and can include open source packages, homegrown code, permissions issues, and sensitive data access issues. If you are looking at the open-source packages, you are only removing one variable of the multi-level vulnerability.

Real World Example:

An organization had a non data processing web application that had a critical CVE related to an open source package. It was determined that since the web application did not process any sensitive data it was low risk and remediation of the CVE could be a low priority and not immediately addressed. A developer made a change and added credit card processing functionality to the web application with the critical CVE which the security team did not know about so they continued to ignore the issue even though it was now processing sensitive PCI information. Bionic’s ASPM platform identified the web application functionality drift and immediately alerted the organization of this major risk. The SCA solution only reported on the CVE risk and not the architectural change of the web application as it related to processing PCI information.

Complete Application Policy Enforcement

Having policies that consider all aspects of risk in your application architecture is a better approach than just focusing on one technology type, such as open-source packages. Issues like misconfigured secrets management, PII data accessed by an application service with a critical CVE that also touches a 3rd party application, or identifying problems that are unique to only your application architecture.

Real World Example:

An organization was concerned about application service drift outside of the approved application architecture. The specific goal of this initiative was to understand how application services accessed and used PII data. If an unapproved application service accessed PII data in any way they wanted to be alerted to it immediately. They were able to quickly adjust existing Bionic ASPM platform queries in minutes to provide specific details about their application architecture to ensure this policy was enforced correctly. This policy needed change events, upstream and downstream data flow data, and database schema information to work correctly. Bionic’s ASPM platform was able to correlate all this information into one simple query.

Prioritization of Risk with Complete Application Architectural Context

Finding issues associated with risk is just the first step in mitigating said risk. How would you know what risk to fix first without complete application architecture understanding? Without ASPM, you would not see the context of risk associated with things like sensitive data, 3rd Party Communication, or misconfigured communication.

Real World Example:

An organization had a war room active for 3 days to identify every instance of the Log4Shell zero day vulnerability. They had a SCA solution so they knew that they had vulnerable packages but struggled with prioritization of what to fix first and what the risk impact of the fix would be. With Bionic’s ASPM platform they were able to identify and prioritize the most dangerous instances of Log4Shell in minutes in addition to understanding how the vulnerable packages communicated with other application services. Their SCA solution could not provide this level of detail.

Why Should I Care?

To ensure your applications are secure, you need to understand how they are architected, what data they process, and all application services and associated data flows. Just focusing on one aspect of your application architecture, such as open-source packages, is not a complete risk picture. SCA is like a lock on the front door of your home as it addresses one source of risk. ASPM looks at all the aspects of risk, just like a complete home security system: every door, every window, and monitors all these points of risk continuously.

Check our latest Bionic Uncensored where we talk about why SCA is BETTER with ASPM:

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

See a Live Demo of the Bionic Platform