You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0c72af6
Browse filesBrowse the repository at this point in the historyBrowse files
docs: repair merge-corruption duplication in SECURITY.md (#611)
The file contained two full drafts of itself concatenated together
(two Scope sections, two reporting-process sections, two Response
Timeline tables, two severity tables, two Safe Harbor sections, two
Bug Bounty sections). Reconciled into one internally-consistent policy
rather than picking either half wholesale:
- Scope: merged the broader FlowStar-wide language with the second
draft's more specific examples (XSS/CSRF/wallet-key exposure,
supply-chain/secret exposure). Kept `contracts/` (not the narrower
`contracts/streaming/`) as the scope path since it's forward-compatible
if more contract packages are added later.
- Response Timeline: the two drafts agreed on every window except Low
severity ("Best effort, based on project priorities" vs "Next
scheduled release") — merged to "Best effort — typically bundled
into the next scheduled release," which keeps both meanings instead
of dropping one.
- Severity Guide: merged both example sets per severity level (e.g.
added the second draft's "DoS affecting individual users" to Medium,
and "unauthorized access to user data" to High) into one table.
- Safe Harbor: merged the first draft's researcher-facing checklist
with the second draft's more explicit maintainer commitments ("we
will not refer you to law enforcement").
- Bug Bounty: kept the first draft's more accurate framing — this repo
runs paid third-party campaigns (see the "Maybe Rewarded"/"GrantFox
OSS" issue labels), so a flat "no bounty program" would be wrong.
Flagging for maintainer review rather than silently resolving: one
draft's "Reporting a Vulnerability" section included an email fallback
("email the maintainers at the address listed on the GitHub profile")
for urgent critical issues. I did not carry that into the merged doc —
"the address listed on the GitHub profile" isn't a concrete, verifiable
contact, and publishing an unclear channel in a security policy seems
worse than omitting it. If maintainers want a backup channel to GitHub
Security Advisories, it needs a real, confirmed address.
| Initial triage and severity classification | Within 1 week|
60
+
| Critical fix or mitigation | Within 72 hours after triage |
61
+
| High severity fix or mitigation | Within 1 week after triage |
62
+
| Medium severity fix or mitigation | Within 2 weeks after triage |
63
+
| Low severity fix | Best effort — typically bundled into the next scheduled release|
59
64
60
65
Complex smart contract issues may require more time for testing, deployment, or
61
66
coordinated disclosure. Maintainers should keep the reporter updated when the
@@ -65,12 +70,12 @@ timeline changes.
65
70
66
71
Use the following guide when estimating impact:
67
72
68
-
| Severity | Examples |
69
-
| --- | --- |
70
-
| Critical | Unauthorized withdrawal or cancellation of streams, theft or permanent loss of user funds, private key or secret exposure, exploit that affects deployed contracts at scale |
71
-
| High | Authorization bypass, transaction manipulation, incorrect accounting that can move funds under specific conditions, CI/CD compromise path |
72
-
| Medium | Incorrect balances or stream state display that can mislead users into signing harmful transactions, limited data exposure, dependency issue with a practical FlowStar exploit path |
73
-
| Low | Hardening gaps, missing security headers, informational leakage without direct fund or permission impact |
| Critical | Unauthorized withdrawal or cancellation of streams, theft or permanent loss of user funds, private key or secret exposure, complete contract takeover, exploit that affects deployed contracts at scale|
76
+
| High | Authorization bypass, unauthorized access to user data, transaction manipulation, incorrect accounting that can move funds under specific conditions, CI/CD compromise path|
77
+
| Medium | Denial of service affecting individual users, incorrect balances or stream state display that can mislead users into signing harmful transactions, data integrity issues without fund loss, limited data exposure, dependency issue with a practical FlowStar exploit path |
78
+
| Low | Hardening gaps, missing security headers, minor/informational disclosure without direct fund or permission impact|
74
79
75
80
CVSS may be used when helpful, but a practical explanation of exploitability and
76
81
user impact is more important than a score alone.
@@ -79,107 +84,33 @@ user impact is more important than a score alone.
79
84
80
85
FlowStar welcomes good-faith security research. If you comply with this policy,
81
86
avoid privacy violations, avoid data destruction, do not exfiltrate funds or
82
-
secrets, and report vulnerabilities promptly, the project will not pursue legal
83
-
action against you for the research activity itself.
87
+
secrets, and report vulnerabilities promptly:
88
+
89
+
- We will not pursue legal action against you for the research activity itself.
90
+
- We will not refer you to law enforcement.
91
+
- We will work with you to understand and resolve the issue quickly.
84
92
85
93
Researchers should:
86
94
87
95
- Test on local environments or testnet whenever possible.
88
96
- Stop testing and report immediately if user funds, private data, or project
89
97
secrets may be exposed.
90
-
- Access only the minimum data needed to prove the issue.
98
+
- Access or modify only the minimum data needed to prove the issue.
99
+
- Avoid denial-of-service testing or disrupting live services.
91
100
- Give maintainers a reasonable opportunity to remediate before public
92
101
disclosure.
93
102
94
103
## Bug Bounty and Recognition
95
104
96
105
This policy does not create a standing cash bounty or guarantee payment. If a
97
106
linked issue, campaign, or external program offers rewards, eligibility,
98
-
severity, payout, and disclosure rules are governed by that program. Maintainers
99
-
may still credit good-faith reporters in release notes or advisories when both
100
-
parties agree.
107
+
severity, payout, and disclosure rules are governed by that program. Absent
108
+
such a program, maintainers will still publicly credit good-faith reporters in
109
+
release notes or advisories, unless the reporter prefers to remain anonymous.
101
110
102
111
## Maintainer Setup
103
112
104
113
To make the reporting path work, repository maintainers should enable GitHub
105
114
private vulnerability reporting or GitHub Security Advisories for FlowStar. The
106
115
private reporting link above should then route researchers away from public
107
116
issues and toward coordinated disclosure.
108
-
## Scope
109
-
110
-
The following are **in scope** for vulnerability reports:
-**CI/CD pipeline** — supply-chain attacks, secret exposure in workflows
115
-
116
-
The following are **out of scope**:
117
-
118
-
- Vulnerabilities in third-party dependencies (report to their maintainers directly)
119
-
- The Stellar network or Soroban runtime itself
120
-
- Issues requiring physical access to a user's device
121
-
- Social engineering attacks
122
-
123
-
---
124
-
125
-
## Reporting a Vulnerability
126
-
127
-
**Preferred:** Use [GitHub Security Advisories](https://github.com/FlowwStar/FlowStar/security/advisories/new) to open a private advisory. This keeps the report confidential until a fix is ready.
128
-
129
-
**Email fallback:** For urgent critical issues, email the maintainers at the address listed on the GitHub profile. Include:
130
-
1. A clear description of the vulnerability
131
-
2. Steps to reproduce or a proof-of-concept
132
-
3. Affected component(s) and version/commit hash
133
-
4. Your assessment of impact and severity
134
-
135
-
Please **do not** open a public GitHub issue for security vulnerabilities.
136
-
137
-
---
138
-
139
-
## Response Timeline
140
-
141
-
| Stage | Target |
142
-
|---|---|
143
-
| Acknowledgment | Within 48 hours |
144
-
| Triage & severity classification | Within 1 week |
145
-
| Fix (Critical) | Within 72 hours of triage |
146
-
| Fix (High) | Within 1 week of triage |
147
-
| Fix (Medium) | Within 2 weeks of triage |
148
-
| Fix (Low) | Next scheduled release |
149
-
150
-
We will keep you updated throughout the process and credit you in the release notes unless you prefer to remain anonymous.
151
-
152
-
---
153
-
154
-
## Severity Classification
155
-
156
-
We use a simplified severity scale:
157
-
158
-
| Severity | Description |
159
-
|---|---|
160
-
|**Critical**| Direct loss of user funds, private key exposure, or complete contract takeover |
161
-
|**High**| Unauthorized access to user data, bypass of core authorization checks |
162
-
|**Medium**| Denial of service for individual users, data integrity issues without fund loss |
163
-
|**Low**| Minor information disclosure, cosmetic security issues |
164
-
165
-
---
166
-
167
-
## Safe Harbor
168
-
169
-
FlowStar is committed to working with security researchers. If you discover a vulnerability and report it responsibly under this policy:
170
-
171
-
- We will not pursue legal action against you
172
-
- We will not refer you to law enforcement
173
-
- We will work with you to understand and resolve the issue quickly
174
-
175
-
We ask that you:
176
-
177
-
- Give us reasonable time to respond before public disclosure
178
-
- Avoid accessing or modifying user data beyond what is necessary to demonstrate the vulnerability
179
-
- Do not perform denial-of-service attacks or disrupt live services
180
-
181
-
---
182
-
183
-
## Bug Bounty
184
-
185
-
There is no formal bug bounty program at this time. We will publicly credit researchers who report valid vulnerabilities (unless anonymity is requested).
0 commit comments