Логика Молока

Логика Молока (далее по тексту - Компания) – Компания №1 по производству свежих молочных продуктов. Наши бренды: Простоквашино, АктиБио, Актимуно, Планто и другие.

Логика Молока – Компания №1 по производству свежих молочных продуктов. Наши бренды: Простоквашино, АктиБио, Актимуно, Планто и другие

Копилка

«Копилка» — файловое хранилище без доступа третьих лиц и стороннего контроля.

Cyber Evaluation is a new approach to validating an organization's cyber defenses, providing an objective security assessment expressed in monetary terms. The Cyber Evaluation project runs a grant program aimed at improving the security posture of businesses operating in Russia.

Cyber Evaluation

Jet Infosystems (NTEs)

Jet Infosystems (Company) is a system integrator and one of the top ten largest tech companies and the top five IT service providers in Russia. We implement unique solutions that we test ourselves. We take on complex projects that others consider impossible: building a data center in permafrost, launching a virtual mobile operator from scratch in six months, or building an IT and clearing infrastructure for a new national payment system in just a few months.

Jet Infosystems is a system integrator and one of the top ten largest tech companies and the top five IT service providers in Russia. The company delivers unique, self-tested solutions and takes on complex projects often considered impossible, such as building a data center in permafrost, launching a virtual mobile operator from scratch in six months, or developing an IT and clearing infrastructure for a new national payment system in just a few months.

Jet Infosystems

Positive Technologies works continuously to create products that are trusted by companies from all over the world. Our experience shows that there is no such thing as a completely secure system. That's why we launched a bug bounty program to reward researchers for reporting vulnerabilities discovered in our own services.

## Scope

* All resources in the ptcloud.ru domain and its subdomains 

**Note.** If you discover an out-of-scope vulnerability, please report it to us too. Our security team will review your report and take measures to fix the problem.

## Participation requirements

1. Participants must be at least 18 years old.
2. Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
3. Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

Participant obligations:

1. Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
2. Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
3. Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.

4. Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.

## Positive Technologies obligations

Positive Technologies has the following obligations:

1. Promptly address identified security issues.
2. To not prohibit the disclosure of vulnerabilities without good reason.
3. To not make baseless accusations against researchers.
4. If details of a vulnerability are published, credit the security researcher who reported it.

# Prohibited actions

Program participants are not allowed to do the following:  

* Tamper with user accounts without their owners' permission.
* Use detected vulnerabilities for personal purposes.
* Use vulnerability testing tools that automatically generate large amounts of traffic and cause resource exhaustion attacks.
* Conduct attacks that compromise integrity and availability of services (for example, DoS and brute-force attacks) or attempt to exploit a resource exhaustion vulnerability. If you find such a vulnerability, report it to the Positive Technologies security team for simulation of an attack in a test environment.
* Perform physical attacks on the company's employees, data centers, or offices.
* Spam or carry out social engineering attacks (phishing, vishing, and so on) against Positive Technologies customers, partners, or employees.
* Analyze the underlying server infrastructure hosting the web applications.

## Rewards for reported vulnerabilities

Examples of vulnerabilities we'll be happy to reward you for:

* Remote code execution (RCE)
* Injections (such as SQL and XML injections)
* Arbitrary file read or write, remote or local file inclusion (LFI/RFI)
* Flawed authentication/authorization
* Access control vulnerabilities
* Business logic vulnerabilities
* IDOR
* Sensitive information disclosure
* Non-blind server-side request forgery (SSRF)


If a vulnerability is discovered in third-party software (for example, open source libraries) used by Positive Technologies, the researcher will receive a limited reward that can be increased at the discretion of the contest commission. Detection of vulnerabilities other than those in the list below may be rewarded at the discretion of the commission, depending on their severity, but payment is not guaranteed.  

**No reward will be given for:**

* Reports generated by security scanners and other automated tools.
* Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
* Information about IP addresses, DNS records, and open ports.
* Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
* Reports of vulnerabilities whose exploitation is prevented by information security tools without demonstrating how to bypass the security tools.
* Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
* Reports indicating the lack of SSL or other current best practices.
* Reports of vulnerabilities already reported by other participants (duplicate reports).
* 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
* Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

## Report requirements

A vulnerability report must contain the following:  

* Vulnerability name.
* Product name and version of the vulnerable software (or component).
* Proof of concept (PoC) or detailed description of how to reproduce the security issue.
* Description of the attack scenario: who can exploit the vulnerability, for what purpose, in what circumstances, and so on.
* Recommendations for remediation.

&nbsp;
You can attach videos and screenshots to your report, but they cannot replace the report (it must be filled out).  

If you identify multiple security issues in Positive Technologies services, prepare a separate report for each vulnerability.  

Vulnerability reporting is subject to the platform rules.

PT NGFW

Positive Technologies is a leading global provider of cybersecurity solutions. Over 2,300 organizations worldwide use technologies and services developed by our company. For more than 20 years, our mission has been to safeguard businesses and entire industries against the threat of cyberattacks. Positive Technologies is the first and only cybersecurity company in Russia to go public on the Moscow Exchange (MOEX: POSI).

Positive Technologies

# Bug bounty program for PT Container Security
The PT Container Security bug bounty program focuses on identifying and validating vulnerabilities that may compromise container and orchestrator environments, allow security control bypass across build/deploy/runtime stages, disrupt DevSecOps workflows, or enable unauthorized control of clusters and underlying hosts.

PT Container Security is an end-to-end security platform for hybrid cloud environments, designed to support secure development and operation of software systems that use container-based virtualization. It protects containers, images, registries, Kubernetes/Docker clusters, and orchestration components across the full lifecycle: from CI/CD pipelines through runtime enforcement. Security flaws in the platform can directly impact critical services and the overall stability of the cloud environment.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

### 1. Centralized management console and API
- Authentication/authorization bypass in the central multi-cluster management console, enabling unauthorized control over clusters and security policies.
- Cross-site scripting (XSS) or cross-site request forgery (CSRF) in the admin UI for managing policies, users, and configuration, potentially enabling actions as a privileged account.

### 2. Image and registry scanning
- Evasion/bypass of CVE scanning for container images (including those based on Astra Linux or RedOS), potentially allowing vulnerable components to reach production deployments.
- SSRF in registry integration features (Artifactory, Nexus, GitLab Registry, Yandex Container Registry) via registry APIs, which could be used to reach internal services or infrastructure components.

### 3. Admission controller
- Bypassing deny rules enforced at the admission controller level to execute commands (exec) in a container.
- Cluster takeover scenarios, including escalation to cluster-admin, caused by vulnerabilities in admission webhooks, service account handling, or token validation (TokenReview API).
- Circumventing admission policies to deploy unsafe workloads (for example, privileged containers or containers with sensitive host volume mounts).

### 4. Runtime security
- Evasion of eBPF-based runtime monitoring used to detect suspicious behavior in containers.
- Tampering with or taking over management of the node-level protection agent (DaemonSet).
- Container escape to the host OS even with syscall monitoring and runtime policies enabled.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT Container Security

Bug bounty program for PT Container Security

# Bug bounty program for PT Application Inspector
The PT Application Inspector bug bounty program focuses on identifying and validating vulnerabilities that may undermine AppSec analysis processes, falsify or skew SAST/DAST/IAST/SCA results, expose source code or analysis artifacts, or enable the platform to be abused as an initial access vector into customer environments.

PT Application Inspector is an end-to-end application security testing platform that brings together SAST, DAST, IAST, and SCA, along with signature- and pattern-based detection. It is used for applications ranging from public-facing services to high-impact enterprise and government systems. Security flaws in the platform can directly reduce the trustworthiness of findings and weaken SDLC security.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

### 1. Web interface and management API
- Authentication bypass in the management interface enabling unauthorized access to projects, analysis results, or system settings.
- Cross-site scripting (XSS) in inputs related to projects, scan settings, or reports that could lead to script execution in the victim's browser.
- Insecure deserialization in API endpoints that may result in arbitrary code execution and component compromise.
- Path traversal in source code upload/ingestion workflows that could allow arbitrary file read or overwrite on the server.

### 2. Source code analysis
- Manipulating analysis outcomes via injections into project metadata, causing false negatives/false positives in vulnerability findings.
- Incorrect processing of known vulnerabilities (CVEs) that could hide real issues in the target codebase or produce fraudulent findings.

### 3. Vulnerability database
- SQL injection in vulnerability search and filtering mechanisms that could expose system data or impact the system's availability.
- Cross-site scripting (XSS) in generated reports that could enable session hijacking or actions impersonating the victim user.
- Circumventing signature database integrity checks to tamper with or disable detection rules.

