This document defines how security issues affecting heiFIP 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.

Security fixes are provided for supported releases only, beginning with the first production release v1.0.0

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: stefan.machmeier@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

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

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.

The following target times apply to supported versions and valid security reports. These targets are operational goals, not contractual guarantees.

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.

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.

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

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.

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

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

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

If no acknowledgement is received within the response target above, the report should be resent to:

• stefan.machmeier@uni-heidelberg.de

Urgent reports involving active exploitation or high-confidence compromise should use the subject line:

[URGENT SECURITY REPORT]

This policy should be reviewed whenever:

• Reporting channels change
• Supported versions change
• Incident response expectations change
• Disclosure commitments change

Last reviewed: 26-03-2026