The DevSecOps Dictionary: 25 Terms Every Developer Should Know

DevSecOps is full of jargon. Every day, security engineers throw around terms like "SBOM," "Shift Left," "CVE," "Policy as Code," and "Admission Controller" — and if you're new to the field, it can feel like a foreign language. But understanding these 25 terms isn't just about sounding knowledgeable in meetings; it's about being able to read security reports, configure CI/CD pipelines, and protect your containerized applications from real-world threats. This DevSecOps Dictionary defines the 25 essential terms every developer must know in 2026, organized into five clear categories.

Group 1: DevSecOps Fundamentals (Terms 1–5)

These five terms form the philosophical and practical foundation of the entire DevSecOps movement. Master these first.

1. DevSecOps

DevSecOps(Development, Security, and Operations) is the practice of integrating security into every phase of the software development lifecycle — not as a final audit gate, but as an ongoing, automated process. Unlike traditional security models where a separate team reviews code just before release, DevSecOps makes developers responsible for security from the first commit. According to theOWASP DevSecOps Guideline, this shift reduces the cost of fixing vulnerabilities by up to 100x compared to fixing them in production.

2. Shift Left

Shift Leftmeans moving security testing and quality checks earlier in the development process — "to the left" of the traditional timeline. Instead of scanning for vulnerabilities after deployment, shift-left practices run security scans on every pull request, every commit, and every build. Tools likehadolint for Dockerfiles and trivy for container images are classic shift-left tools. A study by the CIS DevSecOps Benchmarksfound that teams practicing shift-left catch 73% more vulnerabilities before release.

3. Security as Code

Security as Code(SaC) is the practice of defining security policies, rules, and configurations in machine-readable files that are version-controlled, reviewed, and deployed like application code. Instead of manually configuring firewalls or writing ad-hoc security scripts, teams store security logic in YAML, HCL, or Rego files. This makes security reproducible, auditable, and testable. For example, a Kubernetes Network Policy stored in a Git repository can be reviewed in a pull request before it ever touches a cluster.

4. Policy as Code

Policy as Code(PaC) is a subset of Security as Code that focuses specifically on enforcing organizational policies — compliance rules, access controls, resource limits — through automated policy engines. Tools likeKubernetes Admission Controllers, OPA/Gatekeeper, and Kyverno enforce policies at admission time, blocking non-compliant deployments before they enter the cluster.

5. CI/CD Pipeline

CI/CD(Continuous Integration / Continuous Delivery) is the automated pipeline that builds, tests, and deploys code. From a security perspective, a CI/CD pipeline is where shift-left tooling runs: static analysis in the CI stage, container scanning before registry push, and compliance checks before production deployment. A well-hardened pipeline includessecurity gatesat each stage — automated blocks that stop the pipeline if a critical vulnerability is detected.

Group 2: Container Building Blocks (Terms 6–10)

These terms describe the fundamental infrastructure components of containerized environments.

6. Dockerfile

ADockerfileis a text file containing instructions for building a container image. It starts with aFROM statement specifying the base image, followed by commands like RUN, COPY, and CMD. Each instruction creates a new layer in the image. Security best practices for Dockerfiles — documented in the Docker Security Best Practices guide— include using minimal base images, avoiding theADD instruction for remote URLs, and never storing secrets in image layers.

7. Base Image

Abase imageis the starting point of a container image, specified by theFROM instruction. Choosing the right base image is the single most impactful security decision you'll make for your containers. Official images on Docker Hub (tagged with alpine, slim, or distroless) have significantly fewer CVEs than full OS images. For example, python:3.12-slim has roughly 80% fewer known vulnerabilities than python:3.12 (the full variant).

8. Multi-stage Build

Multi-stage buildsuse multipleFROM statements in a single Dockerfile to separate the build environment from the runtime environment. This technique dramatically reduces image size — and therefore attack surface. A typical Go application might compile in a golang:alpine stage and copy only the binary into a scratch runtime stage, resulting in an image under 20 MB. The Docker multi-stage build docsprovide several examples of this pattern.