### 4. Rule engine
- Remote code execution (RCE) through custom analysis rules that are used to extend or customize analysis behavior.
- Unauthorized modification of built-in analysis rules due to vulnerable access control, leading to manipulated or unreliable scan results.

### 5. CI/CD integrations
- SSRF in integrations with CI/CD platforms (such as Jenkins, GitLab) that could be used to attack internal services or infrastructure.
- Exposure of CI/CD/build credentials used for automated pipeline scans.
- Remote code execution (RCE) through CI/CD hook handling, potentially compromising the build agents or development environment.

### 6. Architecture and deployment
- Container isolation weaknesses that could enable container escape and host compromise.
- Disclosure of sensitive information via error messages that could aid further exploitation or expose internal architecture details.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT Application Inspector

Bug bounty program for PT Application Inspector

# Bug bounty program for PT Sandbox
The PT Sandbox bug bounty program focuses on finding and confirming vulnerabilities that may allow attackers to evade malware detection, run malicious code outside the isolated analysis environment, compromise the sandbox infrastructure, or reduce the overall effectiveness of defenses against targeted attacks.

PT Sandbox is an on-premises sandbox designed to analyze unknown and advanced malware, including zero-day exploits, ransomware, and targeted attacks. It combines static and behavioral analysis with correlation rules, network sensors, machine learning techniques, and OS-level monitoring. Security issues in PT Sandbox could cause malicious objects to go undetected, break the isolation of the analysis environment, and lead to compromise of the product's components and the related infrastructure.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information
For the purposes of this program, vulnerabilities are grouped into bypass levels that indicate how deep and severe its impact is on PT Sandbox's analysis and isolation mechanisms.

## Isolation bypass

| Vulnerability name | Description | Requirements for the attack vector |
| --- | --- | --- |
| Sandbox escape | A file submitted for behavioral analysis is able to break out of the sandbox by changing its execution context and executing code on the host OS or at the hypervisor level. To qualify as a bypass, the outcome must be arbitrary code execution on the host system or the ability to disrupt the host system's operation. | The researcher is able to submit files for analysis from outside the sandbox using any supported submission method. Manual behavioral analysis of files via the product UI is permitted. |

### Bypass of document and file format detection

| Vulnerability name | Description | Requirements for the attack vector |
| --- | --- | --- |
| Malicious document missed                         | Undetected execution of malicious code in the user's context, via documents from widely used office applications (MS Office, LibreOffice, PDF, and others). Environment-dependent malicious behavior that only triggers outside the PT Sandbox environment is allowed.            | The file must run with a single user click, must not require additional software, and must be intended for a supported platform and OS. |
| Concealing an active element in an office document | The malicious active element successfully performs malicious actions, but PT Sandbox does not detect it during static analysis. Techniques may include OLE objects, macros, DDE, ActiveX, JavaScript, OpenAction, external data sources, and Office add-ins. | The file must be a valid document, must start via a user click, and must be intended for a supported platform and OS.                     |
| Hiding a common format from behavioral analysis | A valid executable or document is mistakenly treated as non-active and therefore is not submitted to the virtualized environment for behavioral analysis (for example, an EXE file or an office document).                                                                                 | The file must be intended for a platform and OS supported by PT Sandbox.                                                           |

### Partial bypasses and interface vulnerabilities

| Vulnerability name | Description | Requirements for the attack vector |
| --- | --- | --- |
| Malicious executable missed | Undetected execution of malicious code in the user's context via executable files (EXE, ELF). Environment-dependent malicious behavior that only triggers outside the PT Sandbox environment is allowed. | The file must start with a single user click, must not rely on any additional preconditions, and must be intended for a supported platform and OS.                |
| Web interface and API: authorization bypass | Security issues in the web interface and public API, including authorization bypass, XSS triggered by content submitted for analysis, insecure deserialization, and path traversal when uploading files.             | The researcher is able to submit files through the web UI, the public API, or email-based integrations, and has network access to the exposed system services. |


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT Sandbox

# Bug bounty program for PT Application Firewall
The PT Application Firewall bug bounty program focuses on identifying and validating vulnerabilities that may enable web protection bypass, weaken attack filtering, compromise the UI for security policy management, or allow the WAF to be abused as a bypass point or as an attack amplifier against protected applications.

PT Application Firewall is a web application firewall (WAF) that helps prevent vulnerability exploitation without modifying the protected application. It inspects inbound and outbound HTTP/HTTPS traffic, enforces security policies, and performs behavioral analysis. Vulnerabilities in a WAF can allow attackers to bypass protections or undermine detection logic, potentially giving defenders a false sense of security.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

### 1. Web interface and management API
- Authentication/authorization bypass in the management UI that results in unauthorized access to security policy configuration.
- Cross-site scripting (XSS) in rule configuration or log viewing pages that could be used to hijack an administrator session or execute actions as the administrator.
- SQL injection (SQLi) in input fields used to create custom rules, filters, or exclusion lists.

### 2. Protection engine (WAF bypass)
- HTTP/HTTPS parser evasions using non-standard encodings, request splitting, or HTTP request smuggling.
- Filter evasion via Unicode normalization, case manipulation, non-standard HTTP methods, or crafted request formats.
- Circumventing geolocation/IP restrictions by spoofing client IP headers or leveraging CDNs, proxies, or multi-hop setups.
- Evading rate limiting through distributed traffic or by manipulating identifiers used for session tracking.
- Evading anti-bot defenses (CAPTCHA, JavaScript challenges) using automation and challenge bypass techniques.

### 3. Traffic processing and analysis
- Flaws in protocol parsers (HTTP, XML, JSON) that could cause memory leak, denial of service, or remote code execution (RCE).
- Evasion of file upload inspection using polymorphic payloads or uncommon data formats.
- Breaking or degrading SSL/TLS decryption/inspection by leveraging unusual cipher suites, non-standard handshake parameters or protocol versions, leading to incomplete or incorrect analysis of encrypted traffic.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT Application Firewall

Bug bounty program for PT Application Firewall

# Bug bounty program for PT Data Security
The PT Data Security bug bounty program focuses on identifying and validating vulnerabilities that may enable unauthorized data access, undermine data discovery/inventory and classification, interfere with risk and incident monitoring, or result in sensitive data exfiltration from enterprise data stores.

PT Data Security is a modern data security platform designed to deliver end-to-end visibility and protection across data types and storage locations. It unifies data discovery/inventory, automated classification, and monitoring to provide centralized governance over data storage and processing environments. Security flaws in the platform can directly impact data confidentiality, integrity, and availability, especially for critical or regulated datasets.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

### 1. Management interface and API
- Authentication/authorization bypass that grants access to the product's management UI, allowing an attacker to view or modify system configuration.
- Authentication/authorization bypass in API methods used to manage assets, data classes, risks, and incidents, which could result in unauthorized access to sensitive information.

### 2. Integrations with DBMSs and data storage systems
- Gaining access to plaintext credentials used by the system to inventory and classify content in protected data stores.
- Compromise of a private key or certificate used by the system to decrypt SSL/TLS traffic between users and storage systems, enabling a man-in-the-middle attack and access to data in transit.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT Data Security

# Bug bounty program for MaxPatrol O2
MaxPatrol O2 is designed to automatically detect and handle security incidents in an organization's IT environment.

MaxPatrol O2 streamlines the work of cybersecurity teams by automating incident detection and much of the incident management workflow. Its web interface provides detailed visibility into attacker activity and includes tools to investigate incidents quickly. This improves incident response efficiency, supports timely remediation of security threats, and strengthens overall IT infrastructure security.


## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**


## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

## 1. Web interface and API
- Authentication/authorization bypass in the O2 management interface that results in access to another tenant's or administrator's data and functionality.
- Cross-site scripting (XSS) in any input field that allows an attacker to hijack an administrator's session.
- Server-side request forgery (SSRF) in integration features that allows attacks against internal O2 components or connected sensors.
- Insecure deserialization in an API used to exchange data between O2 components and sensors, which may result in remote code execution (RCE).

## 2. Analysis core (Threat Modeling Engine)
- Tampering with Threat Modeling Engine data in a way that causes an incorrect attack graph and creates defensive blind spots.
- Bypassing event correlation so that malicious activity is not detected (for example, crafting events that O2 cannot reliably correlate into an attack chain).
- Altering or corrupting asset, vulnerability, or network topology data, leading to incorrect risk scoring of activity chains.


