The @shopify/react-native-skia package has no known direct vulnerabilities in its published versions and is safe to adopt, but because it ships native binaries and sits deep in your app's rendering path, the security questions worth asking are about its install mechanism and dependency tree, not about a specific CVE. Maintained by Shopify, it wraps the Skia graphics engine (the same one behind Chrome and Flutter) to give React Native apps fast, expressive 2D drawing.
Popularity is high — the package pulls hundreds of thousands of weekly downloads — but download counts are a maturity signal, not a security guarantee. Let's look at where the actual considerations are.
The clean bill, with context
Vulnerability databases do not report direct vulnerabilities against @shopify/react-native-skia. That is a genuinely good sign for a library this widely used, and it reflects a real maintenance team plus Shopify's bug-bounty program on HackerOne for security reporting.
Two honest caveats belong next to that clean bill:
- "No known direct vulnerabilities" says nothing about the package's own dependencies, which are a separate surface.
- A native graphics library is high-value if it ever were compromised, because it processes untrusted image and drawing data on the device. Absence of a reported flaw is not the same as absence of risk.
Neither is a reason to avoid the package. They are reasons to treat it like any other native dependency: monitor it.
Native binaries and the install path
The most security-relevant characteristic of this package is that it delivers compiled native code, not just JavaScript. Historically, native npm modules leaned on postinstall scripts to fetch or build binaries, and postinstall scripts are one of the most abused vectors in JavaScript supply-chain attacks — they execute arbitrary code on every developer machine and CI runner that installs the package.
The reassuring detail here: the Skia prebuilt binaries are shipped as regular npm dependencies rather than fetched through a postinstall step, so there is no install-time script to audit or allow. That is a materially better design from a supply-chain standpoint than the fetch-on-install pattern, because what you get is exactly what npm resolved and your lockfile recorded — nothing runs code during installation to go pull something else.
You can confirm your install does not silently run scripts by installing with scripts disabled and checking it still resolves the binary as a normal dependency:
npm ci --ignore-scripts
If a native package needs a postinstall to function, that command reveals it. For this library, the prebuilt-as-dependency model means you have far less to worry about.
Pin versions and commit the lockfile
Because this package brings compiled artifacts, reproducibility matters more than usual. You want every developer and every CI run to resolve the identical binary.
npm ci # installs exactly what package-lock.json specifies
Commit package-lock.json (or yarn.lock / pnpm-lock.yaml) and gate version bumps through code review. When you do upgrade, read the release notes — a graphics engine update can change rendering behavior in ways your tests should cover, and it is also your opportunity to pick up any security fixes in transitive dependencies.
Watch the dependency tree, not just the package
The package itself may be clean while something it depends on is not. Inspect and monitor the resolved tree:
npm ls @shopify/react-native-skia
npm audit
npm audit reflects only what is known the moment you run it. For a long-lived mobile app, continuous monitoring is the durable practice — you want to hear about a newly disclosed advisory on a transitive dependency without re-auditing by hand. A software composition analysis tool such as Safeguard can track the full dependency graph of a React Native app, including native module dependencies, and flag new advisories as they land.
Handling untrusted input in your drawings
Beyond supply-chain hygiene, think about what data you feed into Skia at runtime. If your app renders user-supplied images, SVG-like paths, or remote drawing instructions, treat that input as untrusted:
- Validate and constrain image sources and sizes before rendering to avoid resource-exhaustion issues.
- Do not construct drawing commands by interpolating unsanitized user input.
- Load remote assets over TLS and verify their origin.
These are application-level responsibilities that no library can enforce for you. Skia draws what you tell it to; deciding what is safe to draw is your job.
A practical adoption checklist
- Install and confirm no unexpected
postinstallruns (npm ci --ignore-scripts). - Commit your lockfile and pin the version.
- Run
npm auditand enable continuous SCA monitoring of the full tree. - Read release notes on every upgrade, both for behavior and for security fixes.
- Treat any user-supplied graphics input as untrusted at the application layer.
FAQ
Is @shopify/react-native-skia safe to use?
Yes. It has no known direct vulnerabilities, is maintained by Shopify with a bug-bounty program, and ships its native binaries as regular dependencies rather than through risky install scripts. Standard dependency hygiene — pinning, lockfiles, and continuous monitoring — keeps it safe.
Does the package run postinstall scripts?
No. The Skia prebuilt binaries are delivered as ordinary npm dependencies, so there is no postinstall step fetching or building code at install time. That is a meaningfully safer design than the fetch-on-install pattern common to older native modules.
What are the main security concerns with react-native-skia?
Not a specific CVE, but the general profile of a native graphics library: its transitive dependency tree, reproducible installs of its compiled binaries, and how your app handles untrusted image or drawing input at runtime. Monitor the tree and validate inputs.
How do I keep the library secure over time?
Pin the version, commit your lockfile, review release notes on upgrades, run npm audit, and enable continuous software composition analysis so new advisories on the package or its dependencies reach you automatically.