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.
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
SCA: Software Composition Analysis
SOUP: Software of unknown provenance
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.
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.”
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.
Consider the following measures to modernize your software development processes.
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.
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.
While relatively new additions to the cybersecurity toolbox, static analysis tools can be the fulcrum for more robust coding practices.
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.”