Secure Engineering Policy

1. Overview

Software Secured is committed to working with our customers as securely as possible. This Policy outlines the practices and procedures Software Secured follows to ensure any products or services delivered to our customers adhere to this philosophy. The policy comprises secure engineering activities including but not limited to Threat Modelling, Static Analysis, Dynamic Analysis, and Penetration Testing.  

2. Purpose

The purpose of this policy is to establish a standard practice for always delivering and shipping secure code.

3. Scope

The scope of this policy includes all personnel who have or are responsible writing code or delivering products or services to Software Secured clients. It encompasses all software Software Secured has ownership of which contains customer data.

4. Policy

4.1 Threat Modeling

4.1.1 A Threat Modeling exercise will be conducted during the creation of any new product or service to identify security risks and avoid or mitigate serious risks by design.

4.1.2 A smaller targeted Threat Modeling Exercise will be performed on any new features before they are added.

4.1.3 A Threat Modeling Exercise will be performed annually on all components that contain or may contain any form of customer data.

4.2 Secure Code Review & Scanning

4.2.1 All code will undergo either an automated scan using a company approved tool or manual secure code review prior to initial release or significant updates.

4.2.2 All Dependencies will also be scanned using a company approved tool or evaluated for weakness prior to inclusion on any project and on a bi-annual basis.

4.2.3 Identified issues will be addressed per the Vulnerability Management process in 4.5.

4.3 Dynamic Analysis

4.3.2 New features will undergo targeted dynamic scanning prior to release.

4.3.3 Identified issues will be addressed per the Vulnerability Management process in 4.5.

4.4 Penetration Testing

4.4.1 Penetration Testing will be performed on all components on a quarterly basis.

4.4.2 Identified issues will be addressed per the Vulnerability Management process in 4.5.

4.5 Vulnerability Management

4.5.1 All confirmed vulnerabilities will have severity scored for impact (based on CVSS) and risk (Based on DREAD) in accordance with Software Secured Scoring guidelines

4.5.2 All known issues will be logged in the SRC’s Issue tracking page and when appropriate also in Github under the associated project for development tracking.

4.5.3 Vulnerability SLA’s: Critical Severity issues will be addressed prior to release or within a maximum 5 business days for already deployed code High Severity issues will be addressed prior to release or within a maximum 30 business days for already deployed code Medium Severity issues will be addressed within a maximum 90 business days for already deployed code Low Severity issues will be addressed within a maximum 180 business days for already deployed code Informational Severity issues will be evaluated and addressed if warranted at the discretion of Software Secured

4.5.4 Exception/Extension Process

If an evaluated vulnerability cannot be addressed within SLA due to complexity, time, expense, or other factors an exception may be requested.  The specific issue(s) will undergo additional risk assessment to determine:

a) if an exception is warranted

b) A feasible timeline and action plan for addressing the issue

c) Additional controls or mitigations which can be implemented to reduce the risk of exploitation.  

If the SRC approves an Exception/Extension it will be clearly documented along with the short term and long term application plan in the associated ticket.

5. Disclosure

5.1 Vulnerabilities in Shipped Code: Software Secured will issue a public disclosure for any vulnerabilities detected and remediated in code it delivers to customers indicating the type of vulnerability, risk level, and patching or mitigation instructions.

‍5.2 Vulnerabilities in Hosted Code: Software Secured will evaluate and fix vulnerabilities in hosted code in accordance with the above policy.  If Software Secured observes evidence of vulnerability exploitation or IOC’s for high or critical severity vulnerabilities Software Secured will make efforts to contact any impacted customers and notify them of any risk or potential exposure to their data as transparently as possible as indicated by the security incident response policy.

6. Policy Compliance

6.1 Compliance Measurement: The SRC will verify compliance to this policy through various methods, including but not limited to, periodic walk-throughs, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

‍6.2 Exceptions: Any exception to the policy must be approved by the SRC in advance.

‍6.3 Non-Compliance: An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.