Secure Software Development Lifecycle Policy

Updated Annually

Overview

All of the company software is developed using the Agile mythology. Our agile and CI/CD practices are referred to as the Agile Software Development Lifecycle (SDLC). Our engineers work in short iterative sprints which comprise discovery, design, development, testing, and release phases. This allows us to release features quickly with confidence and iterate quickly to improve features over time. Security and privacy tasks are integrated into the SDLC as a seamless, holistic process designed to produce software that has appropriate security and privacy built into it.

Purpose

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.

Scope

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 ID123 or on its internal network.

Source Code Policy

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 the 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

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 reason. If production data is found on the Development or Stage environments it must be immediately reported to the DPO and deleted.

Phases

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

6.2 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 to Sprints. All planning and tracking are performed on JIRA.

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

6.4 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 the QA team. We use various testing tools for developing test cases. Once the code is verified on Dev it is moved to the Stage environment where QA will run regression and security tests before approving for production.

6.5 Deploy Phase
Engineering managers will follow the Change Management procedures by submitting a CR to CAB which includes release notes of the update and rolls back procedures. Upon approval by CAB, date and time are 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.

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

Security

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. The 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 by the Team Lead or Netops on production systems must always be logged and audited.

To satisfy security requirements, we have established an 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

Policy Compliance

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