SA-10(2) - Developer Configuration Management | Alternative Configuration Management
Provide an alternate configuration management process using organizational personnel in the absence of a dedicated developer configuration management team.
Alternate configuration management processes become critical when a developer or supplier lacks robust CM controls. Ground teams must thoroughly test any incoming modules or software in the space domain, where in-orbit hardware changes are nearly impossible. If a subcontractor's procedures fall short, mission operators can compensate with a rigorous preflight testbed: verifying checksums, digital signatures, and functional integrity in a simulated environment that closely mimics on-orbit conditions. The configuration should be flagged for integration only when results pass all acceptance criteria. This approach helps shield the spacecraft from unverified code or hardware, ensuring that latent defects introduced by less mature CM processes do not propagate into the flight segment. Once launched, the operational CM must maintain a master repository of the flight configuration, enabling quick root-cause analysis if anomalies arise and providing evidence that each component or software change was validated despite possible gaps in the supplier's own CM practices.
The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. {AC-3(2),CM-3,SA-8(8),SA-8(31),SA-10(2),SR-4(4)}
The intent is for multiple checks to be performed prior to executing these SV SW updates. One action is mere act of uploading the SW to the spacecraft. Another action could be check of digital signature (ideal but not explicitly required) or hash or CRC or a checksum. Crypto boxes provide another level of authentication for all commands, including SW updates but ideally there is another factor outside of crypto to protect against FSW updates. Multi-factor authorization could be the "two-man rule" where procedures are in place to prevent a successful attack by a single actor (note: development activities that are subsequently subject to review or verification activities may already require collaborating attackers such that a "two-man rule" is not appropriate).
The operating system updates should be performed using multi-factor authorization and should only be performed when risk of compromise/exploitation of identified vulnerability outweighs the risk of not performing the update.