|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +## Purpose |
| 4 | + |
| 5 | +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. |
| 6 | + |
| 7 | +## Supported Versions |
| 8 | + |
| 9 | +Security fixes are provided for the latest released major version. |
| 10 | + |
| 11 | +| Version | Supported | |
| 12 | +| ------- | --------- | |
| 13 | +| `main` / latest release | Yes | |
| 14 | +| Previous minor release | Yes | |
| 15 | +| Older releases | No | |
| 16 | + |
| 17 | +## Confidential Reporting |
| 18 | + |
| 19 | +Security issues must be reported through confidential channels only. Public |
| 20 | +GitHub issues, public pull requests, or other public forums must not be used |
| 21 | +for reporting vulnerabilities. |
| 22 | + |
| 23 | +Approved reporting channels: |
| 24 | + |
| 25 | +- GitHub Private Vulnerability Reporting / Security Advisories |
| 26 | +- Email: `pm300@uni-heidelberg.de` |
| 27 | + |
| 28 | +Reports should include, where available: |
| 29 | + |
| 30 | +- A concise description of the issue |
| 31 | +- Affected component, endpoint, container, or workflow |
| 32 | +- Reproduction steps or validation details |
| 33 | +- Expected impact and potential exploitation scenario |
| 34 | +- Affected version, branch, commit, or image tag |
| 35 | +- Relevant logs, screenshots, request samples, or proof-of-concept material |
| 36 | +- Whether the issue appears actively exploited or time-sensitive |
| 37 | + |
| 38 | +## Confidentiality Requirements |
| 39 | + |
| 40 | +All reported security issues are handled as confidential until review is |
| 41 | +complete and a coordinated disclosure decision has been made. |
| 42 | + |
| 43 | +During this period: |
| 44 | + |
| 45 | +- Issue details must not be disclosed publicly |
| 46 | +- Sensitive technical details must be shared only on a need-to-know basis |
| 47 | +- Access to internal discussion, remediation branches, and advisory drafts |
| 48 | + should be restricted |
| 49 | +- If there is evidence of active exploitation, internal escalation should occur |
| 50 | + immediately |
| 51 | + |
| 52 | +## Intake and Triage |
| 53 | + |
| 54 | +Each report is reviewed to determine: |
| 55 | + |
| 56 | +- Whether the issue is reproducible |
| 57 | +- Whether it affects a supported version |
| 58 | +- Whether there is a meaningful confidentiality, integrity, or availability impact |
| 59 | +- Whether exploitation requires special conditions or privileged access |
| 60 | +- Whether the issue represents active exploitation, a misconfiguration, or a |
| 61 | + theoretical weakness without practical impact |
| 62 | + |
| 63 | +Severity should be classified as `Critical / High / Medium / Low`. |
| 64 | + |
| 65 | +## Response Targets |
| 66 | + |
| 67 | +The following target times apply to supported versions and valid security |
| 68 | +reports. These targets are operational goals, not contractual guarantees. |
| 69 | + |
| 70 | +| Stage | Target | |
| 71 | +| ----- | ------ | |
| 72 | +| Initial acknowledgement | Within 2 business days | |
| 73 | +| Initial triage decision | Within 5 business days | |
| 74 | +| First remediation update | Within 7 calendar days | |
| 75 | +| Ongoing status updates | At least every 7 calendar days | |
| 76 | +| Critical issue remediation plan | Within 7 calendar days | |
| 77 | +| High severity remediation plan | Within 14 calendar days | |
| 78 | +| Medium severity remediation plan | Within 30 calendar days | |
| 79 | +| Low severity remediation plan | Best effort | |
| 80 | + |
| 81 | +If a report indicates active exploitation, credential exposure, remote code |
| 82 | +execution, or broad unauthorized access, the issue should be escalated as an |
| 83 | +incident and handled with priority outside normal backlog processes. |
| 84 | + |
| 85 | +## Remediation Process |
| 86 | + |
| 87 | +When a security issue is confirmed, maintainers should: |
| 88 | + |
| 89 | +- Reproduce and validate the issue |
| 90 | +- Define affected versions and deployment scenarios |
| 91 | +- Prepare a remediation plan proportional to the severity |
| 92 | +- Implement and review the fix |
| 93 | +- Backport the fix to supported versions where feasible |
| 94 | +- Validate the fix before release |
| 95 | +- Prepare customer-facing or operator-facing guidance if configuration or |
| 96 | + operational action is required |
| 97 | + |
| 98 | +Where immediate remediation is not possible, temporary mitigations should be |
| 99 | +documented and communicated clearly. |
| 100 | + |
| 101 | +## Disclosure and Publication |
| 102 | + |
| 103 | +Confirmed vulnerabilities are disclosed in a coordinated manner after one of |
| 104 | +the following conditions is met: |
| 105 | + |
| 106 | +- A fix has been released |
| 107 | +- A mitigation has been published and the residual risk is understood |
| 108 | +- A disclosure deadline has been reached and leadership approves publication |
| 109 | + |
| 110 | +The default disclosure target is `90 days`, but the actual window may be |
| 111 | +shortened or extended based on: |
| 112 | + |
| 113 | +- Evidence of exploitation |
| 114 | +- Fix availability and deployment risk |
| 115 | +- Customer exposure |
| 116 | +- Dependency or vendor coordination needs |
| 117 | + |
| 118 | +Public disclosures may include: |
| 119 | + |
| 120 | +- A security advisory |
| 121 | +- Release notes |
| 122 | +- Upgrade or mitigation instructions |
| 123 | +- Severity and affected-version information |
| 124 | + |
| 125 | +## Operational Communication |
| 126 | + |
| 127 | +Where a confirmed issue affects deployed environments, communication should be |
| 128 | +proportionate to impact. This may include: |
| 129 | + |
| 130 | +- Internal security or operations escalation |
| 131 | +- Notification to administrators, customers, or service owners |
| 132 | +- Temporary mitigation guidance |
| 133 | +- Required upgrade or rotation steps |
| 134 | +- Post-remediation confirmation and closure |
| 135 | + |
| 136 | +Security communications should avoid unnecessary disclosure of exploit details |
| 137 | +before mitigations are available. |
| 138 | + |
| 139 | +## Scope |
| 140 | + |
| 141 | +The following areas are considered in scope for security handling: |
| 142 | + |
| 143 | +- Authentication and authorization controls |
| 144 | +- Password handling and account lifecycle |
| 145 | +- File upload, parsing, and processing pipelines |
| 146 | +- Secrets handling and environment configuration |
| 147 | +- Data access controls and audit logging |
| 148 | +- Container, service, and network configuration |
| 149 | +- Dependency vulnerabilities with validated product impact |
| 150 | +- Sensitive data exposure, privilege escalation, SSRF, RCE, injection, and |
| 151 | + broken access control |
| 152 | + |
| 153 | +## Out of Scope |
| 154 | + |
| 155 | +The following are generally not treated as security vulnerabilities unless |
| 156 | +clear and demonstrated security impact exists: |
| 157 | + |
| 158 | +- Cosmetic misconfigurations without exploitability |
| 159 | +- Missing hardening headers without a practical attack path |
| 160 | +- Issues affecting unsupported or end-of-life releases only |
| 161 | +- Hypothetical findings without reproducible impact |
| 162 | +- Third-party platform issues outside the control of this project |
| 163 | +- Reports based only on scanner output without technical validation |
| 164 | + |
| 165 | +## Safe Handling Expectations |
| 166 | + |
| 167 | +Anyone validating a suspected issue is expected to act in a controlled and |
| 168 | +minimal manner. |
| 169 | + |
| 170 | +Expected behavior: |
| 171 | + |
| 172 | +- Limit activity to what is necessary to confirm the issue |
| 173 | +- Avoid unauthorized access to non-public or third-party data |
| 174 | +- Avoid disruption of production systems |
| 175 | +- Avoid persistence, data modification, or data destruction |
| 176 | +- Stop testing and report promptly once the issue is confirmed |
| 177 | + |
| 178 | +This policy does not authorize: |
| 179 | + |
| 180 | +- Access to data belonging to other users or organizations |
| 181 | +- Service disruption or denial-of-service activity |
| 182 | +- Data exfiltration or retention of sensitive information |
| 183 | +- Any activity that violates applicable law or contractual obligations |
| 184 | + |
| 185 | +## Security Updates |
| 186 | + |
| 187 | +Security fixes may be distributed through one or more of the following: |
| 188 | + |
| 189 | +- Normal release process |
| 190 | +- Out-of-band patch release |
| 191 | +- Security advisory |
| 192 | +- Operational mitigation notice |
| 193 | + |
| 194 | +Where appropriate, the published update should include: |
| 195 | + |
| 196 | +- Affected versions |
| 197 | +- Fixed versions |
| 198 | +- Severity |
| 199 | +- Upgrade path |
| 200 | +- Required operational actions |
| 201 | + |
| 202 | +## Escalation |
| 203 | + |
| 204 | +If no acknowledgement is received within the response target above, the report |
| 205 | +should be resent to: |
| 206 | + |
| 207 | +- `pm300@uni-heidelberg.de` |
| 208 | + |
| 209 | +Urgent reports involving active exploitation or high-confidence compromise |
| 210 | +should use the subject line: |
| 211 | + |
| 212 | +`[URGENT SECURITY REPORT]` |
| 213 | + |
| 214 | +## Policy Maintenance |
| 215 | + |
| 216 | +This policy should be reviewed whenever: |
| 217 | + |
| 218 | +- Reporting channels change |
| 219 | +- Supported versions change |
| 220 | +- Incident response expectations change |
| 221 | +- Disclosure commitments change |
| 222 | + |
| 223 | +Last reviewed: `27-03-2026` |
0 commit comments