Git Product home page Git Product logo

vulnera's Introduction

vulnera

npm version license ossf scorecard github ci workflow

The vuln-era has begun! Programmatically fetch security vulnerabilities with one or many strategies. Originally designed to run and analyze Scanner dependencies it now also runs independently from an npm Manifest.

Requirements

Getting Started

This package is available in the Node Package Repository and can be easily installed with npm or yarn.

$ npm i @nodesecure/vulnera
# or
$ yarn add @nodesecure/vulnera

Usage example

import * as vulnera from "@nodesecure/vulnera";

await vulnera.setStrategy(
  vulnera.strategies.GITHUB_ADVISORY
);

const definition = await vulnera.getStrategy();
console.log(definition.strategy);

const vulnerabilities = await definition.getVulnerabilities(process.cwd(), {
  useStandardFormat: true
});
console.log(vulnerabilities);

Available strategy

The default strategy is NONE which mean no strategy at all (we execute nothing).

GitHub Advisory Sonatype - OSS Index Snyk

Those strategies are described as "string" type with the following TypeScript definition:

type Kind = "github-advisory" | "snyk" | "sonatype" | "none";

To add a strategy or better understand how the code works, please consult the following guide.

API

function setStrategy<T extends Kind>(name: T): AllStrategy[T];
function getStrategy(): AnyStrategy;

const strategies: Object.freeze({
  GITHUB_ADVISORY: "github-advisory",
  SNYK: "snyk",
  SONATYPE: "sonatype",
  NONE: "none"
});

/** Equal to strategies.NONE by default **/
const defaultStrategyName: "none";

Strategy extend from the following set of interfaces;

export interface BaseStrategy<T extends Kind> {
  /** Name of the strategy **/
  strategy: T;
  /** Method to hydrate dependency vulnerabilities fetched by the Scanner **/
  hydratePayloadDependencies: (
    dependencies: Dependencies,
    options?: HydratePayloadDepsOptions
  ) => Promise<void>;
}

export interface ExtendedStrategy<
  T extends Kind, VulnFormat
> extends BaseStrategy<T> {
  /** Method to get vulnerabilities using the current strategy **/
  getVulnerabilities: (
    path: string,
    options?: BaseStrategyOptions
  ) => Promise<(VulnFormat | StandardVulnerability)[]>;
}

export interface BaseStrategyOptions {
  /**
   * @default false
   */
  useStandardFormat?: boolean;
}

export interface HydratePayloadDepsOptions extends BaseStrategyOptions {
  /**
   * Absolute path to the location to analyze
   * (with a package.json and/or package-lock.json for NPM Audit for example)
   **/
  path?: string;
}

Where dependencies is the dependencies Map() object of the NodeSecure Scanner.

Note

the option hydrateDatabase is only useful for some of the strategy (like Node.js Security WG).

Standard vulnerability format

We provide an high level format that work for all available strategy. It can be activated with the option useStandardFormat.

export interface StandardVulnerability {
  /** Unique identifier for the vulnerability **/
  id?: string;
  /** Vulnerability origin, either Snyk, Sonatype, GitHub or NodeSWG **/
  origin: Origin;
  /** Package associated with the vulnerability **/
  package: string;
  /** Vulnerability title **/
  title: string;
  /** Vulnerability description **/
  description?: string;
  /** Vulnerability link references on origin's website **/
  url?: string;
  /** Vulnerability severity levels given the strategy **/
  severity?: Severity;
  /** Common Vulnerabilities and Exposures dictionary */
  cves?: string[];
  /**
   * Common Vulnerability Scoring System (CVSS) provides a way to capture
   * the principal characteristics of a vulnerability,
   * and produce a numerical score reflecting its severity,
   * as well as a textual representation of that score. **/
  cvssVector?: string;
  /** CVSS Score **/
  cvssScore?: number;
  /** The range of vulnerable versions provided when too many versions are vulnerables */
  vulnerableRanges: string[];
  /** The set of versions that are vulnerable **/
  vulnerableVersions: string[];
  /** The set of versions that are patched **/
  patchedVersions?: string;
  /** Overview of available patches to get rid of listed vulnerabilities **/
  patches?: Patch[];
}

Databases

Contributors โœจ

All Contributors

Thanks goes to these wonderful people (emoji key):

Gentilhomme
Gentilhomme

๐Ÿ’ป ๐Ÿ“– ๐Ÿ‘€ ๐Ÿ›ก๏ธ ๐Ÿ›
Tony Gorez
Tony Gorez

๐Ÿ’ป ๐Ÿ‘€ ๐Ÿ›
Antoine
Antoine

๐Ÿ’ป ๐Ÿ› ๐Ÿ“–
OlehSych
OlehSych

๐Ÿ’ป
Mathieu
Mathieu

๐Ÿ’ป
PierreD
PierreD

๐Ÿ’ป ๐Ÿ“–
Kouadio Fabrice Nguessan
Kouadio Fabrice Nguessan

๐Ÿ’ป ๐Ÿšง

License

MIT

vulnera's People

Contributors

allcontributors[bot] avatar antoine-coulon avatar dependabot[bot] avatar fabnguess avatar fraxken avatar halcin avatar mathieuka avatar pierredemailly avatar s-oleh avatar snyk-bot avatar step-security-bot avatar tony-go avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

