Policy Template for Software Development

The purpose of the Systems Development Life Cycle (SDLC) policy is to describe the requirements for developing and/or implementing software and systems at {{organization.name}} and to ensure that all development work is compliant as it relates to any and all regulatory, statutory, and/or contractual guidelines. This document establishes guidelines for the development of software and systems that are required to be applied to all developments to ensure their maintainability, security, protection against cyber-attacks and accessibility. 

This policy covers all development activities carried out by the {{organization.name}} team during the design, implementation and maintenance of {{organization.name}} products and services. {{organization.name}} follows a branching strategy workflow for source control and uses the principles outlined in the OWASP Secure Coding Practices to defend against the OWASP Top 10 security vulnerabilities.

{{organization.name}} Engineering team will consider the security implications of any feature development and/or enhancement to ensure the security and stability of the {{organization.name}}’s application. Things to consider are:

• How can this feature be misused?

• Does this feature cause unnecessary data exposure?

• Does this feature expose an attack vector?

• Are the data sources used by the feature trusted or untrusted?

{{organization.name}} follows a defined branching strategy. 

3.2.1 Feature Development

All new features start with a Requirements Specification provided by {{organization.name}} product staff. A separate Jira issue will be raised for every new feature. For simple features the requirements will be documented on the Jira issue description. For more complex features a wiki page will be created and the Jira issue will link to that. In most cases, a technical specification will be created by the Engineering staff. This technical specification should provide the implementation details & assumptions, data flows, database schema changes, endpoints and scope definition. The technical specification will be shared with the Product Owner for review.

A branch will be created in our source control system for each new feature developed. The branch name will follow the convention:

feature/XXXX

where XXXX is the Jira issue number corresponding to the feature.

All development for the feature is done on this feature branch. When the feature is complete, a pull request is made to merge the feature back into the release branch.

3.2.2 Pull Requests

Before a Pull Request (PR) can be merged into the release branch, it must be reviewed by another member of the Engineering team. The reviewer must not be the same person who created the pull request. A pull request comment must also indicate if there are any new dependencies added to the application, or database migration requirements.

The following things will be evaluated on a pull request review:

• Does the code follow {{organization.name}} coding style and naming conventions?

• Does the code pass the code analysis tool?

• Are there tests associated with the feature?

• Is the code readable and/or properly commented?

• Are there any obvious logic flaws or security holes?

• Is there any debug code left behind?

• Is audit logging properly implemented?

• Is the code reusable? (Where applicable)

• Are the tests within the pull request passed?

Once the pull request is reviewed, it can be:

Approved & merged into the release branch

Reviewer comments that the PR has been approved

Rejected with changes

Reviewer comments what the necessary changes are

After a pull request is reviewed, approved and merged, the associated feature branch may be deleted. PRs that have been rejected for changes will not result in a new pull request being created. The Engineering team member will make the required changes, commit to the associated feature branch and comment on the PR that the changes are completed. The reviewer will then verify the changes are correct and appropriate. If the changes pass review, the PR will be approved and merged. The feature branch may be deleted at this point.

3.2.3 Releases

When the release branch contains the required features for a release, the branch will be frozen and the product handed over to the {{organization.name}} Quality Assurance (QA) team. At this point no new features will be added to the release. Bug fixes and other release oriented tasks only may go into this branch.

Once the release is stable and ready to ship, the release branch is merged into master via a pull request. This provides one last opportunity to review the contents of the upcoming release. Once the release is merged into master, a tag is taken and an official release is created. This is what will be deployed to production. At this point, the release branch may be deleted.

3.2.4 Hotfixes

Occasionally, a bug is discovered in production that requires immediate patching. When this happens, a hotfix branch is created. The hotfix branch is forked from master. After the fix has been made, a PR is created to merge the fix back into master. The Standard PR review process shall apply. Once the hotfix branch is merged, it may be deleted. An official release is not necessary for hotfixes and the commit log will show the merging of the hotfix into the main code streams.

Where applicable, a test should be written that exercises the bug fix in order to prevent future regressions.

3.2.5 Branching Strategy Summary

The overall flow of the branching strategy is:

1. The master branch is the main development trunk. Tags on master indicate official releases.

2. Release branches are created from master.

3. All features are developed on feature branches.

4. When a feature is complete it is merged into the release branch.

5. When the release branch is done it is merged into master.

6. If an issue in the main/production is detected a hotfix branch is created from master.

7. Once the hotfix is complete it is merged to master.

Products and services released by {{organization.name}} require regular reviews for vulnerabilities and attacks. 

An external scan and penetration test will be performed annually.

All data processing inputs are defined, including the source and criteria for processing. All data processed by the {{organization.name}} application is collected directly by the application.

All data processing tasks include a data validation step that confirms the integrity of the data to be processed. Data integrity is enforced at the application level.

Input fields in the {{organization.name}} application are validated on both the client side and the server side for proper formatting, data type and expected values. The definitive source for data validation is on the trusted system (server). Invalid data will be rejected by the server.

All data inputs must be validated for:

• Character encoding

• Acceptable header / Cookie values

• Expected data types / ranges / lengths / valid values

• Allowed characters

User supplied data must never be passed to any dynamic execution function.

3.4.1 Data Processing Schedules

Data processing schedules are defined within the {{organization.name}} application. The results of the processing tasks should be logged and reviewed periodically. Errors and/or exceptions encountered in the processing task generate a detailed exception email that is sent to the DevOps team for remediation.

{{organization.name}} adheres to the following practices for authentication and password management:

• Authentication is required for all resources, except those explicitly intended to be public.

• Authentication is enforced on a trusted system (server).

• Authentication should fail securely.

• All credentials are encrypted with a one-way salted hash performed on a trusted system.

• Password complexity rules are enforced.

• Account disabling enforced after repeated invalid login attempts.

• Multi-factor authentication will be used.

{{organization.name}} adheres to the following practices for access management:

• Access token creation must be done on a trusted system.

• Access token generation must use sufficiently random identifiers.

• Token expiry should be as short as possible, balancing risk and business requirements.

• Generate a new access token on every re-authentication.

• Do not expose access tokens on an insecure channel.

• Logout must destroy any active access tokens for the user.

• Access controls should fail securely.

• ACL must be enforced on all API requests, including the org context.

• The master branch is a protected branch. Access to the protected branch is restricted to a limited number of DevOps personnel.

{{organization.name}} adheres to the following practices for error handling and logging:

• Sensitive information must not be disclosed in error responses.

• Debug or stack trace information will never be displayed on production systems.

• All logging implemented on a trusted system.

• Access to logs is restricted to specific personnel.

• Passwords and other credentials must never appear in logs.

• All system events must be logged.

{{organization.name}} adheres to the following practices for data protection:

• Implement principle of least privilege. We restrict users access to only the functionality and data that is required based on job needs.

• All temporary copies of data should be removed once processing is complete.

• All access credentials must be encrypted using a one-way salted hash.

• All transmission of data must be over secure channels.

• Remove application comments from client side code.

• Do not include sensitive data in GET parameters.

• Disable caching on pages containing sensitive information.

{{organization.name}} adheres to the following practices for communication security and as described in the Key Management and Cryptography policy:

• All transmission of data must be done over an encrypted channel using TLS.

• Failed TLS connections must not fall back to an insecure connection.

As currently available products and services are regularly assessed and reviewed, if a high-risk vulnerability is found, {{organization.name}} will notify the designated customer contacts within 24 hours. {{organization.name}} will provide a plan to address the issue and a timeline for when the software or service will have a solution available. Emergency updates will be available in the form of a hotfix patch deployed to the affected system.