## 3. Integrations and sensors
- Tampering with data delivered to O2 from sensors (MaxPatrol SIEM, EDR, PT NAD, or other tools), leading to false alerts or concealment of attacks.
- Remote code execution (RCE) through the processing of files received from integrated systems (for example, if files are analyzed in PT Sandbox).
- Weaknesses in context enrichment functionality, such as SSRF when O2 queries external services to validate IP addresses or file hashes.

## 4. Automated response
- Unauthorized execution of response playbooks that may disrupt business processes (for example, disabling network nodes or user accounts via the integrated EDR tool).
- Evasion of response playbooks that enables an attacker to persist even after detection.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

MaxPatrol O2

# Bug bounty program for MaxPatrol VM
The MaxPatrol VM bug bounty program focuses on identifying and validating vulnerabilities that could impact vulnerability management workflows, corrupt or misrepresent IT asset data, lead to incorrect risk prioritization, or enable MaxPatrol VM to be abused as an initial access vector into a customer environment.

MaxPatrol VM is a next-generation vulnerability management system that supports the end-to-end vulnerability management lifecycle: asset discovery and inventory, vulnerability identification and prioritization, remediation governance, and overall security posture assessment. Security issues in the product can directly influence decision-making, introduce defensive blind spots, and reduce an organization's ability to respond effectively to real-world threats.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

### 1. Web interface and management API
- Authentication/authorization bypass in the management interface that results in unauthorized access to system features.
- Bypassing access control restrictions, including access to another tenant's or organization's data in a multi-tenant architecture.
- Cross-site scripting (XSS) that could be used to hijack an active session or perform actions as the victim user.
- SQL injection (SQLi) or command injection in inputs used to manage assets, define vulnerability-processing rules, or generate reports.
- Insecure direct object references (IDOR) in API, enabling access to another user's or organization's data, configuration, or scan results.

### 2. Asset and data management
- Path traversal in report handling or file upload functionality that could enable arbitrary file read, deletion, or modification on the server.
- Asset data manipulation that causes incorrect host criticality and remediation prioritization, creating blind spots in defense.
- Circumventing data integrity controls to hide certain assets or vulnerabilities from MaxPatrol VM.

### 3. Scanning and analysis
- Evasion of vulnerability detection logic that leads to false negatives (existing vulnerabilities are missed).
- Server-side request forgery (SSRF) in information-gathering or validation features that could be used to target internal infrastructure components or third-party services.
- Breaking or degrading the retrospective analysis feature (used to detect newly disclosed vulnerabilities without rescanning), potentially causing stale or inaccurate security posture data.

### 4. Authentication and authorization
- Access control flaws that allow a low-privileged user to escalate privileges to a system administrator.
- Weaknesses in how credentials for white-box scanning are stored or transmitted, potentially enabling credential theft and reuse.

### 5. Product components and internal interactions
- Using MaxPatrol VM as an intermediary node to attack its own components, internal services, external integrations (LDAP, SSO, and more), or other systems in the customer environment.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

MaxPatrol VM

# Bug bounty program for PT Dephaze
This bug bounty program focuses on finding and validating vulnerabilities in PT Dephaze, an automated continuous security testing solution.

PT Dephaze is an automated pentesting tool that models attacker progression through an organization's infrastructure.
Regular penetration testing is an objective way to assess an infrastructure's security posture. Because traditional pentests happen periodically, security gaps can build up between engagements. PT Dephaze enables ongoing, controlled security assessment so that weaknesses can be fixed before they're abused by attackers.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

## 1. Web interface and management API
- Authentication/authorization bypass affecting the management console for simulations and agents.
- Cross-site scripting (XSS) in sections for creating attack scenarios or viewing reports, allowing an attacker to hijack an administrator's session.
- Insecure deserialization in an API used to schedule tasks or receive results from agents, which may lead to remote code execution (RCE).
- Server-side request forgery (SSRF) in features that check simulation targets, allowing attacks against internal systems.

## 2. Attack simulation engine
- Bypassing the "safe mode" for scenario execution, which may cause disruption of target systems, such as triggering a denial of service on a critical server.
- Manipulation or corruption of simulation outputs (reports) due to weaknesses in how the system collects and aggregates simulation data.
- Unauthorized execution of arbitrary code or commands on a target system outside the set of scenarios explicitly allowed by the approved scenario library.

## 3. BAS agents
- Removing, disabling, or bypassing BAS agent self-protection on a target host without having the necessary privileges.
- Compromising the agent in order to gain control over the system the agent is running on.
- Forging or modifying an agent's telemetry data reported to the central server in order to conceal actual activity or disguise an attack.

## 4. Attack and scenario library
- Updating the attack library from an untrusted external source (for example, by exploiting a vulnerability in the update mechanism).
- Injecting a malicious scenario into the shared library to be later executed by other users of the system.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |
 

Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT Dephaze

# Bug bounty program for MaxPatrol SIEM
The MaxPatrol SIEM bug bounty program focuses on identifying and validating vulnerabilities that could impact the collection, storage, or analysis of security event data, or that could allow MaxPatrol SIEM to be abused as an initial access point for attacks against a customer environment.

MaxPatrol SIEM is designed to collect, store, and analyze event data from an organization's IT infrastructure. This supports security monitoring across the whole infrastructure and also at the level of specific departments, hosts, and applications.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

### 1. Web interface and management API
- Cross-site scripting (XSS) that could be used to hijack an administrator session or execute actions with administrator privileges.
- Cross-site request forgery (CSRF) that could allow unauthorized changes to system configuration.
- Insecure direct object reference (IDOR) that could allow a user to access or delete another tenant's data or assets.
- SQL injection in API parameters or UI inputs used for asset management or data collection task management.

### 2. Authentication and authorization
- Authentication/authorization bypass at any point in the authentication flow (for example, during password reset) that results in unauthorized access to system features.
- Access control flaws that allow a low-privileged user to escalate privileges to a system administrator.
- Security issues in the single sign-on (SSO) implementation.

### 3. Data processing and correlation
- Server-side request forgery (SSRF) in event enrichment features (for example, when querying external services to validate IP addresses), which could be used to target internal systems.
- Insecure deserialization in event processing and correlation logic that may result in arbitrary code execution.
- Path traversal issues in the handling of log or configuration files collected from monitored assets.

### 4. Integrations and third-party services
- Insecure storage of sensitive data, including credentials used to integrate with external systems.
- Remote code execution (RCE) through file parsing/analysis in integrated components (for example, during file inspection in a sandbox).

### 5. Architecture and deployment
- Docker container weaknesses that allow container escape and host compromise.
- Arbitrary file read on the SIEM system due to vulnerabilities in underlying components (for example, LogSpace or Elasticsearch).


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

MaxPatrol SIEM

# Bug bounty program for PT Industrial Security Incident Manager (ISIM)

PT Industrial Security Incident Manager (ISIM) serves as a centralized hub for monitoring the security of industrial IT/OT environments.
PT ISIM delivers end-to-end security monitoring for industrial IT/OT infrastructure, helping organizations detect modern threats and targeted cyberattacks.

The solution helps organizations address key requirements set by FSTEC of Russia for securing critical information infrastructure (CII) and covers the measures defined in FSTEC Order No. 239, including computer attack prevention and computer incident response.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

## 1. Central console (Overview Center) and API
- Bypassing authentication or authorization in the management interface to obtain administrator-level privileges or gain access to data belonging to another tenant or distributed site.
- Cross-site scripting (XSS) in the incident viewing interface or network topology visualization pages, allowing an attacker to hijack an administrator session.
- Insecure deserialization in the API used to aggregate data from sensors, enabling remote code execution (RCE).

## 2. Sensors (View Sensors) and traffic analysis
- Techniques that bypass the sensor's deep packet inspection (DPI) of industrial protocols (such as Siemens S7, IEC 60870-5-104, Modbus TCP, or OPC UA), for example by using unusual encodings, packet fragmentation, or undocumented PLC functions.
- Forging, altering, or corrupting telemetry data reported by the sensor to the central console, so that malicious activity in the OT network is concealed.
- A denial-of-service (DoS) condition in the sensor triggered by crafted network traffic, causing loss of visibility and creating a monitoring blind spot.

## 3. Threat detection mechanisms
- Evasion of signature-based detection rules and the PT ISTI database by using obfuscation methods that make malicious activity look like normal OT traffic.
- Circumventing behavioral analysis and network integrity controls so that an attacker can stay unnoticed during unauthorized access to an OT network or while making changes to a PLC project.
- Flooding the system with large volumes of false alerts in order to distract from an actual attack.

