Capture due diligence for tooling approvals and recommendation.

[eddie-knight]

Problem

Considering the priorities and perspectives of FINOS members and end users, our projects should be more stringent than most when it comes to selecting tools.

The FINOS Community Website has a "Tooling" list within the Project Collaboration documentation, but this does not include a justification for things such as:

• Is this tooling simply approved or also recommended?
• Why is this tooling approved and/or recommended?
• Are alternatives acceptable?
• Are any alternatives unacceptable?
• What alternatives were considered before making this recommendation?
• What are the end-user implications of using this tooling?
  • For example: Is any end user information captured by a Third Party? If so, how is that information used?

Solution

We should maintain a due diligence document for each software approval and recommendations.

The format and approach for this has yet to be determined.

Items that currently need due diligence:

• Scarf.sh Due Diligence #158
• Dependency Management Due Diligence #159

[eddie-knight]

@eminty69 — I've heard strong opinions from you in the past about data privacy... Would you care to take the lead on defining the policy for what is acceptable when approving third-party tools? If we can put together a first draft, it'll be easier to get feedback from the rest of the TOC.

[JamieSlome]

@eddie-knight - thanks for raising this. From my side, I'd like to understand why a policy is required and at what point a tool requires approval. Ideally, and because this is open source, I think we should encourage autonomy and allow maintainers the freedom to choose and/or experiment.

That said, perhaps we can tap into existing policy flows (i.e. OSSF, CVE, Dependency Scanning) to provide useful advisory or informational suggestions to maintainers when adding new tools to a library?

[eddie-knight]

Hey @JamieSlome! The original concern is with regards to tooling that could be seen as exposing end user consumption information.

The intent wasn't to put in restrictions, though that could hypothetically be a result... but rather to put in explicit approvals so that maintainers can point to the TOC's due diligence where needed.