In June 2026, Gartner named AI application compromise, deepfakes, prompt injection and software supply chain threats as the four critical and unpredictable areas where attackers currently hold a significant advantage over enterprise defenders.
Four threats. One of them is the software supply chain.
For enterprises running infrastructure automation at scale, this is not an abstract analyst observation. It is a direct challenge to how they evaluate, procure and govern the automation software operating across their servers, endpoints, cloud environments and critical systems. The Gartner finding gives formal weight to a question that has been quietly intensifying for years:
Do you actually know what is running your infrastructure, who built it and whether that build process can be trusted?
The Threat Gartner Is Describing
Gartner's position is unambiguous. Software supply chain risks are escalating as attackers increasingly compromise third-party components, open-source libraries and development tools used to create enterprise applications.
The attack surface is no longer limited to the application itself. It now includes every dependency, every build system, every packaging mechanism and distribution channel that touches the software before it reaches production. Software supply chain risk continues to grow as organizations rely on an increasingly complex mix of open-source software, third-party vendors and AI components.
In response, Gartner recommends that CISOs require SBOMs (and AIBOMs) from all vendors and assess every component for risk using tools with up-to-date threat intelligence before deployment. They should:
- Curate repositories for third-party code, container images and AI models
- Enforce branch protection on code repositories
- Sign artefacts during builds
- Implement least-privilege access controls on build systems
- Monitor continuous runtime activity by agentic tools
This is the standard Gartner is setting. The question for enterprises is whether the infrastructure automation software running across their environments was built and delivered to that standard.
Infrastructure Automation Is Not Ordinary Software
Infrastructure automation tools that are deployed in an enterprise environment have numerous critical tasks to complete. These include:
- Running across servers, endpoints, cloud systems and critical infrastructure
- Operating with elevated access
- Installing packages
- Enforcing configuration
- Managing and maintaining compliance
- Executing changes across large fleets of machines
That means enterprises are not merely trusting the automation code. They are trusting the entire software supply chain behind it, from source code to binary, from dependency management to vulnerability response, from build platform to distribution channel.
A compromised package or unpatched dependency in a standard application creates a bounded exposure. But, a compromised package in an infrastructure automation agent creates exposure across every system where that agent runs. The reach is what makes the risk categorically different.
A Packaging Transition That Reframes the Risk Question
The Progress Chef team recently announced the eventual retirement of the Omnibus packaging system, the legacy build mechanism historically used to package Chef products. The rationale was clear: legacy build systems accumulate maintenance complexity, rely on aging platforms, carry a broad dependency surface and generate disproportionate overhead in managing CVEs and supply chain security. The Chef team is moving forward with Habitat-based packaging for current and future products.
This transition raises a critical question for enterprises using community-rebuilt distributions of infrastructure automation software.
When the original vendor retires a build mechanism, who assumes responsibility for organizations that do not move with it?
The answer, in the case of independently maintained distributions, is that the community must. And while community distributions can provide useful continuity, enterprises need to understand the full weight of what that means.
Who Now Owns the Build Chain?
When a downstream or community-maintained distribution continues to package software independently, it must take ownership of more than compiling source code. It must maintain the build infrastructure, manage dependency updates, validate packaging logic, manage the signing process, sustain the release pipeline, respond to vulnerabilities and provide long-term maintenance of the distribution.
This is a significant commitment. And it sits directly inside the threat vector Gartner has elevated to its highest priority category.
The concern is not whether the source code is open; but whether the software running across your infrastructure was built through a process your security team can verify, evidence and trust. Enterprise teams evaluating any infrastructure automation distribution should be asking these questions:
- Who maintains the build system, and is that system itself actively supported?
- Are the underlying build platforms current and patched?
- Are third-party dependencies validated against known vulnerabilities?
- Are distributed packages signed and verifiable?
- Is there a formal CVE response process with defined accountability?
- Who is responsible if the build pipeline is compromised?
- Can the organization provide audit evidence for how the software was built and delivered?
These questions are the operational translation of what Gartner is recommending at the CISO level. A capable attacker is already answering to identify the weakest point in your automation supply chain.
Availability Is Not the Same as Assurance
Community-maintained distributions can make software available. That is not the same as making it assured. Community distributions typically state that their builds are provided with no warranty or guarantee of fitness for enterprise use.
Available means the software can be downloaded and used.
Assured means there is documented accountability for who built it, how it was built, how vulnerabilities are identified and resolved and who is responsible when something goes wrong.
That distinction is now part of the formal risk calculus, validated by Gartner as a critical and unpredictable threat category. For organizations operating in regulated, security-sensitive or large-scale environments, the build chain is no longer a background concern. It is a front-line security question that belongs in every vendor evaluation and every infrastructure governance review.
The Commercially Supported Path Forward
The Progress Chef 360 platform provides a commercially supported path for organizations that require both the power of Chef automation and the supply chain assurance that modern enterprise environments demand.
Chef 360 is backed by product ownership from Progress, supported release processes, proactive security response and long-term lifecycle management. The platform brings together infrastructure management, compliance, job orchestration and AIOps capabilities in a unified environment. For organizations managing distributed infrastructure at scale, this means a single accountable vendor for the full automation stack, with the documentation, signed artifacts and security response processes that Gartner is now recommending as baseline requirements.
Gartner has made it clear that the core question every enterprise asking is:
Do you know who builds, secures and supports the automation software running across your infrastructure?
And Progress Chef 360 provides the answer to that question.
Start your Chef 360 trial today and move your infrastructure automation onto a platform built for the security, accountability and scale that the current threat landscape demands