Open-source security engineering for spacecraft software. Analyze vulnerabilities, develop candidate fixes, and validate changes against mission-critical constraints.
Spacecraft operate with limited physical access, constrained computing resources, intermittent communications, and strict operational requirements.
A security update that resolves a vulnerability can still introduce unacceptable changes to timing, memory usage, fault recovery, or mission behavior.
Securing spacecraft software requires more than generating patches. It requires evidence that a change satisfies the system's defined constraints.
After launch there is no hands-on recovery. Every change arrives over the link and must work the first time.
Memory, CPU and power budgets are fixed. A fix cannot spend what the mission needs.
Contact windows are short and intermittent. Observing the effect of a change can take hours.
Timing, fault recovery and telemetry behavior must remain intact after any change.
A modular workflow connecting security analysis, candidate remediation, simulated execution, and policy-driven verification. Select a stage to inspect it.
Nothing is deployed by this workflow. Review ends with evidence for an operator-controlled approval.
Each subsystem is designed to be inspectable, replaceable, and extensible.
Integrates existing static analyzers rather than reinventing them. Builds a dependency inventory and SBOM, correlates known vulnerabilities, and normalizes findings with severity and evidence.
Documentation SOONProposes candidate patches through configurable model backends, local models included, or rule-based adapters. Every proposal is treated as untrusted and carries its provenance.
Documentation SOONReproducible scenarios against existing spacecraft simulators, comparing baseline with patched behavior, timing and resource use.
Deterministic rules for memory, CPU, deadlines, telemetry compatibility and watchdog behavior. AI may explain a result, never override it.
Aggregates test, simulation and policy results into one verdict: accepted for further review, rejected, or inconclusive. Unresolved risks are listed, never hidden.
Portable outputs for engineering review: patch manifest, machine-readable JSON report, SBOM, test evidence, build metadata and audit records. Signing and deployment stay with operator-managed infrastructure.
One CLI and a Python SDK, designed to run locally and in CI, with machine-readable output at every step.
Runs on your machine. Your source stays yours.
No dependency on a single AI model or provider.
Every run records the inputs needed to repeat it.
Proposed CLI. Commands and output are examples of the intended experience; nothing was executed.
Five layers, each built from replaceable adapters. Select a component to see what it takes in and what it produces.
Open-source flight software framework.
Component-oriented flight software framework and test tools.
Spacecraft software simulation environment.
Planned integrations only. Not certified by, affiliated with, or endorsed by NASA.
astrapatch is intended to support reproducible research into vulnerability remediation, software assurance, and autonomous decision support for resource-constrained, safety-critical systems.
How software agents can propose and refine candidate security patches.
How functional and operational constraints affect patch acceptance.
Security improvements weighed against memory, computation, timing and communication limits.
Auditable, reproducible evidence behind automated engineering decisions.
astrapatch is designed to encourage collaboration across aerospace engineering, embedded security, software verification, and AI research.
License: Apache 2.0, proposed. Active once the license file is in the repository.
Every phase below is proposed work. Nothing here has shipped yet.
Explore the framework, contribute to its development, and help advance reproducible spacecraft software security research.
