description
The description field is mean to describe what the vulnerability is in general, explaining what a XSS or SQLi is, similar to what you would find on wikipedia or OWASP pages.
This field is already present in reconmap.
remediation
The remediation field is to explain to the client how he will be able to patch / fix / workaround / remediate the vulnerability.
The field is already present in reconmap under the name solution.
remediation complexity & remediation priority
The remediation complexity is to give an estimation to the client of how complex it will be to remediate the vulnerability.
Complexity levels:
The remediation priority is to give an estimation to the client of how quick he should remediate the vulnerability (not only based on the criticality / risk but also some legal constraints, etc.).
priority levels:
observation
The observation field is meant to actually explain what was found by the auditors, to give some proves (screenshots, tools output, etc.), and to explain how the vulnerability behave in this specific case, what are the risk for the project. A code analogy: the description is the class and the observation is the instance. It's the explanation of the vulnerability contextualized to the project.
It's already existing and it's split between the Proof of concept and the Impact fields.
references
The references field is meant to store links to external references as well as a brief description, like a bibliography.
Examples: link to the CVE advisories, link to the OWASP remediation cheat sheet, software vendor documentation, etc.
This can be used for the description, observation, remediation.
##vulnerability ID or reference
The vulnerability ID or reference is a unique identifier for the vulnerability. All manufacturers and constructors have a reference for each product, web retailers have a reference for the stuff they are selling etc. The vulnerability ID is a reference for vulnerabilities.
Eg. Using company name abbreviation: CMP-001, CMP-002 etc. or using a prefix by category WEB-001 for web vulnerabilities, INF-001 for infrastructure vulnerabilities, etc.
So when a client ask question about a vuln you just have to ask him the vuln ID to know what he talk about, or if two auditors in a team are talking about a vuln giving the vuln ID is easier than giving the title and there is less confusion (imagine you have a stored XSS vuln and a reflected XSS vuln, just saying XSS you don't know which one you are talking about while giving the reference you are sure about which one it is).
update: it's now External ID
vuln category
It'll talk more about it in a separate issue. #49
custom fields
The precedent fields are the ones that I think should be present by default, but having the possibility to define custom fields would be great for teams having custom uncommon needs.
description
The description field is mean to describe what the vulnerability is in general, explaining what a XSS or SQLi is, similar to what you would find on wikipedia or OWASP pages.
This field is already present in reconmap.
remediation
The remediation field is to explain to the client how he will be able to patch / fix / workaround / remediate the vulnerability.
The field is already present in reconmap under the name solution.
remediation complexity & remediation priority
The remediation complexity is to give an estimation to the client of how complex it will be to remediate the vulnerability.
Complexity levels:
The remediation priority is to give an estimation to the client of how quick he should remediate the vulnerability (not only based on the criticality / risk but also some legal constraints, etc.).
priority levels:
observation
The observation field is meant to actually explain what was found by the auditors, to give some proves (screenshots, tools output, etc.), and to explain how the vulnerability behave in this specific case, what are the risk for the project. A code analogy: the description is the class and the observation is the instance. It's the explanation of the vulnerability contextualized to the project.
It's already existing and it's split between the
Proof of conceptand theImpactfields.references
The references field is meant to store links to external references as well as a brief description, like a bibliography.
Examples: link to the CVE advisories, link to the OWASP remediation cheat sheet, software vendor documentation, etc.
This can be used for the description, observation, remediation.
##vulnerability ID or reference
The vulnerability ID or reference is a unique identifier for the vulnerability. All manufacturers and constructors have a reference for each product, web retailers have a reference for the stuff they are selling etc. The vulnerability ID is a reference for vulnerabilities.
Eg. Using company name abbreviation: CMP-001, CMP-002 etc. or using a prefix by category WEB-001 for web vulnerabilities, INF-001 for infrastructure vulnerabilities, etc.
So when a client ask question about a vuln you just have to ask him the vuln ID to know what he talk about, or if two auditors in a team are talking about a vuln giving the vuln ID is easier than giving the title and there is less confusion (imagine you have a stored XSS vuln and a reflected XSS vuln, just saying XSS you don't know which one you are talking about while giving the reference you are sure about which one it is).
update: it's now
External IDvuln category
It'll talk more about it in a separate issue. #49
custom fields
The precedent fields are the ones that I think should be present by default, but having the possibility to define custom fields would be great for teams having custom uncommon needs.