Notifications: Add support for webhooks

[kiblik]

We would like to do an implementation similar to this: https://docs.gitlab.com/ee/user/project/integrations/webhooks.html

Events will be published via notifications

The whole functionality is described in the documentation section. This is an image which is rendered by mermaid

[Maffooch]

@kiblik this is looking really interesting so far. The only critique I have thus far is that it appears there is only support for one web hook at a time. I think it would be good to allow for an arbitrary amount of web hooks. Sorta like how the Jira integration works where you can connect an arbitrary amount of Jira servers and push to them according to how they are configured.

[kiblik]

@Maffooch, thank you for the feedback. I can add management of multiple webhook endpoints.

Btw, what do you think about User notifications? Do they make sense to you? They are disabled for MS Teams.

Or the combination of your idea and my question: One endpoint System notification endpoint and each user will be able to define his/her/they own endpoint.

[Maffooch]

I would think adding a web hook url would require a higher permission (I think maintainer would be sufficient) so adding user levels would be a little redundant.

[kiblik]

I would think adding a web hook url would require a higher permission (I think maintainer would be sufficient) so adding user levels would be a little redundant.

@Maffooch, we see a possible use case when the user should be able to define his own endpoint. What about this:

• add user = ForeignKey(Dojo_User, null=True, blank=True) to Webhook_Endpoints
• regular user is able to create an endpoint assigned only to himself
• high-privileged user is able to assign an endpoint to anybody and also to nobody
• if it will be assigned to the user, user notifications will be processed/send (the user will also define from which products he/she/they would like to receive notifications)
• if it will not be assigned to the user, system notifications will be processed/send

[Maffooch]

I think that sounds reasonable

[Maffooch]

Hey @kiblik how are things going on this? Can I be of any help on this PR (or any of your others)?

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[kiblik]

Hey @kiblik how are things going on this? Can I be of any help on this PR (or any of your others)?

So, my priorities were on the other tasks recently but I had planned to come back to this functionality during the next week.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[nibiwodong]

Add support for webhooks is really a useful function. Looking forward to releasing this feature

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[rkg-mm]

Is it possible to say when this will be available? We would like to have a 2-way sync for Dependency-Track tool, which so far only supports from DT into DD. The Webhook would be a great way to implement this without touching DD code. https://github.com/DependencyTrack/dependency-track/issues/1926

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[Maffooch]

Hey @kiblik i'v been seeing you pick this one up from time to time. How are things going on it?

[kiblik]

Hey @kiblik i'v been seeing you pick this one up from time to time. How are things going on it?

Hi @Maffooch. Well, every time, when I wanted to continue with implementation, some other priority came in the way. However, I was able to check it again this week and that is the reason why I asked also related questions. Now, I should be able to come back and focus on it during the following 2 or 3 weeks.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[dryrunsecurity[bot]]

Contextual Security Analysis

As DryRun Security performs checks, we’ll summarize them here. You can always dive into the detailed results in the section below for checks.

Status	DryRun Security Check
✅	AI-powered Sensitive Function Check
❌	Configured Sensitive Files Check
✅	AI-powered Sensitive Files Check

Chat with your AI-powered Security Buddy by typing @dryrunsecurity followed by your question into a comment. Example: @dryrunsecurity What are common security issues with web application cookies?

Install and configure more repositories at DryRun Security

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[dryrunsecurity[bot]]

Hi there :wave:, @dryrunsecurity here, below is a summary of our analysis and findings.

DryRun Security	Status	Findings
Server-Side Request Forgery Analyzer	:white_check_mark:	0 findings
Configured Codepaths Analyzer	:white_check_mark:	0 findings
IDOR Analyzer	:white_check_mark:	0 findings
Sensitive Files Analyzer	:grey_exclamation:	1 finding
SQL Injection Analyzer	:white_check_mark:	0 findings
Authn/Authz Analyzer	:grey_exclamation:	13 findings
Secrets Analyzer	:white_check_mark:	0 findings

[!Note] :green_circle: Risk threshold not exceeded.

Change Summary (click to expand)

The following is a summary of changes in this pull request made by me, your security buddy :robot:. Note that this summary is auto-generated and not meant to be a definitive list of security issues but rather a helpful summary from a security perspective.

Summary:

The provided code changes cover a wide range of updates to the DefectDojo application, with a significant focus on the introduction of a new notification webhook feature. The key security considerations across these changes include:

1. Webhook Security: The new webhook functionality introduces a new attack surface that needs to be carefully reviewed and secured. This includes implementing proper input validation, authorization, and secure communication when interacting with external webhook endpoints.

2. Permissions and Access Control: The code changes indicate that the webhook management functionality is restricted to superusers or users with specific permissions. It's important to ensure that these access controls are properly implemented and maintained.

3. Logging and Monitoring: The application should have robust logging and monitoring mechanisms in place to track webhook-related activities, including any suspicious or unauthorized access attempts.

4. Secure Configuration Management: The changes include updates to various configuration files, such as environment variables and settings. It's crucial to ensure that these configurations do not expose any sensitive information and are properly secured.

5. Secure Coding Practices: Throughout the code changes, there are recommendations to follow secure coding practices, such as input validation, sanitization, and secure communication, to mitigate common web application vulnerabilities.

Files Changed:

1. Docker Compose Configuration Files: The changes in these files introduce a new "webhook.endpoint" service, which should be carefully reviewed to ensure that it is not exposed to the public internet and that the implementation is secure.

2. Documentation Files: The documentation updates cover various features, including the new webhook notification functionality, rate limiting, and the deprecation of the Burp plugin. These changes should be reviewed to ensure that the documentation accurately reflects the current security posture of the application.

3. Application Code Files: The majority of the changes are in the application code, particularly related to the implementation of the new webhook notification feature. These changes should be thoroughly reviewed to ensure that the feature is implemented securely and follows best practices for application security.

Overall, the code changes appear to be focused on enhancing the DefectDojo application's functionality, with a particular emphasis on the new webhook notification feature. As an application security engineer, it's crucial to review these changes carefully and ensure that the implementation follows secure coding practices and does not introduce any new vulnerabilities.

Powered by DryRun Security

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.