Ship, Securely, Ch. 6: Conclusion

October 7, 2025 · 6 min read · #devsecops, #ship-securely, #security

Part of Ship, Securely, a hands-on DevSecOps book.

Chapter 6. Conclusion and Next Steps

You just built a local-first DevSecOps stack that runs anywhere a laptop does. It ships a working app on day one, grows in small, testable waves, produces evidence for every step, and hardens both your supply chain and runtime without cloud spend.

This chapter helps you (1) summarize what you’ve built, (2) ratchet quality safely, (3) map your make targets to a hosted CI, and (4) roll it out with sane ownership, SLAs, and audit-ready artifacts. Finally, you’ll get a compact “what’s next” backlog.

5.1 What You Built (at a glance)

Area	You now have	Evidence
Build & Scan	`make ci` runs SAST (Semgrep), secrets (TruffleHog), Dockerfile lint (Hadolint), IaC (Checkov), SBOM (Syft), container SCA (Trivy)	`./artifacts/*` (JSON/TXT/HTML)
Supply Chain	SBOMs + Cosign signature bundle, Trivy gate, SBOM diff, license check	`sbom.json`, `sbom.bundle`, `trivy-image.json`, `sbom-diff.txt`, `license-scan.txt`
Deploy (Local)	`make cd` builds → scans → promotes → loads to Minikube → applies k8s → rollout verify	`kubectl rollout status`, `k8s-verify`
Runtime Guardrails	Kyverno (verify images, org-allow), Pod Security (restricted), RBAC least privilege, NetworkPolicies	`policies/*.yaml`, `artifacts/policy-apply.txt`, `artifacts/rbac-verify.txt`
Testing	ZAP baseline DAST, simple WAF demo	`artifacts/zap/*`, `artifacts/waf-test.txt`
Process	Evidence ZIP, tuned blocking policy, vuln mgmt lifecycle (optional DefectDojo)	`artifacts/evidence-YYYY-MM-DD.zip`, `ARTIFACTS.md`

Design principles: local, offline-friendly, copy-pasteable commands, minimal moving parts, and every change leaves a trail in ./artifacts.

5.2 Ratcheting & Blocking (6-week roadmap you can actually keep)

Start permissive, tune noise, then gradually enforce. Each step adds one small risk reduction with clear success signals.

Week	Change	Rationale	Success signal
1	Secrets: block verified credentials; warn the rest	High signal, low false-positive rate	0 spurious breaks; verified hits get fixed same day
2	SAST: block a curated High/Critical set	Catch top OWASP issues early	PRs fail only on real, fixable code issues
3	SCA: block Critical (and High w/ fixes)	Remove known-bad libs from images	Trivy High/Critical = 0 in RC images
4	IaC: enforce `runAsNonRoot`, seccomp, probes, drop caps	Safe runtime defaults; resilience	Checkov failed→0 for key rules
5	Admission: Kyverno verifyImages + org-allow	Stop untrusted images from running	Bad pods denied; policy test shows “deny/allow” as expected
6	Licenses: WARN → ENFORCE allowlist	Legal & commercial hygiene	No “DISALLOWED” licenses in release builds

Keep the ratchet visible: add a short “Blocking Policy” section to your repo README with the current gates and how to request an exception.

5.3 From Laptop → Hosted CI (thin wrappers around `make`)

Your Makefile is the contract. CI jobs stay tiny and durable.

Example — GitHub Actions