## 4. Control of PLCs and industrial process operations
- Achieving unauthorized control over PLCs (modifying firmware, PLC projects, or operating modes) by exploiting weaknesses in PT ISIM's detection logic that should identify and flag these actions.
- Concealing unauthorized modifications of industrial process parameters, such as setpoints and equipment operating modes, even though PT ISIM is intended to detect these changes.


**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT ISIM

Bug bounty program for PT Industrial Security Incident Manager (ISIM)

# Bug bounty program for MaxPatrol 360

MaxPatrol 360 is a unified platform for security operation center (SOC) investigation and operational management, aimed at centralizing the full lifecycle of cybersecurity incident handling. It acts as a "single pane of glass" to manage security expertise, automate incident response, and provide situational awareness across complex infrastructures

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

## 1. Centralized management console & API
- Authentication bypass or authorization bypass in the centralized management console that leads to gaining platform administrator privileges or access to another tenant's data.
- Cross-site scripting (XSS) in any UI input field that could be used to hijack a system administrator's session.
- Insecure deserialization in an API used for data exchange between platform components, enabling remote code execution (RCE).

## 2. Inter-module communication and data
- Issues that impact the integrity or confidentiality of data exchanged between platform modules (for example, transmission over unencrypted channels, lack of signature verification, or message tampering/forgery).

## 3. Automated response
- Unauthorized execution of response playbooks that may disrupt business processes (for example, disabling network nodes, blocking users, or modifying security policies without authorization).

**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

MaxPatrol 360

MaxPatrol 360 is a unified platform for security operation center (SOC) investigation and operational management, aimed at centralizing the full lifecycle of cybersecurity incident handling. It acts as a "single pane of glass" to manage security expertise, automate incident response, and provide situational awareness across complex infrastructures

# Bug bounty program for PT Network Attack Discovery
The PT Network Attack Discovery bug bounty program focuses on finding and confirming vulnerabilities that may cause attack detection to be unreliable, expose or compromise network activity data, interfere with incident investigation workflows, or allow parts of the system to be used as an entry point into a customer environment.

PT Network Attack Discovery is an NDR/NTA platform that detects attacks both at the network perimeter and inside an enterprise network. It helps uncover hidden threats and suspicious activity, including by analyzing encrypted traffic, and stores and correlates data on attacks. It also integrates with other security tools. Security issues in the product can have a direct effect on infrastructure security and on the accuracy and trustworthiness of incident response decisions.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

### 1. Web interface and management API
- XSS or CSRF vulnerabilities in the management interface that allow an attacker to change detection parameters, modify event correlation rules, or gain access to sensitive system data.
- Authentication bypass or access control weaknesses (including IDOR) in the management console that enable access to data belonging to another remote site, subsidiary site, or installation, or enable obtaining administrator privileges.
- SQL injection (SQLi) or command injection flaws that enable arbitrary database queries or command execution within the security context of the product's server-side components.

### 2. Traffic analysis and detection
- Crafted, spoofed, or otherwise malformed network traffic that can trigger a denial of service (DoS) in traffic analysis components or enable remote code execution (RCE) on a sensor.
- Security flaws in the product's network protocol parsers (more than 85 protocols supported) that may lead to memory leak, inaccurate or unreliable analysis of network traffic, or execution of attacker-controlled code.

### 3. Data storage and processing
- Path traversal when accessing stored PCAP files or extracted objects, enabling arbitrary file read, deletion, or overwrite on the server.
- Vulnerabilities that let an attacker tamper with or remove the forensic evidence associated with previously detected attacks, potentially hiding signs of compromise and distorting incident investigation findings.

### 4. Integrations and external systems
- SSRF vulnerabilities in features that integrate with external systems (such as sending files to PT Sandbox for checking or delivering alerts to a SIEM system), which could be abused to make the product issue requests to internal services and other infrastructure components.
- Insecure deserialization when processing data received from PT MultiScanner or other products in the Positive Technologies ecosystem, potentially resulting in attacker-controlled code execution or broader compromise of system components.

**Note. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

PT NAD

Bug bounty program for PT Network Attack Discovery

# Bug bounty program for MaxPatrol EDR
The MaxPatrol EDR bug bounty program is intended to help identify and validate security vulnerabilities in MaxPatrol EDR, an endpoint detection and response tool.

MaxPatrol EDR is a comprehensive endpoint security solution.
As enterprise IT environments evolve quickly, adversarial tools and techniques evolve as well, becoming more sophisticated and better able to bypass traditional defenses.

To detect these threats early and respond effectively, organizations need endpoint context, continuous threat tracking, and strong correlation, connecting individual events into a coherent view and building attack chains. MaxPatrol EDR helps quickly detect advanced threats and targeted attacks, respond to incidents with confidence, and automate routine tasks in line with an organization's cybersecurity requirements and operational processes.

## Limitations
**When the program launches, access to the product's test environments will be limited.**
**Broader access will be provided later, once the supporting infrastructure and operational procedures are finalized.**

## General information

Types of vulnerabilities eligible for review. We accept vulnerability reports in the following categories (including, but not limited to):

## 1. Centralized management console and API
- Authentication bypass or authorization bypass affecting the EDR management console.
- Cross-site scripting (XSS) in the UI used for viewing security events and investigating incidents.
- Insecure deserialization in the API used to ingest telemetry from agents.
- Attacks on the management console using spoofed or unauthorized agents (for example, DoS, or abusing an agent vulnerability to impact the server).
- Telemetry delivery tampering or integrity violations on the path from the agent server to the SIEM system.
- Server-side request forgery (SSRF) in SIEM/SOAR integration features.

## 2. EDR agents on endpoints
- Bypassing or disabling EDR agent self-protection by exploiting a vulnerability in its kernel driver.
- Uninstalling or stopping the agent without appropriate privileges (for example, as a standard user).
- Causing the running agent to malfunction by manipulating the operating environment (for example, system configuration, dependencies, or resource limits).
- Bypassing application control to run code that violates EDR policies.

## 3. Proactive protection
- Bypassing built-in anti-exploitation controls such as ASLR, DEP, Control Flow Guard, and similar mechanisms.

**Note 1. Only reports relating to the Windows EDR agents and the server-side components (management console) will be reviewed.**
**Note 2. Findings that do not present a practical security risk (for example, purely theoretical issues or reports without exploit validation) may be rejected or treated as informational and are not eligible for a bounty payout.**

## Rewards

Payout amounts are listed in the table below:

|Severity| Payout amount |
|---|---|
|Critical | RUB 300,000–500,000 |
|High | RUB 150,000–300,000 |
|Medium | RUB 50,000–150,000 |
|Low | RUB 0–50,000 |


Rewards are paid only for attack scenarios that can be reproduced on an officially supported product version that is fully patched with all available updates. Reports for end-of-support versions are accepted as well, but a payout for such issues is not guaranteed.

Vulnerability severity is assessed during triage and validation based on the issue's impact on the product security.
The product security team makes the final severity determination.

## Participation requirements
Participants must be at least 18 years old.
Researchers aged 14–18 are allowed to participate only if they can present the written consent of a parent or a legal guardian.
Current Positive Technologies employees, as well as former employees whose employment ended less than three years ago, may take part in the program but are not eligible to receive a bounty payout.

### Participant obligations:
* Follow the vulnerability disclosure rules of the Positive Technologies program and the Standoff 365 Bug Bounty platform.
* Follow the rules related to the handling of sensitive information. Do not gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
* Maintain communication with the security team, send them reports on discovered vulnerabilities according to the program requirements, and provide feedback if they have questions about the report.
* Do not publicly disclose any details of the vulnerabilities discovered. Positive Technologies retains the right to decide if and when information about the reported vulnerability will be published.
* Public disclosure of a vulnerability is allowed only after a fix is released and a publicly registered CVE/BDU identifier has been assigned.
* If a researcher requests disclosure of the report, Positive Technologies will initiate the coordination process to register a vulnerability identifier.

## Rewards for reported vulnerabilities
**No reward will be given for:**
- Reports generated by security scanners and other automated tools.
- Disclosure of non-sensitive information (such as software name and version or technical characteristics and metrics of the system).
- Information about IP addresses, DNS records, and open ports.
- Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
- Reports of vulnerabilities whose exploitation is prevented by security tools, if the researcher does not demonstrate how to bypass the security tools.
- Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
- Reports indicating the lack of SSL or other best current practices (BCPs).
- Reports of vulnerabilities already reported by other participants (duplicate reports).
- 0-day or 1-day vulnerabilities identified by our security team based on information from open sources.
- Reports of brute-force vulnerabilities without providing an attack method that is significantly more efficient than a straight-forward brute-force approach.

