Merge pull request #205 from KeygraphHQ/keygraphVarun-patch-4

Update README.md

README.md

@@ -1,5 +1,5 @@
 >[!NOTE]
-> **[📢 New: AWS Bedrock, Google Vertex AI support now available →](https://github.com/KeygraphHQ/shannon/discussions/categories/announcements)**
+> **[📢 New: Claude models on AWS Bedrock and Google Vertex AI now supported. →](https://github.com/KeygraphHQ/shannon/discussions/categories/announcements)**
 
 <div align="center">
 
@@ -14,7 +14,7 @@ It analyzes your source code, identifies attack vectors, and executes real explo
 
 ---
 
-[Keygraph Website](https://keygraph.io) • [Documentation](https://docs.keygraph.io) • [Announcements](https://github.com/KeygraphHQ/shannon/discussions/categories/announcements) • [Discord](https://discord.gg/KAqzSHHpRt)
+[Keygraph Website](https://keygraph.io) • [Announcements](https://github.com/KeygraphHQ/shannon/discussions/categories/announcements) • [Discord](https://discord.gg/KAqzSHHpRt)
 
 ---
 </div>
@@ -59,7 +59,7 @@ Shannon is developed by [Keygraph](https://keygraph.io) and available in two edi
 
 | Edition | License | Best For |
 |---------|---------|----------|
-| **Shannon Lite** | AGPL-3.0 | Security teams, independent researchers, testing your own applications. |
+| **Shannon Lite** | AGPL-3.0 | Local test testing of your own applications. |
 | **Shannon Pro** | Commercial | Organizations needing a single AppSec platform (SAST, SCA, secrets, business logic testing, autonomous pentesting) with CI/CD integration and self-hosted deployment. |
 
 > **This repository contains Shannon Lite,** the core autonomous AI pentesting framework. **Shannon Pro** is Keygraph's all-in-one AppSec platform, combining SAST, SCA, secrets scanning, business logic security testing, and autonomous AI pentesting in a single correlated workflow. Every finding is validated with a working proof-of-concept exploit.
@@ -88,7 +88,7 @@ The same multi-agent pentest pipeline as Shannon Lite (reconnaissance, parallel
 
 **Static-Dynamic Correlation**
 
-This is the core differentiator. A data flow vulnerability identified in static analysis (e.g., unsanitized input reaching a SQL query) is not reported as a theoretical risk. It is fed to the corresponding exploit agent, which attempts to exploit it against the live application. A business logic invariant violation (e.g., missing cross-tenant authorization) is routed to the Authz agent for runtime confirmation. Confirmed exploits are traced back to the exact source code location, giving developers both proof of exploitability and the line of code to fix.
+This is the core differentiator. A data flow vulnerability identified in static analysis (e.g., unsanitized input reaching a SQL query) is not reported as a theoretical risk. It is fed to the corresponding exploit agent, which attempts to exploit it against the live application. Confirmed exploits are traced back to the exact source code location, giving developers both proof of exploitability and the line of code to fix.
 
 **Deployment Model**
 

SHANNON-PRO.md

@@ -30,7 +30,7 @@ The static analysis stage performs comprehensive code-level security assessment
 
 ## SAST: Data Flow Analysis
 
-Shannon Pro transforms the target codebase into a Code Property Graph (CPG) that combines the abstract syntax tree, control flow graph, and program dependence graph into a unified structure. Nodes represent AST elements (expressions, statements, declarations) and edges capture AST relationships, control flow, and data dependence. The analysis proceeds in three phases.
+Shannon Pro transforms the target codebase into a Code Property Graph (CPG) that combines the abstract syntax tree, control flow graph, and program dependence graph into a unified structure. Nodes represent program constructs (such as expressions, statements, and declarations), and edges capture syntactic, control-flow, and data-dependence relationships. The analysis proceeds in three phases.
 
 ### Phase 1: Source and Sink Extraction
 
@@ -74,9 +74,9 @@ Shannon Pro's business logic security testing operates in four phases:
 
 **Phase 2: Fuzzer Generation.** For each discovered invariant, a second agent generates a targeted fuzzer: a test scenario designed to violate the invariant. These are not random inputs. The agent reads the code, understands the expected authorization checks (or lack thereof), and constructs specific adversarial scenarios. For an authorization invariant, the fuzzer might construct a request where a user from one organization references a resource belonging to another organization. For a state machine invariant, it might craft a sequence of API calls that skips a required approval step.
 
-**Phase 3: Violation Detection.** The generated fuzzers are executed against the codebase (statically, through code path analysis, or dynamically when correlated with the pentest pipeline). When a fuzzer succeeds, meaning the invariant does not hold, the system has identified a confirmed business logic vulnerability. The agent traces the violation back to the specific code location where the missing check or flawed logic exists.
+**Phase 3: Violation Detection.** The generated fuzzers are executed against a stubbed test environment that replicates the application's business logic with mocked dependencies. When a fuzzer succeeds, meaning the invariant does not hold, the system has identified a confirmed business logic vulnerability. The agent traces the violation back to the specific code location where the missing check or flawed logic exists.
 
-**Phase 4: Exploit Synthesis.** For every confirmed violation, the system produces a full proof-of-concept exploit with step-by-step reproduction instructions, the specific API calls or user actions required, the observed versus expected behavior, and the security impact. When correlated with the dynamic testing pipeline, these exploits are validated against the running application to confirm real-world exploitability.
+**Phase 4: Exploit Synthesis.** For every confirmed violation, the system produces a full proof-of-concept exploit with step-by-step reproduction instructions, the specific API calls or user actions required, the observed versus expected behavior, and the security impact.
 
 ### Real-World Example: Cross-Tenant Data Access (CWE-639)
 
@@ -84,7 +84,7 @@ In a production multi-tenant platform, Shannon Pro's business logic security tes
 
 **Invariant discovered:** Document access must verify that the document belongs to the requesting user's organization.
 
-**Fuzzer generated:** The agent identified that the `GetDocument` endpoint in `document_handler.go` retrieves documents by ID from the database but never validates that the document's `organization_id` matches the authenticated user's `organization_id` before returning the response.
+**Fuzzer generated:** The agent extracted the `GetDocument` handler logic into a stubbed test environment, mocking the database layer to return documents with known organization IDs. The fuzzer generated combinations of requesting user organizations and document owner organizations, testing whether the handler enforces organizational boundaries.
 
 **Violation confirmed:** An attacker from Organization B can access documents belonging to Organization A by calling the `GetDocument` endpoint with the victim's document ID, without any authorization check preventing cross-organization access.
 
@@ -241,7 +241,7 @@ Shannon is offered in two editions to serve different operational needs:
 | **Integration** | Manual / CLI | Native CI/CD, GitHub PR scanning, enterprise support, self-hosted runner |
 | **Deployment** | CLI / manual | Managed cloud or self-hosted runner (customer data plane, Keygraph control plane) |
 | **Boundary Analysis** | N/A | Automatic service boundary detection with team routing |
-| **Best For** | Independent research and testing | Enterprise application security posture management |
+| **Best For** | Local testing of own applications | Enterprise application security posture management |
 
 ---