Prioritize risks that could affect devices, video and audio data, user accounts, cloud services, or business continuity.
LONGSE PRODUCT SECURITY · COORDINATED DISCLOSURE
Vulnerability Response Process
Longse Technology Limited takes the cybersecurity of its products and services seriously. We welcome security researchers, customers, partners, and industry organizations to report suspected vulnerabilities responsibly. Each report is handled through a structured, transparent, and traceable process covering validation, assessment, remediation, and coordinated disclosure.
Our Principles
Vulnerability Management Principles
Our primary objective is to reduce risk to customers and users while continuously improving product security through legal compliance, data minimization, and coordinated disclosure.
Escalate high-risk or actively exploited issues and provide actionable mitigation guidance and remediation plans promptly.
Maintain professional and ongoing communication with researchers, customers, suppliers, open-source communities, and coordination organizations.
Feed root-cause findings, remediation lessons, and detection rules back into engineering, security testing, supply-chain, and release processes.
Security Advisories
Vulnerability Disclosure Advisories
After a fixed release, patch, or effective mitigation is ready, Longse may publish an advisory describing affected products, severity, recommended actions, and fixed versions.
Advisory Center StatusNo public advisories at this time
Advisories can be searched by identifier, title, and severity. Material changes will update the advisory date and remain in the revision history; unverified or uncoordinated details will not be published.
| Advisory ID | Title | Severity | Published | Details |
|---|---|---|---|---|
| No public security advisories are currently availablePublished advisories will be searchable by identifier, title, and severity. | ||||
Advisory contentImpact, exploitation prerequisites, affected and unaffected versions.
Remediation informationFixed versions, update instructions, and actionable interim mitigations.
Update mechanismMaterial changes will update the advisory date and retain a revision history.
Response Process
Six-Stage Vulnerability Response Process
From initial receipt through formal disclosure, each valid report is assigned a tracking record and a responsible point of contact.
Receipt and Registration
Receive external reports or internal detections, create a unique tracking identifier, and confirm that the report has entered the response process.
- Check report completeness
- Identify urgent risk indicators
- Assign a responsible contact
Validation and Communication
The product security team works with relevant product, engineering, and testing teams to reproduce the issue and may request additional information from the reporter.
- Confirm reproducibility
- Identify duplicates or false positives
- Protect test data and evidence
Impact Assessment and Severity Rating
Identify affected products, models, versions, configurations, and attack conditions, then determine priority using CVSS and real-world context.
- Assess confidentiality, integrity, and availability
- Assess exploit maturity and affected scope
- Identify supply-chain or multi-vendor impact
Mitigation and Remediation
Develop interim mitigations and long-term remediation, addressing the issue in code, firmware, applications, cloud services, or configuration as appropriate.
- Escalate high-risk issues
- Coordinate with third-party suppliers
- Prepare release and rollback plans
Remediation Verification and Release
Perform security verification, regression testing, and compatibility checks, then deliver the remediation through firmware, patches, application updates, or cloud deployment.
- Confirm the original issue is no longer exploitable
- Check for material regression risk
- Prepare update and mitigation guidance
Coordinated Disclosure and Closure
After the risk is reasonably controlled, publish appropriate security information, provide the reporter with an outcome, and incorporate lessons learned into the secure development lifecycle.
- Coordinate a CVE identifier when appropriate
- Acknowledge the reporter with consent
- Review root cause and improve continuously
Note: The timeframes below are Longse response targets, not fixed remediation deadlines for every vulnerability. Actual handling time may vary because of issue complexity, affected scope, third-party coordination, product lifecycle, or legal and regulatory requirements. Time spent waiting for required information from the reporter is excluded.
Response Targets
Response Targets
Defined communication milestones improve transparency without creating unrealistic fixed remediation commitments for complex firmware, supply-chain, or multi-version issues.
| Milestone | Target | Typical Output |
|---|---|---|
| Initial acknowledgment | Within 2 business days | Confirm receipt and assign a tracking identifier and responsible contact. |
| Initial validity assessment | Within 7 business days | Provide an initial conclusion: valid, duplicate, more information required, or currently not reproducible. |
| Scope and severity assessment | Within 10 business days after sufficient information is available | Confirm affected products and versions, severity, and intended next steps. |
| Critical/High progress update | Every 5 business days | Share mitigation, remediation progress, or disclosure coordination status. |
| Medium/Low progress update | Every 10 business days | Share validation, scheduling, release planning, or bundled remediation status. |
| Remediation and public disclosure | Based on risk and complexity | Firmware, patch, application update, cloud remediation, security advisory, or release note. |
Scope
Scope
This process primarily applies to officially released Longse products and services that remain within their supported lifecycle.
In Scope
- IP cameras, analog HD cameras, PTZ cameras, and specialized cameras
- NVRs, DVRs, XVRs, kits, and related network-enabled equipment
- Device firmware, embedded software, update mechanisms, and device communication protocols
- Mobile applications, PC clients, VMS products, browser plug-ins, and official tools
- Cloud platforms, cloud storage, open APIs, official websites, and official SDKs
- Actual security risks created by third-party or open-source components integrated into Longse products
Generally Out of Scope or Subject to Separate Review
- Unauthorized testing of customer, partner, or third-party production environments
- Denial-of-service, traffic stress testing, social engineering, phishing, physical intrusion, or destructive testing
- Scanner-only or theoretical reports that cannot be reproduced and lack supporting evidence
- Version information, page errors, or general hardening advice without actual security impact
- Issues caused solely by unchanged passwords, user misconfiguration, or defects in a third-party environment
- Products no longer supported or serviced; Critical or High risks may be assessed as an exception
Severity Rating
Vulnerability Severity Rating
Longse may reference the current applicable CVSS version and will also consider device exposure, exploitation conditions, impact on video, audio and personal information, customer scale, known exploitation, and remediation feasibility.
Examples include unauthenticated remote code execution, broadly applicable authentication bypass, large-scale device compromise, a broken update-signing chain, or failure of cloud tenant isolation.
Examples include high-impact authorization bypass, unauthorized video or audio access, exposure of important sensitive data, privilege escalation, or firmware tampering under realistic exploitation conditions.
Exploitation generally requires authentication, a specific configuration, local-network access, or significant user interaction, limiting impact or exploitability.
Exploitation conditions are difficult and impact is limited, without directly exposing sensitive information, granting privileges, or bypassing a primary security control.
General hardening recommendations, issues without direct security impact, or reports that do not constitute an exploitable vulnerability after validation.
Report a Vulnerability
How to Report a Vulnerability
A clear, reproducible report helps shorten validation and remediation time. Submit only the data necessary to reproduce and assess the issue.
1
Reporter InformationName or alias, organization (optional), a reliable email address, and whether public acknowledgment is permitted.
2
Affected Product or ServiceProduct name, model, firmware/software/application version, deployment method, region, and relevant configuration details.
3
Vulnerability DescriptionTitle, vulnerability type, technical explanation, attack preconditions, potential impact, and the reporter’s preliminary severity assessment.
4
Reproduction EvidenceClear reproduction steps, proof of concept, logs, screenshots, recordings, packet captures, or protocol exchanges. Remove unrelated personal information.
5
Disclosure and Remediation InformationWhether the issue has been reported elsewhere, any planned disclosure date, mitigations already applied, and suggested remediation where available.
Responsible Research
Responsible Security Research Guidelines
To protect customers, users, researchers, and company assets, follow these rules when conducting and reporting security research.
- Test only devices, accounts, systems, and data that you own or for which you have explicit authorization. Do not test customer or third-party assets without permission.
- Access only the minimum data needed to validate the issue. If personal information, video, audio, or other sensitive data is encountered, stop immediately and notify Longse.
- Do not damage, delete, modify, or retain data; install backdoors; establish persistent access; move laterally; or expand privileges.
- Do not perform denial-of-service testing, stress testing, malicious automated scanning, social engineering, phishing, extortion, threats, or physical attacks.
- Keep vulnerability details, proof-of-concept code, affected-customer information, and sensitive data confidential until a remediation is available or the agreed disclosure date arrives.
- Do not seek payment by threatening disclosure, selling data, or harming customers. Rewards and recognition are determined separately under Longse policy.
- Comply with applicable laws, regulations, and third-party rights. Obtain written permission before testing that may create real operational risk.
- Longse will handle reports submitted in good faith and in compliance with this policy professionally. Longse will generally not initiate action solely because of good-faith research that strictly follows this policy, but this does not excuse unlawful, infringing, out-of-scope, or harmful conduct.
Disclosure & Governance
Disclosure, Acknowledgment & Governance
Coordinated Disclosure
After customers can obtain a patch, updated version, or effective mitigation, Longse may disclose vulnerability information through a security advisory, release note, or customer notification. For multi-vendor or open-source issues, Longse will coordinate disclosure timing with the relevant parties.
Acknowledgment and Rewards
With the reporter’s consent, Longse may publish the reporter’s name or alias in an advisory or acknowledgment list and may provide a certificate, gift, or other recognition based on impact, report quality, and collaboration. Unless separately announced, this is not a promise of a cash reward.
Information Protection
Vulnerability information is shared only with personnel and partners who need it for response activities. Reporter information and test evidence will be protected in accordance with applicable law, data-minimization principles, and internal security requirements.
Duplicate Reports
For duplicate reports arising from the same root cause or describing the same issue, Longse will generally recognize the earliest valid report containing sufficient reproduction evidence. Later reporters will still receive an appropriate response.
Product Lifecycle
Products within their supported lifecycle are prioritized for remediation. Products no longer under full support or service will be assessed case by case based on severity, exploitability, customer risk, and remediation feasibility.
Policy Updates
Longse may update this process to reflect laws, regulations, industry standards, product scope, and practical experience. The version and date should be revised when updates are published. This page does not create a contract, warranty, or fixed compensation commitment.
Found a Security Issue in a Longse Product?
Submit a complete report through the dedicated security channel. A designated contact will follow up and keep you informed.