В ноябре 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 | 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.
Блог Сергея Борисова: sborisov.blogspot.com
