A vulnerability scanner for container images and filesystems

Overview

Static Analysis + Unit + Integration Acceptance Go Report Card GitHub release GitHub go.mod Go version License: Apache-2.0 Slack Invite

A vulnerability scanner for container images and filesystems. Easily install the binary to try it out. Works with Syft, the powerful SBOM (software bill of materials) tool for container images and filesystems.

grype-demo

Features

  • Scan the contents of a container image or filesystem to find known vulnerabilities.
  • Find vulnerabilities for major operating system packages:
    • Alpine
    • Amazon Linux
    • BusyBox
    • CentOS
    • Debian
    • Distroless
    • Oracle Linux
    • Red Hat (RHEL)
    • Ubuntu
  • Find vulnerabilities for language-specific packages:
    • Ruby (Gems)
    • Java (JAR, WAR, EAR, JPI, HPI)
    • JavaScript (NPM, Yarn)
    • Python (Egg, Wheel, Poetry, requirements.txt/setup.py files)
  • Supports Docker and OCI image formats

If you encounter an issue, please let us know using the issue tracker.

Installation

Recommended

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

...or, you can specify a release version and destination directory for the installation:

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b 
    
    

    
   

Homebrew

brew tap anchore/grype
brew install grype

Note: Currently, Grype is built only for macOS and Linux.

Getting started

Install the binary, and make sure that grype is available in your path. To scan for vulnerabilities in an image:

grype 

The above command scans for vulnerabilities that are visible in the container (i.e., the squashed representation of the image). To include software from all image layers in the vulnerability scan, regardless of its presence in the final image, provide --scope all-layers:

grype  --scope all-layers

Supported sources

Grype can scan a variety of sources beyond those found in Docker.

# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)
grype path/to/image.tar

# scan a directory
grype dir:path/to/dir

Use Syft SBOMs for even faster vulnerability scanning in Grype:

# Just need to generate the SBOM once
syft  -o json > ./image-sbom.json

# Then scan for new vulnerabilities as frequently as needed
grype sbom:./image-sbom.json

# (You can also pipe the SBOM into Grype)
cat ./image-sbom.json | grype

Sources can be explicitly provided with a scheme:

docker:yourrepo/yourimage:tag          use images from the Docker daemon
docker-archive:path/to/yourimage.tar   use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar      use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage              read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
dir:path/to/yourproject                read directly from a path on disk (any directory)
registry:yourrepo/yourimage:tag        pull image directly from a registry (no container runtime required)

Output formats

The output format for Grype is configurable as well:

grype  -o 
   

   

Where the formats available are:

  • table: A columnar summary (default).
  • cyclonedx: An XML report conforming to the CycloneDX 1.2 specification.
  • json: Use this to get as much information out of Grype as possible!
  • template: Lets the user specify the output format. See "Using templates" below.

Using templates

Grype lets you define custom output formats, using Go templates. Here's how it works:

  • Define your format as a Go template, and save this template as a file.

  • Set the output format to "template" (-o template).

  • Specify the path to the template file (-t ./path/to/custom.template).

  • Grype's template processing uses the same data models as the json output format — so if you're wondering what data is available as you author a template, you can use the output from grype -o json as a reference.

Example: You could make Grype output data in CSV format by writing a Go template that renders CSV data and then running grype -o ~/path/to/csv.tmpl.

Here's what the csv.tmpl file might look like:

"Package","Version Installed","Vulnerability ID","Severity"
{{- range .Matches}}
"{{.Artifact.Name}}","{{.Artifact.Version}}","{{.Vulnerability.ID}}","{{.Vulnerability.Severity}}"
{{- end}}

Which would produce output like:

"Package","Version Installed","Vulnerability ID","Severity"
"coreutils","8.30-3ubuntu2","CVE-2016-2781","Low"
"libc-bin","2.31-0ubuntu9","CVE-2016-10228","Negligible"
"libc-bin","2.31-0ubuntu9","CVE-2020-6096","Low"
...

Gating on severity of vulnerabilities

You can have Grype exit with an error if any vulnerabilities are reported at or above the specified severity level. This comes in handy when using Grype within a script or CI pipeline. To do this, use the --fail-on CLI flag.

For example, here's how you could trigger a CI pipeline failure if any vulnerabilities are found in the ubuntu:latest image with a severity of "medium" or higher:

grype ubuntu:latest --fail-on medium

Specifying matches to ignore

If you're seeing Grype report false positives or any other vulnerability matches that you just don't want to see, you can tell Grype to ignore matches by specifying one or more "ignore rules" in your Grype configuration file (e.g. ~/.grype.yaml). This causes Grype not to report any vulnerability matches that meet the criteria specified by any of your ignore rules.

Each rule can specify any combination of the following criteria:

  • vulnerability ID (e.g. "CVE-2008-4318")
  • fix state (allowed values: "fixed", "not-fixed", "wont-fix", or "unknown")
  • package name (e.g. "libcurl")
  • package version (e.g. "1.5.1")
  • package type (e.g. "npm"; these values are defined here)
  • package location (e.g. "/usr/local/lib/node_modules/**"; supports glob patterns)

Here's an example ~/.grype.yaml that demonstrates the expected format for ignore rules:

ignore:
  
  # This is the full set of supported rule fields:
  - vulnerability: CVE-2008-4318
    fix-state: unknown
    package:
      name: libcurl
      version: 1.5.1
      type: npm
      location: "/usr/local/lib/node_modules/**"

  # We can make rules to match just by vulnerability ID:
  - vulnerability: CVE-2017-41432
  
  # ...or just by a single package field:
  - package:
      type: gem

Vulnerability matches will be ignored if any rules apply to the match. A rule is considered to apply to a given vulnerability match only if all fields specified in the rule apply to the vulnerability match.

When you run Grype while specifying ignore rules, the following happens to the vulnerability matches that are "ignored":

  • Ignored matches are completely hidden from Grype's output, except for when using the json or template output formats; however, in these two formats, the ignored matches are removed from the existing matches array field, and they are placed in a new ignoredMatches array field. Each listed ignored match also has an additional field, appliedIgnoreRules, which is an array of any rules that caused Grype to ignore this vulnerability match.

  • Ignored matches do not factor into Grype's exit status decision when using --fail-on . For instance, if a user specifies --fail-on critical, and all of the vulnerability matches found with a "critical" severity have been ignored, Grype will exit zero.

