diff --git a/Document/content/2.2_Appendix_E.md b/Document/content/2.2_Appendix_E.md index d115d7d..8b1ce03 100644 --- a/Document/content/2.2_Appendix_E.md +++ b/Document/content/2.2_Appendix_E.md @@ -1,14 +1,12 @@ # Appendix E: SAIF AI Threat Targeted Components & CVEs/CWEs -This appendix is intended to guide penetration testers by showing how common CVEs and CWEs map to AI-specific threats across the SAIF-defined components of an AI architecture. CVEs typically correspond to vulnerabilities in the technology stack—libraries, frameworks, APIs, and services—that implement user interfaces, the model layer, supporting infrastructure, or data sources. Because the AI pen tests of these guide are meant to be performed against an existing application, it is essential that testers perform careful scoping up front: identify which SAIF components and subcomponents are in scope, enumerate the actual technologies deployed for each, and use that inventory to prioritize CVE/CWE enumeration and threat simulations. For example, components directly involved in the AI application’s operation—such as the chat interface, FastAPI backend, model orchestration logic, and connected data stores—should be considered in scope for penetration testing. In contrast, external or third-party services not owned or controlled by the organization, such as vendor APIs or external data feeds, are typically out of scope, as they fall outside the AI application’s trust boundary and control. +This appendix guides penetration testers on translating discovered CVEs and CWEs into AI-specific threats and concrete test cases mapped against the SAIF components of an AI architecture. CVEs generally point to vulnerabilities in the underlying technology stack — libraries, frameworks, APIs, and services that implement user interfaces, model layers, supporting infrastructure, or data sources. Because the pen tests described here target a live application, careful scoping is essential: testers must first identify which SAIF components and subcomponents are in scope, enumerate the exact technologies deployed for each, and use that inventory to prioritize CVE/CWE enumeration and threat simulations. In-scope items commonly include components owned or operated by the organization and directly involved in the request→response flow — for example, chat UIs, API backends (e.g., FastAPI), session/orchestration layers, model orchestration frameworks (e.g., LangChain or LlamaIndex), vector stores (Redis, Pinecone, Weaviate), ETL/data pipelines, model-serving endpoints, and internally managed connectors. Because these components can contain outdated, misconfigured, or otherwise exploitable dependencies, the first operational step is threat enumeration: map each in-scope SAIF component to its tech stack, identify relevant CVEs (and corresponding CWEs), and derive likely exploit paths. That mapping then drives focused validation with scanners, SCA tools, and proof-of-concept testing so testers can prioritize, reproduce, and demonstrate how conventional software flaws translate into AI-centric impacts. -Once the components in scope versus out of scope for testing are identified and agreed, the next step is to build or reference an inventory of the technology stack used to develop and operate those components. This inventory ensures that testing activities are precise and aligned with the actual implementations. For example, in-scope components typically include those owned or managed by the organization and directly involved in the application’s request–response flow, such as the chat interface, API backends (e.g. FastAPI), session and orchestration layers, model orchestration frameworks (e.g. LangChain or LlamaIndex), vector databases (e.g. Redis, Pinecone, Weaviate), ETL and data processing pipelines, model-serving endpoints, and any internally managed connectors. Because the in-scope components may contain vulnerable libraries due to being outdated, misconfigured, or exploitable by the services used, the first step is threat enumeration and CVE exploit-path mapping, that is the inventory of known CVEs against the tech stack mapped to AI threats. This mapping also helps in identifing likely attack paths exploiting these vulnerabilities and prioritize those paths for validation with scanners and proof-of-concept testing. +To start, the tester performs **Threat enumeration and mappping of CVE exploit paths across the in-scope technology stack**. This begins with discovering known vulnerabilities using both SCA and runtime tools: software composition analyzers (Snyk, Trivy, Dependabot) reveal vulnerable dependencies and libraries, while network and host scanners (Nessus, Nuclei) validate active exposures in services and APIs. Runtime telemetry and host-level inspection add further evidence of exploitability in live environments where vulnerable components are installed and running. Identified CVEs are then translated into AI-specific risks using the AI Threats column: a web issue like a FastAPI sanitization flaw (CVE-2022-36067) becomes a direct prompt-injection vector (T01-DPIJ) when an LLM ingests tainted inputs, and an ETL or retrieval vulnerability such as CVE-2022-40127 can be leveraged to perform remote code execution or data corruption that manifests as data poisoning (T01-DMP) in a RAG pipeline. Mapping each CVE to the relevant AI threat converts a routine vulnerability finding into a concrete attack path, making it possible to explain and demonstrate the real impact on model behavior, data integrity, confidentiality, and availability. -To help with this first step, we provide an example of **Threat enumeration and CVE exploit path mapping**. To begin, the pen tester performs threat enumeration and CVE exploit-path mapping across the in-scope technology stack. This involves identifying known vulnerabilities using tools such as software composition analyzers (SCA) and runtime scanners. SCA tools like Snyk, Trivy, or Dependabot help reveal vulnerable dependencies and libraries, while scanners such as Nessus or Nuclei can validate active exposures in services and APIs. Runtime telemetry and host-level tools can also provide additional evidence of exploitability in live environments where vulnerable components/libraries are being installed and run. Once these CVEs/vulnerabilities are identified, they could be mapped to AI-specific threats using the **AI Threats** column. For example, FastAPI sanitization weaknesses (`CVE-2022-36067`) might appear to be routine web vulnerabilities, but in the context of an LLM they translate to `T01-DPJI` (direct prompt injection). Similarly, CVE-2022-40127 in a LLM or RAG-based application, affect the Apache Airf or retrieval indexes (like Pinecone or Weaviate). This CVEs ould be exploited for remote code execution and `T01-DMP` (data poisoning), corrupting training or retrieval data. By mapping each CVE in the AI application tech stack to the specific AI threats turns a routine CVE finding into a clear attack path that explains the practical impact of exploitation of the CVE on AI Application being this altering the LLM model behavior or impacting the data integrity, confidentiality, or availability. +For each SAIF component in scope, the tester inspects subcomponents to identify where injection, poisoning, or manipulation are possible, confirms the actual technologies deployed, and runs tests to discover vulnerable or unpatched libraries and CVEs. Those technical findings then drive simulations of AI-specific attacks for example prompt injection, model inversion and membership inference, data poisoning, and runtime DoS, so the tester can demonstrate real impact on the application and its model behavior. Pen test reports should use the “Threat enumeration and CVE exploit-path mappings” table to preserve traceability between vulnerabilities and AI impacts. The mapping lets a tester convert a conventional software finding into a concrete AI attack path and explain how exploitation affects data integrity, confidentiality, availability, or model trust. For example, Redis used in SAIF #4 Application Layer for session caching, API state management, and job queues was found vulnerable to CVE-2022-0543, which can lead to multiple AI-specific risks: data leakage (T01-SID), model disruption (T01-DoSM), and model manipulation (T01-MTD). In short, a single Redis compromise can escalate from infrastructure-level control to sensitive information exposure and altered AI behavior, undermining the system’s integrity and trust. Findings like this should clearly link the vulnerability to relevant CWEs, mapped AI threats, exploit paths, and reproducible validation steps so both security and AI teams can remediate effectively. -The AI pen-tester can follow a systematic AI pen-testing workflow by following this guidance: for each SAIF component in scope, inspect subcomponents to identify where injection, poisoning, or manipulation are possible, confirm the actual technologies deployed, and run tests to discover vulnerable or unpatched libraries and CVEs. Those findings drive simulations of AI-specific attacks for example prompt injection, model inversion and membership inference, data poisoning, and runtime DoS, to demonstrate real impact on the application. A pen test report could leverage the table of "Threat enumeration and CVE exploit path mappings" to maintain **traceability** of vulnerabilities and their impacts. A finding might read: Redis, used in SAIF #4 –Application Layer for session caching, API state management, and job queue orchestration, was found vulnerable to CVE-2022-0543 (Lua sandbox escape). This vulnerability could allow remote code execution within the application’s runtime environment, potentially leading to session hijacking, data manipulation, or further compromise of other in-scope components. Redis used in SAIF #4 Application Layer fo session caching, API state management, job queues is found vulnerable to `CVE-2022-0543`,” which maps to three primary AI-specific threats under SAIF: T01-SID (Sensitive Information Disclosure), where attackers can extract cached API tokens or user session data; T01-DoSM (Denial of Service – Model), where cache corruption or overload disrupts model inference and orchestration; and T01-MTD (Model Tampering/Disclosure), where manipulation of stored orchestration or metadata alters model behavior or exposes internal details. In essence, a single Redis compromise can cascade from infrastructure-level control to data leakage, service disruption, and model manipulation, undermining the integrity and trust of the AI application. This creates a clear chain from vulnerability to exploit to AI-specific risk, making the report resonate with both security engineers and AI/ML practitioners. - -The second reccomended step is to conduct a **Threat enumeration and CWE exploit path mapping**. CWE-based enumeration is the bridge between patch-centric security and resilient AI system design. For pen testers, converting technical findings into CWE classes clarifies attacker goals, enables broader test coverage, and produces remediation guidance that hardens architecture — not only one vulnerable library — against the class of attacks that threaten AI applications. The CWE-based table helps the pen tester in framing these vulnerabilities/findings as **design weaknesses**, not just CVEs that need patching. For example, `CWE-20` (improper input validation) points to weak parsing logic, `CWE-276` (incorrect default permissions) highlights misconfigurations in data storage or S3 buckets, and `CWE-345` (insufficient verification of data authenticity) shows systemic flaws in RAG ingestion. +The second recommended step is to perform a **Threat enumeration and CWE exploit-path mapping** This step transforms vulnerability-centric testing into design-level assurance. By classifying findings under CWE categories, the pen tester bridges the gap between patch management and resilient AI architecture. CWE mapping clarifies attacker objectives, expands test coverage beyond isolated CVEs, and guides remediation that strengthens entire system layers rather than individual components. The CWE-based table reframes technical flaws as architectural weaknesses, for instance, CWE-20 (Improper Input Validation) exposes weak parsing logic, CWE-276 (Incorrect Default Permissions) reveals insecure defaults in data storage such as S3 buckets, and CWE-345 (Insufficient Verification of Data Authenticity) uncovers trust and integrity flaws in RAG ingestion. This approach helps testers not only find where AI applications break, but also understand why they break and how to redesign them to resist future exploitation. Finally, the third step is to look at **AI Threats, Targeted CWEs and Provide Recommendations to Fix Them** in the Pen Testing Report. CWEs being targeted by a threat needs to be accompanied by secure design recommendations, such as enforcing schema validation, disabling default public access, verifying dataset authenticity, or encrypting sensitive data. This means pen testers can move from “here is how I broke it” to “here is how you should redesign it to prevent recurrence.” As pen testers revisit AI systems/application in scope for testing as these mighr change, they can update the CVE and CWE of newly discovered vulnerabilities and use the AI Threats column as a checklist for attack simulations in future red-team exercises. Over time, this evolving matrix becomes a living document that supports secure design, ongoing validation, and resilience in AI-enabled systems.