Practice & Reference · Glossary
Glossary
Every term this course leans on without stopping to define it mid-lesson, gathered into one alphabetical, searchable page — scanning categories, secrets and identity, policy as code, supply-chain and container security, cloud posture, compliance frameworks, and the vocabulary of security response.
☺ Explain it like I'm 10
If a lesson uses a term you don't recognize — SBOM, STRIDE, zero trust — it's defined here in a sentence or two, not buried three paragraphs into a page you've already left. Search the box below or scan the list; nothing here assumes you already know the acronym.
Attack surfaceEvery point where an attacker could attempt to enter or extract data from a system — exposed endpoints, open ports, third-party dependencies, misconfigured storage. Reducing attack surface means removing or restricting these points, not just detecting attacks against them.
Blue teamThe defenders in a security exercise: the team responsible for detecting, containing, and responding to a simulated or real attack, typically using the organization's actual monitoring and incident-response tooling.
Branch protectionRepository rules that block direct pushes to a protected branch (typically main) and require conditions such as passing checks, a minimum number of approving reviews, or signed commits before a merge is allowed. The mechanism that makes code review and CI gates actually enforceable rather than optional.
Bug bountyA program that pays external researchers for responsibly disclosed vulnerabilities found in a defined scope of production systems, sourcing findings from a much larger and more adversarially minded pool than an internal security team alone.
Chain of custodyA documented, unbroken record of who collected a piece of forensic evidence, when, and how it was handled afterward. Without it, evidence gathered during an incident investigation can't be trusted to be unaltered — a requirement that matters both for internal root-cause work and for anything that might end up in legal or regulatory proceedings.
Compliance as codeEncoding a compliance control as a machine-checkable policy that runs continuously against live infrastructure, so a pass/fail record is produced automatically as a byproduct of normal operation instead of gathered by a human under audit deadline pressure.
CSPM (cloud security posture management)Tooling that continuously scans cloud accounts against a rule set — public S3 buckets, unencrypted volumes, overly permissive IAM roles — and reports or auto-remediates drift from that baseline. Distinct from a SIEM, which is built around log correlation rather than configuration state.
CVE (Common Vulnerabilities and Exposures)A unique, publicly tracked identifier (e.g. CVE-2024-12345) assigned to a specific, publicly known software vulnerability, maintained by MITRE. The common reference point that scanners, advisories, and patch notes all use to talk about the same flaw.
CVSS (Common Vulnerability Scoring System)A standardized 0–10 severity score for a vulnerability, derived from factors like attack vector, complexity, and privileges required. Used to triage which of the CVEs a scanner surfaces actually need to be fixed before the next release, versus tracked and deferred.
DAST (dynamic application security testing)Testing a running application from the outside, the way an attacker would — sending crafted HTTP requests and observing responses — to find vulnerabilities like injection or broken authentication that only manifest at runtime and wouldn't show up reading the source.
Dependency confusionA supply-chain attack that exploits package managers preferring a public registry package over an internal one of the same name: an attacker publishes a malicious package under an internal project's name to the public registry, and a misconfigured build pulls the attacker's version instead of the private one.
Distroless imageA container base image stripped down to an application and its runtime dependencies only — no shell, no package manager, no OS utilities. Shrinks the attack surface directly: there's no shell for an attacker who gains code execution to pivot into.
Dynamic secretsCredentials generated on demand for a specific short lease rather than provisioned once and reused. A database credential minted by HashiCorp Vault for a single job run and automatically revoked at lease expiry is a dynamic secret; a static password checked into a config file is not.
Encryption at restEncrypting data while it is stored — on disk, in a database, in object storage — so that access to the underlying storage medium alone (a stolen disk, a misconfigured bucket) doesn't expose the data without the decryption key.
Encryption in transitEncrypting data while it moves between systems — typically via TLS — so a party positioned on the network path between sender and receiver can't read or tamper with it, even if they can observe the traffic.
Ephemeral credentialsCredentials issued for a short, bounded lifetime and not intended to be reused after expiry — a CI job's cloud role assumed only for the duration of that job, an OIDC-issued token instead of a long-lived static access key. Limits how much damage a leaked credential can do, since it's already expired by the time most leaks are discovered.
FuzzingAutomatically generating large volumes of malformed, random, or boundary-case input and feeding it to a running program to surface crashes, hangs, or memory-safety violations that indicate exploitable bugs. Finds a different class of defect than SAST or DAST, since it doesn't need to understand the code's logic or the application's expected behavior to trigger a failure.
GDPR (General Data Protection Regulation)The European Union's data protection law, governing how organizations collect, process, and store personal data of EU residents, with defined individual rights (access, erasure, portability) and mandatory breach-notification timelines.
Guardrail vs. gateTwo ways a policy engine can enforce a rule. A gate blocks the action outright — a deploy or a merge simply fails a violating change. A guardrail warns or logs the violation without blocking, useful for rolling out a new policy without breaking teams before they've had a chance to fix flagged issues.
HIPAA (Health Insurance Portability and Accountability Act)A US law setting security and privacy requirements for protected health information (PHI). Any system that stores, processes, or transmits PHI for a covered entity or its business associates falls under its Security Rule.
IAM (identity and access management)The system of users, roles, groups, and policies that determines who or what — a person, a service, a CI job — can perform which actions on which resources. Cloud IAM misconfiguration (overly broad roles, unused permissions) is one of the most common root causes of cloud breaches.
Image signingCryptographically signing a container image so that its origin and integrity can be verified before it's pulled or deployed. A cluster admission controller can then enforce that only signed images from trusted sources are allowed to run.
Incident responseThe structured process an organization follows when a security event is detected, from initial identification through containment, eradication, recovery, and the lessons-learned review afterward. See the PICERL lifecycle.
ISO 27001An international standard specifying requirements for an information security management system (ISMS): a documented, auditable process for identifying risks, applying controls, and continuously improving them. Certification is issued by an accredited third-party auditor after a formal audit.
Least privilegeGranting a user, service, or process only the exact permissions it needs to do its job, and no more. The organizing principle behind most IAM design: every excess permission is attack surface that provides no operational benefit.
MisconfigurationAn insecure setting left in place not through a code vulnerability but through incorrect setup — a public storage bucket, a default admin password, an overly permissive security group. Consistently one of the leading root causes of cloud breaches, ahead of exploited software vulnerabilities.
OPA (Open Policy Agent)-style engineA general-purpose policy engine that evaluates structured input (a Kubernetes manifest, a Terraform plan, an API request) against rules written in a dedicated policy language — Rego, in OPA's case — and returns an allow/deny decision. The reference architecture for "policy as code" tooling on this platform.
PCI-DSS (Payment Card Industry Data Security Standard)A security standard required of any organization that stores, processes, or transmits payment card data, covering network segmentation, encryption, access control, and logging. Enforced through mandatory audits or self-assessments, not government regulation.
Penetration testingAn authorized, time-boxed, goal-directed simulated attack against a defined scope of systems, performed by testers (internal or third-party) trying to achieve a specific objective, such as reaching a database, rather than exhaustively cataloging every possible finding.
PICERLThe classic incident-response lifecycle: Preparation, Identification, Containment, Eradication, Recovery, Lessons learned. A shared vocabulary for what phase an active incident is in and what should happen next.
Policy as codeExpressing a security or compliance rule as a machine-readable policy that's version-controlled and evaluated automatically, instead of as a document a human interprets. Lets a policy be tested, reviewed, and enforced with the same rigor as application code.
Purple teamA collaborative exercise where red and blue teams work together in real time, rather than red team attacking in secret and handing over a report afterward, so detection gaps get identified and fixed while the context of the attack is still fresh.
Red teamThe attackers in a security exercise: a team that simulates a real adversary's tactics, techniques, and procedures against production or production-like systems, often without the defending team knowing in advance, to test detection and response under realistic conditions.
Rugged softwareA movement and mindset that treats resilience to attack, failure, and unexpected use as a core software quality attribute — alongside performance and reliability — rather than a separate concern bolted on by a security team after the fact.
SAST (static application security testing)Analyzing source code, without running it, to find vulnerability patterns — SQL injection, hardcoded secrets, unsafe deserialization — directly in the codebase. Runs early and fast enough to gate a pull request, but can't catch issues that only appear at runtime.
SBOM (software bill of materials)A structured, machine-readable inventory of every component, library, and dependency in a shipped artifact, used to answer "are we affected by this CVE" quickly across a fleet of services, and increasingly required by supply-chain security regulation.
SBOM formats (SPDX and CycloneDX)The two dominant standardized formats for expressing an SBOM. SPDX originated in open-source license compliance and is now an ISO standard; CycloneDX was built by OWASP with security use cases (vulnerability and dependency tracking) as its primary design goal. Most SBOM tooling can emit either.
SCA (software composition analysis)Scanning a project's third-party and open-source dependencies against known-vulnerability databases to flag which libraries in use have disclosed CVEs, and often to check license compliance at the same time.
Secret rotationPeriodically or automatically replacing a credential with a new one and invalidating the old one, so a leaked or compromised secret has a bounded window of usefulness to an attacker instead of remaining valid indefinitely.
Secrets managerA dedicated system — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — for storing, distributing, auditing access to, and rotating credentials, so secrets are pulled at runtime from a controlled, logged source instead of checked into code or config files.
Secrets sprawlThe uncontrolled proliferation of credentials across a codebase and infrastructure — hardcoded in source, pasted into chat, embedded in config files, duplicated across environments — that accumulates when there's no single system responsible for issuing and tracking secrets.
Security championAn engineer embedded on a product or platform team who isn't a full-time security specialist but has extra security training and serves as that team's first point of contact for security questions and reviews, scaling a small central security team's reach across many teams at once.
Security debtDeferred security work — unpatched dependencies, unresolved findings, missing controls — treated as debt with compounding cost: the longer it's deferred, the more expensive and riskier it becomes to fix, and the larger the exposed attack surface in the meantime.
Shared responsibility modelThe division of security duties between a cloud provider and its customer: the provider secures the underlying infrastructure ("security of the cloud"), while the customer is responsible for configuring what they build on top of it correctly ("security in the cloud") — identity, data, network rules, and workload configuration.
Shift-leftMoving a security concern — scanning, threat modeling, review — earlier in the development lifecycle, so problems are caught while they're still cheap to fix instead of after they reach production. The organizing principle this entire course is built around.
SIEM (security information and event monitoring)A platform that centralizes log and event data from across an environment, correlates it against detection rules, and surfaces alerts for a security team to triage — the primary tool a SOC works from during day-to-day monitoring and active incident response.
Signed commitsGit commits cryptographically signed with a developer's GPG or SSH key, so a commit's claimed author can be verified rather than merely trusted, since Git's author field alone can be set to any name or email.
Sigstore/cosign-class toolingOpen-source tooling (Sigstore and its cosign CLI, from the OpenSSF) for signing and verifying software artifacts using short-lived, keyless certificates tied to an identity provider, instead of long-lived private signing keys that have to be separately stored and rotated.
SLSA (Supply-chain Levels for Software Artifacts)A framework of increasing maturity levels for securing a software supply chain, covering how source is controlled, how builds are produced, and how provenance is generated and verified — a shared vocabulary for how much a consumer of an artifact can trust its origin.
SOC 2An audit report, based on the AICPA's Trust Services Criteria, attesting that a service organization's controls meet defined standards for security, availability, processing integrity, confidentiality, or privacy. Type I attests to controls at a point in time; Type II attests to their operation over a period, typically 3–12 months.
STRIDEA threat-modeling mnemonic covering six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. A structured checklist for walking through what could go wrong with a given system design.
Supply-chain attackAn attack that compromises a target indirectly, through a dependency, build tool, or vendor it trusts, rather than attacking the target directly — poisoning a widely used package, compromising a CI runner, or tampering with a build pipeline.
Threat modelA structured analysis of a system that identifies what could go wrong (threats), how likely and damaging each is, and what mitigates it — typically produced by walking a design through a framework like STRIDE before or alongside implementation.
Trust boundaryA point in a system where data or a request crosses from one level of trust to another — from the public internet into an internal network, from an unauthenticated to an authenticated context. Threat modeling concentrates scrutiny at these boundaries because that's where validation and authorization checks actually matter.
Zero trustA security model that assumes no request should be trusted by default based on network location alone — inside the corporate network is treated the same as outside — and instead verifies identity and authorization explicitly on every request, regardless of where it originates.