Software Supply Chain Security: An Australian Guide

The short answer

Software supply chain security is the management of risk that reaches you through software you did not write. It has three layers: the products you buy, the components inside those products, and the toolchain used to build software for you. Most organisations have the first layer on an asset register. Very few have the third.

The third layer is the one that sits upstream of every control you have. If it is compromised, your access reviews, your change approvals and your production hardening all still pass, and none of them help.

If someone built software for your business, it was built somewhere. On a build server, from a code repository, using a pipeline that held credentials good enough to push the result into production. That machine is part of your information estate. It is very rarely on your asset register, and it is very often outside the scope statement of the management system that is supposed to cover your information.

This guide is written for the person who owns information security in an Australian business without owning the infrastructure: the operations manager, the quality manager, the finance director who inherited the ISMS. It is a governance guide, not a remediation guide. The technical work belongs to whoever runs your systems. Knowing what to ask them for, and being able to evidence that you asked, is the part that belongs to you.

Tilt-shift miniature of a developer workstation, a single build server and a data centre linked by glowing data paths, with a figure checking a clipboard beside a conveyor of packaged software — The build server in the middle holds the credentials to deploy. On most asset registers it does not appear at all.

What software supply chain security covers

The phrase gets used loosely, which is part of why it is hard to act on. It is easier to manage as three distinct layers, because each has a different owner, a different failure mode and a different kind of evidence.

Layer	What it is	How it fails	What you can evidence
Software you buy	Commercial products, SaaS platforms, plugins, the systems your provider runs on your behalf	A vulnerability in a product you cannot patch yourself, disclosed on someone else’s timetable	An inventory, a named owner, a route to hear about advisories, a supplier agreement that says who patches what
Components inside it	Open source libraries and dependencies pulled in when software is built	A compromised or abandoned package enters your product without anyone choosing it	A bill of materials, a policy on what may be pulled in, a check at build time
The toolchain	Build servers, source repositories, pipelines, artefact stores, signing keys and the credentials they hold	Someone reaches production without ever touching production	The asset on a register, access restricted and reviewed, environments separated, activity logged

Most organisations do reasonable work on the first row. The second row has improved because customers and tender panels started asking for a software bill of materials. The third row is where the gap usually is, and it is the row with the shortest path to your production systems.

The asset that is not on your register

A worked example, because the abstract version of this argument never lands.

On 24 August 2026 the Australian Signals Directorate’s Australian Cyber Security Centre published a High alert stating that it had observed active exploitation, within Australia, of a vulnerability affecting TeamCity On-Premises servers. The alert describes TeamCity as “a Continuous Integration and Continuous Deployment (CI/CD) server to automate the processes of building, testing, and deploying software”. It says CVE 2026-63077 “may allow an unauthenticated attacker with HTTP(S) access to a TeamCity server to bypass authentication checks and execute arbitrary operating system commands”, and that the vulnerability affects all TeamCity On-Premises versions.

Read the capability rather than the product name. Unauthenticated. Remote. Arbitrary commands. On the machine that builds and deploys your software, and therefore on the machine that holds the credentials to do so.

Here is the part that matters for anyone who has built a management system. A build server sits upstream of your downstream controls. If an attacker changes what the build produces, the artefact that reaches production is signed off by your ordinary change process, approved by whoever approves changes, and deployed through the route you hardened. Every control fires correctly. Every control passes. None of them was looking in the right direction, because none of them was ever pointed at the machine that assembles the thing being controlled.

That is not a failure of the controls. It is a failure of scope.

The alert says “intended for a technical audience”. That is the wrong filter

The alert carries that line, and it is accurate about the remediation. It is misleading about the audience. The same alert is tagged for small and medium business, large organisations and government, and its own mitigation advice includes this: “If TeamCity Server is managed by a third party, such as a MSP or Enterprise IT provider, you should contact that provider to ensure the products have been patched and are being monitored for suspicious activity.”

Contacting a provider and getting a specific answer is not a technical task. It is a governance task, and it is yours. The technical audience patches the server. Somebody still has to know the server exists.

What ISO 27001 asks for

ISO/IEC 27001:2022 does not have a control called software supply chain security. It has a set of Annex A controls that, taken together, describe one. The useful exercise is to read them as a sequence rather than a checklist, because they follow the path a piece of software takes to reach you.

