They are now exploiting trust in open source environments via package injections, maintainer account compromises, dependency confusion attacks, poisoned CI/CD workflows, and build environment vulnerabilities.

For CISOs and DevSecOps leaders, however, the challenge lies in ensuring software provenance, dependency governance, build verification, and constant observation of runtime behaviors in more and more complex development environments.

Open Source Software Dependency in 2026

The development of enterprise software is becoming heavily reliant on open source systems. Rapid development, modularity, and cloud-native scalability have led companies to leverage the reuse of libraries, APIs, frameworks, and even containerized components extensively. 

While this approach has helped in boosting innovation, at the same time, this has led to a situation where trust has become a critical part of software development processes and security.

On an average, enterprise applications today depend on hundreds of third-party dependencies sourced from public repositories like npm, PyPI, Maven Central, and GitHub. 

Many of these also come with additional transitive dependencies that may not be easily noticeable by developers. Consequently, many times organizations are exposed to security risks arising from software packages that are beyond their control.

This rise in dependencies has led to an increasing gap between software usage and security management. 

By the end of 2026, the cybercriminal group “TeamPCP” or UNC6780 was responsible for several software supply chain compromises targeting popular GitHub repositories as well as their corresponding GitHub Action workflows related to projects like Trivy vulnerability scanner, Checkmarx, LiteLLM, and BerriAI. 2

It brought into sharp focus the growing menace of automation workflow compromise, as even one malicious change to a trusted GitHub repo could cascade quickly into enterprise development systems, cloud systems, and production pipelines.

Development teams tend to value rapid delivery more than dependency management, and security teams often find it difficult to keep up with fast-evolving software catalogs. 

Conventional perimeter defense systems are incapable of defending against any malicious software entering through legitimate software sources.

Several factors have contributed to this trust crisis:

1. Fatigue among Maintainers and Abandonment of Repositories

Open source maintainers still struggle under mounting pressures that do not correspond to the necessary security measures or financial investments. Many widely used libraries are still maintained by small volunteer teams.

Attackers often leverage this disparity through credential stealing, social engineering, malicious pull requests, and hijacking of the repositories.

Typically, attackers will focus on abandoned or neglected libraries with large enterprises implementing these libraries downstream. The compromised library allows attackers to deliver malware to multiple clients, thereby circumventing traditional security safeguards.

2. Risks Associated with AI-Assisted Development

The widespread use of AI coding assistants has added yet another layer of complexity to the software development supply chain. 

Google’s Secure AI Framework (SAIF) highlights emerging threats relating to prompt injection, sensitive data leakage, integration vulnerabilities, and AI supply chain exposure, especially as AI systems become increasingly connected to enterprise repositories, development environments, APIs, and operations. 3

There is a growing trend among developers to use AI-assisted coding tools without verifying the legitimacy of the package, its maintainer, or the origin of its dependencies.

In such a scenario, it becomes easier for attackers to exploit AI technology to create malicious packages, impersonate package maintainers, and launch social engineering attacks against developers.

3. Expanding Attack Surface Throughout CI/CD Pipelines

Today’s software delivery pipelines are characterized by extensive use of automation, cloud-native orchestration, and connectivity between build pipelines. The automated inclusion of external dependencies in CI/CD pipelines makes such environments vulnerable to threats, where the adversary tries to exploit the infrastructure for wide-ranging consequences.

Just one infected dependency in the build pipeline could spread through:

• Development environments

• Testing pipelines

• Production deployments

• Customer-facing applications

• Partner networks

4. Attack Patterns and Threat Tactics

Attackers seeking to exploit vulnerabilities within software supply chains have become much more sophisticated in their approach and capabilities. In lieu of directly attacking fortified enterprise networks, adversaries seek to breach trust-based software relationships.

An 89% increase in such attacks was noted to be executed by AI-driven attackers, emphasizing how automation, generative AI, and attack tools are facilitating cybercriminals’ ability to execute reconnoitering, phishing, malware production, and supply chain infiltration operations with greater speed than ever before. 4

5. Dependency Confusion Attacks

Dependency confusion is one of the most successful techniques for conducting supply chain attacks. The attackers distribute the malicious packages using the naming convention that imitates internal corporate packages or commonly used dependencies. 

Package managers will automatically download the malicious packages either while building or updating applications.

