Date

Thursday 15 April 2021 - 12pm EST / 5pm UK

Untracked attendees

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

• Convene, roll call, welcome new people
• Display FINOS Antitrust Policy summary slide
• Approve previous meeting minutes
• DevOps approach at Deutsche Bank - cc @peterrhysthomas
• DevOps Mutualization open SIG team role ... Project Operations Manager
• The first DevOps Mutualization Team Discussion has been posted at https://github.com/orgs/finos/teams/devops-mutualization-participants/discussions/3 as highlighted below.
  • Follow these instructions to Join DevOps Mutualization Team Discussions.
    
• AOB, Q&A & Adjourn (5mins)

Meeting Minutes

• Roll call

  • Amol Shukla, Morgan Stanley
  • James McLeod, FINOS
  • Peter Rhys Thomas, Deutsche Bank
  • Tristan Maat, Codethink
  • Ashok Singh, JP Morgan
  • Rajeev Agrawal, Wells Fargo
  • Tim Johnson, CloudBees
  • Anders Wallgren, CloudBees
  • Preeti, Wells Fargo
  • Tosha Ellison, FINOS

• Antitrust policy slide

• Previous minutes reviewed & approved

• DevOps approach at Deutsche Bank, Peter Rhys Thomas

  • Large organizations, software supply chain controls are built up over years, with various baggage attached to them
  • Based on attestation by people
  • "Accumulate trust" rather than "implicit trust"
  • Reference to Google document no shifting security left, section on "Accumulating trust": https://cloud.google.com/files/shifting-left-on-security.pdf
  • People state that various things have happened, but tick a box, but do not provide evidence
  • Accumulate facts and evidence, use rules based on that evidence to decide how/when to proceed
  • Instead of attesting that something happened, people provide evidence, system applies rules to that data
  • Similar approach wrt. GDPR: don't just say you comply; instead, verify compliance wrt. the facts of what's deployed where, e.g.
  • Peter showed example CI/CD pipeline that runs a tests, provides attestation that those tests have run, that fact is recorded/signed; "test are passing; security scans are passing; manual QA checks/UAT are passing"
  • Prior to deploying to production, attestations are automatically verified
  • Next, what are the attestations & the rules? Most banks have additive controls -- you always add, but never take away, controls. Often rules are added in response to an incident, control gets embeeded to avoid that happening again. Now able to look at all the controls and decide "which ones do we need?" Using https://github.com/grafeas/kritis for this. Currently 22 rules, that fall into 3 categories: (1) traceability of requirements behind all changes (no changes not traceable to a requirement), (2) have a number of people attested that there's appropriate test coverage, (3) does your platform have "technical readiness" to deploy; do you have appropriate release & rollback processes to proceed?
  • Effectively: automatic/manual attestation, some manual attestation by pull request, others automatically. Using github with prebuilt actions teams include in their workflows; they both perform the task and the attestation. E.g. a container scan needs to be performed; an action does the scan, generates the result, provides the attestation with the result.
  • Business user approves the manual attestation pull request
  • Q: Are these encoded into artifacts?
    A: It's building up a set of facts into artifacts; prior, these were not collected in this way and the process didn't check those facts at the time of deployment. If you had an open change windows and an approved change ticket there was no link between what was being deployed vs. what should be deployed. They're not literally embedded inside the image, but effectively, they are. Approvals were recorded, but the facts around the approval were implicit. Now they are explicit.
  • Q/Comment: With many approval requirements, need to develop a shared understanding of what controls we need to get to. Peer review, evidence provision, etc. There's an issue open in the SIG repository around this shared understanding.
    A: Big thing we found is that when you dig into the 22-23 rules we have, there's disconnect between what's required and what's being done. Much easier to go back and work forward from the beginning.
  • Comment: DevOps Mutualization - Structuring conversations around SDLC and Iterating the different types of evidence that needs to be produced #4 -- discussion around rationalizing types of evidence
  • Comment: This is useful; we have effort around the pushback around the commit-to-production flow
  • Comment: Great because it also makes it easier to do post-deploy audits, in addition to providing real-time controls
  • Comment: Nice to be able to link the controls to the reasons why they exist for developers to understand why they need to do the things they're asked to do

• Discussion on Team Discussions (ref below on Metrics discussion)

  • Discussion around forums for these types of discussions: Github issues are public, Github team discussions (w/CCLA/membership required) are more private
  • Discussion around artifacts & reference outputs from these discussions, with goal to share with regulators, the Reg SIG, others
  • James: How do we move forward & action getting artifacts out of these discussions?
  • Tosha: I will reach out to our Reg leads to see if they have documents they know regulators like
  • Q: James to Peter, anything at DB around what formats regulators like to see?
    A: I will ask our reg folks.
  • Ashok: Call for information about processes/procedures that are used in our member firms

• DevOps Mutualization open SIG team role ... Project Operations Manager

  • Job posting at https://github.com/finos/devops-mutualization/blob/master/docs/open-roles/project-operations-manager.md
  • Open-source role, same context & spirit as how we all join these calls

• Amol reviewed the DevOps Metrics discussion topic

  • James: Banks requested a more private area within the SIG for these types of discussions, please join!

• AOB, Q&A & Adjourn

  • Tim Johnson: call for papers to DevOps World 2021, please consider submitting
  • Q: what type of formats?
    A: Tim: Pretty open: "a problem and how we solved it", panel discussions, etc.
  • James: perhaps a FINOS-centric panel? (near-universal acclaim from the audience ;-)
  • Tim: You have a friend who sits on the programming committee...
  • Adjourned

Decisions Made

• ...

Action Items

• ...

WebEx info

Webex:
https://finos.webex.com/finos/j.php?MTID=md62056638ba05fbea86b9582df94f807

Dial-in

• US +1-415-655-0003 US Toll
• UK +44-20319-88141 UK Toll
• Access code: 127 662 6070

Github Repo: https://github.com/finos/devops-mutualization/

Mailing List: Email devops-mutualization+subscribe@finos.org to subscribe to our mailing list