Skip to content

Commit 3a10934

Browse files
zanicarzanicar
committed
docs: Update policies
- Update CONTRIBUTING.md - Update SECURITY.md
1 parent 7b8f578 commit 3a10934

File tree

2 files changed

+243
-84
lines changed

2 files changed

+243
-84
lines changed

‎CONTRIBUTING.md‎

Lines changed: 132 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -1,42 +1,143 @@
1-
# Contributing to `nexus`
1+
# Contributing to Talus Projects
22

3-
Thank you for considering contributing to this project!
4-
The following guidelines help ensure a smooth process for everyone.
3+
Thank you for considering contributing to Talus! This document outlines our contribution process and standards across all Talus repositories.
54

6-
## How to Contribute
5+
## Getting Started
76

8-
1. **Fork the repository** and create your branch from `main`.
9-
2. **Follow the coding style** used in the project.
10-
3. **Write clear, concise commit messages.**
11-
4. **Add tests** for any new functionality.
12-
5. **Ensure all tests pass** before submitting a pull request.
13-
6. **Ensure `rustfmt` and `clippy` are happy** before submitting a pull request.
14-
7. **Do not use unsafe Rust code**.
15-
8. **Update documentation** to complement code changes
7+
All contributions follow our systematic development process. Please familiarize yourself with:
168

