Tag-security: [Project] Supply Chain Security Resources Catalog

[SantiagoTorres]

Description:
Creating a catalog containing software supply chain compromises, best practices and related tools for securing software supply chains.

Impact:
According to the 2019 Symantec Internet Security Threat Report, "Supply chains remained a soft target with attacks ballooning by 78 percent." The previous year's report had this number to almost triple of that, with an increase of 200% in software supply chain compromises.

creating an easy way for system administrators to learn about software supply chain compromises and what they can do to ways to mitigate threats will ultimately lead to fewer successful attacks and hopefully reverse the trend mentioned above.

Scope:
5-15 hours, including solo or team writing sessions to prepare an initial PR and respond to feedback.

We at the in-toto project already have a github repository cataloging recent compromises and providing some context. I think that we could coalesce efforts on this repository and increase its scope to also include other resources for any interested parties.

Project leader: @SantiagoTorres
SIG Chair: @ultrasaurus

Next steps: @SantiagoTorres will facilitate meeting or async work to move forward on this

[lumjjb]

This is awesome! We could probably find a way to link/embed it on the microsite once it's up too!

[TheMoxieFox]

I love this idea but have some questions and focus concerns on this:

• Whatever is done should not duplicate cve or cwe.
• How do we intend cncf projects to take advantage of this?
• Is there an expected action for their development teams to cross check supply practices against this listing?
• How do we distinguish supply chain attacks that are a result of bad practices from vulnerabilities?

[SantiagoTorres]

Hi @TheMoxieFox ! Thanks for your feedback! Some comments on it

• Whatever is done should not duplicate cve or cwe.

Yeah, this is an important point. I think we'd like to point when a CVE/CWE is tied to a supply chain security incident, although this may not always be the case (e.g., when a key is mismanaged it generally doesn't get a CVE/CWE).

• How do we intend cncf projects to take advantage of this?

I envision we will be referring to it often when we do security assessments (e.g, "have you considered incident X? How would your product react to something similar?)

• Is there an expected action for their development teams to cross check supply practices against this listing?

Hmm, I'm not sure just yet! I think it's a good idea to keep this in mind as a way to extend this project.

• How do we distinguish supply chain attacks that are a result of bad practices from vulnerabilities?

I think we need to probably extend the schema to consider something like this, and include other things such as malicious insiders and such.

[TheMoxieFox]

I'm thinking type casting various supply attacks: Config, insider, hash check fail, typo squatting, rogue library, etc. Would be beneficial.

The more I think about it, is this perhaps a mirror of the sans top 10 concept with attack examples?

Are we looking to explicitly define the bad outcome of a supply chain exploit? E.g. not checking the hash means the follow Armageddon events will trigger.

[justincormack]

I think classifying the attacks helps. I tend to not think if bad practise (eg not updating deps) as a supply chain _attack_ but judging from common use, addressing all supply chain vulnerabilities may make sense. Happy to help work on this.

[joshuagl]

This sounds great. I really like the idea of classifying attacks and discussing/linking to related tools will really help users understand how to protect their supply chains.

I'd like to help work on this.

[jonmuk]

Also interested in helping with this one as have an interest in securing supply chain and in-toto

[ultrasaurus]

thanks @TheMoxieFox for your questions and good answers from @SantiagoTorres and discussion.

I also like the idea of developing a shorthand for classifying attacks, which will help us spread knowledge via security assessments and the resource itself will be thought-provoking for anyone who is responsible for software release pipeline. As "devops" has increased, there is more opportunity for any engineer on a development team to spot potential vulnerabilities, so education in this area could have significant positive effect.

Another motivation for this that came up in the in-toto security assessment was that there are potential supply chain attacks outside of the scope of in-toto where there may be an opportunity to improve tooling. An early draft of the in-toto self-assessment had stronger pre-conditions:

Required pre-conditions:

1. CI system or buildserver is in place to package releases.
2. Written process document

We also recommend considering the following, as to whether they will be required as part of the pipeline:

1. Git (or any other VCS) commit/tag signing and verification is not in place
2. A secure software update system (e.g., TUF) is used.
3. A mechanism for distributing package metadata to the end user is available

We ended up separating the list of _recommended considerations_. I think that list may not be complete and, in particular, git commit signing is not a common workflow and would benefit from improved tooling.

I had wanted to spend more time on this, yet agreed that the topic was much broader than the in-toto assessment, so @SantiagoTorres agreed to provide the data they had gathered and his deep expertise in this area on follow-up project. It's great to read that @jonmuk @joshuagl @justincormack are interested in helping as well. :statue_of_liberty:

[ficcaglia]

of interest:
https://attack.mitre.org/techniques/T1195/

[omgclouds]

Of interest:
https://capec.mitre.org/data/definitions/437.html

[TheFoxAtWork]

of interest: https://arstechnica.com/information-technology/2019/08/the-year-long-rash-of-supply-chain-attacks-against-open-source-is-getting-worse/
Where are we at with this project?

[jonmuk]

Can we bring this up in the meeting today? I would like to work with others putting together best practice guidance.

As raised last week there may be conflict of interest concerns when we get to specific tooling but we need to find a way to work around that given the importance of the issue at hand.

[TheFoxAtWork]

I'd like to, i think there was some discussion on identifying conflict of interest for members but i cannot recall.....

[SantiagoTorres]

Hi, Sorry I missed the meeting today as I was travelling. I'll pick this up in the upcoming days once I watch the meeting and read the minute :+1:

[ultrasaurus]

@SantiagoTorres with supply chain attacks on the rise, there’s interest in focusing a meeting on this topic and (hopefully) generate some momentum on raising awareness / creating resources around this. -- proposed date: Sep 4, are you available to join the meeting? (or suggest alternate date?)

[SantiagoTorres]

Yes, I'll be there on Sept 4.

[TheFoxAtWork]

Closing this issue. Catalog is in repo and new paper also describes resources around this space.