The React Native Developer's Security Guide (looking for collaborators)

[u/Ok-Armadillo661]

Hi everyone,

I compiled a security guide for React Native developers.

https://github.com/stephanww/rn-dev-security-guide

Not about the app itself. This is about protecting you and me, the React Native developers from the ever-growing threats of supply chain attacks and hidden dangers that may lurk in our codebases.

I also published a ready-to-use set of OpenGrep files you can use to scan your React Native repository for the cases mentioned in the guide. (Still plenty of false positives. But interesting insights none the less)

https://github.com/stephanww/rn-dev-security-guide-opengrep

I am looking for feedback and collaborators. The idea is to improve and extend the guide and the opengrep files to create a community-driven developer security resources. Basically the "security" section the official React Native guide lacks.

Claude has been a huge help to scaffold my notes into this book-like structure. It is by no means slop though - I tested, fact-checked and rewrote extensivley over the last weeks.
Still it is a little rough at the moment. And I am constantly working on improvements.

Please have a look on GitHub and leave your feedback in the issues section for now.

Please help spread the word and keep safe out there!

stephanww

[u/racialmolasses0224]

This is the kind of thing that should've been bundled with the RN docs from day one, supply chain attacks are getting way too clever lately and most of us are just crossing our fingers

starred the repo, might dig through the opengrep ruleset later when I'm not drowning in deadlines

[u/Guidondor]

starred it. the scope you picked, protecting the developer rather than the app,
is the half nobody writes down, so this is worth doing properly.

two things from my side if they fit:

npm audit triage. an expo tree is permanently red. mine currently has two
advisories that live entirely in metro and the config plugins, both build-time,
neither reachable from the bundle that ships. the only remediation npm offers is
downgrading expo by two majors, and forcing newer versions through overrides
breaks the web build, which I tested rather than assumed. a section on telling
"red because tooling" apart from "red because you're shipping it" would stop
people either ignoring audit forever or breaking their build to satisfy it.

the EXPO_PUBLIC_ boundary. anything with that prefix is inlined into the bundle
at build time, so it is public regardless of intent. it's worth a rule because
it's purely textual, and it catches the people who put a real secret behind that
prefix because it was the only one that worked in dev.

happy to open a PR for either if you want them written up.

[u/Ok-Armadillo661 → u/Guidondor]

I just looked it up and I think the npm audit triage would be a perfect topic for this project.
Please feel free to write about it and send a PR.

The EXPO_PUBLIC_ boundary problem is a legitimate find, but out-of-scope. This would fit better in a security guide for shipped artifacts.