Secure Software Development Policy

Secure Software Development is fundamental to the work that Etch carries out of a day to day basis.

Without a secure baseline, the applications and code that we produce are left open to infiltration and exploitation.

If any user does not fully understand anything in this policy, they should consult with the persons listed under Responsibility.

The aforementioned persons shall resolve any conflicts arising from this policy.

Platform

All CI and CD must be done using GitHub Actions, in order to ensure that build environments are ephemeral, immutable, and secure from remote access.

Only select actions are allowed. Actions are whitelisted prior to use, and using a non-whitelisted action will cause the workflow to fail.

Access

The default, organisation level scope for actions must be read-only, following the principle of least-privilege access. Write access must be assessed on a case-by-case basis, with sign off from both team members listed under Responsibility.

Automation access keys must expire automatically. By ensuring that access keys used by automation expire periodically, we create a shorter window of attack if keys are compromised.

Code Scanning

Static application security testing (SAST) must be run in the CI pipeline, and any critical or high-severity failures must break the build.

Dependency Auditing

All repositories must have Dependabot enabled, and pull requests must be merged in a timely manner.

All repositories must also have an audit workflow that runs at least once every 24 hours, and any issues flagged by that must be addressed in a timely manner.

Package Provenance

Packages that are published to NPM must be published with provenance. See the npm documentation for more information. N.B. this is a work in progress. Packages that were created prior to this policy should be migrated, but there is no set timeline for this.

Deployment

Deployment artifacts must be compiled on a build server, and deployed using Ansistrano.

Deployment artifacts must only ever include compiled code, and must never deploy development dependencies.

Branch Protection

All production and UAT branches must be protected to ensure that all code passes review and status checks before being promoted to user-facing environments.

Pull Requests

Pull requests require two reviewers and all status checks to pass to be merged into production and UAT branches. In addition to supporting good coding practices, this control also helps ensure that no commits are made without competent human oversight.

Commit Signing

All commits must be signed with a GPG key by their author. Unsigned code commits are challenging to trace and pose a risk to the integrity of the code base.

Authors must use their etch.co email address to sign commits.

GPG keys should be:

• added to employee's Github accounts
• enabled by default git config --global commit.gpgsign true
• published on https://keys.openpgp.org.

Key Signing

Etch staff members can sign each other's keys at meetups, and are, of course, welcome to attend any key signing parties that they wish.

Hardening

Servers must be hardened with the DevSec framework, to provide a secure baseline for systems.

Scanning

Servers and sites must be regularly scanned with Zed Attack Proxy and nikto.

Guidelines for scanning are set out in the Security Scans document, and should be treated as part of this policy.

In this policy, the following terms are defined as follows:

Us/We/Etch

Etch Software Limited

Although this Policy explicitly covers the responsibilities of staff, it does not cover the matter exclusively. Other Etch policies, standards, and procedures define additional responsibilities. All users are required to read, understand and comply with other policies, standards, and procedures. If any staff member does not fully understand anything in these documents, they should consult with the persons listed under responsibilities. The aforementioned persons shall resolve any conflicts arising from this policy.