[Feature] Custom findings

[daniel-cues]

Currently, if you want to add or remove fields from a finding, you'll need to change both the model and the corresponding templates. It would be nice if there was a way to add your own fields, or at the very least, that the templates generate themselves from the model in a dynamic way.

[chrismaddalena]

Thanks for the feedback! Something like this is on our road map for future enhancements. For the time being it is expected that you will tweak the model and templates (or repurpose fields) to match your preferred style.

I plan to revisit the findings and templating after we finish our current objectives (e.g. activity logging and API work). That will have a big impact on findings and templates, so it makes sense to revisit it once we have this done.

[noraj]

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 correctness (Easy, Complex, Project, etc.)
• Priority of correction (Low, Urgent, etc.)
• Impact Lelvel
• Any field asked by customer, standard, norm, etc.

So having a way add custom field to the finding model is very useful, for us it's the reason why with stay with PwnDoc even if it less powerful.

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.

@chrismaddalena Can you re-open this issue so it is tracked and not forgotten in closed issues please.

[chrismaddalena]

I like the idea of custom fields and appreciate the effort and thought displayed in your write-up, @noraj. As you've outlined, it's a little more complicated than just adding a field because you probably don't want to add and name a common custom field every time you make a finding. Off the cuff, there would need to be a few new features:

• Add a custom field to individual findings
• Add a custom field globally for all new and existing findings
• Support marking a custom field as required, unique, etc.
• Support bringing the custom fields into the reporting engine
• Support displaying the custom fields on the various webpages

At some point this would (ideally) allow you to customize views, like listing findings by your custom ID field vs. name.