Skip to content

Commit 8ce79f0

Browse files
ThatGuyLLCandreabedini
authored andcommitted
Create SECURITY.md
The Security Council has approved a new SECURITY.md aligned with the bug-bounty process. Please update your project’s SECURITY.md with the correct links for your project and confirm that private vulnerability reporting is enabled for your repository. All bug bounty details found here: https://opensourcecommittee.docs.intersectmbo.org/about/paid-open-source-model-posm/bug-bounty-program'
1 parent 210924d commit 8ce79f0

File tree

1 file changed

+108
-0
lines changed

1 file changed

+108
-0
lines changed

SECURITY.md

Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
# Security Vulnerability Disclosure Policy
2+
3+
## Introduction
4+
5+
The Cardano open source project (xxx) is committed to ensuring the security of
6+
its software and the privacy of its users. We value the contributions
7+
of the security community in helping us identify and address
8+
vulnerabilities in our code. This Security Vulnerability Disclosure
9+
Policy outlines how security vulnerabilities should be reported and
10+
how we will respond to and remediate such reports.
11+
12+
## Security Vulnerability Handling Process
13+
14+
### Reporting a Vulnerability
15+
16+
If you discover a security vulnerability in xxxx, we encourage you to
17+
responsibly disclose it to us. To report a vulnerability, please use
18+
the [private reporting form on
19+
GitHub](https://github.com/input-output-hk/mithril/security/advisories/new)
20+
to draft a new _Security advisory_.
21+
22+
Please include as much details as needed to clearly qualify the issue:
23+
24+
- A description of the vulnerability and its potential impact.
25+
- Steps to reproduce the vulnerability.
26+
- The version of `xxxx` package where the vulnerability exists.
27+
- Any relevant proof-of-concept or exploit code (if applicable).
28+
29+
### Processing Vulnerability
30+
31+
1. **Acknowledgment**: The team acknowledges the receipt of your report
32+
within 3 business days by commenting on the issue reporting it or replying to email.
33+
34+
2. **Validation**: The team investigates the issue and either _reject_ or _validate_ the
35+
reported vulnerability.
36+
37+
a. **Rejection**: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as `Won't fix`.
38+
39+
b. **Acceptance**: If the team accepts the report, a CVE identifier will be requested through GitHub and a [private fork](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability) opened to work on a fix to the issue
40+
41+
3. **Resolution**: The team works to resolve the vulnerability in a
42+
timely manner. The timeline for resolution will depend on the
43+
complexity and severity of the vulnerability, but we will strive to
44+
address critical vulnerabilities as quickly as possible.
45+
46+
4. **Collaboration**: While working on a fix, the team maintains open and transparent
47+
communication with the reporter throughout the process, providing
48+
updates on the status of the vulnerability and any steps taken to
49+
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
50+
51+
5. **Fixing Issue**: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
52+
53+
a. **Mitigation**: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix _if and only if_ a clear, simple, and effective mitigation plan is defined. This _must_ include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
54+
55+
b. **Fix**: When a fix is available and approved, it should be merged and made available as quickly as possible:
56+
57+
- All commits to the private repository are squashed into a single commit whose description _should not_ make any reference it relates to a security vulnerability
58+
- A new Pull Request is created with this single commit
59+
- This PR's review and merging is expedited as all the work as already been done
60+
61+
6. **Release**: The team creates and publish a release that includes the fix
62+
63+
7. **Announcement**: Concomitant to the release announcement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
64+
65+
a. **Credit**: The team publicly acknowledges the contributions of the
66+
reporter once the vulnerability is resolved, subject to the
67+
reporter's preferences for attribution.
68+
69+
8. **Disagreements**: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
70+
71+
## Responsible Disclosure
72+
73+
We kindly request that reporters adhere to responsible disclosure
74+
practices, which include:
75+
76+
- **Do not disclose the vulnerability publicly**: Please refrain from
77+
posting details of the vulnerability on public forums or social
78+
media until it has been resolved.
79+
- **Do not exploit the vulnerability**: Do not attempt to exploit the
80+
vulnerability to cause harm or gain unauthorized access to systems.
81+
- **Work with us**: Allow us a reasonable amount of time to
82+
investigate and address the vulnerability before publicly disclosing
83+
any details.
84+
85+
## Legal Protections
86+
87+
We will not pursue legal action against individuals who
88+
report security vulnerabilities to us.
89+
90+
## Contact Information
91+
92+
To report a security vulnerability, please use [GitHub
93+
form]((add project github form for your project)). Should you experience any issues reporting via GitHub or have other questions, Please contact [Security](security@intersectmbo.org).
94+
95+
## Revision of Policy
96+
97+
This Security Vulnerability Disclosure Policy may be updated or
98+
revised as necessary. Please check the latest version of this policy
99+
on the [xxxx repository]((add link for your project)).
100+
101+
## Conclusion
102+
103+
The xxxx project greatly appreciates the assistance of the security
104+
community in helping us maintain the security of our software while
105+
upholding the highest standards of privacy. Together, we can work to
106+
identify and address vulnerabilities, ensuring a safer and more secure
107+
experience for all users.
108+

0 commit comments

Comments
 (0)