Init to main (WIP)

[toelo3]

Add MVP main.

Contains:

• bootstrap to DSH
• Datastream info and functions to get info from it
• Config for rdkafka
• graceful shutdown handle
• Dead letter queue

To be added:

• github workflows
• examples folder on how to use stuff (examples are currently in API doc)

Note:

• Dead letter queue still requires some refactoring and alignment within the teams

[Arend-Jan]

Please add an example directory with some good examples

[Arend-Jan]

Please add a security policy. For now no garantees ofcourse, but that will reflect in the policy. here an example of a policy

Security Policy

Supported Versions

Use this section to tell people about which versions of your project are
currently being supported with security updates.

Version	Supported
5.1.x	✅
5.0.x	❌
4.0.x	✅
< 4.0	❌

Reporting a Vulnerability

Use this section to tell people how to report a vulnerability.

Tell them where to go, how often they can expect to get an update on a
reported vulnerability, what to expect if the vulnerability is accepted or
declined, etc.

---

To effectively manage the reporting of security vulnerabilities, your policy should provide clear, concise, and easy-to-follow instructions. Here's a structured approach to enhance the "Reporting a Vulnerability" section of your policy:

Contact Information

Dedicated Email: Provide a dedicated email address for reporting vulnerabilities, e.g., security@yourdomain.com. This should be a secure, monitored email.
Security Form: Optionally, include a link to a secure web form for reporting vulnerabilities.

Reporting Process

Details to Include: Request specific information to be included in the report, such as:

• Description of the vulnerability.
• Steps to reproduce the issue (if applicable).
• Potential impact assessment.
• Any additional information or context.

Response and Communication

Acknowledgment of Receipt: Mention that reporters should expect an acknowledgment email within a specified timeframe, e.g., 48 hours.
Updates Frequency: Indicate how often they can expect updates on the status of their report, e.g., weekly.
Confidentiality: Assure reporters that all reports will be handled confidentially and that their personal information will not be disclosed without consent.

Handling and Resolution

Investigation Process: Briefly outline the steps you will take upon receiving a report, such as initial assessment, investigation, and resolution planning.
Timeline for Resolution: Provide a general timeline for resolving reported vulnerabilities, though this may vary based on the complexity of the issue.
Credit and Recognition: If you offer credit or acknowledgments for reported vulnerabilities, mention how and where the credits will be given (e.g., in release notes or a hall of fame page).

Follow-Up

Feedback Loop: Encourage reporters to provide feedback on your handling of the vulnerability report.
Contact for Further Questions: Offer a point of contact for any follow-up questions regarding their report.
Example Policy Addition:

## Reporting a Vulnerability

To report a security vulnerability, please email us at security@yourdomain.com or use our secure [vulnerability reporting form](#). Include a detailed description of the vulnerability, steps to reproduce it, and any other relevant information.

We are committed to responding to all reports within 48 hours to acknowledge receipt. You can expect to receive regular updates about your report, typically on a weekly basis.

Your report will be kept confidential. Personal information provided in the report will not be disclosed without your consent. Our security team will investigate and work towards resolving the issue as swiftly as possible. We aim to resolve all vulnerabilities within a specific timeframe, though this can vary based on the severity and complexity of the issue.

We appreciate contributions to our security and, where appropriate, will offer credit in release notes or our hall of fame page. For any further questions or follow-up, please contact our security team at the same email address. Your feedback on our vulnerability handling process is always welcome.

This structured approach ensures clarity and encourages responsible vulnerability reporting, while also setting expectations for both the reporter and your team.