Security and compliance terminology.
Definitions for the security, compliance, and AI-coding terms that show up across Deva and across the regulated industries we serve. Each entry is self-contained and citable.
Vulnerabilities and Scanning
Core security terminology covering vulnerability classification, scanning techniques, and analysis methodologies.
- CWE· Common Weakness Enumeration
- Common Weakness Enumeration is a category system maintained by MITRE for software security weaknesses. Each CWE entry describes a class of vulnerability (for example, CWE-79 is Cross-Site Scripting, CWE-89 is SQL Injection). CWE provides the canonical taxonomy that security scanners, vulnerability disclosures, and compliance frameworks reference. Deva detects 970+ CWE patterns across 84 categories.
- CVE· Common Vulnerabilities and Exposures
- Common Vulnerabilities and Exposures is the public catalog of disclosed software vulnerabilities maintained by MITRE under sponsorship of CISA. Each CVE entry identifies a specific flaw in a specific product version (for example, CVE-2024-3094 is the XZ Utils backdoor). CVEs are mapped to CWEs to indicate the underlying weakness class. Deva's supply-chain scanner cross-references 27,000+ CVE advisories against project dependencies.
- SAST· Static Application Security Testing
- Static Application Security Testing analyzes source code, bytecode, or binaries without executing them. SAST tools detect vulnerabilities by pattern matching, AST parsing, and dataflow analysis. SAST runs early in the development lifecycle, often in the IDE or pre-commit hook, making it the lowest-cost vulnerability detection point. Deva ships an SAST engine with 341 YAML rules across 84 CWE categories.
- SCA· Software Composition Analysis
- Software Composition Analysis identifies open-source dependencies in a project and matches them against known vulnerability databases (NVD, GitHub Advisory Database, OSV). SCA is the only practical defense against transitive vulnerabilities in third-party packages. Deva's SCA layer checks dependency manifests against a 2,800+ package metadata catalog enriched with 27,000+ CVE advisories.
- DAST· Dynamic Application Security Testing
- Dynamic Application Security Testing executes a running application and probes it for vulnerabilities (injection, broken auth, misconfiguration). DAST complements SAST by finding flaws that only manifest at runtime, but requires a deployed test environment and produces no source-line attribution.
- IAST· Interactive Application Security Testing
- Interactive Application Security Testing combines SAST and DAST by instrumenting a running application to observe both source code paths and execution behavior. IAST detects vulnerabilities with higher confidence than either technique alone, at the cost of requiring an agent inside the application runtime.
- Taint tracking
- Taint tracking follows data flow from input sources (HTTP parameters, file reads, message bodies) through program execution to output sinks (database queries, shell commands, DOM insertion). A finding fires when tainted data reaches a sensitive sink without passing through a recognized sanitizer. Taint tracking has substantially lower false-positive rates than regex matching because it confirms the data path. Deva's scanner includes 163 taint-mode rules across all supported languages.
- AST analysis· Abstract Syntax Tree analysis
- AST analysis parses source code into an Abstract Syntax Tree and then queries the tree for vulnerable patterns. Unlike regex matching, AST analysis understands language structure: it can distinguish a string literal containing 'eval' from an actual call to the eval function. Deva uses tree-sitter-based AST analysis for Python, JavaScript, TypeScript, Go, Java, Ruby, and Rust.
- Dataflow analysis
- Dataflow analysis tracks how values move through a program. It is the foundation of taint tracking, constant propagation, and many compiler optimizations. In security, dataflow analysis answers the question: can an attacker-controlled value reach a sensitive operation, and if so, what transformations does it pass through.
- SBOM· Software Bill of Materials
- Software Bill of Materials is a formal inventory of components, libraries, and dependencies that comprise a software product. SBOMs are required by Executive Order 14028 for software sold to the US federal government and are increasingly demanded by enterprise procurement. Common formats include SPDX and CycloneDX. Without an SBOM, an organization cannot meaningfully respond to supply-chain vulnerability disclosures.
- Supply chain attack
- A supply chain attack targets a software product indirectly, by compromising one of its upstream dependencies, build tools, or distribution channels. Notable examples include the XZ Utils backdoor (CVE-2024-3094), the SolarWinds breach, and the npm event-stream incident. Supply chain attacks are difficult to prevent because they exploit the trust that consumers place in component publishers.
Compliance Frameworks
Regulatory and industry frameworks that govern code-level security and audit requirements in regulated industries.
- HIPAA· Health Insurance Portability and Accountability Act
- HIPAA is the US federal law governing protected health information (PHI). The HIPAA Security Rule (45 CFR Part 164, Subpart C) establishes administrative, physical, and technical safeguards for electronic PHI. Software handling ePHI must implement access controls (164.312(a)(1)), audit controls (164.312(b)), integrity controls (164.312(c)), and transmission security (164.312(e)). Violations carry tiered civil monetary penalties up to roughly $2 million per violation category per year.HIPAA compliance for healthcare developers
- HIPAA Security Rule
- The HIPAA Security Rule, codified at 45 CFR 164.302 through 164.318, defines technical safeguards required when electronic PHI is created, received, maintained, or transmitted. Required implementation specifications include unique user identification, automatic logoff, encryption (addressable), and integrity verification. Deva maps CWE findings to specific Security Rule subsections in its SARIF exports for audit evidence.
- ePHI· Electronic Protected Health Information
- Electronic Protected Health Information is any individually identifiable health information transmitted or stored electronically. The HIPAA Security Rule applies specifically to ePHI. The full list of 18 PHI identifiers is enumerated in 45 CFR 164.514(b)(2)(i) and includes names, geographic subdivisions smaller than a state, dates more specific than a year, contact information, and biometric identifiers.
- BAA· Business Associate Agreement
- A Business Associate Agreement is a HIPAA-required contract between a covered entity and any third party that creates, receives, maintains, or transmits PHI on the covered entity's behalf. The BAA establishes the business associate's obligations under HIPAA and creates direct liability for breaches. Software vendors handling ePHI for healthcare customers typically require a signed BAA before integration.
- CMMC· Cybersecurity Maturity Model Certification
- Cybersecurity Maturity Model Certification is the US Department of Defense framework for protecting Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). CMMC 2.0 has three levels: Level 1 (Foundational, FCI only), Level 2 (Advanced, aligned with NIST 800-171), and Level 3 (Expert, aligned with a subset of NIST 800-172). DoD contracts increasingly require CMMC certification at the relevant level.CMMC compliance for defense contractors
- CMMC Level 2
- CMMC Level 2 implements all 110 security requirements from NIST SP 800-171 Rev 2. Level 2 assessments are conducted by accredited C3PAO (Certified Third-Party Assessor Organization) assessors. As of 2026, Level 2 certification is required for DoD contracts that involve CUI. Source-code-level evidence of flaw remediation (SI.L2-3.14.1) and CUI flow control (AC.L2-3.1.3) are commonly cited assessment areas.
- NIST 800-171· NIST Special Publication 800-171
- NIST Special Publication 800-171 specifies 110 security requirements for protecting CUI in nonfederal systems. Originally released in 2015, the current revision (Rev 2) covers 14 control families: Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity.
- NIST 800-53· NIST Special Publication 800-53
- NIST Special Publication 800-53 (Rev 5, 2020) is the security and privacy control catalog used by US federal information systems. It defines roughly 1,000 controls across 20 families. FedRAMP authorization baselines (Low, Moderate, High) are derived from NIST 800-53 control selections. The SA (System and Services Acquisition), SI (System and Information Integrity), AC (Access Control), and CM (Configuration Management) families contain most code-relevant controls.
- FedRAMP· Federal Risk and Authorization Management Program
- FedRAMP is the US federal program that standardizes security assessment and authorization for cloud services used by federal agencies. FedRAMP authorizations come in three baselines (Low, Moderate, High) and require ongoing continuous monitoring. The latest baselines were updated in 2023 to align with NIST 800-53 Rev 5. FedRAMP High systems have additional egress and data-residency restrictions that often require fully on-premise or air-gapped tooling.
- PCI-DSS· Payment Card Industry Data Security Standard
- Payment Card Industry Data Security Standard is the security requirement set for entities that store, process, or transmit cardholder data. The current version is PCI-DSS v4.0, in effect since March 2024 (with March 2025 final deadline for future-dated requirements). v4.0 has 12 high-level requirements covering network security, vulnerability management, access control, monitoring, and security policy. Code-relevant requirements concentrate in Requirement 6 (Develop and Maintain Secure Systems and Software).Financial compliance with PCI-DSS
- PAN· Primary Account Number
- Primary Account Number is the cardholder account number on a credit, debit, or stored-value card. Under PCI-DSS, PAN must be rendered unreadable when stored (via hashing, truncation, or tokenization) and protected via strong cryptography in transit. Logging the PAN in clear text in application logs, exception traces, or debugging output is a frequent source of PCI violations and is detectable at code level.
- SOX· Sarbanes-Oxley Act
- The Sarbanes-Oxley Act of 2002 imposes accuracy and accountability requirements on US public-company financial reporting. Section 302 requires executive certification of disclosure controls. Section 404 requires assessment of internal controls over financial reporting (ICFR), including the IT systems that support those processes. Section 802 imposes record retention requirements with criminal penalties for tampering. Software touching financial reporting must implement immutable audit trails, separation of duties, and documented change management.
- ITGC· IT General Controls
- IT General Controls are the policies and procedures that govern the IT environment supporting financial reporting. ITGCs apply across applications and include access management, change management, computer operations, and program development. Auditors test ITGCs as part of SOX 404 attestation. Code-level ITGC evidence includes commit-level approval workflows, separation of duties enforcement, and tamper-evident audit logs.
- SOC 2· Service Organization Control 2
- SOC 2 is an attestation framework from the AICPA for service organizations that store customer data. SOC 2 reports assess controls against the five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. A SOC 2 Type II report covers a period of time (typically 6 to 12 months) and is the de facto trust signal for B2B SaaS procurement.
- GDPR· General Data Protection Regulation
- The General Data Protection Regulation (EU 2016/679) governs processing of personal data of EU residents. Article 25 requires data protection by design and by default, meaning privacy controls must be implemented at the technical architecture level rather than added afterward. Penalties for non-compliance can reach 4% of annual global turnover or €20 million, whichever is greater. GDPR applies extraterritorially to any organization processing EU resident data, regardless of where the organization is based.
- Article 25· GDPR Article 25 (Data protection by design and by default)
- GDPR Article 25 codifies the principle of data protection by design and by default. Controllers must implement appropriate technical and organizational measures (such as pseudonymization) at the time of design and during processing. This is the legal hook that pulls privacy requirements down to the code level: input validation, data minimization, encryption, and access control must be present from the start, not bolted on.
Environments and Data Classification
Terms describing controlled computing environments, data classifications, and operational boundaries.
- Air-gapped
- An air-gapped environment has no network connection to untrusted external systems. Traditionally this meant literal physical isolation, but in practice modern air-gapped systems may have controlled one-way data flows (data diodes) or maintenance-window connections to trusted networks. Software that runs in air-gapped environments cannot rely on cloud API calls, package registry pulls, or external telemetry. Deva is engineered for air-gapped deployment: the scanner, local Deva Coder model, and compliance mapping all operate fully offline.
- Classified environment
- A classified environment processes information designated as classified under Executive Order 13526 (Confidential, Secret, or Top Secret). Classified environments enforce strict physical security, personnel clearance requirements, hardware and software approval lists, and prohibitions on egress of classified data. Most commercial AI coding tools cannot operate in classified environments because their architecture requires sending source code to a cloud inference endpoint.
- Controlled Unclassified Information· CUI
- Controlled Unclassified Information is unclassified but sensitive information that requires safeguarding under government-wide policies (Executive Order 13556). CUI categories include privacy, proprietary business information, critical infrastructure, and law enforcement information. CUI handling is governed by NIST 800-171 in nonfederal systems and CMMC 2.0 in DoD supply chain contracts.
- Controlled environment
- A controlled environment in this context refers to any computing environment with strict policy restrictions on data egress, model access, or third-party software use. This includes classified environments, air-gapped enclaves, environments processing CUI or ePHI, and regulated commercial environments (HIPAA, PCI-DSS High Compliance) where source code or sensitive data cannot leave the organization's boundary.
AI Coding and LLM Security
Terms describing AI-assisted software development, large language models in production, and the security implications of agentic AI systems.
- LLM· Large Language Model
- A Large Language Model is a neural network trained on large text corpora to predict token sequences. Modern LLMs (Claude, GPT, Gemini, Llama) have hundreds of billions of parameters and exhibit emergent capabilities in code generation, reasoning, and tool use. Frontier LLMs are typically accessed via cloud APIs, which is incompatible with classified and most air-gapped environments. Locally hosted open-source LLMs (Llama, Mistral, DeepSeek, Qwen) preserve confidentiality at the cost of capability.
- Agentic AI
- Agentic AI describes systems where an LLM is given tools (shell access, file editing, API calls), memory, and a goal, then autonomously plans and executes multi-step tasks toward that goal. Agentic systems can call tools repeatedly, branch on results, and operate across long time horizons. They introduce a new vulnerability class: the agent's tool invocations may reflect adversarial input from any context source it consumed.
- Prompt injection
- Prompt injection is an attack class in which an adversary embeds instructions in content that an LLM consumes (a fetched web page, a document, an email body, a database row). The LLM treats the injected text as instructions from a user, potentially overriding system prompts or guardrails. In agentic systems where the LLM has tool access (shell, code execution, API calls), successful prompt injection behaves functionally like remote code execution. Defense requires output validation at tool boundaries and treating LLM decisions as untrusted input rather than trusted control flow.
- AI code generation security
- AI code generation security is the discipline of analyzing and remediating vulnerabilities in LLM-produced code. Published benchmarks (SusVibes, SecurityEval) consistently find that LLM-generated code passes functional tests at high rates while failing security tests at high rates. The SusVibes Benchmark (CMU, Columbia, Johns Hopkins, December 2024) reported that 82.8% of functionally correct LLM solutions contained exploitable vulnerabilities. The implication is that AI coding tools must be paired with security scanning, not replace it.
- Zero code egress
- Zero code egress is an architectural property of developer tools that guarantees source code never leaves the developer's machine or organizational boundary. It is required for classified environments, FedRAMP High systems, and most healthcare and financial development. Achieving zero code egress with AI features requires local inference (the model runs on local hardware) or on-premise model hosting (the model runs on customer-controlled servers).
Citation note: These definitions are written by the Deva Security Team and are intended for use as references. Cite as "DevSecCode, Inc. Glossary, 2026" or link directly to the term anchor (for example, /glossary#cwe). Corrections welcome.