Skip to content

Security: solidworkssa/landing

Security

SECURITY.md

Security Policy

Supported Versions

We release patches for security vulnerabilities in the following versions:

Version Supported
1.0.x
< 1.0

Reporting a Vulnerability

The Kleo Network team takes security bugs seriously. We appreciate your efforts to responsibly disclose your findings and will make every effort to acknowledge your contributions.

How to Report a Security Vulnerability

Please do NOT report security vulnerabilities through public GitHub issues.

Instead, please report them via one of the following methods:

  1. Email: Send details to [email protected]
  2. GitHub Security Advisory: Use the GitHub Security Advisory feature

What to Include in Your Report

To help us better understand the nature and scope of the issue, please include as much of the following information as possible:

  • Type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.)
  • Full paths of source file(s) related to the manifestation of the issue
  • The location of the affected source code (tag/branch/commit or direct URL)
  • Any special configuration required to reproduce the issue
  • Step-by-step instructions to reproduce the issue
  • Proof-of-concept or exploit code (if possible)
  • Impact of the issue, including how an attacker might exploit it

What to Expect

After you submit a report, you can expect:

  1. Acknowledgment: We will acknowledge receipt of your vulnerability report within 48 hours
  2. Assessment: We will assess the vulnerability and determine its impact and severity
  3. Updates: We will keep you informed about our progress in addressing the vulnerability
  4. Resolution: We will work on a fix and release it as soon as possible
  5. Credit: We will credit you in the security advisory (unless you prefer to remain anonymous)

Response Timeline

  • Initial Response: Within 48 hours
  • Status Update: Within 7 days
  • Fix Timeline: Depends on severity
    • Critical: Within 7 days
    • High: Within 30 days
    • Medium: Within 90 days
    • Low: Next scheduled release

Security Update Policy

Security updates will be released as patch versions (e.g., 1.0.1, 1.0.2) and will be clearly marked in the CHANGELOG.md.

Notification of Security Updates

When a security update is released, we will:

  1. Update the CHANGELOG.md with details
  2. Create a GitHub Security Advisory
  3. Tag the release with security information
  4. Notify users through GitHub release notes

Security Best Practices for Contributors

If you're contributing to this project, please follow these security best practices:

  1. Never commit sensitive data (API keys, passwords, tokens) to the repository
  2. Use environment variables for all sensitive configuration
  3. Keep dependencies up to date and monitor for security advisories
  4. Follow secure coding practices as outlined in CONTRIBUTING.md
  5. Run security linters before submitting PRs
  6. Test security features thoroughly

Known Security Considerations

External Links

All external links in this application use rel="noopener noreferrer" to prevent:

  • Tabnabbing attacks
  • Unauthorized access to the window.opener object

Content Security Policy

This application implements Content Security Policy (CSP) headers to prevent:

  • Cross-site scripting (XSS) attacks
  • Data injection attacks
  • Clickjacking

HTTPS

This application should always be served over HTTPS in production to ensure:

  • Data encryption in transit
  • Authentication of the server
  • Data integrity

Dependency Security

We use automated tools to monitor our dependencies for known vulnerabilities:

  • npm audit: Run regularly to check for vulnerabilities
  • Dependabot: Automated dependency updates
  • GitHub Security Alerts: Notifications for vulnerable dependencies

To check for vulnerabilities yourself:

npm audit

To fix automatically fixable vulnerabilities:

npm audit fix

Security Disclosure Policy

We follow the principle of Coordinated Vulnerability Disclosure:

  1. Security researchers report vulnerabilities privately
  2. We work together to understand and fix the issue
  3. We release a fix before public disclosure
  4. We credit the researcher (if desired)
  5. Public disclosure happens after users have had time to update

Bug Bounty Program

We currently do not have a formal bug bounty program, but we deeply appreciate security researchers who help us keep our users safe. We will:

  • Publicly acknowledge your contribution (if desired)
  • Provide detailed credit in security advisories
  • Consider your contribution in future bounty programs

Questions?

If you have any questions about this security policy, please contact us at [email protected].


Last Updated: January 7, 2026
Version: 1.0

There aren’t any published security advisories