DEV Community: Gabi Dobocan

The Better Npm Audit 🪱

Gabi Dobocan — Tue, 21 Mar 2023 12:20:57 +0000

It's been almost two years since Dan Abramov wrote his controversial article on how npm audit is broken by design:

It makes experienced app developers miserable because they have to either waste time doing obviously unnecessary work, or fight with their security departments trying to explain how npm audit is a broken tool unsuitable for real security audits by design.
Two years - yet not much has changed when it comes to the number of false positives you get from npm audit - false positives that have made JavaScript developers learn to ignore all security warnings in the console when installing new packages. Ironically, making poor audit results part of the default output when installing packages has had a reverse effect, by effectively training developers to ignore security warnings they can't easily understand or address.

It's hard to enforce security rules

So let's say you're not that guy. You care about security and see the threat in blindly relying on hundreds - often thousands - of packages with 3rd party code. You don't currently have the budget for the better-known services out there, but you still want to build security into the core of your application and your workflows as much as possible.

So you add npm audit --audit-level=high to your CI pipeline to enforce "no builds and/or deploys when there are high or critical vulnerabilities". Then you install some dependencies, write some code, and push an update. The build fails because d3-color<3.1.0 is vulnerable to ReDoS. It's high severity so you have a look, and it turns out you're not using any of the options that can allow malicious input to make some RegExp explode. Great, there's nothing to address here! But what about fixing the build now? 🤔

Not all issues are resolved with code

Ok, so maybe you remove the audit step from the CI for now but start using Dependabot. It surfaces the same vulnerabilities that your package manager would, directly from GitHub's Advisory Database. It makes PRs with fixes, when available, and you can dismiss alerts that don't apply by selecting one of a few possible reasons:

You quickly realize, though, that npm audit will still display issues you've dismissed with Dependabot. Devs in your team installing new dependencies will still be ignoring the console warnings, and will probably not realize they're bringing in new vulnerabilities until the next Dependabot scan.

The summary of the security research you're doing with validating all issues before dismissing them is now hopefully stored in a separate documentation repository that people in your team can access - because if it's not, people in the future won't know how or why a specific issue has been dismissed as "risk is tolerable". How has the risk been assessed, and what does "tolerable" mean? That knowledge might be siloed.

Also, anyone who depends on your code is now seeing the same new vulnerability reports from Dependabot that you are getting. Every one of your users who cares about security is now re-doing your research, looking at your code and how you interact with the vulnerable library, before hopefully choosing to dismiss the issue from their repository. Some might just switch to a different library along the way. There's no way to inform the people that care about your security findings & resolutions.

And yeah, those automated fixes aren't always great... 😅

Not all issues are security advisories

Ok, you're now ready to raise some money and take your app to the next level! As part of the due diligence process, the lawyers ask you for a list of all your dependencies, including license info for each. This is when you realize you should have been paying attention to licenses all along. You scramble to figure out what SPDX and OSI are. You think your backend repositories are mostly safe since you don't distribute that code, but then you find out about Network Protective licenses.

A tool to automate and enforce license compliance for your entire team would be nice!

At this point, you've maybe found IBM's audit-ci, which can help with allowlisting advisory IDs, but doesn't audit for any other types of issues except reported security vulnerabilities (same for better-npm-audit, or npm-audit-resolver);
license-checker is pretty popular, but only scans licenses and is not maintained anymore;
ort scans for both vulnerabilities & licenses, but it's heavy and intimidating (Kotlin knowledge required), and doesn't include a way to dismiss alerts.

Meanwhile, you're stuck explaining to everyone on your team about this new license compliance thing they need to look out for.

Plus, have you recently tried getting npm to tell you which of your dependencies is deprecated? It only gives off warnings about that when you install new packages and you probably ignore it then. But you should care about deprecations too, right?

Enter Sandworm 🪱

sandworm-hq / sandworm-audit

Security & License Compliance For Your App's Dependencies 🪱

Beautiful Security & License Compliance Reports For Your App's Dependencies 🪱

Summary