Note: Please continue to report any false positives you see! Even if you can reliably filter out false positives using ignore rules, it's very helpful to the Grype community if we have as much knowledge about Grype's false positives as possible. This helps us continuously improve Grype!

Showing only "fixed" vulnerabilities

If you only want Grype to report vulnerabilities that have a confirmed fix, you can use the --only-fixed flag. (This automatically adds ignore rules into Grype's configuration, such that vulnerabilities that aren't fixed will be ignored.)

For example, here's a scan of Alpine 3.10:

NAME          INSTALLED  FIXED-IN   VULNERABILITY   SEVERITY
apk-tools     2.10.6-r0  2.10.7-r0  CVE-2021-36159  Critical
libcrypto1.1  1.1.1k-r0             CVE-2021-3711   Critical
libcrypto1.1  1.1.1k-r0             CVE-2021-3712   High
libssl1.1     1.1.1k-r0             CVE-2021-3712   High
libssl1.1     1.1.1k-r0             CVE-2021-3711   Critical

...and here's the same scan, but adding the flag --only-fixed:

NAME       INSTALLED  FIXED-IN   VULNERABILITY   SEVERITY
apk-tools  2.10.6-r0  2.10.7-r0  CVE-2021-36159  Critical

Grype's database

When Grype performs a scan for vulnerabilities, it does so using a vulnerability database that's stored on your local filesystem.

By default, Grype automatically manages this database for you. Grype checks for new updates to the vulnerability database to make sure that every scan uses up-to-date vulnerability information. This behavior is configurable. For more information, see the Managing Grype's database section.

How database updates work

Grype's vulnerability database is a SQLite file, named vulnerability.db. Updates to the database are atomic: the entire database is replaced and then treated as "readonly" by Grype.

Grype's first step in a database update is discovering databases that are available for retrieval. Grype does this by requesting a "listing file" from a public endpoint:

https://toolbox-data.anchore.io/grype/databases/listing.json

The listing file contains entries for every database that's available for download.

Here's an example of an entry in the listing file:

{
  "built": "2021-10-21T08:13:41Z",
  "version": 3,
  "url": "https://toolbox-data.anchore.io/grype/databases/vulnerability-db_v3_2021-10-21T08:13:41Z.tar.gz",
  "checksum": "sha256:8c99fb4e516f10b304f026267c2a73a474e2df878a59bf688cfb0f094bfe7a91"
}

With this information, Grype can select the correct database (the most recently built database with the current schema version), download the database, and verify the database's integrity using the listed checksum value.

Managing Grype's database

Note: During normal usage, there is no need for users to manage Grype's database! Grype manages its database behind the scenes. However, for users that need more control, Grype provides options to manage the database more explicitly.

Local database cache directory

By default, the database is cached on the local filesystem in the directory $XDG_CACHE_HOME/grype/db/ / . For example, on macOS, the database would be stored in ~/Library/Caches/grype/db/3/. (For more information on XDG paths, refer to the XDG Base Directory Specification.)

You can set the cache directory path using the environment variable GRYPE_DB_CACHE_DIR.

Offline and air-gapped environments

By default, Grype checks for a new database on every run, by making a network call over the Internet. You can tell Grype not to perform this check by setting the environment variable GRYPE_DB_AUTO_UPDATE to false.

As long as you place Grype's vulnerability.db and metadata.json files in the cache directory for the expected schema version, Grype has no need to access the network.

CLI commands for database management

Grype provides database-specific CLI commands for users that want to control the database from the command line. Here are some of the useful commands provided:

grype db status — report the current status of Grype's database (such as its location, build date, and checksum)

grype db check — see if updates are available for the database

grype db update — ensure the latest database has been downloaded to the cache directory (Grype performs this operation at the beginnign of every scan by default)

Find complete information on Grype's database commands by running grype db --help.

Shell completion

Grype supplies shell completion through its CLI implementation (cobra). Generate the completion code for your shell by running one of the following commands:

  • grype completion
  • go run main.go completion

This will output a shell script to STDOUT, which can then be used as a completion script for Grype. Running one of the above commands with the -h or --help flags will provide instructions on how to do that for your chosen shell.

Private Registry Authentication

Local Docker Credentials

When a container runtime is not present, grype can still utilize credentials configured in common credential sources (such as ~/.docker/config.json). It will pull images from private registries using these credentials. The config file is where your credentials are stored when authenticating with private registries via some command like docker login. For more information see the go-containerregistry documentation.

An example config.json looks something like this:

// config.json
{
	"auths": {
		"registry.example.com": {
			"username": "AzureDiamond",
			"password": "hunter2"
		}
	}
}

You can run the following command as an example. It details the mount/environment configuration a container needs to access a private registry:

docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest

Docker Credentials in Kubernetes

The below section shows a simple workflow on how to mount this config file as a secret into a container on kubernetes.

  1. Create a secret. The value of config.json is important. It refers to the specification detailed here. Below this section is the secret.yaml file that the pod configuration will consume as a volume. The key config.json is important. It will end up being the name of the file when mounted into the pod.

    # secret.yaml
    
    apiVersion: v1
    kind: Secret
    metadata:
      name: registry-config
      namespace: grype 
    data:
      config.json: 
         
    
         

    kubectl apply -f secret.yaml

  2. Create your pod running grype. The env DOCKER_CONFIG is important because it advertises where to look for the credential file. In the below example, setting DOCKER_CONFIG=/config informs grype that credentials can be found at /config/config.json. This is why we used config.json as the key for our secret. When mounted into containers the secrets' key is used as the filename. The volumeMounts section mounts our secret to /config. The volumes section names our volume and leverages the secret we created in step one.

    # pod.yaml
    
    apiVersion: v1
    kind: Pod
    spec:
      containers:
        - image: anchore/grype:latest
          name: grype-private-registry-demo
          env:
            - name: DOCKER_CONFIG
              value: /config
          volumeMounts:
          - mountPath: /config
            name: registry-config
            readOnly: true
          args:
            - 
         
          
      volumes:
      - name: registry-config
        secret:
          secretName: registry-config
    
         

    kubectl apply -f pod.yaml

  3. The user can now run kubectl logs grype-private-registry-demo. The logs should show the grype analysis for the provided in the pod configuration.

