跳到正文
DEV Community· HM Shihabuddin Jashory·· 3 小時前AI 評分64

HM Shihabuddin Jashory 的 8 層自主智能體安全架構如何在 NASA 飛行軟件及 Google Cloud 生態系統中發現經核實的漏洞

How My 8-Layer Autonomous Agentic Security Architecture Found Validated Vulnerabilities in NASA Flight Software and Google Cloud Ecosystems

AI 導讀

HM Shihabuddin Jashory 以其 8 層自主智能體安全架構審核開源基礎設施，促成 NASA F´ 官方修補，並向 Google VRP 提交漏洞披露。

正文

TL;DR

Most automated security scanners drown maintainers in theoretical alerts and false positives. Over the past year, I designed and deployed an 8-Layer Autonomous Agentic Security Architecture (DOI: 10.5281/zenodo.23832719) built around a simple premise: every security patch is a map to the bugs that were missed right next to it.

By combining a 4-Tier Multi-Agent Verification Hierarchy with a specialized Sibling Patch-Gap Engine, this architecture systematically audited mission-critical open-source infrastructure—resulting in:

  • Official upstream security remediation in NASA's F´ (nasa/fprime) spacecraft flight software framework (PR #6299, opened by NASA JPL F´ Cybersecurity Lead @bitWarrior from GHSA-pq8v-c63j-wv29).
  • Two Priority P2 triaged disclosures in Google Vulnerability Reward Program (Google VRP) (Issue #580130935 and Issue #580032520, among 10 active Google VRP disclosures).
  • 25 coordinated private security disclosures (GHSA / VDP) across NASA (nasa/fprime, nasa/fprime-gds, nasa/CryptoLib, nasa/spacewasm, nasa/openmct, nasa/earthdata-search, nasa/harmony), the Space Telescope Science Institute (spacetelescope/jwql for the James Webb Space Telescope), Google (google/adk-*, google-gemini/gemini-cli, googleapis/mcp-toolbox, cdapio/cdap, genkit-ai/genkit, firebase/firebase-tools, google/osv-scalibr, angular/angular-cli, google/oss-fuzz), Bazel (bazelbuild/bazel-central-registry), ChromeDevTools (ChromeDevTools/chrome-devtools-mcp), Anthropic (modelcontextprotocol/inspector, modelcontextprotocol/servers), and Cloudflare (cloudflare/workers-sdk).

Here is an inside look at the architecture, why Sibling Patch-Gap Analysis works so reliably on hardened codebases, and how multi-agent verification eliminates the "AI slop" crisis in security research.

1. The Core Problem: Why Static Scanners Miss High-Severity Bugs—and Why "AI Reports" Fail Maintainers

Traditional SAST tools rely on fixed syntactic rules. When they scan a million-line C++ flight software repository or a distributed TypeScript cloud SDK, they flag thousands of low-impact patterns while completely missing domain-specific trust boundary violations.

Conversely, first-generation LLM bug-hunting scripts hallucinate attack paths that cannot actually execute because they never compile the target, never inspect runtime state, and never verify whether an upstream reverse proxy or caller already sanitizes the input.

When I architected the 8-Layer Autonomous Agentic Security Architecture (DOI: 10.5281/zenodo.23832719), I enforced two strict engineering invariants:

  1. Zero Unverified Claims: No finding can leave the pipeline without a deterministic, benign local reproduction test and a clean, minimal git diff remediation patch.
  2. 4-Tier Chain-of-Command Accountability (Worker -> Supervisor -> Chief Auditor -> Tier-0 System Integrator): Every agent tier audits the raw source code, execution logs, and patch diffs of the tier below it before a disclosure is ever drafted. 
+-------------------------------------------------------------------------+
| Tier-0: System Integrator (SI)                                          |
| Final cross-check of source code, benign PoC output, and git diff patch |
+-------------------------------------------------------------------------+
                                    ^
                                    |
+-------------------------------------------------------------------------+
| Tier-1: Chief Auditor                                                   |
| Adversarial review: attempts to disprove exploitability & check guards  |
+-------------------------------------------------------------------------+
                                    ^
                                    |
+-------------------------------------------------------------------------+
| Tier-2: Supervisor Agent                                                |
| Orchestrates target scope, CWE taxonomy, and sibling commit graph audit |
+-------------------------------------------------------------------------+
                                    ^
                                    |
+-------------------------------------------------------------------------+
| Tier-3: Specialized Worker Agents                                       |
| Shallow clone, AST/dataflow trace, benign local harness & patch builder |
+-------------------------------------------------------------------------+

2. The Secret Weapon: The "Sibling Patch-Gap Engine"

When a security team patches a vulnerability (CVE or GHSA), human engineers naturally focus on the exact file, function, or branch reported in the advisory. However, large engineering repositories rarely implement a pattern only once:

  • If an HTTP client forwards sensitive headers across cross-origin redirects in one transport module, a sibling streaming or proxy module often shares the same flaw.
  • If a path-traversal check is hardened using filepath.Rel() or Path.resolve() in one handler, a sibling handler—or a v2 rewrite branch—often misses the edge case (such as trailing separator absence, Windows volume-relative paths, or Git worktree alternates).
  • If an integer overflow or buffer calculation is fixed in one POSIX file wrapper, the adjacent checksum or memory-allocation helper in the same subsystem often retains the uncast 32-bit arithmetic.

How the Sibling Patch-Gap Engine Works

Instead of scanning codebases blindly from scratch, the engine executes a 4-stage loop:

  1. Security Commit & Advisory Ingestion: The engine queries recent security advisories (GHSA/CVE) and hardening commits (fix(security):, Harden ..., Validate ..., Escape ...) across target repositories.
  2. Semantic Guard Extraction: It extracts the exact mathematical or structural predicate introduced by the fix—for example:
    • Before fix: target.startswith(base_dir)
    • After fix: Path(target).resolve().is_relative_to(Path(base_dir).resolve())
  3. Sibling Call-Site & Cross-Branch Mapping: It searches the entire repository (and active release branches) for:
    • Other call sites of the same sink (execFileSync, os.Open, git.Repo, fetch redirect handlers).
    • Partially applied validations within the same patched function (e.g., validating the primary repository root while overlooking sub-paths or linked worktree pointers).
  4. Benign Boundary Verification & Patch Synthesis: A Worker agent builds an isolated test in a temporary directory, proves whether the guard can be bypassed with benign inputs, and writes the exact remediation git diff.

3. Case Study 1: NASA Flight Software (nasa/fprime Official Fix PR #6299)

F´ (F Prime) is NASA Jet Propulsion Laboratory's (JPL) flight-proven software framework used for spacecraft, CubeSats, and instruments (including the Mars Helicopter Ingenuity heritage ecosystem).

In earlier security hardening (PR #5320 and PR #5850), NASA introduced Os::SandboxedFile to enforce strict directory containment for flight file operations across components such as Svc/FileUplink, Svc/FileDownlink, and Svc/FileManager.

The Sibling Patch-Gap (CWE-22 — Missing Os::SandboxedFile in Svc/CmdSequencer)

Using the Sibling Patch-Gap Engine, our architecture mapped every component in nasa/fprime that opens flight files by path and compared their Os::File declarations against the Os::SandboxedFile migration:

  • While FileUplink, FileDownlink, and FileManager had been migrated to Os::SandboxedFile, the mission-critical command sequence loader in Svc/CmdSequencer (Svc/CmdSequencer/FPrimeSequence.hpp:237 and Svc/CmdSequencer/FPrimeSequence.cpp:373-449) still instantiated a raw, unsandboxed Os::File m_sequenceFile;.
  • Consequently, sequence validation and execution (CmdSequencerImpl::validate / CS_VALIDATE / CS_RUN) bypassed the Os::SandboxedFile containment layer.

Upstream Validation & Resolution

We reported the root cause along with a clean, flight-code-compliant remediation patch via GitHub Private Vulnerability Reporting (GHSA-pq8v-c63j-wv29).

Following that validation, our engine expanded across NASA's broader flight and ground-data software portfolio, submitting verified defensive reports with ready-to-merge patches for:

  • NASA F´ Ground Data System (nasa/fprime-gds — GHSA-rm58-f49w-5c3g), NASA CCSDS Flight CryptoLib (nasa/CryptoLib — GHSA-pfm4-7hrj-24jp), and NASA SpaceWasm (nasa/spacewasm — GHSA-3p2g-79q9-39cr).
  • NASA OpenMCT (nasa/openmct — GHSA-mhv6-5g6q-c4jg), NASA Earthdata Search (nasa/earthdata-search — Issue #2111), and NASA Harmony (nasa/harmony — Issue #995).
  • Space Telescope Science Institute (spacetelescope/jwql — Issue #1809), supporting the James Webb Space Telescope (JWST) Quicklook pipeline.

4. Case Study 2: AI Agent Toolchains & Developer SDKs (Google, Anthropic, Cloudflare)

As AI agent protocols (MCP / Model Context Protocol) and cloud CLIs (genkit, firebase-tools, wrangler) rapidly adopt local HTTP servers, OAuth callbacks, and Git workspace inspection, they introduce subtle cross-boundary vulnerabilities.

Using the Sibling Patch-Gap Engine, we uncovered a recurring class of vulnerabilities across flagship developer tools:

Pattern A: Incomplete Fix in Git Repository Boundary Validation

When an AI tool or CLI validates that a directory is a legitimate Git repository inside an allowed workspace, checking Path(repo).resolve() is not enough if the underlying Git library reads <common_dir>/objects/info/alternates or if linked Git worktrees (git worktree add) cause git_dir and common_dir boundary sets to diverge. Because Git follows objects/info/alternates transparently during object reads (git show, git diff), an attacker-controlled .git metadata directory inside an allowed workspace can point its object store to another repository outside the workspace without using a single filesystem symlink.

Pattern B: Argument Injection (CWE-88) Surviving Command-Injection Fixes

When developers fix shell command injection (CWE-78) by replacing execSync("git ... " + userArg) with execFileSync("git", ["show", "-s", "--format=%B", userArg]), they eliminate shell metacharacter expansion. However, if userArg is not preceded by an end-of-options delimiter (--) or validated against a strict hex-SHA regex, passing --output=<path> as userArg turns git show or git diff into an arbitrary file-write primitive (CWE-88).

Pattern C: Cross-Origin Redirect Header Leakage (CWE-200)

When a CLI or SDK attaches Authorization: Bearer <token> or x-goog-api-key to an initial HTTPS request and relies on standard fetch(..., { redirect: "follow" }), standard runtime fetch implementations forward custom headers—or preserve POST bodies across 307/308 redirects—to cross-origin redirect targets unless headers are stripped on a redirect: "manual" hop check.

5. Key Takeaways for Security Engineers and Maintainers

  1. Audit Every Security Patch for Sibling Call Sites: Whenever you merge a security fix, treat the fix commit as a query template. Search your entire monorepo—and every active release branch (v1, v2, next)—for sibling functions that share the same architectural assumption.
  2. Use -- (End-of-Options) Everywhere in Subprocess Arrays: Replacing execSync with execFileSync or spawn stops shell injection (CWE-78), but it does not stop argument injection (CWE-88). Always pass -- before positional refs or paths, or validate refs against /^[0-9a-fA-F]{7,64}$/.
  3. Never Trust .git Metadata Inside Untrusted Archives or Workspaces: Even if every file and symlink inside .git/ resolves within an allowed directory, plain-text Git configuration (core.fsmonitor, core.sshCommand, diff.external) and .git/objects/info/alternates can cross directory boundaries or execute commands when standard git subcommands run.
  4. Defensive Disclosures Should Always Ship With a Patch: Maintainers are stretched thin. Submitting a concise root-cause analysis paired with a minimal, test-backed git diff turns a stressful triage ticket into a 5-minute code review.

About the Author

HM Shihabuddin Jashory (Shihab) (@jashory) is a security researcher, systems architect, and founder of Vision Flow, specializing in autonomous multi-agent verification systems, supply-chain security, and mission-critical software auditing.

來源：DEV Community · dev.to

#教學/實踐#Agent#MCP/工具調用#Google#Anthropic