2023-11-02 Meeting notes

Craig McNally 

Axel Dörrer 

Chris Rutledge 

Jakub Skoczen 

Skott Klebe 

• SECURITY-9 - Getting issue details... STATUS
  • Craig McNally  will investigate/reach out to devs for:  edge-courses, edge-fqm, and mod-consortia
    • Created story for mod-consortia and linked it to SECURITY-9
    • edge-fqm/edge-courses:  the edge-common-spring framework apparently has a runtime dependency on the folio-spring-system-user library (due to dependency injection?).  I've reached out to Taras to see what we can do about this, but he's on vacation.  Circle back next week.
      • No update from Taras yet.  Craig McNally will check with him and report back in Slack.
  • Axel Dörrer will do the same for the other 4
    • Has created some, e.g. MODCON-114 - Getting issue details... STATUS
    • mod-caiasoft, edge-dematic, edge-inn-reach, edge-dcb still don't have JIRAs.
• We reviewed several isues.
• Started to review the SECURITY issues filed yesterday, but ran out of time.
  • Julian Ladisch will continue to take a first pass at these and we will revisit next week.

• EBSCO has started using a commercial tool (Prisma) for vulnerability scanning.
• This is needed for LoC / FedRAMP compliance.
• The most recent scan has found numerous vulnerabilities related to outdated dependencies
  • Many are related to Spring and will be addressed when teams upgrade to Spring (3.2.x?)
    • I believe this is planned for Quesnelia.  Need to double check though.
  • Excluding those we're looking at ~20 Critical and ~130 High vulnerabilities
  • The open question is whether or not any of these should be embargoed.
• Critical (the ~20 are some combination of the following in various modules):
  • 
  • While these are probably P1s, I don't see anything that screams "must embargo".  Let's discuss.
    
    • org.yaml_snakeyaml - https://nvd.nist.gov/vuln/detail/CVE-2022-1471
      • We triaged this a while ago, see SnakeYaml SafeConstructor
      • If there are modules which Prisma found and Snyk missed, maybe we should embargo those JIRAs since this is an older vulnerability and is therefore more likely to be exploited.
      • We need a list of modules so we can make an assessment.
      • Create an umbrella JIRA, listing the affected modules.  We can then create module-specific JIRAs as needed.
    • org.apache.commons_commons-text - https://nvd.nist.gov/vuln/detail/CVE-2022-42889
      • We need a list of modules so we can make an assessment.
      • Create an umbrella JIRA, listing the affected modules.  We can then create module-specific JIRAs as needed.
    • com.fasterxml.jackson.core_jackson-databind - https://nvd.nist.gov/vuln/detail/CVE-2018-14721
      • This one is less clear to me.  Need to dig into it and discuss
      • Applies to:
        • mod-licenses
        • mod-oa
        • mod-service-interaction
        • mod-agreements
      • From Julian Ladisch : jackson-databind (CVE-2018-14721): I've investigated both the master branch and the Orchid release branch of the four modules mod-agreements, mod-licenses, mod-oa and mod-service-interaction. Running cd service; ./gradlew dependencies shows that jackson-databind 2.13.4.2 is used. Snyk also reports this version. This is a fixed version. Prisma's version resolution is wrong.
    • org.apache.logging.log4j_log4j-core - https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228
      • Applies to:
        • mod-bulk-edit
        • mod-aes
      • Both of these modules have been archived/deprecated.  No need to do anything here.
• High
  • Similar analysis is complete.  How would we like to weigh in on whether or not these should be embargoed?
  • See SECURITY-12 - Getting issue details... STATUS through SECURITY-26 - Getting issue details... STATUS
• EBSCO/EPAM are awaiting our feedback and will create JIRAs for all of these.  Grouping vulnerabilities into fewer JIRAs where applicable

From slack conversation, I think I've gathered the following:

• In this case (bank account and transit numbers), the information is highly sensitive.  
• Highly sensitive information should:
  • Be stored in it's own table
  • Accessed via a dedicated API
  • Protected by a dedicated permission
  • Encrypted in the database, not only on disk.  
    • This could mean either:
      • Explicitly encrypting/decrypting in the application layer and storing the encrypted data in postgres
      • Utilizing postgres extensions/modules to encypt certain columns, e.g. via pgcrypto (see https://www.postgresql.org/docs/current/encryption-options.html)

Let's review and discuss before providing this feedback to Raman.

Axel Dörrer also suggested that defining classes of sensitivity could help teams determine which techniques are applicable in various situations.  I agree having some general guidelines on this would be helpful.

• regular data
• low sensitive - permission based on same API
• high sensitive - permission based on dedicated API

It would probably help to provide concrete examples of data in each class.  This can be a longer term effort, we don't need to sort out all the details today.