LearnBeginner roadmap
From zero to your first contribution.
A self-paced path for people new to security, spacecraft software, or both. Each stage builds on the last, ends with hands-on work on the real astrapatch demo, and has a checkpoint so you know when to move on.
Practice only on code you own or are allowed to test, like the demo. Probing systems you do not own is illegal in most countries and can cause real harm.
Who it is for
- Students and new engineers
- Developers new to C or security
- Security people new to flight software
- Aerospace engineers new to vulnerabilities
What you need
- Linux, macOS, or Windows with WSL
- Python 3.11+, git, make and a C compiler
- A GitHub account with two-factor authentication
About the demo
examples/demo-spacecraft is a small, deliberately vulnerable C program built for learning. It is a host-side harness, not flight software.
Stage 01 · 2 to 4 weeks
Foundations
Linux, git and GitHub, Python
Checkpoint
You can clone a repository, run its tests, make a branch and commit a change.
Learn
- The shell: files, pipes, environment variables, exit codes
- git: commits, branches, pulling, pushing, reading a diff
- GitHub: forks, issues, pull requests, reviews
- Python: modules, virtual environments, pip, pytest
Practice
- Clone astrapatch, create a virtual environment and install it with pip install -e ".[dev]"
- Run pytest and check the exit code
- Find where each command is defined in src/astrapatch/cli.py
Resources
- Pro Git (free book)git-scm.com/book
- The Python Tutorialdocs.python.org/3/tutorial
- GitHub Docsdocs.github.com
Stage 02 · 3 to 6 weeks
C and memory
Pointers, buffers, compiling
Checkpoint
You can explain why copying a header-controlled length into a 64-byte local array can overwrite the stack.
Learn
- Types, arrays, strings and the terminating zero
- Pointers, and the stack versus the heap
- memcpy, strcpy, sprintf and their bounded versions
- Compiling and linking with gcc and make
Practice
- Build the demo with make and make test
- Run the nominal and malformed scenarios and compare exit codes
- Find the line in src/tlm.c that crashes on malformed packets
Resources
- The C Programming LanguageKernighan and Ritchie
- Compiler warningsgcc -Wall -Wextra
Stage 03 · 3 to 5 weeks
Security fundamentals
CWE, static analysis, sanitizers
Checkpoint
Given a short C function, you can name the likely weakness, its CWE, and which tool would catch it.
Learn
- Weakness classes and the CWE catalog
- Static analysis and why it reports false positives
- Sanitizers that catch bugs while a program runs
- Fuzzing, and the difference between a weakness and an exploit
Practice
- Rebuild the demo with -fsanitize=address and run the malformed scenario
- Read the report: a stack-buffer-overflow at src/tlm.c:44
- Compare it with the CWE-121 entry
Resources
- CWEcwe.mitre.org
- AddressSanitizerclang.llvm.org/docs/AddressSanitizer.html
- cppcheckcppcheck.sourceforge.io
Stage 04 · 2 to 4 weeks
How spacecraft software works
Subsystems, telemetry, flight frameworks
Checkpoint
You can explain why "it compiles and the bug is gone" is not enough for software already in orbit.
Learn
- Subsystems: flight computer, power, attitude control, communications, payload
- Telemetry, telecommands and CCSDS space packets
- Open flight software frameworks: NASA cFS and F´
- Constraints: memory, CPU, deadlines, radiation, intermittent links
Practice
- Decode one packet in scenarios/nominal.pkts by hand
- Add a well-formed packet and check the new line in telemetry.out
- Find a command-handling component in cFS or F´
Resources
- NASA cFSgithub.com/nasa/cFS
- NASA F´github.com/nasa/fprime
- NASA NOS3github.com/nasa/nos3
- CCSDS standardspublic.ccsds.org
- SPARTAsparta.aerospace.org
Stage 05 · 1 to 2 weeks
Software supply chain
SBOMs and advisories
Checkpoint
You can read an SBOM and explain how an advisory's version range applies to a component.
Learn
- What an SBOM is and why operators ask for one
- CycloneDX and SPDX
- CVE identifiers and advisory databases such as OSV
- How version ranges decide which versions are affected
Practice
- Run astrapatch analyze and open sbom.cdx.json
- Change the minicrc version to 0.9.3 and analyze again: the fictional advisory disappears
Resources
- CycloneDXcyclonedx.org
- OSVosv.dev
Stage 06 · 2 to 3 weeks
Testing and verification
Regression, scenarios, determinism
Checkpoint
You can explain why a candidate that passes every rule is still only accepted for review.
Learn
- Unit, integration and regression tests
- Baseline versus candidate comparison
- Scenarios and fault injection
- Determinism, reproducibility, and why unknown is never pass
Practice
- Add a check to tests/test_tlm.c and run make test
- Find the test proving a missing metric gives unknown
- Explain what evidence each rule in policy.toml needs
Stage 07 · 1 to 2 weeks
Hands-on with astrapatch
Run it, read it, change it
Checkpoint
You can predict a verdict before running verify, and explain it from verification.json afterwards.
Learn
- The interactive shell and the one-shot commands
- Reading findings.json, verification.json and the evidence package
- How policies and scenarios shape the verdict
Practice
- Run /analyze, /fix, /verify and /report in the shell
- Fix only FINDING-002 and watch verification reject it
- Set small-change to max = 2 and watch a 3-line patch get rejected
- Write a strcpy bug in a new project and see AP-C003 flag it
Stage 08 · ongoing
Your first contribution
Request access, pick a task, open a PR
Checkpoint
Your first pull request is reviewed and merged.
Learn
- The contribution workflow and code standards
- The project's principles and accuracy rules
Practice
- Email contribute@astrapatch.online, mentioning the stage you have reached
- Pick one of the good first tasks
- Open a focused pull request with a test
External resources are independent. astrapatch is not affiliated with or endorsed by NASA, CCSDS, MITRE or The Aerospace Corporation.