9. Container Runtime

Thecontainer runtimeis the software that actually runs containers on a host. Popular runtimes includecontainerd, runc, and cri-o. The runtime enforces kernel-level isolation through features like namespaces and cgroups. Advanced runtime security tools — such as AppArmor, Seccomp, and Drop Capabilities — restrict what a container process can do at the OS level, preventing privilege escalation even if an application is compromised.

10. Container Registry

Acontainer registrystores and distributes container images. Docker Hub, GitHub Container Registry (GHCR), AWS ECR, and Google Artifact Registry are common examples. From a security perspective, registries should enforce image signing, scan images for vulnerabilities on push, and prevent pulling images with known critical CVEs. They are a critical control point in the software supply chain.

Group 3: Image & Supply Chain Security (Terms 11–15)

These five terms cover how container images are identified, documented, and verified — the core of supply chain security.

11. Image Tag

Animage tagis a human-readable label applied to a specific version of a container image (e.g.,nginx:1.25.3, alpine:3.20). Tags are mutable — they can be re-assigned to different image digests, which is why relying on the latest tag in production is dangerous. Always pin images to their digest(SHA256 hash) for immutable deployments:nginx@sha256:abc123....

12. SBOM (Software Bill of Materials)

AnSBOMis a formal, machine-readable inventory of all components, libraries, and dependencies in a piece of software. In container security, an SBOM lists every package installed in an image — including OS-level packages (libssl, curl), language dependencies (pip, npm), and their version numbers. The CISA SBOM initiativepromotes SBOM adoption as a critical defense against supply chain attacks. Tools likesyft and docker scout generate SBOMs from container images in seconds.

13. Software Supply Chain

Thesoftware supply chainencompasses everything involved in creating and delivering software: source code repositories, CI/CD pipelines, third-party dependencies, registries, and deployment infrastructure. Attacks on the software supply chain — like the 2024 xz utils backdoor — exploit trust relationships between these components. Securing the supply chain means verifying the integrity and provenance of every component from source to deployment through image signing, SBOM verification, and policy enforcement.

14. Image Signing

Image signingis the cryptographic process of digitally signing a container image to verify its authenticity and integrity. When you sign an image, you create a digital signature that proves the image was produced by a trusted identity and has not been tampered with since signing.Sigstore, the industry-standard signing framework, makes this process accessible to everyone through keyless signing using OIDC identities.

15. Cosign (Sigstore Tool)

Cosignis the CLI tool from the Sigstore project for signing and verifying container images. A single command —cosign sign — generates a signature stored alongside the image in the registry. Verification happens at deploy time: cosign verify checks the signature against the signer's identity before allowing the image into production. Cosign supports keyless modes that use GitHub/GitLab OIDC tokens, eliminating the need to manage long-lived signing keys.

Group 4: Vulnerability & Risk Management (Terms 16–20)

These terms describe how security issues are identified, scored, and managed within the DevSecOps pipeline.

16. CVE (Common Vulnerabilities and Exposures)

ACVEis a unique identifier for a publicly disclosed cybersecurity vulnerability. Each CVE has the formatCVE-YYYY-NNNNN and is registered in the NVD (National Vulnerability Database). When a container scan reports "5 CVEs found," it means five known vulnerabilities were identified in the image's packages. Understanding CVEs is fundamental to triaging what needs to be fixed urgently versus what can wait until the next release cycle.

17. CVSS (Common Vulnerability Scoring System)

CVSSis the standard scoring system that rates the severity of CVEs on a scale from 0 to 10. A CVSS score of 9.0–10.0 isCritical, 7.0–8.9 isHigh, 4.0–6.9 isMedium, and 0.1–3.9 isLow. TheNVD CVSS calculatorconsiders exploitation complexity, attack vector, privileges required, and impact on confidentiality, integrity, and availability. However, CVSS alone shouldn't determine prioritization — context (is the vulnerable package actually used at runtime?) matters more than the raw score.

