(Last update )
Introduction
The security of our SDK is paramount to the integrity, trustworthiness and reputation of our organization and partners.
This https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures (CVE) Management Policy outlines our commitment to proactive measures in preventing and addressing security vulnerabilities in HOOPS & CEETRON products.
Roles and Responsibilities:
Security is a shared responsibility within our organization.
...
Developers: Developers are responsible for writing secure code and implementing best practices as outlined in our Secure Coding Guidelines. They must also promptly address any security vulnerabilities identified during development.
Quality engineer: Quality engineers are responsible for thoroughly testing the software for security vulnerabilities, identifying potential issues, and reporting them. They work closely with developers to verify vulnerability fixes.
Managers and Tech Leads: Managers and tech leads are accountable for ensuring that security practices are integrated into our test & delivery pipeline and for allocating resources to address vulnerabilities promptly.
Employees: All employees are responsible for maintaining security awareness and promptly reporting any security concerns they encounter during their work.
Prevention
We encourage all employees to stay informed about the latest security threats, vulnerabilities, and best practices. This includes:
...
Code reviews: Every single code change is validated by a peer developer before being pushed to an official branch of our source control system.
For web toolkits, we run a security audit (
npm audit) before every release.We are also occasionally running security scans to discover runtime vulnerabilities for our major release.
Third-party libraries:
We evaluate the security of third-party software before integration.
We review third-party component updates for security patches before every major or minor release
We maintain a list of approved third-party software for use in our projects.
We keep an updated list of third-party components, with the right version in our documentation.
Escalation
In the event of a security incident or breach, we follow a well-defined incident response procedure:
...
We will utilize more specifically the https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System (CVSS) scores.
Resolution
Once a CVE has been escalated, we execute the subsequent actions:
...
Severity | Base Score | Resolution Timeframe |
|---|---|---|
None | 0 | No Plan |
Low | 0.1-3.9 | 1- 2 Quarters (6 months) |
Medium | 4.0-6.9 | 1 Quarter (3 months) |
High | 7.0-8.9 | 1-2 months |
Critical | 9.0-10.0 | 1- 4 weeks |
Internal vs external CVE
As our libraries incorporate two categories of https://en.wikipedia.org/wiki/Open-source_software (OSS), we shall differentiate them as follows:
...
The extent of our control over identifying and rectifying CVEs diverges based on whether the OSS and CVEs are internal or external. Our commitment to resolving specific CVEs is applicable solely to internal OSS. For external OSS and CVEs, our sphere of influence is confined to communication and collaboration with the respective software vendors.
Continuous Improvement
We foster a culture of continuous improvement in our security practices. Key components include:
Periodic reviews of security policies to adapt to evolving threats and technology.
Ensuring that policies remain aligned with industry standards and best practices.
Learning from security incidents and using them as opportunities for improvement
Specific CVEs
| Child pages (Children Display) | ||
|---|---|---|
|