Vulnerability Disclosure Policy
Cybersecurity Blue & Red Team (“CBRT”, “we”, “us”, or “our”) is committed to improving the security of the digital ecosystem through responsible vulnerability research, coordinated disclosure, and constructive collaboration with vendors, maintainers, clients, and the security community. This Policy explains how CBRT receives, handles, coordinates, and publishes vulnerability information.
CNA status. CBRT has applied to join the CVE Program as a CNA (CVE Numbering Authority); the application is currently in process. The provisions of this Policy on the reservation, assignment, and publication of CVE IDs will apply once CBRT is authorized and listed in the CVE Program’s List of Partners; until then they describe how CBRT will operate as a CNA. The intake and coordination of vulnerability reports described here are in effect now.
Purpose
The goals of this Policy are to:
- Provide a clear channel for reporting security vulnerabilities to CBRT.
- Describe how CBRT handles vulnerabilities discovered by our team or reported by external researchers.
- Support coordinated disclosure practices that reduce risk to users.
- Publish advisories for validated vulnerabilities when appropriate.
- Assign CVE IDs, once CBRT is authorized as a CNA and where applicable, within its scope.
Reporting a Vulnerability
CBRT accepts vulnerability reports from the public, including independent researchers, customers, vendors, and other third parties acting in good faith. Send reports to:
- Email: cve@cbrt.com.do
- Encrypted reports: Use our PGP key at https://cbrt.com.do/.well-known/cbrt-cve-pgp.txt for sensitive or embargoed details.
Please include, when possible:
- A clear description of the issue
- The affected product, service, asset, or version
- Steps to reproduce the issue
- Proof-of-concept or supporting evidence
- The potential impact
- Any suggested remediation or mitigation
- Your contact information for follow-up
- Whether you have already reported this issue to the affected vendor or another CNA (and, if so, to whom)
Response times. CBRT acknowledges receipt of a report within three (3) business days. For reports that fall within CBRT’s CNA scope, we respond to the CVE assignment request within five (5) business days. Requests from another CNA or a Root regarding right of first refusal for a vulnerability in CBRT’s scope are handled within seventy-two (72) hours, in line with the CNA Rules. We may request additional details to validate or coordinate the issue. When we assign a CVE ID to a vulnerability you reported, we provide that CVE ID to you.
Scope
This Policy covers two categories of vulnerabilities.
1. Vulnerabilities affecting CBRT-owned systems. CBRT accepts reports related to vulnerabilities affecting systems, services, applications, or assets owned and operated by CBRT, where such testing was conducted in good faith and in accordance with this Policy.
2. Vulnerabilities discovered by CBRT, or reported to CBRT for coordination, in third-party products. This Policy also applies to vulnerabilities that CBRT discovers through independent research or authorized assessment activities, or that third parties report to us in good faith for coordination, in third-party software, products, platforms, devices, or services, provided that:
- The affected product is publicly available or intended for production use.
- The vulnerability was identified through lawful and authorized means.
- The issue is not already covered by another CNA whose scope more specifically applies to the affected product, unless assignment is coordinated with or deferred to that CNA.
- Disclosure is legally and contractually permissible.
For vulnerabilities identified during client engagements or private assessments, CBRT will follow the applicable contract, authorization boundaries, and confidentiality obligations. CBRT will not disclose or publish such issues without the required authorization, unless otherwise permitted by law or contract.
End-of-Life Products
CBRT may assign CVE IDs for vulnerabilities in End-of-Life or unsupported products that are no longer maintained, when the affected product falls within CBRT’s scope and is not covered by another CNA whose scope more specifically applies. CBRT tags such records unsupported-when-assigned in accordance with the CNA Rules.
Prohibited Testing Activities
When testing CBRT-owned assets under this Policy, do not engage in:
- Social engineering, phishing, or spam
- Physical security attacks against CBRT facilities or staff
- Denial-of-service testing or other activity that degrades the availability of CBRT services
- Unauthorized access, data exfiltration, persistence, or destructive actions
- Automated testing that materially degrades CBRT services
What CBRT Will Not Assign a CVE For
CBRT may decline to process, publish, or assign CVE IDs for:
- Reports that do not describe a legitimate security vulnerability
- Issues dependent on malware deployment or self-inflicted misconfiguration without a product security weakness
- Vulnerabilities in non-production, sample, or training code, unless they present a clear real-world security impact
- Products already covered by another CNA whose scope more specifically applies, unless coordination has occurred
- Duplicate reports where the issue has already been reported, assigned, or disclosed
Good-Faith Research and Safe Harbor
CBRT supports good-faith security research intended to improve security and protect users. If you act in good faith and comply with this Policy, CBRT will consider your research to be authorized and will not initiate legal action against you for your testing activities on CBRT-owned assets. This applies when your activities are limited to what is reasonably necessary to identify and report a vulnerability and you avoid causing harm to users, systems, or data.
To qualify for this safe harbor, you must:
- Avoid privacy violations, destruction of data, interruption of services, and unauthorized access beyond what is necessary to demonstrate the issue
- Stop testing and notify us promptly after discovering sensitive data or unintended access
- Not exploit the vulnerability beyond the minimum steps required to establish its existence
- Not use automated testing that materially degrades CBRT services
- Not publicly disclose the issue before CBRT has had a reasonable opportunity to investigate and remediate it
- Comply with all applicable laws and regulations
This safe harbor applies only to activities directed at CBRT-owned assets and does not bind third-party vendors, service providers, clients, or other organizations. If your research involves third-party systems, you must ensure you have appropriate authorization from the relevant owner.
Disclosure Principles
CBRT follows a coordinated vulnerability disclosure model. We aim to balance user protection, remediation time, transparency, and fairness to affected parties.
Our default disclosure timeline is ninety (90) days from the initial notification to the affected vendor, maintainer, client, product owner, or internal owner. This timeline may be extended when there is an active remediation effort and the client, vendor, or product owner requests additional time for a justified reason. CBRT may also shorten the timeline when early disclosure is necessary to protect users, including cases involving active exploitation, significant exposure, or urgent public risk.
Disclosure Process
When CBRT receives or discovers a previously unpublished vulnerability, we generally follow this process:
- Validation and triage: We review the report, validate the issue, assess impact, identify affected products or assets, and determine whether the report is in scope.
- Initial acknowledgment: We acknowledge receipt and may request clarification, evidence, or reproduction details.
- Notification of affected party: If the issue affects a third-party vendor, maintainer, client, or product owner, CBRT will make reasonable efforts to notify the appropriate party through an established security contact or another reliable channel.
- Coordination period: CBRT works with the relevant stakeholders to support validation, remediation, severity assessment, timeline management, and disclosure planning.
- CVE handling: If the issue is eligible and falls within CBRT’s CNA scope, CBRT may reserve or assign a CVE ID. If another CNA’s scope more specifically applies, CBRT may defer to or coordinate with that CNA.
- Public advisory: At the end of the coordination period, or earlier when justified, CBRT publishes a public advisory.
- Post-disclosure updates: Advisories may be updated to reflect new versions, patch availability, vendor statements, severity changes, additional affected versions, or other relevant corrections.
Default Timeline
Unless a different timeline is justified, CBRT generally follows this schedule:
- Day 0: Initial report or notification sent
- Day 7: Follow-up if no acknowledgment has been received
- Day 30–45: Courtesy reminder and notice of anticipated disclosure
- Day 60: Final reminder, if needed
- Day 90: Public disclosure on CBRT advisories
CBRT may extend the timeline beyond 90 days when a client, vendor, or product owner requests more time and there is a legitimate remediation effort underway. CBRT may disclose sooner when public safety or active exploitation warrants earlier publication.
CVE Record Publication
Once a vulnerability with a CBRT-assigned CVE ID is publicly disclosed, CBRT publishes the corresponding CVE Record promptly, and within 72 hours of public disclosure, in line with the CNA Rules. CBRT publishes or updates the CVE Record within 72 hours if it learns that a third party has publicly disclosed a vulnerability tied to a CVE ID that CBRT assigned.
CVE Assignment
When operating within its CNA scope, CBRT may reserve and publish CVE Records for eligible vulnerabilities. CBRT will generally assign CVE IDs only when:
- The issue is a legitimate vulnerability with demonstrated security impact
- The vulnerability falls within CBRT’s CNA scope
- The affected product is not already covered by another CNA whose scope more specifically applies, unless coordination has occurred
- Reasonable efforts have been made to notify the affected party before public disclosure, except in exceptional circumstances
CBRT reserves or assigns a CVE ID only when public disclosure of the vulnerability is expected. If an assigned CVE ID ultimately cannot be publicly disclosed — for example, because of a contractual or legal constraint — CBRT will reject that CVE ID rather than leave it assigned but undisclosed.
For products covered by another CNA whose scope more specifically applies, CBRT may defer CVE assignment to that CNA or coordinate with them as appropriate. Disagreements about a determination, assignment, or record content are handled through the CVE Program Policy and Procedure for Disputing a CVE Record.
Advisory Publication
CBRT publishes advisories at:
- Advisories: https://cbrt.com.do/advisories
Public advisories are freely available, with no registration, login, or restrictive terms of use, and may include:
- Vendor and product name
- Affected versions, if known
- Vulnerability summary and technical details
- Reproduction guidance, where appropriate
- Severity scoring using CVSS v4.0
- CWE classification, where applicable
- CVE ID, where assigned
- Disclosure timeline
- Patch, workaround, or mitigation details, where available
CBRT may publish proof-of-concept material when doing so is considered responsible and helpful for validation, remediation, or defensive use. CBRT may withhold or limit exploit details when publication would create unnecessary risk.
Recognition
CBRT may acknowledge researchers who submit valid reports, unless the reporter requests anonymity or legal, contractual, or operational constraints prevent public recognition.
Policy Location and Contact
- Vulnerability Disclosure Policy: https://cbrt.com.do/vdp
- Advisories: https://cbrt.com.do/advisories
- Contact: cve@cbrt.com.do
- PGP key: https://cbrt.com.do/.well-known/cbrt-cve-pgp.txt
Changes
CBRT may update this Policy from time to time to reflect operational, legal, contractual, or program requirements. The most current version will be published at the policy URL above.
← Back to portal · Last updated: October 9, 2026