Software has spread to almost every aspect of our lives—from our watches to our combat aircraft—and nearly every organisation, from the Department of Defence to your local shopfront, relies on software to operate. It is no longer confined to laptops or computers. Software now controls the operations of power plants, medical devices, cars and much of our national security and defence platforms.

At the same time as software has become integral to our prosperity and national security, attacks on software supply chains are on the rise.

A software supply chain attack occurs when an attacker accesses and maliciously modifies legitimate software in its development cycle to compromise downstream users and customers. Software supply chain attacks take advantage of established channels of system verification to gain privileged access to systems and compromise networks. Traditional cybersecurity approaches, such as those deployed on the perimeter, have limited capability to detect these attacks since they often leverage legitimate certificates or credentials and so don’t raise any ‘red flags’.

Software supply chain attacks are popular, can have a big impact ^[1] and are used to great effect by a range of cyber adversaries. Attackers can sit undetected on networks for months ^[2] and deliver remote-code execution ^[3] into target environments. Efforts to disrupt or exploit supply chains—including software supply chains—have become a ‘principal attack vector ^[4]’ for adversarial nations seeking to take advantage of vulnerabilities for espionage, sabotage or other malicious activities.

The growing prevalence of sophisticated supply chain attacks, like SolarStorm ^[5] and Not Petya ^[6], has seen governments around the world increasingly focused on identifying and mitigating risks to the software supply chain.

In the US, a recent executive order ^[7] requires government agencies to purchase only software that meets secure development standards to protect government data. To support the order, in February the National Institute of Standards and Technology issued guidance that provides federal agencies with best practices for enhancing the security of the software supply chain. Two guidelines were released: the Secure software development framework and the companion Software supply chain security guidance.

The executive order directs the US Office of Management and Budget to take appropriate steps to require that agencies comply with the guidelines within 30 days. This means that federal agencies must begin adopting the framework and related guidance immediately while customising it to their agency-specific risk profile and mission. Vendors that supply software to the US government will soon also have to attest to meeting these guidelines.

In the Australian context, however, software supply chain risks remain largely underappreciated and unaddressed. So, what two key things could the Australian government do to manage these risks?

First, it should update government procurement policies and processes to manage software supply chain risks.

The government should ensure that there are adequate mechanisms to assess software supply chain risks early in the acquisition or procurement process. At the later stages of the acquisition process, which in some cases can be years later, a supply chain risk may be realised and the government may be overly committed to the solution of choice—forcing it to either pay significant costs to remove the risk or attempt to manage the risk. Strengthening references to the importance of software supply chain risks in key procurement policies would support the government to make more informed purchasing decisions and embed risk management practices at the early stages of the acquisition process.

In particular, the government should consider adopting the US guidelines and integrate them into its procurement policies and practices. These documents are intended to help government agencies get the necessary information from software producers in a form that can help guide risk-based decisions. The recommendations span many types of software, along with firmware, operating systems, applications and application services, among other things.

Procurement processes should include asking software companies about their product integrity practices. This could include key questions about their internal processes and oversight mechanisms to mitigate the risk of modification during the development lifecycle and whether they undertake third-party testing to ensure that security vulnerabilities are identified earlier in the process?

The government should also take steps to protect source code integrity by understanding whether vendors have shared their unique intellectual property as a condition of market access. Increasingly, we have seen instances of countries implementing new requirements—most notably, mandates to review or even hold source code—as a condition to sell technology to certain parts of their market ^[8]. Widespread source code disclosure, however, could actually weaken security, since source code can be leveraged to detect and exploit vulnerabilities in software used by organisations globally. Currently, the Australian government doesn’t have visibility as to whether companies it deals with have shared their source code with foreign governments—posing a potential security risk.

Procurement policies should be amended to identify the companies that have shared the source code of their unique intellectual property with governments as a condition of access to certain markets. A similar approach is being taken by the US government ^[9].

Second, the Australian government should establish practices and procedures to regularly review business-critical software.

While some organisations might look at how a company manages its software supply chain at the point of purchase, few would undertake regular and continuous reviews of these practices. However, as we have seen from global attacks, regular reviews of key software companies—their culture and software development practices—may be helpful in preventing exposure to supply chain attacks.

As part of this review process, the government could collaborate with vendors of critical software on risk-based principles, including relevant changes to their software development practices or key  personnel changes (for example, the chief security officer leaving the organisation). It should also consider the ‘red line’ for removing software from its environment—in other words, at what point or risk level would an agency reconsider having a particular software product, and who can sign off on removing it?

As our world becomes increasingly digitised and connected, attacks on software supply chains are only set to increase. Compromising them can be an effective technique to gain widespread and undetected access to networks and systems. These risks are particularly acute for the defence and national security communities, which depend on software for key functions such as surveillance, data analytics and weapon systems, most of which is developed in the private sector.