How to Strengthen Security Across Your Technology Supply Chain

A trusted piece of software can become a security threat without its users realizing anything is wrong. That risk came into sharp focus this year, when a cybercrime group known as TeamPCP poisoned widely used development tools and open-source packages, harvesting credentials from build pipelines and, according to investigators, potentially compromising more than 1,000 organizations worldwide. The campaign illustrates a troubling reality: Organizations can inherit serious cybersecurity risks through technology they didn’t build and may not even know they depend on.

The problem extends well beyond compromised code. According to Verizon’s 2026 Data Breach Investigations Report, third parties were involved in 48% of breaches, up from 30% in the previous year’s report. That exposure can come from software suppliers, vendors that host an organization’s data or partners with access to its systems—and increasingly from more than one at once. But supply chain risks also extend into the technologies and processes organizations use to develop and operate their own systems, creating potential blind spots even for companies with substantial security investments.

Taken together, the recent attacks and growing third-party exposure raise a pointed question for senior executives: What are their current security strategies missing? Members of the Senior Executive Cybersecurity Think Tank bring extensive experience in enterprise security, risk management, secure software development and cybersecurity leadership. Below, three of them examine where established protections are falling short and what a more mature approach to managing these interconnected risks should look like.

“A mature approach applies production-grade controls to the pipeline itself: ephemeral build environments, short-lived credentials, and isolated signing and monitoring of the tools developers use.”

– Harikrishnan Muthukrishnan, Principal IT Developer at BCBS FLORIDA

SHARE IT

Secure the Systems That Build the Software

Harikrishnan Muthukrishnan, Principal IT Developer at BCBS FLORIDA, draws on his experience with DevSecOps and complex IT modernization projects to highlight an important distinction between protecting software and securing the infrastructure that produces it.

“Most supply chain investment went into scanning what gets built: dependencies, containers and software bills of materials,” Muthukrishnan says. “Attackers moved to the things that do the building: the CI runner, the deploy credential and the developer laptop with standing access to production. A signed artifact means little if the signing key sits on a build server anyone can reach.”

He argues that leaders have too often treated the supply chain as a collection of components rather than an interconnected system of trust while leaving development infrastructure outside the security perimeter because it was considered engineering’s responsibility.

“A mature approach applies production-grade controls to the pipeline itself: ephemeral build environments, short-lived credentials, and isolated signing and monitoring of the tools developers use,” Muthukrishnan says. “They must be treated with the same seriousness as customer-facing systems.”

Look Beyond the Vendor Checklist

For Ken Grohe, President of LeverageGTM, Inc., a central concern is the disconnect between organizations’ faith in their supply chain defenses and their actual exposure. 

“According to the 2026 Supply Chain Cybersecurity Trends Report, 90% of security leaders are confident their organization could weather a vendor breach seamlessly, yet 86% express deep anxiety over overall supply chain risk,” Grohe says. “This overconfidence creates an executive disconnect between perceived defense and actual technical vulnerability.”

Grohe questions whether conventional assessments provide the level of assurance executives expect.

“Traditional third-party risk management leans heavily on periodic, point-in-time tools like annual questionnaires, penetration tests or compliance certificates,” he says. “Filling out a questionnaire checks a box; it does not reduce technical risk.”

Grohe notes that the report also says 78% of organizations acknowledge that their internal programs fail to cover more than half of their total vendor ecosystem.

“Organizations secure their tier-one vendors but remain entirely blind to the fourth- and fifth-party dependencies woven into their software pipelines,” he says.

Grohe concludes by highlighting one of the report’s more troubling findings: 60% of organizations require eight days or more just to begin fixing critical supply chain risks.

“That’s a massive window of exposure for attackers,” he says.

“You need continuous, outside-in visibility into every AI tool, AI asset and third-party dependency touching your environment, not a one-time review at adoption.”

– Kumar Ritesh, Founder, Chairman and CEO of CYFIRMA

SHARE IT

Bring Hidden Dependencies Into View

Kumar Ritesh, Founder, Chairman and CEO of CYFIRMA, brings experience in national cyber intelligence and corporate cybersecurity leadership to his assessment of today’s supply chain risks.

“Most organizations still treat supply chain security as a checklist: scan the code, verify the SBOM and tick the compliance box,” Ritesh says. “But the ecosystem has moved faster than the checklist.”

He points to emerging technology dependencies as a particularly important part of that changing environment.

“Today, attackers exploit AI assets, like models and training data nobody inventoried; trusted AI tools embedded in workflows; and open-source components pulled in without a second look,” he says. “We secured the software while ignoring everything now plugged into it.”

For Ritesh, addressing these exposures requires a broader, continuously updated understanding of the technologies and third parties connected to an organization’s environment.

“A more mature approach starts with knowing what you actually have,” he says. “You need continuous, outside-in visibility into every AI tool, AI asset and third-party dependency touching your environment, not a one-time review at adoption.

“Treat every AI integration and every borrowed component as a potential entry point, monitor it accordingly, and assume the next compromise arrives through something you trusted without truly looking at it,” he concludes.

Actionable Strategies: Strengthening Supply Chain Security

• Protect development infrastructure as rigorously as production systems. Apply strong security controls to build environments, deployment pipelines and developer tools, not just the software they produce.
• Limit access to sensitive systems and credentials. Use temporary build environments, short-lived credentials and isolated signing processes to reduce opportunities for attackers to exploit trusted development infrastructure.
• Look beyond traditional vendor assessments. Supplement periodic questionnaires and compliance reviews with ongoing monitoring of third-party risks, including dependencies beyond direct suppliers.
• Make faster remediation a priority. Establish clear processes and timelines for addressing critical supply chain vulnerabilities to minimize the window of opportunity for attackers.
• Identify overlooked technologies and dependencies. Maintain a comprehensive inventory of AI tools, models, training data and open-source components connected to the organization’s systems.
• Continuously evaluate trusted integrations. Monitor third-party components and AI integrations throughout their use rather than assuming an initial security review provides lasting assurance.

Rethinking the Boundaries of Trust

Cybersecurity risks don’t necessarily originate in unfamiliar or obviously suspicious places. They can emerge from trusted development tools, established business relationships and technologies already embedded in everyday operations. Even organizations with substantial security investments may remain vulnerable if their defenses don’t account for the full range of systems, processes and connections their businesses depend on.

As technology ecosystems become more complex and interconnected, determining what can be trusted—and for how long—will become an increasingly important leadership responsibility. A more resilient approach requires continuous visibility, stronger oversight and the ability to respond quickly as new vulnerabilities emerge. Ultimately, the challenge isn’t simply to protect individual systems but to understand and manage the risks created by the connections between them.