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:
Fix all problems that we can right away
“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
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.
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.
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.
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
