Beyond the Code / SBOM: Supply Chain Security
A presentation at Bsides London in in London, UK by Anant Shrivastava
Beyond the Code / SBOM Supply Chain Security
Anant Shrivastava ● Chief researcher @ Cyfinoid Research ● 15+ yrs of corporate exposure ● Speaker / Trainer: BlackHat, c0c0n, nullcon, RootConf, RuxCon ● Project Lead: ● ○ Code Vigilant (Code Review Project) ○ Hacking Archives of India, ○ TamerPlatform (Android Security) (@anantshri on social platforms) https://anantshri.info
Supply chain
It’s a chain like any other chain Producers (3rd Party Lib Maker) Access 3rd party components created Store Consumers (software developers) Download / Use Software Store Infrastructure Provider Download End User Customers
Software Supply chain Development Environment Code Repository CI / CD Pipelines Dependencies Container Environments Runtime / Cloud Environments
What can go wrong Quick History Lesson
First Reference (found so far) Ref: https://seclab.cs.ucdavis.edu/projects/history/papers/karg74.pdf and https://research.swtch.com/nih
Is it re-newed: lets Check OWASP • OWASP Top 10 : 2021 : A06 : Vulnerable and outdated Components • OWASP Top 10 : 2017 : A09 : Using Components of Known Vulnerability • OWASP Top 10 : 2013 : A09 : Using Known Vulnerable Components • OWASP Top 10 : 2010 : A06 : Security Misconfiguration • OWASP Top 10 : 2007 : MISSING • OWASP Top 10 : 2004 : A10 : Insecure Config Management
So, what do we know 1. It’s a known problem for many decades 2. So, what changed recently that it become a big thing
Events Incidences • SolarWind • CodeCov • Colonial Pipeline Resultant • EO by US President • NIST SSDF Framework • SLSA by google
Industry and buzz word brigade • Software Bill of Material : Ledger of ingredients • Provenance : Proof of authenticity of documents (namely sbom)
Funny thought Most of the times software industry is fixing problems, that are created by software industry
What problems have we created • Software build automation == quicker release cycle • Automated release cycle == less wait for features • Faster feature release == less inclination to upgrade dependencies • Too much focus on OSS Codebase without helping the maintainers • Impossible segregation of features and bug fixes • Automated notification of vulnerability (hedonic hamster wheel)
Example • Just to clarify they are not wrong in their assumption. • I am giving example of where we are, not what’s right or wrong.
Business So, the industry now is in the business of: • Finding and reporting as many 3rd party dependency issues as possible • Creating inventory • Validating inventory signatures • & Feeling good about ourselves that we have saved the city
SBoM (Software Bill of Material)
NIST Cyber Security Framework 1.1 • Identify : Know your assets • Protect: Establish Baseline protection • Detect : Identify attacks • Respond : evict, monitor or respond • Recover : Get back on feet
Software Bill of Material • Itemized list of all the ingredients in the software • Ingredients means mostly third-party components • • • • • Software name Version Checksum License information Dependencies list if possible • SBoM’s are mostly for one level depth only with other levels plugged in each others.
What does it miss? • Compiler used • ML models in use • SaaS services used • Operating environment (OS etc) • And much more • Shout to OWASP CycloneDX project they are doing some good work
SBoM can help • Identifying incorrect use of software • Identify what to fix in scenarios like log4shell • Identify impact in sec bug release in a core component • Basically, Inventory problems Ref: XKCD.com/2347
SBoM can’t help • Identify codecov incidence (creds from docker image) • Identify solarwind instance (build system hacked) • Anything not dealing with third party code inventory • It can’t spot if the bug is actually in use in your code
SBoM the Holy Grail • Its not the be all, end all solution. • IT’S the good first step. • One thing that this industry failed all the time.
Has the world done nothing so far • There are two approaches taken before 2021 around this. • Centralized approach (vetted software) • Central body takes care of security for packages • Debian or linux distro’s • De-Centralized Approach (isolated software) • Dev’s maintain their own setup but isolate from system • Python venv • Homebrew (to some extent) • Npm
Vetting Software • Software gets vetted by the team of dedicated volunteer’s • Volunteer’s take ownership of keeping up with software • All updates are marked as feature or security. • Separate branches maintained to handle feature or bug fix • Stability over new features
Vetted Software approach Pro’s • Single authority tracking bugs • Stability over new features • Volunteers have deeper understanding of software • Centralized upgrade Con’s • Limited tracking capability • Features don’t reach end user • Delay in case volunteer is unavailable
Isolated Software Approach • End users or consumers directly use the software’s. • Faster and quicker upgrades • but more importantly controlled upgrades • Software Isolated in environment to not conflict with base items
Isolated approach Pro’s • Dev’s have full control of package versions • Packages localized so different project can work on different version of packages Con’s • In a log4jam or log4shell scenario • No centralized update so security fix push is hard
Modern Problem : Modern Solutions • After decades of software development, we now have • Infrastructure as code • Better cryptographic standards • Hardware, software and storage capabilities to maintain provenances
Provenance • The proof of authenticity of the document • Let me explain in negative • If a software download link is for example.com domain • The checksum of the downloadable file is stored at example.com domain • Is it safe?
Provenance • Ideally the provenance record and or document should be kept in two different places. • At the very least the signing should be done in such a way that third party needs to be called to change anything
So, what can we do? Enough of discussion where do we go from here • Frameworks • Tooling
Frameworks • SLSA Framework is a good approach for producers and consumers • Cyber Security Framework v2 has govern section for end users and consumers • SSDF: is guideline for all software developers (producers and consumers)
SLSA Framework • • • • • Effort by google to create a framework Different levels to represent current maturity levels Started with a lot of ambition in v0.1 With v1.0 toned down to level Level 4 for future edition SLSA is nontransitive : Only assurance of current software not its transitive dependencies
SLSA Framework
SLSA Levels
NIST SSDF Framework SSDF consists of following 4 section • Prepare the Organization (PO): people, processes, and technology are prepared to perform secure software development at the organization level. • Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access. • Produce Well-Secured Software (PW): Organizations should produce well-secured software with minimal security vulnerabilities in its releases. • Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.
Tooling • https://github.com/ossf/scorecard : OSS health check • https://www.sigstore.dev/ : Distribution signing • https://github.com/sigstore/cosign : container Signing • https://github.com/safedep/vet : Org level package vetting + rules • https://stacklok.com/ : VSCode plugin health check + alternative
Questions for Vendors • What do I do with SBoM? • If you report bugs, do you report based on reachability analysis (can you test it) • Do you have alternative suggestions for the vulnerable library.
Supply Chain security is the new buzzword of the town and everyone is gaga about it. After the executive order and SSDF / SLSA documents being released, every single vendor has added SBOM capabilities and declared the problem solved. The problem is its not solved, Supply chain security is not a new problem and sbom is not the final solution. This talk wants to throw lights on supply chain security overview and then address following points.
- How supply chain security is a age old concept.
- What has changed in last few year and how that affects this problem space
- At a broader level how SLSA / SSDF are trying to address the problem.
- What is still missing in market and what is needed to be done beyond buying tools.
We will start by exploring how software supply chain problems have existed in past already, We will then talk about sbom’s what they really are and what they can do. we then focus on the shortcomings of the formats and especially where gaps occur (for example the place to record which compiler version was used to compile the code). After we have looked at sbom we will explore different scenarios where current sbom would not have helped in any ways (this includes solarwind if you are wondering) We then explore how different bodies have attempted to tackle it from npm’s trying to isolate packages, to debian trying to control central repositories, pros and cons on each side. We will then focus on how paradigm shift such as IaC and provinence tools could be of help what they can do and can’t do. we will then conclude the talk around SSDF / SLSA as frameworks to start tackling the problems but also to give people a clear idea where tooling can help and where policies and process would be helpful.
This talk is especially useful for practitioners who want to understand what is going on and how to start looking at these frameworks to put some protection in the environment.
