ssldc_template

01_ssdlc.md

SSDLC Template

Goal: we raise baseline security without slowing shipping (too much). We favor defaults and automation over manuals.

Principles

• Secure by default: reduce choices when possible.
• Automation first: If it’s not in our CI, it’s probably not validated.
• Least privilege: for code, infra, and credentials.
• Traceable artifacts: every build has SBOM, signature, provenance, docs.

Lifecycle (fits in a sprint, cycle, whatever)

Plan & design

• Write a threat-model delta in the PR: what changes, data touched, trust boundaries, some realistic risks + mitigations (not more than 5). It’s okay when nothing changes.
• Choose crypto/protocols from an approved list (list can be a standard, for Germans e.g. BSI TR-02102); necessary deviations get documented.

Build

• Reproducible builds; lockfiles get committed.
• Minimal/non-root images; no secrets in repo. Pin everything you can pin.

Verify

• Unit/integration tests include at least one security proof from the delta.
• CI gates: lint, SAST, dependency scan (incl. transitives, save SBOM), container/IAC scan (trivy/syft etc.), scan license policy.
• Tests for log redaction and RBAC changes.

Release

• Semantic version; call out security changes in release notes/changelog.
• Attach SBOM + signatures + provenance to artifacts. Tell users how to verify your signatures.
• Ship secure defaults with documented, safe overrides.

Respond

• Public disclosure channel + SLA; patch policy by severity. Provide a Security.md if possible.
• Post-incident reviews with time-boxed follow-ups. Note down learnings and post-mortems.

Secure-by-default baselines

• RBAC: least-privilege roles; no default admin.
• TLS: on by default; sane ciphers; rotation guidance.
• Logging: structured; denylist/pattern redaction enforced by tests.
• Config: immutable inputs; safe defaults; explicit escape hatches.

Required artifacts (per release)

• SBOM (machine-readable)
• Artifact/image signatures + provenance
• Release notes/Changelog (security section)
• threat-model delta
• Values/config diff when applicable

Minimal metrics

You review these periodically; monthly is fine

• % builds with SBOM + signatures
• Time-to-fix critical/high vulnerability
• Open risk acceptances (count + avg age)
• Dependency freshness (within 30/90 days of latest)

02_pr_template.md

PR/MR Template

Drop it in your existing template

Summary

What changes + why, if you don’t already have this

Impact

Components/services; data touched (pii/secrets?). Again, if you don’t already have this

Threat-model delta

Keep it to less than 5. risks -> mitigations -> proof (test/monitor) 1) 2)

Secure-by-default

Change to your needs [ ] rbac least-priv [ ] tls sane [ ] logging redaction [ ] inputs bounded

Supply chain

*If your CI doesn’t handle this (it should) [ ] sbom attached [ ] image digest-pinned [ ] signed artifacts/provenance

Risk acceptance

We decided we won’t stand up to nation-state actors today 1) 2)