- Maintainer - a developer, contributor, or maintainer
- Finder - security researcher
- Supplier - supplies, supports, centralizes distribution of assets, or repackages components
- Consumer - End User WG
- Layperson -
- Coordinator -
- Staff Engineer at big tech company
- Mary writes open source software for a large tech firm. She has had both jobs focused on open source software as well as closed source software. She is responsible for maintaining a popular open source project. Her maintainer status on the project is not tied to her job, but she is paid by her company to work on the project.
- Mary has multiple goals tied to herself personally, the project, and her job. For herself, she wants to not end up overloaded with work, and she wants to be seen as a good member of the open source community. For the OSS project she works on she wants it to be successful, popular, and it to be safe for use by the public and her company. For her company she wants to ensure that her work aligns with the goals of the company. She also wants to ensure that both her general open source work in the community as well as specific work on the project reflects well on the company.
- Not to end up overloaded with work
- Seen as a good member of the open source community
- Wants it to be successful, popular and it to be safe for use by the public and her company.
- Wants to ensure that both her general open source work in the community as well as specific work on the project reflects well on the company.
- It is difficult managing open source and company requirements especially if and when they conflict. Work planning is difficult since Mary deals both with internal company work but also deals with tickets coming from the community on her project. Mary needs to deal with unclear and fuzzy metrics compared to internal commercial work. This makes it more difficult for Mary to provide community adoption data, usage data, security data, etc. to both company stakeholders as well as other contributors and maintainers of the project. Mary is unable to use expensive commercial tools for performing common security tasks on the OSS projects like SCA, fuzzers, etc.
- It is difficult managing open source and company requirements, especially if and when they conflict.
- Work planning is difficult since Mary deals both with internal company work but also deals with tickets coming from the community on her projects.
- Needs to deal with unclear and fuzzy metrics compared to internal commercial work. This makes it more difficult for Mary to provide community adoption data, usage data, security data, etc. to both company stakeholders as well as other contributors and maintainers of the project.
- Unable to use expensive commercial tools for performing common security tasks on the OSS projects like SCA, fuzzers, etc.
- OpenSSF governance allows the open source project Mary maintains to fall under OpenSSF ownership if it meets OpenSSF scope and governance requirements and is voted on by the community. If it does fall under OpenSSF, it would be provided with support including security audit/review. Even if the project isn’t under OpenSSF, OpenSSF still can help through its portfolio of security projects under its governance. Mary can use projects like Scorecard to help get metrics on the security health of the project. If Mary’s project is considered critical to the safety of the community, it might fall under the work Alpha-Omega is doing. Mary can have the project follow the best practices, frameworks, and standards that come out of OpenSSF like SLSA, and S2C2F to better protect the project she maintains as well as help protect downstream consumers. Mary’s project also benefits from any projects in her software supply chain that themselves are utilizing OpenSSF tools and following best practices.
- Security audit and review
- Scorecard to help get metrics on the security health of the project
- Allstar for ensuring adherence to security best practices
- If the project is critical to the community it might fall under work Alpha-Omega is doing to secure critical projects
- The project can follow the various best practices, frameworks and standards coming out of OpenSSF like SLSA, and S2C2F.
- All the benefits of utilizing dependencies that also are helped by the OpenSSF
- Full or part-time oss dev, not affiliated with a commercial organization (or work is not related to such).
- SRE for tech company
- Ursula created an open source project on the weekend in order to learn a new programming language and other new tech. That project exploded in popularity and she continues to maintain it after hours and on the weekends along with support from some other volunteers she’s acquainted with. She also works at a tech company that allows her to work on the project but as it's unrelated to her day job requests that she only work on it after hours and with no implied or explicit company affiliation.
- Not get fired for breaking company rules with respect to the open source project.
- To learn new tech and create something she thinks is cool. Her goal here isn’t to necessarily get adoption and therefore is not interested in achieving regulatory consistency that might be requested by {downstream consumers?}.
- To not get burnt out from working both a day job and doing after hours work on the project.
- Create, update, and merge features that she wants to, along with input from the community
- Maybe one day turn it into a primary or side job
- Urusla has no intention of putting the project under an open source foundation while it’s just a side project
- Requests come in both from individuals on their own behalf as well as persons representing large organizations demanding addition of features, assurances around security, etc. She does not get paid for her work on the project.
- Ursula is worried about upcoming legal requirements that might require her to either abandon the side project or have to figure out how to perform expensive, in both time and money, security and compliance tasks.
- Having time to devote to maintenance and updates is hard to find, especially large blocks of contiguous time.
- Interpreting the complicated jargon presented in issues opened against her projects especially those that might be requesting improvements of security and compliance.
- How the OpenSSF can help:
- OpenSSF provides a lot of automated tools that make it easier for Ursula to just integrate into her Github, and build that enforce project security.
- All the benefits of utilizing dependencies that also are helped by the OpenSSF
- Provide an easy on-ramp to the foundation that helps lessen the resources needed to implement this tooling and practices.
- OpenSSF needs to create things that are “easily consumable”: Merge requests / pull requests where practical, CONTRIBUTING guides, issue templates, “bite-sized” tasks (it’s easier to find time for many 15 minute tasks instead of an 8 hour block), “obviously right” solutions.
- working on open source software in their "spare time"
- maintains the project(s) by themselves
- started out as a way to learn new things for fun, has grown beyond that
- I maintain a couple of small packages and contribute new medium size but impactful features to my underlying ecosystem. (Think a compiler optimisation for floats that takes a few months of work and extremely niche knowledge to get right) This is a really common and critical profile.
- Diana is in a loose network of other niche people doing the same in my ecosystem.
- Diana has challenges keeping their toolchain and CI systems up-to-date and running. C was not made for this kind of work, nor are most of the packaging ecosystem, and they have to fight with them all the time.
- keep the project going and as maintained as possible, given constraints of budget, time, and resources.
- Diana usually gets something like 2 hours per month to spend on FOSS. Sometimes up to 4h, sometimes less. 1 to 2h per month are dedicated to simply updating base dependencies. This is when it is just a few patches or minor versions. Sometimes up to 4 hours are taken for this. Sometimes a big major version in an important dependency happens and it takes us 10h to fix, over a quarter. This means that nearly all our time is spent handling dependency stuff. Basic stuff. Not security emergencies or anything like that. Releasing a new version that just is kept up to date basically.
- Diana does not have more time to give. Life is what it is; they have family, a job, friends, etc.
- Diana's tests for the project are in poor shape. This is very well known. They want to make them better, but per the above, there is no additional time to devote to this task. Even something like fuzzing would be incredibly challenging to deal with the additional bugs that could be found, prioritized, and eventually (maybe) fixed.
- Diana has no additional time to read security-oriented material or the use. They know what need to be done.
- Most of Diana's time is spent fighting build and dependency management tools. This is a constant problem. These tools often break in new and obscure ways. Oftentimes, features of the tool need to be disabled to even make things work and not break their builds. There are proably ways around this, but again, see above, there is no additional time to troubleshoot, research, and adjust. Even the basic tools break too much and eat Diana's time.
- Reviewing and reacting to user reports is challenging.
- Sometimes, only updating minor versions breaks things for that dependency, which had an innocuous changelog?!?? Wait, they messed up their versioning. This was API breaking change, but they had no idea. I would have made the same mistake. It is not obvious. Aaaargh. Well i guess i will have to tell everyone to use the old version for the next 6 months while we spend our 6h per quarter all fixing it. I hope no emergency security patch comes through during that time.
- Build and update tools and toolchains to be more aligned to the realities of Diana's work.
- Part-time dev working on passion or school project. Low-to-no resources.
- Hacker
- Researcher
- Academic
- Bug/Bounty Hunter
- Concerned Software Enthusiast -- I find and/or research security vulnerabilities
- Consumer that discovers a vulnerability in implementation
- Where there is software, there will be vulnerabilities. Finders intentionally, or unintentionally, discover vulnerabilities in software. Open source software has vulnerability disclosure processes that connect finders to projects/maintainers for developing a patch that downstream consumers of the open source can apply to remediate the vulnerability. Future versions of the open source should have the vulnerability closed, so downstream consumers of the software are not exposed to discovered vulnerabilities.
- Job to do this
- In security and job is to notice
- Not a job, a hobby or accidental discovery
- Wants to discover vulnerabilities before threat actors.
- Wants recognition/credit for discovering complex and/or high severity vulnerabilities in order to grow their career
- Unknowns caused by projects who do not have well published and public vulnerability disclosure policies -Developers & vendors who are not responsive -Vulnerabilities that I discover that get exploited in the wild
- Continue to provide vulnerability disclosure process to connect finders to open source projects/maintainers
- Educate finder personas with the importance and availability of the open source security vulnerability disclosure process to encourage timely and secure reporting of vulnerabilities they find.
- Software security development courses should have what to do if a vulnerability is disclosed.
- Ethics of reporting a vulnerability vs sharing it as a zero day with threat actor
- Work to have this as part of Computer Science, Computer Information Systems academic programs: what to do if you find an open source project vulnerability (similar to how memory safe languages are taught in academic settings now to train future generations)
- Blogs.
- Leverage DevRel and other industry events (speaking and booths) where the various roles learn (Blackhat/Defcon), Open Source Summits.
- Lessons learned from not following the secure vulnerability disclosure process
- Address concerns when vulnerabilities are disclosed but not swiftly closed by open source projects/maintainers
- For high profile vulnerabilities, having a Security Incident Response Team (SIRT) in place to support projects where a Finder may have disclosed a high profile vulnerability that consumers are anxious to have closed but the priorities of the open source project may not be to close the identified security flaw.
- Incentivize open source projects/maintainers to close vulnerabilities. How can we offset the burden a disclosed vulnerability brings to an open source project/maintainer Possibly Track Mean Time to Remediate (MTTR) metrics tracked for “found” vulnerabilities and disclose the MTTR metric in security scorecard. There is nuance with CVEs, and effort can be expensive.
- Consumers of software can make automated decisions using the RISK metrics (built on security scorecard metrics) to understand open source projects that address “found” vulnerabilities in a timely manner (timely being a consumer's risk tolerance for using open source software with various MTTR).
- Siddharth’s company creates a commercial product that heavily uses open source software and has hundreds of dependencies on assorted OSS libraries.
- Siddharth’s engineers contribute features and bug fixes back upstream to many of the packages used within their product and are active project community members in the projects they deem most critical to their solutions.
- Based on their community contributions and project roles, they sometimes are included in CVD efforts for a few of their OSS components, but not all (not even a large number). These roles allow them to share pre-embargo information ahead of public disclosure internally to prepare so their customers can have patches available at the time of public disclosure.
- Suppliers may or may not understand all of the third-party components and open source software included in their commercial offerings.
- Suppliers typically will support some form of platform or commercial product they license or provide support/subscriptions for.
- Suppliers may or may not be involved in upstream projects they consume and support to a downstream, providing bug fixes upstream.
- Suppliers may or may not be within the circle of trust to receive pre-embargo disclosures to help support downstream.
- Suppliers have their own business goals and objectives that may differ from upstream. The Supplier’s customers look to the Supplier to provide support/bugfixes/vulnerability management for all components within the solution they provide regardless of their ability to influence upstream.
- Suppliers have their own internal SDL practices.
- Suppliers need to be conducting due diligence on their component suppliers.
- I want to understand upstream oss & third-party components used within my solution.
- I need to react to customer inquiries and demand for updates for all components within my solution.
- I would like to participate and have influence in upstream communities that matter to me and my customers.
- I provide support for my solution that may be longer than what my upstream components provide. I need to decide how to manage that situation in financially responsible ways.
- Using OSS helps me extend my engineering capabilities and helps spread the burden of support across all community members/participants. Ideally more suppliers follow me and participate in these communities as well.
- I have Regulatory Obligations and Customer Requirements for my solution that may or may not be met by my upstream providers that I need to provide to my downstream.
- I don’t understand all of my upstream components, how those communities operate, nor how to stay updated with upstream changes.
- Upstream components I use release bug fixes and vulnerability patches too frequently, and do not match my release schedule. Sometimes upstream releases breaks API/ABI compatibility of my solution, barring me from quickly implementing them.
- Not enough other suppliers participate in the software projects that I use, either forcing me to shoulder more of the burden or updates are not done by the community due to lack of resources or prioritization.
- My Regulators and Customers are putting an ever-increasing burden on me to comply with laws, evidentiary requirements, and vulnerability fixes.
- Why upstream has no plans or bandwidth to make updates/fixes - As downstream, what are my options?
- I may choose to not be completely transparent about my practices and components and desire to just meet the bare minimum requirements to meet my legal and regulatory obligations
Projects like Scorecard can help me evaluate the OSS components I use in my solution. Frameworks like SLSA & S2C2F help me understand how my upstream components are developed, composed, delivered and things I need to do as I am ingesting them. My developers need to understand secure application development and secure supply chain practices so we can follow expected industry best practices like the output of the Best Practice working group and the secure development training. I need to understand when fixes and vulnerability patches are provided upstream and then analyze the impact to my particular implementation of that software and how that would affect my customers like OSV, OpenVEX, and the CVD Guides from the Vuln Disclosure working groups
- Goes fast, breaks stuff
- Slow and steady, traditional vendor of a large software system with long development cycles. The resulting software system is often probably critical to the company / country, so the impact of errors can be largeare extremely concerning, leading to general risk aversion. It’s also probably large with a lot of technical debt, and the current maintainers may not be familiar with parts of the system (as their previous maintainers have left), making changes hard and costly.
- Consumers utilize open source software to create software and/or other products which includes open source software as building blocks
- Consumers primarily ingest open source software, but may also contribute features and security improvements, yet in significantly lower volumes than ingesting open source software
- Consumers can be commercial and non-commercial entities
- Commercial entities are subject to regulatory requirements with respect to product security
- Consumer can also be producers
- I want to determine and understand the security posture of the open source software I consume in a scalable and meaningful manner to
- make sure that the (software) products I build are compliant to regulatory requirements
- manage the risks associated with consuming open source software in my products
- to guide meaningful upstream contributions to improve the security posture of the software I rely on
- Open source projects differ widely in terms of security qualities
- It is difficult to assess and understand the security qualities of open source software in a meaningful manner due to the wide range of different (open source) development practices
- Programming languages, tools, source code management and hosting, governance and community structure (company backed projects, foundation based projects, individual maintainer-based projects)
- A supply chain inherently involves multiple entities (e.g., maintainer/supplier and consumer per supply chain link) which need to interact utilize interoperable means for conveying information
- Provide an environment for developing tools for (automatically) assessing and/or improving the security quality of open source projects or for developing improvement proposals for existing tools
- Provide guidelines and recommendation for methods of exchanging information, fostering adoption of interoperable methods
- Provide data (sources) which provide an insight into the security qualities of open source projects
- Software Engineer at Medium Sized Bank
- Danika is a 9-5 software engineer at a bank. She does not do software development in the open source space though she does consume open source software as part of her job. She spends most of her day in an IDE writing software. Once a week she gets a report from security about SCA discovering vulnerabilities in her software.
- Release features while hitting business deadlines and following bank compliance and policy requirements. These requirements involve vulnerability remediation deadlines, security control implementations, etc.
- Danika wants policy and compliance related feedback earlier in the SDLC loop. She would love to have information about using compliance (security, EOL, etc) in the tools she uses (IDEs, CLI tools, etc)
- She is just one developer in a large organization. She does not have the ability to drive meaningful change on her own. This means she is at the whims of the policies and process within the organization including security requirements even if those requirements might not be aligned with modern best practices.
- She does not have much if any security training outside basic quarterly training on how to identify common SQL injection attacks and similar.
- Interpreting the complicated internal jargon and requirements when creating issues in open source dependencies in order to request improvements of security and compliance.
- Creating forward thinking best practices and standards that can help Danika become more proactive in securing her software as opposed to reactive.
- This includes providing Danika with ammunition to help her push for change.
- OpenSSF through its work in helping define or collaborate on controls, standards, best practices, and regulations can drive industry and community change that will eventually be adopted in larger, often slower moving, enterprises.