Free & open source command-line tool
Works with any modern JavaScript package manager
Scans your project & dependencies for vulnerabilities, license, and misc issues
Supports marking issues as resolved
Supports custom license policies
Configurable fail conditions for CI / GIT hook workflows
Outputs
- JSON issue & license usage reports
- Easy to grok SVG dependency tree & treemap visualizations
  - Powered by D3
  - Overlays security vulnerabilities
  - Overlays package license info
- CSV of all dependencies & license info

Generate a report

Navigate charts

CSV output

JSON output

{
  "createdAt": "..."
  "packageManager": "...",
  "name": "...",
  "version": "...",
  "rootVulnerabilities": [...],
  "dependencyVulnerabilities": [...],
  "licenseUsage": {...},
  "licenseIssues": [...],
  "metaIssues": [...],
  "errors": [...],

…

View on GitHub

Sandworm Audit is a command-line tool designed to help with all of your auditing woes:

It's free & open source!
It lets you customize and own your security workflow
It works with any modern JavaScript package manager
It scans your project & dependencies for vulnerabilities, license, and misc issues
It supports marking issues as resolved
It supports custom license policies
It has configurable fail conditions for running in CI / GIT hooks
Product of the day on Product Hunt!

Running a Sandworm audit will generate:

A JSON report with all issue & license usage information;
Easy to grok SVG dependency tree & treemap visualizations;
A CSV list of all project dependencies & license info.

Build security & compliance into your app's core, today

With Sandworm, you're now able to take ownership of your security workflow, just like you always wanted:

You add Sandworm to your CI to enforce security rules. You make a configuration file that you commit to your repo, and define a custom fail policy within it.
You also add a permitted license policy to the configuration file, specifying which licenses are ok and which should trigger issues that need to be investigated. Everyone in the team sees what the rules are - you're all on the same page.
You create a resolved-issues.json file in your repo, and tell your team to use sandworm resolve to dismiss issues that are not addressable by writing code. All resolutions are recorded in the JSON file and your git history, allowing anyone to historically track who resolved what, when, and why.
Updates to the resolution file fit right into your existing code PR approval workflow.
You share your resolution file with your users, to inform them of the issues you've investigated, and what they need to look out for.

Try out Sandworm

We're a small team of long-time techies. The story in this article is our story, over the past five years, handling engineering for several JavaScript-powered startups, where we just wanted to get security right. We made Sandworm with ❤️ and ☕, in the hope that it will change all dev's minds about the importance of security practices, by providing them with the tools they always needed.

You can try out Sandworm in your app by running npx @sandworm/audit@latest, or by installing it globally with npm i -g @sandworm/audit and then running sandworm audit in your app's directory.

More about how Sandworm works in the documentation. Questions, ideas, or feedback? Let me know in the comments! 👇 And if you like Sandworm, please star it on GitHub below to let us know you care about security:

sandworm-hq / sandworm-audit

Security & License Compliance For Your App's Dependencies 🪱

Beautiful Security & License Compliance Reports For Your App's Dependencies 🪱

Summary

Free & open source command-line tool
Works with any modern JavaScript package manager
Scans your project & dependencies for vulnerabilities, license, and misc issues
Supports marking issues as resolved
Supports custom license policies
Configurable fail conditions for CI / GIT hook workflows
Outputs
- JSON issue & license usage reports
- Easy to grok SVG dependency tree & treemap visualizations
  - Powered by D3
  - Overlays security vulnerabilities
  - Overlays package license info
- CSV of all dependencies & license info

Generate a report

Navigate charts

CSV output

JSON output

{
  "createdAt": "..."
  "packageManager": "...",
  "name": "...",
  "version": "...",
  "rootVulnerabilities": [...],
  "dependencyVulnerabilities": [...],
  "licenseUsage": {...},
  "licenseIssues": [...],
  "metaIssues": [...],
  "errors": [...],

…

View on GitHub

Running Eleventy Serverless On AWS Lambda@Edge

Gabi Dobocan — Fri, 03 Mar 2023 16:04:26 +0000

Eleventy is great. It’s a static site generator written in JavaScript, for “Fast Builds and even Faster Web Sites.” It’s 10 to 20 times faster than the alternatives, like Gatsby or Next.js. You get all of your content statically rendered and ready to be CDN-delivered. You needn’t worry about server-side rendering to get those pretty social share unfurls. And, if you have a large data set, that’s great — Eleventy can generate tens of thousands of pages with no issues.

But what if you have a HUGE data set?

When building Sandworm’s open-source security & license compliance audits for JavaScript packages, we wanted to generate a catalog of beautiful report visualizations for every library in the npm registry. That is, for every version of every library in the registry. We soon found out — that’s more than 30 million package versions. Good luck generating, uploading, and keeping that amount of HTML pages up to date in a decent amount of time, right?

We looked at reducing our data set to just the most popular packages. We looked at implementing partial builds, where stale report pages would get continuously generated and uploaded.

But the solution we ended up implementing was Eleventy Serverless, a plugin that runs one or more template files at request time to generate dynamic pages. So instead of going through the entire set of pages at build time, this plugin allows us to separate “regular” content pages rendered at build from “dynamic” pages rendered on demand. We can then simply generate and upload static content (like the homepage, about page, etc.) in the CI, and then deploy some code to a compute provider that will generate an npm package page when a user navigates to a specific URL. Great!

Except: Eleventy Serverless is built to work out-of-the-box with Netlify Functions, and we’re running on AWS.

The good news is that you can get Eleventy Serverless to run in AWS Lambdas. Even better, you can get it to run in Lambda@Edge, which runs your code globally at AWS locations close to your users so that you can deliver full-featured, customized content with high performance and low latency.

gabidobo / 11ty-lambda-edge-demo

A simple tutorial for running Eleventy Serverless on AWS Lambda@Edge

Running Eleventy Serverless On AWS Lambda@Edge

The good news is that you can get Eleventy Serverless to run in AWS Lambdas. Even better, you can get it to run in Lambda@Edge, which runs your code globally at AWS locations close to your users so that you can deliver full-featured, customized content with high performance and low latency.

Read the full tutorial here: https://medium.com/sandworm/running-eleventy-serverless-on-aws-lambda-edge-5010b9571c5f

View on GitHub

Setting up Eleventy

First things first: let’s get Eleventy running the local build. We start by installing it:

npm i @11ty/eleventy --dev

Then, let’s create the simplest template for our static Eleventy page. We’ll write it using Liquid, but since it’s so simple, it won’t take advantage of any useful templating tags for now. Let’s call it index.liquid:

<h1>Hello</h1>

That’s it, we’re ready to build and serve! Run:

npx @11ty/eleventy --serve

[11ty] Writing _site/index.html from ./src/index.liquid
[11ty] Serverless: 3 files bundled to ./serverless/edge.
[11ty] Wrote 1 file in 0.12 seconds (v2.0.0)
[11ty] Watching…
[11ty] Server at http://localhost:8080/

Visit http://localhost:8080/ in your browser at this point, and you should see the “Hello” heading we’ve created above. Neat!

Setting up the Eleventy Serverless plugin

The Serverless plugin is bundled with Eleventy and doesn’t require you to npm install anything. We do need to configure it, though. To do that, we need to create an Eleventy config file:

// .eleventy.js
const { EleventyServerlessBundlerPlugin } = require("@11ty/eleventy");

module.exports = function(eleventyConfig) {
  eleventyConfig.addPlugin(EleventyServerlessBundlerPlugin, {
    name: "edge",
    functionsDir: "./serverless/",
    redirects: false,
  });

  return {
    dir: {
      input: 'src',
    },
  };
};

Let’s break the plugin configuration down:

Each plugin’s unique name will determine the build output directory name and will be required when assigning permalinks. You can also instantiate multiple plugins to have different functions handle different pages.
The functionsDir allows you to specify the path to the build output dir; in our case, the plugin will generate files in the ./serverless/edge directory relative to the app root.
redirects configures how Netlify redirects should be handled — since we’re not running on Netlify, we set this to false to skip generating a netlify.toml file.
Lastly, in the configuration object we return to Eleventy, we specify an input dir for our content to keep things tidy. We’ll also go ahead and move the index.liquid file we created earlier in the src directory.

Next, let's build again by running npx @11ty/eleventy, and investigate what gets output under ./serverless/edge. You should see the following:

A number of js and json files starting with eleventy-. Some are configuration files, and some are built to inform the Netlify bundler of function dependencies — we won’t need those for Lambda.
eleventy.config.js, a copy of the main configuration file in the app root.
The src directory with the index.liquid template.
An index.js file with the actual serverless handler code that we’ll update and deploy to Lambda.

Let’s gitignore the build artifacts that we don’t want in our repo and only keep the index.js file for now. Add this to your .gitignore file:

serverless/edge/**
!serverless/edge/index.js

Good, we’re now ready to create our first dynamically generated page. Let’s make another simple Liquid file for it under src/edge.liquid:

---
permalink:
  edge: /hello/
---
<h1>Hello@Edge</h1>

You’ll notice that for this file, we’ve added some front matter data to the liquid template. Specifically, we’ve defined a permalink for our page to respond to when running under the edge plugin. Eleventy won’t generate an edge.html page when building — this page will only be generated by invoking the serverless handler code.

Making things Lambda-compatible

Let’s now look at what’s going on with serverless/edge/index.js. This is only generated with the initial build, so we’re free to modify it — and we’ll definitely need to in order to support Lambda@Edge.

First, we can remove the require("./eleventy-bundler-modules.js"), as that’s only needed for the Netlify bundle process;
Next, we’ll need to get a reference to the current request path and query, as Eleventy needs that info to know what content to generate. With Netlify, you get these via event.rawUrl, event.multiValueQueryString, and event.queryStringParameters. With Lambda@Edge, we’ll be getting events generated by CloudFront on origin requests — see an example in the AWS docs. We’ll also use querystring to handle parsing the query string. Let’s update the code to this:

const { request } = event.Records[0].cf;
const path = `${request.uri}${request.uri.endsWith("/") ? "" : "/"}`;
const query = querystring.parse(request.querystring);

let elev = new EleventyServerless("edge", {
  path,
  query,
  functionsDir: "./",
});

Finally, we need to update the handler’s returned objects to match the format expected by Lambda@Edge. Update the success & error responses status and headers to:

{
  status: "200",
  headers: {
    "cache-control": [
      {
        key: "Cache-Control",
        value: "max-age=0",
      },
    ],
    "content-type": [
      {
        key: "Content-Type",
        value: "text/html; charset=UTF-8",
      },
    ],
  },
  body: ...
}

We’ve also added a Cache-Control header to configure how CloudFront caches the returned results. We can get more thoughtful about this when moving to production, but for now, we’ll go with no caching.

One last thing: we’ll want to separate build dependencies from edge handling dependencies, so let’s create a separate package.json file in serverless/edge, and install @11ty/edge as a prod dependency. As our edge function grows, we’ll add more things here, like database clients.

And as you add more dependencies, it’s time to also build security and compliance into your app early. Sandworm Audit is the open-source npm audit that doesn’t suck: it checks for multiple types of issues, like vulnerabilities or license compliance, it outputs SVG charts and CSVs, and you can also run it in your CI to enforce security rules. Check the docs and npx @sandworm/audit in your JavaScript app’s root to try it out 🪱.

Here’s our full handler code, for reference:

Testing it out locally

Good, let’s test this out locally before we deploy! It should be pretty easy to simulate sending an event to our handler function. Let’s create a simple test.js file:

const { handler } = require('.');

(async () => {
  const response = await handler({Records: [{cf: {request: {uri: "/hello/", querystring: ""}}}]});

  console.log(response);
})();

Running node test.js in the console, you should see:

{
  status: '200',
  headers: { 'cache-control': [ [Object] ], 'content-type': [ [Object] ] },
  body: '<h1>Hello</h1>'
}

Take a moment to celebrate! You’ve just triggered your first Eleventy build in a serverless function. 🎊

Deploying to AWS

Things look good — it’s now time to deploy this to AWS. To handle the deployment, we’ll be using Serverless. No, not the Eleventy Serverless plugin, but Serverless, the “zero-friction development tooling for auto-scaling apps on AWS Lambda” command-line tool. If you don’t have it installed, run npm install -g serverless. Then create a serverless/edge/serverless.yml file to configure the deploy:

This will instantiate a CloudFront distribution connected to the bucket you specified under events>cloudfront>origin. Any calls to URLs matching the pathPattern will be forwarded to the serverless handler instead of being routed to the bucket.
Fun fact: Lambda@Edge functions log console output to their regional CloudWatch. That is, if a user in Germany accesses your pages via the edge at eu-frankfurt-1, you’ll see logs for that specific run under the eu-frankfurt-1 region and nowhere else. In the yml config, we make sure to give our function proper permissions to write log groups anywhere.
We should also add an exception for the config file to .gitignore — we want this in the repo.
If you already have a CloudFront distribution that you want to connect to your new serverless function, check out the serverless-lambda-edge-pre-existing-cloudfront plugin.

We’re ready to deploy! Make sure you export AWS credentials for an IAM user with proper permissions for deploying the entire stack. When moving to production, for security purposes, you should create a dedicated user with the minimal set of permissions required — however, I haven’t been able to find a comprehensive list of such permissions, so this will likely be a tedious trial-and-error process of figuring them out by trying deploys and seeing what fails. While still in development, an admin user might be easier to use.

Run sls deploy --stage prod to deploy. If all goes well, in a couple of minutes, you should see the URL to your new CloudFront distribution! Your settings will need to propagate globally though, so it might take a few more minutes for everything to be ready. You can check the current status of your distribution under the AWS console dashboard. Once it’s done deploying, navigating to CF_URL/hello in a browser should display our “Hello@Edge” html header from the edge.liquid template. We did it! 🙌

Bonus: making it dynamic

Now let’s quickly make our serverless function actually do something async. Let’s have it accept a URL parameter that’s the name of a Pokémon, and respond with an image of said cute beast. We’ll use https://pokeapi.co/ to get the image.

We could do the async work outside of eleventy, and then inject some global data like this:

const eleventy = new EleventyServerless('serverless', {
  path,
  query,
  functionsDir: './',
  config: (config) => {
    config.addGlobalData('data', yourData);
  },
});

Or, better yet, starting with Eleventy 2.0.0, we can use async filters. Let’s first update our edge.liquid template to include the new HTML we want:

---
permalink:
  edge:
    - /hello/
    - /hello/:name/
---
<h1>Hello@Edge \{\{ eleventy.serverless.path.name }}</h1>
{% if eleventy.serverless.path.name %}
  <img src="\{\{ eleventy.serverless.path.name | escape | pokeimage }}" />
{% endif %}

We’ve added a new permalink that includes a name path parameter. That will become available in the data cascade as eleventy.serverless.path.name.
We’re transforming this name param via two filters: escape and pokeimage. Remember, user input should be treated as potentially malicious 😉.
We need to define our pokeimage filter. This is where the async magic happens. Add this to your .eleventy.js file:

eleventyConfig.addAsyncFilter("pokeimage", async function(name) {
  const results = await fetch(`https://pokeapi.co/api/v2/pokemon/${name}`);
  const json = await results.json();

  return json.sprites.front_default;
});

We’re relying on node’s built-in fetch API here — it’s a good thing we’ve set runtime: nodejs18.x in our serverless.yml file.

Let’s update our test.js file to query the /hello/ditto/ URL, and run node test.js again. In the console output, you should now see:

{
  status: '200',
  headers: { 'cache-control': [ [Object] ], 'content-type': [ [Object] ] },
  body: '<h1>Hello@Edge ditto</h1>\n' +
    '\n' +
    '  <img src="https://raw.githubusercontent.com/PokeAPI/sprites/master/sprites/pokemon/132.png" />\n'
}

One last sls deploy --stage prod to get this deployed, and done! You’ve mastered setting up Eleventy Serverless on Lambda@Edge.

All of Sandworm’s npm package report pages are generated using Eleventy Serverless and Lambda@Edge. Sandworm is about JavaScript security and compliance.

Audit your dependencies and licenses using Sandworm Audit.
Sandbox dependencies and monitor your running app using Sandworm Guard.