DevSecOps Practice Hub

Security Policies

Write policies and standards that are specific enough to be automated and verified.

BeginnerSecurity PoliciesGovernance

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Plan Threat modeling, requirements and security design decisions.

Overview

A useful policy states a testable requirement, names an owner, and points at the automated control that enforces it. Anything vaguer cannot be measured.

Why it matters

Policies written as aspirations produce audit findings but no behaviour change.

How it works

  1. 01Policy is stored in git and versioned with review.
  2. 02Each requirement links to its enforcing control and evidence.
  3. 03Exceptions follow a defined workflow with expiry.

Common tools

Open Policy AgentGitHubGitHubGitLab

Implementation examples

markdownTestable requirement
### CTRL-014 — Container images run as non-rootRequirement: all workloads in production namespaces must setrunAsNonRoot: true.Enforced by: Kyverno policy `require-run-as-nonroot` (Enforce).Evidence: weekly policy report export, retained 400 days.Owner: Platform Security. Exceptions: expire after 90 days.
Requirement, enforcement, evidence and owner in one place makes the policy auditable.

Best practices

  • Write requirements as testable statements.
  • Link every policy to its enforcing control.

Common mistakes

  • Policies that say 'where appropriate' and therefore mean nothing.