Using the above information, users should be able to configure private registry access without having to do so in the grype or syft configuration files. They will also not be dependent on a docker daemon, (or some other runtime software) for registry configuration and access.

Configuration

Configuration search paths:

  • .grype.yaml
  • .grype/config.yaml
  • ~/.grype.yaml
  • /grype/config.yaml

Configuration options (example values are the default):

# enable/disable checking for application updates on startup
check-for-app-update: true

# same as --fail-on ; upon scanning, if a severity is found at or above the given severity then the return code will be 1
# default is unset which will skip this validation (options: negligible, low, medium, high, critical)
fail-on-severity: ''

# same as -o ; the output format of the vulnerability report (options: table, json, cyclonedx)
output: "table"

# same as -s ; the search space to look for packages (options: all-layers, squashed)
scope: "squashed"

# same as -q ; suppress all output (except for the vulnerability list)
quiet: false

# same as --file; write output report to a file (default is to write to stdout)
file: ""

db:
  # check for database updates on execution
  auto-update: true

  # location to write the vulnerability database cache
  cache-dir: "$XDG_CACHE_HOME/grype/db"

  # URL of the vulnerability database
  update-url: "https://toolbox-data.anchore.io/grype/databases/listing.json"

# options when pulling directly from a registry via the "registry:" scheme
registry:
  # skip TLS verification when communicating with the registry
  # GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY env var
  insecure-skip-tls-verify: false
  # use http instead of https when connecting to the registry
  # GRYPE_REGISTRY_INSECURE_USE_HTTP env var
  insecure-use-http: false

  # credentials for specific registries
  auth:
    - # the URL to the registry (e.g. "docker.io", "localhost:5000", etc.)
      # GRYPE_REGISTRY_AUTH_AUTHORITY env var
      authority: ""
      # GRYPE_REGISTRY_AUTH_USERNAME env var
      username: ""
      # GRYPE_REGISTRY_AUTH_PASSWORD env var
      password: ""
      # note: token and username/password are mutually exclusive
      # GRYPE_REGISTRY_AUTH_TOKEN env var
      token: ""
    - ... # note, more credentials can be provided via config file only


log:
  # location to write the log file (default is not to have a log file)
  file: ""

  # the log level; note: detailed logging suppress the ETUI
  level: "error"

  # use structured logging
  structured: false

Future plans

The following areas of potential development are currently being investigated:

  • Support for allowlist, package mapping
  • Accept alternative SBOM formats (CycloneDX, SPDX) as input
