finos / security-scanning

How to protect FINOS hosted projects from security threats and license compliance issues

Table of contents

• The problem
• The solution
• Project Layout
• Enabling CVE scanning in your project
  • NodeJS
  • Python
  • Maven
  • Gradle
  • Scala
  • Rust
  • .NET
  • Docker
  • Other languages and build platforms
• Dependency update tool
• Static code analysis
• License reporting and scanning
• Roadmap
• Contributing
• License

The problem

Given the wide range of platforms, languages and build systems used by FINOS projects, finding one solution that secures a codebase is not an easy task, especially considering the incredible amount of libraries available in public library repositories, which can be easily used, embedded, integrated and re-published; this proliferation of artifacts have dramatically influenced software development:

• On average, 95% of the code shipped in a software artifact is composed of upstream libraries (aka dependencies), built, released and managed by external teams, communities and companies that the consumer has no control/influence over.
• A developer has very little awareness of the codebase quality and software development process in the upstream dependencies of a project, unless going through code scrutiny, which is difficult and time consuming
• Every programming language and build tool has a different way of consuming dependencies, making security tool adoption harder and rarer; as a consequence, more security vulnerabilities are released into public library repositories, which leads to the exponential growth of vulnerabilities and risk for all consumers using these libraries

The solution

Let's first recap requirements, based on the considerations made above; a code scan should be:

• Proactive (triggered periodically, ie every day) and reactive (triggered on code changes)
• Compatible with all languages and build platforms adopted by FINOS hosted projects
• Easy to operate by project teams, git-based, without the need for external dashboards
• Integrated into FINOS project onboarding process and FINOS CVE Disclosure Policy
• Monitorable by FINOS Staff, allowing us to provide a proactive support to our projects

The proactive/reactive approach is crucial to enforce security, as it guarantees - granted that changes are always submitted via Pull Requests - that the code will always be free of CVEs (or at most for less than a day):

• The reactive setup will fail any Pull Request where code change introduces a new CVE from the (updated) dependency list
• The proactive setup will notify (ie on a daily schedule) the team if a new CVE - that affects a library in the dependency list - have been published

Based on the requirements discussed above, we tried to consolidate a list of technical specifications:

• 6 supported build platforms - Maven, Gradle, Python (and Poetry), Scala (with SBT), NodeJS and Rust
• CVE scanning
  • Can be configured to only scan runtime dependencies
  • Scans direct and transitive dependencies
  • Ability to ignore warnings/errors, using a git-hosted file
  • Ability to run as part of CI/CD (GitHub actions)
• Static code analysis
  • Ability to run as part of CI/CD (GitHub actions)
• Documentation that describes how to use the scanning and what to expect

It's worth emphasizing the importance of having a mechanism for ignoring warnings and errors, which may well be false positives. Without it, developers will eventually disable any security tool. And it’s important to store it in the codebase so that changes can be easily done by developers using the Git collaboration workflow.

Project Layout

In this codebase you'll find a folder for each of the build platforms listed below. Each folder includes a Hello World project, with a build descriptor that:

1. Pulls in a CVE
2. Configures a CVE scanning tool that is specific to the build tool
3. Defines a list of ignored warnings/errors caused by the CVE scanning

In the .github/workflows folder you'll find a GitHub Action for each of these projects, that you can simply copy/paste into your GitHub repository and edit to align to your project layout:

• Update the name of the GitHub Action file to cve-scanning.yml (and semgrep.yml), which allows FINOS to monitor which projects are/aren't adopting the tool; the file name is also reflected in the on: / push: / path: section of the action
• If the build files are located in the root project folder, remove all working-directory configurations
• Adapt runtime versions (ie Node, Python, JVM, etc) with the ones used in your projects

Enabling CVE scanning in your project

