disclosure publishing mechanism and format requirements

[Lukas Kahwe Smith]

Aloha,

We have seen a few comments on this already and I have tried to collect things a bit in no particular order. lets try to first think about requirements before jumping to solutions in order to prevent us from building the requirements around the first solution that comes to mind.

publishing mechanism requirements:

1) decentralized
2) as much standards based as possible
3) low infrastructure requirements
4) web based

format requirements:

1) easily parseable for both humans and machines
2) easy authoring
2) as much standards based as possible
4) structured (unstructured information can be provided via a description field or via reference links)

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[padraic.brady]

Hey Lukas,

It may fall into one of the above categories, however we should also consider "discovery", by which I mean making the formatted data discoverable given limited information about the project (e.g. a git or website URI). It's probably more important for those of us like Drupal who rely on RSS feeds.

Delving into the formats section - for those needing background - Drupal has requested an RSS compatible format. So there will likely be two suggested formats: whatever most projects can throw into git repos, and something that can be turned into machine readable XML (either reusing RSS or via an RSS/Atom extension).

Paddy

[larry]

I agree that discovery is in scope to discuss, even if we end up with something light like "conspicuously publish".

I don't recall asking for an RSS feed, though.  Who from Drupal suggested that?  (Personally I like the idea of using Atom for pushhub support, but I don't know that anyone from Drupal besides me had weighed in at all.)

--Larry Garfield

[Pádraic Brady]

You, though my memory isn't perfect and it might have been Atom (no
different to RSS if extra elements are needed).

In any case, Drupal is not the only large project per se that might
want something other than text file in git.

Apologies, if I paraphrased you inaccurately ;).

Paddy

> --
> You received this message because you are subscribed to the Google Groups
> "php-fig-psr-9-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig-psr-9-disc...@googlegroups.com.
> To post to this group, send email to
> php-fig-psr-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig-psr-9-discussion/d92b3194-c747-4f9c-82bb-bc4275cc0795%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

[enygma]

One thing to also be aware of on the topic of discoverability - while lots of PHP projects use GitHub, the mechanism shouldn't necessarily be tied to it (re: the "web based"). There's a much larger percentage of PHP projects out there, especially legacy (non-Composer) ones that seem to have more of the issues that come across the bug trackers, that aren't on GitHub and just live in their own repos.

Or, is the goal to shoot for the low-hanging GitHub based fruit first then expand out?

-chris

[larry]

I'd been suggesting Atom for a while because it's machine parsable and has Push support, both of which are, I believe, important features.  Drupal currently publishes its SAs as plain text blog posts, but Drupal being Drupal that's trivial to also syndicate as an RSS feed (we do) and a twitter stream (we do).  I am not aware of RSS in particular being a requirement for anything.  (It's easy enough for any human-readable format to be mutated to any sort of human-readable feed we want.)

I agree though that "human-readable text file in git" is insufficient.

--Larry Garfield

> email to php-fig-psr-9-discussion+unsub...@googlegroups.com.

[larry]

Agreed entirely that reliance on GitHub would be unacceptable.  (Drupal and Wordpress aren't on GitHub, and that's 2 of the 3 largest PHP projects out there.)  I think it is reasonable to expect it to be some web-accessible URI, however.  Directly linking to GitHub is a web-accessible URI, but so is some URI on Drupal.org or Wordpress.org, or through some aggregating service like Sensio Labs runs.  As long as it's a publicly available URI I think that's sufficient.

--Larry Garfield

[Pádraic Brady]

On 29 November 2014 at 13:16, enygma <eny...@phpdeveloper.org> wrote:
> One thing to also be aware of on the topic of discoverability - while lots
> of PHP projects use GitHub, the mechanism shouldn't necessarily be tied to
> it (re: the "web based"). There's a much larger percentage of PHP projects
> out there, especially legacy (non-Composer) ones that seem to have more of
> the issues that come across the bug trackers, that aren't on GitHub and just
> live in their own repos.
>
> Or, is the goal to shoot for the low-hanging GitHub based fruit first then
> expand out?

Github is popular enough that my practical side would want to allow
for folk to bung a file on their master branch and call it a day. It's
a relatively simple process given a git URI for Github to get the
master branch name (if not "master"), swap "blob" for "raw" in the
URL, and get the raw file needed.

