[EPIC] Aerospace Compliance & Enterprise Integration

[squid-protocol]

Epic: Aerospace Compliance & Enterprise Integration

Target Branch: feature/aerospace-compliance-sarif
Objective: Evolve GitGalaxy from a structural static analysis tool into a compliance-ready, air-gap native DevSecOps platform tailored for highly regulated sectors (Aerospace, Defense, FinTech, and MedTech).

Strategic Imperative: Traditional AST-based static analysis is buckling under the weight of massive, polyglot enterprise repositories. In the defense sector, requiring legacy 1970s compilers just to assess code risk is a non-starter. This epic outlines the architectural roadmap to bypass compilers entirely. By extracting Structural Signatures, establishing strict mathematical liability floors, and leveraging Domain-Specific Ontologies, GitGalaxy will evaluate entire repositories in milliseconds. It provides deep, actionable telemetry on every file, maps the precise flow of information across complex architectures, and seamlessly integrates these insights into standard CI/CD pipelines via OASIS-compliant SARIF outputs—tailored exactly to the security and compliance requirements of the engineering team.

Implementation Strategy (Evolution through Integration): GitGalaxy’s core extraction engines, database recorders, and network topology mappers are already battle-tested and fully operational. Rather than building compliance tools from scratch, a major focus of this epic is seamlessly integrating these existing powerhouses directly into the main galaxyscope.py orchestrator. We are unlocking the engine to provide a frictionless, single-binary execution path for enterprise CI/CD pipelines.

Phase 1: The Defense Primitives (Language Dictionaries)

Goal: Extract the Structural Signatures of legacy and modern safety-critical aerospace languages. By executing these signature definitions natively within the existing language_standards.py engine, we completely eliminate the need for functioning toolchains, allowing instant security audits on decades-old infrastructure.

1. language_standards.py Updates

• Action: Inject the following new language dictionaries into the optical matrix. Ensure they adhere to the standard_block or hybrid_dash patterns, appropriately mapping their unique syntax markers to prevent Catastrophic Backtracking (ReDoS).

Ada / SPARK (ada)

• Extensions: .adb, .ads, .ada

• Lexical Family: hybrid_dash (Uses -- for line comments, no native block comments historically).

• Key Structural Signatures:

  • safety: Strict typing (pragma, pragma Assert, type ... is range). Ada's superpower is compile-time safety. Tracking the density of these pragmas proves whether the code is actually leveraging SPARK's formal mathematical proofs.

  • api: Package specifications (package ... is).

  • structural_boundaries: procedure, function, begin, end.

JOVIAL (jovial)

• Extensions: .jov, .cpool

• Lexical Family: standard_block (Uses " or % for comments depending on the MIL-STD era, often block-like).

• Key Structural Signatures:

  • class_start: TABLE, ITEM declarations.

  • high_risk_execution: GOTO, FALLTHRU. Unstructured control flow in legacy military platforms (like the F-15 or B-52) is a massive indicator of tech debt rot.

  • memory_alloc: Manual memory overlays via OVERLAY.

VHDL (vhdl)

• Extensions: .vhd, .vhdl

• Lexical Family: line_exclusive (Uses -- for line comments).

• Key Structural Signatures:

  • class_start: entity, architecture.

  • concurrency: process, port map (hardware concurrency). Unlike software, hardware description languages execute concurrently by default. High concurrency density here maps the physical complexity of the FPGA logic gates.

  • io: in, out, inout port definitions.

CMS-2 (cms2)

• Extensions: .cms2, .cms

• Lexical Family: standard_block (Uses COMMENT ... $ block markers).

• Key Structural Signatures:

  • globals: SYS-DD (System Data Design).

  • structural_boundaries: PROCEDURE, EXEC.

  • Target Ecosystem: U.S. Navy Aegis Combat System legacy code. Providing instant visibility here bridges a 40-year generational knowledge gap for naval contractors.

Lustre / SCADE (lustre)

• Extensions: .lus

• Lexical Family: hybrid_dash (-- for lines, /* */ for blocks).

• Key Structural Signatures:

  • class_start: node.

  • state_mutation: pre (accessing previous state in synchronous dataflow), -> (initialization).

  • Target Ecosystem: Airbus fly-by-wire and European nuclear control systems. Capturing synchronous dataflow mutations provides unprecedented insight into European safety-critical systems.

CORAL 66 (coral66)

• Extensions: .cor

• Lexical Family: standard_block (Uses COMMENT ... ;).

• Key Structural Signatures:

  • high_risk_execution: GOTO.

  • inline_asm: CODE BEGIN ... CODE END.

  • Target Ecosystem: British MoD (Tornado, Sea Harrier) legacy systems.

AGC Assembly (agc_assembly)

• Extensions: .agc

• Lexical Family: line_exclusive (Uses # for line comments).

• Key Structural Signatures:

  • branch: TC, TCF, BZF (Transfer Control logic).

  • scientific: VAD, VSUB, DOT (Orbital navigation math routines).

  • Target Ecosystem: Apollo Guidance Computer digitized source files. Proves the engine can analyze the ultimate embedded edge-case.

PL/I (pli)

• Extensions: .pli, .pl1

• Lexical Family: standard_block (Uses /* */).

• Key Structural Signatures:

  • structural_boundaries: PROCEDURE, BEGIN, END.

  • memory_alloc: ALLOCATE, FREE.

  • Target Ecosystem: Legacy mainframe infrastructure and foundational segments of the International Space Station (ISS).

HAL/S (hals)

• Extensions: .hal

• Lexical Family: line_exclusive (Uses C in the first column, similar to legacy Fortran).

• Key Structural Signatures:

  • concurrency: SCHEDULE, WAIT, TERMINATE.

  • scientific: Built-in matrix and vector arithmetic blocks.

  • Target Ecosystem: Space Shuttle flight control software.

ATLAS (atlas)

• Extensions: .atl

• Lexical Family: line_exclusive (Uses C in the first column).

• Key Structural Signatures:

  • io: APPLY, MEASURE, VERIFY.

  • Target Ecosystem: U.S. Military Abbreviated Test Language for All Systems (Automated Test Equipment).

Phase 2: The Custom Ontology Engine (Cross-Industry Domain Auto-Binning)

Goal: Establish a Zero-Trust Ontology Map. This engine will dynamically cross-reference dependencies captured by the existing _dependency_capture sensors against a predefined knowledge base, instantly classifying the architectural domain of a file without running expensive, deep-inspection regex patterns.

1. gitgalaxy_config.py Updates

• Target: Create the CUSTOM_ONTOLOGY dictionary.

• Action: Define an expandable, cross-industry matrix mapping specific open-source packages and middleware to high-level Domain-Specific Ontologies.

• Implementation Schema:

  CUSTOM_ONTOLOGY = {
      "Aerospace & Robotics": {
          "Flight Dynamics & Simulation": {"jsbsim", "simulink", "gazebo", "mujoco"},
          "Avionics & Middleware": {"mavlink", "px4", "ardupilot", "uavcan", "rclcpp", "rclpy"},
          "Hardware Buses": {"mil_std_1553", "arinc429", "canbus", "socketcan"},
          "Kinematics & Control": {"eigen", "blaze", "armadillo", "casadi"}
      },
      "FinTech & HFT": {
          "Order Routing & FIX": {"quickfix", "aeron", "chronicle"},
          "Market Data Processing": {"kdb", "zeromq", "flatbuffers"},
          "Ledger & Cryptography": {"openssl", "secp256k1", "web3", "ethers"}
      },
      "MedTech & BioInformatics": {
          "Imaging & DICOM": {"dcmtk", "fo-dicom", "itk", "vtk"},
          "Genomic Sequencing": {"htslib", "biopython", "samtools"}
      }
  }

2. detector.py Updates (The Interception)

• Target: StructuralExtractor._dependency_capture

• Action: [NATIVE INTEGRATION] Intercept the array of raw captured dependencies already being generated by the engine. Iterate through the new CUSTOM_ONTOLOGY matrix in $O(1)$ time via set-intersections.

• Architectural Consequence: If a C++ file imports <mavlink.h>, it is immediately tagged with the Avionics & Middleware domain label in the telemetry dictionary. This bypasses the need for the engine to guess the file's purpose, providing executives with an instant, hyper-accurate architectural map based on its Domain-Specific Ontology.

3. llm_recorder.py & audit_recorder.py Updates

• Target: Report Generation Blocks

• Action: Surface the auto-binned ontology tags at the top of the Markdown and JSON reports.

• Downstream Impact: Instead of merely reporting "240 C++ Files," the LLM receives context stating: "Identified 42 files acting as Avionics Middleware, and 12 files managing Flight Dynamics. Assess the structural coupling between these two domains." This gives AI agents unprecedented situational awareness.

Phase 3: The MISRA Physics Engine (Compliance Exposure)

Goal: Establish the "Aerospace Determinism Index" to optically detect non-conformant Structural Signatures in C/C++ firmware, bound by a strict liability floor to highlight that the engine detects structural indicators, but lacks deep AST semantic verification.

1. language_standards.py Updates

• Target: The c and cpp dictionaries.

• Action: Extract specific functions out of general categories and isolate them into a new rule to prevent blending with general tech-debt.

• New Rule: "misra_non_conformance": re.compile(r"\b(strcpy|strcat|sprintf|gets|malloc|calloc|realloc|free|longjmp|setjmp|goto)\b|\b(int|long|short|char|unsigned\s+int)\b\s+[a-zA-Z_]")

2. analysis_lens.py Updates

• Target: RECORDING_SCHEMAS["SIGNAL_SCHEMA"] and RECORDING_SCHEMAS["RISK_SCHEMA"].

• Action: Add misra_non_conformance to the signals, and misra_exposure to the risk vectors. Ensure length bounds remain perfectly aligned to avoid downstream index out-of-bounds errors.

3. signal_processor.py Updates

• Target: SignalProcessor.

• Action: Implement _calc_misra_exposure(self, loc, raw_signals, lang_id, mp).

• Constraint (The Liability Shield): Inject the 33.3% mathematical floor. final_score = max(score, 33.3).

• Action: [NATIVE INTEGRATION] Explicitly register the newly minted _calc_misra_exposure function into the central exposure_vector dictionary located inside the existing calculate_risk_vector method.

  • Architectural Consequence: By wiring this directly into the primary risk array alongside existing high-severity threats like logic_bomb, MISRA compliance metrics instantly become first-class citizens within the GitGalaxy ecosystem. This guarantees that the mathematically bounded data propagates natively through all visualizers and database dumps.

Phase 4: The Enterprise Standard (SARIF Integration)

Goal: Achieve zero-friction UI integration with GitHub Advanced Security (GHAS), GitLab, Azure DevOps, and orchestrators like Muninn.

1. Create sarif_recorder.py

• Target Directory: gitgalaxy/recorders/

• Action: Create sarif_recorder.py to consume the parsed_files RAM state array, mapping GitGalaxy risks to OASIS-compliant SARIF tool.driver.rules.

• Spatial Binding: Iterate over the hit_vector spatial coordinates. By translating regex byte offsets into line numbers, generate results with exact physicalLocation (URI and line numbers) for each triggered Structural Signature.

• Architectural Impact: Emitting valid SARIF eliminates the need for enterprise teams to write custom parsers. If Santiago uses GitGalaxy in Muninn, GitHub will automatically annotate developer PRs with GitGalaxy's structural findings inline with their code.

2. Wire into galaxyscope.py

• Action: Import SarifRecorder and append it to the final export block alongside the JSON, Markdown, and SQLite recorders, ensuring it generates gitgalaxy_results.sarif by default in CI/CD environments.

Phase 5: Enterprise Value-Addons (Unlocking the Pipeline)

Goal: Seamlessly route existing standalone capabilities into the main automated workflow to transition the tool into a mandatory compliance line-item for Directors and VPs of Engineering.

1. Wire SBOM Generation (CycloneDX/SPDX)

• Target: galaxyscope.py

• Action: [EXISTING CAPABILITY - SEAMLESS INTEGRATION] The precise dependency extraction logic is already fully built in sbom_generator.py. Wire this execution natively into the main galaxyscope.py orchestrator to run automatically alongside scans.

• Strategic Value: Federal Executive Orders mandate SBOMs for government software contractors. Providing an instant, zero-trust physical SBOM alongside structural risk metrics solves two massive compliance headaches with one binary execution.

2. Wire Custom Physics Calibration (BYO-Standards)

• Target: aperture.py / Initialization logic

• Action: [EXISTING CAPABILITY - SEAMLESS INTEGRATION] The configurable physics variables already live in analysis_lens.py. Update the Ingestion phase to look for a .gitgalaxy.yaml file in the target repository root to dynamically override these defaults.

• Strategic Value: Every defense contractor has custom rules. Giving them an API to tune the physics engine to their internal risk tolerance prevents the tool from being abandoned due to perceived false positives.

3. Wire PR Delta Gating (CI/CD Quality Control)

• Target: galaxyscope.py (CLI Argument Parsing)

• Action: [EXISTING CAPABILITY - SEAMLESS INTEGRATION] The engine already tracks deltas efficiently via state_rehydrator.py. Add CLI arguments (e.g., --fail-on-risk=80.0 or --fail-on-misra=50.0) that check the delta output and call sys.exit(1) natively.

• Functionality: Act as the ultimate CI/CD gatekeeper. If a Pull Request increases the repository's overall MISRA Risk Exposure beyond the acceptable threshold, the build fails natively, stopping architectural rot before it merges.

4. Wire the Immutable Compliance Vault (Optional SQLite Mode)

• Target: galaxyscope.py (CLI Argument Parsing) & record_keeper.py

• Action: [EXISTING CAPABILITY - SEAMLESS INTEGRATION] The robust SQLite schema already exists in record_keeper.py. Add a dedicated --compliance-vault CLI flag that engages this recorder specifically for formal archival.

• Functionality: Keep the default run lightweight, but when the vault flag is thrown, generate the SQLite database for cold storage. In aviation, investigators demand to see exact code profiles years after deployment. Storing this vault alongside compiled binaries proves to auditors the exact structural risk profile and dependency graph at the precise moment of the build.

Phase 6: Demonstration & Validation

Goal: Prove the efficacy of the engine against known, high-value, and legacy aerospace targets to generate "Golden Image" payloads for prospective enterprise clients.

1. The Aerospace Test Hitlist

Run full scans using the updated engine on the following target repositories to showcase the speed, polyglot capability, and precision of extracting Structural Signatures without an AST:

• NASA Core Flight System (nasa/cFS)

  • The Proof: This is the holy grail of embedded aerospace C code. Use this to prove your misra_exposure sensor generates a perfect, flat 33.3% floor, demonstrating what a true, memory-safe, zero-malloc flight architecture looks like.

• JSBSim (JSBSim-Team/jsbsim)

  • The Proof: A massive C++ 6-Degree-of-Freedom flight dynamics model used by actual autopilots. Run this to show off the new Domain-Specific Ontologies auto-binning, and prove your algorithmic_dos sensors can parse dense, object-oriented math simulations.

• ArduPilot & PX4 (ArduPilot/ardupilot, PX4/PX4-Autopilot)

  • The Proof: The two largest autonomous drone flight controllers in the world. Use these to validate your io and hardware_bridge sensors, mapping exactly where external sensors (IMUs, barometers) pump data into the monolithic C++ core.

• Cortex (sergiovirahonda/cortex)

  • The Proof: A modern drone flight controller built with strict software engineering principles. Use this to highlight your encapsulation_ratio and api_exposure metrics, visually demonstrating how low-coupling, high-cohesion aerospace C++ should actually look.

• Aegis Combat System Emulators (CMS-2 / JOVIAL examples)

  • The Proof: Find legacy snippets of DoD code on GitHub to prove the engine can ingest, optically slice, and report on dead languages that no modern SaaS tool can process.