Control	What it asks	What the toolchain question looks like
A.5.9 Inventory of information and other associated assets	Maintain an inventory of information and associated assets, with owners	Is the build server, repository and artefact store on the inventory, and who owns each?
A.5.19 Information security in supplier relationships	Manage the security risk of using suppliers’ products and services	Does the developer who builds your software count as a supplier in your process?
A.5.20 Addressing information security within supplier agreements	Agree relevant requirements with each supplier	Does the agreement say who patches the build infrastructure, and on what timeframe?
A.5.21 Managing information security in the ICT supply chain	Define processes to manage risks associated with the ICT products and services supply chain	Do you know what your supplier’s supplier contributes to your product?
A.8.2 Privileged access rights	Restrict and manage privileged access	Who holds deployment credentials, and when were they last reviewed?
A.8.4 Access to source code	Read and write access to source code, tools and libraries is appropriately managed	Who can commit, who can approve, and can one person do both?
A.8.8 Management of technical vulnerabilities	Obtain information about vulnerabilities, evaluate exposure, take action	Would an ACSC alert about your build platform reach a named person?
A.8.9 Configuration management	Configurations are established, documented, monitored and reviewed	Is the pipeline configuration itself under change control?
A.8.30 Outsourced development	Direct, monitor and review outsourced development activity	What do you actually review, and how often?
A.8.31 Separation of development, test and production environments	Development, testing and production environments are separated and secured	Can something move from a developer’s machine to production without a gate?

None of these needs a certificate to be worth doing. What certification adds is that each becomes something a named person owns, with a date on it, that an external auditor will ask to see. A system built that way answers the question the first time it is asked rather than the third.

If your organisation is earlier in its maturity, the Essential Eight is a sensible first step. Patching applications and restricting administrative privileges are two of its strategies and both apply directly here.

Questions worth asking

If someone builds or maintains software for you:

What build and deployment systems do you use for our work, and are any of them internet facing?
Who at your end can deploy to our production environment, and when was that list last reviewed?
How do you find out about vulnerabilities in your own toolchain, and what is your patching timeframe?
Can you provide a bill of materials for what you have built for us?
If your build environment were compromised, would you tell us, on what timeframe, and in writing?

A good answer is specific and dated. It names the products, gives versions, states whether the interface is exposed, and describes what somebody did to look for compromise rather than assuming that patching settled it. An answer that sounds reassuring and contains no nouns is itself a finding, and it is worth recording as one.

If you build software yourself, the questions turn inward: is the build infrastructure on the asset register, is it in the scope of your ISMS, does one person have both commit and deploy rights, and would an advisory about your CI platform reach anyone who could act on it before a customer asked.

How this differs from supplier risk generally

Worth drawing the line, because the two get conflated and the controls are not the same.

Supplier risk management asks whether an organisation you rely on is trustworthy and what happens when it is not. We have written about the obligation that lands on you when a supplier loses data you are responsible for, and about how to get a specific answer out of an IT provider when an alert names a product they may run. If you supply into critical infrastructure, the obligations can also flow toward you, which we covered in the ASD isolation guidance for suppliers.

Software supply chain security is narrower and more concrete. It asks a question about a specific class of asset: the systems that assemble and deliver software into your environment. You can have excellent supplier assurance, a signed agreement, a completed questionnaire and an annual review, and still have no idea that a build server exists.

Common questions

Do we need ISO 27001 to manage this?

No. The inventory, the access restriction and the separation of environments are worth doing on their own merits. Certification changes who is accountable and what evidence exists, which is usually what your customers are testing when they ask.

We only use off the shelf software. Does this still apply?

The first two layers apply to you in full. The third applies indirectly: your vendors have build infrastructure, and their exposure becomes your exposure through the product. Your realistic control is the supplier agreement, the inventory and a route to hear about advisories, rather than anything you patch yourself.

Is a software bill of materials required?

No Australian standard or law currently requires one of a general business. It is increasingly requested in contracts and tenders, particularly where government or critical infrastructure sits at the other end, so it is better treated as a condition of supply that is arriving than as a compliance obligation that has arrived.

Where to start

Take your asset register and look for the machines that build, store and deploy code. If they are not there, that is the finding, and adding them is a short piece of work. Then give each one an owner, check who holds the credentials, and establish how an advisory about that platform would reach a person who can act.

Streamline is led by a practising ISO Lead Auditor, so you get the view from the other side of the audit table. We build and improve ISO 27001 information security management systems, run gap analysis against the controls above, and offer ISO mentoring for the in-house person who owns this and would rather build the capability than outsource it.

For most small and medium Australian organisations, ISO 27001 certification takes three to six months and a first year investment of roughly $15,000 to $30,000. Built as part of an integrated management system alongside other standards, the cost runs at about 50% to 75% of doing it standalone.

If you cannot currently name the machine that builds your software, get in touch and we will help you find it and put it under control.

Sources

ASD’s ACSC, Active exploitation of a software development platform within Australia, 24 August 2026
ISO/IEC 27001:2022, Annex A

This article is general information from an auditing and management system perspective. It is not technical remediation advice and it is not legal advice. Vulnerability and patch guidance changes, so confirm the current position with the vendor and with ASD’s ACSC.

General guidance only. This article is general information, not legal, financial, safety or compliance advice, and it does not take account of your specific circumstances. Streamline ISO Consultants are ISO management-system consultants, not lawyers or licensed advisers. Standards, laws and regulator guidance change, and details were correct only at the time of writing. Always seek professional advice before acting. See our full Disclaimer.