search

bcgov / digital-journeys

PSA Forms System
https://bcgov.github.io/digital-journeys/
Apache License 2.0
8 stars 7 forks source link

Red Hat Dashboard - Critical Vulnerabilities #1701

Closed MeghanStothers closed 2 months ago

MeghanStothers commented 6 months ago

Jason Yang let me know there are critical vulnerabilities on the Red Hat dashboard for formsflow - can you have a look?

Stella-Archer commented 6 months ago

@MeghanStothers does Jason mean here > https://status.developer.gov.bc.ca/ I'm not sure where to access the redhat dashboard Do you @warrenchristian1telus

warrenchristian1telus commented 6 months ago

@MeghanStothers @Stella-Archer - Not sure if this will be patched by the updates this week. Maybe we should (re)review after the updates are in place in prod? There are some critical vulnerabilities I see listed in dev (which I believe has the latest updates), but they are all 8+ months old, which suggests to me they have been reviewed and cleared (unfixable or not remotely accessible). The ACS dashboard can be found here (although I think only DevOps team members have access): https://acs.developer.gov.bc.ca

warrenchristian1telus commented 6 months ago

We also have 49 open pull requests from Snyk and Depndabot, which we should consider implementing. Some are from over a year ago, so should likely either be implemented or cleared-out. https://github.com/bcgov/digital-journeys/pulls

fazil-ey commented 6 months ago

@bhumin-fw to follow up with Warren to coordinate what needs to be shared with AOT to get their input on what vulnerabilities can be resolved by them

warrenchristian1telus commented 6 months ago

@bhumin-fw @Stella-Archer

After some consideration and investigation, my recommendation is to disable all automatic PR (Pull Request) notifications from Snyk and/or Dependabot and leave dependency management and [most] security patching to AOT. We can still leave vulnerability scanning and reporting on, so we can identify any issues that could affect our deployments.

There are too many (NPM) dependencies in FormsFlow for us to take on patching it. Instead, we should rely on AOT releases for our cues to update/patch:

AOT Forms-Flow-AI Releases

Even better, we could adapt our workflow to watch the appropriate repository branch for us, and use a similar process so that we would now get a (single) PR to update FormsFow, rather than 50 smaller ones to address the underlying components.

This should allow us to make these updates by reviewing/approving a single PR issue which will automatically deploy [to dev] once approved, and then running a suite of tests (which will hopefully also be automated one day).

This will cut down these tickets/changes from almost daily, to one every couple of months or so. It also eliminates much of the associated investigation, development, testing and deploying.

We can use this GitHub Action (or similar) to generate the new PRs and provided the required details and notifications to the team, so that it can be scheduled for release.

GitHub Release PR Action

The catch to using the action above is that we may need to implement Conventional Commit 1.0.0 commit messaging in our repo / development workflows (and likely try to match in ZenHub tagging, labeling, etc.).

Conventional Commit 1.0.0 Standard

Fork Sync may work better for our purposes, and seems to be much simpler.

GitHub Fork Sync Action

Either way, we can discuss/test to figure out how best to handle these (much less frequent) updates.

This won't resolve all of our vulnerability issues.

Snyk includes just 49 of 2,723 currently CVEs flagged in prod by ACS.

I'm not sure if we really need to discuss this with AOT, but if we do, maybe we could focus on our best options for scheduling and notifications. For example, what best practice is for implementing timely updates once they are released. Scheduling security patches vs. functional upgrades, etc.. Can/should we automate this piece?

Stella-Archer commented 2 months ago

@warrenchristian1telus is this critical should we be looking at this next sprint?

warrenchristian1telus commented 2 months ago

@Stella-Archer This is no longer critical. ACS dashboard is now showing that we have zero critical vulnerabilities in production. I think previous updates have resolved those.

I think we could [re]address our update/upgrade procedures for products outside of AOT control (MongoDB, Patroni, KeyCloak images, etc.) when we tackle luster right-sizing and deployment strategies.

As this issue is regarding critical vulnerabilities, I would say it can be closed and we can discuss/migrate options for ongoing updates in my comment above: https://github.com/bcgov/digital-journeys/issues/1701#issuecomment-2057274925

Stella-Archer commented 2 months ago

Thanks @warrenchristian1telus Ive tagged this to the 'right sizing' epic so w don't lose sight of it and am closing