Set default findingtype risk in model instead of in bit

[noamblitz]

Changes

Set default findingtype risk in model instead of in bit

Demo

No functional changes

QA notes

Turn of kat-finding-types boefje
Create Hostname with L1
See that finding types appear
Make sure that they are "Pending"
Make sure that no reports are broken with these FindingTypes

Also check with migrations: do the same as above in main and then switch to this branch and "make" again. Rerun bits. Everything should still work

Code Checklist

• All the commits in this PR are properly PGP-signed and verified.
• This PR only contains functionality relevant to the issue.
• I have written unit tests for the changes or fixes I made.
• I have checked the documentation and made changes where necessary.
• I have performed a self-review of my code and refactored it to the best of my abilities.

• Tickets have been created for newly discovered issues.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have included comments in the code to elaborate on what is not self-evident from the code itself, including references to issues and discussions online, or implicit behavior of an interface.

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

[underdarknl]

Hmm, can we still store an 'unknown' severity for findings that we could not hydrate / have no information due to an embargo?
We opted to communicate findings with an unknown severity as being 'critical' due to the nature of embargoed findings. If we change the default to 0.0, they wont be communicated as critical anymore I'd guess?

[noamblitz]

Before, the default was unset and immediately after creation, the bit would set it to 0.0. In the time between creating the finding and setting the value to 0.0, the finding would be invisible (this would be very very short/ unnoticeable). This behavior is now better.

After a while, the boefje would try to find the score, if it didn't succeed, it would set the value to 10.0. This behavior is unchanged.

[ammar92]

Just one question to confirm. Looks good otherwise

[stephanie0x00]

Checklist for QA:

• I have checked out this branch, and successfully ran a fresh make reset.
• I confirmed that there are no unintended functional regressions in this branch:
  • I have managed to pass the onboarding flow
  • Objects and Findings are created properly
  • Tasks are created and completed properly
• I confirmed that the PR's advertised feature or hotfix works as intended.
• I checked the logs for errors and/or warnings and made issues where necessary

What works:

Seems to work as described from what I can see. Couldn't find any obvious regression. Tried both a migration scenario and tested on a clean branch. The findings are Pending and they are resumed when I enable the Kat finding types boefje. Reports can be generated.

What doesn't work:

n/a

Bug or feature?:

n/a