Security teams drown in acronyms before they ever fix a vulnerability. A single AppSec vendor evaluation can surface SAST, DAST, IAST, SCA, SBOM, CVE, CVSS, CWE, RASP, and SSDF in one slide deck — and half of them get used interchangeably even though they measure completely different things. That confusion has real cost: teams buy overlapping tools, misroute findings to the wrong engineers, or under-report SBOM data because nobody agreed on what "software composition" actually covers under Executive Order 14028.
This glossary defines the 10 application security acronyms that show up most often in vendor comparisons, compliance audits, and CVE advisories, with the standards body, publication date, or scoring range behind each one. Each entry answers the question directly, then gives a concrete example — a real CVE, a specific CVSS score, or a named regulation — so you can use the term correctly the next time it appears in a pen test report or a SOC 2 questionnaire.
What do SAST, DAST, and IAST stand for, and how do they differ?
SAST (Static Application Security Testing) scans source code or binaries without running the application, DAST (Dynamic Application Security Testing) attacks a running application from the outside like a black-box pen tester, and IAST (Interactive Application Security Testing) instruments the application at runtime to watch code paths as real traffic hits them. SAST tools such as Semgrep or Checkmarx parse abstract syntax trees and flag patterns like string-concatenated SQL queries before a single line ships — OWASP's 2021 Top 10 lists Injection (A03) as exactly the class of bug SAST is built to catch. DAST tools like OWASP ZAP or Burp Suite instead send crafted HTTP requests to a staging URL and observe the responses, which means they catch misconfigurations (like a missing Content-Security-Policy header) that never appear in source code. IAST sits in between: an agent inside the running app (common in Java and .NET stacks) tags tainted input and traces it through the call stack, giving line-of-code precision with the context of real execution. Gartner has grouped all three under "AST" since its 2011 Magic Quadrant, but they generate three different finding types, and mature AppSec programs run at least SAST and DAST in the same CI/CD pipeline rather than picking one.
What is SCA, and how is it different from SAST?
SCA (Software Composition Analysis) inventories every open-source and third-party package in an application and checks each one against known-vulnerability databases, while SAST only looks at code your own engineers wrote. The distinction matters because most modern applications are majority open source by line count — Synopsys's 2024 OSSRA report found open-source code makes up 77% of the average codebase — so a SAST scan that ignores dependencies is auditing a small fraction of the actual attack surface. SCA tools like Snyk Open Source, Dependabot, or Safeguard's own scanner parse manifest files (package-lock.json, pom.xml, requirements.txt) and flag known CVEs in transitive dependencies, sometimes four or five layers deep. The 2021 Log4Shell vulnerability (CVE-2021-44228, CVSS 10.0) is the canonical example: it lived inside Log4j, a logging library most developers pulled in transitively through Spring Boot or Elasticsearch, and only SCA tooling — not SAST — could have surfaced it before December 9, 2021, when it went public.
What is an SBOM, and why did it become a federal requirement?
An SBOM (Software Bill of Materials) is a machine-readable inventory of every component, library, and version inside a piece of software, and it became a U.S. federal requirement under Executive Order 14028, signed May 12, 2021, following the SolarWinds supply chain attack. The order directed NIST and CISA to define minimum elements for SBOMs, which NIST published in July 2021 and CISA formalized further in 2023 guidance covering two interchangeable formats: SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). Since then, any software sold to a federal agency has needed to produce an SBOM on request, and the FDA has required SBOMs for medical device premarket submissions since October 2023 under the PATCH Act provisions in the omnibus spending bill. In practice, an SBOM answers one question fast during an incident: "do we run the vulnerable version of this library, and where?" — a question that took security teams days to answer manually during Log4Shell and should take minutes with an automated SBOM inventory.
What do CVE, CVSS, and CWE mean, and how do they relate to each other?
CVE (Common Vulnerabilities and Exposures) is a unique identifier for a specific published vulnerability, CVSS (Common Vulnerability Scoring System) is the 0.0–10.0 severity score assigned to that CVE, and CWE (Common Weakness Enumeration) is the category of underlying software flaw that made the vulnerability possible. MITRE has run the CVE program since 1999 and had assigned more than 240,000 CVE IDs by the start of 2025, each following the format CVE-YYYY-NNNNN. CVSS, now on version 4.0 (released November 2023 by FIRST.org), scores a CVE on exploitability and impact — Log4Shell's CVSS score of 10.0 reflected that it was remotely exploitable, required no authentication, and allowed full remote code execution. CWE, also maintained by MITRE, classifies the root cause: Log4Shell maps to CWE-502 (Deserialization of Untrusted Data), the same weakness category MITRE's 2024 CWE Top 25 ranked as the 9th most dangerous software weakness. Together, the three form a chain — CWE explains the flaw type, CVE identifies one instance of it in specific software, and CVSS tells you how urgently to fix it.
What is RASP, and is it still relevant in 2026?
RASP (Runtime Application Self-Protection) is a security control embedded directly in an application's runtime that detects and blocks attacks as they happen, and it remains relevant but has narrowed to a specific niche rather than disappearing. Gartner popularized RASP starting around 2014 as an alternative to perimeter WAFs, since a RASP agent sees actual application context — variable values, call stacks, SQL query construction — instead of just raw HTTP traffic. Vendors like Signal Sciences (acquired by Fastly in 2020) and Contrast Security built products around it, and it's particularly common in legacy Java and .NET monoliths where rewriting code isn't feasible but blocking known-bad patterns at runtime is. Its relevance has shrunk as reachability analysis and better SCA tooling let teams fix the vulnerable code itself pre-deployment rather than shielding it at runtime, but RASP still shows up in regulated environments — banking and healthcare — where a compensating control is required while a permanent code fix works through change management.
What is SSDF, and why does it matter for compliance?
SSDF (Secure Software Development Framework) is NIST's set of recommended practices for building security into every phase of the software development lifecycle, published as NIST SP 800-218 in February 2022 in direct response to Executive Order 14028. SSDF organizes practices into four groups — Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities — and it matters for compliance because federal contractors must now self-attest to SSDF conformance to sell software to U.S. government agencies, per CISA's common self-attestation form finalized in March 2024. Unlike SOC 2 or ISO 27001, which audit an organization's controls broadly, SSDF is scoped specifically to the software build pipeline: things like maintaining provenance data for build environments and running automated vulnerability scanning before release. Auditors increasingly cross-reference SSDF attestations against SBOM data and CVE remediation timelines, so the acronym you learn first (SBOM) and the one you learn last (SSDF) end up in the same compliance packet.
How Safeguard Helps
Safeguard turns this acronym list into a single connected workflow instead of ten disconnected tools. Our platform generates and ingests SBOMs in both SPDX and CycloneDX formats, then runs reachability analysis to determine which CVEs in your dependency tree are actually reachable from your application's code paths — cutting through the noise of SCA alerts that flag vulnerable functions your code never calls. Griffin AI, our AI triage engine, cross-references CVSS scores, CWE categories, and reachability data to rank findings by real exploitability rather than raw severity, and it drafts auto-fix pull requests that bump the vulnerable dependency to a patched version with the diff already validated against your test suite. That means the gap between "CVE published" and "CVE fixed in production" — the gap that mattered most during Log4Shell — shrinks from days to a single merged PR.