Speaker

Paul Novarese

Paul Novarese

Solutions Engineer, Hunted Labs

Memphis, Tennessee, United States

Actions

Paul Novarese is a Principal Solutions Engineer with Hunted Labs. He has been working in open source software for over 25 years, specializing in enterprise infrastructure/operations, security and containers. Recently, he has been studying the industry response to Log4Shell, particularly examining how application developers, security teams and DevOps practitioners in the trenches responded, looking for what worked and what didn’t.

Area of Expertise

  • Information & Communications Technology

Topics

  • SBOM
  • Software Supply Chain
  • InfoSec
  • DevOps
  • DevSecOps

From Log4j to xz - Unsolvable Issues in the Software Supply Chain

Securing the software supply chain became a hot topic after the Solarwinds incident in 2020, and then the Log4Shell disclosure in 2021 made the pain actually tangible to nearly everyone in software development as organizations around the world scrambled to find log4j in their environments.

The xz backdoor discovery in March of 2024 raised the stakes again. A sleeper actor, working for years inside a critical open source project has been a nightmare scenario long theorized about, suddenly made real.

We are struggling to understand why supply chain attacks are accelerating and what can be done about them. We're saddled with vulnerability management tools from the last century that aren’t up to the task. We’ve seen NVD suffer multiple failures this year as a system designed for the 20th century is crushed under the weight of 21st century realities. Proposed next-gen solutions are often single-use reactions that don’t scale and don’t help against the next attacker or are (in many cases) just completely useless security theater.

In this session, we’ll explore why these attacks are suddenly thriving. There’s a lot of bad news: more open source projects are being targeted, and some of these attacks may be unsolvable. We’ll look at xz in particular, how this scenario differed from what the experts expected a insider open source attack to look like, and what that means for defenders. We can learn from our past experience and make the recovery quicker, easier, and less painful.

A New XZ Every Day: The Rude Awakening of Open Source Supply Chains

Enterprise software has radically changed over the last 20 years, largely due to a massive increase in use of open source libraries, but our application security tools are still designed with outdated assumptions from the 1900s. Enterprise software now faces more risk from supply chain attacks than from “traditional” vulnerabilities, but the tools ignore the risk until it’s too late. There have been loud and clear red flags (Log4Shell, XZ etc) and these events garnered a few thinkpieces, but our AppSec toolbox has remained largely unchanged. These types of supply chain attacks didn’t exist back in the 20th century when the vulnerability management strategy embodied in the CVE and NVD programs and tools like Software Composition Analysis were developed, and they have not evolved to meet the threats.

These attacks are accelerating - we’re seeing compromised packages in npm, python and other ecosystems every day. Meanwhile, the CVE catalog has exploded with more advisories than ever, most of which are not actionable, adding noise and creating alert fatigue for defenders who have been told to “patch faster” and “security harder.” It’s not working. Security teams are struggling with obsolete tools from the last century that aren’t up to the task. The NVD suffered multiple failures in 2024 as a system designed for 20th century software development is crushed under the weight of 21st century realities.

In this session, we’ll explore the trends that got us here, where supply chain attacks are suddenly thriving. There’s a lot of bad news: there are other open source projects that have been infiltrated, and some of these attacks are actually unsolvable. We’ll look at XZ in particular, how this real-world scenario differed from what the experts expected a insider open source attack to look like, and what that means for defenders. We can learn from our past experience, take steps to contain the blast radius, and make the recovery quicker, easier, and less painful.

The Lessons of Log4Shell: Preparing for the Next Zero-Day

Think back to December 2021, when Log4Shell was disclosed. How long did the chaos last? What did the response cost your organization?

Attackers are evolving. Software supply chain attacks like Log4Shell are ascendant. This trend is being driven by the massive explosion in open source software combined with pure economic incentives. Modern software now sits on top of a massive iceberg of other people’s code - code that is often completely unexamined. The next zero-day incident is already lying dormant somewhere in your software.

The security practices of the 20th century can’t keep up. Traditional SCA-based response to Log4Shell required slow, expensive rescanning of all existing deployed software just to discover if and where log4j even existed in production environments. No remediation effort could even start without this lengthy process. A new approach is needed, and the Software Bill of Materials is the key to this next generation of software inspection.

The havoc that will ensue from the next Log4Shell-like zero-day event can be considerably reduced with proactive measures that can non-disruptively be included into existing software development workflows. The emergence of the SBOM is giving software producers deep visibility into their software and is allowing them to evaluate that software much more rapidly than before. Having complete visibility into your software means better decisions - driving down both the duration of incidents and the frequency of incidents.

In this presentation, we will learn about SBOMs, explore how they’re generated and see how to get the most out of them. Attendees will learn about the usefulness of SBOMs both for responding to zero-day situations like Log4Shell and for more run-of-the-mill vulnerability scanning (increasing both speed and accuracy). We will tie it all together with strategies to automate creation and evaluation in software pipelines, increasing overall software supply chain security (detecting problems sooner and fixing problems faster with fewer production disruptions).

Bsides Seattle 2025 Sessionize Event Upcoming

April 2025 Redmond, Washington, United States

BSidesSLC 2025 Sessionize Event Upcoming

April 2025 Sandy, Utah, United States

BSidesRedRocks 2024 Sessionize Event

November 2024 Cedar City, Utah, United States

Chattanooga Devopsdays 2023 Sessionize Event

November 2023 Chattanooga, Tennessee, United States

BSides RDU 2023 Sessionize Event

September 2023 Raleigh, North Carolina, United States

DevOpsDays DC 2023 Sessionize Event

September 2023 Washington, Washington, D.C., United States

Paul Novarese

Solutions Engineer, Hunted Labs

Memphis, Tennessee, United States

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top