Open Source Security and SBOM
CyberInsights LongReads #1
Log4shell had all of us scrambling about open source security.
We threw around buzzwords like SBOM and SCA. Then we did what we do best - pester the IT and dev teams to update their Log4j installations… and promptly forgot about it.
Synopsis released a report on open source security that can be downloaded from here. It says that 78% of code in codebases was open source and 81% of that had at least one vulnerability. What is scary is that 88% of open source code has not had an update in more than 2 years. Proof that most apps on the web rely on a very limited set of blokes maintaining and open source repo.
Protestware (making changes to popular open source libraries as a form of protest) is an attack vector that we spoke of in an earlier newsletter. Combine the two and it is enough for us to start sweating again.
What exactly is an SBOM?
According to the Minimum Elements for an SBOM document by the US department of commerce, an SBOM is defined as a formal record of details and supply chain relationships of various components used in building software:
The minimum data elements that are required for an SBOM are:
Supplier
Component Name
Version of the component
Other Unique Identifiers
Dependency Relationships
Author of SBOM Data
Timestamp
Then there are practices and processes to be implemented:
Define the operations of SBOM requests
Generation and use, including
Frequency
Depth
Known Unknowns
Distribution and Delivery
Access Control
Accommodation of mistakes
SBOM information can be exchanged in three formats:
Software Package Data eXchange (SPDX)
CycloneDX
Software Identification (SWID) tags
SBOM Maturity
It can get a little overwhelming for the practitioner to know where they are. Here is a simple matrix that we have created to help you identify where you currently are and where you want to be.
Level 1: You do not have an SBOM and you do not have documented processes for identifying vulnerabilities in your software supply chain.
Level 2: You have implemented an automated mechanism of capturing a software inventory, but lack processes to review, identify software vulnerabilities, track closures and manage the inventory.
Level 3: You have documented and practices processes for identifying vulnerabilities (in your software supply chain, not your run of the mill VA, PT & AppSec), but do not have automated SBOM
Level 4: You have an automated SBOM, documented processes that are followed with a set of people who are explicitly responsible for managing the process
Yes, we value documented and operational processes over automated solutions. Established processes provide more security than automated tools in many scenarios.
Improvements
The minimum elements for a software bill of materials (SBOM) was released in July 2021 and are available for download in pdf format here. The document emphasises that SBOM is an emerging technology and practice and this is just the start.
CyberInsights LongReads is a part of CyberInsights and delves into one topic in detail each month. If you like what you are reading, you can subscribe to get LongReads in your email. Just remember to check your spam in case you do not receive these mails.
What can we do?
You must have started on the SBOM (Software Bill of Material) after Log4Shell (on Log4j) and protestware on NodeJS. Did it lose steam?
Budget for resources to create a one time SBOM
Create a process to update the SBOM everytime new modules are written (try to incorporate it into sprint planning)
Review the list for vulnerabilities that might pop up.
Check if your SAST platforms are able to catch these vulnerable components
Manual SBOM
A manual SBOM might not be the most efficient process for getting an SBOM in place, but it will help you get started and assist you in finding or developing your own automated SBOM tool. Here is a simple template to get you started.
You can download this template from here: Manual SBOM Google Sheet
This sheet is under a Creative Commons License, so feel free to use it as you please as long as you release any derivates of this work under the same license.
SBOM Team Structure
Your SBOM team depends on the way your development team is structured.
Have one representative from the infosec team as a part of any development sprint (if you do not already have it in place). This individual should be responsible for filling / updating this template whenever any changes to the application modules are made.
For example, if your dev team has decided to add a reporting feature and they decide to use an open source module in python for generating graphs, the infosec person who is a part of the sprint will update the SBOM with the new module and identify all the relevant details. In addition to the update, the infosec team member should also be responsible for identifying any known vulnerabilities. This should be done prior to even a penetration testing exercise.
Stay Cyber Safe!
Someone you know can benefit from this LongRead? Share it.