Comments
  • Need ability to scan images within GitLab CI/CD

    Need ability to scan images within GitLab CI/CD

    What would you like to be added:

    An option to exclude files and folders

    Why is this needed:

    In the context of scanning in a container, for example in GitLab-CI, without privileged mode of the underlying docker and DinD, there are 2 options :

    • Pulling the image with podman, but it's time and disk consuming. Not an acceptable option
    • Scan the image from the image itself, but in the case of GitLab, the repository will be mounted in /builds and it should not be scanned.

    So the best option is to scan the image from the image itself, by excluding the repository clone.

    enhancement 
    opened by Karreg 15
  • false positive CVE-2017-7297 for all versions of github.com/docker/docker

    false positive CVE-2017-7297 for all versions of github.com/docker/docker

    What happened:

    Running grype on a syft-generated BOM for github.com/thediveo/lxkns raises CVE-2017-7297. However, CVE-2017-7297 is a rancher-related CVE, which mentions Docker, causing grype to wrongly match on all docker versions instead of matching on rancher.

    What you expected to happen:

    No false positive of CVE-2017-7297 for any Docker version and docker go client version.

    How to reproduce it (as minimally and precisely as possible):

    Checkout github.com/thediveo/lxkns. Then run grype on newly checked-out repository directory.

    Environment:

    • grype build from 2dd41311cb250a621db615f5f7085edda88e4bb1
    • go1.17.1
    • linux/arm64
    bug 
    opened by thediveo 14
  • Index out of range while scanning Java webapps

    Index out of range while scanning Java webapps

    What happened: Scanning fails with the message "panic: runtime error: index out of range [2] with length 2". Output:

    $ grype dir:.
     ✔ Vulnerability DB        [updated]
     ✔ Indexed .
     ⠧ Cataloging packages     [packages 0]panic: runtime error: index out of range [2] with length 2
    
    goroutine 15 [running]:
    github.com/anchore/syft/syft/pkg/cataloger/java.parseJavaManifest(0xc00b90a150, 0x28, 0x14df5e0, 0xc00b7ea080, 0xc00b88f5e8, 0xc00b892360, 0x0)
            /Users/runner/go/pkg/mod/github.com/anchore/[email protected]/syft/pkg/cataloger/java/parse_java_manifest.go:59 +0xa90
    github.com/anchore/syft/syft/pkg/cataloger/java.(*archiveParser).discoverMainPackage(0xc00b7300e0, 0x70, 0x12527a0, 0x1)
            /Users/runner/go/pkg/mod/github.com/anchore/[email protected]/syft/pkg/cataloger/java/archive_parser.go:138 +0x2b9
    github.com/anchore/syft/syft/pkg/cataloger/java.(*archiveParser).parse(0xc00b7300e0, 0x37, 0x7fac37059338, 0xc00b654540, 0xc0000ce001, 0xc00b7300e0, 0xc00b7ea060, 0x0, 0x0)
            /Users/runner/go/pkg/mod/github.com/anchore/[email protected]/syft/pkg/cataloger/java/archive_parser.go:89 +0x45
    github.com/anchore/syft/syft/pkg/cataloger/java.parseJavaArchive(0xc009afaba0, 0x37, 0x7fac37059338, 0xc00b654540, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
            /Users/runner/go/pkg/mod/github.com/anchore/[email protected]/syft/pkg/cataloger/java/archive_parser.go:45 +0x11c
    github.com/anchore/syft/syft/pkg/cataloger/common.(*GenericCataloger).Catalog(0xc0006b0a00, 0x1500770, 0xc0000bd0a0, 0xc00589d390, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, ...)
            /Users/runner/go/pkg/mod/github.com/anchore/[email protected]/syft/pkg/cataloger/common/generic_cataloger.go:51 +0x50a
    github.com/anchore/syft/syft/pkg/cataloger.Catalog(0x1500770, 0xc0000bd0a0, 0x0, 0xc004023080, 0xc, 0xc, 0x0, 0xc000afc2d0, 0xc000cdbdc0, 0xae97bb, ...)
            /Users/runner/go/pkg/mod/github.com/anchore/[email protected]/syft/pkg/cataloger/catalog.go:55 +0x1ec
    github.com/anchore/syft/syft.CatalogPackages(0xc000658120, 0x12e4c10, 0x8, 0xc000658120, 0x1348d60, 0x0, 0x0, 0xc00038dce0, 0x14dc601, 0xc00038dce0)
            /Users/runner/go/pkg/mod/github.com/anchore/[email protected]/syft/lib.go:67 +0x4bf
    github.com/anchore/grype/grype/pkg.syftProvider(0x7fffaacd86fc, 0x5, 0x12e4c10, 0x8, 0xc0002766e0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
            /Users/runner/work/grype/grype/grype/pkg/syft_provider.go:20 +0xe7
    github.com/anchore/grype/grype/pkg.Provide(0x7fffaacd86fc, 0x5, 0x12e4c10, 0x8, 0xc0002766e0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
            /Users/runner/work/grype/grype/grype/pkg/provider.go:20 +0x115
    github.com/anchore/grype/cmd.startWorker.func1.2(0xc000afc2c0, 0x7fffaacd86fc, 0x5, 0xc0005586a8, 0xc000a4f2a0, 0xc000074db0, 0xc00065e0c0, 0xc000afc2b7)
            /Users/runner/work/grype/grype/cmd/root.go:254 +0x105
    created by github.com/anchore/grype/cmd.startWorker.func1
            /Users/runner/work/grype/grype/cmd/root.go:251 +0x35f
    

    What you expected to happen: To complete the scan instead of failing due to some possibly invalid Java manifest. Being told in the report what files / folders were skipped due to such parse errors.

    How to reproduce it (as minimally and precisely as possible): Not sure, the error doesn't even report what file grype was scanning when the error occurred.

    Anything else we need to know?:

    Environment:

    • Output of grype version:
    $ grype version
    Application:          grype
    Version:              0.27.1
    Syft Version:         v0.32.1
    BuildDate:            2021-12-14T02:57:11Z
    GitCommit:            3f23425fa5d38822b31101cf6fde5b10b772951a
    GitTreeState:         clean
    Platform:             linux/amd64
    GoVersion:            go1.16.10
    Compiler:             gc
    Supported DB Schema:  3
    
    • OS (e.g: cat /etc/os-release or similar):
    $ cat /etc/os-release
    NAME="CentOS Linux"
    VERSION="7 (Core)"
    ID="centos"
    ID_LIKE="rhel fedora"
    VERSION_ID="7"
    PRETTY_NAME="CentOS Linux 7 (Core)"
    ANSI_COLOR="0;31"
    CPE_NAME="cpe:/o:centos:centos:7"
    HOME_URL="https://www.centos.org/"
    BUG_REPORT_URL="https://bugs.centos.org/"
    
    CENTOS_MANTISBT_PROJECT="CentOS-7"
    CENTOS_MANTISBT_PROJECT_VERSION="7"
    REDHAT_SUPPORT_PRODUCT="centos"
    REDHAT_SUPPORT_PRODUCT_VERSION="7"
    
    bug changelog-ignore 
    opened by soerenBoisen 12
  • Not Able to Scan Vulnerabilities for Scratch Image

    Not Able to Scan Vulnerabilities for Scratch Image

    What happened: i have image with using FROM alpine:latest What you expected to happen: Using latest version, i am not able to get any vulnerabilities, but if i change to FROM ubuntu:18.04 image i get more than 200 How to reproduce it (as minimally and precisely as possible): grype -vv -o json --scope all-layers

    Anything else we need to know?: there is no change other than above mentioned in docker file Environment:

    • Output of grype version:
    [0002] DEBUG layer metadata: index=0 digest=sha256:2973d55510fcfb1991a6e03231fd5ebfbb408ce99a3337aba8ff8c8c559d773c mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG layer metadata: index=1 digest=sha256:3b368396247a19e2c90944cb32dea8a471ffd182c5b8d63ac002f54a1d1ac323 mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG layer metadata: index=2 digest=sha256:f598f7fc9b7016a47d4c76189e8cec9a6dc90d81aae91a1133b72014d48ef107 mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG layer metadata: index=3 digest=sha256:93b2ea81c49b7858aaeb40d5bc2565661e62c5fc585340f5e969fe45639a78be mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG layer metadata: index=4 digest=sha256:f3e5a123a6cfe24332a695421ac59787f294ca35c25853e43f0411b1739c5c8a mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG layer metadata: index=5 digest=sha256:b99e18ed96cb7d168f15426cdacc789a3d663c006075820b8c1f3b32d5b4a1a0 mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG layer metadata: index=6 digest=sha256:78c5c0f7adc7d3a5b21a85e769887d938ce4213d9de8360861d262d88f4a8626 mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG layer metadata: index=7 digest=sha256:454666fd2fc96b3cecf398b3c9eaf10e887e157f23de0238e7e5566bd26db58e mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip from-lib=stereoscope
    [0002] DEBUG No Refs found from path: /etc/os-release from-lib=syft
    [0002] DEBUG No Refs found from path: /usr/lib/os-release from-lib=syft
    [0002] DEBUG No Refs found from path: /bin/busybox from-lib=syft
    [0002]  INFO could not identify distro from-lib=syft
    [0002]  INFO cataloging image from-lib=syft
    [0002] DEBUG package cataloger "ruby-gemspec-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "python-package-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "javascript-package-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "dpkgdb-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "rpmdb-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "java-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "apkdb-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "go-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG package cataloger "rust-cataloger" discovered 0 packages from-lib=syft
    [0002] DEBUG found database update candidate: Listing(url=https://toolbox-data.anchore.io/grype/databases/vulnerability-db_v3_2021-08-17T08:14:04Z.tar.gz)
    [0002] DEBUG no database update available
    
    • OS (e.g: cat /etc/os-release or similar):
    opened by bnanda2006 12
  • Support CycloneDX as SBOM input to grype

    Support CycloneDX as SBOM input to grype

    What would you like to be added: We are using grype but our generated SBOM files are not always generated by Syft. We'd like to understand what is needed to accept this standard format.

    Why is this needed: To accept commonly used format for the generation of BOM.

    Additional context:

    We saw in the README that is part of the future plans. However the proliferation of tools creating SBOM files following the standard formats represents a blocker to continue using grype.

    enhancement format:cyclonedx 
    opened by hectorj2f 11
  • Ability to ignore vulnerability matches (to help manage false positives)

    Ability to ignore vulnerability matches (to help manage false positives)

    What would you like to be added: I would like to be able to quickly add false positives or accepted vulnerabilities/CVE's to a list so that they are not returned by Grype Why is this needed: This creates less noise for devs and security teams that may want to ignore any false positives or accepted vulnerabilities presented by grype and solely focus on relevant vulns Additional context:

    enhancement 
    opened by cdhaydensmith 11
  • Grype No Longer showing specific Vulnerabilities in Results because of underlying DB update

    Grype No Longer showing specific Vulnerabilities in Results because of underlying DB update

    What happened:

    Grype is no longer showing vulnerabilities that were appearing before.

    What you expected to happen:

    Grype to show the same vulnerabilities it was capturing before.

    How to reproduce it (as minimally and precisely as possible):

    Run grype against the image now, vs yesterday.

    Anything else we need to know?:

    see below

    Environment:

    see below

    Run from 12 Hours ago

    Run anchore/[email protected] /usr/bin/chmod +x /home/runner/work/_temp/f13dc86a-c4c5-41dc-84d3-a9b1e98ea2f3 /home/runner/work/_temp/f13dc86a-c4c5-41dc-84d3-a9b1e98ea2f3 -b /home/runner/work/_temp/f13dc86a-c4c5-41dc-84d3-a9b1e98ea2f3_grype v0.38.0 [info] checking github for release tag='v0.38.0' [info] fetching release script for tag='v0.38.0' [info] checking github for release tag='v0.38.0' [info] using release tag='v0.38.0' version='0.38.0' os='linux' arch='amd64' [info] installed /home/runner/work/_temp/f13dc86a-c4c5-41dc-84d3-a9b1e98ea2f3_grype/grype grype output... Executing: grype -o sarif --fail-on medium gcr.io/***/sourcecode-pullrequest:1.0.3-1-g40a6ac8 [0000] WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none

    1 error occurred: * discovered vulnerabilities at or above the severity threshold

    Output:

    {"version":"1.0.3-1-g40a6ac8","grype_scan":{"version":"2.1.0","$schema":"https://json.schemastore.org/sarif-2.1.0-rtm.5.json","runs":[{"tool":{"driver":{"name":"Grype","version":"0.38.0","informationUri":"https://github.com/anchore/grype","rules":[{"id":"CVE-2022-30065-busybox","name":"ApkMatcherExactDirectMatch","shortDescription":{"text":"CVE-2022-30065 high vulnerability for busybox package"},"fullDescription":{"text":"Version 1.35.0-r15 is affected with an available fix in versions 1.35.0-r17"},"helpUri":"https://github.com/anchore/grype","help":{"text":"Vulnerability CVE-2022-30065\nSeverity: high\nPackage: busybox\nVersion: 1.35.0-r15\nFix Version: 1.35.0-r17\nType: apk\nLocation: /lib/apk/db/installed\nData Namespace: alpine:3.16\nLink: [CVE-2022-30065](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30065)","markdown":"**Vulnerability CVE-2022-30065**\n| Severity | Package | Version | Fix Version | Type | Location | Data Namespace | Link |\n| --- | --- | --- | --- | --- | --- | --- | --- |\n| high  | busybox  | 1.35.0-r15  | 1.35.0-r17  | apk  | /lib/apk/db/installed  | alpine:3.16  | [CVE-2022-30065](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30065)  |\n"},"properties":{"security-severity":"7.8"}},{"id":"CVE-2022-30065-ssl_client","name":"ApkMatcherExactIndirectMatch","shortDescription":{"text":"CVE-2022-30065 high vulnerability for ssl_client package"},"fullDescription":{"text":"Version 1.35.0-r15 is affected with an available fix in versions 1.35.0-r17"},"helpUri":"https://github.com/anchore/grype","help":{"text":"Vulnerability CVE-2022-30065\nSeverity: high\nPackage: ssl_client\nVersion: 1.35.0-r15\nFix Version: 1.35.0-r17\nType: apk\nLocation: /lib/apk/db/installed\nData Namespace: alpine:3.16\nLink: [CVE-2022-30065](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30065)","markdown":"**Vulnerability CVE-2022-30065**\n| Severity | Package | Version | Fix Version | Type | Location | Data Namespace | Link |\n| --- | --- | --- | --- | --- | --- | --- | --- |\n| high  | ssl_client  | 1.35.0-r15  | 1.35.0-r17  | apk  | /lib/apk/db/installed  | alpine:3.16  | [CVE-2022-30065](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30065)  |\n"},"properties":{"security-severity":"7.8"}}]}},"results":[{"ruleId":"CVE-2022-30065-busybox","message":{"text":"The path /lib/apk/db/installed reports busybox at version 1.35.0-r15  which is a vulnerable (apk) package installed in the container"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"image//lib/apk/db/installed"},"region":{"startLine":1,"startColumn":1,"endLine":1,"endColumn":1}},"logicalLocations":[{"name":"/lib/apk/db/installed","fullyQualifiedName":"gcr.io/***/sourcecode-pullrequest:[email protected]:ec34fcc1d526fba48f7f88e4ec765fccc17d4692570db85cf32d9d6b020330f2:/lib/apk/db/installed"}]}]},{"ruleId":"CVE-2022-30065-ssl_client","message":{"text":"The path /lib/apk/db/installed reports ssl_client at version 1.35.0-r15  which is a vulnerable (apk) package installed in the container"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"image//lib/apk/db/installed"},"region":{"startLine":1,"startColumn":1,"endLine":1,"endColumn":1}},"logicalLocations":[{"name":"/lib/apk/db/installed","fullyQualifiedName":"gcr.io/***/sourcecode-pullrequest:[email protected]:ec34fcc1d526fba48f7f88e4ec765fccc17d4692570db85cf32d9d6b020330f2:/lib/apk/db/installed"}]}]}]}]},"badgerfile":{"apiVersion":"","organization":"Badgercorp","component":"validation-repo-golang","version":{"manager":"badger","auto":true,"env":"VERSION"},"properties":{"group":"badger.demo","lob":"Sales","portfolio":"Demo Applications","product":"Validation Jobs"}},"commit":"40a6ac88bd7ef94167229ab1311350b8e46083ed"}
    

    Run from Today

    ➜ validation-repo-golang git:(main) ✗ grype -o sarif --fail-on medium gcr.io/***/sourcecode-pullrequest:1.0.3-1-g40a6ac8
    ✔ Vulnerability DB [updated] New version of grype is available: 0.43.0 ✔ Loaded image
    ✔ Parsed image
    ✔ Cataloged packages [23 packages] ✔ Scanned image [0 vulnerabilities]

    [0000] WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none { "version": "2.1.0", "$schema": "https://json.schemastore.org/sarif-2.1.0-rtm.5.json", "runs": [ { "tool": { "driver": { "name": "Grype", "version": "0.38.0", "informationUri": "https://github.com/anchore/grype" } }, "results": [] } ] }

    the vulnerabilities are no longer being returned, any idea what changed?

    bug 
    opened by nkreiger 10
  • Templates for grype output. HTML template

    Templates for grype output. HTML template

    Hi! Does someone have templates for grype? I need to scan my images to human-readable format HTML.

    I think will be great if we can have a directory with templates for grype project.

    enhancement 
    opened by myrkytyn 10
  • Syft spdx-json files with cataloger enabled results in `unable to identify format`

    Syft spdx-json files with cataloger enabled results in `unable to identify format`

    What happened:

    grype cannot process spdx-json files generated by syft when cataloger is enabled.

    $ curl -sSfL https://github.com/fluxcd/flux2/releases/download/v0.27.3/flux_0.27.3_sbom.spdx.json | grype                   
    1 error occurred:
            * failed to catalog: unable to decode sbom: unable to identify format
    

    What you expected to happen:

    grype should support this format which simply adds an extra element named files. By removing it, grype is happy again:

    $ curl -sSfL https://github.com/fluxcd/flux2/releases/download/v0.27.3/flux_0.27.3_sbom.spdx.json | jq 'del(.files)' | grype
    

    How to reproduce it (as minimally and precisely as possible):

    $ wget https://github.com/fluxcd/source-controller/archive/refs/tags/v0.21.2.tar.gz
    $ SYFT_FILE_METADATA_CATALOGER_ENABLED=true syft packages v0.21.2.tar.gz --output spdx-json | grype
    

    Anything else we need to know?:

    Environment:

    • Output of grype version:
    Application:          grype
    Version:              0.33.1
    Syft Version:         v0.39.3
    BuildDate:            2022-02-27T00:01:17Z
    GitCommit:            b0c8dc0e578d4b7c38a6bb4bdfbbda21a4640e53
    GitDescription:       v0.33.1
    Platform:             linux/amd64
    GoVersion:            go1.17.7
    Compiler:             gc
    Supported DB Schema:  3
    
    • Output of syft version:
    syft version
    Application:     syft
    Version:         0.40.0
    BuildDate:       2022-03-02T16:44:56Z
    GitCommit:       1e75cb0418df15f8bc8193b1b8a3b3a8d81cb3b0
    GitDescription:  v0.40.0
    Platform:        linux/amd64
    GoVersion:       go1.17.7
    Compiler:        gc
    
    • OS (e.g: cat /etc/os-release or similar):
    NAME="Ubuntu"
    VERSION="20.04.4 LTS (Focal Fossa)"
    ID=ubuntu
    ID_LIKE=debian
    PRETTY_NAME="Ubuntu 20.04.4 LTS"
    VERSION_ID="20.04"
    HOME_URL="https://www.ubuntu.com/"
    SUPPORT_URL="https://help.ubuntu.com/"
    BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
    PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
    VERSION_CODENAME=focal
    UBUNTU_CODENAME=focal
    
    bug 
    opened by pjbgf 10
  • anchore/grype crit unable to find '' - use 'latest'

    anchore/grype crit unable to find '' - use 'latest'

    When running the installation script:

    curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

    I get this error:

    anchore/grype crit unable to find '' - use 'latest' or see https://github.com/anchore/grype/releases for details

    Don't know what I'm supposed to do next after that. Any help would be greatly appreciated.

    bug 
    opened by bajanray 10
  • Add vendor-provided CVSS scores to vulnerability match records where available

    Add vendor-provided CVSS scores to vulnerability match records where available

    RHEL and third party feeds may sometimes contain vendor specific CVSS scores that are missing in grype (and maybe grype-db) Examples of CVSS score in RHEL feeds:

    {
      "Vulnerability": {
        "CVSS": [
          {
            "base_metrics": {
              "base_score": 4.9,
              "base_severity": "Medium",
              "exploitability_score": 1.2,
              "impact_score": 3.6
            },
            "status": "verified",
            "vector_string": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.0"
          }
        ],
        "Link": "https://access.redhat.com/security/cve/CVE-2020-2901",
        "Name": "CVE-2020-2901",
        "NamespaceName": "rhel:8",
        "Severity": "Medium"
        ...
      }
    }
    

    Check with @nightfurys for examples of third party feeds

    bug epic: grype / engine integration 
    opened by nightfurys 10
  • False positive CVE-2017-18589 rust package matching cookie npm package

    False positive CVE-2017-18589 rust package matching cookie npm package

    What happened: We have cookie in our dependencies. When scanning our repository we get a false positive on cookie Rust package

    NAME    INSTALLED  FIXED-IN  TYPE  VULNERABILITY   SEVERITY 
    cookie  0.5.0                npm   CVE-2017-18589  High   
    

    What you expected to happen: I expect npm cookie package not to match CVEs against "cookie" Rust package.

    How to reproduce it (as minimally and precisely as possible):

    mkdir sandbox
    cd sandbox
    npm init
    npm install cookie
    grype dir:.
    

    Anything else we need to know?:

    Environment:

    • Output of grype version:
    Application:          grype
    Version:              0.50.1
    Syft Version:         v0.56.0
    BuildDate:            2022-09-13T18:32:52Z
    GitCommit:            403a535321c20565676dc633344e2bf8881cee29
    GitDescription:       v0.50.1
    Platform:             darwin/amd64
    GoVersion:            go1.18.5
    Compiler:             gc
    Supported DB Schema:  4
    
    • OS (e.g: cat /etc/os-release or similar):
    System Software Overview:
          System Version: macOS 12.4 (21F79)
          Kernel Version: Darwin 21.5.0
          Boot Volume: Macintosh HD
    
    bug false positive 
    opened by fouadh 0
  • Enable the Scorecard Github Action and badge

    Enable the Scorecard Github Action and badge

    Closes #926

    Hi, here is the PR with the changes to enable the OpenSSF Scorecard Gihub Action as described at #926

    Thanks for the attention and any doubts or concerns please reach me out.

    opened by joycebrum 1
  • CVE-2022-29885 matched to java package

    CVE-2022-29885 matched to java package

    What happened: https://nvd.nist.gov/vuln/detail/CVE-2022-29885

    cpe:2.3:a:apache:tomcat::::::::   Show Matching CPE(s) | From (including)9.0.13 | Up to (including)9.0.62

    cannot find tomcat 9.0.41 grype info: image

    syft info: image

    What you expected to happen: matched How to reproduce it (as minimally and precisely as possible):

    Anything else we need to know?:

    Environment:

    • Output of grype version:
    • OS (e.g: cat /etc/os-release or similar):

    OS: image grype: image syft: image

    grype db:

    image

    bug false positive 
    opened by wangzhichao666 1
  • Enable the Scorecard Github Action and badge

    Enable the Scorecard Github Action and badge

    Hi I am Joyce and I'm working on behalf of Google and the OpenSSF to help essential open-source projects improve their supply-chain security. The OpenSSF is a non-profit foundation backed by the Linux Foundation, dedicated to improving the security of the open-source community. It counts GitHub as a founding member.

    What would you like to be added: I would like to suggest for you to use Scorecard Github Action to increase the security of your repository.

    The Scorecard system combines dozens of automated checks to let maintainers better understand their project's supply-chain security posture. It is developed by the OpenSSF, with direct support from GitHub.

    However, the OpenSSF has also developed the Scorecard GitHub Action, which adds the results of its checks to the project's security dashboard, as well as suggestions on how to solve any issues (see examples on the "Additional context"). This Action has been adopted by 1600+ projects already.

    Would you be interested in a PR which adds this Action? Optionally, it can also publish your results to the OpenSSF REST API, which allows a badge with the project's score to be added to its README.

    Why is this needed:

    Considering the relevance grype has on ensuring the security of many projects, it's been included in the OpenSSF's list of the 100 most critical open-source projects. Thus, the Scorecard Github Action adoption in this project would help you on the identification and the solution of security risks of the repository, which would increase the security of the project and garantee that it is (mostly) safe from malicious sabotage.

    Additional context:

    Code scanning dashboard with multiple alerts, including Code-Review and Token-Permissions

    Detail of a Token-Permissions alert, indicating the specific file and remediation steps

    enhancement 
    opened by joycebrum 2
  • Condense table output for upstream packages

    Condense table output for upstream packages

    What would you like to be added: Today we show all single package-vulnerability matches on a single row. We do this even for packages that are closely related:

    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-25712       High
    libX11                                1.6.8-3.el8              0:1.6.8-5.el8            rpm             CVE-2021-31535       High
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14345       High
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14362       High
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14346       High
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14347       Medium
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14344       Medium
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14360       High
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14361       High
    libX11                                1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14363       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14361       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14346       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14360       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14363       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-25712       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14345       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14347       Medium
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14344       Medium
    libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14362       High
    libX11-common                         1.6.8-3.el8              0:1.6.8-5.el8            rpm             CVE-2021-31535       High
    

    In this example we have the upstream installed package libX11 and a downstream installed component libX11-common are duplicated in the output. This is expected, however, from a summary perspective, is imperfect. Ideally we should summarize that the X11 dependencies need to be updated. Maybe we could convey this in a condensed output:

    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14361       High
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14346       High
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14360       High
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14363       High
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-25712       High
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14345       High
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14347       Medium
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14344       Medium
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-4.el8            rpm             CVE-2020-14362       High
    libX11, libX11-common                         1.6.8-3.el8              0:1.6.8-5.el8            rpm             CVE-2021-31535       High
    

    Why is this needed:

    The motivation for this change is to improve grokability of the table output. The specific suggestion does not matter as much as the note that we should seek to summarize results better than we are today. Maybe we could event add this as a CLI switch or application config option.

    enhancement 
    opened by wagoodman 0
  • False Positive for pkg:gem/http@5.1.0 CVE-2022-29631

    False Positive for pkg:gem/[email protected] CVE-2022-29631

    What happened:

    False Positive for CVE-2022-29631 https://github.com/oblac/jodd-http/issues/9 Which is Java not Ruby, and jodd-http vs http

    What you expected to happen: No vulnerability reported

    How to reproduce it (as minimally and precisely as possible):

    Gemfile.lock with http (5.1.0)

    Anything else we need to know?:

    syft JSON output (trimmed)

    [
      {
        "id": "ccde18520499a064",
        "name": "http",
        "version": "5.1.0",
        "type": "gem",
        "foundBy": "ruby-gemfile-cataloger",
        "licenses": [],
        "language": "ruby",
        "cpes": [
          "cpe:2.3:a:ruby-lang:http:5.1.0:*:*:*:*:*:*:*",
          "cpe:2.3:a:ruby_lang:http:5.1.0:*:*:*:*:*:*:*",
          "cpe:2.3:a:http:http:5.1.0:*:*:*:*:*:*:*",
          "cpe:2.3:a:ruby:http:5.1.0:*:*:*:*:*:*:*",
          "cpe:2.3:a:*:http:5.1.0:*:*:*:*:*:*:*"
        ],
        "purl": "pkg:gem/[email protected]"
      }
    ]
    

    Environment:

    • Output of grype version:
    Application:          grype
    Version:              0.49.0
    Syft Version:         [not provided]
    BuildDate:            [not provided]
    GitCommit:            [not provided]
    GitDescription:       [not provided]
    Platform:             linux/amd64
    GoVersion:            go1.19.1
    Compiler:             gc
    Supported DB Schema:  4
    
    • OS (e.g: cat /etc/os-release or similar):
    NAME="Alpine Linux"
    ID=alpine
    VERSION_ID=3.16.0
    PRETTY_NAME="Alpine Linux v3.16"
    HOME_URL="https://alpinelinux.org/"
    
    bug false positive 
    opened by ben-elttam 0
