Merge pull request #39 from mmorana1/patch-12

Update 2.2_Appendix_E.md

Document/content/2.2_Appendix_E.md

@@ -1,20 +1,17 @@
 # Appendix E: SAIF AI Threat Targeted Components & CVEs/CWEs 
 
-The purpose of this appendix is to provide pen testers with a detailed tech stack of the targeted SAIF component and sub-components of the AI architecture, whether it be user inputs, the model layer, supporting infrastructure, or data sources and CVEs/CWEs that can be exploited by the AI threats targeting these components and sub-components. During test scoping, the tester determines which components and sub-components of the AI application are in scope for testing. For example, user input through a Slack bot connected to a FastAPI backend may be included, while certain external APIs might be excluded. The tester then can cross-reference the **Tech Stack** column of the mapping table to understand exactly which frameworks and services are deployed, such as FastAPI, Redis, or Pinecone, and uses this knowledge to conduct specific tech-stack aware pen tests. This is a step by step process.
+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. Once the components in scope versus out of scope are identified, 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 implementation.
+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, misconfigurations, or exploitable services, the first step is threat enumeration and CVE exploit-path mapping — i.e., inventory known CVEs against the tech stack, identify likely attack paths, and prioritize those paths for validation with scanners and proof-of-concept testing. 
 
-The first step is **Threat enumeration and CVE exploit path mapping**. The CVE column provides known vulnerabilities that can be validated with scanners (like Nessus or Nuclei) or manual proof-of-concept scripts. For instance, Redis in the data storage layer may expose `CVE-2022-0543` (Lua sandbox escape), which could be exploited to poison embeddings and trigger runtime data poisoning (`T01-RMP`). Similarly, an outdated Confluence instance may expose `CVE-2021-22911`, leading to sensitive information disclosure (`T01-SID`) if training data leaks from a knowledge base. By tying each CVE to an AI-specific threat, the pen tester demonstrates not only a technical flaw but also its effect on model behavior and trustworthiness.
+To help with this first step we provide an example of **Threat enumeration and CVE exploit path mapping** as example. 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, including Falco or eBPF-based detectors, provide additional evidence of exploitability in live environments. For example, a Redis instance used in the data storage layer may expose CVE-2022-0543 (Lua sandbox escape), which could be exploited to poison embeddings and trigger runtime data poisoning (T01-RMP). 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 Airflow that might be used in a LLM to orchestrate the flow of data from raw or external sources (APIs, databases, or files) into embeddings, training corpora, or retrieval indexes (like Pinecone or Weaviate). This CVEs ould be exploited not just for remote code execution but for `T01-DMP` (data poisoning), corrupting training or retrieval data.  By mapping each CVE in the AI application tech stack to the specific AI threat it enables, the pen tester does more than record a vulnerable component they show how that vulnerability can be weaponized against the AI system. This turns a routine CVE finding into a clear attack path that explains the practical impact on model behavior, data integrity, confidentiality, or availability.
 
-Once vulnerabilities are identified, they are mapped to AI-specific threats using the **AI Threats** column. This is where the table delivers unique value: it bridges traditional software flaws with AI-centric risks. 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, weaknesses in an Airflow ETL pipeline (`CVE-2022-40127`) could be exploited not just for remote code execution but for `T01-DMP` (data poisoning), corrupting training or retrieval data. This mapping ensures testers move beyond “server RCE” reports and instead demonstrate AI model compromise impacts.
+The tester can follow a systematic AI pen-testing workflow: for each SAIF component in scope they 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. For example, exploiting a Weaviate plugin path-traversal vulnerability (CVE-2023-41267) could let an attacker inject poisoned vectors, producing T01-RMP runtime data poisoning where the chatbot serves attacker-controlled facts. A pen test report could leverage the table "Threat enumeration and CVE exploit path mappings" to maintain **traceability** of vulnerabilities and their impact. A finding might read: “Redis vulnerable to `CVE-2022-0543`,” which maps to `CWE-94` (code injection) and aligns with AI Threat `T01-RMP` (runtime data poisoning). The impact statement would explain that this weakness allows the chatbot to output attacker-controlled responses. 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.
 
-With this foundation, the tester moves into a **systematic execution strategy**. For each SAIF component, they review the subcomponents to see where injection, poisoning, or manipulation is possible. They verify which technologies are actually deployed and run tests to identify CVEs that can be exploited due to vulnerable and un-patched libraries/components. They then simulate attack driven tests for AI-specific threats such as prompt injection, model inversion, membership inference, poisoning attacks, or runtime denial of service. For example, in the case of data storage infrastructure (SAIF component 15), a vulnerable CVE in Weaviate instance could be targeted. A known plugin path traversal vulnerability (`CVE-2023-41267`) may allow the attacker to inject poisoned vector entries, resulting in `T01-RMP` runtime data poisoning where the chatbot retrieves manipulated facts.
-
-Reporting leverages the table’s structure to maintain **traceability**. A finding might read: “Redis vulnerable to `CVE-2022-0543`,” which maps to `CWE-94` (code injection) and aligns with AI Threat `T01-RMP` (runtime data poisoning). The impact statement would explain that this weakness allows the chatbot to output attacker-controlled responses. 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 step is to conduct a **Threat enumeration and CWE exploit path mapping**. The CWE-based table adds another layer by 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 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. 
 
 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 systems, 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 test harness — a fusion of exploit paths, systemic weaknesses, AI threats, and design-level fixes — that supports secure design, ongoing validation, and resilience in AI-enabled systems.
+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.
 
 ## AI Threat enumeration and CVE exploit path mapping