SecOps Workflow¶
This page describes the repository-level SecOps workflow for the homelab GitOps stack.
The controls are added one tool at a time. CI checks and audit-only workflows come before any live-cluster enforcement.
Current Scope¶
The repository already contains several security-relevant services:
- DefectDojo for vulnerability tracking.
- OpenVAS for vulnerability scanning.
- Wazuh for runtime/security monitoring.
- Renovate for dependency update pull requests.
- SOPS age preparation for future encrypted secret files.
- Infisical and Vaultwarden for secret-management workflows.
- AWX and Semaphore for future remediation workflows.
The current repository also has known tracked secret-like files. New controls must not print secret values or require immediate history cleanup without a separate rotation and rollback plan.
Planned Control Chain¶
Git / CI
-> secret scanning
-> Kubernetes manifest scanning
-> image vulnerability scanning
-> vulnerability tracking
-> Kubernetes policy in audit mode
-> runtime detection
-> AWX or Ansible remediation
Secret Scanning¶
The first control is Gitleaks secret scanning.
Initial behavior:
- Forgejo CI installs pinned Gitleaks
v8.30.1. - Scan only the new commit range introduced by a pull request or push.
- Redact findings in logs.
- Avoid committing a baseline report.
- Avoid scanning or printing known secret-like files outside the changed Git range.
Local usage:
Scan an explicit range:
The local command requires gitleaks on PATH. Forgejo CI installs a pinned binary before running the scan.
Kubernetes Manifest Scanning¶
The second control is Kubeconform schema validation for rendered standardized overlays.
Initial behavior:
- Forgejo CI installs pinned Kubeconform
v0.8.0. - The scan renders each standardized
overlays/<cluster>/path withkubectl kustomize --enable-helm. - Missing schemas for custom resources are ignored so existing Traefik, Fleet, and workload CRDs do not block the first pass.
- Built-in Kubernetes resources are validated in strict mode.
Local usage:
The local command requires kubeconform on PATH. Forgejo CI installs a pinned binary before running the scan.
Trivy Reports¶
The third control is Trivy report-only filesystem vulnerability scanning.
Initial behavior:
- Forgejo CI installs pinned Trivy
v0.72.0. - The scan uses
make secops-trivy-scan. - Reports are generated as JSON, SARIF, and table output.
- Findings do not fail CI because Trivy runs with
--exit-code 0. - Trivy secret scanning is disabled; Gitleaks owns repository secret detection.
- Trivy misconfiguration scanning is not enabled in this first pass because the initial repository test produced a built-in Rego evaluation error. Kubeconform remains the Kubernetes manifest/schema check.
Local usage:
Write reports into the local working tree when testing artifact output:
.secops-reports/ and .trivy-cache/ are ignored by Git.
Ansible Boundary¶
This k8s repository does not contain the main Ansible project layout.
The Ansible content is a separate workspace repository at:
That repository has split docs, inventories, playbooks, roles, plugins, tests, and vault files. Ansible linting should be added there or through a deliberate cross-repo CI handoff, not by making the k8s Forgejo workflow scan a sibling repository path.
Tool Status¶
The source of truth for tool status is:
The implementation roadmap is:
DefectDojo Boundary¶
DefectDojo exists as a deployed service, but CI findings are not uploaded yet.
Before enabling uploads, decide:
- Product and engagement naming.
- API token ownership.
- Whether uploads are blocking or informational.
- Which reports are retained.
- How false positives are tracked.
Do not add DefectDojo API tokens to Git.
Kubernetes Policy Boundary¶
Policy work must start in audit mode.
Do not deploy enforce-mode policies until:
- Current workloads have been scanned.
- Exceptions are documented.
- Operators have reviewed audit results.
- Rollback is clear.