18. Vulnerability Scanning

Vulnerability scanningis the automated process of comparing the packages in a container image against a database of known CVEs. Scanners liketrivy, grype, and docker scout analyze each layer of an image, identify installed packages and their versions, and cross-reference them against CVE databases. Scans can run at multiple points: on every commit (shift-left), on every push to a registry, and on a recurring schedule for already-deployed images.

19. Security Gate

Asecurity gateis an automated checkpoint in a CI/CD pipeline that evaluates security criteria and either passes or blocks the build. For example, a security gate might block an image from being pushed to production if it contains any Critical or High CVSS vulnerabilities. Security gates are the enforcement mechanism of your shift-left strategy — without them, security scans produce reports that nobody reads. Platforms likeShieldOpsimplement security gates that integrate directly with GitHub and GitLab pipelines.

20. Artifact Repository

Anartifact repository(or artifact store) is a centralized system for storing, versioning, and distributing build outputs — container images, JAR files, npm packages, Python wheels, and more. JFrog Artifactory, Sonatype Nexus, and GitHub Packages are common examples. From a DevSecOps perspective, artifact repositories are the enforcement boundary: they should scan every uploaded artifact for vulnerabilities, block malicious uploads, and provide an immutable audit trail of every component version.

Group 5: Compliance & Production Security (Terms 21–25)

These five terms cover the standards, architectures, and tools that protect container workloads in production.

21. CIS Benchmark

ACIS Benchmarkis a set of configuration guidelines published by the Center for Internet Security (CIS Benchmarks) for hardening systems against attacks. There are CIS Benchmarks for Docker, Kubernetes, Linux, and hundreds of other technologies. For example, the Docker CIS Benchmark includes recommendations like "Ensure thedocker.sock file permissions are set to 660 or more restrictive" and "Ensure containers are restricted from acquiring new privileges." Compliance teams often require CIS Benchmark adherence for SOC 2, PCI-DSS, and ISO 27001 certifications.

22. Immutable Infrastructure

Immutable infrastructureis the principle that infrastructure components — servers, containers, VMs — are never modified after deployment. Instead of SSH-ing into a running container to fix a configuration issue, you build a new image with the fix and redeploy. This eliminates configuration drift, ensures reproducible deployments, and simplifies rollbacks. Kubernetes embraces immutability: Pods are disposable, and changes go through the image build and deploy pipeline, never through manual fixes on live containers.

23. Admission Controller

Anadmission controlleris a Kubernetes component that intercepts requests to the API server before objects are persisted, allowing you to enforce policies on what can run in your cluster.Kubernetes Admission Controllerscan validate (reject non-compliant deployments) or mutate (inject sidecars, add labels). OPA/Gatekeeper and Kyverno are popular admission controller frameworks that let you write policies as code. For example, you can create a policy that rejects any Pod running as root or any container with thelatest image tag.

24. Runtime Security

Runtime securityrefers to the tools and practices that detect and respond to threats in running containers. While shift-left scanning catches vulnerabilities before deployment, runtime security monitors what containers actually do in production — unexpected system calls, network connections to unknown IPs, file system writes to sensitive paths.Falco, the CNCF-graduated runtime security project, uses custom rules to detect anomalous behavior and triggers alerts when a container behaves outside its expected profile.

25. Immutable Artifact

Animmutable artifactis a build output that cannot be modified after creation. In container security, an image digest (SHA256 hash) is the ultimate immutable reference — it uniquely and permanently identifies the exact content of an image. Immutable artifacts are a cornerstone of supply chain security: if every deployment uses an immutable digest rather than a mutable tag, attackers cannot swap a compromised image into the tag your pipeline trusts. Most production-grade registries enforce immutability by preventing tag overwrites.

How These Terms Connect: A Practical Map

Understanding individual terms is only half the battle. Here's how they fit together in a real DevSecOps pipeline:

