Skip to content

Latest commit

 

History

History
76 lines (67 loc) · 5.17 KB

2020-12-14.md

File metadata and controls

76 lines (67 loc) · 5.17 KB
Raw

Participants

  • Marcin Hoppe (Auth0)
  • Eva Sarafianou (Auth0)
  • Crystal Hazen (HackerOne)
  • Jason Keirstead (IBM Security)
  • Josh Bressers (Elastic)
  • CRob (Red Hat)
  • Reed Loden (HackerOne)
  • Morten Linderud (Arch Linux)
  • David A. Wheeler (Linux Foundation)
  • Paulo Flabiano Smorigo (Ubuntu/Canonical)
  • Rhys Arkins (WhiteSource)
  • Martin Prpic (Red Hat)
  • Matt Wilson (GitLab)
  • Josh Dembling (Intel)
  • Nicole Schwartz (GitLab)
  • Luigi Gubello (Arduino)
  • Florencio Cano (Red Hat)

Agenda

  • Jason Keirstead: How IBM consumes disclosed vulnerability data?
  • Rhys Arkins: How WhiteSource consumes disclosed vulnerability data?
  • Catch up on progress in defining use cases (#80)
  • Florencio Cano: Verification of Findings initiative

Video recording

YouTube recording: https://www.youtube.com/watch?v=8HgEyynRGjI

Meeting minutes

  • Welcome new team members
    • Florencio - Red Hat
    • Luigi - Arduino
    • Arsala - Student organization to promote open source software
  • Marcin: There is an additional agenda item if we can fit it from Florencio
  • Marcin: Documentation of use cases for a couple of different personas sub-groups from last meeting we can cover toward the end, but we lacked someone to handle tool/vendor persona, we now have someone to help with that (Jason).
  • Jason Keirstead: Presentation - How IBM consumes disclosed vulnerability data?
    • Presentation
    • Pending PR to add slides to documentation folder (Marcin will merge after the call)
    • The slides begin by covering Personas that have been identified by this group, in detail (role, needs, pain points)
      • Identified one additional one - Purchaser - to be added as we document these in the GitHub project
    • There is then an example scenario showing how these personas are weaved together (utilizing a great chart to cover flow)
      • Chat notes that it is true often there is often (50%) a miss on communications to Cherry (persona) from Finn (persona), and the other 50% comes from Alice (persona) and through relationships with upstream communities or monitoring of their resources.
    • Note made this is one example scenario and we can not cover all use cases within one example scenario
    • CRob points out we may not be able to address all items here and we should point to other groups for solving / covering other items we identify
    • Nicole: I believe we should still cover them in use cases etc but specifically not solve them
    • Marcin: we will add both the personas and use cases and a table as separate markdown files between this meeting and the next
    • Marcin: we will cover scenario 2 on next meeting
  • Rhys: Presentation - How WhiteSource consumes disclosed vulnerability data?
    • The raw data is messy (if you have not dealt with it directly before) it is not well structured nor a clear 1:1 mapping of vulnerability to packages
    • Explains low latency notification versus high latency
    • Explains package versioning vs Fingerprinting
      • The industry has improved the flow where a notification of vulnerability also includes a patch (fixed in)
      • Not all package managers support this, which forces the use of fingerprints
    • Tooling in the SDLC, people have already reached optimization of shift left and there needs to be part of security in depth including notification of vulnerabilities discovered in already deployed dependencies.
      • Suggestion to make slide more clear about known and in depth
      • From David A. Wheeler - My thoughts: Shift-left is still a good idea within open source software; the challenge is that in most cases that’s an external supplier, so just “shifting left” within your organization doesn’t prevent vulnerabilities. That means we need to find ways to help OSS projects also shift left (find vulnerabilities & fix them sooner, ideally before the software is released).
    • Usage analysis - being able to identify transitive issues and indicate likely a false positive
      • Discussion note: SBoM should be able to indicate transitive vs not as well
      • Nicole yes but not sure we’re the group to tackle SBoM (at least any time in the near future) although we should indicate all known limits/misses
    • Identify Differing priorities in accuracy vs speed (and balancing accuracy of the results)
  • Florencio - related initiative
    • Open source projects recieve many reports from security researcher that could be dump of a fuzzer tool or other tool - this often is not enough for developers to be able to locate and fix an issue
    • They are working to create a list of things to try and do along with that in order to make it a more valuable report - i.e. don’t just send the result of a tool, because there is limited quantity of time to invest and items that are easy to be triaged will likely be addressed first
    • Template for reporting being created
    • This is within the tooling working group but should it be here?
    • Discussion
      • There is overlap and we should certainly also point to existing work

Action items

  • @MarcinHoppe to extract persona descriptions from Jason's presentation (#91)
  • @MarcinHoppe to create a new issue to discuss the whitepaper (#88)