Most Australian organisations know who they buy software from. Far fewer know who wrote the code inside it.
That blind spot sits at the heart of new research from Purdue University, the United States Military Academy at West Point, and Florida International University. After analysing more than 220 Android apps marketed to US military personnel, researchers found that many relied on third-party software development kits (SDKs) supplied by companies based in China and Russia.
The researchers found no evidence that the embedded code was stealing data or conducting espionage. Instead, the study highlights a broader software supply chain problem that affects organisations everywhere, including Australia: companies often vet the software vendor, but not the external code that ships with the application.
A software visibility problem for Australia’s enterprises
The military angle may grab headlines, but it is only one example of a much broader issue.
Modern enterprise applications are rarely built entirely by one company. Most combine internally developed code with open-source libraries, cloud services, analytics platforms, authentication tools, advertising frameworks, mapping services, and dozens of other third-party SDKs. Many organisations know who sold them the software, but far fewer can identify every external component running inside it.
That is precisely why Australian organisations need to treat software supply chains as a security issue rather than simply a procurement exercise.
The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) has previously encouraged organisations to improve visibility into third-party software components and adopt Software Bills of Materials (SBOMs), which provide an inventory of the libraries, frameworks, and dependencies included in an application. The idea is simple: you cannot properly assess software risk if you do not know the underlying software driving your own visible software.
Recent supply chain attacks have reinforced that message. Rather than attacking businesses directly, threat actors increasingly target widely used software packages and repositories, knowing that a compromised dependency can spread through thousands of organisations before anyone notices. The Purdue research points to the same structural weakness, but from a different angle.
Why Australian IT leaders should care
The findings are not an argument against using third-party SDKs. They are an unavoidable part of modern software development, allowing vendors to build applications faster and deliver new features without reinventing common functionality.
The challenge is governance.
Many procurement reviews still concentrate on the software vendor’s reputation, security certifications, and compliance commitments. Those checks remain important, but they reveal relatively little about the third-party components embedded within the product or how those components are maintained after deployment.
That distinction matters because SDKs and software libraries can receive updates independently throughout an application’s life. A product that passes a security review today may include dependencies that change ownership, introduce new functionality, or develop vulnerabilities months later.
For Australian enterprises already strengthening cyber resilience, software visibility is becoming just as important as vendor trust.
The privacy lesson extends beyond enterprise software
The study also highlights a lesson for consumers.
Whether Australians download a banking app, an airline app, a government service, a retail platform, or a fitness tracker, the software is likely to rely on numerous third-party components that operate behind the scenes. Users rarely know which companies built those components or what data they process.
Researchers also found that 40% of the examined apps disclosed less about their data collection practices. While the finding relates specifically to the apps analysed in the study, it reinforces a broader point: privacy labels and marketplace disclosures provide useful information, but they should not be treated as a complete picture of how software manages personal data over time.
As Australia continues investing in digital sovereignty and stronger privacy protections, visibility into software components is becoming just as important as understanding where information is ultimately stored.
Takeaways for Australian enterprises
The Purdue research should not prompt Australian businesses to blacklist software because the code was developed abroad or parts of its components come from outside the region. That misses the larger point.
Instead, organisations should use it as a reminder to ask more informed questions about the software they deploy. Can vendors provide a Software Bill of Materials? Which third-party SDKs and open-source libraries are included? How are those dependencies monitored? What happens when ownership changes, or vulnerabilities emerge?
Those questions are becoming increasingly relevant as software supply chain attacks grow more common and enterprise applications become more dependent on external code.
The US researchers set out to examine apps marketed to military personnel. Their findings ultimately tell a much broader story — one that Australian organisations are already confronting.
In today’s software ecosystem, knowing who built the software your enterprise relies on is only part of the risk assessment. Understanding what has been built into it is rapidly becoming just as important.