How SBOM Plays a Key Role in CSOC

In general, 75% of codebases use open-source software, according to the 2021 Open Source Security and Risk Study report. Costs associated with development, acquisition, and maintenance as well as cybersecurity risk are dramatically increased by the absence of systemic visibility into the structure and functionality of these software solutions.

Background

The construction of a standardized information document outlining the internals and origins of software components is encouraged by security concerns in complex IT settings and supply chain integrity, and this is when SBOM comes into play. In this blog, we will talk about SBOM and how it plays a key role in CSOC and also we will show a few examples of SBOM implementation.

Software Bills Of Materials (SBOM)

A codebase’s open-source and third-party components are listed in a software Bill of Materials (SBOM). Additionally, an SBOM provides the versions of the components utilized in the codebase, their patch status, and the licenses that govern them. This information enables security teams to immediately identify any security or license problems. When a third-party vulnerability is found, SBOMs can be used to determine which software applications are most vulnerable. Software suppliers and individual application developers are responsible for creating and maintaining SBOMs. Every time a new software version is made available to the general public, a new SBOM should ideally be produced.

Role of SBOM in CSOC

The SBOM is a crucial tool for security teams in the CSOC because it helps them comprehend the parts that make up an application and spot any flaws that an attacker might exploit. Here are some ways that SBOM contributes significantly to CSOC:

• Incident Response: An accurate SBOM can aid the security team in immediately determining the scope and impact of an incident in the case of a security breach. The team can quickly address the problem by using this information to determine which components were affected and how they were affected.
• Vulnerability Management: Vulnerability management is a crucial task in a CSOC. The security team can more easily find vulnerabilities in the software supply chain thanks to SBOM’s complete catalog of all the parts that go into creating an application. Security teams can check the SBOM to see if a component is vulnerable to a known exploit, and if it is, they can take precautions to reduce the risk.
• Supply Chain Security: Understanding the provenance of each component used in an application is crucial as software supply chains become more intricate. Security teams may validate the legitimacy of each component with the use of SBOM, which can also be used to spot any potential security threats related to the supplier.
• Compliance: Software developers are required by rules in many industries to keep an exhaustive inventory of every software utilized in an application. Developers can guarantee adherence to these rules and give auditors the data they need to prove adherence by using SBOM.

SBoM standards

An SBoM standard is a schema created to offer a consistent language for expressing the composition of software in a way that other tools, like vulnerability scanners, can comprehend. A number of SBoM standards have been developed to encourage the usage of SBoMs more broadly by offering a common framework for both internally developing SBoMs and distributing them upstream to end users and consumers. Following is the list of SBOM standards:

• CycloneDX: Software security needs and associated risk analysis are specifically addressed by the SBoM specification known as CycloneDX. It is written in XML and is being developed for JSON. It has support for well-liked build systems and is made to be flexible and adaptive.
• SPDX: Software components, licenses, security details, and copyrights can all be shared across a variety of file formats thanks to the Software Package Data Exchange (SPDX), an SBoM specification. A single file, a collection of files, a piece of code, or even a single software component can all be referenced by an SPDX document. The main purpose of the SPDX project is to develop and expand a “language” to specify the data that can be exchanged as part of an SBoM and to enable the expression of that language in a variety of file formats (RDFa,.xlsx,.spdx, and soon.xml,.json, and.yaml) to facilitate the rapid collection and exchange of information about software content and packages, thereby reducing time spent and improving accuracy.
• SWID: According to the SWID standard, a SWID tag is added to an endpoint as part of the software product’s installation process and subsequently removed during the uninstall process. The existence of the software product that a certain SWID tag identifies correlates with the presence of that tag in this lifetime.

SBOM Requirements

These elements must be present in all examples of SBOMs. To provide users with more information and lessen cybersecurity dangers, many people will go above and beyond the minimal needs. Necessary data fields will provide the following:

• Supplier’s name
• Component name
• Version of the component
• Dependency relationships that show connections between components
• Unique identifier
• Timestamp
• Component hash

SBOM and SCA Tools

• Dependency Check: A tool that identifies known vulnerabilities in project dependencies and generates an SBOM in various formats.
• Dependency Track: A software composition analysis platform that includes SBOM generation, vulnerability tracking, and policy enforcement capabilities.
• GitLab DevSecOps: A suite of DevOps tools that includes a software composition analysis (SCA) feature, allowing users to generate SBOMs for their projects.
• Github: A popular code hosting platform that includes several third-party tools for generating and viewing SBOMs, such as CodeQL and Dependabot.

Dependency Track is one of the leading open-source software composition analysis platforms, it offers a comprehensive set of features that include SBOM generation, vulnerability tracking, and policy enforcement, making it an essential tool for organizations looking to improve their software supply chain security. The fact that Dependency Track is open source means that it is freely available for anyone to use and contribute to, making it a cost-effective and transparent way to manage software dependencies and ensure the security of applications.   Dependency Track’s vulnerability tracking feature enables users to identify and remediate vulnerable components in their software projects. By providing detailed information on known vulnerabilities and their severity level, Dependency Track helps users prioritize which vulnerabilities to address first.   The dashboard includes charts and graphs that offer a high-level view of the project’s overall security posture, making it an invaluable tool for software development teams.  

How is SBOM Implemented in HawkEye?

A software bill of materials (SBOM) is a list of all the components that make up a piece of software, including open source licenses and other relevant information. SBOM can provide deeper transparency into software systems, generate and verify information about code provenance and relationships between components, and help identify which components need to be updated or patched, making it essential for security. In Hawkeye, we follow an automated approach to generate a SBOM so that we can track, report and patch vulnerable softwares seen in a customer’s environment. Below is a simplified workflow that Hawkeye uses:

• Collects and generates a list of every application and third-party code library implemented in an application from all hosts in a customer’s environment. This information is placed in a database locally.
• A scheduled task is run to retrieve a list of published vulnerabilities from different vendors and the details. Below are few of the metadata for reference:
  • Package/Library Name
  • Package/Library Version
  • Architecture
  • Severity
  • CVE number
  • CVSSV2 and CVSSV3 Score
• Our scripts then compares the data synced from the vendor advisories to the list of applications/libraries seen in a customer environment and generates a report of all vulnerable applications/ libraries in the customer’s environment. This report would also have the affected package/library, fix version and the associated CVE number.
• The generated report is finally emailed to the SOC team and then to the customer’s IT team for review and patching.