17-
## Reporting Issues
9+
- **[Discussion Guidelines](https://github.com/Talus-Network/.github/blob/main/DISCUSSIONS.md)** - How to propose and discuss ideas
10+
- **[Improvement Proposal Process](https://github.com/Talus-Network/.github/blob/main/IP_PROCESS.md)** - Our formal proposal and approval workflow
11+
- **Code of Conduct** - Standards for respectful collaboration
1812

19-
- Use the [Issue Tracker] to report bugs or suggest enhancements.
20-
- Check if the issue already exists before submitting.
21-
- Provide steps to reproduce, expected vs. actual behavior, and relevant logs or screenshots.
13+
## How Ideas Become Features
2214

23-
## Pull Request Process
15+
### 1. Community Discussion (GitHub Discussions)
16+
Start with a discussion to gauge community interest and gather initial feedback. Use our [Discussion Guidelines](link) to structure your proposal effectively.
2417

25-
- Open a pull request with a clear description of what it does and why.
26-
- Link to the issue it fixes (if applicable).
27-
- Ensure your branch is up to date with `main`.
28-
- A maintainer will review and may request changes.
29-
- Your PR will be reviewed by maintainers and may be merged after approvals.
18+
### 2. Technical RFC (GitHub Discussions - Ideas)
19+
For ideas with community support, create a technical RFC to explore implementation approaches and feasibility.
3020

31-
## Writing commit messages
21+
### 3. Improvement Proposal (GitHub Issues)
22+
Promising RFCs become formal Improvement Proposals following our [IP template](link). All significant changes require IP approval.
3223

33-
- Use [Conventional Commits] specification for the commit messages
34-
- Use the present tense (e.g., "feat: add command on cli" not "feat: added command on cli")
35-
- Use imperative tone ("add command" not "adds command" or "adding command")
36-
- Reference a ticket if applicable.
37-
- Add more context and an explanation for the contribution.
24+
### 4. Implementation (Pull Requests)
25+
Approved IPs become implementation epics with specific development tasks.
3826

39-
<!-- List of references -->
27+
## Development Standards
4028

41-
[Issue Tracker]: https://github.com/Talus-Network/nexus/issues
42-
[Conventional Commits]: https://www.conventionalcommits.org/
29+
### Code Quality
30+
- **Follow established coding style** for the specific project language
31+
- **Write clear, concise commit messages** using [Conventional Commits](https://www.conventionalcommits.org/)
32+
- **Add comprehensive tests** for new functionality
33+
- **Ensure all tests pass** and code quality checks succeed
34+
- **Update documentation** to reflect changes
35+
- **No unsafe code** in Rust projects without explicit justification
36+
37+
### Commit Message Format
38+
```
39+
type(scope): description
40+
41+
- Use present tense ("add feature" not "added feature")
42+
- Use imperative mood ("fix bug" not "fixes bug")
43+
- Reference issues when applicable
44+
- Provide context for the change
45+
```
46+
47+
### Pull Request Process
48+
1. **Link to Epic/Issue**: All PRs must reference the implementing issue/epic
49+
2. **Descriptive Title**: Clear summary of changes
50+
3. **Detailed Description**: What changed and why
51+
4. **Testing Evidence**: Demonstrate changes work as expected
52+
5. **Documentation Updates**: Include any required documentation changes
53+
54+
## Issue Reporting
55+
56+
### Bugs
57+
Use the bug report template to provide:
58+
- Steps to reproduce
59+
- Expected vs actual behavior
60+
- Environment details
61+
- Relevant logs or screenshots
62+
63+
### Feature Requests
64+
Start with a Discussion rather than immediately creating feature request issues. This allows for community input and ensures alignment with project direction.
65+
66+
### Security Issues
67+
**Never report security issues publicly.** Follow our [Security Policy](SECURITY.md) for responsible disclosure.
68+
69+
## Code Review Standards
70+
71+
### For Contributors
72+
- **Keep PRs focused**: One logical change per PR
73+
- **Respond promptly** to review feedback
74+
- **Test thoroughly** before requesting review
75+
- **Be respectful** of reviewer time and feedback
76+
77+
### Review Process
78+
- Maintainers will review within 48-72 hours for active PRs
79+
- Address all review comments before requesting re-review
80+
- At least one maintainer approval required for merge
81+
- Automated checks must pass before merge
82+
83+
## Community Guidelines
84+
85+
### Communication
86+
- **Be respectful** and constructive in all interactions
87+
- **Assume positive intent** from other contributors
88+
- **Ask questions** when something is unclear
89+
- **Help others** learn and improve
90+
91+
### Collaboration
92+
- **Search existing** discussions and issues before creating new ones
93+
- **Provide context** when referencing external information
94+
- **Update status** on work in progress
95+
- **Celebrate successes** and learn from failures
96+
97+
## Repository-Specific Guidelines
98+
99+
Different repositories may have additional requirements:
100+
101+
- **Rust projects**: Use `rustfmt` and address `clippy` warnings
102+
- **Smart contracts**: Follow Sui Move best practices and security guidelines
103+
- **Documentation**: Use clear, accessible language with examples
104+
- **Frontend**: Follow accessibility standards and responsive design principles
105+
106+
Check individual repository README files for specific requirements.
107+
108+
## License and CLA
109+
110+
### Contributor License Agreement
111+
All contributors must sign our Contributor License Agreement (CLA) before contributions can be merged. The CLA assistant will guide you through this process on your first PR.
112+
113+
### Licensing
114+
- Most repositories use **Business Source License 1.1** by default
115+
- Open source projects use **Apache License 2.0**
116+
- Check individual repository LICENSE files for specific terms
117+
118+
## Getting Help
119+
120+
### Community Support
121+
- **GitHub Discussions**: General questions and community support
122+
- **Discord/Telegram**: Real-time community chat (links in project README)
123+
- **Documentation**: Comprehensive guides at [docs.talus.network](https://docs.talus.network)
124+
125+
### Developer Support
126+
- **Technical Questions**: Start with GitHub Discussions
127+
- **Process Questions**: Reference this guide or ask in discussions
128+
- **Urgent Issues**: Follow our incident response procedures
129+
130+
## Recognition
131+
132+
We value all contributions and recognize contributors through:
133+
- Commit attribution and co-authorship
134+
- Contributor acknowledgments in release notes
135+
- Community recognition in discussions and social media
136+
137+
Thank you for contributing to the Talus ecosystem! Your efforts help build the future of decentralized autonomous systems.
138+
139+
---
140+
141+
**Last updated**: 2025-09-22
142+
143+
*This document is maintained by the Talus team and updated as our processes evolve. For questions or suggestions about these guidelines, please open a discussion.*

‎SECURITY.md‎

Lines changed: 111 additions & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -1,86 +1,144 @@
11
# Talus Labs Security Policy
22

3-
This document describes the Talus Labs Security team's process for handling security issues.
3+
This document describes the Talus Labs security team's process for handling security issues across all Talus repositories and services.
44

55
## Reporting Security Issues
66

7-
__IMPORTANT:__ _Please DO NOT open public issues for security related matters, or discuss it in public forum or on social media._
7+
**IMPORTANT:** Please DO NOT open public issues for security-related matters or discuss them in public forums or on social media.
88

9-
### Email
9+
### Primary Reporting Methods
1010

11-
All security issues should be reported via email to [security-reports@taluslabs.xyz](mailto:security-reports@taluslabs.xyz). Email is delivered to the Talus Labs security team.
11+
#### Email (Recommended)
12+
Report security issues to: **[security-reports@taluslabs.xyz](mailto:security-reports@taluslabs.xyz)**
1213

13-
Include the following details in the report:
14+
Include these details in your report:
15+
- **Your information**: Name and affiliation (if applicable)
16+
- **Technical description**: Detailed issue explanation with reproduction steps
17+
- **Impact assessment**: Who can exploit this and what the implications may be
18+
- **Visibility status**: Whether this vulnerability is public or known to third parties
19+
- **Supporting evidence**: Relevant logs, screenshots, or proof-of-concept (if safe to share)
1420

15-
- Your name;
16-
- Your affiliation (if applicable);
17-
- Technical description of the issue, including steps to reproduce;
18-
- Explanation of who may be able to exploit this vulnerability and what the impact or implications may be;
19-
- Whether this vulnerability is public or known to third parties. Please provide details where applicable;
21+
#### GitHub Private Vulnerability Reporting
22+
For repository-specific issues, use GitHub's private vulnerability reporting:
23+
1. Navigate to the repository's "Security" tab
24+
2. Click "Report a vulnerability" under Security Advisories
25+
3. Complete the form with detailed information
2026

21-
_Please notify the Talus Labs security team at the email above of existing public issues that may be of critical security importance._ Please ensure to include the issue ID along with a short description / explanation of the security relevance.
27+
See [GitHub's documentation](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability) for more information.
2228

23-
### GitHub Private Vulnerability Reporting
29+
### Encrypted Communication
2430

25-
Under the repository "Security" tab / Security Advisories you will find "Report a vulnerability". Please complete the provided form with as much details as possible.
31+
For sensitive reports, use our PGP public key:
32+
- **Download**: [https://talus.network/security-pgp-key.txt](https://talus.network/security-pgp-key.txt)
33+
- **Key Server**: [keys.openpgp.org](https://keys.openpgp.org)
34+
- **Fingerprint**: `103391C9AE4BE87A85E3EFAE2D4462A29BAB94AE`
2635

27-
For more information on GitHub private vulnerability reporting [see this](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability).
36+
**Always verify the fingerprint before using the key.**
2837

29-
_Best practices for writing repository security advisories_ can be found [here](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/best-practices-for-writing-repository-security-advisories).
38+
## Our Response Process
3039

31-
Security researchers can also use the REST API to privately report security vulnerabilities. For more information, see "[Privately report a security vulnerability](https://docs.github.com/en/rest/security-advisories/repository-advisories#privately-report-a-security-vulnerability)" in the REST API documentation.
40+
The Talus Labs security team will:
3241

33-
### Encrypted Communication
42+
1. **Acknowledge receipt** within 72 hours
43+
2. **Verify and assess** the reported vulnerability
44+
3. **Determine scope** including affected versions and impact assessment
45+
4. **Audit for similar issues** to prevent related vulnerabilities
46+
5. **Develop fixes** for all affected production releases
47+
6. **Coordinate disclosure** with ecosystem stakeholders when appropriate
48+
7. **Deploy fixes** following our emergency release procedures
49+
8. **Publish advisories** once fixes are deployed and users can update
3450

35-
If you wish to encrypt your vulnerability report, please use our PGP public key:
51+
### Timeline Expectations
52+
- **Initial response**: Within 72 hours
53+
- **Severity assessment**: Within 5 business days
54+
- **Fix development**: Varies by complexity, communicated during assessment
55+
- **Public disclosure**: After fixes are available and reasonable time for adoption
3656

37-
- **Download**: [https://talus.network/security-pgp-key.txt](https://talus.network/security-pgp-key.txt)
38-
- **Key Server**: [keys.openpgp.org](https://keys.openpgp.org)
39-
- **Fingerprint**: `103391C9AE4BE87A85E3EFAE2D4462A29BAB94AE`
57+
## Incident Response Integration
4058

41-
Always verify the fingerprint before using the key.
59+
Security issues may trigger our [Incident Management Plan](https://www.notion.so/taluslabs/Incident-Management-Plan-25e7a61d1baa80498736f5ece8e58ece), particularly for:
60+
- Active exploits affecting user funds or data
61+
- Platform-wide vulnerabilities
62+
- Critical infrastructure compromises
4263

43-
## Handling Security Issues
64+
In such cases, response times may be accelerated and additional coordination procedures activated.
4465

45-
The Talus Labs security team will:
66+
## Researcher Guidelines
67+
68+
Please help us handle security issues effectively by:
69+
70+
### Responsible Disclosure
71+
- **Allow reasonable time** for our team to respond and address issues
72+
- **Coordinate disclosure timing** to ensure users can protect themselves
73+
- **Provide clear communication** throughout the process
74+
75+
### Research Ethics
76+
- **Avoid exploitation** of discovered vulnerabilities
77+
- **Demonstrate good faith** by not disrupting services, data, or communities
78+
- **Respect privacy** and avoid accessing user data
79+
- **Follow applicable laws** in your research activities
80+
81+
## Safe Harbor Policy
82+
83+
Talus Labs is committed to working constructively with security researchers and the broader security community.
84+
85+
### Legal Protection
86+
When conducting vulnerability research according to this policy, we consider such research to be:
87+
88+
- **Authorized** under applicable computer fraud and abuse laws
89+
- **Exempt** from Terms of Service restrictions that would interfere with security research
90+
- **Lawful and beneficial** when conducted in good faith and compliance with applicable laws
91+
92+
### Research Scope
93+
This safe harbor applies to security research on:
94+
- **Talus Labs infrastructure** and operated services
95+
- **Nexus platform** and related open source software
96+
- **Public-facing applications** and websites operated by Talus Labs
97+
- **Smart contracts** deployed by Talus Labs
4698

47-
1. Acknowledge receipt within 72 hours;
48-
2. Verify and confirm the issue;
49-
3. Determine affected versions and scope of impact;
50-
4. Conduct audits to find any potential similar and related issues;
51-
5. Prepare fixes for relevant in-production releases;
52-
6. Endeavor to communicate and coordinate with relevant ecosystem stakeholders, including the Nexus communities, at the appropriate times;
99+
### Good Faith Requirements
100+
To qualify for safe harbor protection, research must:
101+
- **Avoid privacy violations** and data access/modification
102+
- **Prevent service disruption** or data destruction
103+
- **Exclude social engineering** against employees or community members
104+
- **Provide reasonable disclosure time** before any public disclosure
105+
- **Comply with applicable laws** and agreements
53106

54-
Please assist the Talus Labs security team by following these guidelines:
107+
## Scope and Exclusions
55108

56-
- Allow a reasonable amount of time for the team to respond to and address the issue;
57-
- Avoid exploiting any issues or vulnerabilities that you may become aware of;
58-
- Demonstrate good faith by not disrupting the Talus Labs / Nexus networks, data, services or communities;
109+
### In Scope
110+
- **Platform vulnerabilities**: Nexus protocol and infrastructure
111+
- **Smart contract issues**: Logic flaws, economic exploits, access control
112+
- **Infrastructure security**: API endpoints, authentication, data handling
113+
- **Dependency vulnerabilities**: Third-party library issues affecting our services
114+
- **Configuration issues**: Misconfigurations leading to security exposure
59115

60-
_Every effort will be made to handle and address security issues as quickly and efficiently as possible._
116+
### Out of Scope
117+
- **Social engineering** attacks on staff or users
118+
- **Physical security** of office locations
119+
- **Distributed denial of service (DDoS)** attacks
120+
- **Spam or content-based** attacks
121+
- **Issues in third-party** services not controlled by Talus Labs
61122

62-
## Safe Harbor
123+
## Recognition and Rewards
63124

64-
Talus Labs is committed to working with security researchers and the broader security community. We believe that responsible security research benefits everyone and helps keep our users safe.
125+
From time to time we may operate formal bug bounty programs. We may publish these on our web site, social media or other formal communication channels.
65126

66-
**Legal Safe Harbor**: When conducting vulnerability research in accordance with this policy, we consider such research to be:
127+
We recognize valuable security research through:
128+
- **Public acknowledgment** in security advisories (with your permission)
129+
- **Direct communication** with our security team
130+
- **Community recognition** when appropriate
131+
- **Swag and merchandise** for significant contributions
67132

68-
- **Authorized** in accordance with applicable computer fraud and abuse laws, and we will not initiate or recommend legal action against you for accidental, good-faith violations of this policy;
69-
- **Exempt** from restrictions in our Terms of Service/Use that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy;
70-
- **Lawful** and helpful to the overall security of the Internet when conducted in good faith and in compliance with applicable laws.
133+
## Questions and Support
71134

72-
**Research Guidelines**: To qualify for safe harbor protection, security research must be conducted in good faith, which means:
135+
For questions about this security policy or the reporting process:
136+
- **Email**: [security-reports@taluslabs.xyz](mailto:security-reports@taluslabs.xyz)
137+
- **General security discussions**: Use GitHub Discussions in relevant repositories
73138

74-
- You make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of Talus Labs services and the Nexus network;
75-
- You do not access, modify, or delete data belonging to others;
76-
- You do not perform attacks that could harm the reliability/integrity of our services or data;
77-
- You do not use social engineering techniques against our employees, contractors, or community members;
78-
- You provide us with reasonable time to address the issue before any disclosure;
79-
- You do not violate any law or breach any agreement in the course of your research.
139+
---
80140

81-
**Scope**: This safe harbor applies to security research conducted on:
82-
- Talus Labs operated infrastructure and services
83-
- Open source Nexus software and related repositories
84-
- Public-facing websites and applications operated by Talus Labs
141+
**Last updated**: 2025-09-22
142+
**Version**: 2.0
85143

86-
If you have questions about whether your research is consistent with this policy, please contact us at [security-reports@taluslabs.xyz](mailto:security-reports@taluslabs.xyz) before proceeding.
144+
*This policy is regularly reviewed and updated to reflect our evolving security practices and community needs.*

0 commit comments

Comments
 (0)