Cybersecurity Vocabulary for Developers: OWASP, CVE, and Zero-Trust Language

Security is no longer solely the responsibility of a dedicated security team — modern engineering organisations expect every developer to understand foundational security concepts and to use security vocabulary correctly in code reviews, architecture discussions, and incident analysis. This guide covers the vocabulary you need to participate meaningfully in security conversations.

Core Security Vocabulary

Attack surface — the total set of points in a system where an attacker could attempt to enter, extract data, or cause damage. “Every API endpoint, user input field, and third-party dependency is part of our attack surface. Reducing the attack surface is one of the most effective security measures we can take.”

Threat model — a structured analysis of potential threats to a system, identifying what could go wrong, who might attack, and what the impact would be. “Before we ship the payment integration, we should run a threat modelling session — at minimum, a STRIDE analysis of the new data flows.”

Threat actor — an entity (person, group, or automated system) that could exploit a vulnerability. Threat actors range from opportunistic automated scanners to targeted nation-state attackers. “The threat actors most relevant to our application are credential-stuffing bots and opportunistic web scanners, not sophisticated targeted attackers.”

Vulnerability — a weakness in a system that could be exploited by a threat actor. “The missing input validation on the file upload endpoint is a vulnerability; it could allow an attacker to upload a malicious file.”

Exploit — the specific method used to take advantage of a vulnerability. “A proof-of-concept exploit for that CVE was published yesterday; we need to patch before the weekend.”

CVE (Common Vulnerabilities and Exposures) — a standardised identifier for publicly disclosed security vulnerabilities. “Check whether any of your dependencies have open CVEs with a CVSS score above 7.0 before releasing.”

OWASP Top 10 Vocabulary

The OWASP Top 10 is the most widely referenced list of the most critical web application security risks. Knowing this vocabulary is essential for any developer discussing security in code reviews.

Injection (A03) — a family of attacks where untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most common. “The raw SQL concatenation on line 47 is a classic injection vulnerability — use parameterised queries instead.”

Broken authentication (A07) — weaknesses in how authentication and session management are implemented, allowing attackers to compromise credentials or sessions. “Storing session tokens in localStorage rather than httpOnly cookies is a broken authentication risk.”

Cryptographic failures (A02) — sensitive data exposed due to weak encryption, missing encryption, or poor key management. “Hashing passwords with MD5 is a cryptographic failure — use bcrypt or Argon2.”

Insecure design (A04) — security flaws arising from missing or insufficient security controls at the design stage. “The lack of rate limiting on the login endpoint is an insecure design issue, not just a code bug.”

Security misconfiguration (A05) — the most commonly found issue: default credentials, overly permissive access controls, unnecessary services enabled, or verbose error messages exposing system information. “That S3 bucket is publicly readable — classic security misconfiguration.”

Zero-Trust and Modern Security Architecture Vocabulary

Zero-trust — a security model that assumes no user, device, or network should be trusted by default, even inside the corporate perimeter. Every access request must be verified. “We are moving to a zero-trust architecture: even internal service-to-service calls will require mutual TLS and short-lived certificates.”

Least privilege — the principle that any user, service, or process should have only the minimum permissions required to perform its function. “The Lambda function only needs to read from one S3 bucket and write to one DynamoDB table — apply least privilege and remove the AdministratorAccess policy immediately.”

Defence-in-depth — a layered security approach where multiple independent controls protect a system, so that if one layer fails, others remain. “Our defence-in-depth strategy means that even if a dependency has a vulnerability, the combination of network segmentation, input validation, and WAF rules limits the blast radius.”

mTLS (Mutual TLS) — a variant of TLS where both client and server authenticate each other with certificates, rather than only the server presenting a certificate. Common in zero-trust architectures for service-to-service communication.

SAST (Static Application Security Testing) — automated analysis of source code to identify security vulnerabilities without executing the code. “We run SAST on every pull request; any high-severity finding blocks the merge.”

DAST (Dynamic Application Security Testing) — automated security testing of a running application by simulating attacks. “DAST runs nightly against our staging environment to catch issues that SAST might miss.”

How to Discuss Security in Code Reviews

Raising a security concern:

• “This looks like a potential injection vulnerability — the user-supplied input is interpolated directly into the query string. Can we use parameterised queries here?”
• “I want to flag this from a security perspective: this endpoint has no authentication check. Is that intentional?”
• “The error message on line 34 exposes the database schema — this is an information disclosure risk.”

Praising good security practice:

• “Good use of parameterised queries throughout — this is exactly the right pattern.”
• “I appreciate the explicit input validation on the file type — this is the defence-in-depth approach we want.”

Suggesting improvements:

• “Before this merges, I would like to see a rate limit added to this endpoint — without one, it is susceptible to credential stuffing.”
• “Can we move the secret from the code to the secrets manager? Hardcoded credentials are a critical risk.”

Example Sentences in Context

1. “Our threat model identified that the highest-risk component is the file upload handler — it has a large attack surface and processes untrusted input that ultimately gets served to other users.”

2. “The principle of least privilege applies here: the service account used by this Lambda should only have read access to the specific S3 prefix it needs, not read access to the entire bucket.”

3. “Defence-in-depth is our answer to the question ‘what if one control fails?’ — we have WAF rules, input validation, parameterised queries, and output encoding all protecting against injection attacks.”

4. “The CVE that was disclosed on Monday affects a dependency we use directly; the CVSS score is 9.1, which puts it in the critical category — we need to patch and deploy before the end of the day.”

5. “Zero-trust means we do not assume that traffic originating from inside our VPC is trustworthy; every service-to-service call is authenticated with a short-lived token, and permissions are scoped to the minimum required.”