Secure Supply Chain Consumption Framework (S2C2F)

В ноябре Microsoft разработали и опубликовали интересный фреймфорк (набор практик) безопасности опенсорсного ПО в составе корпоративных продуктов - Open Source Software (OSS) Secure Supply Chain (SSC) Framework. Чуть позже они передали этот фреймворк сообществу Open Source Security Foundation, где он был опубликован уже под именем Secure Supply Chain Consumption Framework (S2C2F).

Давайте посмотрим подробнее что там было интересного.

1. Во первых дается перечень актуальных угроз, связанных с использованием опенсорсных библиотек в продуктах, с примерами инцидентов и практик безопасности, которые помогут закрыть аналогичную проблему в вашем проекте

Эта информация будет очень полезной при корректировки модели угроз для отдельного продукта - если вы знаете какие угрозы наиболее актуальны именно для вас, можно обратить свое внимание именно на соответствующие им практики защиты.

Threats	Real examples	Mitigation via OSS SSC Framework	Framework requirement reference
Accidental vulnerabilities in OSS code or Containers that we inherit	SaltStack	Automated patching, display OSS vulnerabilities as pull requests	UPD-2, UPD-3
Intentional vulnerabilities/backdoors added to an OSS code base	phpMyAdmin	Perform proactive security review of OSS	SCA-5
A malicious actor compromises a known good OSS component and adds malicious code into the repo	ESLint incident	Ability to block ingestion via malware scan, single feed, all packages are scanned for malware prior to download	ING-3, ENF-2, SCA-4
A malicious actor creates a malicious package that is similar in name to a popular OSS component to trick developers into downloading it	Typosquatting	OSS provenance analysis, single feed, all packages are scanned for malware prior to download	AUD-1, ENF-2, SCA-4
A malicious actor compromises the compiler used by the OSS during build, adding backdoors	CCleaner	Rebuilding OSS on trusted build infrastructure ensures that packages don’t have anything injected at build time	REB-1
Dependency confusion, package substitution attacks	Dependency Confusion	Single feed, securely configure your package source mapping	ENF-1, ENF-2
An OSS component adds new dependencies that are malicious	Event-Stream incident	All packages are scanned for malware prior to download, single feed	SCA-4, ENF-2
The integrity of an OSS package is tampered after build, but before consumption	How to tamper with Electron apps	Digital signature or hash verification, SBOM validation	AUD-3, AUD-4
Upstream source can be removed or taken down which can then break builds that depend on that OSS component or container	left-pad	Use package-caching solutions, mirror a copy of OSS source code to an internal location for Business Continuity and Disaster Recovery (BCDR) scenarios	ING-2, ING-4
OSS components reach end-of-support/end-of-life and therefore don’t patch vulnerabilities	log4net CVE-2018-1285	Scan OSS to determine if it is at end-of-life	SCA-3
Vulnerability not fixed by upstream maintainer in desired timeframe	Prototype Pollution in lodash	Implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer.	FIX-1
Bad actor compromises a package manager account (e.g. npm), with no change to the corresponding open source repo, and uploads a new malicious version of a package	Ua-parser-js	OSS provenance analysis, single feed, scan OSS for malware	AUD-1, ENF-2, SCA-4

2. Во вторых в фреймворке дается детальное описание 8 групп практик безопасности, необходимых при использовании опенсорсного ПО

Все практики безопасности разделены распределены по 4-м уровням зрелости, что позволяет их внедрять поэтапно, начиная с практик 1-ого уровня зрелости.

Framework requirements
Requirement description	Framework Requirement ID	L1		L2		L3		L4
Use package managers	ING-1	+		+		+		+
Local copy of artifact	ING-2	+		+		+		+
Scan for known vulnerabilities	SCA-1	+		+		+		+
Scan for software licenses	SCA-2	+		+		+		+
Inventory OSS	INV-1	+		+		+		+
Manual OSS Updates	UPD-1	+		+		+		+
Scan for end of life	SCA-3			+		+		+
Have an incident response plan	INV-2			+		+		+
Auto OSS updates	UPD-2			+		+		+
Display vulnerabilities as comments in pull requests	UPD-3			+		+		+
Audit that developers are consuming OSS through the approved ingestion method	AUD-2			+		+		+
Validate integrity of consumed OSS	AUD-3			+		+		+
Secure package source file configuration	ENF-1			+		+		+
Deny list capability	ING-3					+		+
Clone OSS source code	ING-4					+		+
Scan for malware	SCA-4					+		+
Proactive security reviews	SCA-5					+		+
Enforce OSS provenance	AUD-1					+		+
Enforce consumption from curated feed	ENF-2					+		+
Validate the SBOMs of OSS consumed	AUD-4							+
Rebuild OSS on trusted infrastructure	REB-1							+
Digitally sign rebuilt OSS	REB-2							+
Generate SBOMs for rebuilt OSS	REB-3							+
Digitally sign produced SBOMs	REB-4							+
Implement fixes	PRI-1							+

По каждой практике есть примеры платных и опенсорсных утилит безопасности, которые помогут автоматизировать данную практику

В общем рекомендую обратить внимание на данный фреймворк, особенно на практики безопасности L1 если в вашем продукте ещё ничего не делается для обеспечения безопасности использования OSS