ggi-castalia issueshttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues2023-05-16T13:11:15Zhttps://gitlab.ow2.org/ggi/ggi-castalia/-/issues/44(Trust Goal) Run code reviews2023-05-16T13:11:15ZBoris Baldassari(Trust Goal) Run code reviews
## Description
Code review is a routine task involving manual and/or automated review of an application's source code before releasing a product or delivering a project to the customer. In the case of open-source software, code review ...
## Description
Code review is a routine task involving manual and/or automated review of an application's source code before releasing a product or delivering a project to the customer. In the case of open-source software, code review is more than just about catching errors opportunistically; it is an integrated approach to collaborative development carried out at the team level.
Code reviews should apply to code developed in-house as well as to code reused from external sources, as it improves general confidence in code and reinforces ownership. It is also an excellent way to enhance global skills and knowledge within the team and foster team collaboration.
## Opportunity Assessment
Code reviews are valuable whenever the organisation develops software or reuses external pieces of software.
While being a standard step in the software engineering process, code reviews in the context of open-source bring specific benefits such as:
* When publishing internal source code, verify adequate quality guidelines are respected.
* When contributing to an existing open source project, verify that guidelines of the targeted project are respected.
* The publicly available documentation is updated accordingly.
It is also an excellent opportunity to share and enforce some of your company legal compliance policy rules, such as:
* Never remove existing licence headers or copyrights found in reused open-source code.
* Do not copy & paste source code from Stack Overflow without prior permission from the legal team.
* Include the correct copyright line when required.
Code reviews will bring trust and confidence to code. If people are not sure about the quality or potential risks of using a software product, they should conduct peer- and code- reviews.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] Open source code review is recognised as a necessary step.
- [ ] Open source code reviews are planned (either regularly or at critical moments).
- [ ] A process for conducting open-source code reviews has been collectively defined and accepted.
- [ ] Open-source code reviews are a standard part of the development process.
## Recommendations
* Code review is a collective task that works better in a good collaborative environment.
* Do not hesitate to use existing tools and patterns from the open-source world, where code reviews have been a standard for years (decades).
## Resources
* [What is Code Review?](https://openpracticelibrary.com/practice/code-review/): a didactic read on code review found on Red Hat's Open Practice Library.
* [Best Practices for Code Reviews](https://www.perforce.com/blog/qac/9-best-practices-for-code-review): another interesting perspective on what code review is about.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/24(Trust Goal) Manage key indicators2023-05-16T13:11:15ZCedric Thomas(Trust Goal) Manage key indicators
## Description
This activity collects and monitors a set of indicators that inform day-to-day managerial decisions and strategic options concerning professionally managed open source software.
Key metrics related to open source softwa...
## Description
This activity collects and monitors a set of indicators that inform day-to-day managerial decisions and strategic options concerning professionally managed open source software.
Key metrics related to open source software form the backdrop of how well governance programmes are rolled out. The activity covers selecting a few indicators, publishing them to the teams and management, and sending regular updates on the initiative, e.g. via a newsletter or corporate news.
This activity requires:
* stakeholders to discuss and define the objectives of the program,
* the implementation of a measurement and data collection tool connected to the development infrastructure,
* the publication of at least one dashboard for the stakeholders and for all the people involved in the initiative.
Indicators are based on data that must be collected from relevant source. Fortunately, there are plenty of sources for open source software engineering. Examples include:
* the development environment, the CI/CD production chain,
* the HR department,
* the testing and software composition analysis tools,
* the repositories.
Examples of indicators include:
* Number of resolved dependencies, displayed by licence type.
* Number of outdated/vulnerable dependencies.
* Number of licencing/ip issues detected.
* Contributions made to external projects.
* Bug open time.
* Number of contributors on a component, number of commits, etc.
This activity is about defining these requirements and measurement needs, and implementing a dashboard that shows in a simple and efficient manner the main indicators of the program.
## Opportunity Assessment
Key indicators help understand and better manage the resources devoted to open source software, and measure the results in order to communicate effectively and reap the full benefits of the investment. By communicating broadly, more people can follow the initiative and will feel involved, ultimately making it an organisation-level concern and goal.
While each activity has evaluation criteria that help answer questions about progress achieved, there is still a need for monitoring done with numbers and quantitative indicators.
Whether in a small startup or a large global company, key metrics help keep teams focused and monitor performance. Metrics are crucial because they support decision-making and are the basis for monitoring decisions already taken.
With simple and practical numbers and graphics, the whole organisation members will be able to follow and synchronise efforts regarding open source, making it a shared concern and action. This also allows the various actors to better enter the course, contribute to the project and get the overall benefits.
## Progress Assessment
The following **verification points** demonstrate progress in this activity:
- [ ] A list of metrics and how to collect them has been established.
- [ ] Tools to collect, store, process and display indicators are used.
- [ ] There is a generalised dashboard available to all participants that shows the progress made on the initiative.
## Tools
* [GrimoireLab](https://chaoss.github.io/grimoirelab) from Bitergia.
* [Alambic](https://alambic.io) from Castalia Solutions.
* Generic BI tools (elasticsearch, grafana, R/Python visualisations…) are a good fit too, when the proper connectors are setup according to the defined goals.
## Recommendations
* Write down the objectives and roadmap of the open source Governance.
* Communicate in-house about the actions and status of the initiative.
* Involve people in the definition of KPIs, in order to make sure that
- they are well understood,
- they provide a complete view of the needs and
- they are considered and followed.
* Build at least one dashboard that can be displayed for everybody (e.g. on a screen in the room), with essential indicators to show the progress and overall situation.
## Resources
* The [CHAOSS community](https://chaoss.community/) has many good references and resources related to open source indicators.
* Check out metrics for [Project Attributes](https://www.ow2.org/view/MRL/Stage2-ProjectAttributes) from the OW2 Market Readiness Levels [methodology](https://www.ow2.org/view/MRL/Overview).
* [A New Way of Measuring Openness: The Open Governance Index](https://timreview.ca/article/512) by Liz Laffan is an interesting reading about openness in open source projects.
* [Governance Indicators: A Users’ Guide](https://www.un.org/ruleoflaw/files/Governance%20Indicators_A%20Users%20Guide.pdf) is the UN's guide about governance indicators. Although it is applied to democracy, corruption and transparency of nations, the basics of measurement and indicators as applied to governance are well worth a read.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/23(Trust Goal) Manage software dependencies2023-05-16T13:11:15ZCedric Thomas(Trust Goal) Manage software dependencies
## Description
A *dependency identification* program looks for the dependencies actually used within the codebase. As a result, the organisation must establish and maintain a list of known dependencies for its code base and watch the e...
## Description
A *dependency identification* program looks for the dependencies actually used within the codebase. As a result, the organisation must establish and maintain a list of known dependencies for its code base and watch the evolution of the identified providers.
Establishing and maintaining a list of known dependencies is an enabler for, and a prerequisite to:
* IP and license checking: some licenses cannot be mixed, even as a dependency. One has to know its dependencies to assess its associated legal risks.
* Vulnerabilities management: the entire piece of software is as weak as its smallest part: see the example of the [Heartbleed flaw](https://en.wikipedia.org/wiki/Heartbleed). One has to know its dependencies to assess its associated security risks.
* Lifecycle and sustainability: an active community on the dependency project is a bright sign for bug corrections, optimisations, and new features.
* Thoughtful selection of used dependencies, according to "maturity" criteria - the goal being to use open source components that are safe, with a sane and well-maintained codebase, and a living, active and reactive community that will accept external contributions, etc.
## Opportunity Assessment
Identifying and tracking dependencies is a required step to mitigate the risks associated with any code reuse. In addition, implementing tools and processes to manage software dependencies is a prerequisite to properly manage quality, compliance, and security.
Consider the following questions:
* What is the company's risk (cost, reputation, etc.) if the software is corrupted, attacked or sued?
* Is the code base considered critical for people, the organisation, or business?
* What if a component upon which an application depends changes its repository?
The minimal and first step is to implement a software composition analysis (SCA) tool. Support by specialised consulting firms may be required for a full-fledged SCA or dependency mapping.
## Progress Assessment
The following **verification points** demonstrate progress in this activity:
- [ ] Dependencies are identified in all in-house developed code.
- [ ] Dependencies are identified in all external code executed within the company.
- [ ] An easy-to-setup software composition analysis or dependency identification procedure is available for projects to add to their Continuous Integration process.
- [ ] Dependency analysis tools are used.
## Tools
* [OWASP Dependency check](https://github.com/jeremylong/DependencyCheck): dependency-Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies.
* [OSS Review Toolkit](https://oss-review-toolkit.org/): a suite of tools to assist with reviewing Open Source Software dependencies.
* [Fossa](https://github.com/fossas/fossa-cli): fast, portable and reliable dependency analysis. Supports licence & vulnerability scanning. Language-agnostic; integrates with 20+ build systems.
* [Software 360](https://projects.eclipse.org/projects/technology.sw360).
* [Eclipse Dash license tool](https://github.com/eclipse/dash-licenses): takes a list of dependencies and requests [ClearlyDefined](https://clearlydefined.io) to check their licences.
## Recommendations
* Conduct regular audits about the dependencies and IP requirements to mitigate legal risks.
* Ideally, integrate dependencies management in the Continuous integration process so that issues (new dependency, licence incompatibility) are identified and fixed as soon as possible.
* Keep track of dependency-related vulnerabilities, keep users and developers informed.
* Inform people about the risks associated with wrong licencing.
* Propose an easy solution for projects to set up licence checking on their codebase.
* Communicate on its importance and help projects to add it to their CI systems.
* Set up a visible KPI for dependency-related risks.
## Resources
* Existing [OSS-licenced OSS licence compliance tools](https://oss-compliance-tooling.org/Tooling-Landscape/OSS-Based-licence-Compliance-Tools/) group page.
* [The FOSSology Project](https://www.linuxfoundation.org/wp-content/uploads/lfcorp/files/lf_foss_compliance_fossology.pdf). An up-to-date introduction to FOSSology and FOSS compliance by the Linux Foundation.
* [Free and Open Source Software licence Compliance: Tools for Software Composition Analysis](https://www.computer.org/csdl/magazine/co/2020/10/09206429/1npxG2VFQSk), by Philippe Ombredanne, nexB Inc.
* [Software Sustainability Maturity Model](http://oss-watch.ac.uk/resources/ssmm).
* [CHAOS](https://chaoss.community/): Community Health Analytics Open Source Software.https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/22(Trust Goal) Manage software vulnerabilities2023-05-16T13:11:15ZCedric Thomas(Trust Goal) Manage software vulnerabilities
## Description
One's code is as secure as its least secure part. Recent cases (e.g. heartbleed[^heartbleed], equifax[^equifax]) have demonstrated the importance of checking vulnerabilities in parts of the code that are not directly dev...
## Description
One's code is as secure as its least secure part. Recent cases (e.g. heartbleed[^heartbleed], equifax[^equifax]) have demonstrated the importance of checking vulnerabilities in parts of the code that are not directly developed by the entity. Consequences of exposures range from data leaks (with tremendous reputational impact) to ransomware attacks and business-threatening unavailability of services.
Open source software is known to have better vulnerability management than proprietary software, mainly because:
* More eyes are looking to find and fix problems on open code and processes.
* Open source projects fix vulnerabilities and release patches and new versions a lot faster.
For example, a [study by WhiteSource](https://resources.whitesourcesoftware.com/blog-whitesource/3-reasons-why-open-source-is-safer-than-commercial-software) on proprietary software showed that 95% of the vulnerabilities found in their open source components had already released a fix at the time of the analysis. The issue, therefore, is to **better manage vulnerabilities both in the codebase and its dependencies**, no matter if they are closed or open source.
In order to mitigate these risks, one has to set up an assessment program of its software assets and a vulnerability-checking process executed regularly. Implement tools that alert impacted teams, manage known vulnerabilities, and prevent threats from software dependencies.
## Opportunity Assessment
Any company that uses software has to watch its vulnerabilities in:
* its infrastructure (e.g. Cloud infrastructure, network infrastructure, data stores),
* its business applications (HR, CRM tools, internal and customers-related data management),
* its in-house code: e.g. the company's website, internal development projects, etc., and
* all direct and indirect software and services dependencies.
The ROI of vulnerabilities is little known until something bad happens. One has to consider the consequences of a major data breach or unavailability of services to estimate the true cost of vulnerabilities.
Similarly, a culture of secrecy and hiding for security-related issues inside the company has to be avoided at all costs. Instead, information about the state of vulnerability needs to be shared and discussed to find the best answers from the right people, from developers to c-level executives.
The benefits of preventing cyber-attacks by carefully managing software vulnerabilities are manyfold:
* Avoid reputational risks,
* Avoid exploitation loss (DDoS, Ransomware, Time to rebuild an alternative IT system after an attack),
* Comply with data protection regulations.
Managing OSS software vulnerabilities is just a part of the larger cybersecurity process that globally addresses the security of the systems and services in the organisation.
## Progress Assessment
There should be a dedicated person or team to monitor vulnerabilities and easy-to-use processes for developers to rely on. Vulnerabilities assessment is a standard part of the continuous integration process, and people are able to monitor the current state of risk in a dedicated dashboard.
The following **verification points** demonstrate progress in this Activity:
- [ ] Activity is covered when all in-house software and services are assessed and monitored for known vulnerabilities.
- [ ] Activity is covered when a dedicated tool and process is implemented in the software production chain to prevent the introduction of issues in the daily development routines.
- [ ] A person or team is responsible for evaluating CVE/vulnerability risk against exposure.
- [ ] A person or team is responsible for dispatching CVE/vulnerability to concerned people (SysOps, DevOps, developers, etc.).
## Tools
* GitHub tools
- GitHub provides guidelines and tools to secure code hosted on the platform. See [GitHub docs](https://docs.github.com/en/github/administering-a-repository/about-securing-your-repository) for more information.
- GitHub provides [Dependabot](https://docs.github.com/en/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies) to identify vulnerabilities in dependencies automatically.
* [Eclipse Steady](https://eclipse.github.io/steady/) is a free, open source tool that analyses Java and Python projects for vulnerabilities and helps developers mitigate them.
* [OWASP dependency-check](https://owasp.org/www-project-dependency-check/): an open source vulnerability scanner.
* [OSS Review Toolkit](https://github.com/oss-review-toolkit/ort): an open source orchestrator able to collect
security advisories for used dependencies from configured vulnerability data services.
## Resources
* The [MITRE's vulnerability database](https://cve.mitre.org/) of CVEs. See also [NIST's security database](https://nvd.nist.gov/) of NVDs, and satellite resources like [CVE Details](https://www.cvedetails.com/).
* Check also this new initiative from Google: the [open source Vulnerabilities](https://osv.dev/).
* The OWASP working group publishes a list of vulnerabilities scanners [on their website](https://owasp.org/www-community/Vulnerability_Scanning_Tools), both from the commercial and open sources worlds.
* J. Williams and A. Dabirsiaghi. The unfortunate reality of insecure libraries, 2012.
* [Detection, assessment and mitigation of vulnerabilities in open source dependencies](https://link.springer.com/article/10.1007/s10664-020-09830-x), Serena Elisa Ponta, Henrik Plate & Antonino Sabetta, Empirical Software Engineering volume 25, pages 3175–3215(2020).
* [A Manually-Curated Dataset of Fixes to Vulnerabilities of open source Software](https://arxiv.org/abs/1902.02595), Serena E. Ponta, Henrik Plate, Antonino Sabetta, Michele Bezzi, Cédric Dangremont. There is also a [toolkit in development to implement the aforementioned dataset](https://sap.github.io/project-kb/).
[^heartbleed]: https://fr.wikipedia.org/wiki/Heartbleed
[^equifax]: https://arstechnica.com/information-technology/2017/09/massive-equifax-breach-caused-by-failure-to-patch-two-month-old-bug/https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/21(Trust Goal) Manage legal compliance2023-05-16T13:11:15ZCedric Thomas(Trust Goal) Manage legal compliance
## Description
Organisations need to implement a legal compliance process to secure their usage and participation in open source projects.
Mature and professional management of legal compliance, in the organisation and across the sup...
## Description
Organisations need to implement a legal compliance process to secure their usage and participation in open source projects.
Mature and professional management of legal compliance, in the organisation and across the supply chain, is about:
* Performing a thorough analysis of the intellectual property that includes licence identification and compatibility checking.
* Ensuring the organisation can safely use, integrate, modify and redistribute open source components as part of its products or services.
* Providing employees and contractors with a transparent process about how to create and contribute to open source software.
_Software Composition Analysis (SCA)_: A significant part of legal and IP issues result from the usage of components released under licences that are either incompatible between them or incompatible with the way the organisation wants to use and redistribute the components. SCA is the first step in sorting out those issues as "you need to know the problem to fix it". The process is to identify all the components involved in a project in a Bill of Material document, including build and test dependencies.
_Licence checking_: A licence checking process uses a tool to automatically analyse the code base and identify licences and copyrights within. If executed regularly and ideally integrated into continuous build and integration chains, this allows catching IP issues early.
## Opportunity Assessment
With the ever-growing use of OSS in an organisation's information systems, it is essential to assess and manage potential legal exposure.
However, checking licences and copyrights can be tricky and costly. Developers need to be able to check IP and legal questions quickly.
Having a team and a corporate officer dedicated to IP and legal questions ensures proactive and consistent management of legal questions, helps secure open source components' usage and contributions and provides a clear strategic vision.
## Progress Assessment
The following **verification points** demonstrate progress in this Activity:
- [ ] There is an easy-to-use Licence checking process available for projects.
- [ ] There is an easy-to-use IP checking process available for projects.
- [ ] There is a team or person responsible for legal compliance within the organisation.
- [ ] Regular audits to assess legal compliance are scheduled.
Other ways to set up verification points:
- [ ] There is an easy-to-use licence checking process.
- [ ] There is an easy-to-use legal/IP team as in activity #13.
- [ ] All projects provide the required information for people to use and contribute to the project.
- [ ] There is a contact in the team for questions related to IP and licencing.
- [ ] There is a corporate officer dedicated to IP and licencing.
- [ ] There is a dedicated team for questions related to IP and licencing.
## Tools
* [ScanCode](https://scancode-toolkit.readthedocs.io)
* [Fossology](https://www.fossology.org/)
* [SW360](https://www.eclipse.org/sw360/)
* [Fossa](https://github.com/fossas/fossa-cli)
* [OSS Review Toolkit](https://oss-review-toolkit.org)
## Recommendations
* Inform people about the risks associated with licensing in conflict with business goals.
* Propose an easy solution for projects to set up licence checking on their codebase.
* Communicate on its importance and help projects to add it to their CI systems.
* Provide a template or official guidelines for project structure.
* Set up automated checks to make sure that all projects comply with the guidelines.
* Consider conducting an internal audit to identify licences of the company infrastructure.
* Provide basic IP and licensing training for at least one person per team.
* Provide complete IP and licencing training for the officer.
* Set up a process to escalate IP and licencing issues to the officer.
Remember that compliance is not just about legal; it's also about IP. So here are a few questions to help understand the consequences of legal compliance:
* If I distribute an open source component and do not respect the licence conditions, I infringe the licence --> legal implications.
* If I use an open source component within a project that I wish to distribute/publish, that licence may oblige visibility on elements of code that I do not want to make open source --> Confidentiality impact for my company's tactical advantage and with 3rd parties (legal implications).
* It is an open discussion about whether using an open source licence for a project I want to publish grants relevant IP --> IP implications.
* If I make a project open source _before_ any patent process, that _probably_ excludes the creation of patents concerning the project --> IP implications.
* If I make a project open source _after_ any patent process, that _probably_ allows the creation of (defensive) patents concerning that project --> IP potential.
* In complex projects that bring in many components with many dependencies, the multitude of open source licences may exhibit incompatibilities between licences --> legal implications (cf. Issue #23).
## Resources
* There is an extensive list of tools on the [Existing OSS compliance group page](https://oss-compliance-tooling.org/Tooling-Landscape/OSS-Based-licence-Compliance-Tools/).
* [Recommended Open Source Compliance Practices for the enterprise](https://www.ibrahimatlinux.com/uploads/6/3/9/7/6397792/compliancepractices_ebook_final.pdf). A book by Ibrahim Haddad, from the Linux Foundation, about open source compliance practices for the enterprise.
* [OpenChain Project](https://www.openchainproject.org/)