PT Container Security Bug Bounty Program
Program Description
The PT Container Security Bug Bounty Program is aimed at identifying and confirming vulnerabilities that may lead to compromise of container and orchestrator infrastructure, bypassing protection mechanisms at the stages of container assembly, deployment, and execution, disruption of DevSecOps processes, as well as unauthorized control over clusters and host systems.
PT Container Security is a solution for comprehensive protection of hybrid cloud infrastructure, designed for secure development and operation of software systems using container virtualization. The product provides protection for containers, images, registries, clusters, and orchestrators (Docker, Kubernetes) throughout the entire lifecycle — from CI/CD to runtime. Vulnerabilities in the product can directly affect the security of critical services and the resilience of the entire cloud infrastructure.
Limitations
At the time of program launch, access to test stands of the product is provided on a limited basis.
Extended access will be provided later, as the infrastructure and support procedures become ready.
General Provisions
Accepted Vulnerability Types
We accept reports on vulnerabilities of the following categories (but are not limited to them):
1. Central Management Console and API
- Bypass of authentication or authorization in a unified management console for multi-cluster infrastructure, allowing unauthorized access to cluster and security policy management.
- XSS or CSRF in the web interface used for managing rules, users, and settings, leading to execution of actions on behalf of privileged users.
2. Image and Registry Scanning
- Bypass of vulnerability scanning mechanisms (CVE) in container images, including images based on domestic operating systems (Astra Linux, RedOS), leading to distribution of vulnerable components in production.
- SSRF when integrating with container image registries (Artifactory, Nexus, GitLab Registry, Yandex Container Registry) through their API, allowing attacks on internal services or infrastructure components.
3. Admission Controller
- Command execution (exec) in a container bypassing restrictive rules set at the admission controller level.
- Cluster Takeover, including obtaining cluster-admin rights through errors in admission webhooks, service accounts, or token verification mechanisms (TokenReview API).
- Injection of an unsafe container into a cluster bypassing security policies, for example a container with privileged access or with mounting of sensitive host volumes.
4. Runtime Security
- Bypass of monitoring mechanisms based on eBPF, designed to detect suspicious activity in running containers.
- Substitution, interception, or disruption of management of the protection agent (DaemonSet) installed on cluster nodes.
- Container Escape to the host OS despite active monitoring of system calls and effective security rules.
Note: Vulnerabilities that do not lead to real risk (for example, theoretical or without confirmation of exploitation) may be rejected or rated as "informational" without monetary compensation.
Rewards
Reward amounts are described in the table below:
| Severity Level | Payment Amount |
|---|
| Critical | ₽300,000 - ₽500,000 |
| High | ₽150,000 - ₽300,000 |
| Medium | ₽50,000 - ₽150,000 |
| Low | ₽0 - ₽50,000 |
Rewards may be paid only 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 compensation 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.
Participant Requirements
All interested researchers aged 18 and older may participate in the program.
Researchers aged 14 to 18 are eligible to participate in the program only with written consent from parents or a legal representative.
Current employees of Positive Technologies and former employees who have been separated for less than 3 years may participate in the program but cannot claim compensation.
Researchers Must:
- Comply with the rules established by Positive Technologies in its vulnerability disclosure program, as well as the rules of The Standoff 365 Bug Bounty platform.
- Comply with confidentiality rules. It is prohibited to access another user's data without their consent, modify and destroy it, or disclose any confidential information accidentally obtained during vulnerability search or demonstration. Intentional access to this information is prohibited and may be considered illegal.
- Maintain communication with the security team, submit reports of 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.
- Disclosure of a vulnerability is permitted only if there is a fix and a publicly registered vulnerability identifier (CVE/BDU).
- A bug hunter may request disclosure of the report - PT undertakes to launch a process for coordinating registration of a vulnerability identifier.
Rewards for Vulnerabilities
Positive Technologies Does Not Pay Compensation 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 security tools, without demonstrating a bypass of the security tools.
- Reports of insecure SSL and TLS ciphers without demonstrating their exploitation.
- Reports about the absence of SSL and other best current practices.
- Vulnerabilities whose information was previously submitted by other competition participants (duplicate reports).
- 0-day or 1-day vulnerabilities whose information was received 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.
Rewards are paid to individual entrepreneurs and self-employed persons.
