Security Considerations in the Open Source Software Ecosystem
Dominik Wermke
dwermke.com
Dominik Wermke
Usable Security & Privacy
North Carolina State University

https://dwermke.com

Human Factors in Security

  • Premise:
    Fantastic theoretical solutions to many problems
  • Problem:
    Users de facto not protected
  • Solution:
    Consider human factors to help close this gap!
Usable Security & Privacy
Security & Privacy
Security & Privacy
Security & Privacy
Usable Security & Privacy

Popular Research Topics



Based on 500 qualitatively coded paper abstracts
If it's not the user's fault ...
  • Log4Shell vulnerability
  • Heartbleed, Cloudbleed
  • Shellshock vulnerability, Bashdoor

... is it the developers fault?
Usable Security & Privacy
Usable Security & Privacy for Developers
How can we help ...
  • Developers
  • Maintainers
  • Contributors
  • ...

My Research

Towards enabling experts to deploy secure, privacy-respecting, and trustworthy software

Methods I utilized

Populations I work with

The Supply Chain
is under
Attack!


President's Executive Order 14028 - Improving the Nation's Cybersecurity

Second act on increasing the security of IT systems
(German IT Security Act 2.0)

Targeting Developers


Tech Monitor, 2023-01-03

Developers as the weakest Link

[A]n unauthorized third party leveraged malware deployed to a CircleCI engineer’s laptop in order to steal a valid, 2FA-backed SSO session.
CircleCI

Open Source Software

  • Usage: Most projects on their platform rely on some form of Open Source Software
  • Connected: Median of 683 transitive dependencies in the npm ecosystem
Why you should care about the security of Open Source Software

Open Source Software

Open Source Supply Chain

Open Source code appears as foundation, glue, or during the build process in many software projects.


Adopted from xkcd 2347

Adopted from xkcd 2347
Incident: FakerJS
Nov 2020
Respectfully, I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work.
There isn't much else to say.

Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.
Incident: Protestware node-ipc
Mar 2022

Quick Recap

  • Open source software plays an important role in the software supply chain
  • Utilizing open source components introduces unique challenges in terms of security and trust
  • How can we empower and support the involved software experts?

Always Contribute Back

