Secure Design & Coding Practices

Feature Design:

• Features are designed using Figma so that the behavior can be clearly understood by the development team.
• Features are designed using the FDS Design System which has been created with security concerns in mind.
• During design, the security and privacy requirements for a feature are specified so that the developers are not required to make assumptions.
• Features are defined and designed as stories in <Github Projects>.
• During backlog refinement, the team has the opportunity to ask questions and fully understand the intent and the technical challenges of the features. * Security considerations are discussed as a team before development begins.
• Changes impacting privacy and/or security will trigger an update to the project's PIA and STRA. Periodically, the updated PIA and STRA will be submitted for review by privacy and security analysts for updated approval.
• Logging requirements are specified as part of new features when necessary.

Development Environment Setup:

• Developers will always work on a secure network.
• Production secrets (API keys, database credentials, etc.) will be stored securely by developers and never checked into GitHub or exposed publicly.
• In the event of an accidental exposure of a secret, the incident will be immediately reported and the team will rotate the secret that may have been leaked.
• Production secrets will shared between developers in a secure manner. Our current practice is to put the value into manually for other developers to be able to access (and nobody else).
• Developers will not download and host production data on their development environment.
• Developer workstations will be secure. This means that the workstation is locked when not in use, and that the workstation operating system and critical software is kept up to date to prevent vulnerabilities to malicious software. Developers will keep anti-virus software up to date.

Development Process:

• Developers need to be aware of secure coding practices such as https://owasp.org/www-project-developer-guide/draft/.
• Developers will follow the standards define by the architecture group here: Coding Patterns & Practices.
• Each subcomponent of a solution should have its own Sonar profile. Projects - Province of British Columbia (sonarcloud.io)
• Sonar quality gates are integrated into the pull request checks. Sonar will fail the check if the quality gates do not pass.
• Pull request checks include running unit tests. If the unit tests do not pass, the PR check fails.
• Sonar is configured to fail the build if the code coverage of the unit tests dip below the proscribed threshold.
• A pull request cannot be merged to main without passing all the checks.
• No code is merged to main without a pull request.
• Every pull request must be reviewed and approved by a team member other than the author.
• Libraries are scanned by Dependabot and Renovate to identify potential patches and version updates. Every sprint, the team evaluates the necessary upgrades and applies them.
• Functions in the product will always output adequate logging information. The logs will be rich enough to facilitate anomaly detection as well as investigate incidents. New features will generally require updates to the log messages.

Environment & Release Management:

See the nr-spar repo for the implementation details and the process details.

• Environments will be managed by triggering GitHub Actions and Terraform jobs.
• Each environment has its own set of secrets. It is not possible to successfully deploy to these environments without knowing the appropriate secrets. * * Only the GitHub administrator for the repository can change the secrets, and the values can never be retrieved.
• GitHub Actions that deploy to non-development environments (not "Tools" or "Dev") must be approved by certain team members. This rule is enforced by GitHub. Only GitHub admin can manage the list of approvers for the environments.
• The main branch cannot be merged into without a pull request.
• The "Test" and "Prod" environments can only be deployed from the main branch. This rule can be temporarily amended to include a hotfix branch if necessary, but only by the repository administrator. The change will be reverted after the hotfix is completed.
• Release notes for each version of the product will be maintained in GitHub and include a list of changes for each version.
• The team creates a release checklist for each version. Release checklists are managed under in Confluence.
• Periodically, the latest version of the product will be scanned for vulnerabilities defined by OWASP. see https://owasp.org/www-project-developer-guide/