Review JFrog article on new attack types seen on NuGet, and assess against our list of mitigations today

[adriandiglio]

Might need to triage this article, and potentially add impersonating well-known package authors as another threat that should be included in our list. And evaluate if a net-new requirement should be added.

https://jfrog.com/blog/attackers-are-starting-to-target-net-developers-with-malicious-code-nuget-packages/

[tpepper]

I feel like OSS Supply Chain Threat “A malicious actor creates a malicious package that is similar in name to a popular OSS component to trick developers into downloading it” is effectively the impersonation scenario from the article. Maybe the text could be “…is similar in name or namespace…“?

The listed mitigations should also roughly cover the situation. Maybe AUD-1 could state “Able to track that a given OSS package traces back to the expected repo and expected maintainer(s)“?

[pp-researcher]

I agree with @tpepper. The requirement should be updated to: "A malicious actor creates a malicious package that is similar in name or namespace to a popular OSS component to trick developers into downloading it" and AUD-1 to be updated as "Able to track that a given OSS package traces back to the expected repo and expected maintainer(s)" to cover the impersonation threat.

[adriandiglio]

We discussed this during the S2C2F SIG meeting on 4/11/2023, and we agreed that a well-written requirement does not include the word "and". As soon as the word "and" is introduced to a requirement, then there are multiple aspects that need to be satisfied before the requirement is satisfied. Thus, we believe that this is best represented as a new requirement.

In accordance with your recommendations, I think we will update our list of known threats appropriately to include this new "author impersonation" threat, and the text of the requirement should read, "Able to track that a given OSS package traces back to the expected maintainer(s)."

We also need to agree on the Practice that this new requirement belongs to, and what Maturity level it should be. I'll start by proposing that I think this should be added to the Audit Practice so that it sits next to the "AUD-1 expected repo" requirement, and I'll propose that I think this belongs under Maturity Level 3 (same as AUD-1).

What do you all think?

[tpepper]

I like the proposal. I can imagine the "able to track that a given OSS package ___" list might additionally grow in future.

[CsatariGergely]

In accordance with your recommendations, I think we will update our list of known threats appropriately to include this new "author impersonation" threat, and the text of the requirement should read, "Able to track that a given OSS package traces back to the expected maintainer(s)."

How is the capability to trace back to the expected repo differs from capability to trace back to the expected maintainers? For me these are the same. Maybe "Able to track that a given OSS package traces back to the expected repo with the expected maintainer(s)"?

[joshuagl]

In accordance with your recommendations, I think we will update our list of known threats appropriately to include this new "author impersonation" threat, and the text of the requirement should read, "Able to track that a given OSS package traces back to the expected maintainer(s)."

How is the capability to trace back to the expected repo differs from capability to trace back to the expected maintainers?

Source code from an expected SCM repository is usually transformed during packaging and publishing. Some examples of where the new AUD-5 could help:

• If the source code comes from the expected repository but the repository has been compromised, as with PHP internals.
• If the source code comes from the expected repository, but the package was not generated by the maintainer and had malicious content introduced during packaging---i.e. through install hooks, as in the example added to the threats table in #20.
• If the source code comes from the expected repository, but the source was modified during the packaging process as with Webmin.

Maybe "Able to track that a given OSS package traces back to the expected repo with the expected maintainer(s)"?

The repo having the expected maintainers does not help in any of the three cases I cited above, but checking that the package was from an approved maintainer (as in the proposed AUD-5) does help with the first two.

[adriandiglio]

Based on discussions today, we believe a more sustainable approach toward having S2C2F addressing this type of threat is to ensure that OSS Consumers are pulling from "endorsed sources". This can be achieved through OpenSSF Scorecard package scores, a 3rd party vetting service, and/or at least mitigated in other ways.

As such, S2C2F won't create a new AUD-x requirement, however, we do plan to provide guidance on how to leverage OpenSSF Scorecards metadata to make policy decisions. This will be documented in Supplemental Material as tracked here: https://github.com/ossf/s2c2f/issues/24