Secure Development & CI/CD¶
Holmes develops software on GitHub and Azure in C#, Python, and TypeScript. This policy covers the security of that work: the pipelines, the dependencies, the secrets, and the code review. It applies to anyone writing or shipping code at Holmes, including AI-assisted and AI-agent development (05).
1. CI/CD pipeline integrity¶
| Ref | Requirement |
|---|---|
| DEV.1 | The default workflow token (GITHUB_TOKEN) permission MUST be read-only at the organisation level. Write and id-token permissions MUST be granted per job, only where needed. |
| DEV.2 | Reusable workflows MUST NOT use blanket secret inheritance (secrets: inherit). Secrets MUST be passed explicitly, per secret, to the jobs that need them. |
| DEV.3 | Use of pull_request_target and similar elevated-trigger patterns MUST be inventoried and restructured so untrusted fork code can't run with write access or read secrets. CI cache write boundaries MUST be assessed so fork PRs can't poison trusted caches. |
| DEV.4 | Build runners MUST be ephemeral, and pipelines MUST authenticate to cloud via short-lived OIDC federation rather than stored credentials where supported. |
2. Dependencies and supply chain¶
| Ref | Requirement |
|---|---|
| DEV.5 | Package-manager lifecycle and install scripts MUST be disabled by default (ignore-scripts for npm). Dependency installs MUST use locked, hash-verified installs: npm ci with committed lockfiles, pip install --require-hashes. |
| DEV.6 | A dependency ingestion cool-down (24 to 72 hours minimum release age) SHOULD be enforced via an internal artifact proxy or mirror, and a behavioural package firewall SHOULD screen new dependencies. |
| DEV.7 | Software composition analysis MUST run on all repositories with a defined remediation SLA, and automated dependency updates (Dependabot or equivalent) MUST be enabled everywhere. |
A short ingestion cool-down (DEV.6) blocks the common supply-chain attack where a compromised package is published and pulled into builds within hours, before anyone notices.
3. Secrets in development¶
| Ref | Requirement |
|---|---|
| DEV.8 | Secrets MUST NOT be stored in code, pipeline environment variables, or config files. They MUST be fetched at run time from the approved secret store, for example Azure Key Vault. |
| DEV.9 | Long-lived personal access tokens MUST be replaced by GitHub App installation tokens or OIDC. Where a static token is unavoidable, it MUST expire in 90 days or less, be minimally scoped, and be rotated on a documented schedule (03 IAM.24, IAM.25). |
| DEV.10 | Secret scanning with push protection MUST be enabled across repositories, the full git history MUST be scanned, and any exposed secret MUST be rotated regardless of age. |
A single over-privileged, long-lived token is enough to compromise an entire build system, which is why DEV.9 pushes toward short-lived, minimally-scoped credentials.
4. Code review and repository protection¶
| Ref | Requirement |
|---|---|
| DEV.11 | Default and release branches MUST be protected: at least one required reviewer, required status checks, and force-push restrictions. Admin bypass MUST be limited to named individuals. |
| DEV.12 | Static analysis (SAST, for example CodeQL) MUST run on code changes with a defined remediation SLA. |
| DEV.13 | Infrastructure-as-code (Terraform, Bicep) MUST be scanned before deployment, and container images MUST be scanned at build and in the registry. |
5. Programme foundations¶
| Ref | Requirement |
|---|---|
| DEV.14 | A secure-development standard and a named security champion MUST be maintained in the development function, with recurring (not one-off) security training. |
| DEV.15 | A vulnerability-management process for code MUST set severity-based remediation SLAs (indicative: critical 7 days, high 30, medium 90) and track security findings separately from functional backlog (10). |
| DEV.16 | GitHub Enterprise audit logs MUST be streamed to central monitoring, with alerting on anomalous CI/CD activity (11). |
| DEV.17 | A CI/CD incident-response procedure MUST exist, and it MUST remove attacker persistence before rotating credentials. Rotating first can hand new credentials straight to an attacker who still holds a foothold (12). |
| DEV.18 | A vulnerability-disclosure contact (security.txt, RFC 9116) SHOULD be published for Holmes' public-facing services. |
6. Legal & jurisdictional notes¶
Where Holmes develops software that processes client or personal data, secure-development obligations feed the appropriate technical measures expected under NZ Privacy Act 2020, GDPR Art. 32, and the AU APPs.
Supply-chain provenance (SBOM, DEV.7 and DEV.13) is increasingly a client and government-procurement requirement, especially for US federal-adjacent work, so it's worth tracking as a contractual driver.
Related policies¶
00 Framework, 03 Identity & Access, 04 Cloud & Third-Party, 05 AI Systems, 10 Vulnerability & Patch Management, 11 Logging & Monitoring, 12 Incident Response.