At QCon London 2025, Johnson Matthey’s Vulnerability Manager, Celine Pypaert, discussed managing open-source dependency risks while maintaining momentum in innovation. She described a three-part blueprint for handling the security challenges that arise with the now widespread use of open-source dependencies.
Pypaert explained that open-source components are present in 96% of commercial codebases, according to a 2024 report from Black Duck. She said how people can misplace trust in familiar software used both personally on our devices and by enterprises. She spoke about some recent security incidents, such as the XZ Utils backdoor, where a rogue contributor gained trust from the sole maintainer of the project by committing valuable code before eventually inserting malicious code, and the Left-pad incident, where a single vital component’s deletion from npm caused React-based applications to break.
There’s an implicit trust in things that people use every day – so we embed these components into our code
The main element of Pypaert’s talk was a three-part blueprint for managing open-source dependencies. Pypaert begins by identifying and prioritising vulnerabilities. She recommends organisations implement SCA (Software Composition Analysis) tools to find and audit open-source dependencies and also suggests doing this even in test environments to catch any vulnerabilities early.
Pypaert suggests a structured tactical approach to triaging and prioritising fixes to deal with the possibly overwhelming number of vulnerabilities when embarking on a project like this. “Don’t just look at the criticality – draw a Venn diagram and cross-check with what is easy to fix and what is likely to happen,” she advised. She suggests picking the top five or so issues with critical or high impact, tackling them directly with priority, and then making a phased, longer-term approach to the lower priority issues. These lower-priority issues can be harder to shift – but now is the time to influence budget-holders to commit time and resources to fixing these over the medium term.
Ownership and accountability are the second part of Pypaert’s blueprint. With open-source libraries often introduced passively, she spoke of circular conversations trying to find owners for these. She suggested. Pypaert described how developers should seek assistance from security teams to help bridge gaps. She also suggests using a risk register to get executive attention. She explained how developers can show how seemingly low-level technical risks can feed into the broader organisational risk – and leveraging the possibilities that a cyber incident could cause a business to fail to gain focus on intractable issues. This helps the organisation understand how software supply chain issues can feed into enterprise risk.
It’s funny how quickly things can happen when someone’s name appears next to a risk
Pypaert explained how building a risk profile helps an organisation to join the dots between business continuity and vulnerability management and eventually leads to reducing and eliminating technical debt. With basic policies and standards in place, training developer teams to work responsibly within them.
Make sure people understand that when they’re doing a PR or push to production that they have ticked the boxes
The final part of the blueprint focuses on moving security fixes from reactive to proactive. Pypaert strongly advocates automating security tasks wherever possible, giving an example of feeding a vulnerability detection from a tool such as GitHub’s Dependabot directly into a project management tool such as Jira. Using automation to automatically assign security tickets to the correct group of people with automatic alert routing also reduces friction and helps teams incorporate security tasks into their sprints.
Pypaert closed off her talk by assigning “homework” to the attendees – encouraging those who are only at the “crawling” stage of implementing a process such as this to get started with some basic detection, assignment and policy drafting. She suggested that attendees then start to involve other teams – perhaps by looking at compensating controls to temporarily hide vulnerabilities from the public internet with techniques such as WAFs (web application firewalls) and rate-limiting.