vulnera's Issues

Update documentation to deprecate Node.js Security WG DB

The Node.js Ecosystem Security Database is no more maintained (it's deprecated). So there is no reason to use it anymore for a production application. We should tag as deprecated in README (and also in the strategy markdown page).

image

case VULN_MODE.SECURITY_WG:
return Object.seal(await SecurityWGStrategy(options));

Here a link to an official Node.js article that explain why: https://nodejs.medium.com/node-js-ecosystem-vulnerability-reporting-program-winding-down-591d9a8cd2c7

Provide benchmarks for each available strategy given a dataset of librairies with vulnerabilities

The main idea of @nodesecure/vuln is to expose a set of strategies to detect vulnerabilities within a given project.

In my opinion, it would be great to process some benchmarks for each strategy against a dataset of open-source libraries including well-known to rare vulnerabilities.
This would let consumers know the tradeoffs of each @nodesecure/vuln strategy given their project environment and constraints (e.g: npm strategy requires the specific package-lock.json lockfile to be present).

Now that the objective should be clear enough, we must determine three things:

  • the amount of data we must collect and then use to provide a representative dataset for each strategy
  • the criteria from which we determine that a strategy has effectively caught a given vulnerability in a library (i.e: do we take into account the vulnerability score ("medium", "high", etc) or we just say that whenever a strategy catches a vulnerability we count it)
  • the output and format of each benchmark

@fraxken suggested that we could create a /benchmark root directory

Make the API work for a given manifest path (or payload).

Vuln is originally designed to work with NodeSecure/scanner. However i would like to expand the API to allow any third-party codes to use this package.

The hydratePayloadDependencies method is very specialized for the Scanner. One of my idea is to provide a new method to allow to launch an analysis on a given manifest (package.json). We could ask for a path or even a manifest payload.

However all strategies may not work well with this (Node.js Security WG for example). But we can work step by step to provide support and find solutions for those strategies (no need to rush).

Allow npm strategy to work with pnpm

Currently, the npm strategy only works for package-lock.json and npm-shrinkwrap.json lock files.

We could actually extend that to pnpm-lock.yaml using the npm strategy using programmatically the library provided by the pnpm organization which uses the same vulnerability registry.

It would allow us to enhance the compatibility of the npm strategy (pnpm + npm would be both supported).

Finalize the implementation of the Sonatype strategy by implementing API payload and rate limits

For now, the strategy around Sonatype is not taking into account rate and payload limits imposed by the API.

  • Payload limit

When requesting multiple components, there is a payload limit of 128 components per requests). Given that a project might contains thousands of dependencies, we must provide a way to batch requests respecting taking care of that limit.

Issue:
For now, all the dependencies found from the scanner are provided in the body of the request here . This is problematic because when dealing with a lot of dependencies, there is at the moment only one http request fired with all the dependencies, whereas we should batch X requests which each containing a maximum of 128 dependencies by payload. When providing more than 128 components per request, the API responds with an error.

Goal:
Take for instance an array of package urls with 130 components (130 dependencies formatted as package urls). The goal is the create from this array chunks of size 128 and to fire an HTTP request to the API with each chunk.
In this example we would have:

  • 1 HTTP request with components from 1 to 128

  • 1 HTTP request with components from 128 to 130

  • API rate limit

Probably needs an implementation using @myunisoft/httpie.

Issue:
Nothing specific with vuln here, but the interactions with the Sonatype API should handle rate limit through the use of the @myunisoft/httpie http client. Without throttling requests, we are sure to exceed the rate limit of the API.

Goal:
Use @myunisoft/httpie to configure rate limit, there is an example here

Implement standalone database API

The goal of the task is to implement standalone database API like the OSV one for:

  • GitHub
  • Snyk
  • Sonatype
  • NVD

The main idea behind that is to use them to refactor strategy (for example in Snyk and Sonatype we kinda do the work ourself).

I created one issue but each of the require a separated PR.

Specification of a "standard" format

One of the challenge with fetching vulnerabilities from multiple source is that we have to deal with multiple payload with different keys and values.

The ideal would be to find a standard format that would belong to NodeSecure.

We could also add a new option in the "HydratePayloadDependenciesOptions" interface.

Implement OSV format

I think we should work toward the goal of supporting multiple formats including OSV: https://ossf.github.io/osv-schema/

For the API we should probably rename useStandardFormat to useFormat. This new property take a string with possible enumeration: OSV or Standard

const vulnerabilities = await definition.getVulnerabilities(process.cwd(), {
  useFormat: "OSV"
});

Merging multiple strategies in one ?

Hello ๐Ÿ‘‹,

One of the thing to explore is to merge multiple strategies in one to maybe get a better end results ?

Any ideas are welcome.

Adding "Snyk" Strategy

The goal of the task is to add a new Strategy to fetch vulnerabilities from Snyk API.

Screenshot from one of the old code i have made:
https://twitter.com/fraxken/status/1355272169429872642/photo/1

As the screenshot demonstrate we have to make one API call by dependency (that why we need to do in the hydratePayloadDependencies of the strategy).

Snyk API is not free and we need a token (i have a premium org so ask me for access).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.