Inside BugFall's Software Supply Chain Village at BSides Adelaide 2026

Open-source software is central to modern delivery, but every package, registry and build step extends the trust boundary around an application. At BSides Adelaide 2026, BugFall created a hands-on village where participants could explore that trust boundary by compromising a simulated software ecosystem.

The goal was not simply to demonstrate attacks. It was to make the path from package selection to build compromise visible, then connect each weakness to controls that engineering teams can use in real delivery pipelines.

Why supply-chain attacks are difficult to see

Software teams rarely write every component they ship. Applications depend on open-source packages, internal libraries, build runners, package registries and automation maintained across several systems.

That creates opportunities for an attacker to target the delivery process rather than the application itself. A package with the right name, a poorly scoped build credential or an unexpected registry lookup can become enough to introduce malicious code into a trusted build.

These weaknesses can be easy to miss because every individual tool appears to be working as designed. The risk emerges from how those tools trust and interact with one another.

What participants explored

The village placed participants inside a deliberately vulnerable build environment. They could follow several common supply-chain attack paths and observe the result in real time.

Dependency confusion

Dependency confusion takes advantage of ambiguity between private and public package names. If a build tool searches a public registry before, or in addition to, an organisation's private source, an attacker may be able to publish a package that the build selects unexpectedly.

The important lesson is that package names are part of the security boundary. Registry configuration, namespace ownership and deterministic dependency resolution all need to be treated as security controls.

Malicious package injection

A compromised or intentionally malicious dependency can execute code during installation or build. That code may inherit access to source, credentials, signing material and deployment systems.

Teams need more than a vulnerability scanner here. Useful controls include restricting install-time behaviour, reviewing package provenance, limiting build-runner permissions and monitoring unexpected changes in dependency trees.

Build-pipeline compromise

Build systems connect source code to production, which makes them unusually valuable targets. A compromised pipeline can alter artefacts after review, expose credentials or publish software that appears to come from a trusted process.

The exercise made one principle clear: a build runner should not receive broad, permanent access simply because automation needs to be convenient. Short-lived credentials, isolated jobs and verifiable artefacts reduce both the likelihood and impact of compromise.

The controls have to fit delivery

Supply-chain security is most effective when it works with engineering rather than adding a separate approval layer. Controls should produce evidence teams can act on inside the tools they already use.

That usually means combining:

• controlled package sources and namespaces;
• locked and reviewable dependency changes;
• least-privilege build identities;
• isolated and reproducible build environments;
• artefact signing and provenance;
• monitoring for unexpected package and pipeline behaviour; and
• clear ownership when a finding needs remediation.

No single product provides all of this. The useful outcome is a delivery system where trust decisions are explicit, reviewable and difficult to bypass unnoticed.

Bringing the exercise back to real systems

The same attack paths can be assessed safely in an organisation's own delivery environment. A focused review can map package sources, build identities, secrets, deployment permissions and artefact flows, then prioritise the controls that reduce meaningful exposure.

BugFall works with engineering teams on application and software supply-chain security, from targeted assessment through remediation and ongoing improvement.