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
Copy file name to clipboardExpand all lines: SECURITY.md
+27-4Lines changed: 27 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,7 +34,7 @@ If you believe that you have found a security issue in any software, service, or
34
34
35
35
Please note, however, that projects governed by stdlib sometimes do unsafe things by design. For example, the stdlib REPL supports executing arbitrary code, certain API implementations may use code generation for performance optimization, and stdlib "base" APIs may eschew input validation and sanitation based on the assumption that all input arguments are correct and can be trusted. In general, any unsafe behavior should be explicitly documented, and, if documented, the behavior is **not** considered a security issue.
36
36
37
-
While there are no clearly delineated rules for determining whether a bug should be reported as a security issue or a "regular" issue, when in doubt, please error on the side of filing a security issue. If, after investigation, we subsequently determine that the issue is a regular issue, we will advise you to move the discussion to the [public issue tracker][stdlib-issues].
37
+
While there are no clearly delineated rules for determining whether a bug should be reported as a security issue or a "regular" issue, when in doubt, please err on the side of filing a security issue. If, after investigation, we subsequently determine that the issue is a regular issue, we will advise you to move the discussion to the [public issue tracker][stdlib-issues].
38
38
39
39
### Threat model
40
40
@@ -79,31 +79,49 @@ When submitting a report,
79
79
- please provide detailed reports with reproducible steps and a clearly defined impact.
80
80
- submit only one vulnerability per report.
81
81
- do not engage in any form of social engineering (such as phishing, vishing, or smishing).
82
+
- do not attempt to show CI/CD vulnerabilities by creating new pull requests to any of stdlib's repositories. Doing so will result in a [content report][github-content-report] to GitHub as an unsolicited exploit. The proper way to provide such reports is by creating a new repository, configured in the same manner as the repository about which you would like to submit a report, and, with a pull request to your own repository, showing the proof-of-concept.
82
83
83
84
**Please do NOT report security vulnerabilities through public GitHub issues, discussions, or pull requests, or any other public stdlib forum.**
84
85
85
86
* * *
86
87
87
88
## Process
88
89
89
-
After submitting a private security vulnerability report, your report will normally be acknowledged within **5 days**, and you will receive a more detailed response to your report within **10 days** indicating the next steps in handling your submission. Note, however, that the timelines may extend when stdlib maintainers are away on holiday, particularly at the end of the year.
90
+
After submitting a private security vulnerability report, your report will normally be acknowledged within **5 business days**, and you will receive a more detailed response to your report within **10 business days** indicating the next steps in handling your submission. Note, however, that the timelines may extend when stdlib maintainers are away on holiday, particularly at the end of the year.
90
91
91
92
After the initial reply to your report, stdlib maintainers will strive to keep you informed of progress made toward implementing a fix and making a full announcement. During the course of our investigation, we may ask for additional information or guidance concerning the reported issue.
92
93
94
+
Please note that it is of the utmost importance that you read carefully and follow the guidelines outlined in the stdlib security policy to ensure that the ecosystem as a whole is not disrupted due to improperly reporting vulnerabilities.
95
+
96
+
stdlib does **not** support any reporting outside of the process outlined in this document.
97
+
93
98
* * *
94
99
95
100
## Disclosure policy
96
101
97
102
Our disclosure policy is as follows:
98
103
99
104
- Once a security vulnerability is reported, the report is assigned a primary handler. This person will coordinate the fix and release process.
105
+
100
106
- The problem is then validated against the **latest** release version (e.g., if a package published to npm, the latest `<major>.<minor>.x` release). Due to limited maintainer bandwidth, security vulnerabilities discovered in older `<major>.x.x` release lines are considered out-of-scope and will not receive security updates. Users are advised that only vulnerabilities affecting the **latest** release line will receive patches.
101
-
- Once confirmed, code is then audited to find any potential similar problems.
107
+
108
+
- Depending on the outcome of validation, the primary handler will communicate to the individual who submitted the potential vulnerability one of the following possible responses:
109
+
110
+
-**Acceptance**: what was reported is a considered a new vulnerability.
111
+
-**Rejection**: what was reported is not considered a new vulnerability.
112
+
-**Needs more information**: we need more information in order to evaluate what was reported.
113
+
114
+
- Once a vulnerability is accepted, code is then audited to find any potential similar problems.
115
+
102
116
- Fixes are subsequently prepared for the latest `<major>.<minor>.x` release line.
117
+
118
+
- After fix preparation, the primary handler will coordinate with stdlib maintainers to define a release date for the publication of the vulnerability.
119
+
103
120
- The changes are pushed to the affected public repositories and, where relevant, new builds are published to npm.
121
+
104
122
- The private security vulnerability report is then made public.
105
123
106
-
Note that the above process can take time, especially when coordination is required with maintainers of other projects. We thus ask that you provide us with a reasonable amount of time to resolve reported vulnerabilities prior to any public disclosure or third party reporting. We will make every effort to handle the security report in as timely a manner as possible.
124
+
Note that the above process can take time (up to and beyond **90** days depending on the complexity of the fix), especially when coordination is required with maintainers of other projects. We thus ask that you provide us with a reasonable amount of time to resolve reported vulnerabilities prior to any public disclosure or third party reporting. We will make every effort to handle the security report in as timely a manner as possible.
107
125
108
126
We further ask that you please allow us to follow the release process described above so that we can ensure that disclosures are handled in a consistent manner.
109
127
@@ -139,6 +157,7 @@ This policy document draws from the following security policies:
0 commit comments