SecurityCRob commented 3 years ago

A pain point this group identified between Finder/Researchers and Maintainers is the lack of an easy, consistent way to share vuln. reports that capture enough information that makes them actionable on the developer-end. To that end, I submit this simple form for the group to comment on so we can ultimately have a template that correctly captures how best Finders can communicate with an OSS Maintainer when they discover/suspect a vulnerability. I am looking forward to the conversation:

TITLE!

Researcher: YOUR NAME or L33T h@x0rr handle!

Contact information: How do you want to communicate about this?

Description: Short, yet descriptive overview of what you’ve found

Exploitation technique: Local, Remote, other?

Impact(s): What breaks with the thing you found?

Proof of Concept: POC Code and/or steps to reproduce (can attach a file)

Mitigation: Any suggestions on how to fix it?

Affected versions: What Product, OS, stack and versions have you tested against?

Timeline: Have you shared with anyone else yet (who and when)? Do YOU have a deadline they should be aware of?

Credits: Who should get credit for all of this good work?

msmeissn commented 3 years ago

sounds good as-is... i would perhaps mention encryption method additionaly.

lirantal commented 3 years ago

Hopefully, this gets disclosed in a private issue though. Is that possible to do? (private security issue + issue template)

esarafianou commented 3 years ago

@RedHatCRob Could you submit the template as a PR for easier commenting/collaboration?

johnandersen777 commented 1 year ago

Not sure if this is still active, but have been working on a methodology as part of this SCITT use case: WIP: RFCv6: IETF SCITT: Use Case: Attestations of alignment to S2C2F and org Overlays. In this use case we're looking at OpenVEX as the format which we could use to submit the vuln. We'd use the description or evolution of the linked data format there to reference a SARIF or other standard format document or set of instances of formats which would act as the justification, with the status set to affected. Effectively submitting the "form" would be proposing that an ad-hoc generated CVE-ID affects a product. Perhaps a schema and example of form above would help restart discussion?

Ping @kaniini, thoughts? (I might have totally f'd this up, please let me know, thank you 🐇 :) I mentioned in https://github.com/openvex/spec/issues/9 that the ActivityPub.content piggyback based approach in that use case doc is probably too high in the stack protocol/bytes overhead wise, still eagerly awaiting Rapunzel. There may be cases where people like OSS maintainers might want to leverage existing infra to relay at the content level due to not being able to host infra themselves, but not sure what the next move is for vuln comms interop yet until hearing more input from you.

References
- https://github.com/usnistgov/vulntology
- We could leverage vulntology to describe these potential CVEs. Dave one of the authors said this was the original idea.
- https://github.com/ietf-scitt/use-cases/issues/14
- https://github.com/ossf/s2c2f/blob/main/specification/framework.md#appendix-relation-to-scitt
- It looks like transparency services will be the place where vulns are logged, therefore, aligning federation methodologies and vuln submission methodologies would be nice.
- Alice Engineering Comms: 2023-03-16 OpenSSF Town Hall
- Chistoph Puppe asked: "will ai be used for the industrialization of vulnerability hunting in FOSS? aks chatgpt for all signal injections in projects? :)"
  - John posted to chat: https://github.com/ietf-scitt/use-cases/pull/18
- https://github.com/usnistgov/vulntology
- Goals:
  - To standardize the description of vulnerabilities through structured characterization formatting.
  - To enable automated scoring agnostic of any particular system.
  - To improve the level of detail in provided information for the purpose of assisting with defense while minimizing increased risk from attacks.
  - To assist in establishing a baseline of the minimum information needed to properly inform downstream vulnerability management processes.
  - To allow for easier vulnerability information sharing across language barriers

"@context":
  "@vocab": "https://github.com/intel/dffml/raw/93b9b339b2821c330791b33fe12c19c1b7f21fac/schema/security/vuln/proposed/0.0.0.schema.json"
"@id": "https://github.com/intel/dffml/blob/93b9b339b2821c330791b33fe12c19c1b7f21fac/schema/security/vuln/proposed/example.0.0.0.yaml"
include:
- affected_versions:
  - 0.0.0
  credits:
  - name: Alice
  description: "Some kind of caterpillar"
  exploitation_techniques:
  - remote
  - local
  mitigation: "Wake up!"
  poc: |
    print("🐛")
  timeline:
  - date: "2022-04-17"
    description: "Here"
    parties:
    - name: Alice
  - date: "2023-03-23"
    description: "Reported"
    parties:
    - name: Alice
    - name: Bob

$id: https://github.com/intel/dffml/raw/93b9b339b2821c330791b33fe12c19c1b7f21fac/schema/security/vuln/proposed/0.0.0.schema.json
$schema: https://json-schema.org/draft/2020-12/schema
definitions:
  affected_version:
    description: What Product, OS, stack and versions have you tested against? TODO
      regex for PURLs
    type: string
  entity:
    description: Who done it
    properties:
      name:
        description: Whooooo areeeeee youuuuuu?
        type: string
    type: object
  exploitation_technique:
    description: How can did you break it?
    enum:
    - local
    - remote
    type: string
  mitigation:
    description: Any suggestions on how to fix it?
    type: string
  poc:
    description: POC Code and/or steps to reproduce (can attach a file, base64 encode
      a zip or tar for now if a repo or more than one file)
    type: string
  proposed_vuln:
    properties:
      affected_versions:
        items:
          $ref: '#/definitions/affected_version'
        type: array
      credits:
        items:
          $ref: '#/definitions/entity'
        type: array
      description:
        description: "Short, yet descriptive overview of what you\u2019ve found"
        type: string
      exploitation_techniques:
        items:
          $ref: '#/definitions/exploitation_technique'
        type: array
      mitigation:
        $ref: '#/definitions/mitigation'
      poc:
        $ref: '#/definitions/poc'
      timeline:
        $ref: '#/definitions/timeline'
    type: object
  timeline:
    description: What are we thinking the order of events related to responsible discloure
      is?
    items:
      $ref: '#/definitions/timeline_item'
    type: array
  timeline_item:
    description: Something is happneing!
    properties:
      date:
        description: When is this timeline itme happening. TODO date regex. TODO non-linear
          time conversion helpers
        type: string
      description:
        description: What's happening at this point in time?
        type: string
      parties:
        description: Who's involved in this timeline item?
        items:
          $ref: '#/definitions/entity'
        type: array
    type: object
properties:
  '@context':
    items:
      type: string
    type: array
  '@id':
    type: string
  include:
    items:
      $ref: '#/definitions/proposed_vuln'
    type: array

johnandersen777 commented 1 year ago

Looks like related work is happening over in CycloneDX as well, woohoo!

ossf / wg-vulnerability-disclosures

Simple Vulnerability Intake Form for OSS Projects #94

TITLE!