1. Developer commits code→ triggers theCI/CD Pipeline(Term 5)
2. Pipeline builds imageusing aDockerfile(Term 6) with a minimalBase Image(Term 7) andMulti-stage Build(Term 8)
3. Vulnerability Scanning(Term 18) runs on the image — if aCVE(Term 16) with a highCVSS(Term 17) score is found, theSecurity Gate(Term 19) blocks the build
4. SBOM(Term 12) is generated and attached to the image
5. Image Signing(Term 14) withCosign(Term 15) cryptographically signs the image
6. Imageis pushed to aContainer Registry(Term 10) with anImmutable Artifact(Term 25) digest
7. Kubernetes Admission Controller(Term 23) verifies the signature and checksCIS Benchmark(Term 21) compliance before allowing the Pod to run
8. Runtime Security(Term 24) monitors containers in production, enforcingImmutable Infrastructure(Term 22) principles

This end-to-end workflow embodiesDevSecOps(Term 1),Shift Left(Term 2),Security as Code(Term 3), andPolicy as Code(Term 4) — all at once.

Next Steps for Your DevSecOps Journey

Knowing these 25 terms is the first step. Here's how to put them into practice:

• Run your first vulnerability scan— installtrivy and scan a local image: trivy image nginx:latest
• Review your Dockerfiles— runhadolint against your project's Dockerfiles to catch security issues early
• Generate an SBOM— usesyft nginx:latest -o spdx-json to see every component in an image
• Set up a security gate— configureShieldOpsin your CI/CD pipeline to block builds that exceed your vulnerability threshold
• Read related guides— check out our posts onContainer Security for BeginnersandVulnerability Management Lifecycle

Frequently Asked Questions

Do I need to master all 25 terms before starting with DevSecOps?

No. Start with terms 1–5 (fundamentals) and 16–18 (vulnerability management). Learn the rest as you encounter them in your CI/CD pipeline or security reports. Most teams gradually adopt more advanced practices like image signing and admission controllers over several months.

What's the difference between a CVE and a CVSS?

ACVEidentifies a specific vulnerability (like an ID number for a security bug).CVSSscores that vulnerability's severity (how dangerous it is). Think of CVE as "what" and CVSS as "how bad." One CVE can have multiple CVSS scores over time as researchers discover more about the exploit.

Is Docker still the standard for containers in 2026?

Yes, Docker remains the most widely used container runtime and image format. However, many production environments usecontainerddirectly (Docker's runtime extracted into a standalone component), and Kubernetes has deprecated Docker as a runtime in favor of CRI-compatible runtimes. Dockerfiles and Docker images remain the universal standard across all runtimes.

What should I prioritize: vulnerability scanning or admission controllers?

Start withvulnerability scanning. You need to know what vulnerabilities exist in your images before you can enforce policies about them. Admission controllers add value after scanning is mature — they enforce the rules based on scan results (e.g., "block any image with critical CVEs").

How often should I regenerate SBOMs for my containers?

Every build.SBOMs should be generated automatically as part of your CI/CD pipeline on every commit. Since dependencies change frequently (often daily with security patches), a stale SBOM is almost as dangerous as no SBOM. Automate it with a tool likesyft running in a pipeline step.

What's the easiest way to start with image signing?

UseSigstore's keyless signingwith Cosign. If your CI/CD runs on GitHub Actions or GitLab CI, Cosign can automatically use your workflow's OIDC identity to sign images without managing any keys. Runcosign sign --keyless your-image:tag and you're signing in seconds.

Conclusion

Mastering DevSecOps starts with mastering its language. These 25 terms represent the core vocabulary of modern container security — from the philosophical foundation of Shift Left and Policy as Code, through the technical infrastructure of Dockerfiles and Container Registries, to the advanced practices of Image Signing and Admission Controllers.

The best way to learn is by doing. Start your first vulnerability scan today, generate an SBOM for one of your projects, or set up a security gate in your CI/CD pipeline.Create your free ShieldOps accountto get automated vulnerability scanning, SBOM generation, and policy enforcement working in minutes — not weeks.