Add Boefje and Normalizer models in the KATalogus

[Donnype]

Changes

Also see #2997 and the epic https://github.com/orgs/minvws/projects/7/views/33?pane=issue&itemId=60723200.

This adds the models, APIs and logic behind the following part of the new database schema:

classDiagram

class boefje {
    id
    plugin_id
    scan_level
    consumes
    produces
    version
    created
    description
    name
    environment_keys
    oci_image
    oci_arguments
}

class normalizer {
    id
    plugin_id
    scan_level
    consumes
    produces
    version
    created
    description
    name
    environment_keys
}

Loading

Some particular choices I faced where I decided myself how this should probably work, but are up for discussion:

• For local plugins, we can also add entries with the same id to overwrite these fields:
  • name
  • description
  • scan_level
  • oci_image
  • oci_arguments
• I removed unused fields such as options and authors for the time being.
• We now expose a static field to be able to differentiate between plugins that can be hard-deleted and the local plugins. For now it doesn't make sense to be able to be able to delete these local plugins, perhaps never. This field is not saved on a database level though since it can simply be configured when fetching the data. The editable-fields logic above makes sure that also for local plugins we overwrite this works well.

Issue link

Closes #2997

Demo

Although next PRs will showcase more functionality and the power in the frontend, one funny thing you could to to see that this works is go to the katalogus api and add a random plugin using the post endpoint:

To suddenly find a new entry in your KATalogus:

This entry is useless unless you configure a real oci_image pointing to a boefje image though.

---

Code Checklist

• All the commits in this PR are properly PGP-signed and verified.
• This PR only contains functionality relevant to the issue; tickets have been created for newly discovered issues.
• I have written unit tests for the changes or fixes I made.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have performed a self-review of my code and refactored it to the best of my abilities.

Communication

• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have made corresponding changes to the documentation, if necessary.
• 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]

Would it make sense to also include a path to a normalizer image? zip file / oci image or otherwise? And would it make sense to track the author? (eg, if this plugin was created by a local user, or (if null) comes from upstream?

I'd also guess that one of the things a user Might want to overwrite (without changing the actual oci_image) is the jsonschema that contains the settings their variant of the plugin consumes/reqiures

[ammar92]

Nice work. I do have a few remarks to improve it even more. Let me know what you think

[Donnype]

Would it make sense to also include a path to a normalizer image? zip file / oci image or otherwise? And would it make sense to track the author? (eg, if this plugin was created by a local user, or (if null) comes from upstream?

I'd also guess that one of the things a user Might want to overwrite (without changing the actual oci_image) is the jsonschema that contains the settings their variant of the plugin consumes/reqiures

Eventually, yes custom images make sense probably. Authors could make sense, although perhaps the first iterations could live without it, especially if authors could be inferred from the oci_image somehow. I also thought about the schema, since actually now there is not support for it for these kinds of boefjes. Perhaps we need to have a json schema field as well. Could be implemented once we tie the frontend and backend together and (probably) find out we need this, and then consider if we want to change the API with respect to the schema's?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[Donnype]

@underdarknl Follow up ticket: #3052

[ammar92]

Looks good to me 👍 I don't have any remarks anymore

[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:

Nothing obvious is broken. Performed scans against various targets which all seem to work as expected.

What doesn't work:

n/a

Bug or feature?:

n/a