Vulnerabilities in what you use.
WHY IT MATTERS
Most software is largely composed of components you did not write.
WHAT THAT MEANS
Most of your vulnerability exposure comes from dependencies.
WHAT TO ESTABLISH
Awareness of vulnerabilities affecting your components.
HOW
Automated scanning against vulnerability databases Notifications from the projects themselves Monitoring of security advisories
WHAT TO ESTABLISH
That scanning runs regularly and that someone acts on the results.
WHY SOMEONE
Scanning that produces reports nobody reads achieves nothing.
WHAT TO ASSESS FOR EACH FINDING
Whether the vulnerable component is actually used Whether the vulnerable function is reachable What the consequence would be Whether a fix is available
WHY REACHABILITY
Many reported vulnerabilities do not apply to how you use the component.
WHAT TO PRIORITISE
Vulnerabilities that are exploitable in your context.
WHAT TO AVOID
Treating every finding as urgent Ignoring findings because there are many
WHY THE SECOND
Alert volume causes genuine problems to be missed.
WHAT TO ESTABLISH
A process for triage.
WHAT TO DO ABOUT UNMAINTAINED COMPONENTS WITH VULNERABILITIES
Replace them, or accept responsibility for fixing them yourself.
WHY
Nobody else will.
WHAT TO ESTABLISH ABOUT UPDATES
A regular cycle of dependency updates.
WHY REGULAR
Large infrequent updates are risky and they are deferred.
WHAT TO TEST
Updates, before deploying.
WHY
Dependency updates break things.
WHAT TO ESTABLISH
That you can update quickly when required.
WHY
Serious vulnerabilities require response in days.
