Secure Development Lifecycle (SDLC) Policy

Policy status

Status: Approved · approved 2026-09-10

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 with production-facing code must enforce the following on the default branch (main or master or the release/sirosid branch where applicable):

• Pull request required before merging — no direct pushes.
• Minimum 1 approving review from a team member for changes that require review (cf below).
• Branch deletion prohibited on protected branches.

These rules are enforced via GitHub Repository Rulesets. Only repository administrators may bypass these rules, and bypasses are logged. When changes are authored by an LLM the change is approved by a human. Because of github limitations this approval may take take the form of a github admin override merge.

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 and Roles

4.1.1 The Code Owner

All code changes are done via pull requests (PRs). All PRs are automatically screened for test coverage and for security and code quality issues using a number of automated tools. Developers that have the code ownership role for a repo is responsible for making a judgemet call on each PR. The lead developer should rely on reviews from team members for all PR and must request and receive at least one approving review on any PR that is directly security related. If the code owner is fully confident that a change doesn't introduce a risk they may merge it directly, bypassing the automated review block. This must be accompanied by an explicit note listing the reason.

Reasons that are generally acceptable include the following:

• minor change (typographic correction, comments etc)
• test/CI fixes that increase test coverage and doesn't otherwize change the functional properties of the code
• new work that is being tested and reviewed elsewhere (note on were in the comment)
• release-notes and other documentation updates

Reviews should be used for

• security related changes
• changes that changes the configuration and deployment of service components

Regardless of the reason for an override on the general review block the code owner is responsible for the decision.

When in doubt, always ask for a review.

4.1.2 The Reviewer

Reviewers work from their individual experience and it is the responsability of the code owner to decide on suitable choices for reviewers. The reviewer should 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.

Code reviewers may depend on automated tooling to provide input to the review. Reviewers must signal if they are unsure about material aspects of the code they are asked to review.

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 except when existing, well tested libraries are used
• PII processing or storage

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

This PR checklist is used by all external PRs

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.
• 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.
• Listed on developers.siros.org

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 document (SID-POL-VULNMGMT).

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	Leif Johansson	Initial version
1.1	2026-08-20	Leif Johansson	Clarifications