漏洞披露

This policy follows ISO/IEC 29147:2018 for receiving and disclosing vulnerability information and ISO/IEC 30111:2019 for handling it. It covers the web estate of the group, and it covers nothing else. The assets in scope are:

• www.parousiagroup.com and parousiagroup.com.
• westafrica.parousiagroup.com, eastafrica.parousiagroup.com, europe.parousiagroup.com, americas.parousiagroup.com, middleeast.parousiagroup.com and apac.parousiagroup.com.
• The HTTP endpoints those sites expose, including the contact and newsletter endpoints, and the assets they serve.

Everything not on that list is out of scope, and the following are named because they are the ones researchers ask about.

• The product domains of the six solutions — among them netvoxintelligence.com, globaltechnologyafrica.com, afrikaplaza.com, pagexpress.com and pagpay.com — are outside this policy. A report about them may be sent to the reporting address below and will be routed to the operator, but the deadlines and the safe harbour in this document apply only to the assets in scope above.
• Services the group does not operate: email, DNS, certificate, hosting and content delivery providers, social network accounts, and any third-party platform. Report those to their operator; testing them is not authorised here and the group cannot authorise it.
• Physical premises, staff, telephone systems and postal mail. Nothing in this policy authorises access to a building or contact with an employee as a test.
• Any finding that requires an already compromised account, a rooted or malware-infected device, a physically stolen device, or an obsolete browser that the user would have to install deliberately.
• Findings with no demonstrated impact: missing security headers, cookie flag preferences, TLS configuration preferences, software version disclosure, absence of rate limiting on an unauthenticated endpoint, self-inflicted cross-site scripting, clickjacking on a page with no state-changing action, mail configuration records on domains that send no mail, and raw output from an automated scanner. A demonstrated impact moves any of these into scope.

Testing within the following rules is authorised by the group. The rules are the condition of the commitment not to pursue set out below; activity outside them is outside that commitment.

• Test only the assets in scope, and only with accounts and data that belong to you.
• Use the least interaction that demonstrates the problem, and stop as soon as it is demonstrated. Proving that one record is readable is a finding; reading the table is not a better finding.
• Keep a record of what you did: dates and times in UTC, the source addresses you tested from, and the requests that mattered. A distinctive User-Agent string identifying your research makes it possible to tell your traffic from an attack, and helps the group answer you faster.
• Report promptly, and give the group the coordination window set out below before publishing.

• Denial of service is not authorised, in any form: volumetric attacks, load or stress testing, resource exhaustion, and mass automated requests that degrade the service for others.
• Social engineering is not authorised: phishing, pretexting, or any approach to staff, customers, partners or suppliers, whether by email, telephone, message or in person.
• Accessing, altering, deleting or exfiltrating data belonging to another person is not authorised. If you reach such data, stop at the point of proof, do not copy it, and say so in your report.
• Establishing persistence, installing a backdoor, pivoting to another system, or leaving any artefact behind is not authorised.
• Brute force or credential stuffing against real accounts, and the use of credentials found in a breach dump, are not authorised.
• Physical attacks, attacks on the supply chain of the group, and attacks on the personal devices or accounts of staff are not authorised.
• Demanding payment, or making disclosure conditional on payment, is extortion rather than research, and the commitment not to pursue does not apply to it.

Where you act in good faith, within the scope and the rules set out above, the group makes the following commitments, and they are the operative part of this policy.

• The group considers your activity authorised, and it will not initiate, support or encourage any civil claim or criminal complaint against you in respect of it, nor request that a public authority pursue you for it.
• The group will not treat that activity as a breach of its terms of use, and for that activity it waives any term of those conditions that would otherwise prohibit or restrict it.
• If a third party brings a claim or a complaint against you for activity that complied with this policy, the group will make it known — publicly, and to the court or authority concerned if asked — that the activity was authorised by the operator of the systems.
• The group will not require you to sign a non-disclosure agreement as a condition of your report being received or handled, and will not condition the outcome of a report on your silence beyond the coordination window set out below.
• A good-faith mistake about scope — a subdomain you reasonably believed was in scope, a test you stopped as soon as you realised where it led — does not forfeit these commitments, provided you report it.

A report that can be reproduced is handled faster than a report that has to be interpreted. The following are what the group needs; a report missing some of them is still received and still assessed.

• The affected asset: the exact host, path and parameter, and the request that triggers the behaviour.
• The date, time and time zone of your testing, and the source addresses you tested from.
• A description of the vulnerability, the steps to reproduce it, and a non-destructive proof of concept.
• Your assessment of the impact: what an attacker obtains, and what they need in order to obtain it.
• Any account you used, and whether you reached data belonging to another person — including data you saw without intending to.
• Whether the finding has been shared with anyone else, and whether it is already public or subject to another timeline.
• Whether you want public credit, and under what name or handle, and how you prefer to be contacted.

Handling follows ISO/IEC 30111:2019: receipt, verification, assessment of severity, development and verification of a fix, release, and monitoring afterwards. Severity is scored with CVSS v4.0, and the score is given to the reporter with the reasoning behind it, so that a disagreement about severity can be had on the facts.

The coordination window is ninety days from the acknowledgement of receipt. The group asks that you not publish details before the fix is released or before that window closes, whichever comes first. After it closes you are free to publish, whether or not the vulnerability has been fixed, and the group will not treat that publication as a breach of this policy or as a ground for any claim.

• An extension is requested only with a reason and a date, never as an open-ended delay, and you are free to refuse it.
• Where a vulnerability is being actively exploited, the group may publish before the window closes in order to warn users, and will tell you before it does.
• The group publishes what a reader needs in order to act: what was affected, what an attacker could have done, what was done about it, and when. It credits the reporter where the reporter asked for credit.
• Where the vulnerability lies in a third-party component, the group reports it to the maintainer and coordinates with them, and tells you that the timeline is no longer entirely in its hands.
• Where personal data were exposed, the notification duties in Articles 33 and 34 of the GDPR apply, and where an entity of the group falls within Directive (EU) 2022/2555 its incident notification duties apply too. Neither is affected by an agreement between the group and a researcher.

What the group does offer is credit, and it is given on request rather than by default: a researcher who does not ask to be named is not named. Credit states the name or handle you chose, the date the report was received, and the severity. On request, the group also provides a written confirmation of the finding and of how it was handled, which is worth more than a keyring to a person building a professional record. A researcher who asks for anonymity gets it, including in the published disclosure.

RFC 9116 defines a file served at /.well-known/security.txt that tells a researcher where to send a report, where to find the policy, which languages are read, and when the file expires. The group has not yet published one. When it does, it will carry the Contact, Expires, Policy, Preferred-Languages and Acknowledgments fields and point at this document, and the file rather than this paragraph will be the machine-readable source of truth.

Two other things do not exist yet and are named here rather than implied: a public encryption key, and any product-level disclosure policy. Where the group places on the European market a product with digital elements within the meaning of Regulation (EU) 2024/2847, that product will carry its own coordinated vulnerability disclosure policy and its own reporting obligations; this document covers the web estate in scope and does not stand in for one.