- release.yml:
- Normalize App.php, package.json, and package-lock.json to clean release version ($TARGET) prior to tagging, ensuring tagged commits contain clean release metadata in git history.
- Update release commit message to `chore(release): release <version>` to reflect that code, manifests, and templates are committed.
- Automate updating issue templates (bug report.yml and feature_request.yml) on release: prepends new release, retains top 5 versions, and preserves the fallback option.
- Automate updating supported versions in SECURITY.md (>= $TARGET and < $TARGET).
- Remove automated regex update of README.md: the intro sentence describes the v3.4 rewrite to CI4, so blindly regex-replacing the version on future releases produces misleading prose and is brittle against wording edits.
- Add concurrency group `release` and restrict workflow execution to master branch.
- Bump App.php, package.json, and package-lock.json to next dev snapshot ($NEXT) in post-release commit.
- build-release.yml:
- Remove redundant VERSION="${VERSION%-dev}" check and in-runner normalization step now that release commits are clean.
- Templates and Security Policy:
- Add OpenSourcePOS 3.4.3 to bug report.yml, feature_request.yml, and SECURITY.md.
- Add "- Older version (specify in description)" fallback option to issue templates.
- Remove default selection in bug report.yml so reporters specify version explicitly.
5.1 KiB
Security Policy
Supported Versions
We release patches for security vulnerabilities.
| Version | Supported |
|---|---|
| >= 3.4.3 | ✅ |
| < 3.4.3 | ❌ |
Security Advisories
For a complete list of published and draft security advisories with CVE details, see our GitHub Security Advisories page.
Reporting a Vulnerability
Option 1: GitHub Security Advisory (Preferred)
-
Create a draft security advisory directly on GitHub:
- Go to https://github.com/opensourcepos/opensourcepos/security/advisories
- Click "New draft security advisory"
- Fill in the vulnerability details using our template below
- Submit as draft (not published)
-
Notify us for triage:
- Send an email to jeroen@steganos.dev with:
- Subject:
[GHSA] Brief description of vulnerability - Link to the draft advisory
- Brief summary
- Subject:
- Send an email to jeroen@steganos.dev with:
Option 2: Email Report
Send vulnerability details to jeroen@steganos.dev.
You will receive a response within 48 hours. Confirmed vulnerabilities will be patched within a few days depending on complexity.
Disclosure Process
Timeline
| Step | Timeline | Action |
|---|---|---|
| 1. Report received | Day 0 | We acknowledge within 48 hours |
| 2. Triage & confirmation | Day 1-3 | We validate the vulnerability |
| 3. Fix development | Day 3-7 | We develop and test the fix |
| 4. Patch release | Day 7-10 | We release a security patch |
| 5. CVE request | Day 7-14 | We request CVE from GitHub (if applicable) |
| 6. Advisory published | Day 14 | We publish the advisory with credit |
| 7. Public disclosure | Day 14+ | Full disclosure after patch release |
CVE Process
We request CVE identifiers through GitHub's security advisory system. This is the preferred and easiest method:
- After we confirm and fix the vulnerability, we'll request a CVE through GitHub
- GitHub coordinates with MITRE on our behalf
- The CVE is automatically linked to the advisory
- You'll be credited as the reporter in the published advisory
Already have a CVE? If you've already obtained a CVE from another source (e.g., VulDB, CVE.MITRE.ORG), please include it in your report or advisory. We'll update our advisory to reference the existing CVE.
No Bug Bounty Program
Important: Open Source Point of Sale does not offer a bug bounty program.
- All security research and vulnerability triage is done on a voluntary basis in our free time
- We do not offer monetary rewards for vulnerability reports
- We do credit reporters in published advisories (unless anonymity is requested)
- We greatly appreciate the security research community's efforts to help improve project security
Security Best Practices for Researchers
- Do not access, modify, or delete data that doesn't belong to you
- Do not perform denial of service attacks
- Do not publicly disclose vulnerabilities before we've had time to fix them
- Do provide sufficient information to reproduce the vulnerability
- Do allow us reasonable time to fix before public disclosure
- Do report through official channels (GitHub advisories or email)
Vulnerability Template
When creating a draft advisory, please include:
## Summary
[Brief description of the vulnerability]
## Impact
- **Confidentiality:** [High/Medium/Low - what data can be exposed]
- **Integrity:** [High/Medium/Low - what can be modified]
- **Availability:** [High/Medium/Low - service disruption potential]
- **Privilege Required:** [None/Low/High - authentication level needed]
- **CVSS v3.1:** [Score] ([Vector string])
## Details
[Technical details about the vulnerability]
**Affected Code:**
```php
// Path to affected file and vulnerable code
Attack Vector: [How an attacker can exploit this]
Proof of Concept
# Steps to reproduce
Patch
[Suggested fix or approach]
Affected Versions
- OpenSourcePOS X.Y.Z and earlier
Credit
[Your GitHub username or preferred name]
---
**Thank you to all security researchers who have contributed to making Open Source Point of Sale more secure.** Your voluntary efforts help protect thousands of users worldwide and contribute to a safer, more trustworthy free and open-source software ecosystem. We deeply appreciate your responsible disclosure and the time you invest in improving our project.
If you've reported a vulnerability and would like to discuss CVE coordination or have questions about the process, please reach out to us at [jeroen@steganos.dev](mailto:jeroen@steganos.dev).