otp scan PRs for vulnerabilities #9790

kikofernandez · 2025-05-02T07:49:08Z

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 · 2025-05-02T07:49:57Z

CT Test Results

38 files 1 006 suites 7h 25m 15s ⏱️
12 565 tests 11 762 ✅ 802 💤 1 ❌
26 975 runs 24 837 ✅ 2 137 💤 1 ❌

For more details on these failures, see this check.

Results for commit d2b09ef.

♻️ 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

garazdawi · 2025-05-04T20:01:47Z

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 · 2025-05-05T19:54:32Z

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 · 2025-05-06T06:57:39Z

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 · 2025-05-07T06:47:53Z

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 · 2025-05-23T14:18:10Z

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

Perform vulnerability scanning per PR. If a CVE is found the PR fails that test
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)

.github/scripts/otp-compliance.es

.github/workflows/osv-scanner-scheduled.yml

erts/emulator/ryu/vendor.info

lib/wx/vendor.info

voltone · 2025-08-21T07:19:37Z

This is the first time I see the OTP purl pkg:otp/[email protected] used as referencing an OTP release. Is this really the right way to express that? Right now I believe the second "path" component is defined as describing an OTP "application". If we assign a special meaning to the value "erlang" in this position, it means there can never be an application by that name.

Should we consider defining a better way to express "releases" in OTP purls, in a way that doesn't clash with application namespace? For example, NPM packages often use an "@" prefix (I don't know what it means, I don't do JS), which in a purl is encoded as "%40". So the Erlang/OTP release 28 could be specified as pkg:otp/%[email protected]?

kikofernandez · 2025-08-21T07:41:54Z

thanks for the feedback.

And yes, I agree with your insights. That said whether that's an issue under the otp type or not, I am not sure...
I do not think that Erlang/OTP, Elixir, nor Gleam will ever name an application erlang; for the same reason that no one should create an application name Elixir that resides under otp/elixir :)

I took the naming based on EEF convention that Elixir is under pkg:otp/[email protected] (https://security.erlef.org/specs/otp_purl_type)
Thanks for the suggestion. I am not too fond of the %40 :)
I see that in the OTP SBOM we place OTP releases as pkg:github/erlang/[email protected]"
Just to be able to merge the PR and start our trial period, I can change it to be consistent with SBOM purls.

We can adjust once we take a final decision. I think that using the github package convention will always be valid, but I would like some consistency between how we name things. If Elixir and Gleam are under otp/elixir and otp/gleam, it makes sense to me that the Erlang language becomes also under the same type :)

voltone · 2025-08-21T07:46:55Z