Releases(v0.50.2)
Owner
Anchore, Inc.
Anchore, Inc.
Agent-less vulnerability scanner for Linux, FreeBSD, Container, WordPress, Programming language libraries, Network devices

Vuls: VULnerability Scanner Vulnerability scanner for Linux/FreeBSD, agent-less, written in Go. We have a slack team. Join slack team Twitter: @vuls_e

Future Corp 9.5k Sep 17, 2022
Scanner to send specially crafted requests and catch callbacks of systems that are impacted by Log4J Log4Shell vulnerability (CVE-2021-44228)

scan4log4shell Scanner to send specially crafted requests and catch callbacks of systems that are impacted by Log4J Log4Shell vulnerability CVE-2021-4

Frank Hübner 12 Sep 17, 2022
Super Java Vulnerability Scanner

XiuScan 不完善,正在开发中 介绍 一个纯Golang编写基于命令行的Java框架漏洞扫描工具 致力于参考xray打造一款高效方便的漏扫神器 计划支持Fastjson、Shiro、Struts2、Spring、WebLogic等框架 PS: 取名为XiuScan因为带我入安全的大哥是修君 特点

4ra1n 116 Dec 30, 2021
Log4j 2 (CVE-2021-44228) vulnerability scanner for Windows OS

log4j-scanner Log4j 2 (CVE-2021-44228) vulnerability scanner for Windows OS. Example Usage Usage .\log4j-scanner.exe Terminal is used to output resul

