📘 Glossary++
Intro: This glossary is intentionally practical. It is written for readers who need to survive real reviews, incidents, and planning conversations, not for people collecting definitions in the abstract.
What this page includes
- the term;
- a plain-English explanation;
- where the term usually appears in day-to-day work;
- common confusion;
- related terms that should be learned next.
| Term | Plain-English explanation | Where it appears in real work | Common confusion | Related terms |
|---|---|---|---|---|
| Admission controller | A control point in the Kubernetes API path that can validate or mutate objects before they are stored. | Appears in Kubernetes security review, policy enforcement, and secure platform guardrails. | People often confuse the controller with a single product; it is a control point that can be implemented by several engines or built-in plugins. | Pod Security Admission; Kyverno; Gatekeeper |
| AppArmor | A Linux security module that constrains what a process can access through named profiles. | Used in container hardening and node-level workload isolation discussions. | It is not identical to SELinux; both are isolation mechanisms with different policy models. | SELinux; seccomp; securityContext |
| AppSec | The part of security work focused on reducing software and product risk before and after release. | Appears in code review, threat modeling, triage, and release decisions. | People sometimes use it as a synonym for scanners only. It is broader than tooling. | Product Security; secure SDLC; ASVS |
| Artifact signing | Attaching a cryptographic signature to a build artifact so verifiers can check origin and integrity. | Used in supply-chain controls, registries, and deployment policy enforcement. | Signing does not by itself prove the build was trustworthy; provenance and build isolation still matter. | Cosign; provenance; attestation |
| ASVS | OWASP Application Security Verification Standard; a practical catalog of security requirements and review targets for applications. | Used to build review checklists, security requirements, and maturity baselines. | It is not a law and not a drop-in release policy by itself. | OWASP; verification; checklist |
| Attack path | A realistic sequence of weaknesses or assumptions that an attacker can chain together. | Shows up in triage, architecture review, and incident response discussions. | People often confuse a single weakness with a full attack path. | exploit chain; blast radius |
| Attestation | A signed statement about some property of an artifact or workload, such as how it was built or what it contains. | Used in CI/CD evidence packs, SLSA-style pipelines, and admission policies. | A signature over an artifact and an attestation about an artifact are related but not the same thing. | provenance; signing; SBOM |
| Blast radius | How much of the system, data, or customer base can be affected if something goes wrong. | Used in change review, incident response, and architecture trade-offs. | It is not only about production outage; data and authority count too. | segmentation; rollback; containment |
| BOLA | Broken Object Level Authorization; a user can access an object they should not own or see. | Common in API review and customer-data route review. | People sometimes think route auth alone prevents BOLA. It does not. | API1:2023; object authorization |
| Break-glass access | Emergency access path used when standard access is unavailable or too slow. | Appears in IAM review, incident response, and platform operations. | It should be rare, logged, and reviewed, not a normal admin shortcut. | JIT access; privileged access |
| Canary release | A limited rollout to a small subset of traffic or users to reduce blast radius. | Used in release review and production readiness discussions. | It is not automatically safe if telemetry and rollback are weak. | feature flag; staged rollout |
| CodeQL | A semantic code analysis platform built around code databases and queries. | Used in code scanning, deep variant analysis, and custom secure-coding queries. | Teams often compare it directly to lint-style SAST only; it is closer to a query engine over program structure and data flow. | Semgrep; SAST; code scanning |
| Compensating control | A control that reduces risk when the preferred primary control is missing or delayed. | Used in exception handling and risk acceptance. | It should meaningfully reduce risk, not just sound reassuring. | residual risk; exception |
| Control plane | The administrative or orchestration layer that creates, configures, or governs workloads. | Used in cloud, Kubernetes, and CI/CD security reviews. | People sometimes focus only on data paths and ignore who can reconfigure the system. | management plane; admin plane |
| Cosign | A Sigstore tool used to sign and verify containers and other OCI artifacts. | Used in modern supply-chain guidance for image signing and provenance verification. | It is not identical to the older Docker Content Trust workflow, even if both solve related trust problems. | signing; provenance; Sigstore |
| CVSS | A scoring system for technical vulnerability severity. | Appears in vuln reports and scanner outputs. | CVSS is not the same thing as business priority. | severity; prioritization |
| DAM | Database Activity Monitoring; controls and platforms that observe and record database actions, especially high-risk and privileged activity. | Used in regulated database environments, audit preparation, and privileged-user oversight. | DAM is broader than native DB audit logging alone because it often adds policying, analytics, and independent evidence retention. | audit log; immutable logging; privileged session management |
| DAST | Dynamic Application Security Testing against a running application. | Appears in web/API testing and release gates. | A clean DAST run does not prove the application is secure. | SAST; scanner; release gate |
| Defense in depth | Using more than one layer of control so that one failure is not catastrophic. | Shows up in architecture reviews and hardening strategy. | It is not an excuse for weak primary controls. | preventive control; detective control |
| Dependabot | GitHub-native automation for dependency update pull requests and security advisories. | Appears in repo hygiene, patching cadence, and compatibility-testing discussions. | Fast update generation does not remove the need for controlled rollout and test quality. | Renovate; dependency updates; compatibility testing |
| Docker Content Trust | An older Docker image-signing approach based on Notary v1. | Shows up in older books, older pipelines, and legacy registry workflows. | It is increasingly treated as legacy guidance for new designs. | Notation; Cosign; signing |
| DREAD | A historical threat-rating model that scores Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. | Useful mainly as a legacy reference in SDL and threat-modeling conversations. | It is not the same as STRIDE: DREAD is about scoring, while STRIDE is about threat categories. | STRIDE; threat ranking; risk scoring |
| Drift | A change from the expected or approved state over time. | Used in cloud config review, access review, and platform operations. | People often notice drift only after an incident. | posture; configuration management |
| Envelope encryption | A pattern where data is encrypted with a short-lived data key and that data key is then encrypted with a longer-lived key-encryption key. | Used in KMS-backed application encryption, storage systems, and secrets workflows. | Teams sometimes think envelope encryption means a single master key encrypts all data directly. | KMS; key hierarchy; data key |
| Falco | A runtime detection engine for containers, Kubernetes, and Linux workloads that raises alerts from syscall and other runtime signals. | Used in Kubernetes and runtime-detection labs, clusters, and security operations. | Falco is a detector and alerting source, not a full incident-response platform by itself. | runtime signal; Falcosidekick; detection |
| Falcosidekick | A companion router that forwards Falco alerts to systems such as Slack, Teams, webhooks, SIEMs, and ticketing tools. | Used when teams want Falco detections to land in the places they already triage. | It forwards and reshapes alerts; it does not replace rule logic or investigation. | Falco; alert routing |
| Feature flag | A control that can enable, disable, or scope behavior without a full redeploy. | Used in release safety and blast-radius reduction. | A feature flag is not a substitute for authorization. | rollout; kill switch |
| Federation | Trusting an external identity provider or token issuer instead of using static local credentials. | Used in cloud trust, CI/CD, and workload identity design. | People sometimes call any token exchange federation; the trust relationship matters. | OIDC; workload identity; STS |
| Finding | A scanner result, review issue, or security observation that may need action. | Used in triage, backlog management, and governance reporting. | A finding is not automatically a bug, exploit, or top priority. | vulnerability; triage |
| GitOps | An operating model where desired state is stored in version control and reconciled into the environment by automation. | Used in Kubernetes delivery, change control, and deployment-plane governance. | GitOps does not make deployments safe by itself; repo trust, admission controls, and runtime rollback still matter. | Argo CD; Flux; reconciliation |
| GraphQL | An API query language and runtime that allows clients to request exactly the fields they need. | Appears in API design, resolver authorization, complexity limits, and introspection review. | People often overfocus on auth at the endpoint and underfocus on resolver-level authorization and query cost. | resolver auth; depth limits; complexity analysis |
| gRPC | A high-performance RPC framework that commonly uses Protocol Buffers over HTTP/2 and supports unary and streaming calls. | Used in microservice architecture, service-to-service auth, and streaming security design. | gRPC transport security does not automatically solve per-method authorization or unsafe streaming behavior. | mTLS; deadlines; streaming security |
| Hardening | Reducing avoidable attack surface and risky defaults in a system or workload. | Shows up in Docker, Kubernetes, cloud, and OS baselines. | Hardening helps, but it does not replace authorization or design review. | baseline; secure configuration |
| HSM | Hardware Security Module; a device or managed service designed to protect key material and perform sensitive cryptographic operations. | Used in high-assurance key management, signing, and regulated encryption designs. | Not every KMS is an HSM service, even if it may rely on HSM-backed protection behind the scenes. | KMS; root of trust; key hierarchy |
| Identity | The actor, user, service account, workload, or automation principal performing an action. | Used everywhere: auth design, IAM review, incidents, logging. | Teams sometimes talk about services without naming the identity that acts. | principal; authentication; authorization |
| Immutable logging | A logging pattern where stored records cannot be silently modified or deleted within the retention window. | Used in investigations, audit evidence, and privileged-user oversight. | Centralized logging is not automatically immutable logging unless retention and deletion protections are enforced. | Object Lock; WORM; evidence retention |
| Istio | A service mesh platform that provides traffic policy, identity, and mTLS controls for Kubernetes and related environments. | Used in zero-trust networking, workload identity, and mesh certificate operations. | Installing Istio does not automatically produce a mature identity program; CA hierarchy, policies, and exceptions still require ownership. | Linkerd; service mesh; mTLS |
| JIT access | Just-in-time privileged access granted for a limited window instead of permanently. | Used in admin access and operations review. | Short-lived access is useful only if approvals and logs are real. | break-glass; privileged access |
| Kill switch | A control that can quickly disable a risky feature, integration, or workflow. | Used in release planning and incident containment. | It must be tested; theoretical kill switches do not help under pressure. | feature flag; rollback |
| KMS | Key Management Service; a service used to create, protect, and use cryptographic keys through policy-controlled APIs. | Used in application encryption, secrets workflows, storage encryption, and signing. | KMS usage does not eliminate application design choices such as key hierarchy or authorization boundaries. | HSM; envelope encryption; key hierarchy |
| Kyverno | A Kubernetes-native policy engine that uses YAML-style policies to validate, mutate, generate, and verify resources. | Used in admission policy, image verification, and cluster hardening. | It is not the only admission strategy and is not interchangeable with all Rego-based tooling. | admission controller; Gatekeeper; policy as code |
| Least privilege | Giving identities only the minimum authority required for the task. | Used in IAM, Kubernetes service account, and CI/CD design. | People often think scope only in actions, not also in resources, time, and environment. | IAM; scope; trust policy |
| Linkerd | A lightweight service mesh focused on secure service-to-service communication, reliability, and operational simplicity. | Used in Kubernetes networking, mTLS, and traffic policy designs. | Automatic workload cert rotation does not remove the need to manage trust anchors and issuer lifecycle. | Istio; service mesh; identity |
| Logging | Recording events that matter for operations, investigations, and detections. | Used in incidents, detections, audits, and production readiness. | Verbose logs are not always useful if high-value events are missing. | telemetry; audit logs |
| mTLS | Mutual TLS; both sides of a connection authenticate with certificates instead of only the server doing so. | Used in microservice identity, zero-trust networking, and service mesh controls. | mTLS authenticates peers on the connection but does not by itself decide business authorization. | service identity; SPIFFE; certificates |
| Multi-tenant | A product model where multiple customers share some infrastructure or application layers. | Used in SaaS design, isolation review, and architecture patterns. | Shared infrastructure is not automatically unsafe, but isolation must be explicit. | tenant isolation; admin plane |
| Object Lock | A retention and legal-hold feature that can make stored objects undeletable or unmodifiable for a defined period. | Used in backup immutability, evidence retention, and ransomware resilience design. | Versioning helps, but it is not the same thing as an enforced retention lock. | immutable logging; backup immutability; WORM |
| OIDC | OpenID Connect; a standard identity layer often used for federation and token-based trust. | Used in CI/CD-to-cloud trust, app auth, and SSO. | OIDC itself is not the same thing as authorization or safe token handling. | federation; identity provider |
| PAM | Privileged Access Management; controls and platforms that govern, broker, record, and review high-risk administrative access. | Used in production operations, platform administration, and break-glass oversight. | PAM is not just a password vault; mature PAM includes session control, approvals, and evidence. | JIT access; privileged session management; break-glass access |
| PASTA | Process for Attack Simulation and Threat Analysis; a risk-centric threat-modeling method that walks from business objectives to attacks and defenses. | Used when teams want a more scenario-driven and risk-oriented model than basic STRIDE-only workshops. | PASTA is not a quick shortcut; it is heavier and best used for critical systems or material change. | STRIDE; attack path; risk analysis |
| Pod Security Admission | The built-in Kubernetes admission mechanism that enforces pod-security profiles at the namespace level. | Used in baseline Kubernetes hardening and policy rollout. | It is focused on pod-level policy and is not a full replacement for broader admission and governance needs. | Pod Security Standards; admission controller; restricted profile |
| Pod Security Standards | The Kubernetes-defined policy levels Privileged, Baseline, and Restricted for pod security posture. | Used in cluster hardening, namespace labeling, and workload exceptions. | They are policy definitions; enforcement happens through Pod Security Admission or other policy tooling. | Pod Security Admission; securityContext; restricted |
| Policy as code | Encoding security or platform rules in code so they can be reviewed and enforced automatically. | Used in Kubernetes admission, CI/CD, and cloud governance. | It can reduce variance, but bad policies still create friction without reducing risk. | OPA; Kyverno; guardrails |
| Provenance | A verifiable record of where, when, and how an artifact was produced. | Used in secure build factories, artifact promotion, and supply-chain audit evidence. | A checksum alone is not provenance because it says nothing about build process and authority. | SLSA; attestation; artifact signing |
| Prowler | A cloud security assessment tool focused on provider configuration checks and evidence gathering. | Used in cloud review, posture assessment, and compliance-style scan-to-triage workflows. | It is useful for breadth, but findings still need prioritization and codification. | posture; cloud audit; evidence |
| RASI | A responsibility model that marks who is Responsible, Approving/Accountable, Supporting, and Informed for an activity. | Used in program governance, workflow design, and staffing models. | Teams often mix RACI and RASI language; choose one model and define it clearly. | RACI; ownership; segregation of duties |
| Renovate | A dependency automation tool with flexible grouping, scheduling, and policy controls for update pull requests. | Used in dependency hygiene, controlled rollout, and maintenance automation. | High configurability is powerful, but poorly tuned rules can create noise or unsafe batching. | Dependabot; cadence; controlled rollout |
| Residual risk | The risk that remains after controls, fixes, or compensating measures are applied. | Used in exception records and leadership communication. | Residual risk should be named clearly, not hidden inside vague language. | risk acceptance; compensating control |
| Rollback | The practical way to return to a safer previous state after a bad change or deployment. | Used in release and incident planning. | Rollback is not always trivial if state or schema changed. | kill switch; recovery |
| Runtime signal | An event seen while the workload is actually running, such as a suspicious exec or denied system call. | Used in container and Kubernetes response work. | Runtime alerts are useful only if triage and context are good enough. | Falco; Tetragon; detection |
| RuntimeClass | A Kubernetes resource that selects a container runtime configuration for a pod, such as a sandboxed runtime. | Used in workload isolation and platform hardening. | It is not a general security policy object; it maps pods to runtime behavior. | gVisor; sandboxing; pod isolation |
| SBOM | Software Bill of Materials; an inventory of components in software or an image. | Used in supply chain review and vulnerability management. | An SBOM helps visibility but does not prove component safety or reachability. | dependency inventory; provenance |
| Scope | The boundaries of what a control, permission, review, or exception actually covers. | Appears in IAM review, release review, and risk communication. | People often use broad words like 'covered' without defining the scope. | blast radius; least privilege |
| ScoutSuite | A modern multi-cloud posture-audit tool and the practical successor to older Scout2-style guidance. | Used in cloud auditing and baseline review. | Older material often says Scout2; modern teams usually mean ScoutSuite. | cloud audit; posture |
| Seccomp | Secure computing mode for Linux; a filter that restricts which syscalls a process may use. | Used in container isolation, runtime hardening, and least-privilege execution. | Seccomp is not a full sandbox by itself; it reduces syscall surface but does not replace broader isolation. | AppArmor; SELinux; capabilities |
| Secret | A piece of confidential material such as a token, key, password, or credential that grants access or trust. | Used in CI/CD, service config, and incident response. | Not all sensitive data is a secret, and not all secrets should be long-lived. | credential; secret manager |
| SELinux | A Linux mandatory access control system that labels resources and constrains what processes can do with them. | Used in node and container hardening, especially on enterprise Linux platforms. | SELinux is powerful but often misunderstood as only an OS concern instead of a workload-isolation control too. | AppArmor; seccomp; labels |
| Semgrep | A fast code-analysis engine that matches structural patterns and supports custom rules across many languages. | Used in secure-coding checks, custom policy rules, and lightweight code scanning. | It is excellent for fast pattern-based and taint-style rules, but it is not the same style of engine as CodeQL. | CodeQL; custom rules; SAST |
| Service identity | The machine- or workload-level identity used by a service when it calls another system. | Used in microservice auth, zero-trust networking, and secrets reduction patterns. | Teams sometimes mix service identity with application role or business authorization. | mTLS; workload identity; SPIFFE |
| Service mesh | An infrastructure layer that manages service-to-service communication, identity, policy, and telemetry. | Used in Kubernetes networking, mTLS, and traffic governance. | A mesh can reduce some authn and traffic-management burden but can also add control-plane and certificate complexity. | Istio; Linkerd; mTLS |
| SLO | Service Level Objective; the expected target for a service behavior such as latency or availability. | Used in production readiness and reliability discussions. | Security changes can affect SLOs, so trade-offs should be explicit. | SLA; reliability |
| SLSA | Supply-chain Levels for Software Artifacts; a framework for assessing build and provenance maturity. | Used in build-factory design, provenance roadmaps, and release evidence. | SLSA is a maturity and assurance framework, not just a signing feature. | provenance; attestations; build integrity |
| SPIFFE | A framework for standardized workload identities, commonly represented as SPIFFE IDs and X.509 or JWT documents. | Used in service identity and mTLS architectures across platforms. | SPIFFE defines identity format and trust model; it is not the same thing as the control plane that issues identities. | SPIRE; workload identity; mTLS |
| SPIRE | An implementation of SPIFFE that issues and manages workload identities based on attestation. | Used in cloud-native service identity, mTLS bootstrap, and secretless auth patterns. | SPIRE is an identity-control-plane implementation, not just another certificate generator. | SPIFFE; attestation; workload identity |
| STRIDE | A classic threat-modeling method that groups threats into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. | Used in design review, data-flow analysis, and SDL-style threat modeling workshops. | STRIDE is about categorizing threats, not about scoring business risk by itself. | DREAD; PASTA; threat model |
| TDS | Test-Driven Security; defining concrete security expectations as tests that can run in delivery workflows. | Used when converting vague requirements into pipeline checks and repeatable controls. | It does not mean every security activity belongs directly in fast CI. | CI/CD; control; baseline |
| Threat model | A structured view of assets, actors, trust boundaries, likely abuse paths, and controls. | Used in design review and architecture changes. | It is not only a diagram or paperwork exercise. | attack path; trust boundary |
| Triage | The act of deciding what matters first and what can wait. | Used in finding management, incident handling, and release decisions. | Triage is not the same thing as final remediation planning. | prioritization; backlog |
| Trivy | A widely used scanner for containers, repositories, and IaC that can report vulnerabilities, secrets, and misconfigurations. | Used in CI/CD, registry review, and cloud-native hygiene workflows. | A green scan does not prove runtime safety, exploitability, or business priority. | scanner; SBOM; misconfiguration |
| Trust boundary | A place where authority, data sensitivity, or assumptions change. | Used in threat modeling and architecture review. | Beginners often look for components, not boundary changes. | identity; data flow; control plane |
| Vulnerability | A weakness that can be exploited under some set of conditions. | Used in reports, scanners, and risk discussions. | A vulnerability may be real without being an immediate business priority. | finding; exploitability |
| WAF | Web Application Firewall; a control layer that filters or blocks web requests based on security policy and attack indicators. | Used at internet-facing edges, APIs, and web applications. | A WAF is useful for friction and containment, but it does not replace fixing authorization or business-logic flaws. | rate limit; virtual patching; edge controls |
| Workload attestation | The process of proving something trustworthy about a workload before issuing identity or access, often based on platform or node facts. | Used in zero-trust service identity systems such as SPIRE. | Attestation is about trust in the workload instance, not just trust in the code repository. | SPIRE; service identity; federation |
| Workload identity | The identity used by a running workload or service to call other systems. | Used in cloud-native and Kubernetes reviews. | Teams often overfocus on container config and forget the workload's authority. | service account; federation |
| Workload isolation | The combination of runtime, OS, and orchestration controls that prevent one workload from easily affecting another. | Used in multi-tenant Kubernetes, container runtime design, and node hardening. | Isolation is not a single setting; it is a layered outcome across runtime, kernel, policy, and network. | RuntimeClass; seccomp; namespaces |
How to use this glossary
- when you hit a term in a review and cannot explain it in one sentence, come back here;
- learn terms in clusters rather than alone: identity + authorization + trust boundary are more useful together;
- if a term sounds too broad, ask what system, identity, or data flow it refers to.