Sandworm
HomepageGitHub
  • Sandworm Audit
    • Getting Started
    • How It Works
    • Configuration
    • Issue Types
    • Resolved Issues
    • License Policies
    • Fail Policies
    • Custom Registries
    • Chart Info
  • Sandworm Guard
    • Overview
    • Getting Started
    • Supported Methods
    • Enforcing Permissions
    • Describing Permissions
    • Caller Module Paths
    • Configuration
    • Bundlers & Sourcemaps
  • Snapshot Testing
  • Contributing
    • Code of Conduct
    • Security Policy
Powered by GitBook
On this page
  • Summary
  • The permission database project
  • How Sandworm is tested

Was this helpful?

Edit on GitHub

Sandworm Guard

Easy auditing & sandboxing for your JavaScript dependencies 🪱

PreviousChart InfoNextOverview

Last updated 2 years ago

Was this helpful?

Summary

  • Sandworm Guard intercepts all potentially harmful Node & browser APIs, like arbitrary code execution (child_process.exec) or network calls (fetch). It knows what packages are responsible for each call.

  • Simple obfuscation techniques can confuse static analysis tools, but Sandworm's dynamic analysis will always intercept risky calls at run time.

  • You can use Sandworm Guard to:

    • audit your dependencies, monitor activity and permissions, and see what your code is doing under the hood using the Inspector;

    • generate a security profile automatically from your test suite and do snapshot testing against it;

    • secure your app against supply chain attacks by enforcing per-module permissions.

  • Install it as an npm module in your existing Node or browser app.

  • Works in Node v15+ and . Beta support for browsers and sourcemaps.

Get involved

  • Have a support question? .

  • Have a feature request? .

  • Did you find a security issue? .

  • Did you find a bug? .

  • Want to write some code? See .

The permission database project

A longer-term goal for Sandworm is to provide an open, public database of per-package permission requirements, based on:

  • running automated tests with Sandworm enabled for public packages;

  • anonymous info about requirements collected from real-world apps by the inspector.

For every method call that Sandworm intercepts, the inspector will share the following info:

{
  "module": "CALLER_MODULE_NAME",
  "family": "INVOKED_METHOD_FAMILY",
  "method": "INVOKED_METHOD_NAME",
  "sessionId": "INSPECTOR_SESSION_ID"
}

How Sandworm is tested

Sandworm has several layers of automated testing:

  • Jest is used to run Node.js capture & enforce tests for all supported Node APIs (tests run on Node 16.10 and above). See the tests/node directory.

  • Playwright is used to run browser capture & enforce tests for all supported browser APIs (tests run on WebKit, Chromium, and Firefox). See the tests/web directory.

  • Jest is used to run unit tests on the core Sandworm source files. See the tests/unit directory.

This will make it easier for everyone to audit packages and set up Sandworm. To opt out of sharing data with the community, run the inspector with the --no-telemetry option. You can also audit and the .

Check out our latest test run inside our .

what's getting sent
server code
CircleCI pipeline
modern browsers
Post it here
Post it here
See SECURITY.md
Post an issue
CONTRIBUTING.md
CircleCI
License
npm
Maintainability
Test Coverage