msmeissn
commented
3 years ago sounds good as-is... i would perhaps mention encryption method additionaly.
Open SecurityCRob opened 3 years ago
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?
pdxjohnny
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.
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
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: arrayLooks like related work is happening over in CycloneDX as well, woohoo!
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?