null 0 Dec 13, 2021
log4jshell vulnerability scanner for bug bounty

log4shell-looker a log4jshell vulnerability scanner for bug bounty (Written in G

Ravro 19 Sep 1, 2022
Yet another log4j vulnerability scanner

k-amon-k - Yet another log4j scanner Quick-n-Dirty installation Assuming you hav

Athanasios Kostopoulos 3 Dec 19, 2021
GONET-Scanner - Golang network scanner with arp discovery and own parser

GO/NET Scanner ScreenShots Install chmod +x install.sh ./install.sh [as root] U

Luis Javier 61 Sep 9, 2022
Gbu-scanner - Go Blog Updates (Scanner service)

Go Blog Updates - Scanner This service scans go blog (go.dev) and publishes new posts to message broker (rabbitmq). It uses mongodb as a storage for a

null 1 Jan 10, 2022
Carbon Black Harbor Adapter is a scanner to scan images in Harbor Registry with the help of Carbon Black Cloud.

carbon-black-adapter-for-harbor Overview Carbon Black adapter for Harbor integrates your Harbor Registry with the Carbon Black Cloud. It leverages Har

VMware 3 Apr 18, 2022
Find secrets and passwords in container images and file systems

Find secrets and passwords in container images and file systems

null 1.6k Sep 27, 2022
A fast tool to mass scan for a vulnerability on Microsoft Exchange Server that allows an attacker bypassing the authentication and impersonating as the admin (CVE-2021-26855).

proxylogscan This tool to mass scan for a vulnerability on Microsoft Exchange Server that allows an attacker bypassing the authentication and imperson

dw1 140 Aug 28, 2022
Nuclei is a fast tool for configurable targeted vulnerability scanning based on templates offering massive extensibility and ease of use.

Fast and customisable vulnerability scanner based on simple YAML based DSL. How • Install • For Security Engineers • For Developers • Documentation •

ProjectDiscovery 9.8k Sep 18, 2022
Scans and catches callbacks of systems that are impacted by Log4J Log4Shell vulnerability across specific headers.

Log4ShellScanner Scans and catches callbacks of systems that are impacted by Log4J Log4Shell vulnerability across specific headers. Very Beta Warning!

null 56 Jun 17, 2022
Check and exploit log4j2 vulnerability with single Go program.

log4j2-exp Check and exploit log4j2 vulnerability with single Go program. You don't need to install anything except develop it. It supports ldaps and

鹫尾须美 48 Sep 8, 2022
Check and exploit log4j2 vulnerability with single Go program.

Log4Shell Check and exploit log4j2 vulnerability with single Go program. You don't need to install anything except develop it. It supports ldaps and h

鹫尾须美 49 Sep 25, 2022
Detect and fix log4j log4shell vulnerability (CVE-2021-44228)

log4fix This tool is to detect and fix the log4j log4shell vulnerability (CVE-2021-44228) by looking and removing the JndiLookup class from .jar/.war/

Nanitor 11 Apr 8, 2022
Discover and remediate Log4Shell vulnerability [CVE-2021-45105]

sakuraji_log4j This tool is used to discover and remedidate the Log4Shell vulnerability [CVE-2021-45105] by removing the 'JndiLookup.class' file from

Sakuraji 1 Dec 28, 2021
A fast tool to scan CRLF vulnerability written in Go

CRLFuzz A fast tool to scan CRLF vulnerability written in Go Resources Installation from Binary from Source from GitHub Usage Basic Usage Flags Target

dw1 814 Sep 24, 2022
The Go Vulnerability Database

The Go Vulnerability Database golang.org/x/vulndb This repository is a prototype of the Go Vulnerability Database. Read the Draft Design. Neither the

Go 438 Sep 21, 2022