Skip to content

otp scan PRs for vulnerabilities #9790

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kikofernandez
Copy link
Contributor

  • 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.

@kikofernandez kikofernandez self-assigned this May 2, 2025
Copy link
Contributor

github-actions bot commented May 2, 2025

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

// Erlang/OTP Github Action Bot

@kikofernandez kikofernandez added the team:VM Assigned to OTP team VM label May 2, 2025
@garazdawi
Copy link
Contributor

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
Copy link
Contributor Author

kikofernandez commented May 5, 2025

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 kikofernandez force-pushed the add-vendor-vulnerability-analysis branch from 86a4478 to c10c255 Compare May 5, 2025 19:59
@kikofernandez
Copy link
Contributor Author

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)

@kikofernandez kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 7 times, most recently from 4f13738 to f74a0f5 Compare May 7, 2025 06:35
@github-advanced-security
Copy link

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 kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 4 times, most recently from 007ae7f to 982b107 Compare May 23, 2025 13:06
@kikofernandez
Copy link
Contributor Author

kikofernandez commented May 23, 2025

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)

@kikofernandez kikofernandez changed the base branch from master to maint May 23, 2025 14:18
@kikofernandez kikofernandez requested review from garazdawi and rickard-green and removed request for garazdawi and rickard-green May 23, 2025 14:19
@garazdawi garazdawi self-requested a review May 26, 2025 13:49
garazdawi
garazdawi previously approved these changes May 26, 2025
@CLAassistant
Copy link

CLAassistant commented Jun 10, 2025

CLA assistant check
All committers have signed the CLA.

@kikofernandez kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 2 times, most recently from 07936d8 to 9a8d637 Compare June 10, 2025 18:08
@kikofernandez kikofernandez changed the base branch from maint to master June 10, 2025 18:09
@kikofernandez kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 6 times, most recently from d1ce4bc to f8bdd68 Compare June 17, 2025 14:48
@kikofernandez
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@kikofernandez kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 2 times, most recently from 99a543f to d6ee2c5 Compare June 17, 2025 19:55
@kikofernandez kikofernandez requested a review from garazdawi June 17, 2025 21:04
@kikofernandez kikofernandez added the full-build-and-check Run a more thorough testing of this PR label Jun 18, 2025
@kikofernandez kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 3 times, most recently from cb9133b to 2ef8b43 Compare June 18, 2025 11:03
- perform vulnerability analysis on a pull requests basis and on a
  scheduled basis.

- adds the option `osv-scan` to `otp-compliance.es` to submit requests
  to OSV API.

- filter CVEs found based on VEX statements

- creation of reusable Github workflow to allow direct
  calls (workflow_call) and gh triggering events (workflow_dispatch).

- add script to generate OpenVex statements based on ErlangOTP release
  tree, i.e., generates statements for OTP versions and OTP applications
@kikofernandez kikofernandez force-pushed the add-vendor-vulnerability-analysis branch from 2ef8b43 to 75454be Compare June 18, 2025 12:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
full-build-and-check Run a more thorough testing of this PR team:VM Assigned to OTP team VM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Vulnerability, License and ScoreCard Info missing for API Dependency Submission
4 participants