Zeek & Domainator Integration

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,91 @@
+
+# Code of Conduct
+
+## Our Pledge
+
+We pledge to make our community welcoming, safe, and equitable for all.
+
+We are committed to fostering an environment that respects and promotes the dignity, rights, and contributions of all individuals, regardless of characteristics including race, ethnicity, caste, color, age, physical characteristics, neurodiversity, disability, sex or gender, gender identity or expression, sexual orientation, language, philosophy or religion, national or social origin, socio-economic position, level of education, or other status. The same privileges of participation are extended to everyone who participates in good faith and in accordance with this Covenant.
+
+## Encouraged Behaviors
+
+While acknowledging differences in social norms, we all strive to meet our community's expectations for positive behavior. We also understand that our words and actions may be interpreted differently than we intend based on culture, background, or native language.
+
+With these considerations in mind, we agree to behave mindfully toward each other and act in ways that center our shared values, including:
+
+1. Respecting the **purpose of our community**, our activities, and our ways of gathering.
+2. Engaging **kindly and honestly** with others.
+3. Respecting **different viewpoints** and experiences.
+4. **Taking responsibility** for our actions and contributions.
+5. Gracefully giving and accepting **constructive feedback**.
+6. Committing to **repairing harm** when it occurs.
+7. Behaving in other ways that promote and sustain the **well-being of our community**.
+
+
+## Restricted Behaviors
+
+We agree to restrict the following behaviors in our community. Instances, threats, and promotion of these behaviors are violations of this Code of Conduct.
+
+1. **Harassment.** Violating explicitly expressed boundaries or engaging in unnecessary personal attention after any clear request to stop.
+2. **Character attacks.** Making insulting, demeaning, or pejorative comments directed at a community member or group of people.
+3. **Stereotyping or discrimination.** Characterizing anyone’s personality or behavior on the basis of immutable identities or traits.
+4. **Sexualization.** Behaving in a way that would generally be considered inappropriately intimate in the context or purpose of the community.
+5. **Violating confidentiality**. Sharing or acting on someone's personal or private information without their permission.
+6. **Endangerment.** Causing, encouraging, or threatening violence or other harm toward any person or group.
+7. Behaving in other ways that **threaten the well-being** of our community.
+
+### Other Restrictions
+
+1. **Misleading identity.** Impersonating someone else for any reason, or pretending to be someone else to evade enforcement actions.
+2. **Failing to credit sources.** Not properly crediting the sources of content you contribute.
+3. **Promotional materials**. Sharing marketing or other commercial content in a way that is outside the norms of the community.
+4. **Irresponsible communication.** Failing to responsibly present content which includes, links or describes any other restricted behaviors.
+
+
+## Reporting an Issue
+
+Tensions can occur between community members even when they are trying their best to collaborate. Not every conflict represents a code of conduct violation, and this Code of Conduct reinforces encouraged behaviors and norms that can help avoid conflicts and minimize harm.
+
+When an incident does occur, it is important to report it promptly. To report a possible violation, **contact us via mail at stefan.machmeier@uni-heidelberg.de & maximilian.ludwig@uni-heidelberg.de.**
+
+Community Moderators take reports of violations seriously and will make every effort to respond in a timely manner. They will investigate all reports of code of conduct violations, reviewing messages, logs, and recordings, or interviewing witnesses and other participants. Community Moderators will keep investigation and enforcement actions as transparent as possible while prioritizing safety and confidentiality. In order to honor these values, enforcement actions are carried out in private with the involved parties, but communicating to the whole community may be part of a mutually agreed upon resolution.
+
+
+## Addressing and Repairing Harm
+
+****
+
+If an investigation by the Community Moderators finds that this Code of Conduct has been violated, the following enforcement ladder may be used to determine how best to repair harm, based on the incident's impact on the individuals involved and the community as a whole. Depending on the severity of a violation, lower rungs on the ladder may be skipped.
+
+1) Warning
+   1) Event: A violation involving a single incident or series of incidents.
+   2) Consequence: A private, written warning from the Community Moderators.
+   3) Repair: Examples of repair include a private written apology, acknowledgement of responsibility, and seeking clarification on expectations.
+2) Temporarily Limited Activities
+   1) Event: A repeated incidence of a violation that previously resulted in a warning, or the first incidence of a more serious violation.
+   2) Consequence: A private, written warning with a time-limited cooldown period designed to underscore the seriousness of the situation and give the community members involved time to process the incident. The cooldown period may be limited to particular communication channels or interactions with particular community members.
+   3) Repair: Examples of repair may include making an apology, using the cooldown period to reflect on actions and impact, and being thoughtful about re-entering community spaces after the period is over.
+3) Temporary Suspension
+   1) Event: A pattern of repeated violation which the Community Moderators have tried to address with warnings, or a single serious violation.
+   2) Consequence: A private written warning with conditions for return from suspension. In general, temporary suspensions give the person being suspended time to reflect upon their behavior and possible corrective actions.
+   3) Repair: Examples of repair include respecting the spirit of the suspension, meeting the specified conditions for return, and being thoughtful about how to reintegrate with the community when the suspension is lifted.
+4) Permanent Ban
+   1) Event: A pattern of repeated code of conduct violations that other steps on the ladder have failed to resolve, or a violation so serious that the Community Moderators determine there is no way to keep the community safe with this person as a member.
+   2) Consequence: Access to all community spaces, tools, and communication channels is removed. In general, permanent bans should be rarely used, should have strong reasoning behind them, and should only be resorted to if working through other remedies has failed to change the behavior.
+   3) Repair: There is no possible repair in cases of this severity.
+
+This enforcement ladder is intended as a guideline. It does not limit the ability of Community Managers to use their discretion and judgment, in keeping with the best interests of our community.
+
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public or other spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 3.0, permanently available at [https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).
+
+Contributor Covenant is stewarded by the Organization for Ethical Source and licensed under CC BY-SA 4.0. To view a copy of this license, visit [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
+
+For answers to common questions about Contributor Covenant, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are provided at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). Additional enforcement and community guideline resources can be found at [https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources). The enforcement ladder was inspired by the work of [Mozilla’s code of conduct team](https://github.com/mozilla/inclusion).

.github/SECURITY.md

@@ -0,0 +1,223 @@
+# Security Policy
+
+## Purpose
+
+This document defines how security issues affecting the python release of `Hamstring` must be reported, handled, remediated, and disclosed. The goal is to ensure that security-relevant findings are managed confidentially, triaged consistently, and resolved within appropriate operational timelines.
+
+## Supported Versions
+
+Security fixes are provided for the latest released major version.
+
+| Version | Supported |
+| ------- | --------- |
+| `main` / latest release | Yes |
+| Previous minor release | Yes |
+| Older releases | No |
+
+## Confidential Reporting
+
+Security issues must be reported through confidential channels only. Public
+GitHub issues, public pull requests, or other public forums must not be used
+for reporting vulnerabilities.
+
+Approved reporting channels:
+
+- GitHub Private Vulnerability Reporting / Security Advisories
+- Email: `pm300@uni-heidelberg.de`
+
+Reports should include, where available:
+
+- A concise description of the issue
+- Affected component, endpoint, container, or workflow
+- Reproduction steps or validation details
+- Expected impact and potential exploitation scenario
+- Affected version, branch, commit, or image tag
+- Relevant logs, screenshots, request samples, or proof-of-concept material
+- Whether the issue appears actively exploited or time-sensitive
+
+## Confidentiality Requirements
+
+All reported security issues are handled as confidential until review is
+complete and a coordinated disclosure decision has been made.
+
+During this period:
+
+- Issue details must not be disclosed publicly
+- Sensitive technical details must be shared only on a need-to-know basis
+- Access to internal discussion, remediation branches, and advisory drafts
+  should be restricted
+- If there is evidence of active exploitation, internal escalation should occur
+  immediately
+
+## Intake and Triage
+
+Each report is reviewed to determine:
+
+- Whether the issue is reproducible
+- Whether it affects a supported version
+- Whether there is a meaningful confidentiality, integrity, or availability impact
+- Whether exploitation requires special conditions or privileged access
+- Whether the issue represents active exploitation, a misconfiguration, or a
+  theoretical weakness without practical impact
+
+Severity should be classified as `Critical / High / Medium / Low`.
+
+## Response Targets
+
+The following target times apply to supported versions and valid security
+reports. These targets are operational goals, not contractual guarantees.
+
+| Stage | Target |
+| ----- | ------ |
+| Initial acknowledgement | Within 2 business days |
+| Initial triage decision | Within 5 business days |
+| First remediation update | Within 7 calendar days |
+| Ongoing status updates | At least every 7 calendar days |
+| Critical issue remediation plan | Within 7 calendar days |
+| High severity remediation plan | Within 14 calendar days |
+| Medium severity remediation plan | Within 30 calendar days |
+| Low severity remediation plan | Best effort |
+
+If a report indicates active exploitation, credential exposure, remote code
+execution, or broad unauthorized access, the issue should be escalated as an
+incident and handled with priority outside normal backlog processes.
+
+## Remediation Process
+
+When a security issue is confirmed, maintainers should:
+
+- Reproduce and validate the issue
+- Define affected versions and deployment scenarios
+- Prepare a remediation plan proportional to the severity
+- Implement and review the fix
+- Backport the fix to supported versions where feasible
+- Validate the fix before release
+- Prepare customer-facing or operator-facing guidance if configuration or
+  operational action is required
+
+Where immediate remediation is not possible, temporary mitigations should be
+documented and communicated clearly.
+
+## Disclosure and Publication
+
+Confirmed vulnerabilities are disclosed in a coordinated manner after one of
+the following conditions is met:
+
+- A fix has been released
+- A mitigation has been published and the residual risk is understood
+- A disclosure deadline has been reached and leadership approves publication
+
+The default disclosure target is `90 days`, but the actual window may be
+shortened or extended based on:
+
+- Evidence of exploitation
+- Fix availability and deployment risk
+- Customer exposure
+- Dependency or vendor coordination needs
+
+Public disclosures may include:
+
+- A security advisory
+- Release notes
+- Upgrade or mitigation instructions
+- Severity and affected-version information
+
+## Operational Communication
+
+Where a confirmed issue affects deployed environments, communication should be
+proportionate to impact. This may include:
+
+- Internal security or operations escalation
+- Notification to administrators, customers, or service owners
+- Temporary mitigation guidance
+- Required upgrade or rotation steps
+- Post-remediation confirmation and closure
+
+Security communications should avoid unnecessary disclosure of exploit details
+before mitigations are available.
+
+## Scope
+
+The following areas are considered in scope for security handling:
+
+- Authentication and authorization controls
+- Password handling and account lifecycle
+- File upload, parsing, and processing pipelines
+- Secrets handling and environment configuration
+- Data access controls and audit logging
+- Container, service, and network configuration
+- Dependency vulnerabilities with validated product impact
+- Sensitive data exposure, privilege escalation, SSRF, RCE, injection, and
+  broken access control
+
+## Out of Scope
+
+The following are generally not treated as security vulnerabilities unless
+clear and demonstrated security impact exists:
+
+- Cosmetic misconfigurations without exploitability
+- Missing hardening headers without a practical attack path
+- Issues affecting unsupported or end-of-life releases only
+- Hypothetical findings without reproducible impact
+- Third-party platform issues outside the control of this project
+- Reports based only on scanner output without technical validation
+
+## Safe Handling Expectations
+
+Anyone validating a suspected issue is expected to act in a controlled and
+minimal manner.
+
+Expected behavior:
+
+- Limit activity to what is necessary to confirm the issue
+- Avoid unauthorized access to non-public or third-party data
+- Avoid disruption of production systems
+- Avoid persistence, data modification, or data destruction
+- Stop testing and report promptly once the issue is confirmed
+
+This policy does not authorize:
+
+- Access to data belonging to other users or organizations
+- Service disruption or denial-of-service activity
+- Data exfiltration or retention of sensitive information
+- Any activity that violates applicable law or contractual obligations
+
+## Security Updates
+
+Security fixes may be distributed through one or more of the following:
+
+- Normal release process
+- Out-of-band patch release
+- Security advisory
+- Operational mitigation notice
+
+Where appropriate, the published update should include:
+
+- Affected versions
+- Fixed versions
+- Severity
+- Upgrade path
+- Required operational actions
+
+## Escalation
+
+If no acknowledgement is received within the response target above, the report
+should be resent to:
+
+- `pm300@uni-heidelberg.de`
+
+Urgent reports involving active exploitation or high-confidence compromise
+should use the subject line:
+
+`[URGENT SECURITY REPORT]`
+
+## Policy Maintenance
+
+This policy should be reviewed whenever:
+
+- Reporting channels change
+- Supported versions change
+- Incident response expectations change
+- Disclosure commitments change
+
+Last reviewed: `27-03-2026`