I took the naming based on EEF convention that Elixir is under pkg:otp/[email protected] (https://security.erlef.org/specs/otp_purl_type)

In an Elixir release there is an elixir application, and the version numbers are the same. So that example refers to the elixir application, not the release.

Just to be able to merge the PR and start our trial period, I can change it to be consistent with SBOM purls.

Yes, that is probably the best way forward. Whether or not OTP purl needs a way to express releases at all then becomes a separate discussion

kikofernandez · 2025-08-21T08:08:44Z

I took the naming based on EEF convention that Elixir is under pkg:otp/[email protected] (https://security.erlef.org/specs/otp_purl_type)

In an Elixir release there is an elixir application, and the version numbers are the same. So that example refers to the elixir application, not the release.

Just to be able to merge the PR and start our trial period, I can change it to be consistent with SBOM purls.

Yes, that is probably the best way forward. Whether or not OTP purl needs a way to express releases at all then becomes a separate discussion

Ok, I did not know

In an Elixir release there is an elixir application, and the version numbers are the same. So that example refers to the elixir application, not the release.
Then I agree with the reasoning and to keep it consistent

Thanks!

maennchen · 2025-08-21T08:14:51Z

Summing up my thoughts I shared on Slack:

1. Scope of otp purls

The otp purl type was designed to identify OTP applications, not entire Erlang/OTP releases.
For example, pkg:otp/elixir refers to the Elixir OTP application (which lives in lib/elixir in the Elixir repo), while the Elixir project itself is pkg:github/elixir-lang/elixir.
Erlang is not an OTP application—it’s a collection of them (e.g. kernel, stdlib, etc.).

2. No special cases

Assigning a special meaning to pkg:otp/erlang or pkg:otp/@erlang would introduce exceptions into the spec, which I’d prefer to avoid.
I’d rather not create special cases in the purl format just to deal with one-off scenarios.

3. Using the application module

One of the design goals is that any otp purl should correspond to something you can handle via the application module in Erlang.
That doesn’t apply to an entire release, so pkg:otp/erlang doesn’t fit.

4. Representing releases

OTP releases are better represented using their actual source location, e.g. pkg:github/erlang/[email protected].
In an SBOM, we can include multiple external references to cover various distributions or identifiers, for example:
- pkg:deb/[email protected]
- cpe:2.3:a:erlang:erlang\/otp:28.0.2:*:*:*:*:*:*:*

This keeps the semantics clear: pkg:otp/... is for OTP applications, while pkg:github/... (or others) is for releases or distributions.

maennchen · 2025-08-21T08:19:47Z

I also did a tiny change to the flowchart in package-url/purl-spec#472 to better reflect the things stated above.

kikofernandez · 2025-08-21T08:20:03Z

Thanks for your input as well @maennchen .
I will follow this advice, I think it is good and I misunderstood the meaning of the PURL otp.

vex/otp-28.openvex.json

u3s · 2025-08-20T14:24:42Z

system/doc/vulnerabilities/vulnerabilities.md

+
+## Introduction
+
+This section describes how Erlang/OTP reports vulnerabilities for Erlang/OTP


I think github advisories should be considered and explained here.
For Erlang/OTP vulnerabilities, this is how CVE are reported today and it will remain I guess.

As we discussed the 2 channels will be redundant. It would be good if we protect in some way against providing inconsistent information.

How Erlang/OTP CVEs are supposed to be fetched? From what source?

The two channels are not redundant, but contain shared information :)

Advisories only list vulnerabilities towards Erlang/OTP (including possible vendor, but not common case)

VEX statements list:

under investigation, probably not used,

affected, same as Advisories, and

not affected, useful to signal that upstream vulnerabilities do not affect us, silencing false positives, e.g., towards openssl/zlib/asmjit/ryu/pcre2/zstd/etc.

At the moment, there could be inconsistent information. This PR is for testing purposes of OpenVEX.
More details about all the good points that you raised here: #9790 (comment)

system/doc/vulnerabilities/vulnerabilities.md

u3s · 2025-08-21T16:25:36Z

HOWTO/SBOM.md

+
+Erlang/OTP will maintain VEX files for the latests three releases.
+Because of this, Erlang/OTP will always contain the latest information in the `master` branch.
+Any OpenVEX file in other branches is considered outdated.


shouldn't they be deleted? or maybe somehow marked so when processed will generated an error indicating the outdatedness fact?

The script only considers useful the changes in master. If we start considering useful possible things in each of the 3 branches/releases that we maintain, it is a nightmare to sync between branches.

If we like OpenVEX, we can push automatic updates towards a new section in erlang.org that contains OpenVEX statements and users are supposed to fetch those.

For now, this PR is a way to test if OpenVEX is good for our use case. All the other alternatives are more complex, so we start with the simplest one :)

HOWTO/SBOM.md

u3s · 2025-08-22T07:25:14Z

system/doc/vulnerabilities/vulnerabilities.md

