The complete security report is confidential, but some key findings will be shared with the FOLIO security team in one of the following meetings.
Hongwei is on vacation, but when he returns he can provide additional information to the security team.
0 min
Kafka security
Team
Background
The topic of Kafka security was raised as part of a conversation at the TC.
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.
Defer the security conversation until after the dust has settled
5-10 min
Keeping Dependencies Up to date
Julian/Team
Background
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 vulnerably 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?
Update from slack:
@hereI just had a conversation with Khalilah, she has a plan for asking teams to regularly update their dependencies each release cycle and will be communicating it out to teams on March 1. Leading up to that we both took some action items:
Khalilah will create user stories for individual teams/modules to check their dependencies and upgrade them during the bugfix phase of each release cycle (starting with Orchid).
She will also create user stories for teams to do these checks ~1/2 way through each release cycle to get a better idea for what's coming, and identify inter-team dependencies (e.g. for shared libraries, etc.), and help with planning.
I will discuss with the Security Team what guidance and/or tool recommendations we can make to help teams identify dependencies which can be updated... I'm thinking there must be a maven plugin or something for backend... and for frontend something likenpm outdated? We can discuss at our meeting on Thursday.
John Coburn have raised the issue there are so many dependencies which need to be upgraded. All we can do is chip away at this in Orchid and Poppy, the expectation being that we'd be caught up by Quesnellia and from there on it should be more doable to keep dependencies up to date on a per-release basis.
Doing the dependency upgrades in the "bugfix" phase of the release cycle is too late. We need to do this prior to the module release deadline. Craig McNally will circle back with Khalilah on this. Maybe there was a misunderstanding. It seems like we don't have enough time to start doing this work in Orchid. Let's plan it out and give teams a more reasonable amount of time, guidance, etc.
As far as providing guidance to teams...
Julian Ladisch proposed the idea of introducing BOMs for sets of folio dependencies. He will write it up with an example so we can share this with dev teams.
For frontend yarn outdated should do the trick to identify what needs to be updated.
For backend we need to find something that performs the same task (maven plugin?) Craig McNally will investigate and provide options.
Dependabot may be another option. If this is the direction we want to head in, we need to check which repos it's enabled for, etc.
Julian Ladisch will write it up with an example of the BOM for folio dependencies so we can share this with dev teams.
For frontend modules "yarn outdated --all" gives you the complete picture.
Would we be running this at the platform level? Module level? Both?
Dev teams should run this against their own modules
It will also be run at the platform level (by stripes architecture?)
We also have dependabot running in some places - running weekly
How do we prioritize what get's updated?
Dependencies with known vulnerabilities should be updated first
Support periods should be considered as well, but understanding what's supported, for how long may be challenging in itself
It's very difficult to stay on top of all these dependencies, it may not be realistic to expect to be able to update all outdated dependencies each release cycle
This plugin returns a lot of information including potentially unstable versions (release candidates, alphas, etc.) which we don't want teams to upgrade to.
Today:
Julian Ladisch will write it up with an example of the BOM for folio dependencies so we can share this with dev teams.
Java: All 38 security hotspots rules and all 53 vulnerabilities rules are enabled (2 deprecated vulnerabilities rules are disabled).
JavaScript: 53 security hotspots rules and all 27 vulnerabilities rules are enabled.
John Coburn will check whether the remaining 2 security hostspots rules should be enabled.
Julian Ladisch walked us through the ability to ignore vulnerabilities in Synk, including the ability to add notes, duration of the ignore, etc.
Skott Klebe to take a closer look and add ignore where applicable
0 min
Cumulative upload problem
Team
Background
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.
For Orchid all modules have migrated from Spring Boot 2 to 3. Only one exception: FOLSPRINGB-92 "Update mod-spring-template to Spring boot v3.0.0 and identify issues." However, this is a template not directly used in production.
This work was done for Orchid (Yay!)
Still unsure what the plan is wrt backporting to Nolana
Craig McNally to touch base with the spring-force team via slack.
Julian Ladisch created a "officially supported technologies" page for poppy: Poppy
The Spring-* versions have been updated, but everything else was copied over as-is from the Orchid page.
Craig McNally to raise this topic with the TC - how do we keep these pages updated?
Craig McNally to ping Oleksii P. again, didn't receive a response last week (wrt backporting to Nolana)
Craig McNally to keep this group updated as the TC makes decisions on the processes around maintaining/managing the officially supported technologies pages.
Today:
Oleksii's response:
"This work took 60 man/days for development and 20man/days for testing. Not sure, that we are going to repeat this for Nolana. I will double check with Mark."
It seems unlikely, but we'll wait and see what Mark says.
Conversations about officially supported technologies pages is ongoing with the TC.
5 min
Disable tenant checking to support multi tenant requests (MODAT-143).
Didn't get to this today. Will be sure to review the board next week.
Topic Backlog
Logging & Personal Data
Craig/Team
A developer recently reached to me asking if the security team or TC has guidance or rules in place for logging of personal data. Some guidelines are documented on the wiki, but I'm wondering if it's worth making some clarifications and creating a draft decision record for the TC to formally endorse
Is this even in our purview? Should we seek input from the Privacy SIG? Should I raise this with the TC first?
Next steps:
For now, put this on hold. See how the Draft DR approach works for the periodic dependency updates (see above). If that goes smoothly, we'll take this on next. Otherwise we'll consider other approaches.
