Back to Perspectives
DefenceGovernment

Sovereign Capability: What It Means for Australian Software

Blue Neon1 December 20258 min read

"Sovereign capability" gets thrown around in Canberra defence circles with the confidence of people who assume everyone else knows what it means. It appears in ministerial statements, defence white papers, and procurement documents. It's used to justify everything from submarine contracts to cloud computing decisions. And in most contexts, it's used so loosely that it's nearly meaningless.

If you're building software for Australian defence or government, here's what sovereign capability means in practice, why it matters, and where the real challenges lie.

The Core Definition

At its core, sovereign capability means Australia's ability to independently develop, maintain, and operate critical systems without depending on foreign entities for continued access or functionality. The key word is "independently." Not "in isolation", no country builds everything from scratch, but with sufficient control that a foreign government's policy change or a foreign company's business decision can't render your critical systems inoperable.

For software, this breaks down into several dimensions. Data sovereignty: where is the data physically stored, who can access it, and under which country's laws? Operational sovereignty: can you operate the system without ongoing foreign support? Intellectual sovereignty: do you understand how the system works well enough to modify it? Supply chain sovereignty: can your dependencies be cut off?

Each of these dimensions exists on a spectrum. Very few systems need to be 100% sovereign across all dimensions. That would mean writing your own operating system, fabricating your own chips, and manufacturing your own hardware. The real work is identifying which dimensions matter for a given system and to what degree.

"Sovereign capability doesn't mean building everything in Australia. It means having enough control over critical systems that a foreign actor can't switch them off."

The Cloud Sovereignty Question

The most contentious sovereign capability debate in Australian government IT centres on cloud computing. AWS, Azure, and GCP all now have Australian regions (and in some cases, classified regions operated in partnership with the ASD). The open question: does running on a US-owned hyperscaler in an Australian data centre constitute sovereign capability?

The pragmatic answer is: it depends on the workload. For PROTECTED-level workloads, the major hyperscalers have IRAP-assessed offerings that meet the security requirements. The data stays in Australia, the staff who manage the classified infrastructure hold Australian security clearances, and the operational controls are well-understood. For most government systems, this is sufficient.

But there are legitimate concerns. US legislation, specifically the CLOUD Act, theoretically allows US government agencies to compel US companies to disclose data stored overseas. Application to Australian government data is debatable, but the legal mechanism exists. For highly sensitive workloads, intelligence systems, certain defence capabilities, cabinet-level communications, this theoretical risk may be unacceptable.

The Australian-owned alternatives are growing. AUCloud, Vault Cloud, and Sliced Tech offer sovereign cloud infrastructure specifically for government workloads. They're smaller scale and higher cost than the hyperscalers, but they eliminate the foreign jurisdiction risk entirely. For systems that genuinely need it, the premium is justified.

Software Supply Chain Sovereignty

Most organisations underestimate the software supply chain dimension. A typical modern application has hundreds of dependencies: npm packages, Python libraries, container base images, CI/CD tools, monitoring services. Each dependency is a potential point of foreign control. The left-pad incident of 2016 was a minor annoyance for web developers. A similar event affecting a critical defence system would be a capability failure.

The practical mitigations are straightforward but require discipline. Pin all dependencies to exact versions, not ranges. Maintain a local mirror of critical package registries (Artifactory or Nexus). Generate and verify SBOMs (Software Bills of Materials) for every deployment. Audit the provenance of critical dependencies — who maintains them, where are they based, who funds them? And have a documented plan for replacing any critical dependency that becomes unavailable.

SLSA (Supply-chain Levels for Software Artifacts) provides a good framework for assessing and improving supply chain security. At Level 3, which we target for defence systems, every build artefact has cryptographically verified provenance from source code to deployed binary, and the build process itself is hardened against tampering.

The Skills Dimension

The most overlooked aspect of sovereign capability: people. You can host data in Australia and use Australian-owned infrastructure, but if the only people who understand how the system works are contractors from a foreign company, you don't have sovereign capability. You have sovereign hosting.

Software sovereignty requires Australian engineers who understand the systems well enough to maintain, modify, and extend them without foreign assistance. This means investing in Australian engineering talent, not just buying Australian hosting. It means ensuring that knowledge transfer is a contractual requirement, not an afterthought. And it means building internal capability alongside external delivery, so the organisation isn't permanently dependent on consultants — including us.

This is the hardest part. Australia has a structural shortage of cleared software engineers, and the defence sector competes for talent with commercial tech companies that offer higher salaries and more flexibility. The solution isn't higher pay alone, it's making defence software work interesting, providing modern engineering environments rather than forcing people onto locked-down Windows desktops with IE11, and creating career paths that don't require leaving for the private sector.

Making It Real

For organisations building software in the Australian defence and government space, sovereign capability isn't a binary checkbox, it's a set of decisions about risk tolerance, cost, and capability across multiple dimensions. The practical approach is to assess each system on its actual sovereign requirements — data classification, operational criticality, threat model — and make proportionate investments. Not everything needs to be built from scratch in a bunker in Canberra. But the things that matter need Australian control. Knowing the difference is the real capability.