Today no one can claim ignorance about the need for an open source vulnerability strategy, so what is yours? Are you the fire alarm type, who prefers to sit tight unless a vulnerability alert is ringing in your inbox? Or are you the fire hose type, staying ahead of the game with a never-ending stream of open source updates to apply? Join Rhys as he discusses the pros and cons of these two approaches, as well as whether there's a magical middle ground between the two which doesn't involve a fire analogy.

1. Fire Alarms vs. Fire Hoses:
Keeping Up with
Dependencies
Rhys Arkins, Director of Product Management
1

2. Dependency
Management
2
Future
Approaches
The
Vulnerabilities
Challenge
1 2 3

3. 3
1Dependency
Management

4. Company Confidential & Proprietary 4
Old School Dependencies
1. Find useful third party code
2. Copy and paste it into your project
3. Move onPlease put Slides 4, 5 and 6 into three pillars on
one slide

5. Company Confidential & Proprietary 5
The CDN Approach
1. Find useful third party code
2. Find a CDN that hosts it
3. Copy/paste a link into your website headers
4. Move on

6. Company Confidential & Proprietary 6
Early Package Management
1. Browse registry, select a package
2. Add dependency to a package file
3. Stay always up to date because every time you install
you get the newest version

7. AKA Dependency Roulette
▪ Always installs the latest version
▪ Team members might run different
versions
▪ It usually works, sometimes doesn’t
Add better image of Roulette

8. Company Confidential & Proprietary 8
Modern Package Management
1. Declare dependencies like before
2. Commit a lock file
3. Get same results every install

9. 9
2The
Vulnerabilities
Challenge

10. 10
Open Source Vulnerabilities Are Rising
Replace with 2019 version

11. Company Confidential & Proprietary
▪ Scans your source code regularly to detect third party code
(“dependencies”)
▪ Cross-matches that against a database of known vulnerabilities
▪ Notifies you/your team of any new vulnerability
▪ May include expert advice on how to fix
▪ May even offer a Pull Request to fix it
11
How Vulnerability Alert Services Work

12. Company Confidential & Proprietary
▪ The vulnerability might be VERY
important
▪ Your company might rely on you
remediating the vulnerability
immediately
▪ However, you are 18 months and 10
releases out of date
12
The Dependency Fire Alarm Routine

13. “I wish it was just a patch..
-- Every developer when facing a vulnerability in a long-forgotten dependency
13

14. Company Confidential & Proprietary
▪ Your computer and phone keep themselves automatically up-to-
date, so why can’t your software project?
14
Dependency Automation
Automation icon

15. Company Confidential & Proprietary
▪ Scans your software project for dependency declarations
▪ Checks if updated versions exist
▪ Submits Pull Requests including Release Notes
▪ Supports grouping and scheduling according to user preferences
15
How Dependency Automation Tools Work

16. Company Confidential & Proprietary
▪ Being “relatively” up-to-date with
dependencies significantly reduces the
time and risk of remediating vulnerable
dependencies
▪ Staying up-to-date may even mean
patching vulnerabilities before they’re
even announced
▪ Naturally, any bug fixes are an added
bonus
▪ However, there can really be a lot of
updates in any week or month
16
Dependency Fire Hoses
Better image of fire hoses

17. Company Confidential & Proprietary
▪ Vulnerabilities:
▪ Know what you’re using, and if any are vulnerable
▪ Have a process for managing vulnerability remediation
▪ Automatically remediate when available
▪ Updates:
▪ Use an automated tool for processing dependency updates
▪ Adjust the schedule according to your team’s needs
▪ More up-to-date = less vulnerability risk
17
Current Best Practices

18. 18
3Future Approaches

19. Company Confidential & Proprietary
▪ Copy/paste third party code
▪ Very high risk. Likely never updated, may have vulnerabilities and bugs
▪ Use dependency ranges
▪ High risk. Different versions could be installed on every machine
▪ Use lock files
▪ Medium risk. Predictable builds but dependencies won’t “update themselves”
▪ Use automated dependency updates
▪ Lowest risk (when combined with lock files)
▪ Know whenever there’s an update, and
review the Release Notes
19
Recapping Dependency Maturity Levels

20. Company Confidential & Proprietary
▪ It can be quite a lot of work to continuously update
dependencies
▪ The earlier you adopt a new version after release,
the higher chance it has an undiscovered bug that
you get to discover
20
What’s Left To Do?

21. Company Confidential & Proprietary
▪ “Have good test coverage” is a common
suggestion, but it’s not your job to test the entirely
of your dependencies either
▪ If your tests pass with a new version, how
confident are you that nothing will go wrong?
▪ What if you could know that tests also passed for
200 other companies using the same
dependency?
21
Safety Through Crowd Testing

22. Company Confidential & Proprietary
▪ Passing everyone’s tests is a very good sign, but sometimes bugs
can still slip through
▪ What if you could wait until X companies or Y% of companies have
already upgraded for a week?
▪ What if you could skip any upgrade that saw multiple users roll
back the new version?
22
Safety Through Crowd Adoption

23. Company Confidential & Proprietary
▪ At its core, an open source project:
https://github.com/renovatebot/renovate
▪ Over 100+ contributors, daily releases
▪ Very wide platform support (GitHub, GitLab, Bitbucket, Azure
DevOps)
▪ 40+ package managers supported (npm, Yarn, Gradle, Maven,
Poetry, Go Modules, Dockerfile, etc)
▪ Thousands of participating users and companies
to gather “safe” dependency data from
23
WhiteSource Renovate – Safe Dependency Updates
Add Renovate Icon

24. Thank You!
24