PT Application Inspector
Bounty Range
Up to $6,000
external program
PT Application Inspector
Bounty Range
Up to $6,000
external program
Company: Positive Technologies
The Bug Bounty Program for PT Application Inspector is aimed at identifying and confirming vulnerabilities that may lead to the compromise of application security analysis processes, distortion of SAST/DAST/IAST/SCA test results, leakage of source code and analysis data, as well as use of system components as an entry point for attacks on customer infrastructure.
PT Application Inspector is a comprehensive application security analysis platform that combines static, dynamic, interactive analysis, open source component analysis (SCA), as well as signature and pattern matching mechanisms. The product is used to protect applications of various scales — from public web services to critical corporate and state systems. Vulnerabilities in the product can directly affect the reliability of analysis results and the security of the software development lifecycle (SDLC).
At the time of program launch, access to product test environments is provided on a limited basis.
Extended access will be provided later, as infrastructure and support procedures become ready.
We accept reports on vulnerabilities of the following categories (but not limited to them):
Authentication bypass in the management interface allowing unauthorized access to projects, analysis results, and system settings.
XSS in input fields used when working with projects, scan parameters, or reports, allowing execution of arbitrary code in a user's browser.
Unsafe deserialization in the API leading to arbitrary code execution or compromise of system components.
Path Traversal when uploading source code for analysis, allowing reading or overwriting arbitrary files on the server.
Substitution of analysis results through injections in project metadata leading to distortion of conclusions about the presence or absence of vulnerabilities.
Incorrect handling of known vulnerabilities (CVE) allowing concealment of actual vulnerabilities in the analyzed code or injection of false results.
SQL injections in vulnerability search and filtering mechanisms allowing access to system data or disruption of its operation.
XSS in system-generated reports leading to compromise of user sessions or execution of actions on their behalf.
Bypass of vulnerability signature database integrity checks allowing substitution or disabling of detection rules.
Remote Code Execution (RCE) through custom analysis rules used to extend system functionality.
Substitution or modification of system analysis rules through access control vulnerabilities leading to distortion of application check results.
SSRF in integration functions with CI/CD systems (Jenkins, GitLab, etc.) allowing attacks on internal services or infrastructure.
Leakage of build system credentials used for automatic application analysis in pipelines.
Remote Code Execution (RCE) through CI/CD hooks leading to compromise of the build or development environment.
Vulnerabilities in containers leading to escape from isolated environment and access to host system.
Disclosure of sensitive information in error messages allowing simplification of further attacks or obtaining information about system architecture.
Note: Vulnerabilities that do not lead to actual risk (for example, theoretical or without exploitation confirmation) may be rejected or evaluated as "informational" without monetary reward.
Reward amounts are described in the table below:
| Severity Level | Reward Amount |
|---|---|
| Critical | ₽300,000 - 500,000 |
| High | ₽150,000 - 300,000 |
| Medium | ₽50,000 - 150,000 |
| Low | ₽0 - 50,000 |
Reward can only be paid for attack scenarios reproducible on installations of officially supported product versions with all available updates. Reports on defects in unsupported versions are also accepted, but reward payment for such vulnerabilities is not guaranteed.
The severity level of a vulnerability is determined during triage and confirmation of the report taking into account the impact on product security.
The final decision on the severity level of a vulnerability is made by the product security team.
All interested researchers aged 18 and above may participate in the program.
Researchers aged 14 to 18 have the right to participate in the program only with written consent from parents or legal representatives.
Current employees of Positive Technologies and former employees whose termination occurred less than 3 years ago may participate in the program but cannot claim rewards.
Comply with the rules established by Positive Technologies in its vulnerability disclosure program and the rules of The Standoff 365 Bug Bounty platform.
Comply with confidentiality rules. It is forbidden to access another user's data without their consent, modify and destroy it, as well as disclose any confidential information accidentally obtained during the search for vulnerabilities or their demonstration. Intentional access to this information is forbidden and may be recognized as illegal.
Maintain communication with the security team, send them reports on identified vulnerabilities formatted according to requirements, and provide feedback if specialists have questions about the report.
Not disclose information about the vulnerability. The right to publish information about a found vulnerability remains with Positive Technologies.
Vulnerability disclosure is permitted only if there is a fix and a publicly registered CVE/BDU identifier.
A bug hunter may express a desire for report disclosure — PT undertakes to launch a process for coordinating registration of a vulnerability identifier.
Positive Technologies does not pay rewards for:
Reports from security scanners and other automated tools;
Disclosure of non-secret information (software name or version, technical parameters and system metrics, etc.);
Information about IP addresses, DNS records, and open ports;
Problems and vulnerabilities that are based on the version of the product used without demonstrating their exploitation;
Vulnerabilities whose exploitation is blocked by information security measures without demonstrating a bypass of these measures;
Reports of insecure SSL and TLS ciphers without demonstrating their exploitation;
Reports of missing SSL and other best current practices;
Vulnerabilities whose information has previously been submitted by other competition participants (duplicate reports);
0-day or 1-day vulnerabilities whose information was obtained by the security team from open sources;
Vulnerabilities to brute-force attacks if the report does not describe a method with significantly higher efficiency than direct brute-force.