+the [Erlang/OTP Github repository](https://github.com/erlang/otp) in the `master` branch, where
+`<version>` corresponds to the number of the Erlang/OTP release.
+
+## Erlang/OTP VEX Statements


we can't manually maintain same information in 2 places, I think :-/
should advisory be source of information for Erlang/OTP CVEs? @rickard-green please also comment.
should detection of inconsistent data (advisories vs openvex.table) be something to add to our advisories verification script?

This is a great point, but outside the scope of the PR.
Once this PR is merged, we can start a testing phase of OpenVEX.

Do we find it useful?

Easy with the tooling we have?

Does it silence enough false positives?

After the PR is merged (I started working on the below changes yesterday), I would like to:

release an automation script that download published advisories in Erlang/OTP Github Advisories (checks our advisories)

takes our published OpenVEX files and performs set substraction operations,
OpenVEX -- Published Advisories = {} (ignoring non-OTP non-vulnerable statements), and
Published Advisories -- OpenVEX = {}.
This should guarantee consistency for published CVEs

If there are published advisories not present in OpenVEX files, create an automatic PR towards Erlang/OTP with updated openvex.table and otp-XX.openvex.json files in it

If all of this works, we "only" need to release manual OpenVEX statements (not automatically created) for the vendor dependencies that have new CVEs

I am all in favour of making sure that we automate as much as possible.
If I were to add this part here as well, the PR may end up with more than 10,000 lines, and it is already tricky to test the Github Actions, so I would prefer that we go with a testing phase and continue adding improvements until we decide to fully adopt OpenVEX.

There will be new vulnerabilities and not automated things in the process, but creating a single PR that solves all of it is a huge job, has many moving parts:

OSV API integration,

GH Action integrations scheduled and per PR with reusable workflows that work across three releases,

OpenVEX generation of OTP release and application version inference,

testing and verification of OpenVEX results,

probably more stuff that I forgot

If we add automatic generation of PRs and sync with GH Advisories for verification purposes, it is a humongous task for a testing phase of OpenVEX. The end result should contain as much automation as possible, but we are just starting 😄

I think this PR is "big enough" already.
Maybe remove Erlang/OTP vulnerabilities from it (just a thought to reduce scope and simplify the journey)? To reduce the scope but have all the mechanics you need in place? Also reduce the pressure on automating the sync between advisories and OpenVex?

- 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 - create range of products for otp non_affected status with this change, introducing an erlang/otp application will fetch all versions of the application from initial version until the last version of the OTP release. Example: ``` { "pkg:otp/[email protected]": "CVE-2023-45853", "status": { "not_affected": "vulnerable_code_not_present" }} ``` will produce erts version 14.0 - 14.2.5.11 and all OTP releases as well. This makes sense to write for erts and other applications that rely on third party, simply to state that Erlang is not vulnerable. in any other case, it does not make sense as either OTP is affected by a CVE towards OTP, or it is not.

kikofernandez self-assigned this May 2, 2025

kikofernandez requested review from garazdawi and rickard-green May 2, 2025 09:22

kikofernandez added the team:VM Assigned to OTP team VM label May 2, 2025

DDupriest approved these changes May 3, 2025

View reviewed changes

kikofernandez force-pushed the add-vendor-vulnerability-analysis branch from 86a4478 to c10c255 Compare May 5, 2025 19:59

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

kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 4 times, most recently from 007ae7f to 982b107 Compare May 23, 2025 13:06

kikofernandez changed the base branch from master to maint May 23, 2025 14:18

kikofernandez requested review from garazdawi and rickard-green and removed request for garazdawi and rickard-green May 23, 2025 14:19

garazdawi reviewed May 26, 2025

View reviewed changes

garazdawi self-requested a review May 26, 2025 13:49

kikofernandez requested a review from IngelaAndin August 18, 2025 16:56

IngelaAndin previously approved these changes Aug 19, 2025

View reviewed changes

kikofernandez dismissed IngelaAndin’s stale review via ecc9a25 August 20, 2025 07:36

kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 3 times, most recently from b359ae7 to 0389fe1 Compare August 20, 2025 07:45

kikofernandez requested a review from IngelaAndin August 21, 2025 08:36

maennchen reviewed Aug 21, 2025

View reviewed changes

vex/otp-28.openvex.json Outdated Show resolved Hide resolved

kikofernandez force-pushed the add-vendor-vulnerability-analysis branch 3 times, most recently from 224776a to 08f01c0 Compare August 21, 2025 12:17

IngelaAndin previously approved these changes Aug 21, 2025

View reviewed changes

kikofernandez dismissed IngelaAndin’s stale review via 8229932 August 22, 2025 07:35

kikofernandez force-pushed the add-vendor-vulnerability-analysis branch from 08f01c0 to 8229932 Compare August 22, 2025 07:35

u3s reviewed Aug 22, 2025

View reviewed changes

kikofernandez force-pushed the add-vendor-vulnerability-analysis branch from 04e7af8 to 2b27cb6 Compare August 22, 2025 09:25

u3s previously approved these changes Aug 25, 2025

View reviewed changes

kikofernandez dismissed u3s’s stale review via fa474ed August 25, 2025 09:46

IngelaAndin self-requested a review August 25, 2025 09:48

IngelaAndin approved these changes Aug 25, 2025

View reviewed changes

kikofernandez force-pushed the add-vendor-vulnerability-analysis branch from fa474ed to d2b09ef Compare August 25, 2025 11:03

kikofernandez merged commit d848fbc into erlang:master Aug 26, 2025
62 of 65 checks passed


		## Introduction

		This section describes how Erlang/OTP reports vulnerabilities for Erlang/OTP

otp scan PRs for vulnerabilities #9790

otp scan PRs for vulnerabilities #9790

Uh oh!

Conversation

kikofernandez commented May 2, 2025

Uh oh!

github-actions bot commented May 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CT Test Results

Artifacts

Uh oh!

garazdawi commented May 4, 2025

Uh oh!

kikofernandez commented May 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

kikofernandez commented May 6, 2025

Uh oh!

github-advanced-security bot commented May 7, 2025

Uh oh!

kikofernandez commented May 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

voltone commented Aug 21, 2025

Uh oh!

kikofernandez commented Aug 21, 2025

Uh oh!

voltone commented Aug 21, 2025

Uh oh!

kikofernandez commented Aug 21, 2025

Uh oh!

maennchen commented Aug 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maennchen commented Aug 21, 2025

Uh oh!

kikofernandez commented Aug 21, 2025

Uh oh!

Uh oh!

u3s Aug 20, 2025

Choose a reason for hiding this comment

Uh oh!

kikofernandez Aug 22, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

u3s Aug 21, 2025

Choose a reason for hiding this comment

Uh oh!

kikofernandez Aug 22, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

u3s Aug 22, 2025

Choose a reason for hiding this comment

Uh oh!

kikofernandez Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kikofernandez Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

u3s Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

github-actions bot commented May 2, 2025 •

edited

Loading

kikofernandez commented May 5, 2025 •

edited

Loading

kikofernandez commented May 23, 2025 •

edited

Loading

maennchen commented Aug 21, 2025 •

edited

Loading

kikofernandez Aug 22, 2025 •

edited

Loading

kikofernandez Aug 22, 2025 •

edited

Loading

u3s Aug 25, 2025 •

edited

Loading