SAN FRANCISCO — July 6, 2026. Security leaders are more worried than ever about the software they didn't write. That's the headline finding from the latest Safeguard PulseMeter survey, a quarterly pulse-check on how security, engineering, and risk teams perceive supply chain threats. Fielded between June 8 and June 26, 2026, across 412 respondents spanning application security, DevSecOps, and platform engineering roles at mid-market and enterprise organizations, the report paints a picture of an industry that has accepted the software supply chain as a permanent attack surface — but still lacks confidence in its own ability to defend it.
The numbers are stark. 71% of respondents said they experienced at least one incident traceable to a third-party dependency, open-source package, or CI/CD misconfiguration in the past 12 months. That's up from 58% in the same survey a year earlier. Yet only 34% said they felt "very confident" their organization could detect a compromised dependency before it reached production. The gap between exposure and confidence is the story of this report — and it tracks closely with what Safeguard's own research and incident response teams have observed across customer environments over the same period.
A Widening Perception Gap
The PulseMeter data shows a familiar pattern: awareness has outpaced capability. Nearly every respondent (94%) said their organization now treats "software supply chain risk" as a board-level or executive-level concern, up sharply from 76% in 2024. That's the good news — supply chain security has graduated from a niche AppSec talking point to a line item in risk committee decks.
The less encouraging news is what happens after the board conversation. When asked to name the single biggest obstacle to actually reducing supply chain risk, the top three answers were:
- Alert volume without context (41%) — teams are drowning in CVE and SCA findings with no signal on what's actually exploitable.
- Lack of visibility into transitive dependencies (33%) — most tooling stops at direct dependencies, missing the second- and third-order packages where real risk often hides.
- No reliable inventory of what's actually running in production (26%) — SBOMs exist on paper for compliance, but aren't operationalized for detection or response.
This lines up with a trend Safeguard has flagged before: organizations are generating more security data than ever, but converting very little of it into action. Respondents estimated that their teams triage an average of 1,850 open-source vulnerability alerts per month, yet only act on roughly 9% of them — not because the rest are false positives, but because there's no fast way to tell which findings sit on a code path an attacker could actually reach.
Where the Risk Is Actually Concentrated
Perhaps the most useful data in this quarter's PulseMeter is the breakdown of where respondents believe supply chain compromise is most likely to originate. The distribution has shifted meaningfully since 2024:
- CI/CD pipeline compromise: 38% (up from 22%) — reflecting a wave of high-profile pipeline and build-system intrusions reported industry-wide over the past 18 months.
- Malicious or typosquatted open-source packages: 31% (roughly flat) — package registries remain a steady, if not growing, vector.
- Compromised or over-privileged CI tokens and secrets: 19% (up from 11%) — a direct reflection of secrets sprawl across build systems.
- Vulnerable but unpatched direct dependencies: 12% (down from 24%) — notably, the "classic" vulnerable-dependency scenario is perceived as declining in relative risk, likely because most organizations now have baseline SCA coverage for direct dependencies.
That last data point is worth sitting with. It suggests the industry has, to its credit, largely solved for the easy case — known CVEs in first-party manifests — and attackers (and defenders' attention) have moved to the harder cases: pipeline integrity, transitive risk, and identity/secrets hygiene inside build systems. Respondents who described their organization as "mature" in supply chain security were nearly three times more likely to say they had a formal CI/CD hardening program than those who described themselves as "early stage."
The SBOM Adoption Paradox
Software Bills of Materials continue to be simultaneously the most-adopted and most-underused artifact in the supply chain security toolkit. 83% of respondents said their organization now generates SBOMs for at least some production applications — a substantial jump attributable to continued regulatory pressure (NTIA minimum elements, EO 14028 follow-through, and sector-specific mandates now reaching mid-market suppliers, not just prime contractors). But when asked "does your team actively query or monitor your SBOMs for emerging risk," only 28% said yes. The rest characterized their SBOMs as compliance artifacts — generated, filed, and rarely opened again until the next audit or customer questionnaire.
This is the paradox PulseMeter keeps surfacing quarter over quarter: the data needed to answer "are we exposed to the thing that just got disclosed" already exists inside most organizations. It's just sitting in a PDF or a JSON blob nobody re-reads. Respondents who said they could answer "are we affected by a newly disclosed CVE" within one hour of disclosure were disproportionately the same respondents who described their SBOMs as "living" and machine-queryable rather than static compliance deliverables.
Team Confidence vs. Team Capacity
One of the more human findings in this quarter's data: burnout and headcount pressure are shaping perception as much as tooling gaps are. 62% of AppSec and DevSecOps respondents said their team is responsible for triaging more alerts than a year ago, with no corresponding increase in headcount. Nearly half (47%) said they've had to deprioritize a known finding in the last quarter purely due to lack of time to investigate it — not because it was judged low-risk.
That statistic should worry every CISO reading this report. It means that in a meaningful share of organizations, the difference between "patched" and "exploited" isn't risk analysis — it's whichever finding happened to get picked up before the backlog ran out the day. This is precisely the condition that automated reachability analysis and auto-remediation are designed to correct: when a human has to manually decide which of 1,850 alerts matters, fatigue and time pressure become de facto risk-acceptance policy.
What This Means for Security Programs
Taken together, the PulseMeter findings point to three practical priorities for the second half of 2026:
- Move from inventory to intelligence. Generating an SBOM is table stakes; the differentiator is whether that SBOM is continuously reconciled against new advisories and actually queryable in real time.
- Prioritize by reachability, not by CVSS score alone. With triage capacity flat and alert volume rising, teams need a way to separate "technically vulnerable" from "exploitable in our actual runtime," or they will keep deprioritizing real risk by accident.
- Treat the pipeline as the perimeter. With CI/CD compromise now the top perceived vector, hardening build systems, rotating and scoping tokens, and monitoring pipeline behavior deserve the same rigor historically reserved for production infrastructure.
How Safeguard Helps
Safeguard was built around the exact gap this survey quantifies: the distance between knowing you have a vulnerability and knowing whether it matters. Our reachability analysis engine traces call paths from declared dependencies — including deep transitive ones — into your actual application code, so teams can cut through alert volume and focus on the fraction of findings that are truly exploitable rather than triaging on CVSS score alone. Griffin AI, Safeguard's security reasoning engine, correlates that reachability data with runtime context and pipeline telemetry to explain why a finding matters and what changed since the last scan, turning static SBOM data into something teams actually query day to day instead of filing away for the next audit. Native SBOM generation and ingest keep a continuously reconciled inventory of every component in your software, across every repo and pipeline, so "are we affected by this new CVE" is a search, not a fire drill. And where a fix exists, Safeguard opens auto-fix pull requests directly against the affected manifest, closing the loop between detection and remediation without adding to an already overloaded backlog. If this quarter's PulseMeter findings sound familiar, that gap between awareness and action is exactly what Safeguard is built to close.