diff --git a/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/READEME.md b/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/README.md similarity index 90% rename from tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/READEME.md rename to tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/README.md index 311b8ffa8..1aa046b7f 100644 --- a/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/READEME.md +++ b/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/README.md @@ -18,8 +18,7 @@ Rather than proposing a new framework, the initiative emphasizes learning from w ## Deliverable(s) or exit criteria * Secure DevEx Pain Point & Usability Report: Findings from maintainers and contributors, with actionable recommendations. -* Maturity Case Studies: Extracted lessons from established CNCF projects to illustrate effective approaches others can adopt. ## Tracking document for meeting and progress -https://notes.cncf.io/PchBX0teSauZcRGIVjEG6g \ No newline at end of file +https://notes.cncf.io/PchBX0teSauZcRGIVjEG6g diff --git a/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/survey-results-analysis.md b/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/survey-results-analysis.md new file mode 100644 index 000000000..426dc4c11 --- /dev/null +++ b/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/survey-results-analysis.md @@ -0,0 +1,212 @@ +# Survey Results Analysis: Secure Coding Practices in CNCF Projects + +Source: `tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/survey-results-secure-coding-practices.csv` + +> Note: source CSV in this directory is sanitized. Timestamps and direct contact details were removed or redacted. Project names and public technical references were preserved. + +## Summary + +This survey produced a **small but useful directional dataset**. The strongest signal is that **projects are more constrained by time, clarity, and workflow fit than by philosophical resistance to secure coding**. + +The survey has been communicated extensively in ~20 Slack channels of maintainers and contributors over the course of 8 weeks and **has not received many answers (13) compared to a similar survey TAG DevEx has done around AI within the CNCF that has received 200+ answers** from the same targeted personas. This divergence implies that AI disruptions are currently top-of-mind for CNCF project maintainers and contributors compared to security practices. + +The data suggests five headline findings: + +1. **Awareness of TAG Security & Compliance guidance is low.** Most respondents rated their familiarity at the low end of the scale. +2. **Projects often have security practices, but they are usually informal.** Only one response clearly indicated an established and documented standard. +3. **The main adoption barrier is maintainer bandwidth.** Time and contributor capacity dominated both structured and free-text answers. +4. **Low-friction wins are mostly automation and repository guardrails.** Dependabot, CodeQL, branch protections, audits, and signing were the clearest success stories. +5. **Friction is concentrated in adoption and remediation, not daily contribution flow.** Most respondents said secure coding practices had not blocked development, but they did report false positives, tooling complexity, and workflow mismatch. + +## Methodology and data quality notes + +- Raw submissions: **13** +- Responses included in analysis: **12** +- Excluded: **1 likely junk/accidental row** (`sdfsadf`) with only two populated cells +- Sample size is **small**, so findings should be treated as **directional**, not representative +- The sample is **heavily skewed toward the OpenTelemetry ecosystem** +- The CSV exports numeric scale values. These should be interpreted as **higher numbers are more positive / higher familiarity** +- One included response listed the project as `No`; it appears to be a valid response with an invalid project name, so it is treated as **unknown project** rather than dropped + +## Respondent profile + +### Project mix + +Project names were normalized where obvious (for example, `Open Telemetry`, `OpenTelemetry`, `opentelemetry`, `opentelemetry-injector`, and the OpenTelemetry .NET repo links were grouped together). + +| Normalized project family | Responses | +| --- | ---: | +| OpenTelemetry ecosystem | 6 | +| TAG DevEx | 1 | +| Kubeflow | 1 | +| Argo Rollouts | 1 | +| Kubescape | 1 | +| Prometheus | 1 | +| Unknown / invalid project name | 1 | + +### Contributor roles + +| Role answer | Responses | +| --- | ---: | +| Developer + DevOps / CI/CD / infrastructure | 10 | +| No role provided | 2 | + +Interpretation: this survey mostly reflects the views of **hands-on contributors and maintainers working in both code and delivery pipelines**, not pure security specialists. + +## Detailed findings + +### 1) TAG Security & Compliance awareness is low + +| Familiarity rating (1 to 5) | Responses | +| --- | ---: | +| 1 | 6 | +| 2 | 4 | +| 3 | 1 | +| 4 | 1 | + +- **10/12 (83%)** rated familiarity **1 or 2** +- Average: **1.75 / 4** +- Median: **1.5 / 4** +- Even among low-familiarity respondents, **5/10** still reported at least informal standards + +Takeaway: projects appear to be doing some security work, but often without linking it to TAG Security & Compliance guidance. + +## 2) Standards mostly exist as informal practice + +| Current standards status | Responses | +| --- | ---: | +| Yes, informal / implicit | 6 | +| Yes, established and documented | 1 | +| Not sure | 4 | +| No | 1 | + +- **7/12** reported some form of standard +- Only **1/12** reported something clearly established and documented +- Detailed examples often described broader controls: **OWASP practices, `SECURITY.md`, RBAC, branch protection, artifact signing, 2FA** + +Takeaway: respondents often interpreted **secure coding** broadly as overall project security hygiene, not only coding standards. + +## 3) Security and delivery speed look compatible + +| Balance rating | Responses | +| --- | ---: | +| 1 | 1 | +| 2 | 1 | +| 3 | 3 | +| 4 | 4 | + +- Answered by **9/12** respondents +- Average: **3.11 / 4** +- Respondents with any standards averaged **3.43 / 4** +- Respondents with **`No`** or **`Not sure`** averaged **2.0 / 4** + +Takeaway: some structure seems to reduce perceived tradeoff between security and velocity. + +## 4) Biggest pain point is maintainer time + +This question allowed multiple selections. + +| Pain point | Mentions | Share of respondents who answered the question | +| --- | ---: | ---: | +| Lack of contributor time | 7 | 64% | +| Lack of clear best practices | 4 | 36% | +| Tooling complexity | 4 | 36% | +| High false positives in scans | 3 | 27% | +| Integration with project workflows | 3 | 27% | + +Takeaway: friction is layered: **capacity first**, then **clarity**, **tooling quality**, and **workflow fit**. + +## 5) Direct blocking is uncommon; noisy tools cause most pain + +| Did secure coding slow or block work? | Responses | +| --- | ---: | +| No | 9 | +| Yes | 2 | + +Only one respondent gave concrete detail: + +> False positives in code scans + +Takeaway: biggest pain is not day-to-day coding blockage. It is tool adoption, triage, remediation, and workflow integration. + +## 6) Free-text blockers reinforce same pattern + +Recurring themes: + +- **Bandwidth:** repeated mentions of time pressure, competing priorities, unclear starting point +- **Tool trust:** false positives and blunt criticism of tool quality +- **Workflow mismatch:** incident response and GHSA/private-fix flows do not fit normal CI/review patterns +- **Awareness gap:** one respondent learned about TAG Security & Compliance only from survey itself + +Takeaway: blockers are operational, not philosophical. + +## 7) Success stories were automation-first + +Only **4** respondents shared low-friction wins: + +- branch/tag protections and GitHub Action audits +- **CodeQL** +- **Dependabot** +- automated dependency upgrades plus code scans + +Takeaway: strongest pattern is **automation + guardrails**, not training programs or heavyweight review processes. + +## 8) Advice was pragmatic + +Only **3** respondents offered recommendations, but answers aligned: + +- plan for security early +- use defense in depth +- keep controls maintainable + +Takeaway: respondents want security built in early, but kept lightweight. + +## 9) Interview follow-up pool is small + +| Willing to participate in an interview | Responses | +| --- | ---: | +| Yes | 1 | +| Maybe | 3 | +| No | 7 | + +Only one respondent provided a contact method, and it is redacted in sanitized data. Due to the low amount of interest for joining a working session to discuss it more, these will not be held. + +## Cross-cutting insights + +- **Practice maturity is ahead of TAG Security & Compliance guidance awareness.** +- **Low-friction security means automation by default.** +- **Real friction is operational overhead:** time, triage, integration, remediation. +- **Noise reduction matters as much as detection.** False positives are recurring DX problem. + +## Recommendations for the initiative + +Based on this survey, the initiative should prioritize: + +1. **A maintainer-oriented quick-start baseline** + - Start with a short, practical checklist + - Emphasize what can be adopted in under an hour or a day + +2. **Automation-first guidance** + - Dependabot / dependency automation + - CodeQL or equivalent scanning + - Branch protection and release guardrails + - Artifact signing where appropriate + +3. **Guidance on reducing scanner friction** + - False-positive tuning + - Triage workflow examples + - Advice on what to block vs what to warn on + +4. **Workflow-native security patterns** + - GHSA / private security fix workflows + - CI-compatible incident response practices + - Review patterns that work in open source projects + +5. **Awareness-building for TAG Security & Compliance guidance** + - The awareness gap is large enough that publishing guidance alone is unlikely to be sufficient + - The distribution channels need to be rethought to ensure it reaches the intended audience + +## Bottom line + +This survey does not show strong opposition to secure coding. It shows a more practical problem: **maintainers need secure practices that are easy to discover, easy to enable, low-noise, and compatible with existing workflows without requiring large investment of contributor time**. + diff --git a/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/survey-results-secure-coding-practices.csv b/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/survey-results-secure-coding-practices.csv new file mode 100644 index 000000000..d5deba173 --- /dev/null +++ b/tags/tag-developer-experience/initiatives/showcase-frictionless-secure-coding/survey-results-secure-coding-practices.csv @@ -0,0 +1,14 @@ +"Timestamp","Which CNCF project(s) do you primarily contribute to?","What is your primary contributor role?","How would you rate your familiarity with TAG Security’s guidelines (ref: https://contribute.cncf.io/projects/best-practices/security/)?","Does your project currently follow any formal secure coding standards?","If you answered yes to the previous question, please expand which standards are followed and if they are documented, please add a link to them.","How would you rate the balance between security improvement and development speed for these tools or practices?","What are the top pain points your project has experienced when trying to adopt secure coding practices?","Have any secure coding practices inadvertently slowed development or blocked contributions?","If you answered yes to the previous question, in what ways have you seen this impact?","What has been the biggest blocker for adopting secure coding tools or processes in your project?","Can you describe an example where your project successfully improved security with minimal friction?","What would you recommend to other maintainers trying to adopt secure coding in their projects?","Would you be willing to participate in an interview for the initiative?","If you answered yes to the previous question, what is the best way to communicate with you?","Additional comments and general feedback" +"Response-01","TAG DevEx","","2","Yes, established and documented","OWASP Secure Coding Practices: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/","3","Lack of clear best practices;High false positives in scans","No","","Time pressure and lack of strategy ","","To be part of the project planning not an after thought. With regulations enforcing this now, it's hard to deny","Maybe","","" +"Response-02","No","","1","No","","1","Tooling complexity","Yes","","","","","No","","" +"Response-03","sdfsadf","","","","","","","","","","","","","","" +"Response-04","Kubeflow","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","2","Yes, informal/implicit","SECURITY.md, RBAC, Merging via prow, Immutable releases, branch protections, reviews etc.","4","Tooling complexity;Lack of clear best practices;Lack of contributor time;Integration with project workflows","No","","Contributor time and multitude of tasks / unclear where to start","Implementing a lot of changes around branch/tag protections and GitHub action audits post the trivy incident.","Apply defense in depth and try to keep the overall project in a state where it's as ""easy"" to maintain and evolve as possible in order to be able to react to the ever-changing security landscape.","Yes","Redacted in sanitized dataset","" +"Response-05","Argo Rollouts","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","3","Yes, informal/implicit","Artifact signing https://argo-rollouts.readthedocs.io/en/stable/security/signed-release-assets/","2","Tooling complexity;Lack of clear best practices;Lack of contributor time","No","","Time","","","No","","" +"Response-06","Open Telemetry","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","1","Not sure","","","High false positives in scans;Lack of contributor time","No","","","","","","","" +"Response-07","OpenTelemetry","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","1","Yes, informal/implicit","","3","Tooling complexity;High false positives in scans","Yes","False positives in code scans","That the tools simply suck","","","No","","" +"Response-08","https://github.com/open-telemetry/opentelemetry-dotnet https://github.com/open-telemetry/opentelemetry-dotnet-contrib","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","1","Yes, informal/implicit","","4","Lack of contributor time","No","","","Enabled CodeQL","","No","","" +"Response-09","Kubescape","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","4","Yes, informal/implicit","","4","Lack of contributor time;Integration with project workflows","No","","Time, incentive","Enabling dependabot","","Maybe","","" +"Response-10","prometheus","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","1","Not sure","","","Lack of contributor time","","","","","","Maybe","","" +"Response-11","opentelemetry-injector","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","2","Yes, informal/implicit","rbac/access management for the repo, two factor auth, branch protection, issue templates","4","","No","","I wasn't aware of https://contribute.cncf.io/projects/best-practices/security/ until just now. :)","","","No","","" +"Response-12","opentelemetry","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","1","Not sure","","3","Integration with project workflows","No","","Lack of tooling to handle incident response, private PR for GHSA impossible to handle, does not fit with existing workflow, impossible to review, test and pass CI which is not run.","Automated upgrade of dependencies (dependabot) and code scans working well. Remediation is more a painpoint.","","Yes","Redacted in sanitized dataset","" +"Response-13","OpenTelemetry","Code-Centric: Developer (Code submission), DevOps (CI/CD, Infrastructure)","2","Not sure","","","Lack of clear best practices;Lack of contributor time","No","","lack of time","","","No","",""