| Time | Item | Who | Notes |
|---|
| 1 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 with Julian Ladisch how 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 upgrade all third 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: @here I 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 like
npm 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
- For backend modules: https://www.mojohaus.org/versions/versions-maven-plugin/examples/display-dependency-updates.html
- This plugin returns a lot of information including potentially unstable versions (release candidates, alphas, etc.) which we don't want teams to upgrade to.
- Julian Ladisch will write it up with an example of the BOM and parent dependency for folio dependencies so we can share this with dev teams.
- some progress, but not ready to present to security team.
Today: |
| 5 min | OWASP/SNYK | Team | - Epic:
FOLIO-3582
-
Getting issue details...
STATUS
- Feature:
FOLIO-3583
-
Getting issue details...
STATUS
- User Story:
FOLIO-3584
-
Getting issue details...
STATUS
- User Story:
FOLIO-3709
-
Getting issue details...
STATUS
- Sonar ( https://sonarcloud.io/organizations/folio-org/quality_profiles):
- 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.
- Snyk: Skott Klebe to take a closer look and add ignore where applicable
Today: - What about the OWASP stuff?
|
| 1 min | Cumulative upload problem | Axel Dörrer | Background - Regarding file upload size issues (See
 FOLIO-3317 - Spike - investigate possible file upload vulnerability OPEN ), 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.
- Created
FOLIO-3615
-
Getting issue details...
STATUS
Chris Rutledge and Axel Dörrer to look at it and ask sysops folks to chime in
- Let's create a wiki page to capture ideas/feedback - Axel Dörrer → done
- Raised at the SysOps meeting
- A small working group was formed, but has not yet met.
- Group is meeting on Fridays... See link above for meeting notes, etc.
- Will be creating a test env. to aid in the investigation
- A similar issue was discovered in folio-vertx-lib... linked the issue to FOLIO_3317
- Wrapping up definition of test cases.
- Investigating available pentest tools.
- Test system/honeypot is in place
- preparing to create scripts for test cases
- SysOps group is working with a developer from Frankfurt
- Working towards running the pentest tools → utilizing information from RAML/OpenAPI for each module.
- Which environment is being targeted?
- A dedicated one provided by Leipzig
- Work in the NTC group is still progressing slowly
- Some movement in the origin issues ARCH-19 and MDEXP-487 (closed) .
- This topic should be divided into two
Today: - No updates this week.
- Do we need a standing agenda item for this, or can we rely on the kanban board to track this effort?
|
| 1 min | NCT group (Pen. testing) | | Progress is slow... at most expect monthly updates. |
| 1 min | STCOR-395 "refactor login form to avoid using any form framework whatsoever" | | Background - Create a spike to investigate what's involved in divorcing the login page from the NPM ecosystem. Will reach out to John and Ryan as needed.
- Reopen STCOR-395 and block on the spike. – Done.
- Where does this stand? Get an update from Ryan Berger / John Coburn
- Waiting for the spike (
STCOR-651
-
Getting issue details...
STATUS
) to be completed. – currently in the Open state.
- John to reach out to Skott to discuss what the level of risk associated with this. – Still needs to happen.
- John Coburn pulled together two PoCs. See comments in
STCOR-651
-
Getting issue details...
STATUS
- How do we want to move forward?
- Solutions need to be reviewed and discussed.
- Sounds like the iframe approach is a non-starter... actually a step in the wrong direction security-wise
- John Coburn (and others) to read up on browser CSPs
- John Coburn has made some progress on investing CSPs
- Will share some draft guidance we may want to include into the installation documentation (via slack)
- SG will review and provide feedback. Skott Klebe please take a look too
- Next up: John to work on some spike work - focused on introducing CSPs on the folio-snapshot site
- can serve as a reference impl of the guidance we'll be adding to the install docs
- Not much progress since last week, but hopefully get some movement on this soon.
-
FOLIO-3691
-
Getting issue details...
STATUS
Spike
- John Coburn trying to get this lined up for next sprint
- John Coburn to discuss with another developer (Maccabee) who is familiar with CSPs.
- John had the chance to look on it but only via metatag need to try out or examine http header configuration at the server side
- Some things happen in stripes modularity too which might have impact too
- John Coburn is making progress - has done some testing locally, but wants to exercise it in a more realistic env.
Today: - John Coburn No progress today - I don't think there's been much progress though.
|
| 1 min | Disable tenant checking to support multi tenant requests (MODAT-143). | | A few wiki pages have been shared on this... See Enhanced Consortia Support(ECS) Julian Ladisch will discuss his concerns with Olamide, etc. and we can discuss here again if/when needed. - There's a need to allow for the user to easily switch between tenant contexts
- Maybe making this opt-in is a reasonable approach
- the restriction would remain unchanged by default, but you could relax this constraint by making an explicit configuration change
- Julian Ladisch met with Thunderjet/Olamide
- mod-consortia/ui-consortia have been submitted for TC review
- This will probably be raised as part of those reviews
- Added a comment to the
TCR-26
-
Getting issue details...
STATUS
:
Security team disagree with breaking the tenant seperation on okapi token level. We would like to encourage an alternative solution on saml or openid techniques which would be less invasive to the current approach. - TC would like to split off the security/token concerns from the module acceptance, will be discussed next Wednesday TC's meeting
- Craig McNally to raise this with the TC again and get the ball rolling on discussing the larger topic (e.g. via a subgroup? RFC? something else?)
- Will involve Axel and Julian to a subgroup
- The TC approved mod-consortia, but also wanted to discuss the concerns raised about tenant isolation and relaxing tenant checks in certain circumstances. The TC plans to discuss on Monday 6/5 11:00 AM ET. → Julian and Axel to join the meeting
Today: |
| 5 min | FOLIO-3535 Upgrade bitnami/elasticsearch:7.10.2 in reference and vagrant development boxes (folio-ansible) | All | - Jakub Skoczen to bring this to the devops team asking to bump elasticsearch to a major version in this case
- but there is the concern who should responsible to keep these environments up to date and maintain them in general
- the devops team is greatly lacking on resources and can't take the task permanently
- need to have a discussion in a wider group (TC?)
Today: - Craig McNally to touch base with Jakub Skoczen about this in slack.
Get it on the TC agenda if needed.- My guess is that if DevOps can't do this, it will likely fall on the Kitfox team. It should be discussed with Oleksii P. and Mark V.
- I don't think the TC will be helpful here since they don't direct development resources/teams/etc.
|
| 1 min | Security team participation | Team | Discussed how attendance at these meetings has waned, and we should try to re-engage some of the members who haven't joined in a while. - Craig McNally to touch base with Ryan Berger to see what his situation is. If he'd like to step down, or start joining us again, etc.
|
* | Review the Kanban board. | Team | - Reviewed tickets which haven't moved recently. We made it up through EDGERTAC-72, then ran out of time.
Today: -
MODHAADM-27
-
Getting issue details...
STATUS
- PO Charlotte Whitt requested: "While we need to be careful about spending our available developer time wisely, it would be helpful if you could indicate whether this work is a must fix now, or something we can fix when/if we decide to build the FOLIO Harvester module."
- https://github.com/indexdata/localindices/pull/90 "MODHAADM-27: Migrate log4j from 1 to 2#90". This pull request uses the Log4j 1.x bridge (log4j-1.2-api), no code change is needed. This fixes all known log4j security issues, including https://nvd.nist.gov/vuln/detail/CVE-2019-17571 .
- What advice does the security team give? Fix now or postpone to 2024?
|
| Topic Backlog |
| Retiring issues which have been open for a long time w/o progress | All | Discussed gathering a report for the TC to review/approve. Need to work out details/logistics. Query so far: - labels = Security AND created < '-52w' AND status != closed AND status != completed AND status != Cancelled
|
| Bot Detection/Control | All | - Not a huge problem due to needing to authenticate first, and the user has the required permissions to get the information sought after.
- If using AWS, WAF bot control may provide some protection w/ little effort - Skott Klebe to investigate.
- Craig McNally to check in with Skott on this
|
| Time slot | All | Do we need a better time slot for the security team meeting to allow more members to join? |
| 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.
|
| Cyber Resilience Act | Team |
|