Secure Software Development Lifecycle Policy

Updated annually

The purpose of this policy is to establish standards for the development of internal tools and software that is intended to be operated within or interact with the production environment. Effective implementation of this policy will minimize unauthorized access to confidential and proprietary information assets.

All employees, contractors, consultants, temporary and other workers at the company and its subsidiaries must adhere to this policy. This policy applies to server equipment that is owned, operated, or leased by CodeREADr or on its internal network.

All source code is stored in Github. Access to the private source code repository (in Github and elsewhere) is restricted to authorized personnel, and access controls are enforced to maintain the security of the repository. Developer access to the source code repositories must be approved by appropriate engineering manager prior to granting any new or additional access rights. All access to source code or changes in access rights to the source code repositories must be logged and is subject to audit.

Production data may not be used for development or testing in the Stage or Development environments or local environments. Production data may not be exported by developers from the Production environment for any reasons. If production data is found on the Development or Stage environments it must be immediately reported to the DPO and deleted.

Discovery Phase – The discovery phase comprises of product feasibility and requirements gathering and is typically performed by the Product Manager.

Design Phase – During the planning and design phase high level designs, user stories and UI mock ups are created. Stories are broken up into tasks and estimated for complexity and effort which is measured in time (days). Stories and Tasks are assigned into Sprints. All planning and tracking is performed on JIRA.

Development Phase – During the development phase, engineers are assigned tasks from an active Sprint. Each developer has their own port running on the Dev Server where they can commit code without review. Engineers rely on manual peer code reviews to ensure the code changes are correct and the quality of code is high. Once their code has been reviewed and tested on their port they can submit a pull request to move the code to the main dev branch and main dev port 443. Once pulled on port 443 of the dev server a third party code analysis system runs automated SAST and code quality analysis and report on issues back to developers.

Testing Phase – Engineers write regression tests, unit tests, manual tests, and integration tests during this phase. Changes are tested locally by developers on Dev and verified to work on Dev by QA team. We use various testing tools for developing test cases. Once the code is verified on Dev it is moved to Stage environment where QA will run regression and security tests before approving for production.

Deploy Phase – Engineering managers will follow the Change Management procedures by submitting a CR to CAB which includes release notes of the update, and roll back procedures. Upon approval by CAB, a date and time is select to move code to production. Customers are notified of scheduled maintenance. Production pushes are coordinated and managed via Jira, Slack, GitHub and other automation tools. Stories are then tested in production until the Sprint is closed.

Monitoring Phase – We monitor all deployments post release to ensure stability and performance. Our engineering team rotates on-call and are responsible for fixing or rolling back any issues, if they ever occur.

Developers are expected to adhere to published coding standards throughout the development cycle, including standards for quality, commenting, and security. At a minimum, developers are expected to address the common security issues in the OWASP top-10 in the course of their design, development, reviewing, and testing efforts. Developers performing peer code reviews are expected to have taken requisite security training and are to examine the new or revised code and provide feedback. Review must confirm that the code does not violate any security principles or design objectives. In-scope software must be subjected to standardized tests that include both functionality and security testing. Any security issues detected during testing must be addressed prior to release. Emergency Actions taken the Team Lead or Net Ops on production systems must always be logged and audited.

To satisfy security requirements, we have established application security evaluation checklist:

Architecture & Design Review

• ADA Compliance Review
• Operating Environment Review

Secure Coding Standards Review

• Manual Code Review

Privacy & Data Protection Review

• User account and privilege management
• Data handling, exposure, and behavior

Vendor & 3rd Party Libraries Review

• Interactions with other systems

Vulnerability Scan
Security Testing

• OWASP Top 10

Customer Requirements

• External security and compliance requirements

The Product Manager will verify compliance to this policy through various methods. Any exception to the policy must be approved by in advance. An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.