Organizations having weak segmentation practices in their package management systems are vulnerable to dependency confusion attacks. The attackers take advantage of default behavior in resolving the packages to breach the development pipeline without triggering endpoint security solutions.

6. Package Injection Attacks

There have been notable upticks in the number of malicious packages uploaded to public repositories. Such packages typically appear to be benign applications but actually include:

• Credential harvesters
• Remote access trojans
• Cryptocurrency miners
• Exfiltration tools
• Backdoors

A number of these malicious packages are purposely designed to bypass any automated scanning process through delaying tactics or via the use of obfuscation. Others lie dormant until deployment into enterprise networks that meet pre-defined criteria.

7. Compromised Maintainer Accounts

Hackers now often attack maintainers themselves via social engineering, MFA exhaustion techniques, session hijacking, and even token theft. Once a maintainer’s account is compromised, hackers can deploy malware through legitimate package updates with little suspicion.

Since most organizations trust established packages by default, any infected updates can quickly propagate across international software infrastructures without detection.

8. Poisoned CI/CD Pipeline Attack

CI/CD pipelines have emerged as highly valued targets for threat actors due to their direct access to:

• Source code
• Signing keys
• Cloud credentials
• Build/deployment environments
• Production infrastructures

Hackers poison build environments to modify software assets at the build or deployment stage. In some instances, malware can be injected dynamically during the build process, completely avoiding static source code reviews.

The GhostAction incident, which is believed to be one of the biggest supply chain attacks ever, was detected by GitGuardian on September 5, 2025. The GhostAction attack hit 327 GitHub users through their 817 repositories. 5

This attack vector poses significant risks because the manipulated assets will seem authentic from a cryptographic standpoint if hackers compromise the signing environment.

9. Malicious GitHub Actions and Workflow Exploitation

GitHub Actions and similar automation platforms are being abused to achieve persistence inside development pipelines. The malicious workflows can:

• Steal secrets
• Alter builds
• Compromise repositories
• Pivot into cloud infrastructures

The nature of automation scripts being used across multiple applications means that one malicious script can cause damage to an entire organization.

Impact Within Specific Sectors

Open source supply chain attacks have ramifications that go well beyond the software engineering team today. There are several sectors whose operations, regulatory obligations, and finances are all affected by software dependency compromises.

Financial Services

Financial organizations make extensive use of open source software frameworks to implement digital banking, payments, fraud analysis, and cloud-native application development services. The attack could affect transactions and compromise sensitive financial data.

Due to their complex ecosystem of vendors and API-based integrations, financial organizations can suffer simultaneous impacts from malicious dependencies in multiple operational environments.

Manufacturing and Industrial Processes

The increasing trend among industrial enterprises is that of cloud-based software, IoT, and software-defined operations technology being adopted into manufacturing processes. Weaknesses in industrial software stacks could result in exposure through:

• Manufacturing execution systems
• Supply logistics
• Industrial control systems
• Predictive maintenance

For attackers operating in such environments, disruption is the primary goal.

Critical Infrastructure

Critical infrastructure stakeholders are increasingly being challenged to update their software environments, yet they must ensure resilience. Unfortunately, visibility of the software within operational technology environments is still nascent.

Software update compromise or malware dependency that impacts energy, transportation, telecom, or water critical infrastructure might have significant national security repercussions.

Detection, Visibility, and Governance 

Many companies are still finding it difficult to establish visibility into their software ecosystem. Security professionals typically cannot generate an accurate inventory of:

• Third-party components 
• Transitive components 
• Software runtime behaviors 
• Build chain provenance 
• Permissions granted to developers 

Traditional vulnerability management solutions cannot be used to counter dynamic software supply chain issues since they mainly target known vulnerabilities, but not integrity or trust.

Adoption of SBOMs

Software bills of materials (SBOMs) have proven to be essential governance tools for enhancing dependency visibility. They allow organizations to track software parts, detect vulnerabilities, and respond to incidents that arise in their supply chain.

However, not all companies have fully developed SBOM automation processes to keep up with constantly changing dependencies in real time.

Software Composition Analysis (SCA)

SCA solutions play an integral role in organizational dependency governance approaches. They can help organizations discover the following:

• Libraries with vulnerabilities
• License compliance issues
• Package tampering
• Dependencies with outdated versions
• Repository reputation threats

Although many organizations have increasingly adopted SCA, most of them scan their dependencies at certain stages of development but not continuously.

