Dependency health is important for software projects but difficult to maintain. Most projects know how to stay up-to-date and secure but few actually do so. The document discusses strategies for improving dependency health, including prioritizing vulnerabilities using static analysis to identify which are reachable, regularly updating dependencies to incorporate fixes, and using aggregate data from diverse projects to identify reliable new releases and avoid breakages. The goal is to make dependency management easier through automated tools that minimize risk while keeping projects reasonably up-to-date.

1. 1
Dependency Health:
Removing the Barriers to Keeping
Projects in Shape
David Habusha
VP Product
Rhys Arkins,
Director of Product
Management

2. Health: Easier Said Than Done
• Everyone knows it’s
important to be healthy
• Most people know what it
takes to be healthy
• Yet, the majority of people
aren’t truly healthy
2

3. ▪ Most developers know it’s best to be up-to-date and vulnerability free
▪ Majority of developers know approximately how to do that
Yet, very few projects are up-to-date and vulnerability-free
3
Dependency Health: The Analogy

4. 4
Case Studies: Eslint and React version distribution
Latest 41.51%
Current major 18.09%
Previous major 27.52%
2+ major behind 40.40%
Latest 75.91%
One minor
behind 7.43%
Same major 16.00%
1 major behind 0.65%

5. 50+% of WhiteSource
customers have at least one
high or critical severity
vulnerability alert
outstanding
5
Vulnerability Stats

6. The Health Coaches / Trainers
• Most don’t claim to have
magic recipes or workouts.
• The most valuable
contribution they make is
determining what’s preventing
healthy lifestyles today, and
coming up with an achievable
plan for getting and staying in
shape.
6

7. Provide tools and services to make open source adoption feasible & safe for
enterprises, large and small:
✓ Forensic scanning of projects to identify open source components
✓ Accurate matching of components to licenses and vulnerabilities
✓ Reports and workflows
7
SCA - The First Generation

8. SCA - The Next
Generation
• Eliminate the majority of effort
required for free and fearless use
of Open Source
• Ensure that open source
compliance is not considered a
burden but instead a reasonable
and necessary part of developing
software
• Put dependency management
on “easy mode”
8

9. The Dependency
Management Challenge
• Use of open source inevitably leads to
the frequent but unpredictable need to
update to avoid known vulnerabilities.
• These will often be very high priority if
there is the possibility that vulnerabilities
could be exploited in production.
• The more out of date your dependency
version is, the higher the risk of updating it.
9

10. Thought of the
day
• Over 85% of vulnerabilities have a fix available at time
of disclosure.
• Fixes are usually applied to the latest release, and
infrequently backported to older minor major releases.
• Therefore if you simply adopt the latest version of
dependencies immediately, you could resolve the
majority of vulnerabilities.
10

11. Why is Updating Perceived to be
Complicated?
Changes in behavior of libraries can result in the wrong behaviour in your application,
which can come from:
• Major updates: Intentionally “breaking”, documented, and clearly indicated.
• Non-major but documented: Behavior change occurs in a minor or patch release,
but is documented in release notes.
• Undocumented: Behavior change was either unintentional, or the library author
didn’t realize it would be “breaking” for downstream users
Additionally, you might need to retest your application and services fully, issue a new
release, etc. Both of these are more difficult for organizations without mature DevOps for
Continuous Integration and Deployment.
11

12. Reality Check
Adopting every latest release is not feasible in
production.
But due to vulnerabilities, sometimes we should
adopt a very new release for our own protection.
12

13. Step 1:
Reducing the
quantity of
vulnerability
remediations
1313

14. What Holds People Back
From Remediating?
One of the most common problems is
that there’s too much and users are
overwhelmed.
Prioritizing based on severity has limited
use because a large proportion of
vulnerabilities are classified as high risk.
Like with getting fit, people can
irrationally delay starting at all if they see
a great challenge ahead.
14

15. Solution: Effective
Usage Analysis
WhiteSource research shows that 80%+
of the time a software project receives a
vulnerability alert, the problematic code is
unreachable by the application.
Developers often reach the same
conclusion too, through manual
investigation of (a) the vulnerable code,
and (b) their application’s use of the
vulnerable library. However, it is a difficult
call to decide for sure that the vulnerable
code is unreachable.
15

16. 16
Dynamic usage analysis works like code
coverage - it can tell you which lines of code
have been reached in production, but it can’t tell
you if they can’t be reached.
e.g. code is broken into two categories:
• Definitely can be reached
• Maybe can be reached
When it comes to vulnerability remediation, it’s
not good enough to say “we’ll ignore that
vulnerability because nobody’s accessed the
exploitable code it yet”.
Why Dynamic Usage
Analysis Fails

