Application Security Glossary

The application security field has developed a precise technical vocabulary spanning vulnerability classification, testing methodology, regulatory compliance, and architectural defense. This glossary defines the canonical terms encountered across the application security fundamentals landscape, drawing on authoritative definitions from NIST, OWASP, ISO/IEC, and MITRE. Professionals navigating tools, frameworks, or procurement decisions rely on shared terminology to avoid misclassification of risk and misalignment between teams.

Definition and scope

An application security glossary is a structured reference that maps standardized definitions to terms used across secure software development, vulnerability research, compliance frameworks, and security tooling. The scope covers web applications, mobile platforms, APIs, cloud-native architectures, and the software supply chain.

Authoritative definition sources include NIST SP 800-53 Rev 5, the OWASP Foundation, MITRE ATT&CK, ISO/IEC 27001, and the NIST Secure Software Development Framework (SSDF), NIST SP 800-218. Where definitions conflict across sources, the governing framework for a given context (e.g., PCI DSS for payment applications, HIPAA for health data) takes precedence.

The glossary applies to three primary professional audiences: application security engineers building or auditing systems, compliance officers mapping controls to regulatory requirements, and procurement specialists evaluating vendor tooling. Terms are organized by functional domain rather than alphabetical listing to preserve conceptual relationships.

How it works

Application security terminology operates within a layered reference architecture. Understanding how terms relate to one another requires distinguishing four classification strata:

1. Vulnerability classes — Structural weaknesses in code or configuration, catalogued in sources such as the MITRE CWE list (Common Weakness Enumeration) and the OWASP Top Ten.
2. Attack techniques — Exploitation methods mapped in MITRE ATT&CK and described in CVE entries published via the National Vulnerability Database (NVD).
3. Control types — Preventive, detective, and corrective countermeasures aligned to frameworks such as NIST SP 800-53 and the Secure Software Development Lifecycle.
4. Testing methodologies — Approaches including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Software Composition Analysis (SCA).

Key contrast — SAST vs. DAST: SAST analyzes source code, bytecode, or binary without executing the application; it operates at development time and detects issues such as SQL injection patterns and insecure function calls. DAST probes a running application from the outside, simulating attacker behavior against live endpoints; it detects runtime issues that source analysis cannot observe, such as authentication bypass under real HTTP traffic. Neither method achieves complete coverage in isolation — production-grade programs combine both with manual secure code review.

Severity scoring uses the Common Vulnerability Scoring System (CVSS), maintained by FIRST.org. CVSS v3.1 scores range from 0.0 to 10.0, with critical findings defined as 9.0–10.0. Scores factor in attack vector, attack complexity, privileges required, user interaction, and three impact dimensions (confidentiality, integrity, availability).

Common scenarios

Regulatory compliance mapping — Organizations subject to PCI DSS application security requirements must demonstrate that terms like "penetration test," "vulnerability scan," and "web application firewall" align with PCI SSC definitions, not generic industry usage. PCI DSS v4.0 distinguishes authenticated from unauthenticated scanning and mandates application-layer testing under Requirement 6.

Procurement and vendor evaluation — When evaluating application security tools, buyers encounter overlapping vendor claims. "RASP" (Runtime Application Self-Protection) and "WAF" (Web Application Firewall) address overlapping threat surfaces but operate at different layers: a WAF inspects HTTP traffic at the network perimeter, while RASP instruments the application runtime itself. Conflating the two leads to coverage gaps.

Incident classification — During appsec incident response, teams must distinguish a "security misconfiguration" (CWE-16) from a "broken access control" flaw (CWE-284), because remediation paths, responsible teams, and regulatory notification obligations differ. HIPAA breach notification under 45 CFR §164.400–414 applies when protected health information is exposed — a classification that depends on precise vulnerability typing, not general labels.

Supply chain and dependency risk — Software Composition Analysis tools identify vulnerabilities in third-party libraries using NVD CVE data. An SBOM (Software Bill of Materials) provides the component inventory against which CVE lookups run. These terms have distinct meanings under Executive Order 14028 (May 2021), which directed NIST to publish guidance on SBOM minimum elements — published as "The Minimum Elements For a Software Bill of Materials" by the NTIA.

Decision boundaries

Applying terminology precisely requires understanding where classification boundaries fall:

• Vulnerability vs. exposure vs. weakness — A weakness (CWE) is a class of flaw in code or design. A vulnerability (CVE) is a specific, confirmed instance of a weakness in a named product version. An exposure is a condition that does not directly allow exploitation but increases risk. Treating an exposure as a confirmed vulnerability inflates risk scores and misallocates remediation effort.
• Threat vs. risk — NIST SP 800-30 Rev 1 defines threat as any circumstance with potential to adversely impact operations; risk is the probability-weighted impact of that threat acting through a vulnerability. Threat modeling for applications addresses threats; a risk register quantifies risk.
• Authentication vs. authorization — Authentication confirms identity; authorization determines permitted actions. Authentication and authorization security controls address both, but failures in each require distinct remediation. OWASP lists broken access control (authorization failure) as the top-ranked risk in the OWASP Top 10 2021.
• False positive vs. false negative in testing — In SAST/DAST output, a false positive is a reported finding that does not represent a real vulnerability; a false negative is a real vulnerability the tool missed. Tool selection for CI/CD pipeline integration must account for both error types, as high false-positive rates degrade developer trust while high false-negative rates create undetected exposure.

References

• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems
• NIST SP 800-218 — Secure Software Development Framework (SSDF)
• NIST SP 800-30 Rev 1 — Guide for Conducting Risk Assessments
• OWASP Top 10 2021
• MITRE CWE — Common Weakness Enumeration
• MITRE ATT&CK
• National Vulnerability Database (NVD) — NIST
• FIRST.org — CVSS v3.1 Specification
• NTIA — Minimum Elements for a Software Bill of Materials (SBOM)
• PCI Security Standards Council — PCI DSS v4.0
• HHS — HIPAA Breach Notification Rule, 45 CFR §164.400–414