Format for the comments, bundle for vulnerability-lookup

[adulau]

Vulnerability-lookup will allow logged user (with validated account) and with type "commenter" or "admin" to create comment or bundle.

The format of the JSON foreseen (draft) is the following:

field name	values	type	required	description
uuid	UUID	uuid	X	UUIDv4 of the message
vulnerability-lookup-origin	UUID	uuid	X	UUIDv4 of the vulnerability lookup instance
creation_timestamp	datetime	datetime	X	When the message was created originally
timestamp	datetime	datetime	X	When the message was last updated
type	comment, bundle	string	X	Type of the message. Comment is a title, description text per vulnerability mentioned. Bundle is a bundle of vulnerabilities with title and a description text.
title	free text (limit? 65K?)	string	X	Title of the message
description	free text	string	-	Description of the message
description-format	markdown, text	string	-	Format of the description
vulnerability	array of vulnerability references	array	X	One or more vulnerability references for this message
meta	array of fields (like MISP galaxy)	array	-	Zero or more meta-fields

[cedricbonhomme]

Thank you for this !

As discussed here I focus on finishing the user management system (creation, management of accounts) with a simple case of submitting a new vulnerability. Just to not have a huge PR. It won't be small PR. But it will be ready soon. I'll make first a draft PR for it. And after we can add the comments in another PR.

[cedricbonhomme]

And since you raise the problem of 'type' of users, I would like to make clear the different roles we need for the moment.

To summarize, an authenticated user (not an admin) can have several roles/permissions ? For example:

• commenter (as you said)
• reporter (to submit/edit vulnerabilities) The user can be only commenter, only reporter, or both ? All is fine for me.

Or a same type of authenticated user (not admin) is able to comment and report, without distinction ?

[adulau]

The roles seen are the following:

• admin full access to everything including update of other comments or bundles or vulnerabilities
• commenter allow to create new comment or edit their own comments
• reporter is also a commenter but can also submit/edit vulnerabilities their own vulnerabilities

[cedricbonhomme]

Thanks for the information. I did the self-creation of accounts (creation by the admin was already done). The new user receives an email in order to verify the account. When the app is executed in debug mode, the email is simply written in a file. I will update the roles and permissions now.

[cedricbonhomme]

For the graphical interface I have something like this in mind.

Related vulnerabilities view, almost no change:

The new view for the comments/bundles:

It's just a draft.

[adulau]

Looks great! Maybe another tab for the bundles listing the reference if the vulnerability is referenced in a bundle.

[cedricbonhomme]

yep, indeed it's better.

[cedricbonhomme]

Should the admin of the platform review the comments before they get published ?

[adulau]

@cedricbonhomme That would be ideal (maybe to have it optional).

[cedricbonhomme]

The last version of the JSON schema is available here, @adulau. There are minor changes to what you proposed. But maybe we need some more updates.

Some suggestions/ideas/questions:

• should we make the description field required (it is not, even if you see it in the list of required fields) ? Only a title feels a bit strange on the Web page.
• here we have a list of vuln IDs (related vulnerabilities). Maybe this field should be a field to set the ID of the vuln related to the actual comment, not an array. And the list/array of vulns will be for related vulnerabilities, let's name it _relatedvulnerabilities.
• description-format field is not mandatory. As discussed we can set a default value, for example markdown. When a user is using the graphical Web interface, via the markdown editor, the value will be automatically set to markdown. And when the user is directly using the API, the user will have the possibility to set the value to text or markdown.

don't hesitate if you have feedback.

---

if you want to see the result with the markdown editor:

[adulau]

@cedricbonhomme Good point. The description field should be indeed mandatory. For the array of vulnerabilities, it was just if we wanted to have the same descriptions for many vulnerabilities.