# GSVS Working Group Meeting Agenda and Notes

## Monday July 11th 3pET/12pPT
* Monday July 11th 3pET/12pPT
* Join Zoom Meeting
* https://zoom.us/j/96487746164?pwd=SHJUMkFJSHdTVkhlS3dnclM0aDIrZz09

## BoF notes

* [Analysis of the data of vulnerabilities - BoF @GSVS](https://hackmd.io/plWDyYZqTPuF3_7SSSF-uQ)
* [Gaps in Vulnerability Identification - BoF @GSVS](https://hackmd.io/TV99i1pMTsiHTwfU8oTn-w)

### Agenda

* Recap GSVS BoF
* First project - Vulnerability management and data enrichment
* Scope
* Deliverable(s)

### Notes

#### Attendees
*please include your affiliation*
* Emily Fox, Apple, CNCF TOC
* Brandon Lum, Google, Security TAG Co-Chair
* Josh Buker, Cloud Security Alliance, GSD
* Josh Bressers, Anchore
* Jamie Magee, Microsoft
* Coby Allred, Microsoft

#### Discussion
*collaboratively take notes here please!*

Recap from GSVS.

For GSD, its the ability to update and enrich existing data

Commit matching - boil the ocean, OSV supports this (initial and fix time) but not super deep, **hold off**. How do you handle different branches where the git history isn't linear. There is a library that supports this.

Does OSV suffice the needs that GSD needs it for?

* Affected version(s)
* Version fixed (if just fixable by version)
* How to fix (if no version does this)
* Which package
* Which ecosystem
* How does an exploit of the vulnerability it work

Example: Needs of a developer (like using bundler audit). They only need to know severity, package affected, version known and version fixed.

OSV seems to be a good enough schema for now for most things and improvements can be made as they come up.

Add descriptions to the type categories (machine-readable).

Human curated information for identifiers (tl;dr) and reference links.

[high level of maturity] Capture the metadata and discussion about how it came to be, the timeline, the impact (think CISA known exploitability stuff), would be nice to parse. But this is not particularly relevant for Developers.

Is compromises and this information intended for GSD and its audiences? Where should this information be part of? Probably not immedietely, different audience between developers vs security researchers.

The consumer personas of this (to focus this work) is Developers and Security Ops, or Security Product.

From security ops standpoint the information you want to gather from database is different.

When working with incidence response, developers want to update dependencies. They want to determine what is the criticality and timeline. Some cases more information is needed, not just the fix.

Security ops are looking for indicators of compromise.

Need a security reddit

## Exercise: figure out the minimum set of fields by persona.

Personas
* Developers
* Affected version(s)
* Version fixed (if just fixable by version)
* How to fix or mitigate (if no version does this)
* Which package
* Which ecosystem
* How does an exploit of the vulnerability it work
* References
* What is the criticality of the vulnerability?
* Where is the discussion on the vulnerability? (i.e. Github Issue)
* Security Operations
* Indicators of compromise
* Which package
* Affected version(s)
* Version fixed (if just fixable by version)
* How to fix or mitigate (if no version does this)
* Where is the discussion on the vulnerability? (i.e. Github Issue)
* References
* When it was reported
* Check if I'm affected i.e. Proof of Concept
* Security Product
* Which package
* Which ecosystem
* Where is the affected code?
* What is the fix?
* What is the actual impact (vulntology and bugs framework)?
* What do the IoCs look like?
* References
* Researchers - this is the provider of the content to meet the minimums defined above.

Focus on machine-readable data so that it can be used for analysis.

What is the threshold for additional metadata?

## Exercise: dedupe the minimal listing and discover what isn't in OSV
* Affected version(s)
* Version fixed (if just fixable by version)
* How to fix or mitigate (if no version does this) [not in OSV]
* Which package
* Which ecosystem
* How does an exploit of the vulnerability it work
* References
* What is the criticality of the vulnerability?
* Where is the discussion on the vulnerability? (i.e. Github Issue)
* Indicators of compromise
* When it was reported
* Check if I'm affected i.e. Proof of Concept
* Where is the affected code?
* What is the actual impact (vulntology and bugs framework)?

### Next steps

1. Understand which of the minimums are already in OSV.

2. Flesh out the [references section](https://ossf.github.io/osv-schema/#references-field), potentially introduce "Tagging" or Prefix in References.

3. Categorize URLs by lifecycle stage. Look at what is tagged as a catch all, and abstract categories.