CVE Management Policy

(Last update Oct 25, 2023 )

Introduction

The security of our SDK is paramount to the integrity, trustworthiness and reputation of our organization and partners.

This 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.

To maintain a robust security posture, we define the following Tech Soft 3D roles and responsibilities:

• 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:

• Regularly attending security training and awareness programs.

• Keeping abreast of industry news, threats, and trends related to software security.

• Reporting any suspicious activities or security concerns to our Slack channel

Secure coding guidelines are essential to our efforts in preventing security vulnerabilities from the outset. Developers must adhere to these guidelines when writing code. Our guidelines encompass:

• Input validation to prevent injection attacks.

• Using Security-Enhanced CRT and removing all security warnings from the C++ compiler.

• Proper authentication and authorization controls.

• Avoidance of known security pitfalls as outlined in OWASP Top Ten | OWASP Foundation.

We conduct the following assessments:

• 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 monitor daily CVEs detected by our team or reported in our support system (Jira service desk) by our partner) and expeditiously investigate such issues.

• For a comprehensive understanding of identified CVEs, we consult the National Vulnerability Database (NVD) to evaluate their details and severity.

We will utilize more specifically the Common Vulnerability Scoring System (CVSS) scores.

Resolution

Once a CVE has been escalated, we execute the subsequent actions:

• Upgrade of Affected Third Party Dependency: We will update the version of the implicated Third-Party Dependency to the latest secure iteration.

• Substitute Vulnerable APIs: In the same Third-Party Dependency, we will substitute vulnerable APIs with secure alternatives.

• Replacement of Vulnerable Dependency: If necessary, we will replace the vulnerable Third-Party Dependency with an appropriate substitute.

We have defined a timeline to address CVEs. It’s outlined below and serve as guidance:

Internal vs external CVE

As our libraries incorporate two categories of Open-source software (OSS), we shall differentiate them as follows:

• Internal OSS and Associated CVEs: These pertain to CVEs originating directly from OSS used within our libraries, such as Boost and PDFium.

• External OSS and Associated CVEs: These concern CVEs emanating from OSS utilized by our software vendors, such as PDFL and ODA.

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