Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OSPO Book] Scenarios & Recommendations - CH 4 #455

Closed
wants to merge 1 commit into from
Closed

[OSPO Book] Scenarios & Recommendations - CH 4 #455

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 29 additions & 6 deletions ospo-book/content/en/04-chapter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,8 @@

# Introduction

Understanding the day-to-day activities of those managing open source operations within an organization is crucial for several reasons. First and foremost, it sheds light on the fundamental tasks that an OSPO must focus on to ensure the organization's

Check failure on line 15 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"proselint.Cliches" 

'First and foremost' is a cliche.
technology strategy and aefforts aligns with open source best practices. This knowledge helps to streamline engineering processes and maintain compliance with open source licenses and security measures.

Check failure on line 16 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"Vale.Spelling" 

Did you really mean 'aefforts'?

OSPO day-to-day operations encompass a broad spectrum of activities aimed at enhancing open source engagement and compliance within the organization, including providing personalized technical support on licensing and software selection, leveraging automation tools for process efficiency and security,
developing and disseminating educational materials, strategically allocating resources, managing risks through comprehensive assessments of the tech stack, sponsoring and engaging with open source communities and foundations, measuring technical debt in projects, and facilitating coordination
Expand Down Expand Up @@ -48,24 +48,47 @@
| **Automation in Security** | Enable tools and best practices for integrating security measures, such as scorecards, into daily operations. | Automation in security practices and vulnerabilities exploration in open source projects allows effective risk management. | Explore automation tools that assist developers to self-assess security risk on specific projects, without burdening them with lengthy approval processes. | Explore automation tools that assist developers to self-assess security risk on projects they would like to contribute as employees, without burdening them with lengthy approval processes. | OSFF Scorecard [https://github.com/marketplace/actions/openssf-scorecard-monitor](https://github.com/marketplace/actions/openssf-scorecard-monitor) |
| **Measuring Performance** | Inform strategic adjustments and operational enhancements. | Measuring performance facilitates transparent assessment of the OSPO's effectiveness. | TBD (ping CHAOSS OSPO metrics WG to give input on this). | N/A | N/A |
| **Strategy and its Impact** | A unified strategy influences daily operations. | Guiding decisions on contributions to open source projects, engagement with community initiatives, and the balancing of organization and community benefits. | Enable decision makers understand the critical importance of supporting open source projects (and its community) and foundations, and the different ways to offer support. | Frameworks that support strategic planning and execution. | N/A |
| **Personalized Support / Q&A Sessions**| Actively involve employees and managers in open source activity engagement. | Increase and improve open source knowledge and expertise across the organization's teams. | Answering questions on everything about open source, including license compliance, selecting open source software, and dealing with vendors. | Answering questions on everything about open source, including license compliance, selecting open source software, and dealing with vendors. | Internal developer portals / Issue tracker systems / Chatbots / webinars / AMA sessions / IRC |

Check failure on line 51 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"Vale.Spelling" 

Did you really mean 'Chatbots'?
| **Advocacy and Education** | Advocating for the importance of education in open source and creating resources to support it. | Ensure that people are qualified to judge a project (governance models, maturity, etc) and measure the technical debt on an open source project. | Build training and documentation, and assist teams in creating these materials across different teams. | Providing knowledge on how to measure the technical debt on an open source project, including maturity models and governance models, is a form of educational advocacy to help projects improve and sustain. | External open source training and certification courses, customized training courses adapted to the organization's goals. |
| **Community Integration** | Integrate organization's activities effectively with the open source projects and foundations (financial as well as resource support) as well as community dynamics. Map interactions with technical (engineering) versus non-technical teams (business, design team). | Allocate effective financial and resource support to critical open source projects that organization's employees use/engages. | How to get sponsorship, run open source events, and integrate effectively with the open source community and its foundations. | How to get sponsorship, run open source events, and integrate effectively with the open source community and its foundations. | N/A |
| **Business Assessment on Risk Management** | Assess risks that the organization is facing, including an overview of the tech stack. | Assistance in evaluating which open source projects to use and how to prioritize resources effectively. | E.g., business assessment to determine whether optimizing SBOMs or focusing on other areas is more beneficial (dealing with vendor-supplied software, legacy software, proprietary software). | E.g., business assessment to determine whether optimizing SBOMs or focusing on other areas is more beneficial (dealing with vendor-supplied software, legacy software, proprietary software). | N/A |


## Recommendations (TBD)
## Recommendations

`💡Recommendations`

### Scenario #11
- Scope:

- Recommendation:
Social Engineering Attack on Upstream xz/liblzma: A social engineering attack targeted the xz/liblzma, an essential open source library. The attack was meticulously planned, gaining trust within the community before executing a malicious attack. This incident was discovered inadvertently by an unrelated project, underscoring the sophistication and stealthiness of such vulnerabilities. The challenge for Open Source Program Offices (OSPOs) lies in identifying and mitigating these vulnerabilities, which are not always apparent until after they occur. Despite existing procedures and policies, OSPOs recognize the need for mechanisms to proactively measure and respond to such threats.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityMaybe" 

Reconsider using 'Attack', it may be profane.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityUnlikely" 

Be careful with 'Attack', it’s profane in some cases.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityMaybe" 

Reconsider using 'attack', it may be profane.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityUnlikely" 

Be careful with 'attack', it’s profane in some cases.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityMaybe" 

Reconsider using 'attack', it may be profane.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityUnlikely" 

Be careful with 'attack', it’s profane in some cases.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityMaybe" 

Reconsider using 'attack', it may be profane.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityUnlikely" 

Be careful with 'attack', it’s profane in some cases.

Check warning on line 63 in ospo-book/content/en/04-chapter.md

View workflow job for this annotation

GitHub Actions / Review docs

"alex.ProfanityUnlikely" 

Be careful with 'lies', it’s profane in some cases.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Social Engineering Attack on Upstream xz/liblzma: A social engineering attack targeted the xz/liblzma, an essential open source library. The attack was meticulously planned, gaining trust within the community before executing a malicious attack. This incident was discovered inadvertently by an unrelated project, underscoring the sophistication and stealthiness of such vulnerabilities. The challenge for Open Source Program Offices (OSPOs) lies in identifying and mitigating these vulnerabilities, which are not always apparent until after they occur. Despite existing procedures and policies, OSPOs recognize the need for mechanisms to proactively measure and respond to such threats.
Social Engineering Attack on Upstream xz/liblzma: A social engineering attack targeted the xz/liblzma, an essential open source library. The attack was meticulously planned, gaining trust within the community before executing a malicious attack. This incident was discovered inadvertently by an unrelated project, underscoring the sophistication and stealthiness of such vulnerabilities ([more details](https://research.swtch.com/xz-timeline)). The challenge for Open Source Program Offices (OSPOs) lies in identifying and mitigating these vulnerabilities, which are not always apparent until after they occur. Despite existing procedures and policies, OSPOs recognize the need for mechanisms to proactively measure and respond to such threats.

I added a link to provide more context about the attack vector details


### Scenario #12
> Recommendation
>
> 1. SBOMs Compliance Ready: Ensure that all software components are documented through Software Bill of Materials (SBOMs). This documentation helps in quickly identifying potentially compromised components once a vulnerability is disclosed.
>
> 2. Automation Security Checks: Implement automated security checks, such as the OpenSSF Security Scorecard, to continuously evaluate the security posture of projects. This proactive measure can highlight vulnerabilities or anomalies that merit further investigation.
>
> 3. Having a Computer Emergency Response Team (CERT) within the organization and having the OSPO collaborate closely with them. This specialized team should be equipped with the tools and authority to respond swiftly to security incidents. Pre-existing relationships within the team facilitate rapid internal communication about the > > severity of incidents.
>
> 4. Scorecard Management: Keep security and vulnerability scorecards up to date. These scorecards should reflect the latest security checks and assessments, helping in quick decision-making during a crisis.
>
> 5. Automated Feedback Loops: Develop well-automated feedback loops for bug reporting and fixing. Knowing who is responsible for addressing a particular bug and ensuring that this process is as automated as possible can significantly reduce response times.

- Scope:
### Scenario #12

- Recommendation:
OSPOs face the challenge of navigating license changes and assessing software trustworthiness. As projects like Redis have shown, altering license terms can have significant implications for use, distribution, and contribution. These changes needs clear communication and understanding of the roles and responsibilities dictated by new license terms. Furthermore, OSPOs are tasked with evaluating the trustworthiness of software, which can vary based on whether a project is maintained by a single vendor or hosted under a foundation. For instance, The Almalinux Foundation presents a case where donating a project to a foundation mitigated risks associated with single-vendor governance, thereby enhancing trust in the project.

> Recommendation
>
> 1. Educational Initiatives on License Implications: Develop educational materials and sessions for developers and users within the organization to understand the nuances of different licenses. This understanding will help them make informed decisions when using or contributing to open-source projects.
>
> 2. Explicit License Terms: Work with legal teams to ensure that license terms are as explicit and unambiguous as possible. Clear terms help in avoiding misunderstandings and potential legal conflicts.
>
> 3. Software Trust Rating System: Implement a system to evaluate and rate the trustworthiness of software, considering factors like governance structure, maintenance practices, and community engagement. Projects hosted under reputable foundations could be rated higher for trustworthiness due to the oversight and governance provided.
>
> 4. Encourage Foundation Hosted Projects: Advocate for donating projects to foundations to mitigate risks associated with single-vendor control. Highlight successful cases like Almalinux to illustrate the benefits of this approach, such as increased trust and community support.
>
> 5. Stakeholder Engagement in License Decisions: Engage a broad range of stakeholders, including developers, legal advisors, and end-users, in discussions about license changes or the adoption of new projects. Their insights can help in making balanced decisions that align with the organization's values and risk tolerance

## Resources (TBD)

Expand Down
Loading