Secure Development Lifecycle (SDLC) Policy

Property	Value
Document ID	SID-POL-SDLC
Version	1.0
Effective Date	2026-04-12
Owner	Tech Lead
Review Cycle	Annual (next review: 2027-04)

1. Purpose

This document defines the Secure Development Lifecycle (SDLC) practices for all SirosID software repositories. It formalizes existing workflows and establishes minimum security requirements for code changes, reviews, and releases.

2. Scope

This policy applies to all repositories under the sirosfoundation GitHub organisation and to forked repositories maintained by SirosID (wallet-frontend, wallet-common, vc).

3. Repository Protection

3.1 Branch Protection Rules

All repositories must enforce the following on the default branch (main or master) and the release/sirosid branch (where applicable):

• Pull request required before merging — no direct pushes.
• Minimum 1 approving review from a team member.
• Branch deletion prohibited on protected branches.
• Force push prohibited (non-fast-forward) on protected branches.

These rules are enforced via GitHub Repository Rulesets. Only repository administrators may bypass these rules, and bypasses are logged.

3.2 Branch Strategy

Branch	Purpose
main / master	Default development branch; receives PRs
release/sirosid	Staging branch for integration/release (fork repos + core repos)
release/sirosid/vX.Y.Z	Versioned release snapshots (vc repo)
Feature branches	Short-lived branches for individual changes

4. Code Review Requirements

4.1 Review Process

All code changes must go through a pull request (PR) and receive at least one approving review before merge. The reviewer must verify:

1. Correctness — Code does what the PR description claims.
2. Test coverage — New code has tests; existing tests still pass.
3. Security — No hardcoded secrets, proper input validation, no new attack surface without justification.
4. Dependencies — New dependencies reviewed for known vulnerabilities and license compatibility.

4.2 Security-Sensitive Changes

Changes that affect the following areas require explicit security consideration in the PR description:

• Authentication or authorisation logic
• Cryptographic operations or key management
• PII processing or storage
• Network-facing APIs or protocol implementations
• Dependency updates that change security-relevant packages

4.3 PR Template

All repositories inherit the organisation-wide PR template, which includes a Security Checklist covering:

• No hardcoded secrets or credentials
• Dependencies reviewed for vulnerabilities
• Input validation and sanitisation
• Attack surface assessment
• PII/data protection compliance

5. Automated Security Controls

5.1 CI Pipeline

Every repository runs the following automated checks on pull requests and pushes to protected branches:

Check	Go Repos	JS/TS Repos
Static analysis	CodeQL (Go)	CodeQL (JavaScript/TypeScript)
Vulnerability scanning	govulncheck v1.1.4	npm/pnpm/yarn audit
Dependency review	dependency-review-action on PRs	dependency-review-action on PRs
Lint	golangci-lint	ESLint (where configured)
Tests	go test with race detector	Framework test runner

5.2 Supply Chain Security

• Dependabot is enabled on all repositories for automated dependency update PRs.
• SBOM generation (CycloneDX) runs on every push to the default branch, producing a signed artifact. See SBOM Monitoring for details.
• Go version is sourced from go.mod via go-version-file — no hardcoded versions in CI.
• GitHub Actions are pinned to specific versions or commit SHAs.

5.3 Scheduled Scanning

• CodeQL runs weekly (Monday 08:00 UTC) in addition to PR/push triggers.
• Dependabot checks for new dependency updates daily.

6. Release Process

6.1 Version Tagging

Releases are created by pushing a signed tag matching v*.*.*. The release workflow:

1. Runs the full test suite.
2. Builds release artifacts.
3. Generates an SBOM.
4. Creates a GitHub Release with changelog.

6.2 Container Images

For services with Dockerfiles, container images are:

• Built from the release tag.
• Published to ghcr.io/sirosfoundation/<repo>.
• Tagged with semver (vX.Y.Z, vX.Y, vX) and commit SHA.

7. Dependency Management

7.1 Update Cadence

• Security updates (Dependabot security advisories): Merged within SLA timelines (see Vulnerability Management SLA).
• Routine updates (Dependabot version updates): Reviewed and merged weekly.
• Major version updates: Require explicit review and may require migration planning.

7.2 New Dependencies

Adding a new dependency requires:

1. Checking for known vulnerabilities via govulncheck / npm audit.
2. Reviewing the dependency's licence for compatibility.
3. Confirming the dependency is actively maintained.
4. Noting the addition in the PR description.

8. Incident Response

Security vulnerabilities discovered in SirosID code or dependencies are handled according to the Vulnerability Management SLA.

Responsible disclosure reports should be directed to the contact in the organisation's SECURITY.md or security.txt.

9. Compliance Mapping

This policy addresses the following compliance requirements:

Finding	Framework	Control
EN-S-3	ENISA	Partial SDLC, change management and vulnerability scanning
ISO-T-3	ISO 27001	Secure development lifecycle gaps
ISO-T-6	ISO 27001	Partial vulnerability and malware protection
ISO-O-12	ISO 27001	Partial supply chain security

10. Document History

Version	Date	Author	Changes
1.0	2026-04-12	Platform Team	Initial version