Outside of Github, given a URL, the HTML at that URL needs to declare
the file location. The usual method is a meta tag for an identifier
containing the URI.

Format is a distinctly different topic than discovery. We can use Atom
or RSS - however, neither is likely fully reusable. We can extend the
available tags using a custom namespace perhaps which may or may not
overlap with the existing RSS/Atom elements should we choose to reuse
any. A simpler companion format that can be hand typed (e.g.
JSON/YAML) MAY be advantageous in keeping the cost of entry low. I
tend to prefer JSON since PHP already has built in support for it.

As we dig through it, discovery will inevitably look more and more of
an annoyance ;). So I'd propose keeping it to its own topics far away
from formats (the two are mutually exclusive for the most part).

Paddy

[Lukas Kahwe Smith]

On 29 Nov 2014, at 22:01, larry <la...@garfieldtech.com> wrote:

Agreed entirely that reliance on GitHub would be unacceptable.  (Drupal and Wordpress aren't on GitHub, and that's 2 of the 3 largest PHP projects out there.)  I think it is reasonable to expect it to be some web-accessible URI, however.  Directly linking to GitHub is a web-accessible URI, but so is some URI on Drupal.org or Wordpress.org, or through some aggregating service like Sensio Labs runs.  As long as it's a publicly available URI I think that's sufficient.

--Larry Garfield

On Saturday, November 29, 2014 7:16:52 AM UTC-6, enygma wrote:

One thing to also be aware of on the topic of discoverability - while lots of PHP projects use GitHub, the mechanism shouldn't necessarily be tied to it (re: the "web based"). There's a much larger percentage of PHP projects out there, especially legacy (non-Composer) ones that seem to have more of the issues that come across the bug trackers, that aren't on GitHub and just live in their own repos.

Or, is the goal to shoot for the low-hanging GitHub based fruit first then expand out?

Maybe I do not understand the proposal but what is Github specific here? Isn't it just using a VCS with a web frontend?

regards,

Lukas

[Larry Garfield]

For our purposes, yes.  Otherwise see Paddy's reply, to which I say "what he said".

--Larry Garfield

[enygma]

I think I misunderstood what the reference to "web based" was relating to. Based on the other comments I see that it's not the "based on a website" definition but the "web accessible" type of thing. My misunderstanding....nothing to see here, move along :p

I do definitely agree that discovery and format should be separated out and agree with Paddy. Ideally, the format comes first, then we figure out how to discover/share that resource.

-chris

[Pádraic Brady]

To be fair, even mentioning Github may itself be out of scope for
discovery since users can't exactly ring up the GH team and demand
that they put files at specific web-based URLs. I'm mainly assuming
that given a git location, whoever might implement a tool can, given
certain discovery rules, translate that to a Github HTTP request as an
efficient shortcut to cloning the repo.

Paddy

> --
> You received this message because you are subscribed to the Google Groups
> "php-fig-psr-9-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to php-fig-psr-9-disc...@googlegroups.com.

> To post to this group, send email to
> php-fig-psr-...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig-psr-9-discussion/7c0ce055-41d4-4e46-962d-11c09d2970e1%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

[enygma]

I think this belongs in this thread (as it relates to the format) but do we want to reinvent something or would using something like the CVRF make more sense:

http://www.icasi.org/cvrf-1.1

It's pretty widely adopted - it might only take something that would make it easier to use/produce.

-chris

> email to php-fig-psr-9-discussion+unsub...@googlegroups.com.

[Pádraic Brady]

On 8 December 2014 at 19:40, enygma <eny...@phpdeveloper.org> wrote:
> I think this belongs in this thread (as it relates to the format) but do we
> want to reinvent something or would using something like the CVRF make more
> sense:
> http://www.icasi.org/cvrf-1.1
>
> It's pretty widely adopted - it might only take something that would make it
> easier to use/produce.
>
> -chris

We could, however the problem is:
http://www.icasi.org/images/CVRF-mindmap-1.1.jpeg

