Skip to content

Vulnerability Disclosure Policy

Version: 1.0.0
Last Updated: January 15, 2026
Effective Date: January 15, 2026

Introduction

USL takes security seriously. We appreciate the security research community's efforts to responsibly disclose vulnerabilities and help us keep USL secure.

This policy outlines how to report security vulnerabilities and what to expect from the USL security team.

Reporting a Vulnerability

How to Report

DO NOT open public GitHub issues for security vulnerabilities.

Contact: security@usl-lang.org

PGP Key: Available at https://usl-lang.org/security/pgp-key.asc

Alternative Contact: For urgent issues, contact the project lead at lead@usl-lang.org

What to Include

Please provide as much information as possible:

  1. Type of vulnerability (injection, auth bypass, DoS, etc.)
  2. Component affected (parser, codegen, runtime, etc.)
  3. Steps to reproduce (detailed, ideally with proof-of-concept)
  4. Impact assessment (what can an attacker achieve?)
  5. Suggested fix (optional, but appreciated)
  6. Your contact information (for follow-up questions)

Example Report

Subject: [SECURITY] SQL Injection in Generated Query Code

Component: Code Generator (src/codegen/sql/query.rs)
Severity: High

Description:
When generating SQL queries for entities with optional String fields,
the codegen produces string concatenation instead of parameterized queries.

Steps to Reproduce:
1. Create entity with optional String field:
   entity User { name: String? }
2. Generate query code: cargo run -- examples/user.usl
3. Inspect generated SQL: cat target/generated/db/queries/user.sql
4. Observe: WHERE name = '" + name + "'" (vulnerable)

Expected:
WHERE name = $1 (parameterized)

Impact:
Attackers can inject arbitrary SQL through the name parameter,
potentially reading/modifying any data in the database.

Proof of Concept:
name = "' OR '1'='1" bypasses authentication

Suggested Fix:
Use parameterized queries for all optional fields (same as required fields).

Contact: researcher@example.com

Response Timeline

Acknowledgment

Target: Within 24 hours (business days)

We will acknowledge receipt of your report and assign a tracking ID.

Initial Assessment

Target: Within 7 days

We will: - Confirm the vulnerability - Assess severity (Critical, High, Medium, Low) - Provide an estimated fix timeline - Discuss disclosure timeline

Fix Development

Target: Depends on severity

  • Critical: 7 days
  • High: 14 days
  • Medium: 30 days
  • Low: 60 days

We will keep you updated on progress.

Coordinated Disclosure

Standard: 90 days after initial report

We prefer coordinated disclosure: 1. We fix the vulnerability 2. We prepare security advisory 3. We notify affected users 4. We publish CVE (if applicable) 5. You publish your research (after fix)

Exceptions: - Active exploitation: Immediate disclosure - User safety at risk: Accelerated timeline - Fix complexity: Extended timeline (with mutual agreement)

Scope

In-Scope

We welcome reports for vulnerabilities in:

USL Compiler

  • Parser/Lexer (src/lexer/, src/parser/)
  • Input validation bypasses
  • Denial of service attacks

  • Memory safety issues

  • Semantic Analyzer (src/semantic/)

  • Policy bypass vulnerabilities
  • Secret leakage

  • Type confusion

  • Proof Engines (src/proof/)

  • Proof soundness issues

  • Verification bypasses

  • Code Generator (src/codegen/)

  • SQL injection in generated code
  • XSS in generated APIs

  • Authentication/authorization bypasses

  • Runtime Library (src/runtime/)

  • Runtime security bypasses
  • Secret handling flaws

Generated Code

  • TypeScript/Node.js
  • Injection vulnerabilities
  • Authentication bypasses

  • Authorization flaws

  • SQL Queries

  • SQL injection

  • Row-level security bypasses

  • OpenAPI Specifications

  • Security definition errors
  • Missing authentication

Deployment

  • Docker Images
  • Container escape
  • Privilege escalation

  • Exposed secrets

  • Kubernetes Manifests

  • RBAC misconfigurations
  • Network policy bypasses
  • Resource exhaustion

Out-of-Scope

The following are not eligible for rewards/recognition:

  1. Vulnerabilities in dependencies (report to upstream projects)
  2. Social engineering attacks (phishing, etc.)
  3. Physical security (data center access, etc.)
  4. DoS requiring significant resources (>10,000 requests/sec)
  5. Issues in example applications (marked as demos, not production)
  6. Theoretical vulnerabilities without proof-of-concept
  7. Vulnerabilities in third-party adapters (user-provided code)
  8. Issues already reported or known (check GitHub Security Advisories)
  9. Self-XSS (requires user to execute malicious code)
  10. Version disclosure (not a security issue)

Edge Cases

If you're unsure whether something is in scope, please ask at security@usl-lang.org before spending significant time.

Severity Assessment

We use CVSS 3.1 for severity scoring:

Critical (9.0-10.0)

  • Remote code execution
  • Authentication bypass affecting all users
  • SQL injection in generated code
  • Secret leakage affecting all deployments

Response: 7-day fix target, immediate notification

High (7.0-8.9)

  • Authorization bypass (specific conditions)
  • XSS in generated APIs
  • DoS with minimal resources
  • Container escape

Response: 14-day fix target

Medium (4.0-6.9)

  • Information disclosure (limited impact)
  • Policy enforcement edge cases
  • Configuration vulnerabilities
  • Supply chain issues (low likelihood)

Response: 30-day fix target

Low (0.1-3.9)

  • Theoretical vulnerabilities
  • Issues requiring local access
  • Minor information leakage
  • Documentation errors

