Unpacking the State of Code Security report 2023: Open source is a top priority

The report offers tons of insightful data on application security. Drawing from a survey with over 100 cybersecurity and application development professionals, it identifies securing cloud environments as the greatest application security pain point. We also learn that organizations feel most vulnerable in the API security domain. Read on to discover more, and don’t forget to claim your bonus points at the end!

The open source pain point

At the same time, the increased focus on, and use of, Open Source Software (OSS) over the past decade is clearly reflected in the responses. Close behind the cloud security concern, we find “Frequent use of unsecured open source libraries.” This high-ranking position for open source security can be attributed to several factors.

Rising popularity of OSS

Open source software has surged in popularity in recent years thanks to its affordability, flexibility, and potential to expedite development. Basically, all software relies on some OSS, which often comprises 70%-80% of the codebase.

Lack of visibility and transparency

OSS is often introduced by developers, and an OSS library can, in turn, have several indirect (or transitive) dependencies unknown to the organization. Thus, it can be challenging to keep track of which libraries are being used in their applications. This, in turn, makes it very difficult to ensure they are up-to-date and secure.

More sophisticated cyber threats

Attacks are increasingly driven by economic incentives, and OSS vulnerabilities are frequently used in these attacks. Moreover, such vulnerabilities are relatively easy to find and exploit since the vulnerable software is used by many organizations.

Regulatory requirements

Several new and upcoming regulatory requirements make the use of OSS more complex. An example is the Biden Cybersecurity Executive Order, followed by the recent US National Cybersecurity Strategy. Both emphasize the fortification of the software supply chain, for instance, by requiring the availability of a Software Bill of Materials. A similar requirement can be found in the upcoming EU Cyber Resiliency Act.

Vulnerabilities in OSS can persist for a long time if proper tools and processes aren’t in place to address them. This, coupled with the ongoing struggle to allocate more resources to security, undoubtedly causes headaches in organizations.

Open Source Vulnerabilities

Just behind API security, “The security of open source components” is considered a major organizational vulnerability. This shouldn’t come as a surprise, considering the above discussion. What’s more surprising at first glance is that larger organizations rank this as their top vulnerability, while smaller organizations place it as number four. We can attribute this to the fact that OSS usage is tricky to keep track of and as the organization grows, this difficulty becomes more evident.

So, how should you go about securing the OSS components used in your software? Well, one way to think about it is the ‘Know-Fix-Prevent’ framework.

Know your OSS vulnerabilities

This involves two somewhat independent parts. To make this work, we need to distinguish between “your” and “vulnerabilities.” Knowing the vulnerabilities is one aspect, which includes keeping track of all published OSS vulnerabilities.

Now, this collection of vulnerabilities needs to be narrowed down to those that affect you. Being able to do so requires you to first know all your dependencies and the versions you use. Then, you need to understand all the dependencies of those dependencies, which are used transitively. This can amount to a significant number of dependencies.

Once you have both these elements – vulnerabilities and dependencies – you need to correctly match them to ensure there are no false positives and negatives in your list of vulnerabilities that affect you. Doing this manually is very time-consuming and error-prone. Reliable tooling is your best friend here.

Prevent new vulnerabilities

Every time you include a new dependency, you expose yourself to a new risk. Understanding this risk by better understanding the dependency is key here. Vetting a dependency for the probability of it harboring a future vulnerability isn’t easy. But there are several things that you can look at.

This includes how often new commits are made, the experience of the developers, how they have handled previous vulnerabilities, and how widely used this dependency is. By evaluating how well the dependency is maintained, you can reduce the risk of future vulnerabilities, and more importantly, the risk of such vulnerabilities not being handled appropriately.

Because let’s face it, as the old saying goes, “If it ain’t broken, it will be.”

Fix your vulnerabilities

This can sometimes be the most difficult part. Just because you know you have a vulnerability in a given dependency does not mean that you can just go ahead and fix it.

First, there needs to be a fix available. If a fix, i.e., a patched version, isn’t available, you either can’t fix it or you need to rewrite the code yourself, which many lack the expertise to do. You might not even want to do it as it would involve understanding the code and the actual problem and then fixing it without breaking the functionality with other code it depends on, and that depends on that code.

If there is a patched version, it may often not be a good idea to just update the dependency to that new version. Such a change might break something downstream. What if your software depends on A, and A depends on B? If you update B, you do not know if that new version is compatible with A. What you rather want to do is to update A to a version that depends on the safe version of B. Then all you need to make sure is that your software correctly uses the new version of A.

Again, a good tool will help you identify the version of A that you need to update in order to solve the vulnerability, relieving you of manual time-consuming, and error-prone work.

Mastering the open source pain points with proper tooling

It is clear that the key practices in the ‘Know-Fix-Prevent’ framework require tooling and automation. There are simply too many vulnerabilities and dependencies. Manual handling is too time-consuming but also potentially error-prone, and considering the regulations, we can’t afford to get it wrong.

Looking at the State of Code Security report, 56% of the respondents are not using an SCA tool. But out of those, more than 80% plan to adopt an SCA tool within the next year. This shows that SCA tooling is top of mind for organizations. A suitable tool needs to help handle the pain points presented by open source software.

With Debricked, you’ll have a tool that automatically matches your dependencies with vulnerabilities from a range of sources and databases. You’ll also know exactly which version to update your direct dependencies to in order to fix vulnerabilities further down in the hierarchy.

But what is more, Debricked also provides a database containing nearly 30 million open source libraries, each with accompanying data and metrics. You can evaluate and compare dependencies to make an informed decision when integrating new open source dependencies. With our Start Left Policies, you can even match the open source policies in your organization with new dependencies even before they are selected for use.

Key takeaways

The State of Code Security report considers several interesting aspects of application security. It further represents yet another testimonial of the importance of securing the open source supply chain. Open source software can offer many benefits, and it is a great asset to many organizations. It surely helps accelerate development. Nonetheless, caution is needed, and measures are needed to mitigate the security risks that come with it.

Bonus points

Want to keep the ‘Know-Fix-Prevent’ framework at your fingertips? Click here and download our infographic.