It is clear from the updated data and research in The Verizon 2026 Data Breach Investigations Report (DBIR) that attackers are still winning, overall, through access. 

Credentials still decide how far many attacks can go. Exploited vulnerabilities are now the most common initial access vector for breaches at 31%, up from 18% in the previous report. Credential abuse appears at 13% as an initial vector, down from the high of 22% a year prior. However, when Verizon looks across the full breach progression, credential abuse appears in 39% of breaches. 

Their research shows that a vulnerable application can create the first foothold. And so can a compromised vendor, a malicious package, a remote access tool, or a web application flaw. After that, attackers need access that works. Passwords, API keys, OAuth tokens, service account credentials, cloud keys, deployment tokens, and any standing permissions shape the blast radius. Secrets leak in where software teams work, as documented in the GitGuardian 2026 State of Secrets Sprawl Report, including the communication platforms and ticketing systems that engineers rely on. 

The DBIR shows credentials as connective tissue across modern attacks. Different entry points converge on the same practical need. Attackers need usable access.

DevSecOps Runs On Non-Human Access

DevSecOps sits directly on the systems where credentials accumulate.

Application teams need API keys to connect services, and platform teams need cloud credentials to automate infrastructure. CI/CD pipelines need tokens to build, test, and deploy software, while observability tools need access to logs and telemetry. 

And a lot of these end up on the developers' machines who build and use these systems.

Each workflow creates a trust path. Each trust path usually depends on a secret, token, certificate, key, service account, or machine identity.

Secret scanning helps teams find exposed credentials at scale. The larger challenge is the way modern software delivery depends on non-human access. That access is often long-lived, duplicated, overprivileged, and poorly owned.

A leaked password creates an obvious risk. A leaked deployment token can lead to greater operational exposure. A cloud key with broad permissions can become infrastructure control. A database credential found in an old repository can still unlock production data when rotation never happened.

These all become reusable access for anyone who finds them. 

Entry versus Expansion

Entry gives the attacker a foothold. Expansion turns that foothold into impact. Credentials sit at the center of expansion.

Once inside an environment, attackers look for leverage. They check which identity they are running as and query cloud metadata. They inspect environment variables while searching for mounted secrets, readable build logs, and developer tokens, among other things.

Credential sprawl gives attackers options. A token exposed in a build log may still grant access to a package registry or deployment workflow. That access can reveal environment variables, release configuration, artifact metadata, or additional secrets used by downstream jobs. The attacker does not need every credential at once. They need one valid credential that reaches a trusted part of the software delivery path, then they use that trust to look for the next opening.

Security teams need to know what a secret unlocks, where it appears, whether it is still valid, who owns it, how it is rotated, what depends on it, and what would break if it were revoked.

Real-world delays often start there. The owner is unclear. Is the service account shared? Is the integration business-critical? The rotation process is manual, so changing the credentials feels operationally risky, so they remain active.

Attackers benefit from that hesitation.

Third-party Trust Is Also Vulnerable

Third-party involvement reached 48% of total breaches, up from 30% last year. Given the way we build modern applications and run our internal platforms and business systems, that should give us pause. 

Modern delivery environments are stitched together with vendors. Code repositories, cloud providers, CI/CD platforms, artifact registries, ticketing systems, and software-as-a-service applications all exchange trust.

They exchange that trust mostly through access grants, tokens, service accounts, OAuth applications, shared secrets, and API keys.

The Salesloft Drift and Salesforce breach of 2025 is a good example of the problem. Customer OAuth tokens, or the keys to derive them, were compromised from the Salesloft Drift application and then used against Salesforce to steal customer data. OAuth is an authorization framework that lets applications access data without directly sharing passwords. In practice, it can create powerful trust paths across software-as-a-service environments.

Delegated Authorization Became The Attack Path

The same pattern shows up across DevSecOps tooling. A CI/CD token may let a vendor read repositories. A cloud integration may let a platform create infrastructure. A security scanner may need broad repository access. A support integration may hold customer data access. A deployment webhook may trigger production workflows.

These permissions are granted for good reasons. They often live longer than the project, owner, or business needs that created them.

Credentials become governance debt when integrations outlive their context. The organization may know the vendor exists. It may have limited visibility into every token the vendor holds, every scope assigned to that token, every repository it can read, every environment it can reach, and every stale integration still in place.

One trusted integration can give attackers a cleaner path than a direct attack against the enterprise.

Ransomware Monetizes Valid Access

Ransomware remains one of the clearest reasons credentials deserve priority. Nearly half of breaches in the report feature ransomware somewhere in the attack chain. Ransomware appears in 77% of breaches under the System Intrusion pattern category, where attackers gain access to systems, as opposed to Denial-of-Service attacks. 

The attacker needs enough privilege to move, discover data, disable defenses, exfiltrate files, encrypt systems, pressure the victim, and sustain leverage. Every one of those steps becomes easier with valid credentials.

Stolen credentials let attackers look like normal users. They can use trusted remote access tools. They can access administrative consoles. They can query cloud resources. They can reach backups. They can return after initial containment when credentials remain valid.

