Ensuring that RedwoodJS releases pass the security audit

I started a brief version of the issue being described here, with @ajcwebdev and @Krisztiaan in the Discord / General section, and am carrying it here for everyone to participate.

Today I run the command yarn rw dev and got a tip (most likely from yarn) that I should run the command yarn audit from the root of my project. Here is what I got:

Two occurrences of high risk coming from the package immer and 1 occurrence from prismjs. There is also information on the version for each package, where this risk was fixed.

Not all offending packages are direct dependencies of RedwoodJS., so we may not be in the position to address such problems in our release creation process - however, we can:

  1. Fix all problems that we can right away
  2. “Invent” a process to address that globally. GitHub would be a good example of such a “clearinghouse”.

My years-long “fear” that node based application development will crumble under the weight of all packages used in a typical application is caused by this information (the redwoodblog tutorial application finished only up to and excluding Cells | Learn RedwoodJS


I am sharing this screenshot to show my still lasting amazement with the sheer size of this application. How could anything that includes 67,781 parts work together in a reliable fashion??? More seriously though, this size information is the reason that we all do our best to ensure the best fit for all these parts

Thoughts? Ideas?

The idea of having an audit process - manual automated or augmented via tools like Dependabot and setting up automating policies or scanning via

sounds like something to do – and to that end since there is a meetup this Friday, let’s open it up for discussion and see if anyone from the community wants to take the lead on what the next steps should be.

Also, we could consider setting up automated code scans via:

Is anyone else in the community using this? And if so, how has it been working out?

Mentioning GitHub and Dependabot in the same context, means that we are reading the immediate future well - as this article explains.

Errata: replace immediate future by recent past

Maybe Snyk | Developer security | Develop fast. Stay secure. would help redwood out as it can replace dependabot and also it is.

free to open source projects.

They also have a Vulnerability DB | Snyk that has a list of loads of npm package vulnerability

1 Like

Thanks @Chris! We can compile a list of third-party tools to help run audits and then perhaps the Community can review and test out a few to make a recommendation.

tl;dr: This is a great, important topic. The potential vulnerabilities listed in the original post are low risk. The opportunity to improve communication about the topic of Security is timely and important.

To be clear, we do utilize GitHub security tools and have continual dependency scans running in the background. When the Core Team maintainers receive alerts, we assess and take action. This is not publicly visible activity for, well, security reasons.

There’s improved communication action we can and will take. Thank you for nudging us in this direction.

Two final things:

  • a part of the assessment is evaluating what and where there is a security risk and then taking appropriate action. In the case of development-only tooling, e.g. Storybook, the risk is much lower
  • Redwood Framework Security != Security of Applications built on Redwood → Of course we want to ensure security best practices and make the framework as secure as possible (this is our responsibility) — ultimately security rests in the hands of the application developers who use Redwood. We will do as much as we can, but we can only do so much.

Also see Security Best Practices especially having security.txt and security.md


It seems that this little paragraph did not catch anyone’s attention, so I am raising it again, to steer the conversation to discuss the following: if the yarn audit reports security violations somewhere deep in my app’s dependency chain, how can I address it other than sending a message to the offending module maintainer, asking to cause that “sub-chain” in a way to make the violation reported by yarn audit go away.

I do not know enough about yarn to propose just updating the version of immer to fit the report stating that it is updated in version >= 8.0.1 (see npm advisory.

There ought to be a better solution for such my-app local patching, as this would soon become unwieldy.

this might be helpful:

You seem to always be awake and always very helpful. Do you get tired sometimes :grinning_face_with_smiling_eyes:

This article Fixing security vulnerabilities in npm dependencies in less than 3 mins is explaining more details

FYI - The redwood repository does have security advisory notices on:

Thanks, David! I posted a few questions about ensuring that any RW app behaves correctly and fully expected that someone (you in this case) will tell me that the RWJS team thought about it.

I am still nearly overwhelmed with the richness of RW information, so help like yours is very appreciated