Prepared by: Adam Skupien, Vulnerability Security Analyst | Published: Wed 08 April 2026
The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) has warned of increased targeting of online code repositories, including activity aimed at stealing secrets, accessing private code bases and modifying packages to infect users. While repository compromise is often framed as a developer or maintainer issue, the risk is just as relevant to organisations that consume third-party software packages as part of normal development and build activity.
Recent incidents have shown how quickly abuse of a trusted package ecosystem can become a downstream client security issue. In the recent Axios npm compromise, malicious versions were published with an added dependency that downloaded a second-stage remote access trojan, affecting Windows, macOS and Linux systems.
For organisations, the lesson is straightforward: dependency risk is no longer limited to code quality, licensing or patching. It is also a question of whether the organisation can prevent risky packages from entering the environment, and whether it can quickly identify and respond if a compromised dependency is found.
ACSC’s advisory is relevant to organisations that maintain online repositories, publish software packages, and consume third-party dependencies from public code ecosystems. Threat actors have been observed using phishing, social engineering, compromised credentials, compromised authentication tokens and infected software packages to gain access, after which they have modified packages, scanned repositories for secrets, leaked credentials and exposed private code.
For most organisations, the more immediate risk is on the consumption side. A malicious or compromised dependency can reach developer workstations, build agents and CI/CD pipelines through routine software installation or update activity, potentially exposing credentials and creating a path for follow-on compromise.
The key defensive question is not simply whether an organisation trusts open-source software. It is whether it has the controls to reduce risky dependency changes before they are introduced, and the visibility to determine quickly whether an affected package is present when an incident occurs.
Modern software delivery depends heavily on third-party packages, direct and transitive dependencies, and automated build processes. That creates a problem for defenders: a compromised package may not only affect the application that ultimately ships, but also the systems that install, test or build it. In practical terms, a dependency event can become an endpoint, CI/CD and credential exposure issue before the organisation has even established whether production code was altered.
The recent Axios incident is a useful example because it illustrates how little friction may exist between a public repository compromise and downstream organisational impact. The malicious Axios versions 1.14.1 and 0.30.4 were published on 31 March 2026, injected with a malicious dependency, and used install-time execution to download a second-stage RAT. The package’s runtime application logic was not the only concern; the threat was triggered during installation, which is exactly why build systems and developer environments matter so much in this class of incident.
This is also why the issue should not be treated as a niche concern for software publishers alone. ACSC has made clear that the current targeting affects organisations that use third-party packages sourced from online repositories, not just those that maintain or publish them. For organisations that rely on third-party software packages sourced from online repositories, the challenge is twofold:
Reduce the chance of a risky dependency entering the environment
Be prepared to investigate rapidly when a package is later found to be malicious or compromised
For organisations consuming third-party dependencies, prevention is not about eliminating all open-source risk. It is about adding practical controls that make it harder for unsafe packages, unexpected dependency changes or malicious install behaviour to move into business systems unnoticed. GitHub’s dependency review capability is specifically designed to help catch insecure dependencies before they are introduced, while npm and Node.js guidance emphasise lockfile enforcement and stricter install behaviour.
At a high level, organisations should prioritise a small set of consumer-side controls:
npm ci requires a lockfile and errors if the lockfile and manifest do not match, which helps prevent silent dependency drift.--ignore-scripts, particularly because malicious packages may rely on post-install behaviour rather than obvious runtime code changes.These controls will not prevent every supply-chain incident. They do, however, reduce the likelihood of risky dependency changes entering the environment unnoticed, and they narrow the blast radius when a trusted package later proves to be malicious or compromised.
For most organisations, the critical control in a dependency incident is not perfect prevention. It is the ability to quickly determine whether an affected dependency is present, where it is present, and which systems may have installed, built or executed it. That is particularly important in repository and package compromise scenarios, where the first material question is often not whether a production application is vulnerable, but whether developer endpoints, build runners or CI/CD workflows were exposed during installation or build activity. ACSC’s current advisory reflects this by recommending that organisations investigate affected systems, validate packages, monitor for signs of secret harvesting, suspicious repository access, or credential misuse, and rotate potentially exposed secrets.
In practical terms, organisations should be able to answer a small number of questions quickly:
Do we use the affected package?
Which versions are present?
Where are they deployed or referenced?
Which systems installed them?
What credentials or secrets may have been exposed during that process?
In incidents such as the Axios compromise, those answers directly shape the response, because systems that installed the package may need to be treated as potentially compromised even before any broader application impact is confirmed.
This is where software component visibility becomes especially important. A Software Bill of Materials (SBOM) is best understood as a formal inventory of the components and supply chain relationships used to build software. CISA describes SBOM as a key building block in software security and supply chain risk management, while NIST describes it as a formal record that improves transparency and speeds the identification and remediation of vulnerable or affected components. In this context, SBOM is not a standalone control or a single tool; it is a visibility mechanism that helps organisations determine where a package is used and what may be affected when a dependency issue emerges.
Used well, that visibility allows organisations to move faster when an incident occurs: identify impacted applications and environments, remove or roll back affected versions, assess developer and build systems for compromise, rotate secrets, and prioritise follow-on monitoring. Without that visibility, even a well-resourced security team can lose valuable time simply establishing where an affected package exists.
Some organisations will not only consume third-party dependencies, but also maintain private repositories, internal development platforms, or public packages of their own. For that group, the current threat is broader than downstream dependency risk. ACSC has warned that threat actors are targeting online code repositories to extract secrets, access private code bases, and modify packages to infect users. In practice, that means repository compromise can create both a software supply-chain problem and a direct confidentiality problem if internal code, credentials, or release processes are exposed.
The first priority is account and access security. Repository platforms should be treated like other business-critical systems: access should be limited to the people and integrations that genuinely need it, and stronger authentication should be enforced for anyone with meaningful repository or organisation privileges. GitHub supports organisation-level 2FA requirements and allows organisations to require secure 2FA methods such as passkeys, security keys, authenticator apps, and the GitHub mobile app.
The second priority is protecting critical branches, tags, and release paths from unsafe or unauthorised change. GitHub’s protected branches allow organisations to define whether collaborators can delete or force-push to important branches and to require controls such as passing status checks before changes are accepted. That matters not only for code quality, but for reducing the likelihood that a compromised account, rushed change, or malicious commit reaches production code or release infrastructure without scrutiny.
The third priority is reducing the chance that secrets and tokens become the entry point for a larger incident. Organisations that maintain repositories should consider enabling secret scanning to detect exposed credentials in repository content and history, and push protection to help block detected secrets before they are pushed. GitHub says secret scanning scans the entire Git history on all branches for API keys, passwords, tokens, and other known secret types, while push protection can stop users from pushing secrets to repositories. That is especially relevant here because ACSC specifically warns about scanning repositories for secrets and extracting credentials.
The fourth priority is tightening programmatic and publishing access. GitHub recommends fine-grained personal access tokens over classic tokens where possible, noting that they are more secure and controllable and can be limited to specific repositories and permissions, and npm’s trusted publishing model uses OIDC to eliminate long-lived npm publishing tokens from CI/CD workflows. That matters because stolen or over-scoped tokens can turn a repository compromise into a package publication incident very quickly. For organisations that publish software, token scope, token lifetime and publishing controls deserve the same attention as branch protection and repository permissions.
At a practical level, the message for repository-owning organisations is:
Secure maintainer accounts
Minimise repository and token permissions
Protect important branches and tags
Block secrets before they are pushed
Those steps will not remove repository risk entirely, but they do materially reduce the likelihood that a compromised account, exposed token, or accidental secret leak results in private code exposure or a broader supply-chain event.
The ACSC advisory is a timely reminder that repository targeting is no longer just a software publisher problem. For organisations consuming third-party dependencies, the priority is to reduce risky package changes before they enter the environment and to build the visibility needed to respond quickly when a dependency is later found to be compromised. For organisations that also maintain repositories or publish packages, the same message extends upstream: repository access, secrets and publishing controls deserve the same level of operational attention as any other business-critical system.
https://www.triskelelabs.com/blog/axios-npm-supply-chain-compromise
https://docs.github.com/en/code-security/concepts/supply-chain-security/about-dependency-review
https://docs.github.com/en/code-security/concepts/secret-security/about-secret-scanning
https://docs.github.com/en/code-security/concepts/secret-security/about-push-protection
https://nodejs.org/learn/getting-started/security-best-practices