The topic of Kafka security was raised as part of a conversation at the TC yesterday.
The Security Team should be aware of this and probably should weigh in on the topic, or even generate proposals if we have ideas for how to solve the problem.
User Story: FOLIO-3584SPIKE - investigate OWASP Zed Attack Proxy (ZAP)
Progress on FOLIO-3584?
Skott ran a scan against MG Bugfest
Skott Klebe and Craig McNally to review results... weed out false positives, then bring results to next week's meeting.
Scan stopped at 95% (OOM issue in Firefox)
Any other features/stories we want to create?
Not related to OWASP, but I think Skott Klebe suggested that our SNYK could be tuned/adjusted to better suit our needs.
Maybe make the Epic more generic – "Security Fitness Functions" or Create another epic to track the non-OWASP stuff?
SNYK
Should define JIRAs
Spike to investigate how we can tune snyk to better suit our needs – Craig McNally to create this.
Provided some background/history about SNYK in the FOLIO community
Stripes architecture reviews dependencies every other flower release (1-2x/year)
Currently only looking at platform level (with package.json/lock files)
Avoids a lot of the dev/peer dependency false alarms
Skott Klebe will have limited time to spend on SG activities but will have some time to spend on the TBD Snyk spike in mid-December.
It sounds like he's seeking help from someone more familiar with snyk ... either to have a conversation or provide documentation links.
All this means is the spike JIRA should contain documentation links
Also need to clarify which repos are integrated with Snyk, and what the process looks like for managing this.
TODO: look at the FOLIO documentation on Snyk.
Today:
Spike still hasn't been created yet.
1 min
Cumulative upload problem
Team
Regarding file upload size issues (SeeFOLIO-3317-Spike - investigate possible file upload vulnerabilityOPEN), let's brainstorm ideas for mitigating the cumulative upload problem, not just the large file upload size problem.
Some APIs are more vulnerable to this than others, such as those not protected by permissions - e.g. mod-login, edge APIs, etc.
Axel provided some background/context. We still need to give this some thought and possibly suggest a solution
Use case 1: Some script unintentionally sends endless data to some API. This is caught by a maximum upload size.
Use case 2: Denial of service. Difficult to address in Okapi. Might be better handled in other tools like nginx or firewalls that can limit requests. Unlikely that a denial of service attack has a valid login / access token.
TODO: For use case 2: Only add documentation that implementers should use an external firewall (or external nginx) to limit requests.
Some investigation is required, let's capture this in a spike (JIRA).
Axel Dörrer to help define this. – Started, not finished yet.
We can review together and find someone to work on this... maybe have a champion on this team work with someone in the Sys-ops SIG/community.
I've added versions for the Spring components to theOfficially Supported Technologies list. For Orchid it's easy:https://wiki.folio.org/display/TC/OrchidFor Nolana it's more complicated:https://wiki.folio.org/display/TC/NolanaThe OSS support of several Spring components ends in May 2023. This is more than three months before the end of the Nolana support period that end in August or September 2023. The next minor version of those Spring components will be released in November 2022, this is during Nolana bug fest. We need to bump to this next minor version and release a bug fix for all affected FOLIO Spring libraries and FOLIO modules in November 2022.Running unsupported Spring components is a security risk. If there is a security issue in asupportedSpring component we simply can bump the patch version, no risk. If there is a security issue in anunsupportedSpring component we don't get notified because it's unsupported, and if we know of an issue we need to bump the minor version, this comes with some risk. Bumping the minor version as early as possible gives more testing time and is less risky. We can discuss this today.
How do we want to approach this?
Consult the Spring Force team... Is this feasible? Do you have better suggestions?
Craig McNally to post in #folio-spring-base, at-mentioning Petrenko.
How do we communicate this out?
Coordinate with the release manager (Oleksii Petrenko)
How much work is expected to be required?
Craig McNally to follow up with Oleksii P. again to see if the team has discussed this yet.
Met with Oleksii P. and Spring-force. They're onboard with this proposal and will take it from here.
There are complications with this... conversations in #folio-spring-base:
Spring Boot 2.7 has extended OSS support until 2023-11-18, this completely covers the Nolana support period (~ August 2023), no need to switch to Spring Boot 3, but see below
However, folio-spring-base also uses Spring Cloud, and other Spring way modules also use other Spring components without extended OSS support
Spring Cloud 3.1 support ends 2023-05-18, this is at least three months before the end of the Nolana support period around August 2023.
Spring Cloud 4.0 GA release will be in November 2022.
Spring Force team has agreed that Milestone versions can be used. These need to be replaced by the GA version. Nolana GA release will be in December 2022.
Only recently (2022-10-04) Spring Force noticed that Spring Cloud 4 requires Java 17 and only (officially) supports Spring Boot 3.
Also introduced the topic at the Technical Council meeting yesterday but ran out of time. The TC will discuss more in slack and if necessary at next week's TC meeting.
Last week it was decided that the Spring Upgrade (Spring Boot from 2.7 to 3, Spring Cloud from 3.1 to 4) and the Java Upgrade from 11 to 17 is postponed to Orchid; and:
Two options that need to be discussed in January 2023
Limit support of Nolana release up to May 2023
Backport of Orchid spring-based changes to Nolana HF
Postpone for now – at some point we need to check in with spring-force to see how things are going
Looks like JIRAs have been created for some of this – a good sign
Seem some JIRAs have been created. Need to get an update from Taras / Spring force at some point.
Today:
Developers are migrating several repositories to the new major Spring version. Might be in time for Orchid.
1 min
Security Team processes - revisited
Team
Review/discuss the proposal shared in slack
The team reviewed the document changes and agreed that everything looks good.
Craig McNally to merge these changes into the official document
Craig McNally to notify Khalilah of these changes. It will be up to her to decide how to disseminate this information to the POs
I've merged the changes we reviewed/discussed a few weeks ago into the official documentation: FOLIO Vulnerability and Remediation Policy. I also gave Khalilah a heads up about these changes and additionally recommended that teams check for and update their dependencies on a regular basis, e.g. once per release cycle, twice a year, etc.
5-10 min
MODEXPS-186
Julian/Team
MODEXPS-186"Describe way how to check dependency vulnerabilities during RMB versions upgrade" reads:
Purpose/Overview:We need to increase version of dependencies that have vulnerabilities during RMB versions upgrade Approach: Contact withJulian Ladischhow to run vulnerabilies scanner to identify list of versions that need to be increased. Add step into acceptance criteria of RMB upgrade stories to run this scanner and update versions of these dependencies. Update Jira template of RMB upgrade story to include this new step to check vulnerable versions.
Is there some misunderstanding? For each flower release development teams should upgradeallthird party dependencies. Either to the latest production ready version, or to an older version that is supported by the third party for the complete period of the FOLIO flower release (if the development team uses some unsupported version it must do security monitoring and prepare for backporting security fixes and for writing security fixes if no fixes are provided by the third party). These upgrades should be made for all dependencies, regardless of any known vulnerabilities. This is needed to keep hot fixes as small as possible if a vulnerability needs to be back-ported later on.
If teams commit to updating all of their dependencies on a per-flower-release basis, the need for teams to use a vulnerability scanner is much less.
When communicating the revised security team processes (see above) to the product owners (via Khalilah), we should also strongly recommend that teams do this.
Maybe we can get the TC to endorse this and make it official policy?
