You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The vulnerability have a decent amount of default fields (remediation, pboservation/poc, description, impact, some metrics, etc.) but it could be nice to have the ability to create custom ones.
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.
The findings/vulnerabilities database is powerful but is lacking of custom fields.
Examples of fields used in pentest report that are not available in the finding model that could be added as custom fields :
CVSS score and/or CVSS string
CWE
OWASP category, or any customer category
ID (a unique identifier or reference)
Ease of exploitation
Impact Level
Any field asked by customer, standard, norm, etc.
So having a way add custom field to the finding model is very useful.
In additions to custom fields, having several types of custom field would be nice, input (eg. as title), dictionary (eg. like severity), free text (eg. like description). Also some fields like a custom ID or reference would need a search feature, eg. if you want to assign an internal reference to all findings like INF-00234, WEB-00678, etc. you would like to have a search bar to see that you have already used all ID from WEB-00001 to WEB-00678, so you can create WEB-00679. Some field would also need a uniq switch, eg. CVSS score is not unique but the ID/ref must be.
Once you have several custom fields you also would like to display them in the finding library, it means be able to add columns on the table view (eg. you'd like to add a ref/ID column or CWE, etc.).
Finally, the most important part is being able to have the custom fields available in the template, for this reason I think custom fields name should be enforced to be unique and with only alphanumeric characters + space so it's easy to get {{ finding.cvss_score }} for example.
PwnDoc is a similar project with Custom field enabled if you need an idea of architecture.
The text was updated successfully, but these errors were encountered:
The vulnerability have a decent amount of default fields (remediation, pboservation/poc, description, impact, some metrics, etc.) but it could be nice to have the ability to create custom ones.
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.
The findings/vulnerabilities database is powerful but is lacking of custom fields.
Examples of fields used in pentest report that are not available in the finding model that could be added as custom fields :
So having a way add custom field to the finding model is very useful.
In additions to custom fields, having several types of custom field would be nice, input (eg. as title), dictionary (eg. like severity), free text (eg. like description). Also some fields like a custom ID or reference would need a search feature, eg. if you want to assign an internal reference to all findings like INF-00234, WEB-00678, etc. you would like to have a search bar to see that you have already used all ID from WEB-00001 to WEB-00678, so you can create WEB-00679. Some field would also need a uniq switch, eg. CVSS score is not unique but the ID/ref must be.
Once you have several custom fields you also would like to display them in the finding library, it means be able to add columns on the table view (eg. you'd like to add a ref/ID column or CWE, etc.).
Finally, the most important part is being able to have the custom fields available in the template, for this reason I think custom fields name should be enforced to be unique and with only alphanumeric characters + space so it's easy to get
{{ finding.cvss_score }}
for example.PwnDoc is a similar project with Custom field enabled if you need an idea of architecture.
The text was updated successfully, but these errors were encountered: