Т-Банк Rule-Bounty
Company: T-BankRule-Bounty - an additional bounty program for researchers who help us improve code security by creating unique rules for Semgrep Community Edition. For each new rule that meets the requirements below, we pay the same as the main bug bounty program.
Rewards are paid to individual entrepreneurs and self-employed persons
Program description
Welcome to T-Bank's Rule-Bounty!
Rule-Bounty is an additional reward program for researchers who help us improve code security by creating unique rules for Semgrep Community Edition. For each new rule that meets the requirements below, we pay the same as the main bug bounty program.
≡ Table of Contents
- Program Objective
- Scope
- Rule Requirements
- What Not to Submit
- Verification Process and Duplicates
- Payout Table
- Determining Rule Criticality
- Rules of Participation
- FAQ
- Example of a Well-Formed Rule
- Contact Us
1. Program Objective
We want to create unique, practically useful rules for Semgrep that find vulnerabilities in T-Bank repositories and improve the quality of our internal rule base. The higher the practical value and impact of the rule, the higher the reward.
2. Scope
- Explore popular languages and frameworks (Java/Kotlin/Scala, C#, Go, Python, JavaScript/TypeScript).
- We will validate the rules on an internal sample of T-Bank repositories.
3. Rule Requirements
| # | Requirement | Details |
|---|---|---|
| 1 | Semgrep Community Edition | Use Semgrep CE syntax; features available only in the Enterprise edition are prohibited. |
| 2 | Uniqueness | The rule must not be published in the Semgrep Registry, GitHub, blogs, articles, reports, chats, etc. |
| 3 | CWE | Specify the relevant CWE identifier (e.g., CWE-89: SQL Injection). |
| 4 | Full metadata | Required fields: id, message, severity, languages, metadata.cwe, metadata.category, metadata.confidence, metadata.likelihood, metadata.impact |
| 5 | Snippet | Minimal example code that triggers the rule (Semgrep unit test). |
| 6 | Impact description | Briefly: what the rule detects, what the threat is caused by the remaining vulnerability. |
Submission format
Submit the YAML file of the rule + snippet (.yml and .txt/.py/…) in a single archive. Describe the logic in the report and indicate how to test it.
4. What not to send
- Duplicate rules of public rules.
- Linter-level rules: code style, cosmetics, dead code without impacting security.
- Templates requiring third-party Semgrep Enterprise plugins.
- Catch-all rules with a large number of false positives.
- Rules without CWE, without a snippet, or with incomplete metadata.
5. Verification process and duplicates
- Acceptance - automatic and manual format and condition checking. If necessary, we can return the rule to the author for revision.
- Uniqueness check:
- If the rule is found in public sources, the report is closed without payment, indicating the original source. - If we already have a similar rule, we send proof, and the report is closed without payment.
- Impact Validation - We test the rule on our repositories. For this, we select a scope that matches the rule stack on which the submitted rule is executed. After testing, we validate the results, looking at the number of triggers and the False Positive percentage. If necessary, we can return the rule to the author for revision.
- Severity Rating - See the table below.
- Payment / Rejection - We will respond within two weeks.
6. Payout Table
| Criticality | Critical | High | Medium | Low |
|---|---|---|---|---|
| Maximum payout amount, ₽ | 1,000,000 | 400,000 | 50,000 | 10,000 |
The amount may be reduced if the rule yields a lot of FP, covers a narrow edge case, or is easily bypassed.
7. Determining rule criticality
Key factors:
- ease of use
- potential scale of damage
- number of affected systems.
We evaluate not only the correctness of the rule, but also its practical usefulness for T-Bank's code. If the rule fails to produce results on our repositories, it is not eligible for payment.
8. Participation rules (briefly)
- One report - one rule.
- Do not disclose the rule until we respond.
- Only custom rules are allowed.
9. FAQ
How and when are reports reviewed?
Reports with rules are reviewed by our internal security team. Response time depends on workload, but we strive to process requests within two weeks.
Reports with the "Insufficient information from the hacker" status without activity for a month are closed at the discretion of the security team.
Reports with the "Insufficient information from the hacker" status without activity for a month are closed at the discretion of the security team.
Can small patterns be combined into a single rule?
Yes, if they are logically related and improve accuracy.
10. Example of a well-formatted rule
[Rule] C# Validate Issuer Signing Key Set To False (*Кликабельно*)
rules: - id: validateissuersigningkey-set-to-false pattern-either: - pattern: | ValidateIssuerSigningKey = false - pattern: | $OPTIONS.ValidateIssuerSigningKey = false - pattern: | bool $PARAM = false; ... <... ValidateIssuerSigningKey = $PARAM ...> - pattern: | bool $VAL = false; ... <... $OPTIONS.ValidateIssuerSigningKey = $VAL ...> metadata: category: security cwe: "CWE-347: Improper Verification of Cryptographic Signature" author: bug-hunters@tinkoff.ru confidence: HIGH likelihood: HIGH impact: HIGH subcategory: - vuln message: Accepting unsigned security tokens as valid security tokens allows an attacker to remove its signature and potentially forge an identity. As a fix, set ValidateIssuerSigningKey to be true. languages: - csharp severity: ERROR
[Snippet] Validate Issuer Signing Key Set To False (*Кликабельно*)
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options => { options.TokenValidationParameters = new TokenValidationParameters { // ruleid: validateissuersigningkey-set-to-false ValidateIssuerSigningKey = false, RequireSignedTokens = false, ValidateIssuer = false, ValidateAudience = false }; }); services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options => { options.TokenValidationParameters = new TokenValidationParameters { // ok: validateissuersigningkey-set-to-false RequireSignedTokens = true, ValidateIssuer = false, ValidateAudience = false }; });
11. Contacts
bug-hunters@tinkoff.ru - any questions about our Bug-Bounty program.