About OWASP dep-scan
dep-scan uses cdxgen command internally to create Software Bill-of-Materials (SBoM) file for the project. This is then used for performing the scans. The following projects and package-dependency format is supported by cdxgen. Language|Package format node.js|package-lock.json, pnpm-lock.yaml, yarn.lock, rush.js, bower.json, .min.js java|maven (pom.xml [1]), gradle (build.gradle, .kts), scala (sbt), bazel php|composer.lock python|setup.py, requirements.txt [2], Pipfile.lock, poetry.lock, bdist_wheel, .whl, .egg-info go|binary, go.mod, go.sum, Gopkg.lock ruby|Gemfile.lock, gemspec rust|binary, Cargo.toml, Cargo.lock .Net|.csproj, packages.config, project.assets.json [3], packages.lock.json, .nupkg dart|pubspec.lock, pubspec.yaml haskell|cabal.project.freeze elixir|mix.lock c/c++|conan.lock, conanfile.txt clojure|Clojure CLI (deps.edn), Leiningen (project.clj) docker / oci image|All supported languages and Linux OS packages GitHub Actions Workflows|.github/workflows/*.yml Jenkins Plugins|.hpi files YAML manifests|docker-compose, kubernetes, kustomization, skaffold, tekton etc NOTE The docker image for dep-scan currently doesn’t bundle suitable java and maven commands required for bom generation. To workaround this limitation, you can -
--risk-audit argument enables package risk audit. Currently, only npm and pypi packages are supported in this mode. A number of risk factors are identified and assigned weights to compute a final risk score. Packages that then exceed a maximum risk score (config.pkg_max_risk_score) are presented in a table. Use --private-ns to specify the private package namespace that should be checked for dependency confusion type issues where a private package is available on public npm/pypi registry. For example, to check if private packages with namespaces @appthreat and @shiftleft are not accidentally made public, use the below argument. --private-ns appthreat,shiftleft Risk category|Default Weight|Reason pkg_private_on_public_registry|4|Private package is available on a public registry pkg_min_versions|2|Packages with less than 3 versions represent an extreme where they could be either super stable or quite recent. Special heuristics are applied to ignore older stable packages mod_create_min_seconds|1|Less than 12 hours difference between modified and creation time. This indicates that the upload had a defect that had to be rectified immediately. Sometimes, such a rapid update could also be malicious latest_now_min_seconds|0.5|Less than 12 hours difference between the latest version and the current time. Depending on the package such a latest version may or may not be desirable latest_now_max_seconds|0.5|Package versions that are over 6 years old are in use. Such packages might have vulnerable dependencies that are known or yet to be found pkg_min_maintainers|2|Package has less than 2 maintainers. Many opensource projects have only 1 or 2 maintainers so special heuristics are used to ignore older stable packages pkg_min_users|0.25|Package has less than 2 npm users pkg_install_scripts|2|Package runs a custom pre or post installation scripts. This is often malicious and a downside of npm. pkg_node_version|0.5|Package supports outdated version of node such as 0.8, 0.10, 4 or 6.x. Such projects might have prototype pollution or closure related vulnerabilities pkg_scope|4 or 0.5|Packages that are used directly in the application (required scope) gets a score with a weight of 4. Optional packages get a score of 0.25 deprecated|1|Latest version is deprecated Refer to pkg_query.py::get_category_score method for the risk formula.
Project Resources
Project Information
Slack