Picture this:

‍

You just rolled out a shiny new software composition analysis (SCA) tool after months of effort. It churns out its first report, and the results are worse than you imagined: 5,000 critical vulnerabilities across your repositories. You present this data, expecting urgency, but instead, you’re met with apathy, excuses, or worse—disbelief.

‍

Here’s the hard truth: the lack of urgency? That’s on how the data was presented. Security engineers often use a “shock and awe” approach, dumping all the vulnerabilities at once, hoping the sheer volume will drive action. Spoiler alert: it doesn’t.

‍

I’ve been on the receiving end of a 5,000-critical-vulnerability report before. It felt like a kick in the shin. When people feel attacked, their amygdala lights up. When that happens, one of four responses typically follows:

‍

Fight - “No way my code is that bad! This report must be wrong.”

Flight - “We are working on a higher priority from <CEO>.”

Freeze - “I don’t even know where to start. Let’s push this to our next planning cycle.”

Fawn - “We’ll form a working group to evaluate this.” (Translation: Nothing will happen.)

‍

The good news is that there is a better way. You can transform your approach and motivate developers to take real ownership of these vulnerabilities.

‍

If it Ain’t Broke…

‍

The first challenge with massive vulnerability reports is credibility. Developers think:

‍

“If these 5,000 critical vulnerabilities haven’t caused major breaches yet, how critical can they really be?”

‍

They’re not wrong. Vulnerable libraries often sit unnoticed for years without immediate consequences. Plus, fixing outdated libraries introduces risk: updates can break things and cause downtime.

‍

Here are three more reasons developers may not prioritize addressing these vulnerabilities:

‍

• Lack of Visibility and Tooling: Developers may not have access to the SCA tools or the training to interpret the data.
• Complexity of Transitive Dependencies: Vulnerabilities often exist in dependencies of dependencies, hidden layers that are tough to untangle.
• Metrics Overload: Reports that dump raw numbers without context feel insurmountable. A giant number like “5,000 criticals” doesn’t inspire action—it inspires avoidance.

‍

These obstacles can be overcome with a smarter, more strategic approach.

‍

Here’s how. 

‍

By reframing how you present vulnerability data, you can drive meaningful action. Let’s break it into three steps:

‍

‍

Step 1: Become a Scruffy Nerf Herder (for Packages)

‍

What is more motivating? 

‍

“You have 5,000 critical risk vulnerabilities that need to be patched within 30 days.”

‍

-or- 

‍

“You have 10 outdated libraries that, if updated, will resolve 3,500 critical risk vulnerabilities.”

‍

The trick is to group vulnerabilities by library. Most organizations reuse the same libraries across applications, meaning a handful of fixes can significantly reduce risk.

‍

For example, during an engagement, I grouped vulnerabilities by package. I found that the OpenSSH package was the cause of a huge number of vulnerabilities.. After digging into the CVE, I realized it only applied to SSH servers. The application in question only made outbound SCP connections, so the vulnerability was irrelevant. Instead of handing off noise, I removed it and saved the team unnecessary effort.

‍

Actionable Step: Start grouping vulnerabilities by package to uncover high-priority libraries that developers can tackle first.

‍

‍

Step 2: Packages Don’t Age Like Fine Wines

‍

Once you’ve grouped the vulnerabilities, assess how outdated the libraries are. This paints a picture of the service’s overall health.

‍

Here are common findings that grab attention:

‍

• End-of-life packages (no longer supported or patched).
• Libraries older than the company itself.
• Notorious vulnerabilities (e.g. Log4J v1.x).
• Problematic licenses (e.g. libraries with non-commercial licenses).

‍

Here’s a format I use to present this data:

‍

‍

This format tells a story. For example, Library X hasn’t been updated in over five years and only requires a minor update to fix vulnerabilities. Library Y would require a major upgrade to bring it to the current version, but only a bug fix to resolve the vulnerability. 

‍

Developers can quickly assess the scope of work and move forward with confidence. 

‍

‍

Step 3: A New Hope - It Isn’t as Bad as You Thought

‍

Once you’ve grouped the data and shown package age, something magical happens: developers see a path forward.

‍

Here’s what this approach achieves:

‍

1. Builds Understanding and Trust: You’ve demonstrated that you know the data inside and out. Developers, leaders, and auditors will feel confident in the information you’re presenting.
2. Turns Panic into Progress: Instead of overwhelming developers with raw counts, you give them a prioritized list that feels manageable. A “Top 10 Vulnerable Packages” list is far more actionable than “5,000 vulnerabilities.”

‍

When you present vulnerabilities this way, developers take ownership. They start fixing issues without being chased, and they develop their own solutions tailored to their workflows. You become a partner in their success rather than a messenger of doom.

‍

‍

Finally {

‍

Stop the shock and awe. By grouping vulnerabilities, assessing package age, and presenting actionable next steps, you can transform overwhelming SCA reports into manageable plans. Developers want to do the right thing—your job is to help them see the path forward.

‍

When you equip your team with hope and clarity, you’ll make real progress on securing your software supply chain.

‍

}

‍

Diving Deeper:

Here are resources to help you dig deeper into software supply chain security:

• OWASP Dependency-Check
• OWASP Developer Guide
• Open Source Licenses

‍