Source-linked AI summary
The Rising Cost of Trust: Practitioners' Trust Signals, Controls, and Responses in the Software Supply Chain
Ranindya Paramitha, Siri Paidipalli, Laurie Williams, Christian Kästner
TL;DR
The paper addresses the lack of an empirical baseline for how practitioners’ trust in the software supply chain is evolving as complexity, attacks, and AI reshape its risks. Through 38 semi-structured interviews focused on revealed preferences and grounded in social-science trust concepts, it finds eroding trust expressed through accumulating controls, with practitioners automating verification and delegating trust decisions to guardians. The authors use this trust framing to provide concepts for future interventions and behavior studies.
Problem
The study asks how practitioners’ trust in the software supply chain is evolving, addressing limited empirical understanding beyond subjective impressions.
Method
The authors conducted semi-structured interviews with 38 industry and open-source practitioners, analyzing revealed control actions through established social-science trust concepts.
Results
Practitioners’ controls accumulate and are rarely retired, indicating eroding system trust; they automate checks and delegate trust decisions to guardians.
Takeaways & Limitations
The trust lens supplies concepts such as guardians of trust and system trust for designing targeted interventions and establishing future behavioral baselines.
Takeaways & Limitations
The qualitative sample is not designed for quantification, and inferring trust from control actions remains an interpretive reading rather than a measurement.
Abstract
from arXiv · showhide
The software supply chain is becoming more complex, and AI is reshaping its threat landscape, e.g., raising concerns about the quality of AI-generated dependencies. Seen through the lens of trust, the stakes of eroding trust in the software supply chain are high, yet we lack an empirical baseline on practitioners' trust. The goal of this study is to aid software practitioners in taking informed actions as trust in the software supply chain evolves, through an interview study with 38 practitioners. We conducted semi-structured interviews with industry and open-source practitioners, focusing on their revealed preferences (the controls they adopted) rather than their stated attitudes, and analyzed the data using thematic analysis grounded in established trust concepts from the social sciences. We find that trust is eroding, which is becoming costly: aware practitioners are accumulating controls. To cope with the rising cost of trust, practitioners automate verification, delegate trust decisions to guardians, or consider exiting the software supply chain entirely. Understanding software supply chain dynamics through the lens of trust provides the vocabulary and concepts (e.g., guardians of trust, system trust, signals) to shape future interventions for a well-functioning supply chain with appropriate levels of trust.
I. INTRODUCTION
The paper examines whether practitioners are losing trust in the software supply chain by analyzing their actions rather than relying on stated attitudes. It finds accumulating controls and emerging mechanisms that relocate trust while increasing costs.
- The study asks how practitioners’ trust in the software supply chain is evolving amid increasingly prevalent attacks and AI-related uncertainty.The authors frame the question against visible supply-chain attacks, changing security practices, and unclear AI consequences.
- 38 practitioners were interviewed using revealed preferences, interpreting adopted controls through established social-science trust concepts.The study focuses on what practitioners do rather than what they say about trust.
- Accumulating controls and rarely retiring them indicate that trust in the supply chain as a system is eroding.The authors interpret persistent control actions as evidence of changing system trust.
- Practitioners automate checks and delegate trust decisions to intermediaries that pool effort and balance risk exposure against cost.These intermediaries function as guardians of trust, helping keep trust-related costs bearable.
- The trust lens contributes concepts for targeted interventions and establishes a baseline for studying future software supply-chain security behavior.The paper connects its conceptual framing, study design, and interview results to future intervention and trend research.
II. TRUST IN SOFTWARE SUPPLY CHAIN: BACKGROUND, FRAMING, AND RELATED WORK
The paper frames software supply-chain trust as reliance on a sociotechnical system spanning people, infrastructure, and norms. Because direct verification is costly, practitioners use partial controls and observable proxies to manage exposure.
- Software supply chains extend modular reuse across organizational and authorship boundaries, allowing developers to use components without understanding their internals.This arrangement makes trust relevant beyond a single software component or maintainer.
- Trust enables cooperation with low transaction costs, whereas mistrust requires extensive checking and verification.In software supply chains, eroding trust can undermine the efficiency benefits of reuse.
- System trust is confidence in the continued functioning of an arrangement of maintainers, infrastructure, community norms, and the broader ecosystem.Adopting a dependency entails judging this arrangement trustworthy enough to justify vulnerability.
- Controls are partial forms of checking, monitoring, or verification that reduce rather than eliminate risk exposure.Examples include checking selected updates, using README quality as a proxy, and running static analysis.
- The study infers trust from observable control actions using revealed preference theory instead of directly asking about subjective trust perceptions.Controls are treated as more directly observable than trust itself.
B. Signals and the Breakdown of Honest Signaling
Because direct verification is impractical at scale, practitioners rely on signals as proxies for component trustworthiness. Attackers and generative AI can make these signals cheaper to fake, undermining their reliability.
- Practitioners infer dependency quality and intent from signals such as star counts, contributor activity, README quality, maintenance history, and maintainer affiliation.These proxies help developers decide to trust without fully verifying code.
- Signaling theory explains why a signal can be informative when trustworthy participants can produce it more cheaply than untrustworthy participants.Historically, long maintenance histories provided this cost asymmetry.
- Attackers can game reputation signals by building plausible profiles or buying stars, as illustrated by the XZ Utils attack.These actions make projects appear more reputable than they are.
- Developers treat discrete control actions as substitutes for relying without checking, while broader control structures may also build trust at another level.The paper distinguishes its narrow action-level interpretation from literature treating trust and control as complements.
- Generative AI can lower the cost of mimicking trustworthy signals through high-quality READMEs and automated responses.When faking becomes cheap, the paper describes an ensuing breakdown of honest signaling and a market for lemons.
C. The Role of Attackers and the Shift to System Trust
The paper shifts attention from individual maintainer ability to system trust because supply-chain harm can arise from degraded signals, infrastructure, and ecosystem assumptions. It studies this framing through interviews with industry and open-source practitioners and concrete security practices.
- C. The Role of Attackers and the Shift to System Trust: System trust avoids blaming individual maintainers for failures arising in tightly coupled, complex systems.The authors note that maintainers are often additional targets rather than the source of harm.
- C. The Role of Attackers and the Shift to System Trust: Supply-chain attackers are not necessarily parties to trust relationships; they degrade the properties that make reliance reasonable.The paper identifies signals, infrastructure reliability, and expectations about non-weaponized trust as system-level properties.
- Study Design: The study conducted 38 semi-structured interviews with industry and open-source practitioners without using the term trust in recruitment or questions.Interviews covered dependency management, build systems, human factors, and related processes.
- Study Design: The study scopes software supply-chain security to the integrity of externally incorporated software, including dependencies, build and distribution infrastructure, and their maintainers.Practitioner discussions sometimes extended beyond this scope into broader security concerns.
- Study Design: Semi-structured interviews were chosen to elicit practices broadly and explore unanticipated directions that public artifacts only partially reveal.The sample combines open-source and industry practitioners because many relevant practices leave little public trace.
- Study Design: Questions anchored on concrete practices and timing were intended to reduce, though not eliminate, recall, social-desirability, and hindsight biases.The interview phases separately examined dependencies, build infrastructure, and human factors.
C. Recruitment and Participants
The study recruited 38 practitioners across industry and open-source settings using multiple channels, while acknowledging that these strategies shape whom the sample represents. Participants varied in geography, roles, and experience.
- The sample comprised 19 industry and 19 open-source practitioners with experience managing dependencies, build infrastructure, or human-factor risks.
- Open-source recruitment combined events with analysis of recent dependency and workflow changes in GitHub projects.Researchers manually analyzed 669 projects adopting dependencies and 267 extending builds, then contacted 395 eligible practitioners.
- Recruitment channels produced selection effects: professional-network recruiting favored industry practitioners already engaged with supply-chain security, while open-source targeting favored active maintainers.The authors accepted these effects to reach a specialist, difficult-to-contact population and discuss transferability separately.
- Participants represented North America, Asia, Europe, and Africa, with roles ranging from freelancers to chief officers and varied experience levels.Nineteen participants had more than five years of experience and 19 had fewer; the median interview lasted 57 minutes and 39 seconds.
D. Analysis
The researchers analyzed interview transcripts through iterative thematic coding focused on controls, trust targets, decision rationales, and changes over time. They used multiple-author refinement and an LLM as a redundant reliability aid, while treating the findings as interpretive rather than quantitative.
- Analysis: The study applied thematic analysis to 928 transcript pages from 38 interviews, refining themes iteratively.
- Analysis: Coding tracked controls, reasons for adopting or rejecting them, changes in controls, and the rationales for those changes.
- Analysis: Coders classified each passage across five dimensions: decision-maker, trust target, whether trust was imposed or implicit, decision rationale, and control change.
- Theme Development and Finding Synthesis: The authors iteratively grouped controls and trust targets into themes including personal versus system trust, delegated decisions, and external forces shaping adoption.
- LLM-Assisted Reliability Improvement: An LLM was used as an additional reliability check rather than to replace researchers’ judgment.
- Limitations: The qualitative sample describes observed practices and reasoning rather than population distributions, and trust inferences remain interpretive readings rather than direct measurements.
IV. RESULTS
The results indicate that practitioners are accumulating controls as trust in the supply chain erodes, while adapting through automation, delegation, and reliance on signals. Trust is extended both deliberately and by default, and AI is beginning to pressure traditional signals without yet broadly undermining system trust.
- A. Partially Eroding Trust in the Software Supply Chain: Practitioners add controls across dependencies, build infrastructure, and human factors, and rarely retire them unless replacing them.Newer controls are increasingly automated and AI-based, suggesting growing costs associated with maintaining trust.
- B. Coping with Eroding Trust: Participants increasingly automate dependency scanning, CI/CD security gates, SBOM generation, and other checks.Examples include Snyk, Dependabot, GitHub Copilot, and Claude, alongside deliberate delays before updating dependencies.
- A. Partially Eroding Trust in the Software Supply Chain: Trust is often extended by default when risks and controls are not salient, through intuitive judgments, community practices, or limited awareness.
- A. Partially Eroding Trust in the Software Supply Chain: Many practitioners rely on cheap signals such as dependency popularity, maintainer activity, documentation quality, and community recommendations.The authors interpret reliance on these signals instead of deeper checks as persisting system trust.
- A. Partially Eroding Trust in the Software Supply Chain: AI recommendations are replacing some community recommendations, often with only manual checks of popularity and activity signals.
- A. Partially Eroding Trust in the Software Supply Chain: Only a few participants raised concerns that popularity and documentation signals could be faked through coordinated activity or AI.The authors report that AI had not yet broadly undermined system trust during the interviews, though this may change.
- A. Partially Eroding Trust in the Software Supply Chain: Trust in people remains personal, relying on relationships and behavioral track records for interpersonal supply-chain decisions.
B. Relocating Trust through Automation and Delegation
As trust erodes, practitioners relocate trust to automation and guardians to keep verification costs bearable, while a few consider avoiding dependencies altogether.
- Automation: Manual controls are increasingly automated because auditing and inspection scale poorly, making automation a new object of trust.Automated scanning and infrastructure checks reserve manual attention for issues surfaced by tooling.
- Automation: Practitioners often combine tools or retain manual checks because automation can fail systematically and is trusted selectively, especially for AI quality.Some use multiple tools or AIs to catch one another’s failures, and trust AI differently depending on who controls it.
- Delegation: Some practitioners delegate trust decisions to security, compliance, or external guardians and adopt cleared components with little independent control.Guardians include organizational teams, licensed dependency providers, and marketplaces.
- Delegation: Other practitioners delegate control-setting to guardians, accepting recommended or enforced regimes that cap how far they may extend trust.These regimes can reduce decision complexity, but may require more controls or prevent developers from bypassing checks.
- Exit: Avoiding third-party dependencies is rare but appears as a possible AI-assisted response when producing a component costs less than controlling an untrusted dependency.This strategy is limited by component scale: participants described replacing small dependencies, not frameworks such as Spring.
C. Control Adoption to Build Trust
Controls are adopted not only to reduce practitioners’ own exposure, but also to signal trustworthiness and satisfy requirements imposed by clients, markets, and regulators.
- Trust-building signals: Practitioners adopt attestations, certifications, SBOMs, reproducible builds, and documented policies to appear trustworthy to downstream users.These controls function as signals because they are difficult to mimic.
- External requirements: Some controls are externally imposed by clients and regulators rather than voluntarily adopted for risk reduction or signaling.Requests include SBOMs, legal review, and compliance with contractual or regulatory standards.
- External requirements: Requirements from major clients and governments can become templates adopted voluntarily by organizations outside the original contractual or regulatory scope.The paper describes this as a bridge from imposed controls to voluntary signaling.
V. DISCUSSIONS, IMPLICATIONS, AND CONCLUSION
The discussion frames the paper’s goal as calibrating an appropriate level of system trust rather than restoring blind trust.
- The paper argues that software supply chain trust should be calibrated to an appropriate level rather than restored as blind trust.
A. Reading Trust from Revealed Preferences
The paper interprets practitioners’ observable actions through system-trust theory, showing how low trust increases verification costs and motivates delegation to guardians.
- Reading trust from action: Practitioners’ actions provide a way to study system trust, which is difficult to access through introspection until disruption occurs.The theory lens also distinguishes similar controls adopted for mistrust from those adopted to build trust.
- System trust: System trust concerns confidence in the software supply chain as a sociotechnical arrangement rather than trust in an individual maintainer.The arrangement includes maintainers, infrastructure, community norms, and the broader ecosystem.
- Low-trust consequences: Low trust increases verification and transaction costs, while practitioners who trust dependencies are more willing to engage with them.Interview accounts include both installing many packages comfortably and withdrawing from packages after trust loss.
- Guardians: Delegation pools checking effort through guardians, reducing repeated verification while requiring trust in guardians’ competence.The paper identifies external guardians that vet once for many as a promising direction, while distinguishing AI from shared guardians because it lacks pooling and accountability.
- Guardian limitations: Guardians concentrate rather than eliminate the trust problem, creating high-value targets and risks of incumbent entrenchment that require oversight.The paper recommends standards, certification, redundancy, and oversight for guardian institutions.
D. Calibrating Trust in Software Supply Chain
The study frames eroding trust as a calibration problem: excessive trust carries hidden risk, while insufficient trust imposes costly controls. Practitioners are reorganizing trust through automation, guardians, and external requirements rather than abandoning the supply chain.
- D. Calibrating Trust in Software Supply Chain: Overtrust hides security risks, whereas undertrust creates excessive controls that may exceed the risks they address.The paper therefore treats trust calibration—not simple restoration—as the central challenge.
- D. Calibrating Trust in Software Supply Chain: Trust calibration should match control levels to dependency criticality and signal quality.The paper contrasts stronger signals such as attestation with popularity alone and recommends closer scrutiny for higher-risk dependencies.
- E. Return to the Opening Question: The study supports eroding trust, but presents a more nuanced and less bleak picture than a simple collapse into low trust.Practitioners’ costly actions provide this evidence rather than stated opinions.
- E. Return to the Opening Question: A high-trust regime is reorganizing under adversarial pressure through automation, guardians who vet once for many, and external trust-building forces.These mechanisms, rather than the trend direction alone, are identified as targets for future tools, policies, and governance.