Publish list of OSS compromises and how SLSA can help

[inferno-chromium]

Some of the links we tracked in 2021 and 2020, i am guessing there are many more. We need find the right place to plug them in.

2021
faisalman/ua-parser-js#536
https://jfrog.com/blog/malicious-pypi-packages-stealing-credit-cards-injecting-code/
https://www.bleepingcomputer.com/news/security/npm-package-steals-chrome-passwords-on-windows-via-recovery-tool/
https://blog.secure.software/third-party-code-comes-with-some-baggage
https://www.bleepingcomputer.com/news/security/microsofts-halo-dev-site-breached-using-dependency-hijacking/
https://blog.sonatype.com/sonatype-catches-new-pypi-cryptomining-malware-via-automated-detection
https://www.reddit.com/r/msp/comments/ocggbv/crticial_ransomware_incident_in_progress/h3u5j2e/https://news.sophos.com/en-us/2021/07/04/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses/
https://twitter.com/BRIAN_____/status/1392234974783279105?s=19
https://wwws.nightwatchcybersecurity.com/2021/04/25/supply-chain-attacks-via-github-com-releases/
https://brew.sh/2021/04/21/security-incident-disclosure/https://blog.ryotak.me/post/homebrew-security-incident-en/
https://www.neowin.net/news/linux-bans-university-of-minnesota-for-sending-buggy-patches-in-the-name-of-research/
https://blog.cocoapods.org/CocoaPods-Trunk-RCE/
https://about.codecov.io/security-update/https://arstechnica.com/gadgets/2021/04/backdoored-developer-tool-that-stole-credentials-escaped-notice-for-3-months/https://www.theregister.com/2021/04/26/hashicorp_reveals_exposure_of_private/https://www.bleepingcomputer.com/news/security/hashicorp-is-the-latest-victim-of-codecov-supply-chain-attack/
https://blog.sonatype.com/damaging-linux-mac-malware-bundled-within-browserify-npm-brandjack-attempt
https://www.bleepingcomputer.com/news/security/phps-git-server-hacked-to-add-backdoors-to-php-source-code/
https://unit42.paloaltonetworks.com/malicious-cryptojacking-images/
https://michenriksen.com/blog/finding-evil-go-packages/
https://lwn.net/SubscriberLink/846272/4f8e060bdfc0e0de/
https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
https://www.welivesecurity.com/2021/02/02/kobalos-complex-linux-threat-high-performance-computing-infrastructure/
https://www.bleepingcomputer.com/news/security/heres-how-a-researcher-broke-into-microsoft-vs-codes-github/
https://www.ehackingnews.com/2021/01/perlcom-official-site-for-perl.html
https://threatpost.com/discord-stealing-malware-npm-packages/163265/
https://www.theregister.com/2021/01/07/great_suspender_malware/

2020
https://www.zdnet.com/article/malicious-npm-packages-caught-installing-remote-access-trojans/
https://twitter.com/kengiter/status/1330209964812607494https://www.theverge.com/2021/4/22/22398156/university-minnesota-linux-kernal-ban-research
https://www.zdnet.com/google-amp/article/npm-package-caught-stealing-sensitive-discord-and-browser-files/
https://jordan-wright.com/blog/post/2020-11-12-hunting-for-malicious-packages-on-pypi/
https://www.reddit.com/r/HobbyDrama/comments/jouwq7/open_source_development_the_great_suspender_saga/
https://www.reddit.com/r/HobbyDrama/comments/jo9wxn/open_source_development_the_fall_of_nano_defender/
https://www.zdnet.com/article/malicious-npm-package-opens-backdoors-on-programmers-computers/
https://blog.securityinnovation.com/repo-jacking-exploiting-the-dependency-supply-chain
https://www.zdnet.com/article/three-npm-packages-found-opening-shells-on-linux-windows-systems/
https://www.zdnet.com/article/four-npm-packages-found-uploading-user-details-on-a-github-page/
https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain
https://blog.reversinglabs.com/blog/mining-for-malicious-ruby-gems

[inferno-chromium]

This is another one - https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises

[MarkLodato]

One idea: add references to real-world attacks from https://slsa.dev/threats

[jspeed-meyers]

Thought I would add this dataset of all publicly known software supply chain compromises that I and others have been maintaining: https://github.com/IQTLabs/software-supply-chain-compromises

Perhaps this dataset should be moved to the governance of OpenSSF or SLSA? This way interested parties don't need to copy around a bunch of links but have a canonical dataset. I'd be glad to discuss if there is any interest.

Here also is a link to an article by myself and others that analyzes this dataset: https://www.usenix.org/system/files/login/articles/login_winter20_17_geer.pdf

Also, I like this idea of analyzing how SLSA can help with these compromises. Please let me know if I can be helpful with that as well.

[david-a-wheeler]

I really like the idea of capturing research on software supply chain attacks. I would also add the Backstabber's Knife Collection paper.

I think it might be better if the overall list of relevant compromises was in the main OpenSSF "Supply Chain Integrity" Working Group's GitHub repo. Basically, we could create a page or directory under https://github.com/ossf/wg-supply-chain-integrity and maintain it there. SLSA is part of that WG, but it's easy to imagine that other work will slot in.

I also like the idea of analyzing how SLSA can help. SLSA-specific analysis belongs, I think, within SLSA.

What do you think?

[jspeed-meyers]

@david-a-wheeler, thank you for the response. That sounds like a reasonable plan to me, though I have a modest amendment to propose. Adding @inferno-chromium, @MarkLodato, @trishankatdatadog, and @dlorenc if they have any suggestions, proposals or different opinions.

