Modern space research runs on software.
Ground systems, communication platforms, data-processing environments, monitoring tools, identity services, cloud infrastructure, research applications and operational workstations all depend on software that changes over time.
Updates are part of keeping these systems secure. They fix vulnerabilities, improve reliability, add functionality and support compatibility with new standards. Without regular and trusted updates, even well-designed systems become exposed.
But software updates also introduce risk.
An update mechanism is a powerful point of trust. If it is compromised, an attacker may be able to distribute malicious code through the same channel that an organisation uses to maintain its systems. If update signing is weak, if repositories are poorly protected, if supplier processes are unclear or if deployment is not controlled, the update path itself can become an attack path.
For space research, this matters because software sits close to sensitive data and trusted communication.
A compromised update affecting a ground-segment system, communication service, identity platform or data-processing environment could create consequences beyond a single device. It could affect confidentiality, system integrity, partner trust and operational continuity.
Trusted updates are therefore not a routine IT detail. They are a core part of secure communication architecture.
Software provenance and signing
The first principle is software provenance.
Organisations need to know where software comes from, who maintains it, how it is built and how updates are delivered. This applies to commercial products, open-source components, internally developed tools, supplier-provided packages and specialist systems.
In research environments, software often accumulates over time. A project may use vendor platforms, custom scripts, academic tools, cloud services, libraries, containers and operational software developed by different teams. Some components may be well maintained. Others may no longer have an active owner.
That creates uncertainty.
A trusted update strategy starts by identifying critical software assets and understanding their supply chain. Which components support secure communication? Which systems handle sensitive data? Which tools have privileged access? Which dependencies are externally maintained? Which software is no longer supported?
These questions help determine where update integrity matters most.
The second principle is cryptographic signing.
Software updates should be signed so that systems can verify their authenticity and integrity before installation. A valid signature helps confirm that the update came from a trusted source and has not been altered.
However, signing only works if the trust behind the signature is protected.
Signing keys must be carefully managed. Access should be limited. Key use should be monitored. Compromise procedures should exist. Expiry, rotation and revocation should be planned. The signing process should be separated from ordinary development activity where appropriate.
A weak signing process can create a false sense of security.
For systems involved in secure communication, signing keys deserve particular attention. If an attacker can sign malicious software as trusted, the technical strength of encryption, authentication or monitoring may be undermined from within.
Controlled distribution and testing
The third principle is controlled distribution.
Trusted software should be delivered through trusted channels. Organisations should avoid informal update practices such as emailing packages, downloading binaries from unverified sources, copying files manually between systems or relying on undocumented supplier instructions.
Controlled repositories, verified checksums, signed packages, secure transport, access controls and audit logs all help strengthen the update process.
This is especially important in multi-partner research settings. Different organisations may need to deploy compatible software or security patches. If each partner uses a different informal process, trust becomes difficult to maintain.
A secure communication environment should make it clear where approved software comes from and how it is validated before use.
The fourth principle is testing before deployment.
Security updates may be urgent, but untested updates can create disruption. In research and operational environments, a failed update can interrupt workflows, break compatibility or affect communication between systems.
Trusted update processes should include testing appropriate to the risk of the system. Critical communication infrastructure, identity services, key-management systems and ground-segment components may require staged deployment, rollback plans and compatibility checks.
The aim is not to slow down security patching unnecessarily. The aim is to apply updates in a way that preserves both security and continuity.
Dependencies and supplier assurance
The fifth principle is visibility into dependencies.
Modern software rarely stands alone. Applications depend on libraries, frameworks, containers, operating-system packages, APIs, cloud services and build tools. A vulnerability or compromise in one dependency can affect systems that appear unrelated.
For space research communication, hidden dependencies can become a serious risk. A system may be considered secure at the application level while relying on outdated cryptographic libraries, unsupported components or build processes that are not monitored.
Organisations should maintain visibility into critical dependencies, especially where software supports authentication, encryption, signing, data transfer or remote access.
This is also important for post-quantum readiness.
As cryptographic standards evolve, software components will need to support new algorithms, updated protocols and revised trust models. Organisations that do not understand their dependencies will find it harder to plan migration.
The sixth principle is supplier assurance.
Many software update processes are controlled partly or entirely by suppliers. This is normal, but it requires governance. Organisations should understand how suppliers build, sign, test and distribute updates. They should also understand how vulnerabilities are disclosed, how quickly patches are released, how long products are supported and how security issues are communicated.
For high-trust environments, supplier claims should not remain vague.
Procurement and project teams should ask direct questions: How are updates signed? Who controls signing keys? What happens if a signing key is compromised? How are dependencies monitored? What is the support lifecycle? Is there a roadmap for post-quantum cryptographic support? How are emergency patches delivered?
These questions are part of responsible risk management.
Incident readiness and build environment
The seventh principle is incident readiness.
Organisations should plan for the possibility that an update mechanism, software package or supplier component may become untrusted. This requires clear procedures.
Can a malicious or faulty update be blocked? Can affected systems be identified quickly? Can certificates or signing keys be revoked? Can systems be rolled back safely? Can partners be notified? Can communication continue through alternative paths while the issue is investigated?
In a multi-partner space research environment, these questions should be addressed before a crisis occurs.
The update chain is part of the trust chain. When trust is broken, response speed matters.
The eighth principle is protecting the build environment.
For organisations developing their own software, the update process begins before distribution. Source-code repositories, build systems, developer credentials, automation pipelines, test environments and release tools all require protection.
A compromised build environment can produce malicious software that appears legitimate. This risk is especially serious when software is signed automatically after build.
Development and release systems should therefore be treated as sensitive infrastructure. Access should be controlled. Changes should be reviewed. Build outputs should be reproducible where practical. Secrets should not be embedded in code or pipelines. Logs should support investigation.
Trusted updates depend on trusted development practices.
Long-term maintainability and the COSMOS-SECURE perspective
The ninth principle is long-term maintainability.
Space research systems may remain in use for many years. Software that is secure today may become difficult to maintain if vendors end support, dependencies become obsolete or update mechanisms cannot support new security requirements.
Long-life systems should be designed with maintainability in mind. This includes clear documentation, upgrade paths, supplier lifecycle commitments and avoidance of unnecessary lock-in.
It also includes cryptographic maintainability.
Post-quantum migration will affect software update systems because many of them rely on digital signatures, certificates and public-key mechanisms. Organisations will need to understand whether their update infrastructure can support new signature schemes and trust anchors when required.
A system that cannot update its own trust mechanisms becomes difficult to secure over time.
COSMOS-SECURE focuses on secure communication in space research, and trusted software updates are part of that mission.
Communication systems cannot remain trusted if the software that supports them cannot be verified, maintained and updated safely. The integrity of updates affects encryption tools, identity platforms, monitoring systems, operational software and the infrastructure that connects research partners.
For organisations involved in space research, practical steps can begin immediately.
Identify critical software assets. Review how updates are obtained and verified. Protect signing keys. Use controlled repositories. Test updates before deployment. Monitor dependencies. Ask suppliers about update integrity and post-quantum readiness. Protect build systems. Prepare response procedures for compromised or faulty updates.
Trusted communication depends on trusted software.
And trusted software depends on an update chain that is secure by design, governed in operation and adaptable over time.