otp scan PRs for vulnerabilities

[kikofernandez]

• scan PRs for vendor vulnerabilities.
• the submission of the vendor SBOM should happen only on push events.
• vulnerability scanning of dependencies must happen on a per PR basis, and on a per push basis (although Dependatbot should inform us of this).

GH should fix actions/dependency-review-action#923 for us to get alerts about dependencies.

[github-actions]

CT Test Results

    38 files   1 003 suites   7h 25m 36s ⏱️
12 446 tests 11 739 ✅   707 💤 0 ❌
26 871 runs  24 878 ✅ 1 993 💤 0 ❌

Results for commit 75454be.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• No Windows Installer found

// Erlang/OTP Github Action Bot

[garazdawi]

From what I can tell only our github actions dependencies are scanned by this right now, is that correct? Will it in the future be able to use the information in the sbom created in the job you are adding this step to? or is this check only for github actions?

[kikofernandez]

I think you are right @garazdawi
I have updated the PR to scan for vulnerabilities using OSV.

Summary

• CC++ works better in OSV providing a sha, and they do range analysis.
• Our vendor libraries should provide a versionInfo, and in the case of CC++ vendor libraries, we should provide the sha as well. If there is no sha, then we cannot do vulnerability scanning for this CC++ vendor library.
• If a vendor library belongs to an ecosystem, we write its ecosystem in the vendorInfo.
  OSV works better for standard ecosystems, such as npm, maven, hex, etc.

I have tested that it works by manually hand-picking previous commit that fixed a known vulnerability reported to on github repos.

Information sent

{
  "queries": [
    {
      "commit": "1a8db63788c34a50e39e273d39b7e1033208aea2",
      "package": { "name": "github.com/madler/zlib" }
    },
    {
      "commit": "a465fe71ab3d0e224b2b4bd0fac69ae68ab9239d",
      "package": { "name": "github.com/asmjit/asmjit" }
    },
    {
      "commit": "f8745da6ff1ad1e7bab384bd1f9d742439278e99",
      "package": { "name": "github.com/facebook/zstd" }
    },
    {
      "commit": "442029c6fa37f1b6f9203357de09672d5704077c",
      "package": { "name": "github.com/microsoft/STL" }
    },
    {
      "commit": "1264a946ba66eab320e927bfd2362e0c8580c42f",
      "package": { "name": "github.com/ulfjack/ryu" }
    },
    {
      "commit": "cdfb0923a66155ce97640fca68ae57b3a2972029",
      "package": { "name": "github.com/openssl/openssl" }
    },
    {
      "commit": "1e09555d6950bfcf83bd98fa597b0c6440d43c9c",
      "package": { "name": "github.com/PCRE2Project/pcre2" }
    },
    {
      "commit": "636dfadc70ce26f2473870570bfd9ec352806b1d",
      "package": { "name": "github.com/openssl/openssl" }
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "tablesorter"
      },
      "version": "2.32"
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "jquery"
      },
      "version": "3.7.1"
    },
    {
      "commit": "fd0f60daea24e9c62d372d774be9e32ce2b0849d",
      "package": { "name": "github.com/wxWidgets/wxWidgets" }
    }
  ]
}

Result

[OSV] There are existing vulnerabilities:
- github.com/madler/zlib: CVE-2023-45853
- github.com/openssl/openssl: CVE-2024-12797
- github.com/PCRE2Project/pcre2: OSV-2024-1237
- github.com/wxWidgets/wxWidgets: CVE-2024-58249

[kikofernandez]

The vendor vulnerability scanning now fails because I changed the vendor.json sha to refer to existing CVEs, and this PR detects them (https://github.com/erlang/otp/actions/runs/14845728041/job/41679578778?pr=9790 for otp, and this for my fork https://github.com/kikofernandez/otp/actions/runs/14845971887/job/41680388662)

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[kikofernandez]

I have updated the scripts and this is the end result, using OSV for vulnerability scanning.

1. Perform vulnerability scanning per PR. If a CVE is found the PR fails that test
2. Perform vulnerability scanning as per scheduled and fan out per branch. If a CVE is found, create a SARIF file and upload to GH, such that GH Security contains those under Code Scanning on a per last three release basis. (we avoid duplicates via fingerprinting, and postpone the OpenVex integration for now)

[CLAassistant]

All committers have signed the CLA.

[kikofernandez]

This is the expected result whenever there is a CVE found.
https://github.com/kikofernandez/otp/actions/runs/15716372559/job/44286988466

Checking OpenVex statements in 'vex/otp-28.openvex.json'...
OpenVex statements found.
Exiting known vulnerabilities already open:
- github.com/madler/zlib: CVE-2023-45853
- github.com/PCRE2Project/pcre2: OSV-2025-300
- github.com/wxWidgets/wxWidgets: CVE-2024-58249
[Vulnerability] Contact OTP team.
The following CVEs must be checked in OpenVex statements for master:
- github.com/openssl/openssl: CVE-2025-4575

What it says is that it has detected a possible CVE for which the OTP team has not created a VEX statement, thus, it is not clear if ErlangOTP is affected. They way to proceed is to inform OTP team, OTP team pushes a VEX statement about it, and the PR should be re-run (which will pick up the latest master statements and be good to go).

I have removed all the SARIF generation because it was producing more issues than anything else, and instead we use OpenVex as source of truth to confirm if we are affected by CVEs.

[kikofernandez]

The current PR will fail in the reusable workflow because it looks for master to contain openvex statements, and that cannot happen until this PR is merged.