latest version at all times • For analysis assume they’re always 1 day behind STRATEGY 2 • Wait a month after new major or minor versions • Always on the latest patch release STRATEGY 3 • Use the latest version when you add, then forget • Equally likely to have added or updated the gem at any time in the last year Three common gem strategies
of disclosure • Allows us to determine whether a given version is secure The data to test them Ruby Advisory Database • History of gem releases over time • Includes date of each release • Tells us which version each strategy would have been using at any time Rubygems API • Combining, we can tell what version each strategy would have been on at the time a vulnerability was disclosed, and whether that version is secure • Full analysis at https://github.com/dependabot/gem-vulnerability-analysis
strategy (just) Required response to a new vulnerability disclosure Always up-to-date Late adopter Reactive 47% 47% 47% 3% 4% 4% 42% 35% 35% 8% 15% 16% Not affected Fix by upgrading Fix by downgrading No fix on day zero • In addition, remember, the late adopter has a harder job with “fix by upgrading” • Full analysis at https://github.com/dependabot/gem-vulnerability-analysis
Patch x.y.c -> x.y.z • Based on CI info for 1,750 updates • Many major updates are just dropping old Ruby support, etc. Minor and patch versions rarely have any incompatibilities or new bugs • Based on CI info for 12,000 updates • Pre-1.0.0 updates excluded • Based on CI info for 17,000 updates • Pre-1.0.0 updates excluded Updates with passing CI Notes • SemVer might not work in theory, but it does work in practice • Minor updates are nearly as easy to upgrade as patch releases