Resources Blog Post-conference tech spec: Why building your ship ...

Post-conference tech spec: Why building your ship (application) with raw materials is a bad idea


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.



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.


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?


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.


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

The software supply chain (SSC)

An image detailing each part of the software supply chain. It has bubbles for suppliers (third party software, such as open source), warehouses (component repositories), manufacturers (software development teams), and finished goods (software applications).

A timeline of software supply chain attacks.


Differences in SCA tools

An image comparing how different SCA tools are similar to all of the ingredients that eventually make a cake.
Basic practices for higher quality, more secure code.

This image lists easy ways to improve security. They include: code review, binaries outside of projects, dependencies pinned to a specific version, and secure branches.


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.

An image depicting different kinds of dependency exploitation. They are separated into "Automated", which features dependency confusion and typo-squatting, and "social engineering", which features open source repo attacks and build tool attacks.

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.

This image compares cybercrime to world economies. It features: United States ($20.89 trillion), China ($14.72 trillion), Cyber Crime ($6 trillion), Japan ($5.06 trillion), Germany ($3.85 trillion), India ($2.65 trillion), United Kingdom ($2.63 trillion), and France ($2.58 trillion).

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.

A graph showing how quickly the Year of Date Reported and Average Days from Public Disclosure to Exploit are closing.

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.

An image demonstrating how one line of code can have a big impact.


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.

An image showing how to choose dependencies wisely. Steps include: Knowing what's in your application, assessing existing dependencies, continuous upgrade strategies, ongoing security scanning, having a remediation strategy.

Use static analysis tools

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

An image that answers the question: what is a static analysis tool? Answers include: SA tools examine your applications source code for enforced coding standards, insecure code patterns, measuring test coverage, control flow, nesting and data flow, documentation and requirements docs.

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.

An image urging organizations to be proactive with a quote from Sonatype CTO Brian Fox that reads: "If no other manufacturing industry is permitted to ship known vulnerable or defective parts in their products, why should software manufacturers be any different?"

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.”

Picture of Aaron Linskens

Written by Aaron Linskens

Aaron is a technical writer on Sonatype's Marketing team. He works at a crossroads of technical writing, developer advocacy, software development, and open source. He aims to get developers and non-technical collaborators to work well together via experimentation, feedback, and iteration so they can build the right software.