Contents
Summary
Query: Among well-resourced open source projects (Linux kernel, PostgreSQL, Node.js, Kubernetes, Python CPython), what CI and quality enforcement tooling do they actually run, and why do they build bespoke tooling rather than adopting standard commercial or open-source SAST/SCA scanners like CodeQL, Semgrep, and Trivy? Is there evidence that these tools are considered inadequate, too noisy, or inapplicable to large-scale projects?
Bottom Line: Direct evidence about the CI tooling decisions of the five named projects was not found through web search. Standard SAST tools have documented fundamental limitations (cannot detect business logic vulnerabilities, authorization bypass, race conditions; 68-75% false positive rates; combined detection of only 38.8%). These limitations provide a plausible rationale for bespoke tooling but the specific evaluation-and-rejection decisions are undocumented in available sources. The 'active rejection' framing is unsupported — the reality is likely passive non-adoption, historical path dependency, or complementary use.
Results
| Artifact |
Description |
| Input |
Original text, clarification, scope, vocabulary |
| Assessment |
Evidence synthesis, probability assessment, gaps |
| Self-Audit |
Process audit across 4 ROBIS domains |
| Reading List |
Prioritized source list |
Searches
| ID |
Target |
Returned |
Selected |
| S01 |
Linux kernel CI and quality tooling |
0 |
0 |
| S02 |
Kubernetes CI and quality tooling |
0 |
0 |
| S03 |
Patterns in bespoke vs. standard tooling across large projec |
0 |
0 |
| S04 |
CPython CI and quality tooling |
0 |
0 |
| S05 |
Patterns in bespoke vs. standard tooling across large projec |
0 |
0 |
Sources
| ID |
Title |
Reliability |
Relevance |
| SRC001 |
https://arxiv.org/html/2602.14572v3 |
High |
High |
| SRC002 |
https://www.chainguard.dev/unchained/wolfis-upstream-securit |
Medium |
High |
| SRC003 |
https://github.com/ossf/scorecard |
High |
High |
| SRC004 |
https://www.blackduck.com/blog/open-source-trends-ossra-repo |
Medium |
High |
| SRC005 |
https://www.scworld.com/news/open-source-vulnerabilities-per |
Medium |
High |
| SRC006 |
https://www.sonatype.com/state-of-the-software-supply-chain/ |
Medium |
High |
| SRC007 |
https://www.sonatype.com/state-of-the-software-supply-chain/ |
Medium |
High |
| SRC008 |
https://www.moderne.ai/blog/security-dependency-updates-unma |
Medium |
High |
| SRC009 |
https://konvu.com/compare/semgrep-vs-codeql |
Medium |
High |
| SRC010 |
https://arxiv.org/html/2605.07900v1 |
High |
High |
| SRC011 |
https://arxiv.org/html/2409.07669v2 |
High |
High |
| SRC012 |
https://openssf.org/blog/2024/01/31/maintainer-motivations-c |
High |
High |
| SRC013 |
https://link.springer.com/article/10.1007/s10664-023-10369-w |
High |
Medium |
Evidence Snapshot
| Dimension |
Rating |
| Evidence quality |
Limited |
| Source agreement |
Medium |
Revisit Triggers
- [study] A study or blog post documenting specific SAST/SCA evaluation decisions by Linux kernel, PostgreSQL, Node.js, Kubernetes, or CPython maintainers is published
- [organization] OpenSSF publishes a case study of how critical projects implement security scanning
- [study] The researcher conducts primary source research by examining project repositories and mailing lists directly
- [policy] CNCF publishes security tooling requirements or adoption data for graduated projects like Kubernetes
- [data_update] KernelCI or another project-specific CI system publishes documentation about its relationship to standard SAST/SCA tools
← Back to run overview