MaxPatrol EDR

# What reports and vulnerabilities are accepted
As part of the Bug Bounty program, we review reports of real vulnerabilities that may affect the security of the cloud platform services and K2 Cloud customer data.

### Priority
- Remote Code Execution (RCE);
- Injections (SQL, XML, SSTI, etc.);
- Reading or writing arbitrary files (LFI, RFI);
- SSRF (with demonstration of real impact);
- Access control vulnerabilities (IDOR, vertical/horizontal escalation);
- Authentication and authorization deficiencies;
- Business logic errors allowing bypass of financial/functional restrictions;
- Disclosure of sensitive or confidential information;
- Other vulnerabilities capable of affecting platform/data operation or security.

### Special attention
Critical scenarios related to gaining control over infrastructure, bypassing cloud isolation, accessing other customers' resources, violating service integrity and availability.
- - -
# Program scope
The program scope covers all resources that are part of the K2 Cloud platform:

### Web console for managing cloud resources
* [console.k2.cloud](https://console.k2.cloud)

### Cloud platform service domains
* autoscaling.ru-msk.k2.cloud
* autoscaling.ru-spb.k2.cloud
* backup.ru-msk.k2.cloud
* backup.ru-spb.k2.cloud
* cloudtrail.ru-msk.k2.cloud
* cloudtrail.ru-spb.k2.cloud
* cloudwatch.ru-msk.k2.cloud
* cloudwatch.ru-spb.k2.cloud
* directconnect.ru-msk.k2.cloud
* directconnect.ru-spb.k2.cloud
* ec2.ru-msk.k2.cloud
* ec2.ru-spb.k2.cloud
* efs.ru-msk.k2.cloud
* efs.ru-spb.k2.cloud
* eks.ru-msk.k2.cloud
* eks.ru-spb.k2.cloud
* elb.ru-msk.k2.cloud
* elb.ru-spb.k2.cloud
* ext.ru-msk.k2.cloud
* ext.ru-spb.k2.cloud
* iam.k2.cloud
* paas.ru-msk.k2.cloud
* paas.ru-spb.k2.cloud
* primary.k2.cloud
* route53.k2.cloud
* ru-msk.console.k2.cloud
* ru-spb.console.k2.cloud
* s3.ru-msk.k2.cloud
* s3.ru-spb.k2.cloud

The current [API reference and description](https://docs.k2.cloud/en/api/index.html) of platform services are always available on our [public documentation website](https://docs.k2.cloud/en/).

- - -
# What is not accepted within the program
Some categories of issues are not accepted within the K2 Cloud Bug Bounty program and are not subject of bounty.

### Findings without practical value
- automated reports from scanners and other tools, if no proof of manual vulnerability exploitation is provided;
- disclosure of non-confidential or publicly available information: software version, username, public profiles, image metadata, technical headers and parameters;
- messages about best-practices non-compliance (e.g., absence of certain HTTP headers or CSP/DMARC/SPF/DNSSEC settings) are not accepted as standalone vulnerabilities unless real security impact is demonstrated (e.g., possibility of clickjacking attack, email spoofing, etc.);
- messages about open ports, IP addresses, DNS records without practical exploit;
- vulnerabilities related only to product/protocol version (e.g., "OpenSSL X.Y.Z is used"), without real exploitation scenario;
- reports about "logical" or "UI" errors without security impact.

### Theoretical or impractical vulnerabilities
- Blind SSRF and open redirects if security impact is not demonstrated or possibility of exploitation for access to sensitive data is not shown;
- theoretical attacks not confirmed by practical Proof of Concept;
- problems related to demo stands, test environments, training domains and services if there is no threat to main infrastructure.

### Methods excluded from the program
- attacks affecting service availability (DoS, flood, spam, brute-force, performance tests, resource exhaustion);
- social engineering attacks (phishing, interaction with customers, partners or company employees);
- vulnerabilities requiring physical access, modified or compromised devices, etc.

### Other exclusions
- vulnerabilities in third-party services, client projects or external integrations that do not affect K2 Cloud platform security and its users
- problems related to absence of obfuscation or code reversal possibility without confirmed security impact;
- errors discovered by current or former company employees (within a year after dismissal);
- information obtained from public buckets in K2 Cloud;
- vulnerabilities of the 0-day and 1-day classes may be considered duplicates within several weeks after their public disclosure; the decision on reward payment is made individually and is not guaranteed.
- - -
# Testing rules and ethics
To ensure service security and proper program operation, follow these principles.

### Test responsibly
- use only your accounts or specially allocated test accounts;
- do not disrupt service operation, do not delete or modify other users' data;
- avoid actions that may lead to data loss, impact on other users or customers;
- do not do actions that may affect service availability for customers (DoS, flood, brute-force, etc.);
- do not use automated scanning tools with high intensity.

### Prohibited
- researching vulnerabilities in **K2 Cloud customer infrastructures**: this applies to all addresses in the form of \*.elastic.k2.cloud, s3.ru-msk.k2.cloud/\*, \*.website.ru-msk.k2.cloud, s3.ru-spb.k2.cloud/\* and \*.website.ru-spb.k2.cloud (however, you may investigate similar resources that you have created yourself);
- social engineering: phishing, spam, attempts to gain access through customers, partners or company employees;
- physical impact on equipment, offices, data centers and other company facilities;
- publishing or disclosing vulnerability information before they are fixed and without written consent from K2 Cloud;
- using discovered vulnerabilities for personal gain or bypassing tariff limitations.

### Restrictions on especially sensitive categories
- to confirm vulnerabilities like RCE, SQL injections, LFI/RFI, SSRF and other potentially dangerous bugs, use the minimal impact and safe exploits for Proof of Concept (e.g., sleep, reading /etc/passwd, request demonstration);
- for dangerous operations (privilege escalation, infrastructure interference) - coordinate actions with the K2 Cloud security team before testing at [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).

### Maintain confidentiality
- all information about discovered vulnerabilities must remain between the researcher and K2 Cloud security team until written permission for publication is obtained.

### Participation principles
- follow ethics and laws - your actions must comply with information security rules and applicable legislation;
- follow program conditions - review the rules before starting testing;
- respect team decisions - if you disagree, justify your position and provide evidence, we are open to dialogue;
- the final reward decision is made by the K2 Cloud team.
- - -
# Report formatting requirements
Reports are accepted exclusively on the Standoff365 platform. To expedite review of your request and increase your chances of receiving a reward, include in the report:
- **Vulnerability name and description**
- **Category**
- **CVE (if available)**
- **Criticality level analysis according to CVSS v3.1**
- **Address (or component) of the affected service**
- **Step-by-step exploitation scenario description:**
 - how the vulnerability was discovered;
 - what actions, parameters or conditions are needed for reproduction;
 - who and how can exploit the vulnerability.
- **Technical Proof of Concept (PoC):**
 - request/response examples, commands, scripts;
 - screenshots, video - if this helps verify the vulnerability (links to external sources are prohibited);
 - testing date and time.
- **Impact assessment:**
 - what data, services, users or infrastructure may be affected.
- **Remediation recommendations**
- **Your K2 Cloud account login (if used)**

> Each report should describe one vulnerability. If the exploit is built on a chain of vulnerabilities, you may include them in one report. In this case, the description must be made as clear as possible and all required information for each vulnerability must be indicated in the report. 
> Screen recording and screenshots are welcome but do not replace detailed textual description and PoC. 
> Reports without necessary data for reproduction may be returned for revision.

 Please ensure the report is structured and easy to read. Brief text error checking will make it more understandable and expedite review.
- - -
# Report processing and rewards
### Review process
- All reports are checked by the K2 Cloud security team.
- We usually provide the first response within **5 business days**.
- Full report review, validity determination and criticality level assessment usually takes up to **14 business days**.
- The decision on vulnerability seriousness, need for remediation and reward amount is made individually, considering: technical novelty, real impact level, exploitation complexity, affected services, potential mass impact and other factors.
- Rewards are paid only for the first valid reports on a specific vulnerability (duplicates are not paid).
- Vulnerabilities without confirmed security impact or with theoretical scenarios may be recognized as informative and remain unpaid.
- The reward amount is determined individually and depends on vulnerability seriousness and its security impact.
- Reward amount determination is carried out within **30 calendar days** after vulnerability validity confirmation and final report status establishment.
- In exceptional cases, review or payment timeframes may be increased, but in such cases we will definitely notify the researcher about reasons and estimated timelines.

### Reward amounts
|Vulnerability type|Reward range|Explanation|
|---|---|---|
|Remote Code Execution (RCE), access to internal infrastructure|150 000 — 500 000 ₽|Implies confirmed ability to execute arbitrary code on internal infrastructure servers of the cloud platform or gain access to internal services/networks. Theoretical scenarios and reports without PoC are not paid.|
|Server-side injections (SQLi, XML, SSTI, etc.)|50 000 — 200 000 ₽|Important are cases where the vulnerability leads to reading/changing data or system compromise. Reports based only on DBMS version or without confirmed data access are not paid.|
|Reading/writing arbitrary files (LFI, RFI, XXE)|50 000 — 150 000 ₽|Special attention is given to cases of accessing sensitive system or user files, or the ability to upload and execute files.|
|Privilege escalation (vertical or horizontal)|30 000 — 90 000 ₽|Horizontal - access to other users' data. Vertical - user → admin. Especially valuable are scenarios allowing management of others' resources or execution of admin functions.|
|Insecure Deserialization with confirmed impact|30 000 — 90 000 ₽|Only cases where the vulnerability leads to: - remote code execution (RCE); - privilege escalation or bypass of control mechanisms; - unauthorized access to confidential data; - manipulation of critical object attributes (e.g., role, access rights). Attacks leading exclusively to denial of service (DoS) are considered out of scope.|
|SSRF (with proven security impact)|20 000 — 60 000 ₽|The vulnerability must allow access to internal services, cloud metadata or perform malicious actions. Blind SSRF without demonstrated impact (e.g., without data leakage or filter bypass) is not paid.|
|Access control vulnerabilities, IDOR, disclosure of critical/confidential data|20 000 — 60 000 ₽|These include cases where one user can access data or operations of another. Information about access to public or insignificant data (e.g., nicknames) may be recognized as informative and remain unpaid.|
|Authentication and session management errors|20 000 — 60 000 ₽|Category includes login bypass, session fixation or theft, token compromise. Comments like "session lives too long" without exploit are not paid.|
|XSS (only with proven impact: token theft, action execution on behalf of user)|20 000 — 60 000 ₽|Important are substantial cases where, for example, XSS allows stealing tokens, executing actions on behalf of users or affecting sensitive data. Self-XSS or XSS affecting only the researcher is not paid.|
|CSRF (only if it affects critical functions)|20 000 — 60 000 ₽|Valuable are cases where the attack allows changing passwords, managing users and their rights, changing important service settings, billing parameters, etc. Logout CSRF or insignificant actions may be recognized as informative and remain unpaid.|
|Business logic errors, bypass of financial and functional restrictions|individually|Reward is determined individually as impact may be unique. Example: bypassing paid features or tariff restrictions.|
|Other confirmed vulnerabilities|individually|Main condition - real confirmed impact on user or infrastructure security.|

### How we determine criticality and reward amount
Vulnerability criticality assessment is conducted by the K2 Cloud security team and is always based on a combination of factors. After receiving a report, we consider not only technical details but also practical risk for customers and services. The analysis considers, among other things:
- how the vulnerability can affect user data and their availability;
- scale of the problem: does it affect one customer, a separate service, or infrastructure as a whole;
- level of preparation and conditions required for an attacker to exploit (e.g., presence of special rights or chains of multiple bugs);
- probability of discovery and attack repetition by other researchers or attackers;
- need for end-user involvement or possibility to automate the attack;
- possible business consequences, including reputational risks and customer trust.

This combination of criteria allows us to assess severity as objectively as possible and prioritize remediation.
For unification of assessment, we use **CVSS v3.1**, but the final decision is always made by the security team based on context and specifics of the particular case.

### How criticality relates to payouts
The rules of the program specify a reward range for each vulnerability category. The specific amount paid to the researcher depends on the vulnerability's criticality level:
- vulnerabilities with limited impact receive rewards closer to the lower range boundary;
- more serious problems that may affect multiple services or users are assessed in the middle of the range;
- the most dangerous cases (mass impact, critical business or customer damage) are rewarded closer to the upper range boundary.

> For some categories (e.g., **XSS** or **CSRF**) maximum impact is usually limited to the scope of a single user or session. In such cases, rewards are distributed within low and medium criticality levels, and the upper range limit applies only in the presence of truly non-standard impact (e.g., XSS in admin panel, bypass of protective mechanisms, or using XSS as part of a chain for a more serious attack).
 
The payout amount is directly related to the risk level of the discovered vulnerability.

### Duplicate handling rules
We pay a reward only for the first received report (provided it contains all the information necessary to reproduce the vulnerability). Any subsequent reports covering the same vulnerability will be marked as duplicates. Reports describing similar attack vectors may also be considered duplicates if our security team believes that information from a single report is sufficient to fix all possible attack vectors or issues.
The original report may be submitted either by an external researcher or be a description of the issue prepared by the K2 Cloud team.
- - -
# Technical details and support
### Access to K2 Cloud
To obtain access to a test account in K2 Cloud for research purposes:
1. Write to [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).
2. In the email, provide a link to your confirmed profile on the Standoff365 platform.
3. We will provide access and necessary consultations.

### Contacting the team
For questions about Bug Bounty participation, report formatting, or policy clarification, write to [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).
We are always open to constructive dialogue with researchers.

### Updating and changing rules
K2 Cloud reserves the right to change Bug Bounty program conditions, as well as report assessment criteria and payment procedures without prior notice.
- - -
# Let's make K2 Cloud safer together
We thank everyone who helps make K2 Cloud safer and more reliable for customers!

Your research is valued, and we are ready to cooperate honestly and openly with everyone interested in real improvement of information security level of our services.

All questions, wishes and suggestions for program development are accepted at [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).

K2 Cloud

[K2 Cloud](https://k2.cloud/) is a cloud provider with integrator expertise. We build and protect cloud infrastructure for our customers and strive to deliver the highest possible service reliability.
To make our cloud platform even more secure, we are launching a Bug Bounty program and invite information security professionals to collaborate with us in identifying vulnerabilities.

[K2 Cloud](https://k2.cloud/) is a cloud provider with integrator expertise. We build and protect cloud infrastructure for our customers and strive to deliver the highest possible service reliability.
To make our cloud platform even more secure, we are launching a Bug Bounty program and invite information security professionals to collaborate with us in identifying vulnerabilities.

## Правила для нас

Мы уважаем время и усилия наших исследователей;
Мы отвечаем в течение 5 рабочих дней;
Мы обрабатываем отчеты в течение 10 рабочих дней после ответа;
Мы можем увеличить сроки обработки отчетов, но в таком случае мы проинформируем вас о задержке;
Мы определим сумму вознаграждения в течение 15 рабочих дней после обработки;
Мы сделаем все возможное, чтобы в процессе обработки отчета вы были в курсе нашего прогресса.

## Правила для вас

Будьте этичным хакером и уважайте конфиденциальность других пользователей;
Соблюдайте правила, которые устанавливает Минцифры России в рамках данной программы, а также правила платформы The Standoff 365 Bug Bounty;
Соблюдайте правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, которая была получена случайным образом ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным;
Избегайте ситуаций, которые могут привести к прерыванию или ухудшению качества наших услуг. Инструменты автоматического сканирования должны быть ограничены 30 запросами в секунду к одному целевому узлу, суммируя все инструменты и потоки, работающие параллельно;
Поддерживайте общение с командой безопасности Минцифры России, направляйте ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давайте обратную связь, если у специалистов возникнут вопросы по отчету;
Сообщайте нам обо всех обнаруженных уязвимостях путем создания отчета (кнопка **Сдать отчет** рядом с названием программы);
Участниками программы могут быть только граждане Российской Федерации в возрасте от 18 лет.

## Скоуп

* do.gosuslugi.ru
* 109.207.2.97


В программе участвуют только указанные домены и IP-адреса. Все остальные домены и ресурсы (включая базы данных, почтовые серверы и так далее) в скоуп не входят.

## Вознаграждения за уязвимости

| Уязвимость (по уровню опасности) | Вознаграждение |
| ------------ | ------------ |
| Критический | 200 000 – 500 000 ₽ |
| Высокий | 50 000 – 200 000 ₽ |
| Средний | 30 000 – 50 000 ₽ |
| Низкий | 5 000 – 15 000 ₽ |

## Публичное раскрытие информации об уязвимости

**Публичное раскрытие информации о найденных в рамках программы уязвимостях в данный момент не предусмотрено.**

## Мы не принимаем и не рассматриваем:

*	Отчеты сканеров уязвимостей и других автоматизированных инструментов;
*	Раскрытие информации, не являющейся конфиденциальной, например версии продукта;
*	Раскрытие публичной информации о пользователе, например nickname;
*	Отчеты, основанные на версии продукта/протокола без демонстрации реального наличия уязвимости;
*	Отчеты об отсутствующем механизме защиты/лучшей текущей практике (например отсутствие CSRF-маркера, защита от framing/clickjacking) без демонстрации реального влияния на безопасность пользователя или системы;
*	Сообщения об опубликованных и неопубликованных политиках SPF и DMARC;
*	Кроссайтовые подделки запросов, приводящие к выходу из системы (logout CSRF);
*	Уязвимости партнерских продуктов или сервисов, если пользователи/учетные записи ЕСИА не затронуты напрямую;
*	Безопасность рутированных, jailbreaked или иным образом модифицированных устройств и приложений;
*	Возможность обратного инжиниринга приложения или отсутствие бинарной защиты;
*	Open redirections принимаются только в том случае, если определено влияние на безопасность, например возможность кражи авторизационного токена;
*	Ввод неформатированного текста, звука, изображения, видео в ответ сервера вне пользовательского интерфейса (например, в данных JSON или сообщении об ошибке), если это не приводит к подмене пользовательского интерфейса, изменению поведения пользовательского интерфейса или другим негативным последствиям;
*	Same Site scripting, reflected download и подобные атаки с сомнительным воздействием;
*	Отчеты, связанные с CSP, для доменов без CSP и доменных политик с небезопасными eval и/или небезопасными inline;
*	Гомографические атаки IDN;
*	XSPA (сканирование IP/портов во внешние сети);
*	Инъекция формул Excel CSV;
*	Скриптинг в документах PDF;
*   Self-XSS без демонстрации импакта;
*	Атаки, требующие полного доступа к локальной учетной записи или профилю браузера;
*	Атаки со сценариями, где уязвимость в стороннем сайте или приложении требуется как необходимое условие и не демонстрируется;
*	Теоретические атаки без доказательства возможности использования;
*	Уязвимости отказа в обслуживании (DoS), связанные с отправкой большого количества запросов или данных (флуд);
*	Возможность отправки большого количества сообщений;
*	Возможность отправки спама или файла вредоносного ПО;
*	Раскрытие информации через внешние ссылки, не контролируемые Минцифры России (например, поисковые dork’и к приватным защищенным областям robots.txt);
*	Раскрытие неиспользуемых или должным образом ограниченных ключей JS API (например, ключ API для внешнего картографического сервиса);
*	Возможность выполнить действие, недоступное через пользовательский интерфейс, без выявленных рисков безопасности;
*	Уязвимости раскрывающие только учетные записи пользователей, не содержащие пароля или иных персональных данных.

## Недопустимые действия

Исследователям запрещено:

* Воздействовать на учетные записи других пользователей без их разрешения;
* Использовать обнаруженные уязвимости в личных целях;
* Использовать инструменты тестирования уязвимостей, автоматически генерирующие значительные объемы трафика и приводящие к атакам с исчерпанием ресурсов;
* Проводить атаки, наносящие вред целостности и доступности сервисов (например, DoS-атаки, брутфорс-атаки и т.д.), пытаться эксплуатировать уязвимость, нацеленную на исчерпание ресурсов. Следует сообщить о проблеме команде по безопасности Минцифры России, которая проведет атаку в тестовой среде;
* Проводить физические атаки на персонал, дата-центры и офисы Минцифры России или поставщиков услуг;
* Проводить атаки на системы Минцифры России с использованием техник социальной инженерии (фишинг, вишинг и т.д.) и спам-рассылки клиентам, партнерам и сотрудникам;
* Исследовать серверную инфраструктуру, где размещены веб-приложения;
* Проникать во внутренние системы веб-сервисов и приложений информационных систем Минцифры России, а также иных информационных ресурсов Минцифры России. Программа по поиску уязвимостей в веб-сервисах и приложениях информационных систем Минцифры России должна заканчиваться взломом порталов и закреплением на них, строго без дальнейшего проникновения Исследователем во внутренние системы веб-сервисов и приложений информационных систем Минцифры России;
* Совершать попытки получения доступа к учетным записям, данным пользователей или к любым другим конфиденциальным данным, выходящим за пределы действий, минимально необходимых для демонстрации найденной уязвимости;
* Осуществлять целенаправленную выгрузку персональных данных граждан из внутренних систем веб-сервисов и приложений, а также иных информационных ресурсов, не указанных в программе.

## Политика тестирования RCE

Тестирование уязвимостей, которые могут приводить к удаленному исполнению кода, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Выполнения команд ifconfig (ipconfig), hostname, whoami, id;
Чтения содержимого файлов /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini);
Создания пустого файла в каталоге текущего пользователя.

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика тестирования SQL-инъекций

Тестирование уязвимостей, которые могут приводить к внедрению команд SQL, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Получения данных о текущей БД (SELECT database()), ее версии (SELECT @@version), текущего пользователя (SELECT user(), SELECT system_user()) или имени хоста (SELECT @@hostname);
Получения схемы БД (SELECT table_schema), списка таблиц в ней (SELECT table_name) и имен столбцов в таблицах (SELECT column_name);
Выполнения математических, конверсионных или логических запросов (включая использование SLEEP) без извлечения данных (кроме тех, что перечислены выше).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика загрузки и чтения файлов

Тестирование уязвимостей, которые могут приводить к чтению произвольных файлов на сервере или произвольной загрузке файлов, должно выполняться в соответствии с данными правилами:

Запрещенные действия при загрузке файлов:

Изменение, модификация, удаление и замена любых файлов на сервере (включая системные), кроме тех, что ассоциированы с вашей учетной записью либо с учетной записью пользователя, который явно выразил свое согласие;
Загрузка файлов, которые могут вызвать отказ в обслуживании (например, файлов большого размера);
Загрузка вредоносных файлов (например, малвари или шпионского ПО).

При получении возможности чтения произвольных файлов на сервере запрещены любые действия кроме чтения таких файлов, как /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Требования к оформлению отчета

Отчет об уязвимости должен содержать:

* Название уязвимости;
* Название продукта и версию затрагиваемого ПО (компонента);
* Проверку концепции (proof of concept) или подробное описание обнаруженной уязвимости и шагов по ее воспроизведению;
* Описание сценария атаки: кто может использовать уязвимость, для какой выгоды, как она эксплуатируется и т.д.;
* Рекомендации по устранению уязвимости.

Видео и скриншоты могут быть приложены к отчету об ошибке, но не могут его заменить.
Если при исследовании сервисов Минцифры России обнаружено несколько проблем безопасности, необходимо подготовить отчет о каждой выявленной уязвимости отдельно.
Передача информации об обнаруженной уязвимости происходит путем создания отчета (кнопка **Сдать отчет** рядом с названием программы).

ФГИС ДО

The Ministry of Digital Development, Communications and Mass Media of the Russian Federation is a federal executive authority responsible for shaping digital policy and promoting industry growth in the interests of Russian citizens, businesses, and the public sector.

Russian Ministry of Digital Development

## Правила для нас

Мы уважаем время и усилия наших исследователей;
Мы отвечаем в течение 5 рабочих дней;
Мы обрабатываем отчеты в течение 10 рабочих дней после ответа;
Мы можем увеличить сроки обработки отчетов, но в таком случае мы проинформируем вас о задержке;
Мы определим сумму вознаграждения в течение 15 рабочих дней после обработки;
Мы сделаем все возможное, чтобы в процессе обработки отчета вы были в курсе нашего прогресса.

## Правила для вас

Будьте этичным хакером и уважайте конфиденциальность других пользователей;
Соблюдайте правила, которые устанавливает Минцифры России в рамках данной программы, а также правила платформы Standoff 365 Bug Bounty;
Все отправляемые запросы по этой программе должны содержать уникальный HTTP заголовок, который доступен на платформе. Для получения заголовка необходимо выполнить вход в свою учетную запись на платформе;
Соблюдайте правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, которая была получена случайным образом ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным;
Избегайте ситуаций, которые могут привести к прерыванию или ухудшению качества наших услуг. Инструменты автоматического сканирования должны быть ограничены 30 запросами в секунду к одному целевому узлу, суммируя все инструменты и потоки, работающие параллельно;
Поддерживайте общение с командой безопасности Минцифры России, направляйте ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давайте обратную связь, если у специалистов возникнут вопросы по отчету;
Сообщайте нам обо всех обнаруженных уязвимостях путем создания отчета (кнопка **Сдать отчет** рядом с названием программы);
Участниками программы могут быть только граждане Российской Федерации в возрасте от 18 лет.
Информация, полученная в рамках участия в программе, является конфиденциальной. Её распространение (в том числе публикация) на тематических форумах, в чатах (закрытых чатах), социальных сетях и т.п., используя информационно-телекоммуникационную сеть Интернет, возможно только с письменного разрешения Минцифры России.
Все отправляемые запросы по этой программе должны содержать уникальный HTTP заголовок, который доступен на платформе. Для получения заголовка необходимо выполнить вход в свою учетную запись на платформе;
Исследователи обязаны отправлять отчеты обо всех уязвимостях, обнаруженных в сервисах Минцифры РФ.


## Скоуп

* 109.207.1.155
* 109.207.1.178
* 109.207.8.43
* 109.207.1.71
* kcr.gosuslugi.ru
* frgu3.gosuslugi.ru


В программе участвуют только указанные домены и IP-адреса. Все остальные домены и ресурсы (включая базы данных, почтовые серверы и так далее) в скоуп не входят.

## Вознаграждения за уязвимости

| Уязвимость (по уровню опасности) | Вознаграждение |
| ------------ | ------------ |
| Критический | 200 000 – 500 000 ₽ |
| Высокий | 50 000 – 200 000 ₽ |
| Средний | 30 000 – 50 000 ₽ |
| Низкий | 5 000 – 15 000 ₽ |

## Публичное раскрытие информации об уязвимости

**Публичное раскрытие информации о найденных в рамках программы уязвимостях в данный момент не предусмотрено.**

## Мы не принимаем и не рассматриваем:

*	Отчеты сканеров уязвимостей и других автоматизированных инструментов;
*	Раскрытие информации, не являющейся конфиденциальной, например версии продукта;
*	Раскрытие публичной информации о пользователе, например nickname;
*	Отчеты, основанные на версии продукта/протокола без демонстрации реального наличия уязвимости;
*	Отчеты об отсутствующем механизме защиты/лучшей текущей практике (например отсутствие CSRF-маркера, защита от framing/clickjacking) без демонстрации реального влияния на безопасность пользователя или системы;
*	Сообщения об опубликованных и неопубликованных политиках SPF и DMARC;
*	Кроссайтовые подделки запросов, приводящие к выходу из системы (logout CSRF);
*	Уязвимости партнерских продуктов или сервисов, если пользователи/учетные записи ЕСИА не затронуты напрямую;
*	Безопасность рутированных, jailbreaked или иным образом модифицированных устройств и приложений;
*	Возможность обратного инжиниринга приложения или отсутствие бинарной защиты;
*	Open redirections принимаются только в том случае, если определено влияние на безопасность, например возможность кражи авторизационного токена;
*	Ввод неформатированного текста, звука, изображения, видео в ответ сервера вне пользовательского интерфейса (например, в данных JSON или сообщении об ошибке), если это не приводит к подмене пользовательского интерфейса, изменению поведения пользовательского интерфейса или другим негативным последствиям;
*	Same Site scripting, reflected download и подобные атаки с сомнительным воздействием;
*	Отчеты, связанные с CSP, для доменов без CSP и доменных политик с небезопасными eval и/или небезопасными inline;
*	Гомографические атаки IDN;
*	XSPA (сканирование IP/портов во внешние сети);
*	Инъекция формул Excel CSV;
*	Скриптинг в документах PDF;
*   Self-XSS без демонстрации импакта;
*	Атаки, требующие полного доступа к локальной учетной записи или профилю браузера;
*	Атаки со сценариями, где уязвимость в стороннем сайте или приложении требуется как необходимое условие и не демонстрируется;
*	Теоретические атаки без доказательства возможности использования;
*	Уязвимости отказа в обслуживании (DoS), связанные с отправкой большого количества запросов или данных (флуд);
*	Возможность отправки большого количества сообщений;
*	Возможность отправки спама или файла вредоносного ПО;
*	Раскрытие информации через внешние ссылки, не контролируемые Минцифры России (например, поисковые dork’и к приватным защищенным областям robots.txt);
*	Раскрытие неиспользуемых или должным образом ограниченных ключей JS API (например, ключ API для внешнего картографического сервиса);
*	Возможность выполнить действие, недоступное через пользовательский интерфейс, без выявленных рисков безопасности;
*	Уязвимости раскрывающие только учетные записи пользователей, не содержащие пароля или иных персональных данных.

## Недопустимые действия

Исследователям запрещено:

* Воздействовать на учетные записи других пользователей без их разрешения;
* Использовать обнаруженные уязвимости в личных целях;
* Использовать инструменты тестирования уязвимостей, автоматически генерирующие значительные объемы трафика и приводящие к атакам с исчерпанием ресурсов;
* Проводить атаки, наносящие вред целостности и доступности сервисов (например, DoS-атаки, брутфорс-атаки и т.д.), пытаться эксплуатировать уязвимость, нацеленную на исчерпание ресурсов. Следует сообщить о проблеме команде по безопасности Минцифры России, которая проведет атаку в тестовой среде;
* Проводить физические атаки на персонал, дата-центры и офисы Минцифры России или поставщиков услуг;
* Проводить атаки на системы Минцифры России с использованием техник социальной инженерии (фишинг, вишинг и т.д.) и спам-рассылки клиентам, партнерам и сотрудникам;
* Исследовать серверную инфраструктуру, где размещены веб-приложения;
* Проникать во внутренние системы веб-сервисов и приложений информационных систем Минцифры России, а также иных информационных ресурсов Минцифры России. Программа по поиску уязвимостей в веб-сервисах и приложениях информационных систем Минцифры России должна заканчиваться взломом порталов и закреплением на них, строго без дальнейшего проникновения Исследователем во внутренние системы веб-сервисов и приложений информационных систем Минцифры России;
* Совершать попытки получения доступа к учетным записям, данным пользователей или к любым другим конфиденциальным данным, выходящим за пределы действий, минимально необходимых для демонстрации найденной уязвимости;
* Осуществлять целенаправленную выгрузку персональных данных граждан из внутренних систем веб-сервисов и приложений, а также иных информационных ресурсов, не указанных в программе.

## Политика тестирования RCE

Тестирование уязвимостей, которые могут приводить к удаленному исполнению кода, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Выполнения команд ifconfig (ipconfig), hostname, whoami, id;
Чтения содержимого файлов /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini);
Создания пустого файла в каталоге текущего пользователя.

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика тестирования SQL-инъекций

Тестирование уязвимостей, которые могут приводить к внедрению команд SQL, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Получения данных о текущей БД (SELECT database()), ее версии (SELECT @@version), текущего пользователя (SELECT user(), SELECT system_user()) или имени хоста (SELECT @@hostname);
Получения схемы БД (SELECT table_schema), списка таблиц в ней (SELECT table_name) и имен столбцов в таблицах (SELECT column_name);
Выполнения математических, конверсионных или логических запросов (включая использование SLEEP) без извлечения данных (кроме тех, что перечислены выше).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика загрузки и чтения файлов

Тестирование уязвимостей, которые могут приводить к чтению произвольных файлов на сервере или произвольной загрузке файлов, должно выполняться в соответствии с данными правилами:

Запрещенные действия при загрузке файлов:

Изменение, модификация, удаление и замена любых файлов на сервере (включая системные), кроме тех, что ассоциированы с вашей учетной записью либо с учетной записью пользователя, который явно выразил свое согласие;
Загрузка файлов, которые могут вызвать отказ в обслуживании (например, файлов большого размера);
Загрузка вредоносных файлов (например, малвари или шпионского ПО).

При получении возможности чтения произвольных файлов на сервере запрещены любые действия кроме чтения таких файлов, как /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Требования к оформлению отчета

Отчет об уязвимости должен содержать:

* Название уязвимости;
* Название продукта и версию затрагиваемого ПО (компонента);
* Проверку концепции (proof of concept) или подробное описание обнаруженной уязвимости и шагов по ее воспроизведению;
* Описание сценария атаки: кто может использовать уязвимость, для какой выгоды, как она эксплуатируется и т.д.;
* Рекомендации по устранению уязвимости.

Видео и скриншоты могут быть приложены к отчету об ошибке, но не могут его заменить.
Если при исследовании сервисов Минцифры России обнаружено несколько проблем безопасности, необходимо подготовить отчет о каждой выявленной уязвимости отдельно.
Передача информации об обнаруженной уязвимости происходит путем создания отчета (кнопка **Сдать отчет** рядом с названием программы).

ФРГУ

Реестр государственных услуг

Programs