name: ship-securely
on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - name: Run CI (local parity)
        run: make ci

  gate-and-artifacts:
    needs: build-and-scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Enforce SCA gate & collect evidence
        run: |
          make sca
          make evidence || true
      - uses: actions/upload-artifact@v4
        with:
          name: artifacts
          path: artifacts/**

Mapping Cheat-Sheet

Make target	GitHub Actions	GitLab CI	Jenkins
`ci`	job `build-and-scan` → `run: make ci`	stage `build` → `script: make ci`	“Build” stage shell step
`promote`	`needs: build-and-scan` → `run: make promote`	stage `release`	post-build step
`k8s-audit`	job `k8s-audit` → `run: make k8s-audit`	stage `test`	“Test” stage
`kyverno-*`	cluster context in staging env	same	same
`evidence`	upload artifacts	`artifacts:`	archive artifacts

For staged environments, call the same targets; just swap kubeconfig/namespace via environment variables.

5.4 Operating Model (RACI, cadence, SLAs)

Ownership

Activity	Dev	Security	Ops/Platform
Fix SAST/Secrets/IaC in owned code	R	C	I
Curate rules, tune noise	C	R	C
Kyverno/PSA/NetPol policy	I	R	R
SBOM/sign/SCA thresholds	I	R	R
Weekly triage & SLAs	R (for their code)	R (policy + coaching)	C
Evidence & audits	C	R	R

SLAs (starter): Critical ≤ 7d, High ≤ 30d, Medium ≤ 90d.
Ceremonies: 15-min weekly triage; monthly “ratchet” review; quarterly policy refresh.

5.5 Compliance Cheat-Sheet (show, don’t tell)

Ask	Show this	Where
“Prove you scan code & images”	`semgrep.json`, `trivy-image.json`	`./artifacts`
“Prove SBOM + integrity”	`sbom.json`, `sbom.bundle` (+ `cosign verify`)	`./artifacts`
“Prove supply-chain policy”	Kyverno `verify-image-signatures.yaml`, `policy-apply.txt`	`./policies`, `./artifacts`
“Prove runtime limits”	Deployment `securityContext`, `NetworkPolicy` YAMLs	`infra/k8s/**`
“Prove findings are managed”	Evidence ZIP, `ARTIFACTS.md` (or DefectDojo export)	`./artifacts`

5.6 What’s Next (sane backlog)

Item	Why	Effort
Provenance (SLSA) with `cosign attest`	Trust the how of the build, not just the bits	Med
Commit signing & branch protections	Reduce supply-chain PR tampering	Low
Renovate/Dependabot (self-host ok)	Keep deps fresh, shrink CVE surface	Low
External Secrets Operator	Pull secrets from KMS without plaintext in Git	Med
`kube-bench` (CIS)	Cluster baseline scorecard	Med
Centralized alerts	Turn ZAP/Kyverno/Falco into notifications	Med
CI templates	Publish your `make` wrappers for the org	Low

5.7 Thank You & Call-to-Action

If this book helped you, consider:

Keep building: fork the starter repo, adapt the Makefile, and add one control per sprint.
Stay current: subscribe to the mailing list (free PDF, update notes, and new checklists).
Go deeper with your team: workshops, ruleset curation, or a focused pentest on your app’s threat model.
Give back: open a PR with improvements to the demo app, policies, or docs.

You now have a working, auditable DevSecOps stack that fits in your backpack. Keep it small, keep it practical, and keep shipping—securely.

Chapter 6. Checklist

Move from “works on my laptop” to “works for the org”.

Rollout & Governance

Scope: Which apps/teams adopt this first (pilot group)? What’s the rollout wave plan?
Ownership: Who owns Make targets, policies, and mirrors (Dev / Sec / Platform)?

Metrics & Reporting

KPIs: Which 3 numbers will you track? (e.g., High vulns in RC, SLA compliance, time-to-fix)
Cadence: Weekly triage? Monthly ratchet review? Quarterly policy refresh?

CI/CD Migration

Mapping: Have you mapped make targets to your CI (Actions/GitLab/Jenkins)?
Runners: Who maintains runner images (tooling versions aligned with local Make)?

Training & Culture

Training gaps: Does your team need OWASP Top 10 / Secure Coding refreshers?
Playbooks: Do you have incident and “deny at admission” runbooks?

Budget & Tools

Costs: Any paid tools needed now? If not, what will trigger a purchase later (scale, SLA)?
Key management: Where do cosign keys live (HSM/KMS)? Rotation schedule?

Audits & Evidence

Evidence path: Where do ./artifacts and evidence ZIPs live for audit?
Third-party requests: Can you produce SBOMs/signature bundles for customers on demand?

Resilience & Risk

Backups: Are mirrors, keys, policies, and artifact stores backed up & recoverable?
Bus factor: If one maintainer is out, who can run the release and fix the gates?

Backlog & Evolution

Next steps: Provenance (SLSA), commit signing, Renovate/Dependabot, External Secrets, kube-bench — what’s next and when?
De-risk: Which area feels riskiest today (people/process/tech)? What’s the first experiment to address it?

← Back to the blog