Runtime Visibility Shortcomings

Static scanning is not enough to identify malicious activities during runtime. This is because attackers employ dormant malware, delayed execution techniques, and environment-aware payloads, which can evade pre-runtime scanning.

It is becoming necessary for organizations to incorporate runtime monitoring and analytics in order to detect malicious activities during runtime.

Governance and Mitigation Pathway

To solve the open source software trust challenge, enterprises need to make software provenance and dependencies an integral part of their cybersecurity strategy, not just an individual developer’s problem.

Recommended Strategic Controls

Establish SBOM Automation

Organizations should deploy automation for SBOM generation through all key development pipelines to enhance visibility and preparedness.

Secure CI/CD Pipelines

Controls include:

• Isolated build environments
• Least privilege access
• Signing artifacts
• Managing secrets
• Segregating pipeline
• Dependency Governance

Developer teams need to incorporate:

• Repository rules
• Dependency pinning
• Allow-listed packages
• Verifying maintainers’ trustworthiness
• Runtime Security

Continuous runtime security monitoring must address:

• Unusual package activity
• Unintended external communication
• Privilege elevation attempts
• Suspicious process activity
• Software Provenance Verification

Organizations should consider:

• Signed artifacts
• Provenance technologies
• SLSA controls
• OpenSSF recommendations

Framework for Enterprise Open-Source Supply Chain Resilience

With growing operational complexity in software supply chain attacks, there is a need for governance structures that go beyond vulnerability fixes. It now requires incorporating visibility, trust verification, real-time monitoring, and enterprise governance to be resilient.

The framework below shows an enterprise strategy for software supply chain resilience in 2026.

1. Dependency Visibility and Inventory Management

The organization needs to ensure the following:

• Direct dependencies
• Transitive dependencies
• Container components
• Build components
• Packages brought in by developers

Comprehensive SBOMs should be used as a starting point for governance for all development environments. If an organization does not have a reliable list of dependencies, it will be unable to properly evaluate its vulnerability exposure and pinpoint affected components in the event of a supply chain attack.

An important problem that many organizations will face in 2026 is dependency sprawl. Cloud-native apps frequently use dozens or even hundreds of interdependent packages spread across several repositories and development groups. In many companies, no formal approach to dependency management exists yet.

2. Software Provenance and Trust Validation

Trust assumptions associated with open-source software environments are becoming increasingly obsolete. Organizations have to verify:

• Package authenticity 
• Maintainer authenticity 
• Artifact integrity 
• Repository reputation 
• Software provenance 

Organizations need to implement solutions like:

• Artifact signing 
• Cryptographic verification 
• Provenance frameworks 
• Repository whitelisting 
• Package reputation metrics 

Frameworks like SLSA (Supply-chain Levels for Software Artifacts) and OpenSSF recommendations are gaining relevance in setting up trust levels for software within organizational development processes.

The move towards software provenance validation represents a wider industry trend of transitioning from trust assumptions to continuous software integrity verification.

3. CI/CD Pipeline Hardening

CI/CD environments have emerged as one of the most strategically important targets for attackers since they typically have privileged access to:

• Source code
• Deployment credentials
• Cloud infrastructure
• Signing keys
• Production environments

Companies should consider implementing:

• Isolation of build environments
• Least privilege access to pipelines
• Secret management
• Multi-factor authentication
• Separate deployment processes

Security teams must also ensure continuous monitoring of:

• Anomalies in builds
• Workflow tampering
• Automation abuse
• Abnormal artifact generation behavior

A compromised CI/CD pipeline can deploy malware across an entire organization’s environment without being detected by many traditional security systems.

4. Runtime Monitoring and Behavior Analysis

Dependency scanning on its own is not sufficient against modern supply-chain threats. Some packages are specifically crafted to avoid detection during pre-deployment scanning due to their deferred execution or environment-aware activation.

The requirement for runtime monitoring that can detect:

• Unauthorized outbound connections
• Privilege escalation
• Malicious process execution
• Abnormal package behavior
• Credential harvesting attempts

is growing because today’s supply-chain attacks favor persistence and lateral movement over payload delivery.

5. Governance, Ownership and Accountability of Executives

Supply chain software security can no longer remain a developer-only concern. For governance, it is critical that there is accountability among:

• Security teams
• Engineering executives
• Procurement
• Compliance
• Risk management
• Executive-level leaders