17. Why Static Usage
Analysis Succeeds
Static usage analysis works by breaking
down code and libraries into syntax trees
and tracking all possible “paths” that an
application can take. Once all possible
paths have been tracked, code can be
classified into two categories:
• Definitely unreachable
• Definitely reachable
• Maybe reachable
This is very important because we can only
disregard a vulnerability warning if we know
the code is definitely unreachable.
17

18. Ultimately, EUA means that many projects can
see a reduction in vulnerability volume by
around 80%.
This way, we can try to reduce:
▪ Developers already know that most
vulnerabilities are ineffective, even before
there existed tools to determine this
automatically
▪ Pointless work is demoralizing
▪ 5x too many alerts runs the risk of “boy
who cries wolf” - people start ignoring it
18
Decrease Vulnerabilities by 80%

19. Step 2:
Preventative
Health
Measures
1919

20. Benefits of being up-to-
date with Dependencies
If there’s a vulnerability fix available, you
already have it.
Most vulnerability fixes will come to you
in the form of a simple patch.
All bug fixes are applied. Maybe some of
them affected your end users even if you
weren’t aware of it yet.
New features are all available for any
future code you write.
20

21. Risks of being up-to-date
with Dependencies
New versions of dependencies can
introduce regression errors.
Early adopters run the highest risk of
hitting undiscovered/unfixed bugs.
2121

22. 22
Can we prevent bugs in open source software?
No

23. Can we
better avoid
broken
releases in
open source?
23
No
23

24. What do open source consumers really
want?
To be as up-to-date as possible
while minimizing risk.
In other words: take every update
possible, unless it’s a bad one.
One of the most valuable things an
SCA vendor can do is to help you
avoid bad open source releases, and
warn you about all breaking ones
(whether properly documented or not).
24

25. Positive indicators about
a new release
✓ The package’s historical reliability/breakage ratio
✓ Amount of source code changes.
✓ The new release passes your tests.
✓ The new release passes everyone else’s tests too.
✓ A significant proportion of projects have already
upgraded to the new release.
✓ No projects have rolled back.
2525

26. The Power of
Crowds
• The most significant indicators for a
release’s reliability come from aggregate
data.
• Even the largest enterprises may not
have enough diverse use of packages to be
confident that nothing changed / nothing
broke.
• Only a diverse sampling of test and
deployment results across the industry can
be used to rapidly detect problems in open
source.
26

27. Hosted dependency update application for
GitHub and GitLab clouds.
Installed into more than 150,000 repositories,
200 million jobs run, 1m+ Pull Requests created.
Runs continuously to monitor dependency
versions and automatically propose updates into
installed repositories.
27
The Strength of WhiteSource Renovate

28. Sampling: Apps vs Libraries,
Public vs Private
• Libraries normally stay “up to date” with
dependencies automatically by using open
ranges. They are typically passing on the risk of
new releases to downstream applications.
• Most public repositories are either libraries or
non-production applications - neither of which are
the best measure of whether a new dependency
version is good.
• The most powerful data comes from active
private repositories with strong test suites.
2828

29. The WhiteSource Dependency Vision
• Provide users with a confidence in open source releases that they could never
obtain on their own.
• Allow projects to define tolerable risk levels for adopting new releases.
• Deliver regular bundles of updates that “just work”, allowing companies to stay
reasonably up-to-date and ready to respond quickly when needed.
• Industry-leading vulnerability detection to alert whenever a new release should
be adopted out-of-cycle.
• Effective usage analysis to suppress alerts when vulnerabilities are ineffective.
29

30. Getting and Staying
in Good Health
• Much like physical health, it takes more than
just awareness and availability of tools to be
successful.
• Tools or processes that demand too much or
generate too much noise start to be ignored.
• The “secrets” for successful adoption of safe
open source use will be:
o It should just work, with the minimum of effort
and risk
o Demands for extraordinary effort should be
limited and justified
3030

31. Looking Forward - The Ideal Strategy
• Reduce vulnerability false positives
with effective usage analysis.
• Reduce positives by adopting an
automated schedule for dependency
updating and “staying ahead of the
curve”. Use a service that can deliver
dependency update recommendations.
• For the remaining vulnerabilities,
reduce the risk of rapidly updating by
being at most 1-2 minor releases
behind whenever possible.
31

32. 32
Q&A

33. 33
Thank You!