Security Policy

What's in scope

This policy covers anything that ships under the @sparkgoldentech organization on GitHub, npm, the VS Code Marketplace, and Open VSX:

• The traceless-style npm package — runtime helpers, the CLI, and the bundler integrations (webpack, Vite, Rollup, esbuild).
• The VS Code extension (sparkgoldentech.traceless-style-vscode).
• The browser DevTools extension for Chrome / Edge / Firefox.
• The traceless-style.dev documentation site.

What we want to hear about

Anything that lets an attacker do something they shouldn't. Some concrete examples relevant to a build-time CSS library and its ecosystem:

• CSS-injection bypass — a value that survives the build-time injection guards (;, }, <, >, */, control characters) and ends up emitting unintended rules into the consumer's stylesheet.
• Property-allowlist escape — a way to register an unsafe CSS property (e.g., something that loads an external resource) by tricking the property validator.
• Path-traversal in the CLI — if traceless-style extract can be tricked into reading or writing outside the project directory.
• Arbitrary code execution — including via the AST parser, the SWC integration, or any plugin that processes tokens / themes / keyframes.
• Supply-chain risks — if you suspect any published package has been tampered with, or you find a typo- squatted package masquerading as ours, email us immediately.
• Extension permission abuse — any way the VS Code or DevTools extension reads, writes, or transmits data beyond what its declared scope allows.

What's not in scope

We genuinely appreciate diligent reporters, but the following are not vulnerabilities for our purposes — please don't spend your time on them:

• Missing X-Frame-Options, Content-Security-Policy, or related headers on the docs site — we layer security via Cloudflare; specific header values are tuned there.
• Reports based on outdated dependency versions if a fixed version exists in our latest release.
• Theoretical timing attacks against constant-time-irrelevant code paths (we don't process secrets).
• Self-XSS, social-engineering scenarios, or attacks that require the attacker to already control the user's machine.
• Cosmetic issues, broken links, typos — please open a normal GitHub issue or PR for those.

How to report

Two channels, in order of preference:

1. GitHub Security Advisories. Open a private advisory on the main repository. This gives us a structured workflow for tracking the issue, drafting a fix, and crediting you in the published advisory.
2. Email. If you can't use GitHub Advisories or would rather email, [email protected] with Security advisory in the subject line so it's routed correctly. Include reproduction steps, affected versions, and the worst-case impact you can demonstrate.

Either way: please give us a reasonable window to fix the issue before public disclosure (typically 90 days from initial report; we'll negotiate a shorter or longer window depending on severity and ease of fix).

What you can expect from us

• Initial response within 72 hours. Usually much faster — we monitor both channels actively.
• Triage within 7 days. We'll tell you whether we're treating it as a vulnerability, what severity we're assigning, and a target patch date.
• Patch within 14 days for critical / high severity, longer for medium / low. We publish the fix as a patch release on npm and a coordinated GitHub Security Advisory.
• Credit in the advisory — with your name, handle, and (if you want) a link to your site. If you'd rather stay anonymous, just say so.

Bug bounty

We don't currently run a paid bounty program. We will publicly thank you in the advisory and the release notes, and we're happy to write a recommendation on LinkedIn or wherever you'd find it useful.

Hall of fame

Reporters who've helped harden traceless-style (none yet — the project is brand new). When the first one arrives, we'll list them here.

PGP / encryption

We don't currently publish a PGP key. If you need encrypted correspondence for a particularly sensitive report, mention it in your initial email and we'll set up a key exchange before you send the details.

Contact

Security reports: GitHub Security Advisories first; otherwise [email protected] with Security advisory in the subject. Everything else: all the ways to reach us.