The DBIR shows stolen credentials holding steady at 36% across breach action varieties. In System Intrusion, stolen credentials and exploited vulnerabilities are both common initial access vectors, at 39% each. In Basic Web Application Attacks, stolen credentials remain the top action, and credentials are compromised in 52% of breaches in that pattern. In Public Administration, stolen credentials appear in 59% of hacking-related breaches.

Credentials Are Reusable Attacker Assets

A closed vulnerability, removed malicious package, or rebuilt host can still leave a copied API key, password, token, or service account credential in circulation. The credential keeps working until it is found and revoked

Incident response needs credential exposure analysis as a core motion. Teams need to identify which secrets were present on affected systems, which logs the attacker could read, which CI/CD variables were accessible, which cloud roles were reachable, which service accounts authenticated during the intrusion window, which tokens were created or refreshed, and which credentials were duplicated across environments.

(Shadow) AI Creates More Credential Exposure Paths

This year's DBIR frames AI as an accelerator across familiar attacker behaviors. It shows how threat actors are using generative AI across targeting, initial access, malware development, and tooling. AI helps attackers move faster, produce more convincing pretexts, automate routine work, and scale operations.

The report notes that 67% of users access AI services with non-corporate accounts on corporate devices. Regular AI use on corporate devices rose to 45% of employees, up from 15% the previous year. Shadow AI is now the third most common non-malicious insider action in the data loss prevention dataset, with a 4x percentage increase from the prior year.

The most common data submitted to external generative AI models was source code, followed by images and structured data. In 3.2% of data loss prevention policy violations, research and technical documentation were uploaded to unauthorized AI systems.

Source code often carries more than application logic. It may include hardcoded secrets, test credentials, internal endpoints, infrastructure details, authentication flows, sample configuration, deployment scripts, and references to systems intended for internal use.

Browser extensions add another layer of risk. The report notes that the average company had more than 15% of users with unauthorized AI extensions installed. Some tools collect and retain browsing context, including repositories, pull requests, issue trackers, runbooks, cloud dashboards, internal documentation, customer records, and incident notes.

Each well-intentioned action can move secrets or secret-adjacent data outside governed systems.

Ownership Turns Detection Into Action

Non-human identities always have an owner, a lifecycle, a login pattern, and a departure process. This is true even if you do not have a governance plan in place. The plan is just chaos.

Service accounts, deployment tokens, automation keys, machine users, OAuth applications, certificates, webhook secrets, and cloud roles often exist because a workflow needed them at some point.

Then the workflow changes. The owner moves teams. The project gets renamed. 

The integration keeps working, so no one touches it. That is how credentials become permanent infrastructure.

Rotating a secret sounds simple until no one knows which jobs use it. Deleting an old service account sounds responsible until a legacy integration breaks at midnight. The result is that broad access stays broad and long-lived credentials stay long-lived. Stale secrets stay active because the operational risk of change feels more immediate than the security risk of leaving them alone.

The better path is visibility, ownership, validation, and workflow. Teams need to identify where secrets exist, confirm their validity, assign ownership, understand what they unlock, and rotate or revoke them without guessing.

That work is how you build resilience.

GitGuardian Fits Where Modern Work Happens

GitGuardian helps teams reduce credential exposure across the places where software delivery actually happens. The platform finds and tracks secrets where they show up, across source code repos, build logs, containers, SaaS tools, vaults, identity providers, and collaboration systems. It gives you insight into developer workstations and CI/CD pipelines where secrets are copied, reused, logged, pasted, embedded, tested, committed, and forgotten.

That visibility changes how teams manage credential risk before and after an incident. Before an incident, GitGuardian helps developers prevent secrets from staying in plaintext on laptops and entering repositories or pipelines. ggshield pre-commit and AI hooks, and AI agent skills-driven workflows give developers guardrails in their daily work, reducing friction and catching exposure closer to the source. 

Detection extends across code, endpoints, CI/CD, and other reachable environments that attackers may inspect after gaining access.

For incident response, any investigation depends on context. Teams need to know where a secret appeared, whether it is still valid, who owns it, what it unlocks, and what downstream systems may depend on it. GitGuardian supports remediation workflows that help security and DevSecOps teams prioritize action, coordinate fixes, and rotate or revoke exposed credentials at scale.

The platform also supports the shift from isolated secret detection toward broader non-human identity governance. Secrets visibility becomes more powerful when it connects with secrets vaults, SaaS applications, and identity providers. 

That connection helps teams build a more complete inventory of secrets and identities, identify ownership gaps, spot over-permission issues, and address unauthorized access across machine identities, service accounts, and automation keys.

The Credential Map Is The Resilience Map

Vulnerability exploitation may lead to initial access, and third-party involvement may define modern breach paths, while ransomware ultimately may drive the economics. Across all the breaches that Verizon investigates, credentials keep reappearing as the mechanism that turns exposure into movement, movement into data access, and data access into impact.

We must build a map of how trust is established in our organizations. We must know: 

• Which secrets exist
• Where they live
• If they are valid 
• Who owns them 
• What permissions do they carry
• Which systems depend on them
• How to rotate them, safely and quickly, when trust breaks

That work is incident readiness. That work results in resilient systems that can withstand whatever attackers come up with next. 

In a breach landscape defined by trust sprawl, the organizations that recover fastest will already know where their credentials are, what they unlock, and how to shut them down before attackers turn them into leverage.