Beyond the Code / SBOM: Supply Chain Security

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.