1. Identify the language(s) and build system(s) used in the repository you want to scan.
2. Checkout your repository locally.
3. Find - from the list below - which sections applies to you.
4. Follow the instructions to run the scan locally, make sure that the scan runs successfully and generates a list of CVEs.
5. Investigate CVEs, one by one; the majority of CVEs can be addressed by updating a given library to a newer version; in some cases, you'll find out that you're using a certain library in an unsecure way; in some other cases, you may stumble on false positives (that is, a CVE that doesn't apply to your codebase) and therefore you'd have to ignore the error by updating the ignore list file.
6. Copy the related GitHub Action (in .github/workflows) into your project; make sure to call them cve-scanning.yml, so that FINOS monitoring tools can find easily find it.
7. From the GitHub Actions tab, you can select the CVE Scanning action and Create status badge, which will allow you to copy Markdown code for your README.md file that shows a badge with the result of the last action run; this is quite useful for consumers to see that code is scanned and that no CVEs were spotted in the main codebase branch.
8. Push the changes to GitHub and checkout the Github Action run and output.

OWASP Dependency Check

The OWASP Dependency Check (or simply OWASP DC) is a code scanning tool that supports multiple languages, some of which are listed below; it is widely adopted and makes life easier, especially for multi-language projects, as it provides a standard way to define scanning configurations.

It also provides Docker images and GitHub Actions that are nightly built, including the latest and greatest CVE dictionaries that are used to scan project dependencies, allowing the scanning process to be self-contained yet fast (and less error-prone due to usage quota or connectivity issues).

We have used the OWASP Dependency Check Action to run the scanning continuosly, across the following build platforms:

• NodeJS
• Maven
• Gradle
• .NET

In these examples, the OWASP DC Action is also responsible to upload a report as build artifact, which you can access from the Github's Actions tab.

You can suppress false positives by creating an allow-list.xml file and adding CVEs. For more information, refer to the OWASP Dependency Check documentation.

You can exclude dependencies from the scan by adding --exclude in the args of your action see the OWASP Dependency Check documentation. There are various command line arguments available for your specific needs.

Supported languages

NodeJS

The NodeJS sample project uses AuditJS, a library built by Sonatype which provides a very good alternative to npm audit; you can read more about their comparison on https://blog.sonatype.com/compare-npm-audit-versus-auditjs .

The project descriptor pulls the chokidar 2.0.3 dependency, which contains some CVEs that are ignored into the list of ignored errors.

To run AuditJS locally:

1. Access the folder that contains the package.json file
2. Cleanup the codebase from previous runs - rm -rf node_modules
3. Install (only runtime) dependencies - npm ci --prod ; if using yarn, the command should be yarn install --production --frozen-lockfile
4. Run AuditJS - npx --yes auditjs ossi
5. If you want to ignore errors, create an allow-list.json file and append --whitelist allow-list.json to the command on step 4
6. You should see from this example 1 vulnerability - pkg:npm/[email protected] - 1 vulnerability found!

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning.yml; make sure to adapt the code to your project layout.

Python

The Python sample project uses the safety library, which checks requirements.txt entries against the NVD database.

The python sample project defines a dependency on insecure-package, which pulls a CVE that is ignored in the safety-policy.yml, in order to demo how to manage false positives.

If you're using Poetry, you can simply export your libaries into a requirements.txt file and then follow the steps above, using:

poetry install
poetry export --without-hashes -f requirements.txt --output requirements.txt

To run Safety locally:

1. Access the folder containing the requirements.txt file
2. Make sure you're running Python 3.x using python --version, otherwise the version of safety that you're able to use would be quite outdated
3. Create a virtual environment using python -m venv .
4. Install safety with ./bin/pip install safety - we need to run this step since the scanning will run through all libraries available in the current Python environment
5. Run safety with ./bin/safety check --full-report -r requirements.txt
6. If you want to ignore errors, create a safety-policy.yml and append --policy-file safety-policy.yml to the command on step 4
7. You should see from this example 1 vulnerability - Vulnerability found in insecure-package version 0.1.0

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning-python.yml; make sure to adapt the code to your project layout.

Maven

The Maven sample project uses the OWASP Dependency Check plugin for Maven to scan runtime dependencies for known vulnerabilities.

To run the Maven Dependency Check Plugin locally:

1. Access the folder containing the pom.xml file (it supports multi-module builds)
2. Run mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7
3. If you want to ignore errors, create an allow-list.xml and append -DsuppressionFile="allow-list.xml" to the command on step 2

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning.yml; make sure to adapt the code to your project layout.

Gradle

The Gradle sample project uses the OWASP Dependency Check plugin for Gradle. Sadly, Gradle doesn't allow to invoke plugins without altering the build manifest, namely build.gradle; follow instructions below to know how to add code scanning in your project.

To run the Gradle Dependency Check Plugin locally:

1. Access the folder containing the build.gradle file
2. Copy the allow-list.xml file into your project and remove all <suppress> items
3. Copy the dependencyCheck setup from build.gradle file into your build.gradle file
4. Run ./gradlew dependencyCheckAnalyze

The build.gradle file defines a (commented) dependency on struts2 version 2.3.8, which contains the CVE that led to the (famous) equifax hack. By uncommenting it, the build is expected to fail, assuming that CVEs are not suppressed by the allow-list.xml file, used to manage false positives.

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning.yml; make sure to adapt the code to your project layout.

Scala

The Scala sample project uses the OWASP Dependency Check plugin for SBT to scan runtime dependencies for known vulnerabilities.

To run the Scala Dependency Check Plugin locally:

1. Access the root project folder
2. Copy dependencyCheckFailBuildOnCVSS and dependencyCheckSuppressionFiles configurations from build.sbt file in your project
3. Copy the sbt-dependency-check plugin definition from plugins.sbt into your project
4. Run sbt dependencyCheck

The build.sbt file defines a (commented) dependency on struts2 version 2.3.8, which contains the CVE that led to the (famous) equifax hack. By uncommenting it, the build is expected to fail, assuming that CVEs are not suppressed by the allow-list.xml file, used to manage false positives.

If you want to test dependencyCheck:

1. Open the file build.sbt
2. Comment the line dependencyCheckSuppressionFiles ++= List(file("../allow-list.xml")),
3. Run sbt dependencyCheck The build should fail and show all CVEs pulled by struts2.

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning.yml; make sure to adapt the code to your project layout.

To keep your library dependencies, sbt plugins, and Scala and sbt versions up-to-date, checkout Scala Steward.

Rust

The Rust sample project uses Cargo audit to scan runtime dependencies for known vulnerabilities.

To run Cargo Audit locally:

1. Access the root project folder
2. Install Cargo audit with cargo install --force cargo-audit
3. Run the scan with cargo audit
4. Append --ignore RUSTSEC-2020-0071 to the command on step 3

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning.yml; make sure to adapt the code to your project layout.

For more information about Cargo audit configuration, visit https://docs.rs/cargo-audit/0.17.0/cargo_audit/config/index.html

.NET

The .NET sample project uses the dotnet CLI to scan runtime dependencies for known vulnerabilities.

To run dotnet locally:

1. Access the root project folder, where your .csproj file is defined
2. Install .NET CLI
3. Run dotnet build
4. Run the scan with dotnet list package --vulnerable --include-transitive
5. You should see this vulnerability Newtonsoft.Json 12.0.3 12.0.3 High https://github.com/advisories/GHSA-5crp-9r3c-p9vr

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning.yml; make sure to adapt the code to your project layout.

Unfortunately there is no way yet to ignore warnings and errors for dotnet, although it may be possible to add some bash logic into the GitHub Action to achieve it.

Docker

Docker scanning can be very useful to check if downstream Docker images are affected by vulnerabilities; it also scans for OS components and provides a solution for projects using C and C++ code.

There are many CLI tools that perform a docker image scanning; the easiest one is docker scan, as you'll probably have the docker command installed in your local environment, assuming you're already working with Docker.

For GitHub Actions, we are using [trivy][trivy.dev], wrapped into this GitHub Action.

To run locally, follow instructions on how to install trivy locally, then run:

1. docker build -f Dockerfile -t user/image-name:latest .
2. trivy image user/image-name:latest

The GitHub action can be copied from here into your repo under .github/workflows/cve-scanning.yml; make sure to adapt the code to your project layout.

Unfortunately there is no way yet to ignore warnings and errors, although it may be possible to add some bash logic into the GitHub Action to achieve it.

Other languages and build platforms

If your project is built using other languages or build platforms, checkout the list of analyzers offered by the OWASP Dependency Check plugin.

There is also a GitHub Dependency Check Action that uses a nightly build of the CVE database, along with the Dependency check plugin.

Dependency update tool

Keeping dependency versions up to date is a hard task, given the big amount of downstream libraries used by today's software projects and their frequent release cadence; adopting a tool to automate it can drastically save time for developers.

Github ships with Dependabot, which can be easily enabled on every repository, but we found Renovate to be easier and more powerful to use, you can read this comparison article, if you're interested.

Assuming that Renovate is running on your project, the CVE scanning tools mentioned above would generate way less alerts, making it easier to manage project's security; as a result, we strongly advise to enable Renovate first, then add CVE scanning tools.

In order to enable Renovate:

1. Email [email protected] and request enabling the Github App on your FINOS repositories
2. Merge the Pull Request that gets generated after step 1

Renovate will create a GitHub issue (titled Renovate Dashboard) with the recap of the actions that it will take and a one Pull Request for each depdendency version update; please note that:

• The list of Pull Requests sent daily is limited to 10.
• In order to ignore an update, simply close its related Pull Request; Renovate won't ask for the update anymore, unless requested via the Renovate Dashboard issue.

Note that Renovate can be configured to group multiple updates together, using the groupName feature, which can save a lot of developers time, expecially on large codebases.

Static code analysis

To identify bugs in the hosted source code, that is, code that is written and hosted in your own repository, there are several tools out there; the one that proved to work well for us is https://semgrep.dev , and we designed a GitHub Action in .github/workflows/semgrep.yml that continuously scans the code upon every change.

Semgrep supports a long list of programming languages and defines a rich list of rulesets that tests the code against.

It also provides ways to ignore false positives by:

1. adding a // nosemgrep (or # nosemgrep) comment on top of the code block that causes the error
2. adding a .semgrepignore file with a list of file names that should be ignored during the scan

In order to use it, you need to

1. Sign up for free on https://semgrep.dev and generate a token
2. Create a GitHub Secret called SEMGREP_APP_TOKEN, with the token earlier created as value. If you want to enable scanning on a FINOS hosted repository, please email [email protected] and they will take care of setting the SEMGREP_APP_TOKEN secret on the GitHub repository and enabling the Semgrep GitHub app.
3. Run semgrep scan --error --config auto

In order to test it locally, make sure to:

1. Install Semgrep
2. Signup to semgrep.dev
3. Generate a token, using the Settings menu option
4. (optional) export SEMGREP_APP_TOKEN=<your personal semgrep token> - to aggregate results into FINOS (private) dashboard
5. Run semgrep scan --error --config auto from the root folder, here the docs to install semgrep locally

License scanning and reporting

To enforce compliance of open source projects, it is crucial to validate that inbound libraries adopt a license that is "compatible" with the outbound one in terms of rights and obligations; for FINOS, the outbound license used is the Apache License v2.0.

There are hundreds of different open source licenses, some of which have conflicting clauses (you can learn more on tldrlegal.com), and it's sometimes hard to understand the consequences of adopting a library with a different license than the outbound one, especially without having some legal background or knowledge.

For this reason, we are working on automated tasks to continuously scan licenses being pulled within FINOS projects; such tools should be able to either:

• Run a scanning process that takes as input the list of allowed licenses and the packages to ignore (preferred)
• Build a report of licenses that can be manually reviewed and checked

Right now, we have managed to automate license scanning and reporting on:

• Maven
• Python
• Dotnet
• Rust
• Node.js
• Gradle - The allowed-licenses.json file allows to ignore specific libraries/licenses, whereas license-normalizer-bundle.json allows to define license aliases, such as Apache License Version 2.0 and Apache License, Version 2.0. Note that the build.gradle needs to be changed to make use of the Gradle-License-Report plugin

For more info about compliance requirements at FINOS, checkout our Contribution Compliance Requirements and License Categories pages.

Roadmap

1. Add documentation into community.finos.org
2. Publish post on FINOS blog - https://www.finos.org/blog/introducing-finos-security-scanning
3. Push for adoption across FINOS projects
4. Add license reporting and scanning features
5. Add support for C#
6. Add support for mill

Contributing

For any bug, question or enhancement request, please create a GitHub Issue

1. Fork it (https://github.com/finos/code-scanning/fork)
2. Create your feature branch (git checkout -b feature/fooBar)
3. Read our contribution guidelines and Community Code of Conduct
4. Commit your changes (git commit -am 'Add some fooBar')
5. Push to the branch (git push origin feature/fooBar)
6. Create a new Pull Request

NOTE: Commits and pull requests to FINOS repositories will only be accepted from those contributors with an active, executed Individual Contributor License Agreement (ICLA) with FINOS OR who are covered under an existing and active Corporate Contribution License Agreement (CCLA) executed with FINOS. Commits from individuals not covered under an ICLA or CCLA will be flagged and blocked by the FINOS Clabot tool (or EasyCLA). Please note that some CCLAs require individuals/employees to be explicitly named on the CCLA.

Need an ICLA? Unsure if you are covered under an existing CCLA? Email [email protected]

License

Copyright 2022 FINOS

Distributed under the Apache License, Version 2.0.

SPDX-License-Identifier: Apache-2.0

security-scanning's Issues

GitHub Action Configuration

Improve GitHub Actions to be installable on-click via a PR, without the need to update build descriptors, such as pom.xml, build.gradle or similar. See #5 , #6 and #7

It is also acceptable to write some documentation to instruct developers to copy/paste a certain block of code; this is an example coming from GitHub - https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle#using-the-gradle-starter-workflow

The GitHub Actions triggers should be:

• Run every day, at a certain time
• Everytime a PR is submitted, involving specific file names (see below)
• On each push, involcing specific file names (see below)

Specific file names are those defining build descriptors, such as pom.xml, build.gradle, package.json, requirements.txt or pyproject.toml, etc.

Consider adopting ORT

Happen to stumble upon the announcement of this project and wonder if the maintainers of this project are familiar with or have considered OSS Review Toolkit which offers similar functionality as this project.

ORT is a Linux Foundation project maintained by several (mostly automotive) OSPOs and one can use it to automate your FOSS policy using Policy as Code to do licensing, security vulnerabilities and engineering standards checks for your software project and its dependencies. It support detecting dependencies for ~20 different package managers out-of-the-box and is battle-tested with hundreds of thousands of scans done amongst its users over the last 6 years.

ORT users include Bosch, Deutsche Telekom, EPAM, Forvia, HERE Technologies, Porsche and recently the Eclipse foundation indicated its adopting ORT within their IP process.

Happy to do a demo/q&a call, you can reach me via opensource [at] steenbe [.nl]. Will be demo-ing ORT capabilities as part of my Nov 15, 2022 TODO OSPOLogy talk, see also https://community.linuxfoundation.org/events/details/lfhq-todo-group-presents-how-to-automate-your-foss-policy-and-processes/

Gradle depcheck is failing

See https://github.com/finos/code-scanning/actions/runs/6655725039/job/18086616561?pr=295 .

Transitive Dependencies

Seems like it works, might need some definite testing

Add missing license scanning tools

• Gradle
• Scala
• .NET
• Rust

NodeJS CVE scanning is failing - 5.3 CVE found on semver package

See https://github.com/finos/security-scanning/actions/runs/5337432643/jobs/9673473138

[53/65] - pkg:npm/[email protected] - 1 vulnerability found!

  Vulnerability Title:  [CVE-2022-25883] CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
  ID:  CVE-2022-25883
  Description:  Versions of the package semver before 7.5.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.


  CVSS Score:  5.3
  CVSS Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
  CVE:  CVE-2022-25883
  Reference:  https://ossindex.sonatype.org/vulnerability/CVE-2022-25883?component-type=npm&component-name=semver&utm_source=auditjs&utm_medium=integration&utm_content=4.0.39

Suggestions:

1. Run npm install and npm ls --depth=5 to understand where semver is coming from
2. Understand which library to update in package.json in order to pull a non vulnerable version of semgrep
3. (optional - if step 2 cannot be applied for any reason - try to override semver with a new version, see https://www.stefanjudis.com/today-i-learned/how-to-override-your-dependencys-dependencies/
4. (optional - if step 2 and 3 cannot be applied for any reason - add the CVE to the allow list; at the end of the day, this project is a sample to explain how to scan and ignore CVEs

Fix Static Code Analysis action

The semgrep scanning is complaining about GitHub Actions not being pinned, see https://github.com/finos/security-scanning/actions/runs/6416732661/job/17421042253 :

    .github/workflows/cve-scanning-docker.yml 
       yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha.
  third-party-action-not-pinned-                                                
       to-commit-sha                                                            
          An action sourced from a third-party repository on GitHub is not      
  pinned to a full length                                                       
          commit SHA. Pinning an action to a full length commit SHA is currently
  the only way to use                                                           
          an action as an immutable release. Pinning to a particular SHA helps  
  mitigate the risk of a                                                        
          bad actor adding a backdoor to the action's repository, as they would 
  need to generate a                                                            
          SHA-1 collision for a valid Git object payload.                       
          Details: https://sg.run/koLA                                          
                                                                                
           16┆ - uses: docker-practice/actions-setup-docker@master
            ⋮┆----------------------------------------
           21┆ uses: crazy-max/ghaction-container-scan@v2

Run Action without changing SBT Config

Static Code Analysis

Node documentation package-lock.json and yarn.lock

Following the documentation, Node step 2
rm -rf node_modules package-lock.json and yarn.lock
It's removing package-lock.json and yarn.lock which make npm ci --prod not working

npm ERR! The npm ci command can only install with an existing package-lock.json or

Gradle dependencyCheckAnalyze no results

After doing all the steps from readme.md, running the command

• ./gradlew dependencyCheckAnalyze

But the scan result give nothing, still in 0%.

 ./gradlew dependencyCheckAnalyze

Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
Starting a Gradle Daemon, 1 stopped Daemon could not be reused, use --status for details

 > Task :dependencyCheckAnalyze
Verifying dependencies for project gradle
Checking for updates and analyzing dependencies for vulnerabilities
<-------------> 0% EXECUTING [2m 9s]
> :dependencyCheckAnalyze

Contribute this project to FINOS

Blocked by #4

Run Gradle action without changing build configuration

As described on jeremylong/DependencyCheck#4044 (comment) , this approach could help running the Gradle scan without changing build.gradle:

1. Create a file called run-odc.gradle

initscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.owasp:dependency-check-gradle:6.5.3"
  }
}
rootProject {
  apply plugin: org.owasp.dependencycheck.gradle.DependencyCheckPlugin
  dependencyCheck {
    failBuildOnCVSS=5
    suppressionFile="./allow-list.xml"
    format='ALL'
  }
}

2. Run the gradlew command:

./gradlew --init-script run-odc.gradle dependencyCheckAggregate --info

Testing DC GitHub Action

I tried using the DC GitHub Action and reproduce the same check done by the Maven Plugin, to see if I get the same outcome.

This is how I run the Maven Plugin:

git clone [email protected]:maoo/security-scanning.git
cd security-scanning/maven
mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7

This is the result that I get:

[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '7.0':
....

If I use the DC Docker Image as follows (the run-dc.sh script was copied from the Docker image page), I don't get any CVE spotted:

git clone [email protected]:maoo/security-scanning.git
cd security-scanning/maven
../run-dc.sh
cat odc-reports/dependency-check-report.csv

Correct documentation terms

In the documentation, the term "downstream dependency" is used to describe software that is brought in as part of the build process.

Instead, software that flows in should be referred to as "upstream" while software flowing out is "downstream."

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency aws-sdk to v2.1409.0
• Update dependency com.google.guava:guava to v32.1.1-jre

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency org.apache.struts:struts2-core to v2.5.31 [SECURITY]
• Update dependency chokidar to v3.5.3
• Update dependency eslint to v8.44.0
• Update dependency gradle to v8.2
• Update dependency org.apache.struts:struts2-core to v2.5.31
• Update dependency Newtonsoft.Json to v13
• Update dependency org.apache.struts:struts2-core to v6

Detected dependencies

cargo

rust/Cargo.toml

• chrono 0.4.26

dockerfile

docker/Dockerfile

• openjdk 21-jdk

github-actions

.github/workflows/cve-scanning-docker.yml

• actions/checkout v3
• crazy-max/ghaction-container-scan v2

.github/workflows/cve-scanning-dotnet.yml

• actions/checkout v3
• actions/setup-dotnet v3

.github/workflows/cve-scanning-gradle.yml

• actions/checkout v3
• actions/setup-java v3

.github/workflows/cve-scanning-maven.yml

• actions/checkout v3
• actions/setup-java v3

.github/workflows/cve-scanning-node.yml

• actions/checkout v3
• actions/setup-node v3

.github/workflows/cve-scanning-python.yml

• actions/checkout v3
• actions/setup-python v4
• abatilo/actions-poetry v2

.github/workflows/cve-scanning-rust.yml

• actions/checkout v3
• actions-rs/toolchain v1

.github/workflows/cve-scanning-scala.yml

• actions/checkout v3
• actions/setup-java v3

.github/workflows/license-scanning-maven.yml

• actions/checkout v3
• actions/setup-java v3
• actions/upload-artifact v3
• actions/upload-artifact v3

.github/workflows/license-scanning-node.yml

• actions/checkout v3
• actions/setup-node v3

.github/workflows/license-scanning-python.yml

• actions/checkout v3
• actions/setup-python v4

.github/workflows/semgrep-ci.yml

• actions/checkout v3

.github/workflows/semgrep.yml

• actions/checkout v3

gradle

gradle/build.gradle

• org.owasp:dependency-check-gradle 8.3.1
• com.google.guava:guava 32.0.1-jre
• joda-time:joda-time 2.12.5
• org.apache.struts:struts2-core 2.3.8
• junit:junit 4.13.2

gradle-wrapper

gradle/gradle/wrapper/gradle-wrapper.properties

• gradle 8.1.1

maven

maven/pom.xml

• joda-time:joda-time 2.12.5
• org.apache.struts:struts2-core 2.3.8
• org.apache.maven.plugins:maven-shade-plugin 3.5.0

npm

node/package.json

• aws-sdk ^2.149.0
• handlebars ^4.4.2
• is_js ^0.9.0
• jsonwebtoken ^9.0.0
• parse-github-url ^1.0.0
• uuid ^9.0.0
• chokidar 3.0.0
• dotenv 16.3.1
• eslint 8.43.0
• eslint-plugin-prettier 4.2.1
• jasmine 5.0.2
• jasmine-spec-reporter 7.0.0
• mock-require 3.0.3
• node-license-validator 1.3.2
• prettier 2.8.8
• serverless 3.33.0
• xml2js 0.6.0
• glob-parent 6.0.2

nuget

dotnet/sample.csproj

• Newtonsoft.Json 12.0.3

poetry

python/pyproject.toml

• colorama ^0.4.5
• insecure-package 0.1.0
• safety 2.3.5

sbt

scala/build.sbt

• org.apache.struts:struts2-core 2.3.8

scala/project/build.properties

• sbt/sbt 1.9.1

scala/project/giter8.sbt

• org.foundweekends.giter8:sbt-giter8 0.16.2

scala/project/plugins.sbt

• net.vonbuchholtz:sbt-dependency-check 5.1.0

scala/src/main/g8/build.sbt

• scala 2.13.11
• org.scala-lang.modules:scala-parser-combinators 2.3.0

scala/src/main/g8/project/build.properties

• sbt/sbt 1.9.1

---

• Check this box to trigger a request for Renovate to run again on this repository

Support for C#

Apparently this can be achieved using the CLI tool; on this blogpost, the following command line is reported:

dependency-check.bat -s packages/**/*.dll -f HTML --project "demo"

There's also a Docker distro on owasp/dependency-check

There is also a GitHub action using CodeQL, see https://learn.microsoft.com/en-us/dotnet/architecture/devops-for-aspnet-developers/actions-codeql

Run Action W/O Changing Pom

It should be possible to add the action to the project without needing to change pom.

Run Action Without Changing Gradle Buildfile