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
Starting this year, I’m going to endeavor to create a community update every quarter (aka every 3 months) throughout the year. I’m going to call this my first update for 2024 so there will be at least 3 more after this. Exact timing is TBD and we’ll figure that out as we go forward.
2024-Q1 DefectDojo Updates
There are two topics in this update.
Upcoming Deprecations
As part of our continuing effort to drive up the quality of DefectDojo, we’re going to be deprecating some formerly supported technology options. The following options will no longer be supported by DefectDojo:
MySQL as the database for DefectDojo
RabbitMQ as a message broker for DefectDojo
Testing PostgreSQL HA as part of our Github Actions - see here
Timeline:
MySQL and RabbitMQ will be deprecated and no longer supported as of July 1st, 2024
PostgreSQL HA testing will be removed in the 2.33.0 release (April 2024)
What this means to people using MySQL currently:
DefectDojo stores the bulk of its data in the database so this will need to be migrated
You will need to move from using MySQL with DefectDojo to PostgreSQL prior to July 1st to remain on a tested and supported option
There’s already been discussions about migrating from MySQL to DefectDojo which provide options, Pros and Cons and other considerations
This will be a one-time event
For those running older versions of DefectDojo, it’s advisable to move to as close to the most recent version as possible prior to migrating. If for no other reason but to keep the scope of change as small as possible.
What this means to people using RabbitMQ currently:
DefectDojo through Celery uses RabbitMQ and Redis to hold queued work items
Since these are async items, durable, long term storage of them is not required
Migration will consist of changing the configured from RabbitMQ to Redis - mostly the DD_CELERY_* settings especially the DD_CELERY_BROKER_SCHEME
What will happen after July 1st, 2024?
Once the transition period is over, the following will happen:
MySQL and RabbitMQ specific tests in Github Actions will be retired. This should cut the time to run GH Actions roughly in half. 🎉
The existing reference docker-compose configurations in the repo will have the MySQL and RabbitMQ options removed also greatly simplifying the yaml configs. 🎉
After several releases, we’ll remove the Python libraries required by MySQL and RabbitMQ. Dockerfiles will also have those dependencies removed. 👋
All of these are obviously ‘to be created’ PRs which won’t be submitted until after the deprecation
New Guidelines on Parsers, especially multi-parsers
Recently, more and different types of security tools are being offered by the same vendor. While it seems like the natural thing to do is to create a ‘multi-parser’ to handle all the formats at once, this can lead to some problems:
Parsers become harder to debug
Unit tests for parsers become more complicated
Creating a dedup algorithm for multiple tool types becomes difficult to impossible
Going forward, we will not accept PRs which are muti-parsers. 🚫
So, what’s a multi-parser?
A parser written to handle more than one type of security scanner from a single vendor
e.g. Snyk provides SCA, SAST and Container scans - a multi-parser would attempt to parse the outputs from 2+ of these tools in one parser (aka Test_Type in DefectDojo)
Are there any exceptions to this new guideline?
Yes, if a tool happens to produce more than one file format, a single parser to handle that may be accepted if:
The type of security scanner isn’t different for the different file formats
Each of the file formats is handled separately in separate helper methods to increase visibility of what code is handling which format
An example of this is supporting Fortify .xml and .fpr files in a single parser since both are file exports from the same type of security scanner (SAST)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
DefectDojo Community members,
Starting this year, I’m going to endeavor to create a community update every quarter (aka every 3 months) throughout the year. I’m going to call this my first update for 2024 so there will be at least 3 more after this. Exact timing is TBD and we’ll figure that out as we go forward.
2024-Q1 DefectDojo Updates
There are two topics in this update.
Upcoming Deprecations
As part of our continuing effort to drive up the quality of DefectDojo, we’re going to be deprecating some formerly supported technology options. The following options will no longer be supported by DefectDojo:
Timeline:
What this means to people using MySQL currently:
What this means to people using RabbitMQ currently:
What will happen after July 1st, 2024?
Once the transition period is over, the following will happen:
All of these are obviously ‘to be created’ PRs which won’t be submitted until after the deprecation
New Guidelines on Parsers, especially multi-parsers
Recently, more and different types of security tools are being offered by the same vendor. While it seems like the natural thing to do is to create a ‘multi-parser’ to handle all the formats at once, this can lead to some problems:
Going forward, we will not accept PRs which are muti-parsers. 🚫
So, what’s a multi-parser?
Are there any exceptions to this new guideline?
Look for a PR to update “How to write a parser” shortly as well.
That’s all I have for 2024-Q1. 🥂
Beta Was this translation helpful? Give feedback.
All reactions