Skip Navigation
Resources Blog Going online with the OWASP Vulnerability Management Guide ...

Going online with the OWASP Vulnerability Management Guide Working Group


Software vulnerabilities influence your level of cybersecurity risk.

In order to manage that risk, you identify, assess, and mitigate vulnerabilities in your software systems that could be exploited by bad actors to gain unauthorized access, steal sensitive information, or disrupt operations.

The OWASP Vulnerability Management Guide (OVMG) project seeks to simplify vulnerability management into repeatable and scalable cycles. The project democratizes the process of establishing industry best practices and guidelines to help any organization set up a vulnerability management program best suited to meet their needs.

The OVMG working group officially launched last week with its first online meeting as part of the OWASP Foundation Women in Application Security (WIA), Diversity and Inclusion Meetup.

The meeting began with a rundown of CVEs that dominated the headlines in 2022, such as:

  • CVE-2021-44228, Log4Shell
  • CVE-2022-30190, Follina
  • CVE-2022-3786 and CVE-2022-3602, OpenSSL

Then Theresa Mammarella, developer advocate at Sonatype, made a case to reframe vulnerability management as dependency management to control cybersecurity risk with her presentation titled Untangling the Web of Software Dependencies.

“The main area of focus I typically talk about and look at is the risk that is associated with software dependencies and managing those dependencies appropriately,” said Mammarella.

The use of dependencies is widespread since it saves developers time as they don’t have to reinvent the wheel in solving problems. But when you solve one problem in software — especially when you depend on other people’s solutions to do so — you typically end up creating new and possibly more difficult problems that need to be solved to support the solution you built.

“Java projects, on average, have about 150 dependencies per project. We typically see, at least in Maven Central, on average those dependencies each have 10 releases a year. That’s quite a lot of updates to consider,” said Mammarella. “That introduces the problem of dependency management. How do you handle all of these things?”

Given modern automation methods, can you fully understand what's in your build? How about the vulnerabilities associated with every dependency? According to Mammarella, this amounts to security risk. She frames it in terms of a supply chain.


“All those dependencies are supplies that get pulled into a manufacturing system and put out into a software application. When we talk about the risk that’s on those, we can talk about that in a few different ways, said Mammarella. “There’s upstream risk — open source packages that are coming from Maven Central, npm, PyPI. The midstream area — attacks that can happen in build tools. And of course downstream, which are direct attacks on an application.”


What Mammarella points to here is how upstream attacks trickle down into the other areas of the SDLC. Dependencies reside upstream in public open source software repositories. Bad actors focus their attention there in order to carry out their supply chain attacks. As uncovered in the 8th annual State of the Software Supply Chain report, there’s been a huge amount of growth in this type of attack since there’s so much opportunity to take advantage of unsuspecting developers downstream.

These new types of supply chain attacks exist in forms such as:

  • Dependency confusion — an attempt to get a different version into a binary repository, often “latest.”
  • Typosquatting — a lookalike domain or dependency with single or a couple different characters.
  • Open source repo attack — an attempt to get malware or vulnerabilities added into dependency source via social or tools.
  • Build tool attack — an attempt to get malware into tools used to produce dependencies.

Mammarella went on to frame Log4Shell as an example of a dependency management risk. For those still unfamiliar Log4Shell is the vulnerability in Log4j, the go-to logging framework for Java developers.

According to Mammarella, a huge amount of Log4j dependencies are still vulnerable. She spoke about research in the State of the Software Supply Chain report regarding download statistics of different versions of Log4j.

“There was a pretty big jump in using safer versions once they were available. But then it kind of levels out there, and throughout the rest of the year that tended to stay the trend,” she said. “A big part of that is because it is really difficult to actually find the dependencies in that web of dependencies.”


Data shows that zero-day vulnerabilities continue to increase. This increases the importance of  dependency management and who will be responsible for it. But while it may seem that this puts more responsibility on open source projects, Mammarella caveats this notion.

“That of course is true to an extent that the libraries that are being consumed do have a responsibility to use secure practices,” she said. “However, in practice, another study we did actually showed that open source libraries are actually doing okay. About 96% of projects that have vulnerable releases do have a fix for them. On the other hand, 62% of consumers are downloading vulnerable projects.”


According to Mammarella, while there is work to be done on both sides in terms of security, there is a really big gap here as the consumer is not consuming dependencies intelligently.

She feels the path to better choices and more managed responses begins with automation.

“With the massive scale of dependencies that are being consumed, it’s not really possible to be able to do this really properly.”

She described a few different schools of thought for updating dependencies, which depend on business factors:

  • Living in disarray
  • Living close to the edge
  • Living on the edge


If you strike the right balance in the middle ground of “Living Close to the Edge,” Mammarella says you will upgrade intelligently and understand what dependencies are there and how to make the safest choices. This also serves as an optimal strategy to protect against future vulnerabilities.

“In the news these days, everyone is saying ‘oh this is the next Log4Shell’ and ‘this is the next Log4Shell.’ Whether you think one is just as bad or not, there is going to be more coming around the corner,” she said. “Having plans like this in place, to be able to remediate better when it comes to those pesky dependencies is going to be more and more important in the security landscape.”

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.