It's one of those XML monstrosities (I might be exaggerating just a
wee bit) that aren't well aligned to having a simple parser/emitter
for a "list of vulnerabilities". It works extremely well for certain
projects that collate data on stacks of vulnerabilities and need to
cross-reference and track them very carefully, but I just wouldn't
want to rely on my faith in programmers to populate all of those
fields accurately, reliably and in a schema perfect manner compared to
a dumber JSON file or some narrow additions to basic RSS/Atom. Many of
the fields would also be redundant or self-evident out of the gate
when applied to single projects.

I am indeed strongly favouring ease of implementation here.

That said, there is nothing to stop us from raiding it for a subset of
elements. I'm mostly in favour of using RSS/Atom + Custom Extension
since we already have a bunch of feed parsers around that could be
easily modified to handle that requirement, and keeping things limited
to one file/URL per application/project. Though we'll see how long my
notions of simplicity rule as the requirements get teased out...

Paddy

[enygma]

I'm good with avoiding the full standard, but I wonder if some of the terminology could be shared between them to make for at least some cross-pollination if it came to it.

There's lots of good ideas in their Dictionary that could be reused in our format: http://www.icasi.org/cvrf-1.1-dictionary

Most of the things the FriendsOfPHP descriptors fit into categories in this dictionary too.

-chris

[Pádraic Brady]

On 9 December 2014 at 18:33, enygma <eny...@phpdeveloper.org> wrote:
> I'm good with avoiding the full standard, but I wonder if some of the
> terminology could be shared between them to make for at least some
> cross-pollination if it came to it.
>
> There's lots of good ideas in their Dictionary that could be reused in our
> format: http://www.icasi.org/cvrf-1.1-dictionary
> Most of the things the FriendsOfPHP descriptors fit into categories in this
> dictionary too.
>
> -chris

No objections here.

[Larry Garfield]

I like the idea of stealing their terminology, or at least making sure ours is compatible.  I agree with Paddy, though, that we should definitely keep the implementation in the "human editable" realm if we expect anyone to actually use it. :-)  (Yes, XML can be human editable!)

--Larry Garfield

--

You received this message because you are subscribed to the Google Groups "php-fig-psr-9-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig-psr-9-disc...@googlegroups.com.

To post to this group, send email to php-fig-psr-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig-psr-9-discussion/57f2845f-ca78-4109-92a6-cdb406a0727a%40googlegroups.com.

[Lukas Kahwe Smith]

> On 10 Dec 2014, at 01:12, Larry Garfield <la...@garfieldtech.com> wrote:
>
> I like the idea of stealing their terminology, or at least making sure ours is compatible. I agree with Paddy, though, that we should definitely keep the implementation in the "human editable" realm if we expect anyone to actually use it. :-) (Yes, XML can be human editable!)

agreed as well on both points (SHOULD use terminology but MUST be human readable)

[enygma]

