Hey Guys,My name is Sam, I'm very excited about this project. My eyes lit up when I heard you guys talking about it on the OSS podcast (One of my favorites). The problem domain has been weighing on my mind ever since I read "This is how they tell me the world ends". The Log4j hit and the first security fix as disabling a configuration? I told my wife it was the equivalent of an attacker breaking into the house, turning the lights off, and standing her standing still. Eventually, they will find the light switch.I truly believe that this domain should be open-sourced. I think we need it to be decentralized and provide a Vulnerability Disclosure Blockchain that creates an economy to combat 0-day market bounties ethically... Like I said it's something that eats at me and what really got me hyperfocused on this area.
Anyways, here is a quick thought I had...I think my skill set can contribute to the project. I work for Whitesource Software as a Technical Support Engineer and we provide open source vulnerability scanning and compliance through software composition analysis solutions.One tool that GitHub acquired is LGTM which provides continuous SAST and scanning on open source repos. They provide the SARIF files that contain that CWEs and links to the CodeQL database on the project's site. This would help the project gain adoption by allowing vendors to easily integrate the response from GSD into their solutions. It would be very useful to include these links so anyone using SAIRF for SAST or CodeQL could easily have access to how the weakness was discovered. The most we get out of a CVEs/NVD is a link to a website of a thread that started in 2012, slight sarcasm. Like you guys said, Twitter is a better resource for learning about CWEs.SAIRF Spec: https://docs.oasis-open.org/sarif/sarif/v2.0/sarif-v2.0.htmlLGTM: https://lgtm.com/projects/g/apache/logging-log4j2/
While I think interoperability with existing formats is valuable, we should not restrict or limit the functionality to only the existing challenge areas (which have gotten us here in the first place).
That being said, (and rereading this thread), I'm not clear one what we're specifically searching for a solution to?A data format for information exchange?A data format for information storage?A data model to transcribe external information into a GSD compatible format?
I was under the impression (likely wrongly so) that OSV and json would be the preferred formats. However OSV would require some modification to cover the variety of values needing to be expressed (such as extending beyond just open source to include proprietary software and cloud services, exploit path, evidence of compromise, tests, etc.), because the existing standards and formats are grossly lacking in the necessary details to make informed decisions let alone account for the variety of information technology and service constructs that exist in today's computing era.If we're also discussing a data model, we must first understand what are the values we seek to retain wrt a given vulnerability (suspected or confirmed - also implies state or status), so does it then make sense for us to first articulate what we need to know about a vulnerability and then determine what formats exist that are viable and the corresponding delta between the format, industry formats, and then describe the data model to exchange between them all?
let me know if i'm on the wrong path here.