First, it makes sense to have this dataset (i.e. https://github.com/IQTLabs/software-supply-chain-compromises) associated with the supply chain integrity group, if they're open to it!

Second, and this is the amendment, it would seem logical to me fork the current repo (https://github.com/IQTLabs/software-supply-chain-compromises) to the overall ossf GitHub group so that there would then be a ossf/software-supply-chain-compromises repo. The supply chain integrity working group page would then have a link to this dataset.

• The text of the ossf/software-supply-chain-compromises will need to be amended to make it more germane to OpenSSF and less to IQT Labs, the organization that is my current employer and currently hosts it.
• The text will also need to be made slightly more professional. Sorry!
• The current repo (https://github.com/IQTLabs/software-supply-chain-compromises) should have text added to it that the dataset has been moved to openSSF at a new link and this IQTLabs repo should be archived.

Third, the same section of the supply chain integrity group GitHub page that links to this dataset should also, like you mention, link to the Backstabber's Knife Collection dataset and paper. The one other similar effort that could also be mentioned is the dataset created by Trey Herr for the Breaking Trust project at the Atlantic Council:

Fourth, I agree that the SLSA-specific analysis, if it is done, should be done within SLSA.

Fifth, let me make sure my collaborators and IQT colleagues all support these actions. I think they unanimously will, but let me get back to you early next week.

Finally, if it's not clear from the dataset or paper about the dataset, this dataset is very much a work in progress and could stand to be improved on many dimensions. So if any party objects to aspects of the dataset small or large, object away! I'm sure it could be dramatically improved with the input of the OpenSSF community, which is why I think it should live here, should there be interest.

How does all of that sound?

[kimsterv]

adding another one to the list
https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

[bureado]

(Edit: this one mentioned above: Here's another decently sized and reasonably updated inventory that I have contributed to in the past: https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises)

I would be delighted to spend cycles combining the indices (as @david-a-wheeler says, possibly as part of one of OpenSSF's WG) but my current sense is that it would only make sense to have a single inventory if it's source-controlled, has a search interface and a taxonomy that we don't need to spend years agreeing on.

To me the biggest value would be to have serial identifiers for the supply chain breaches so we can reference them in other lines of work. That's where things start sounding NVD-like and where I think an OpenSSF-led effort might be helpful (again, as a contributor to other list of compromises, I've seen the value in having different language/artifact ecosystems weigh in, so that should remain a goal - and I'll make a point to post a link here to both the OpenSSF and CNCF supply chain WGs)

Otherwise, there's the risk of ending with a (very interesting) dump of doom which might have diminishing returns. Corollary of this is that SLSA might not need to reference every single incident to make the argument for the requirements and controls it has in v0.1. TLDR I think my current proposal reading this issue would be to graduate this issue to an OpenSSF effort, perhaps, and enable SLSA to reference incidents from such an index in future revisions of the spec(s) so that there's a common understanding of what kind of incidents are forefront in our common thinking. $self->2e-2.

[jspeed-meyers]

@bureado, I second your points and proposal. Let me know if, when, and how you think others (to include myself) can be of assistance.

[trishankatdatadog]

@bureado, I second your points and proposal. Let me know if, when, and how you think others (to include myself) can be of assistance.

Sounds good! Would both of you like to volunteer to head this?

[inferno-chromium]

I like the idea of this database becoming an openssf project (and SLSA pages can cross-link to incident which would be individual files in the newly created repo) and moving it out of repos such as https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises, https://github.com/IQTLabs/software-supply-chain-compromises
It would be nice to have each incident in a yaml format that anyone can modify/append more info to it. I like the idea of a serial identifier as well for easy cross-reference. @jspeed-meyers @bureado - do you have cycles to lead this ? we can create a project and you can start adding information there

[jspeed-meyers]

@inferno-chromium and @trishankatdatadog, I do have cycles for this project. If @bureado is willing to co-lead it with me, I am glad to pitch in! @bureado, do you have time and interest for this?

[inferno-chromium]

@david-a-wheeler - are you ok with this as well. This was discussed in WG, so i think I can create a repo ? maybe something like ossf/oss-compromises or ossf/oss-incidents or any other name recommendations ?

[bureado]

Happy to collaborate with @jspeed-meyers and @inferno-chromium on this, and OK with starting something in ossf/*.

[inferno-chromium]

@bureado @jspeed-meyers @kimsterv @david-a-wheeler - since we all agree, can you provide a repo name that you want for this project (i like ossf/oss-compromises and next one is ossf/oss-incidents). since we discussed this in supply chain wg, I will go ahead and create the repo.

[jspeed-meyers]

I like ossf/oss-compromises but am willing to consider others. What do the rest of you prefer? Thank you, @inferno-chromium for keeping this moving.

[inferno-chromium]

@jspeed-meyers @bureado - ossf/oss-compromises private repository is created and you guys are added as contributors. It is good to think of a data structure format first for both easy editing and viewing first (yaml/json/md), present some examples in WG and then migrate all of the data over from various places (we can get community help in migration part).

[jspeed-meyers]

@bureado, perhaps you and I (and any interested parties) should synchronously meet and discuss data structure options?

[jspeed-meyers]

Friendly ping, @bureado.

[bureado]

@jspeed-meyers and thanks for the ping! I contacted @inferno-chromium on the OpenSSF Slack (same alias) but happy to connect elsewhere.

[jspeed-meyers]

Ah, that works! I'll go join now and find you two.

[jspeed-meyers]

@inferno-chromium, @MarkLodato, and @david-a-wheeler, I worked on a proof of concept blog post about how SLSA can help OSS compromises. link - https://blog.chainguard.dev/slsa-vs-software-supply-chain-attacks/ If expanded, this is the type of work that I think could constitute a "how SLSA could help" analysis.

[sergiomarotco]

maleware in node-ipc
https://gist.github.com/MidSpike/f7ae3457420af78a54b38a31cc0c809c
https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/