feat: add Snyk dependency scanning and Netlify deployment config - #1753
Open
magic-peach wants to merge 1 commit into
Open
feat: add Snyk dependency scanning and Netlify deployment config#1753magic-peach wants to merge 1 commit into
magic-peach wants to merge 1 commit into
Conversation
── Snyk ─────────────────────────────────────────────────────────────────────
snyk added as a devDependency (via bun — this repo uses bun.lock, not npm),
a .snyk policy with no ignores, a `bun run security` script, and a dedicated
snyk.yml workflow.
Separate workflow rather than a job in main.yml: it needs a different trigger
gate and a different secret, and a security finding failing "CI" would read as
a broken build. It also matches how this repo already splits concerns, with
lint.yml, typecheck.yml and chromatic.yml each standing alone.
Two things the obvious setup would have got wrong:
* Snyk's Node scanner resolves dependency trees from package-lock.json,
yarn.lock or pnpm-lock.yaml. bun.lock is not a supported target file, so
`snyk test` here would fall back to package.json ranges and miss
transitive vulnerabilities entirely. Both CI and the local script generate
a throwaway lockfile first with `npm install --package-lock-only`. It is
never committed — package-lock.json is gitignored and CLAUDE.md forbids it.
* Fork PRs get no repository secrets, and nearly all contributions here come
from forks, so the job is gated to pushes and same-repo PRs. Otherwise
SNYK_TOKEN would be empty and every contributor PR would fail red.
Requires a SNYK_TOKEN repo secret, which does not exist yet.
── Netlify ──────────────────────────────────────────────────────────────────
netlify.toml with an explicit `bun install && bun run build` and publish = out.
Explicit because Netlify's package-manager detection keys off bun.lockb, while
this repo uses the newer text-format bun.lock — relying on detection would
have silently fallen back to npm.
Security headers are mirrored into netlify.toml AND public/_headers, byte for
byte identical to vercel.json (verified programmatically). Netlify's docs do
not state which source wins when both define a header, so keeping them in
agreement means precedence cannot matter. Collapse to one once verified live.
COOP: same-origin + COEP: require-corp are load-bearing, not hygiene:
ffmpeg.worker.ts branches on self.crossOriginIsolated and loads the
multi-threaded core only when it is true. Verified by serving the real out/
directory with the real headers: crossOriginIsolated = true and
SharedArrayBuffer available = true.
That same COEP setting would have broken the Netlify badge. netlify.com serves
the badge SVG with neither Cross-Origin-Resource-Policy nor CORS headers, so a
hotlinked <img> is blocked outright — confirmed with a control test that
rendered RESULT-BLOCKED. The SVG is self-hosted at
public/badges/netlify-badge-color-accent.svg instead; same-origin assets are
exempt from COEP. The link still points at netlify.com, which is what their
open source plan actually asks for.
Footer gains the badge and a Code of Conduct link; README gains both too.
── Drive-by fixes ───────────────────────────────────────────────────────────
README.md had an unresolved merge conflict committed to main (lines 44-61),
which renders literal <<<<<<< HEAD markers on GitHub. The HEAD side was empty,
so the resolution is to drop the markers. Its CI badge also pointed at
Sneha079-codes/reframe, a fork, rather than this repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NhT15Aq6XUyhZSHa2HAh57
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Contributor
👋 Thanks for your PR, @magic-peach!Welcome to Reframe — a browser-based video editor built for everyone 🎬 What happens next
Quick checklist
Useful links
Happy coding! 🎉 |
Contributor
|
github-actions
Bot
added
level:advanced
Contributor
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds Snyk vulnerability scanning and makes the site deployable on Netlify (for the Open Source plan), alongside the existing Vercel deployment.
Part 1 — Snyk
snykas a devDependency (installed with bun — this repo usesbun.lock, not npm).snykpolicy with no ignores, and a commented template showing the reason/expiry shape for future exceptionsbun run securityfor local pre-PR checks.github/workflows/snyk.ymlon push tomainand PRs,--severity-threshold=high, expecting aSNYK_TOKENsecretSeparate workflow, not a job in
main.yml— it needs a different trigger gate and a different secret, and a security finding failing "CI" would read as a broken build. It also matches how this repo already splits concerns (lint.yml,typecheck.yml,chromatic.ymleach stand alone).Two things the obvious setup would have got wrong:
Part 2 — Netlify
netlify.tomlwithpublish = "out"and an explicitbun install && bun run build. Explicit because Netlify's package-manager detection keys offbun.lockb, and this repo uses the newer text-formatbun.lock— relying on detection would have silently fallen back to npm.Headers (the load-bearing part)
All seven headers from
vercel.jsonare mirrored into bothnetlify.tomlandpublic/_headers, byte-for-byte identical (verified programmatically). Netlify's docs don't state which wins when both define a header, so keeping them in agreement means precedence can't matter.The last two are load-bearing:
ffmpeg.worker.tsbranches onself.crossOriginIsolatedand loads the multi-threaded core only when true. Verified rather than assumed — served the realout/with the real headers in headless Chrome:The COEP trap this nearly walked into
require-corpblocks cross-origin subresources that send no CORP/CORS headers — and netlify.com serves its badge SVG with neither. A hotlinked badge would have been silently blocked on the live site, i.e. exactly where the OSS plan needs it visible. Confirmed with a control test:require-corp/badges/…svg)So the SVG is vendored at
public/badges/netlify-badge-color-accent.svg. The link still points to netlify.com, which is what the plan actually asks for.Badge + Code of Conduct link added to the site footer and the README.
Drive-by fixes
README.mdhad an unresolved merge conflict committed tomain(lines 44–61) rendering literal<<<<<<< HEADmarkers on GitHub. HEAD's side was empty, so the fix is dropping the markers.Sneha079-codes/reframe— a fork — instead of this repo.Verified
bun run build,bunx tsc --noEmit,bun run lintall pass;out/_headersand the badge both land in the publish directory.🤖 Generated with Claude Code
https://claude.ai/code/session_01NhT15Aq6XUyhZSHa2HAh57