DevSecOps Glossary¶
Quick Reference
Specialized terminology for security teams and DevSecOps practitioners. Each term includes practical context and links to relevant documentation.
Supply Chain Security¶
SLSA (Supply chain Levels for Software Artifacts)¶
A security framework with four levels for supply chain integrity.
SLSA proves build integrity using cryptographic attestation. It identifies the source and build process. It verifies build isolation. SLSA prevents supply chain attacks like SolarWinds.
Related: SLSA Playbook | SLSA Levels | SLSA vs SBOM
Provenance¶
Cryptographic proof of how an artifact was built.
Provenance records the source commit and build details. Digital signatures prevent tampering. This verifies artifacts match their source. Required for SLSA Level 2+.
Related: SLSA Provenance | Verification Workflows
Attestation¶
A signed statement about software artifacts.
Attestations make verifiable claims using cryptographic signatures. They cover builds, tests, or scans. Multiple attestations can be combined.
Related: SLSA Provenance | Policy Templates
SBOM (Software Bill of Materials)¶
A complete list of all software components. It includes all libraries and dependencies. Enables vulnerability tracking. Enables license compliance. Different from SLSA provenance.
Related: SBOM Generation | SLSA vs SBOM
Sigstore¶
An open-source project for signing software.
Sigstore provides free code signing. It uses short-lived certificates. It maintains transparency logs. No key management needed. Used by OpenSSF and GitHub Actions.
Related: SLSA Provenance | Container Release
Cosign¶
A tool for signing container images.
Cosign is part of Sigstore. It signs images. It stores signatures in OCI registries. It integrates with admission controllers.
Related: Image Signing | Image Verification
Policy & Compliance¶
Policy-as-Code¶
Security and compliance policies expressed as executable code.
Policies can be version controlled and tested. They are automatically enforced. Code policies block violations. Implemented using OPA, Kyverno, and Gatekeeper.
Related: Policy-as-Code Overview | Policy Templates
OPA (Open Policy Agent)¶
A policy engine that uses Rego language for rules.
OPA evaluates policies across cloud-native stacks. It works with Kubernetes through Gatekeeper. Policies are decoupled from code. Used for authorization and compliance.
Related: OPA Templates | OPA vs Kyverno
Kyverno¶
A Kubernetes-native policy engine using YAML.
Kyverno validates and mutates resources. No new language to learn. Works at local dev, CI, and runtime. Enforces policies at all three layers.
Related: Kyverno Basics | Kyverno Templates | CI/CD Integration
Gatekeeper¶
OPA integration for Kubernetes.
Gatekeeper uses Rego policies. It deploys as a webhook. Templates define reusable policies.
Related: OPA Templates | Migration Guide
Admission Controllers¶
Kubernetes components that intercept API requests.
They run before persistence. They validate or mutate resources. Kyverno and Gatekeeper are admission controllers. Critical for security.
Related: Policy-as-Code | Runtime Deployment
Scorecard¶
OpenSSF tool that measures security practices.
Scorecard evaluates 18 checks. Each scores 0 to 10. Checks cover branch protection and code review. High scores are a byproduct of good security.
Related: Scorecard Guide | Score Progression | CI Integration
Architecture Patterns¶
Hub-and-Spoke¶
A centralized distribution pattern.
The hub controls many spoke repositories. Provides centralized control. Common for organization-wide policies.
Related: GitHub Actions Integration
Three-Stage Design¶
A workflow with three phases: Discovery, Distribution, and Summary.
Makes errors visible. Each phase has clear success criteria. Each phase can roll back.
Related: GitHub Actions Integration | Three-Stage Design
Strangler Fig¶
Incremental migration for replacing legacy systems.
Run old and new systems in parallel. Gradually shift traffic. Zero downtime. Rollback at any point.
Related: Strangler Fig Overview | Traffic Routing | Migration Guide
Separation of Concerns¶
Single-responsibility components with clear boundaries.
Every component does one thing well. Orchestration separated from business logic. Maintainability at scale.
Related: Separation of Concerns | Implementation | Go CLI Architecture
Matrix Distribution¶
Run operations in parallel across targets.
Matrix strategies enable parallel processing. Discovery builds the target list. Distribution spawns parallel jobs.
Related: Matrix Distribution | Conditional Distribution
Environment Progression¶
Progressive deployment across environments.
Deploy to dev, then staging, then production. Test with realistic load. Validate migrations. Automate rollback.
Related: Environment Progression | Operations | Testing Blog
Efficiency Patterns¶
Idempotency¶
An operation that always gives the same result.
Run it once or a thousand times. The result is identical. Makes retries safe. Critical for automation.
Related: Idempotency Overview | Idempotent Automation | Decision Matrix
Work Avoidance¶
Patterns for skipping unnecessary work.
These reduce runtime and costs. Complements idempotency. Uses change detection and caching.
Related: Work Avoidance Overview | 5 Seconds to 5 Milliseconds | Techniques
Check-Before-Act¶
Check state before creating it.
The most common pattern. Check if state exists. Skip if yes. Act if no. Watch for race conditions.
Related: Check-Before-Act Pattern | Idempotency Patterns
Tombstone Markers¶
Leave markers when operations complete.
Create a marker file when done. On rerun, check for marker. Skip if present. Universal fallback.
Related: Tombstone Markers | CI/CD Examples
Content Hashing¶
Use hashes to detect changes.
Compute hash of content. Compare hashes. If hashes match, content is identical. Skip processing.
Related: Content Hashing | Cache-Based Skip
Caching¶
Store results for reuse.
Save results for later use. Cache invalidation is hard. Design for cache hits. Survive cache misses.
Related: Cache Considerations | Cache-Based Skip
CI/CD & Automation¶
GitHub Actions¶
GitHub CI/CD platform for workflows.
Workflows run on events. Jobs run in parallel. Steps execute commands.
Related: GitHub Actions Integration | File Distribution | Work Avoidance
GitHub Apps¶
Organization apps for authentication.
Apps provide machine identity. All actions auditable. Higher rate limits. Critical for cross-repo operations.
Related: GitHub Core App | Token Generation | Token Lifecycle
Argo Workflows¶
Kubernetes workflow engine.
Define workflows in YAML. Run steps in containers. Handle retries and errors. Compose from templates.
Related: Argo Workflows Patterns | WorkflowTemplate Patterns | Workflow Composition
Argo Events¶
Event-driven workflows for Kubernetes.
Connect systems to reactive workflows. EventSources capture events. Sensors trigger actions. No polling needed.
Related: Argo Events Overview | Event Routing | Reliability Patterns
Release-Please¶
Automated versioning from commits.
Reads commit history. Generates changelogs. Creates release PRs. Tags releases. No manual version management.
Related: Release-Please Configuration | Workflow Integration
Pre-commit Hooks¶
Git hooks before commits.
Block bad code from history. Check for secrets and violations. Faster feedback than CI.
Related: Pre-commit Hooks | Pre-commit Patterns
Reusable Workflows¶
Parameterized workflows called by others.
Define once. Call from many repos. Centralize logic. Reduce duplication.
Related: GitHub Actions Integration | File Distribution
Conventional Commits¶
Structured commit messages for automation.
Format: type(scope): description. Enables changelog and version bumps. Required for Release-Please.
Related: Release-Please Configuration | Versioned Docs
WorkflowTemplate¶
Reusable Argo Workflow in Kubernetes.
Define once. Reference from many workflows. Parameterize. Compose pipelines.
Related: WorkflowTemplate Patterns | Workflow Composition
Security & Hardening¶
Zero Trust¶
No implicit trust.
Every request needs verification. Network location does not matter. Verify at every layer.
Related: Secure-by-Design
Defense in Depth¶
Multiple security layers.
Each layer adds protection. Layers work independently. One breach cannot destroy everything.
Related: Defense in Depth
Least Privilege¶
Minimum permissions needed.
Give only what is needed. Limits damage from breaches. Required for security.
Related: Least Privilege
Fail Secure¶
Failures default to safe states.
When controls fail, deny access. Prevents bypass. Kubernetes uses failurePolicy: Fail.
Related: Fail Secure | Integration
Branch Protection¶
GitHub rules enforcing security on branches.
Requires code review. Blocks force pushes. Requires status checks. Drift is common. Automated enforcement fixes drift.
Related: Branch Protection | Security Tiers | Drift Detection
Commit Signing¶
Cryptographic proof of authorship.
Git author fields are trivial to forge. GPG signatures prove authorship. Required for audits.
Related: Commit Signing | Implementation Roadmap
Workload Identity¶
Cloud auth without static keys.
Containers use JWT tokens instead of keys. Tokens rotate automatically. Eliminates largest attack surface.
Related: Workload Identity | Migration Guide
GKE Hardening¶
Security for Google Kubernetes Engine.
Private clusters. Workload Identity. Binary Authorization. Infrastructure as Code.
Related: GKE Hardening | Cluster Configuration | Network Security
Missing a Term?
If you find terminology not defined here, please open an issue.
Related: Roadmap | Patterns | Blog