Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature suggestion] Vulnerability custom fields #13

Open
noraj opened this issue Jun 19, 2022 · 0 comments
Open

[Feature suggestion] Vulnerability custom fields #13

noraj opened this issue Jun 19, 2022 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@noraj
Copy link

noraj commented Jun 19, 2022

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.

@mesquidar mesquidar self-assigned this Jun 20, 2022
@mesquidar mesquidar added the enhancement New feature or request label Jun 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants