Q002 — Barriers to Security Tooling Adoption in OSS — Assessment¶
Contents¶
Primary barriers are: lack of awareness, supply chain mistrust, high false positive rates (68-75% for SAST), setup complexity, and the perception that security features are unnecessary. Direct evidence for 'security fatigue' (spike-and-decline) is absent. The pattern is better characterized as persistent non-adoption. The Log4j case shows 13% still vulnerable 3+ years later despite a non-breaking fix, suggesting inertia rather than reversal.
Evidence Synthesis¶
Evidence quality: Medium — Strong academic evidence on barriers (Imtiaz et al. systematic study with 37 identified aspects). The OpenSSF/Linux Foundation survey provides maintainer perspectives. The SAST false positive rate data is quantitative and well-sourced. However, no quantitative longitudinal data on adoption spikes and declines post-incident was found. The 'security fatigue' concept is better documented as 'alert fatigue' in SOC literature than in developer tooling contexts.
Source agreement: High — All sources agree on the key barriers: supply chain mistrust, lack of automation, lack of awareness, false positive rates, and setup complexity. The Imtiaz et al. study, the OpenSSF blog, and the SAST comparison all converge on these themes from different angles. No source contradicts the finding that security tooling adoption faces significant barriers.
Independence: Moderately independent. Imtiaz et al. conducted original academic research (systematic study of 37 aspects). The OpenSSF blog summarizes a Linux Foundation survey. The konvu.com comparison draws on published benchmarks. These are three different research approaches arriving at consistent conclusions.
Probability Assessment¶
Confidence: Medium
Evidence Gaps¶
Expected but not found: - Longitudinal data on security tool adoption rates before and after Log4Shell (December 2021) - Time-series data on GitHub Actions security workflow additions and removals - Quantitative evidence for 'security fatigue' as a documented phenomenon in developer tooling - Data on security tool abandonment rates (not just non-adoption)
Unanswered questions: - Does security tool adoption actually spike and decline after incidents, or is the pattern simply persistent non-adoption? - What is the abandonment rate for SAST tools after initial adoption in open source projects? - Is the barrier primarily initial adoption or sustained maintenance? - How do barriers differ between solo-maintainer projects and team-maintained projects?
Impact on confidence: The barrier identification is well-supported (High confidence). The 'security fatigue' component is poorly supported (Low confidence) — no direct evidence was found for the spike-and-decline pattern, and the phenomenon may be better characterized as persistent non-adoption. This gap affects the article's framing but not its core argument.