44th IEEE Symposium on Security and Privacy (IEEE S&P'23)

Attack Vector:
External Dependencies


JFrog, 2021-07-29

Security Challenges for Industry

  • How do industry projects deal with security and trust challenges of including open source components in their projects?
  • We investigated their projects' processes, decisions, and considerations in the context of exterrnal open source components

Research Questions

  • RQ1:
    How are Open Source Components included in companies’ tech stacks in terms of position, importance, and security effects?
  • RQ2:
    What are companies’ awareness, experiences, and attitudes regarding the security of including external open source code?
  • RQ3:
    If and how do stakeholders make decisions and considerations around security and trust challenges of including Open Source Components?

Interviews

25
Software Developers, Architects, and Engineers from Industry Projects

Security Challenges

Industry projects that encountered security challenge due to OSCs
No --- Some / Other

Security Challenges

Industry projects that encountered security challenge due to OSCs
No (1) --- Some / Other (24)

Security Challenges

  • No longer maintained or abandoned open source projects
  • Updates and changes breaking previously working setups
  • Projects delaying or never patching known vulnerabilities

Selection Criteria

Most common metrics for selecting open source projects
  • (16) Popularity measure like downloads or GitHub stars
  • (11) Large and active community
  • (10) Activity measures like commit frequency and recent releases
  • (10) Specific features

Internal Mirrors

Projects that use (at least partially) internal mirrors:
Yes --- No / Other

Internal Mirrors

Projects that use (at least partially) internal mirrors:
Yes (14) --- No / Other (11)

Internal Mirrors

We do use internal mirrors mainly for speed and convenience, especially large codebases. [...]
Usually, when we clone from those internal repositories, we’re going to use fixed commits from it, so it makes development a lot easier

Contributing Back

Projects that in some way contribute back to open source
Yes --- No / Other

Contributing Back

Projects that in some way contribute back to open source
Yes (14) --- No / Other (11)

Contributing Back

Projects that in some way contribute back to open source (or would like to)
Yes or would like to (19) --- No (6)

Summary

  • Open source components hold important roles in many participants’ projects
  • Most projects had some form of company policy or at least best practices for including external code.
  • Selection and exclusion criteria for OSCs were often based on easily visible metrics like activity, number of contributors, or GitHub stars.
  • Most contribute in some form back to open source projects, or would at least like to, with some suggesting their management or legal departments do not fully understand the open source ecosystem.

Reproducible Builds

44th IEEE Symposium on Security and Privacy (IEEE S&P'23)
To what extent should one trust a statement that a program is free of Trojan horses?
Perhaps it is more important to trust the people who wrote the software.
~ Ken Thompson

Reproducible Builds

  • An important step of trusting the people that wrote the software, is to also be able to trust the resulting artifacts
  • Reproducible builds are a solution to this problem

Challenges

  • Timestamps (current)
  • File order and build directories
  • Any build randomness

Interviews

24
Reproducible Builds Experts

Findings

  • Motivation: "Same input should always compile to same output" and broken expectations
  • Experiences: "Receptive upstream projects" and "Patience and Communication"
  • Common Obstacles: Date and other times, build directory name inclusion

Committed to Trust

43rd IEEE Symposium on Security and Privacy (IEEE S&P'22)

Research Questions

  • RQ1:
    How are open source projects structured behind-the-scenes?
  • RQ2:
    If and what guidance and policies are provided by open source projects?
  • RQ3:
    How do open source projects approach security and trust challenges?

Interviews

27
Owners, Leaders, Maintainers, Contributors of Open Source Projects

Findings

Security
Trust
Processes

Security

Security
Trust
Processes

Past Incidents

Security incidents encountered in the past:
None --- Some / Other

Past Incidents

Security incidents encountered in the past:
None (16) --- Some / Other (11)

Past Challenges

Most commonly encountered security challenges
(That not necessarily resulted in an incident)
  • (15) Suspicious or low quality commits
  • (8) Vulnerability introduced by dependencies
[T]here’s definitely been people that have intentionally tried to put malicious code in projects, but it’s always very easy to spot immediately. It’s like those spam emails where they have bad grammar and stuff
Summary

Security

  • Few projects have experienced an outright security incident
  • Many of our participants were familiar with suspicious or low quality commits and potential vulnerabilities introduced by dependencies

Trust

Security
Trust
Processes

Trust Incidents

Trust incidents encountered in the past:
None --- Some / Other

Trust Incidents

Trust incidents encountered in the past:
None (20) --- Some / Other (7)

Trust Incidents

Trust incidents encountered in the past:
  • Drive-by cryptocurrency miner commits
  • Failed background checks
  • Pro-active block after potential SSH key theft
Summary

Trust Processes

  • Most use some form of meritocracy for establishing trust with new contributors.
  • Some even assume trustworthiness by default to facilitate first-time contributions.
  • The majority never experienced a trust incident in their projects and did not establish specific trust incident strategies.

Processes

Security
Trust
Processes

Guidance

Most mentioned guidances
  • (14) Guidance for contributing to the project
  • (13) Programming language-specific guidance
  • (8) General guidance for project setup and infrastructure

Guidance

Somebody would have to write the guide, and I am the only one who can write it. I mean, there is nobody paid to write it and I am also not paid to write it.
Summary

Guidance & Policies

  • Participants diverge on their opinions regarding the helpfulness of (written) guidance
  • Security policies: larger projects mentioned dedicated security teams, smaller projects mentioned a security contact channel
  • Most projects included some type of disclosure policy or at least contact for security issues

Summary

  • Projects are highly diverse in deployed security measures, trust processes, motivations
  • Growing scope and contributors → growing needs for security and trust processes
  • Smaller projects handle security and trust incidents "as they happen"

Takeaways

Securing a Bowl of Spaghetti

  • Software supply chain analogy: (wrongly) conveys linear relations
  • With clear start (producer) and end (consumer) endpoints
  • In reality: a giant bowl of spaghetti
  • Some companies focus on stuff on their plate

"Not Your Average Supply Chain"

  • Some participants mentioned that their management doesn't seem to fully grasp the benefits and challenges of open source software
  • While other support utilized open source components by donating, e.g., money, developer-hours, knowledge, or code
  • Few mentioned even following the guideline to always contribute back

References

[S&P 23b]
It's like flossing your teeth: On the Importance and Challenges of Reproducible Builds for Software Supply Chain Security
Marcel Fourné, Dominik Wermke, Will Enck, Sascha Fahl, and Yasemin Acar.
IEEE S&P 2023, In 44th IEEE Symposium on Security and Privacy, May 22-25, 2023.
[S&P 23a]
"Always Contribute Back": A Qualitative Study on Security Challenges of the Open Source Supply Chain
Dominik Wermke, Jan H. Klemmer, Noah Wöhler, Juliane Schmüser, Harshini Sri Ramulu, Yasemin Acar, and Sascha Fahl.
IEEE S&P 2023, In 44th IEEE Symposium on Security and Privacy, May 22-25, 2023.
[S&P 22]
Committed to Trust: A Qualitative Study on Security & Trust in Open Source Software Projects
Dominik Wermke, Noah Wöhler, Jan H. Klemmer, Marcel Fourné, Yasemin Acar, and Sascha Fahl.
IEEE S&P 2022, In 43rd IEEE Symposium on Security and Privacy, May 23-26, 2022.