Post-Conference Tech Spec: Why Building Your Ship (Application) with Raw Materials is a Bad Idea (2023)

At Sonatype, a great presentation never dies. Nor does it simply fade away. While you might watch a presentation given by one of our team members onsite or online for a tech conference or community event, you can also catch a recap on our blog. This is one such case.

Jamie Coleman, Developer Advocate on Sonatype’s Developer Relations team, delivered this presentation at Voxxed Days Zurich in March 2023, and we’ve distilled his words and slides into a tech spec below.

Introduction

Our ship captain for this tech spec is Jamie Coleman, Developer Advocate on Sonatype’s Developer Relations team. Previously, Jamie worked aboard IBM as a developer in mainframe software (CICS),WebSphere, and OpenJ9.

Description

Imagine you're a ship captain navigating dangerous waters, relying on the quality of the materials that make up your vessel to keep you afloat. In the same way, your organization depends upon the quality and availability of open source components (or “raw materials”) to build applications and maintain velocity in software development.

In the vast and unpredictable sea of open source software (OSS), supply chain incidents like Log4Shell create a storm of uncertainty. Just as a captain sailing in the midst of a tempest would take stock of every element of their ship, from the sails to the rigging, an organization and its crew of developers can reexamine aspects of their development lifecycle.

With recent executive acts requiring a software bill of materials (SBOM), the pressure is on to certify that open source components are not full of vulnerabilities and actually follow secure programming practices. So, what if you can't verify the sources or dependencies of OSS components? Can you simply label them as “raw materials” to bypass security testing?

Increased scrutiny has become a lighthouse for governments, foundations, and industry voices looking for a better and safer path forward. A good first step on any voyage with OSS: Greater transparency and shared responsibility across development sourcing methodologies.

Problem Statement

Open source software greatly powers commercial applications far and wide. With great power comes great responsibility, according to recent cybersecurity announcements and acts by the US, EU, and UK governments.

These measures put the onus on organizations to better manage the security of the software they produce rather than pass liability to their end-users or the open source components integrated into their products. And while you try to steer through an ocean of third-party components, the constantly changing tides of threat actors besiege you.

Given recent legislative actions that essentially make organizations entirely responsible for the security of their applications, what can you do to more safely navigate the increasingly choppy waters of vulnerabilities in open source components?

Terminology

Raw materials: third-party (open source) components an organization pulls into its development lifecycle

• In the context of this tech spec, organizations sometimes leverage the “raw materials” label as an umbrella term for all third-party components (from unknown suppliers) they utilize thereby outsourcing all accountability for subsequently found vulnerabilities or exploits and resultant issues to parties outside of the organization.

SCA: Software Composition Analysis

• Sonatype defines SCA as the ongoing, precise, and in-depth review of the open source components, dependencies, and license requirements embedded in a particular piece of software or across a software supply chain.

SOUP: Software of unknown provenance

• In this context, SOUP refers to software whose source or origin cannot be verified and presents a security risk due to the potential for containing malicious code or vulnerabilities that can be exploited by attackers. Jamie states this term is sometimes used synonymously with “raw materials” as described above.

Assumptions

This tech spec assumes prior knowledge of the following aspects and concepts:

The software supply chain (SSC)

A timeline of software supply chain attacks.

Differences in SCA tools

Basic practices for higher quality, more secure code.

Context

What are the circumstances, as described by Jamie

On how the industry leverages open source code:
“Nearly 90% of the code in all applications is open source code. So, we’re actually only writing about 10% of our applications these days. That’s great, because we’re saving 90% of the time that we didn’t have to write this code, and we’re just borrowing it from each other.”

On the genesis of this presentation:
“I was at a developer conference. We sat down at a roundtable with some very, very big corporations. I won’t name who they are, but they were talking essentially about how they can get around policy and dependency management. I was completely befuddled that people were trying to get around their policies just so they can get open source code into their applications.”

On direct versus transitive dependencies:
“You have dependencies that require other dependencies. You have your main dependency that you incorporate, but that dependency might require another three dependencies, and those dependencies might require another five. So, it gets very complicated very quickly.”

On dependency management in open source:
“The average Java project has about 150 dependencies, and those dependencies have about 10 releases per year. That’s 1,500 updates to consider per year in a basic Java project. So, that can get a bit confusing.”

Why security in open source matters

Cybercriminals know about the increasingly unmanageable complexity created by dependencies in open source, and they exploit this with more sophisticated automated and social engineering methodologies.

In 2016, cybercrime surpassed the drug trade in terms of its monetary costs. The big business of modern cybercrime has increased exponentially year over year since then, and by some estimates would be the world’s third-largest economy.

The window of time from the disclosure of a zero-day vulnerability to its zero-day exploit now nearly mirrors the namesake for both. In the case of Log4Shell, malicious traffic reportedly began almost immediately.

With a slim margin for error, the difference between a vulnerability and no vulnerability can come down to a single symbol in a line of code.

Goals

Consider the following measures to modernize your software development processes.

Start (but don’t stop) with an SBOM

According to Jamie, “It’s great to have a software bill of materials, but the important part is what you do with it.”

Once you generate one, act on the data it provides. Know that SBOMs are not the solution – they are just a small part of the solution. And even SBOMs are not safe from hacking.

Manage your dependencies better

There is a flood of open source vulnerabilities to be managed, and hiding behind your firewall will not keep your organization safe. In the wake of some high-profile exploits, downloads of the vulnerable component can persist years after the fact. Systematize your dependency selection and management.

Use static analysis tools

While relatively new additions to the cybersecurity toolbox, static analysis tools can be the fulcrum for more robust coding practices.

A code analysis platform such as Lift scans your application (and the open source components therein) and:

• automatically analyzes each pull request
• provides feedback with comments directly in the code review
• reports critical security, performance, and reliability bugs within the developer workflow

Out of your Lift analysis, you can export a CycloneDX SBOM and pull it into BOM Doctor to generate a visualization of the dependencies of a given application.

While the visualization might turn out to be a bit painful (or possibly feel like a trip to dependency hell) as a spider web of dependencies, you can also find a better route forward by analyzing vulnerability scores and discovering update paths for certain components.

Know that one day your luck will run out

One day, your organization will be hacked—that is, if you continue to remain reactive rather than proactive in terms of your secure development practices.

And in consideration of recent legislative actions regarding cybersecurity, Jamie asserts: “There’s no point waiting for these laws to be enforced. You might as well get started now and start making changes to your applications because you will be forced to, and if you don’t do it, you just won’t be able to sell your applications in the future.”

Tags: secure software supply chain, Open Source, devsecops, DevZone