Response: 60-day fix target (may be bundled with releases)

Informational

  • Security best practice improvements
  • Hardening suggestions
  • Documentation clarifications

Response: Acknowledged, may be implemented in future releases

Rewards and Recognition

Recognition

All security researchers who report valid vulnerabilities will be:

  1. Acknowledged in the security advisory (with permission)
  2. Listed in our Security Hall of Fame (https://usl-lang.org/security/hall-of-fame)
  3. Credited in release notes

You may choose to remain anonymous.

Rewards (Future)

We are establishing a bug bounty program (planned Q2 2026):

Severity Reward Range
Critical $2,000 - $10,000
High $500 - $2,000
Medium $100 - $500
Low $50 - $100

Current Status: We do not offer monetary rewards at this time. Recognition only.

What We Don't Reward

  • Duplicate reports (first reporter only)
  • Out-of-scope issues
  • Reports without proof-of-concept
  • Publicly disclosed vulnerabilities
  • Vulnerabilities discovered through illegal activity

Safe Harbor

USL commits to:

  1. Not pursue legal action against security researchers who:
  2. Comply with this policy
  3. Report vulnerabilities in good faith
  4. Do not access/modify user data beyond proof-of-concept

  5. Do not publicly disclose before coordinated disclosure

  6. Work with researchers to understand and reproduce issues

  7. Provide credit for valid vulnerability reports

What We Expect

Security researchers should:

  • Make good faith effort to avoid privacy violations, data destruction, and service disruption
  • Not access or modify data beyond what is necessary for proof-of-concept
  • Not perform physical attacks against USL infrastructure
  • Not engage in social engineering (phishing, etc.)
  • Not perform DoS attacks requiring significant resources
  • Keep vulnerabilities confidential until coordinated disclosure
  • Not demand payment for vulnerability reports

This policy is based on: - ISO/IEC 29147:2018 (Vulnerability Disclosure) - NTIA Coordinated Vulnerability Disclosure Template - GitHub Security Bug Bounty Legal Safe Harbor

We will not initiate legal action for good-faith security research under this policy.

Communication

Contact Methods

  • Email: security@usl-lang.org (PGP encouraged)
  • PGP Key: https://usl-lang.org/security/pgp-key.asc
  • Fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX

Response Language

We primarily communicate in English. If you need translation assistance, please let us know.

Confidentiality

All vulnerability reports are treated as confidential until coordinated disclosure.

We will not share: - Your personal information (without permission) - Report details (except with necessary team members) - Vulnerability details (until patch is available)

Security Advisories

After coordinated disclosure, we publish security advisories:

Location: https://github.com/shaifulshabuj/USL/security/advisories

Format: GitHub Security Advisory

Contents: - Vulnerability description - Affected versions - Fixed versions - Severity (CVSS score) - Credits (with permission) - Mitigation steps - Workarounds (if available)

Notification: - GitHub Security Advisories (automatic) - Security mailing list: security-announce@usl-lang.org - Release notes - Blog post (for critical vulnerabilities)

CVE Assignment

For significant vulnerabilities, we will:

  1. Request CVE ID from GitHub or MITRE
  2. Include CVE in security advisory
  3. Update national vulnerability databases (NVD)
  4. Notify downstream distributors

Threshold: High or Critical severity affecting released versions

Version Support

We provide security updates for:

Version Status Support Until
1.0.x Current Ongoing
0.9.x EOL January 2026

Policy: Security fixes for current major version only. Users should upgrade to the latest version.

Exception: Critical vulnerabilities may be backported to previous minor versions (at our discretion).

Examples of Past Vulnerabilities

We will maintain a list of disclosed vulnerabilities:

None disclosed as of January 15, 2026.

Future advisories will be listed at: https://github.com/usl-lang/usl/security/advisories

Frequently Asked Questions

Q: What if my vulnerability is rejected?

A: We'll explain why it's not considered a security issue. You're free to publish your findings (if not confidential) after we've responded.

Q: Can I test vulnerabilities on production systems?

A: No. Set up a local development environment. Do not test on production deployments or third-party USL applications.

Q: What if I accidentally discover a vulnerability while using USL?

A: Please report it! Accidental discoveries are welcome.

Q: Can I discuss my findings with others?

A: Please wait until coordinated disclosure. If you need clarification, contact us first.

Q: What if I disagree with the severity assessment?

A: We're open to discussion. Provide additional context, and we'll reassess.

Q: Can I report vulnerabilities anonymously?

A: Yes, but provide a way for us to follow up (anonymous email, Signal, etc.).

Q: What if someone else reports the same vulnerability first?

A: First reporter receives credit. We'll let you know if it's a duplicate.

Q: Can I report multiple vulnerabilities at once?

A: Yes, but please use separate reports for unrelated issues (easier to track).

Q: What if I find a vulnerability in a dependency?

A: Report to the dependency maintainers. We'll track it in our security monitoring.

Hall of Fame

We thank the following security researchers:

2026: - No reports yet (launched January 15, 2026)

Policy Changes

This policy may be updated occasionally. Changes will be:

  • Published on this page
  • Announced via security-announce@usl-lang.org
  • Effective immediately unless otherwise stated

Last Updated: January 15, 2026

Version History: - v1.0.0 (2026-01-15): Initial policy

Contact

Security Team: security@usl-lang.org
PGP Key: https://usl-lang.org/security/pgp-key.asc
GitHub: https://github.com/usl-lang/usl/security
Website: https://usl-lang.org/security

Thank you for helping keep USL secure! 🔒