I started to take a stab at going through their dictionary and figuring out what values might work best in our context (and what doesn't really make sense to be included). Here's the list I came up with:

1. Title

2. Description of vulnerability

3. Product Name

4. Contact (email, probably)

5. Vulnerability release/publish date

6. Unique ID for the advisory

7. URL to reference more information about the issue

Then in a "Vulnerability" sub-section (for human-readability, naturally):

1. Severity (from [low, medium, high])

2. CVE ID (optional)

3. CWE ID (optional)

4. Affected Version(s)

5. Status (from [Open, In Progress, Disputed, Completed])

6. Remediation description (how it was fixed)

7. Remediation type (from [Workaround, Mitigation, Vendor Fix, None Available, Will Not Fix])

8. Remediation URL (more information on the fix itself, could be the same as other URL)

9. Risk (from [low, medium, high], a combination of exploitability, prevalence, detectability and impact)

There's not a concept of the overall "Risk" in the CVRF document but I think it'd a valuable thing to have for people wanting to know how much importance to give it.

Obviously this could be contained in a "Vulnerabilities" set that could provide extra meta about the project too.

Thoughts?

-chris

[Pádraic Brady]

Hi Chris,

On 10 December 2014 at 16:09, enygma <eny...@phpdeveloper.org> wrote:
> There's not a concept of the overall "Risk" in the CVRF document but I think
> it'd a valuable thing to have for people wanting to know how much importance
> to give it.
> Obviously this could be contained in a "Vulnerabilities" set that could
> provide extra meta about the project too.
>
> Thoughts?

Risk or severity could be implied from the CVSS scores in CVRF.
Simplest one to check is base score - low, medium and high severity
would be subdivisions of a base score between 0 and 10.

We can probably stick to the basic textual ratings but allow for CVSS
scores. Possibly even vectors - anyone out there using those?

[enygma]

On Wednesday, December 10, 2014 10:32:07 AM UTC-6, padraic.brady wrote:

Risk or severity could be implied from the CVSS scores in CVRF.
Simplest one to check is base score - low, medium and high severity
would be subdivisions of a base score between 0 and 10.

We can probably stick to the basic textual ratings but allow for CVSS
scores. Possibly even vectors - anyone out there using those?

Agreed...I'd like to keep it as "human readable" as possible but still allow for the CVSS scoring. Most people who would read these reports would more readily understand a text rating than the CVSS, especially non-security folks.

-chris

[Lukas Kahwe Smith]

> On 10 Dec 2014, at 17:09, enygma <eny...@phpdeveloper.org> wrote:
>
> I started to take a stab at going through their dictionary and figuring out what values might work best in our context (and what doesn't really make sense to be included). Here's the list I came up with:

> Then in a "Vulnerability" sub-section (for human-readability, naturally):
>
> 1. Severity (from [low, medium, high])
> 2. CVE ID (optional)
> 3. CWE ID (optional)
> 4. Affected Version(s)

what syntax are we going to use for version ranges especially? do we just use composer/npm style here? in that case the version can be a single string but for easier readability multiple separate versions and version ranges should be supported as well

> 5. Status (from [Open, In Progress, Disputed, Completed])

I guess "completed" would then imply that at least one newer version is available that is not vulnerable but I guess seeing the remediation type it just means that no additional work is planned at this point. in this sense the status could also revert back ?

> 6. Remediation description (how it was fixed)
> 7. Remediation type (from [Workaround, Mitigation, Vendor Fix, None Available, Will Not Fix])

see my points above

> 8. Remediation URL (more information on the fix itself, could be the same as other URL)
> 9. Risk (from [low, medium, high], a combination of exploitability, prevalence, detectability and impact)

we might also give some "suggestions" on how to use the risk or what should be what risk level.

regards,
Lukas

[enygma]

On Wednesday, December 10, 2014 11:36:10 AM UTC-6, Lukas Kahwe Smith wrote:

> On 10 Dec 2014, at 17:09, enygma <eny...@phpdeveloper.org> wrote:
>
> I started to take a stab at going through their dictionary and figuring out what values might work best in our context (and what doesn't really make sense to be included). Here's the list I came up with:

> Then in a "Vulnerability" sub-section (for human-readability, naturally):
>
> 1. Severity (from [low, medium, high])
> 2. CVE ID (optional)
> 3. CWE ID (optional)
> 4. Affected Version(s)

what syntax are we going to use for version ranges especially? do we just use composer/npm style here? in that case the version can be a single string but for easier readability multiple separate versions and version ranges should be supported as well

I could see it being similar to the Composer version definitions (again, more possibility for crossovers between the two projects) and just having sets like [">=3.2.0", "4.0.3"]. Like with PHP itself, there's been numerous CVE-related issues that were fixed in like a 5.4.x and 5.5.x versions at the same time. That way you'd only need one record for both issues. (relevant: https://getcomposer.org/doc/01-basic-usage.md#package-versions)

 

> 5. Status (from [Open, In Progress, Disputed, Completed])

I guess "completed" would then imply that at least one newer version is available that is not vulnerable but I guess seeing the remediation type it just means that no additional work is planned at this point. in this sense the status could also revert back ?

Since the data is related to the vulnerability and not really a "tracker" of things being fixed, yes - I could see it reverting back if the same vulnerability popped up again in a later version. I guess that brings to light one interesting point....is the intent of this document to be:

1. A "feed" of the vulnerabilities as they're reported and fixed or

2. A data source that lists all vulnerabilities and can be updated like with Status changes

In #1, you'd possibly have the same vulnerability information duplicated multiple times. It's possible, given the right structure, that for #2 a single entry could have multiple of the sub-sections, each with the happening of the vulnerability. So like:

vulnerabilities: [

    {

        status: "Fixed",

        versions: ["3.4.2"]

    },

    {

        status: "Open",

        versions: [">=5.1.0"]

    }

]

So that the main data for the vulnerability (like title and description) are kept out of the vulnerability instances.

 

> 6. Remediation description (how it was fixed)
> 7. Remediation type (from [Workaround, Mitigation, Vendor Fix, None Available, Will Not Fix])

see my points above

> 8. Remediation URL (more information on the fix itself, could be the same as other URL)
> 9. Risk (from [low, medium, high], a combination of exploitability, prevalence, detectability and impact)

we might also give some "suggestions" on how to use the risk or what should be what risk level.

Agreed but this one is tricky. What might be considered a "high" for a templating project (ex. not preventing XSS) would be a "low" for others. As always, the answer would mostly be a great big "it depends" heh.

 

regards,
Lukas

[Pádraic Brady]

On 10 December 2014 at 20:28, enygma <eny...@phpdeveloper.org> wrote:
>> > Then in a "Vulnerability" sub-section (for human-readability,
>> > naturally):
>> >
>> > 1. Severity (from [low, medium, high])
>> > 2. CVE ID (optional)
>> > 3. CWE ID (optional)
>> > 4. Affected Version(s)
>>
>> what syntax are we going to use for version ranges especially? do we just
>> use composer/npm style here? in that case the version can be a single string
>> but for easier readability multiple separate versions and version ranges
>> should be supported as well
>
>
> I could see it being similar to the Composer version definitions (again,
> more possibility for crossovers between the two projects) and just having
> sets like [">=3.2.0", "4.0.3"]. Like with PHP itself, there's been numerous
> CVE-related issues that were fixed in like a 5.4.x and 5.5.x versions at the
> same time. That way you'd only need one record for both issues. (relevant:
> https://getcomposer.org/doc/01-basic-usage.md#package-versions)

Composer version syntax would be ideal. It's an existing known system
that would ensure consistency across various data imports and thus
make implementation less of a PITA handling edge cases.

>> > 5. Status (from [Open, In Progress, Disputed, Completed])
>>
>> I guess "completed" would then imply that at least one newer version is
>> available that is not vulnerable but I guess seeing the remediation type it
>> just means that no additional work is planned at this point. in this sense
>> the status could also revert back ?
>
> Since the data is related to the vulnerability and not really a "tracker" of
> things being fixed, yes - I could see it reverting back if the same
> vulnerability popped up again in a later version. I guess that brings to
> light one interesting point....is the intent of this document to be:
>
> 1. A "feed" of the vulnerabilities as they're reported and fixed or
> 2. A data source that lists all vulnerabilities and can be updated like with
> Status changes

Technically, there shouldn't need to be a distinction so treating the
source as a "feed" is perfectly valid. If you take Atom as an example,
you can alter individual entries and revise the date in an "updated"
field so that readers can replace old entries with fresher data.

Most people are likely to view it as a flat file database since the
size of data for many projects is unlikely to necessitate pagination.
We'll inevitably need to handle pagination in some manner.

> In #1, you'd possibly have the same vulnerability information duplicated
> multiple times. It's possible, given the right structure, that for #2 a
> single entry could have multiple of the sub-sections, each with the
> happening of the vulnerability. So like:
>
> vulnerabilities: [
> {
> status: "Fixed",
> versions: ["3.4.2"]
> },
> {
> status: "Open",
> versions: [">=5.1.0"]
> }
> ]
>
> So that the main data for the vulnerability (like title and description) are
> kept out of the vulnerability instances.

Agreed.

>> > 9. Risk (from [low, medium, high], a combination of exploitability,
>> > prevalence, detectability and impact)
>>
>> we might also give some "suggestions" on how to use the risk or what
>> should be what risk level.
>
>
> Agreed but this one is tricky. What might be considered a "high" for a
> templating project (ex. not preventing XSS) would be a "low" for others. As
> always, the answer would mostly be a great big "it depends" heh.

Such assessments need context and objective measurements. Actually the
whole raison d'etre for CVSS scoring and vector abbreviations was to
allow stakeholders prioritise tasks when mitigating issues by tackling
those with higher severity compared to other CVSS scored
vulnerabilities. If we decided to offer guidance, it needs to meet
similar criteria - comparability for prioritisation. That means taking
into account not only the dire consequences of a given issue, but also
factors like exploitation difficulty, access required to exploit, any
user interactivity required, etc.

You could write a book on doing that, but I suppose we could offer
some sort of summary guidance so such factors are at least in folks'
minds...

[enygma]

True, and it'd be good to have a single document to refer to rather than having to mess with any kind of pagination that might come along with the traditional "feed" idea.

It might get a bit big after a while (though hopefully not!) but given that you're only really working with one entry at a time, I can't see that being too big of an issue.

I agree...we'd have to be careful not to define any kind of "checklist" for things here though. I can see something like "If it has an effect on user information or payment details, it's major" or similar relatively generic advice. Would we want to define an optional CVSS field that could be used specifically for that rather than the consumer having to know the risk level values on their side? I imagine projects with internal security teams might make more use of the CVSS details, but I do want to keep the bar relatively low for those that don't have that luxury.

I think providing a resource that lists the main criteria (exploitability, prevalence, detectability and impact), definitions of each and possibly some kind of weighting of the data (ex: exploitability over discoverability) it could be a good source of guidance.

[Lukas Kahwe Smith]

Hi,

I have a few more questions here:

> On 10 Dec 2014, at 17:09, enygma <eny...@phpdeveloper.org> wrote:
>

> I started to take a stab at going through their dictionary and figuring out what values might work best in our context (and what doesn't really make sense to be included). Here's the list I came up with:
>
> 1. Title
> 2. Description of vulnerability
> 3. Product Name
> 4. Contact (email, probably)
> 5. Vulnerability release/publish date
> 6. Unique ID for the advisory

so this is supposed to be a project specific ID?

> 7. URL to reference more information about the issue
>
> Then in a "Vulnerability" sub-section (for human-readability, naturally):
>
> 1. Severity (from [low, medium, high])

what is the difference between security and risk?

> 2. CVE ID (optional)
> 3. CWE ID (optional)
> 4. Affected Version(s)
> 5. Status (from [Open, In Progress, Disputed, Completed])
> 6. Remediation description (how it was fixed)
> 7. Remediation type (from [Workaround, Mitigation, Vendor Fix, None Available, Will Not Fix])
> 8. Remediation URL (more information on the fix itself, could be the same as other URL)
> 9. Risk (from [low, medium, high], a combination of exploitability, prevalence, detectability and impact)
>
> There's not a concept of the overall "Risk" in the CVRF document but I think it'd a valuable thing to have for people wanting to know how much importance to give it.
> Obviously this could be contained in a "Vulnerabilities" set that could provide extra meta about the project too.
>
> Thoughts?

can you explain why you think a vulnerability subsection would be useful?

[Lukas Kahwe Smith]

I guess one reason for a subsection is that there can be multiple remedies, ie. there can be a mitigation (no BC break solution), a vendor fix (current version with a BC break) and a will not fix (for example for some earlier versions). in this sense however I would propose to just split out:
* Affected Version(s)
* Remediation description (how it was fixed)
* Remediation type (from [Workaround, Mitigation, Vendor Fix, None Available, Will Not Fix])
* Remediation URL (more information on the fix itself, could be the same as other URL)

It might also make sense to also split out:
* Risk (from [low, medium, high], a combination of exploitability, prevalence, detectability and impact)

This should however then all be collected under a “remedy” tag ..

[Lukas Smith]

> On 10 Dec 2014, at 17:09, enygma <eny...@phpdeveloper.org> wrote:
>

> I started to take a stab at going through their dictionary and figuring out what values might work best in our context (and what doesn't really make sense to be included). Here's the list I came up with:
>
> 1. Title
> 2. Description of vulnerability
> 3. Product Name
> 4. Contact (email, probably)
> 5. Vulnerability release/publish date
> 6. Unique ID for the advisory
> 7. URL to reference more information about the issue
>
> Then in a "Vulnerability" sub-section (for human-readability, naturally):
>
> 1. Severity (from [low, medium, high])
> 2. CVE ID (optional)
> 3. CWE ID (optional)
> 4. Affected Version(s)

we should also include an optional fixed versions here I guess

regards,
Lukas