DevSecOps Practice Hub

Audit & Traceability

Maintain a tamper-resistant record of who changed what, when and with what approval.

IntermediateAuditGovernanceIdentity

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Release Approval controls, artefact promotion and provenance.
  • Operate Runtime security, secrets rotation and configuration reconciliation.

Overview

Audit trails span git history, pipeline runs, approvals, cluster API activity and cloud control-plane events, correlated so a production change can be traced to its commit and approver.

Why it matters

Traceability is a compliance requirement and the backbone of incident investigation.

How it works

  1. 01Audit logging is enabled at each control plane.
  2. 02Logs are shipped to storage the platform team cannot silently modify.
  3. 03Deployment identifiers link runtime state back to commits.

Common tools

Kubernetes AuditElastic SecurityGitLabKubernetesAWSGitLab

Implementation examples

yamlKubernetes audit policy
apiVersion: audit.k8s.io/v1kind: Policyrules:  - level: RequestResponse    resources:      - group: ""        resources: ["secrets", "serviceaccounts"]  - level: Metadata    omitStages: ["RequestReceived"]
Full request/response logging for secrets access, metadata elsewhere, keeps volume manageable.

Best practices

  • Store audit logs outside the audited system.
  • Link runtime artefacts to commits.

Common mistakes

  • Keeping audit logs only inside the cluster they describe.