ENIKA Coordinated Vulnerability Disclosure Policy
ENIKA places a high priority on the security of its products, digital services and users. We encourage security researchers, customers and other parties who identify a potential security vulnerability to report it responsibly in accordance with the rules described below.
2. Single Point of Contact
ENIKA provides a dedicated point of contact for reporting security vulnerabilities.
Vulnerability reporting email:
security@enika.pl
Alternative address / alias:
psirt@enika.pl
Security reporting page:
https://enika.pl/security/
security.txt:
https://enika.pl/.well-known/security.txt
Single Point of Contact (SPOC):
PSIRT ENIKA
Primary address:
security@enika.pl
Alternative address / alias:
psirt@enika.pl
The Single Point of Contact is accessible to vulnerability reporters and allows them to use their preferred means of communication. The reporting process is not limited exclusively to automated tools. Reporters are able to communicate directly with a person responsible for handling security reports.
3. Rules for Security Researchers – Safe Harbor
ENIKA will not initiate legal action against security researchers who act in good faith and comply with this policy.
Permitted security research must be conducted in a manner that:
does not violate user privacy,
does not degrade or disrupt services,
does not result in access to data belonging to other users.
The reporter will receive confirmation that the vulnerability report has been received and will be provided with information regarding the progress of its handling.
The following research methods are prohibited in particular:
DoS or DDoS attacks,
brute-force attacks,
social engineering, including phishing,
modification or destruction of data,
installation of malicious software,
accessing accounts or data belonging to other users.
The reporter must keep information about the vulnerability confidential until ENIKA has made an official fix available. Any public disclosure date should be coordinated with ENIKA as part of the coordinated vulnerability disclosure process.
4. Vulnerability Handling Process and Target Timelines
Acknowledgement
Target timeframe: within 72 hours
After receiving a vulnerability report, ENIKA:
Triage and Assessment
Target timeframe: within 7 days
ENIKA performs:
verification of the report,
vulnerability classification,
severity assessment, including CVSS where applicable,
assignment of an owner responsible for further handling.
Remediation Development
Timeframe: according to the applicable ENIKA SLA
Once the vulnerability has been confirmed, ENIKA takes appropriate action to:
develop a fix,
implement an appropriate remediation,
apply a compensating measure where an immediate fix is not possible.
Coordinated Disclosure
Default timeframe: 90 days
After a fix or update has been made available, ENIKA may perform coordinated disclosure of the vulnerability, including publication of a security advisory and, where applicable, a CVE identifier.
The disclosure date may be coordinated with the reporter depending on the nature of the vulnerability, the associated risk and the availability of a remediation.
5. Publication and Cooperation
After an update or security fix has been released, ENIKA may publish a security advisory containing:
a description of the vulnerability,
the CVE identifier,
information about its impact,
the severity rating, including CVSS,
information assisting users with remediation or risk mitigation.
Actively exploited vulnerabilities are additionally handled in accordance with ENIKA procedures governing the reporting of security vulnerabilities and incidents.
ENIKA cooperates with the competent CSIRT, including where the CSIRT acts as a coordinator for coordinated vulnerability disclosure, and with ENISA to the extent required by applicable law.
6. Scope and Non-Qualifying Reports
This policy covers all publicly available ENIKA products, digital services and products with digital elements falling within the scope of the Cyber Resilience Act. The following are generally considered non-qualifying or out-of-scope reports:
spelling, editorial or cosmetic errors with no security impact,
missing HTTP headers or deviations from configuration best practices where no actual security impact has been demonstrated,
error pages, including 404 pages, and publicly available information where no meaningful security exploitation is possible,
reports generated solely by automated scanners without a demonstrated exploitability or suitable Proof-of-Concept.
7. Required Information for a Valid Vulnerability Report
To enable ENIKA to perform efficient verification, triage and remediation, a vulnerability report should contain as much relevant information as possible.
Please include:
the name of the affected product or component, or the URL of the affected service,
the software or firmware version, where applicable,
a description of the vulnerability,
steps required to reproduce the issue,
screenshots where useful,
Proof-of-Concept (PoC) code where possible,
an estimated assessment of the security impact,
a preliminary CVSS score, where the reporter is able to provide one,
the reporter's contact details,
the reporter's preferences regarding public credit or acknowledgement.
Reports containing the above information can generally be verified and classified more efficiently.
8. Recognition and Acknowledgements
Security researchers who comply with this policy and cooperate with ENIKA during the investigation and remediation process may be acknowledged in a published security advisory as the discoverers of a vulnerability.
ENIKA may also provide additional forms of recognition to individuals whose contribution has materially improved the security of ENIKA products or services.
Any public acknowledgement or disclosure of the reporter's identity will only take place with the reporter's consent.
.svg){kind=small}