Organizations should create:

• governance of dependency policies
• standardized repositories
• processes for reviewing third-party software
• playbooks for dealing with supply chain incidents
• metrics for executive-level reporting on software trust maturity

As more regulations arise around the software provenance chain, companies may soon find themselves under pressure to prove governance maturity and software integrity.

Here’s Why Software Supply Chain Risks Are Increasing More Rapidly Than Conventional Protection Methods

The prevailing threat to the integrity of today’s software supply chains is not just due to more malware attacks. It is the consequence of structural shifts within the process of creating, distributing, and implementing software within organizations.

Conventional cybersecurity strategies have always focused on protecting perimeters, endpoints, and networks. The new software supply chain attacks leverage trusted connections found throughout the software development process.

This introduces a number of critical imbalances that benefit the attackers.

Trust Outpaces Security Verification

Contemporary software development practices are marked by a need for fast and automated development, along with modular code. Software developers frequently use other people’s APIs and libraries in order to save time. Unfortunately, the process of verifying security is lagging behind when compared to dependency management.

This leads to many organizations having to deal with significant unseen risks, including:

• transitive dependencies
• abandoned packages
• lack of verifications of package maintainers
• lack of security in build systems
• lack of secure third-party integrations

Open Source Environments Offer Leverageable Attack Surfaces

The fact that attacking just one component will enable attackers to access potentially thousands of organizations downstream is increasingly appreciated by attackers looking to maximize their leverage in cybercrime operations.

Unlike conventional ransomware attacks, which target an organization directly, attacking the software environment creates systemic vulnerabilities for:

• customers
• vendors
• partners
• cloud services
• MSPs

AI Is Expanding Adversaries’ Scale and Capabilities

AI-powered adversaries are transforming software supply chain attacks by enhancing automation, impersonation, and malware flexibility. 

CrowdStrike reports that organizations have seen a rise of 89% in the number of attacks carried out by AI-powered adversaries. This highlights how AI generation and automation tools allow adversaries to rapidly conduct reconnaissance, phishing attacks, package impersonation, and malware deployment. 4

The capabilities afforded by AI-powered attacks also allow adversaries to:

• Create believable fake repositories
• Automate malware packages production
• Expand credential phishing efforts
• Imitate legitimate developer activity
• Defeat static protection mechanisms

Visibility Is Still the Biggest Enterprise Weakness

Even with greater awareness, most companies do not yet have good visibility into their software environments. Security professionals usually do not know:

• Dependencies in production
• Behavior of runtime packages
• Build history
• Installation of unauthorized packages
• Relationships of software trust

The lack of visibility slows down incident response and hinders forensics after a supply-chain attack.

The Industry Is Shifting to Software Trust Governance

The cybersecurity industry is slowly moving from vulnerability-focused security approaches to comprehensive software trust governance models. This entails focusing more on:

• Implementation of SBOMs
• Provenance verification
• Signing of artifacts
• Runtime verification
• Repository trust scoring
• Design-based secure development

In the future, the task for organizations will not only be to thwart all malicious dependencies. It will be to establish robust governance structures that can continually assess software trust in highly distributed and automated development environments.

References

1. IBM X-Force Threat Intelligence Index
   IBM (2025) IBM X-Force Threat Intelligence Index. Available at: https://www.ibm.com/reports/threat-intelligence (Accessed: 15 May 2026).
2. Google Cloud Threat Intelligence Blog
   Google Cloud (2025) ‘AI vulnerability exploitation and initial access trends’, Google Cloud Blog. Available at: https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access (Accessed: 15 May 2026).
3. Google Secure AI Framework (SAIF) Risks
   Google (2025) Secure AI Framework (SAIF): Risks. Available at: https://saif.google/secure-ai-framework/risks (Accessed: 15 May 2026).
4. CrowdStrike 2026 Global Threat Report
   CrowdStrike (2026) 2026 Global Threat Report. Available at: https://go.crowdstrike.com/2026-global-threat-report.html (Accessed: 15 May 2026).
5. Your CI/CD Pipeline: An Attacker’s Favorite Backdoor
   InstaTunnel (2025) ‘Your CI/CD Pipeline: An Attacker’s Favorite Backdoor’, Medium. Available at: https://medium.com/@instatunnel/your-ci-cd-pipeline-an-attackers-favorite-backdoor-0303818f5058 (Accessed: 15 May 2026).