# Vulnerability Disclosure Policy Flopsar Technology Sp. z o.o. operates a coordinated vulnerability disclosure process for the Flopsar product family. We rely on the security research community and on our customers to help us identify weaknesses in the product before they can be exploited, and we commit to handling every report we receive in a predictable, time-bound, and professional manner. This policy is the public expression of that commitment. It is the document referred to by Article 13(1) of Regulation (EU) 2024/2847 (the Cyber Resilience Act) and by point 5 of Annex I, Part II of the same Regulation. Its structure follows the guidance of ISO/IEC 29147:2018 *Vulnerability disclosure* and ISO/IEC 30111:2019 *Vulnerability handling processes*. ## Single point of contact The single point of contact for vulnerability reports about Flopsar is the Flopsar Product Security Incident Response Team (PSIRT): * **Email**: `security@flopsar.com` This is also the contact point referred to by Article 13(1) of the Cyber Resilience Act. The PSIRT is monitored on business days during European business hours; reports submitted outside those hours are acknowledged on the next business day at the latest, within the SLA stated in Section 5.1. If the matter you wish to report is not a security vulnerability — for example, a feature request, a non-security bug, or a licensing question — please use the appropriate channel listed on the Contact page instead. ## Scope ### In scope This policy covers vulnerabilities in any released artefact of the following components of Flopsar, in any version that is currently within the security support window defined in Support & Maintenance Lifecycle: * **Flopsar Server** — the server daemon, its REST and gRPC interfaces, its configuration and key management code, and its persisted storage format. * **Flopsar Agent** — the JVM agent shared library (Linux, Windows), including its instrumentation, networking, and cryptographic subsystems. * **Flopsar Workstation** — the web user interface, including its authentication and authorisation logic and its API client code. * **Distribution packages** — the `.deb`, `.rpm`, and container images that we publish, and their signing metadata. * **Documentation hosted on `docs.flopsar.com`** — only where a documentation defect could lead a competent operator to introduce a security weakness in their deployment. ### Out of scope The following are explicitly out of scope and will normally be closed without further investigation: * Vulnerabilities in third-party software outside our control, including the operating system, the JVM running the instrumented application, the reverse proxy in front of Flopsar, or upstream open-source libraries for which we are not the maintainer. Where a vulnerability in a third-party library affects Flopsar, we will coordinate with the upstream maintainer; please report the original issue to them. * Reports based solely on the **output of automated scanners** (DAST, SAST, secret-scanners) without a demonstrated security impact on a current, supported release of Flopsar. * Issues caused by **misconfiguration of a customer deployment** that contradicts the documented Hardening Checklist. * **Social engineering, physical attacks, or denial-of-service** attacks against Flopsar Technology Sp. z o.o. infrastructure or staff. * Issues that require **physical access** to a host where the Flopsar Server, Agent, or Workstation is installed. * Theoretical attacks without a practical proof of concept on a supported release. * **End-of-life releases** (see Support & Maintenance Lifecycle), except where a class of vulnerability also affects a supported release. ## How to report The preferred channel is **PGP-encrypted email to `security@flopsar.com`**, using the public key whose fingerprint is published in Section 2. Reports sent in cleartext will be accepted, but we strongly recommend using encryption for any report that contains a working proof of concept or sensitive information. ### Reporting through a national CSIRT or ENISA In accordance with Article 13(11) of the Cyber Resilience Act, a reporter may, in addition to or instead of contacting us directly, report the vulnerability to the CSIRT designated as a coordinator in\ their Member State, or to ENISA. We will cooperate fully with any such CSIRT or with ENISA in the course of handling the report. ### What to include in a report To allow us to triage and reproduce the issue quickly, please include in your report: * the affected component (server, agent, workstation, package) and the exact version, including build metadata where available; * a description of the vulnerability and, where applicable, the weakness class (CWE) and an indicative CVSS v3.1 vector; * a step-by-step proof of concept that allows us to reproduce the issue in a controlled environment; * a description of the security impact you believe the vulnerability has, and the threat model under which that impact applies; * any logs, screenshots, or scripts that support the analysis; * whether you wish to be credited in the public advisory, and under what name (see Section 9); * whether you have already disclosed the issue, or intend to disclose it, to any third party — and on what timeline. We do not require reporters to provide a fix; if you propose one, we will review it but cannot accept it directly into the proprietary code base. ## Our process We follow the process described in ISO/IEC 30111:2019. A report passes through five stages: acknowledgement, triage, remediation, validation, and disclosure. ### Acknowledgement and triage timeline The PSIRT acknowledges reports promptly, normally within a few business days of receipt. The reporter receives a subsequent substantive response with the triage outcome once initial analysis has been completed. ### Severity classification We classify vulnerabilities using the Common Vulnerability Scoring System version 3.1 (CVSS v3.1). The CVSS base score is computed by the PSIRT, taking into account the standard deployment profile of Flopsar documented in Architecture Fundamentals and Security Overview. | Severity | CVSS v3.1 base score | | -------- | -------------------- | | Critical | 9.0 – 10.0 | | High | 7.0 – 8.9 | | Medium | 4.0 – 6.9 | | Low | 0.1 – 3.9 | We may publish a different temporal or environmental CVSS vector in the advisory if customer-deployed configurations materially change the score. ### Remediation timelines We address vulnerabilities affecting supported releases of Flopsar **without undue delay**, in accordance with point 7 of Annex I, Part II of Regulation (EU) 2024/2847. The corresponding security update is made available **without undue delay** and, unless otherwise agreed for tailor-made products, **free of charge**, in accordance with point 8 of the same Annex. What constitutes "without undue delay" in a given case depends on the severity of the vulnerability (Section 5.2), the technical complexity of the fix, the availability of coordinated upstream changes where the vulnerability concerns a third-party component, and any operational constraints that affect the release process. The PSIRT prioritises remediation work strictly by severity, with higher-severity vulnerabilities taking precedence over lower-severity ones within the same release line. For releases that are within the extended security support phase of their lifecycle, as defined in Support & Maintenance Lifecycle, remediation may be limited to vulnerabilities of higher severity. We commit to keeping the reporter informed of the progress of remediation in accordance with Section 5.4, including any material change in the expected timing. ### Communication with the reporter We will provide the reporter with written status updates at the following points in the process: * on initial acknowledgement (Section 5.1); * on completion of triage, including the assigned severity and advisory identifier (`FLOPSAR-YYYY-NNN`); * on availability of a fix in an internal build, with a request for validation if the reporter has offered to assist; * on public release of the fix and publication of the advisory. If we have not produced an update for more than 14 calendar days, the reporter is invited to write to `security@flopsar.com` for a status request. ### Coordinated disclosure timing Public disclosure is coordinated between the reporter and Flopsar Technology Sp. z o.o. with the objective of giving customers a reasonable opportunity to apply the security update before details of the vulnerability become public. The exact embargo period is agreed on a case-by-case basis. ## Safe harbor Flopsar Technology Sp. z o.o. will not pursue or support any civil or criminal claim against a person who in good faith and in compliance with this policy: * discovers, tests, and reports a vulnerability in a component of Flopsar that is in scope under Section 3.1; * uses only research methods that respect the limits set out in Section 8; * does not access, modify, or exfiltrate any data other than their own test data, or, where unavoidable, the minimum strictly necessary to demonstrate the vulnerability; * does not publicly disclose the vulnerability before the agreed embargo end (Section 6) or, in the absence of agreement, before the default 90-day period has elapsed; * complies with the laws of their jurisdiction. This safe harbor is a unilateral commitment by Flopsar Technology Sp. z o.o. It does not bind third parties — including customers operating their own Flopsar deployments, hosting providers, or law enforcement — and reporters should ensure that their research methods are lawful in their own jurisdiction and in the jurisdiction of any system they touch. If you are unsure whether a planned research activity would fall under this safe harbour, please ask `security@flopsar.com` in advance. ## Restrictions and rules of engagement When researching vulnerabilities in Flopsar, you must not: * attack **production deployments of Flopsar operated by customers**; use your own evaluation copy of the product, obtainable from Flopsar Technology Sp. z o.o. by request; * access, modify, exfiltrate, or destroy data belonging to anyone other than yourself; * run automated scanning tools against systems operated by Flopsar Technology Sp. z o.o. without prior written authorisation; * perform any form of social engineering against Flopsar employees, contractors, customers, or suppliers; * perform denial-of-service attacks, including those that test the resilience of the product under load, against any system that is not your own; * publish data obtained from the vulnerable system other than the minimum required to substantiate the report. Violation of these rules removes the protection of the safe harbour in Section 7. ## Credit and acknowledgement Where the reporter consents, the advisory published under Security Advisories will include the reporter's name or chosen handle and an optional one-sentence statement of their choosing. We do not list affiliations without the reporter's explicit request. If the reporter prefers to remain anonymous, no identifying information will be published. ## Financial reward Flopsar Technology Sp. z o.o. does **not** currently operate a paid bug bounty programme. We acknowledge contributions through the public advisory or through a written letter of recognition on request. The absence of a financial reward does not diminish the obligations we undertake in the rest of this policy. We reserve the right to revise this position; any future bug bounty programme will be announced on this page. ## Confidentiality Reports submitted under this policy are treated as commercially sensitive. They are accessible internally only to the PSIRT and to the engineers strictly necessary for triage, fix, and validation. They are not shared with third parties other than: * the reporter, in the course of coordinated disclosure; * upstream suppliers, where the vulnerability affects a shared component, under an appropriate non-disclosure arrangement; * national CSIRTs, ENISA, and market surveillance authorities, in the course of fulfilling our obligations under the Cyber Resilience Act (notably Articles 14 and 15) and other applicable laws. Personal data contained in a report is processed in accordance with our Privacy & Data Handling statement. ## Compliance and standards This policy is maintained in accordance with the following references: * Regulation (EU) 2024/2847 (Cyber Resilience Act), in particular Article 13(1), Article 14, and Annex I, Part II, point 5; * ISO/IEC 29147:2018 *Information technology — Security techniques — Vulnerability disclosure*; * ISO/IEC 30111:2019 *Information technology — Security techniques — Vulnerability handling processes*; * Directive (EU) 2022/2555 (NIS2) Article 12, where Flopsar is used by a customer operator subject to the Directive. The version of this policy in force is the one published at the canonical URL stated in the page header. Earlier versions are retained in the repository history and made available to authorities on request. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.flopsar.com/7/vulnerability-disclosure-policy.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.