Unveiling Software Anatomy: A Guide to SBOMs with Amazon Inspector

Published in

Globant

11 min readMay 29, 2024

In today’s digital age, every piece of software we use is like a puzzle made of different smaller parts from various sources. A Software Bill of Materials (SBOM) is a list that tells exactly what these parts are. Think of it as an ingredient label on food packaging but for software. This list is significant because it helps us know what’s inside our daily software. Knowing what’s inside is crucial for safety, just like knowing what’s in the food we eat. If there’s something bad in the software, like a security weakness, the SBOM helps us find and fix it quickly, keeping our computers and information safe.
Sometimes, bad guys can sneak harmful things into the software that many companies use. This is called a software supply chain attack. It’s like someone putting something harmful in a part of a car that gets used in many different car brands. If this happens, it can affect not just one car but many cars across all those brands. An SBOM can help us find out where the bad part is in the software so we can fix it before it causes problems. It’s a way to check everything quickly and ensure the software is safe to use, which stops these bad guys from causing much trouble.

It’s important for everyone who makes or uses software to think about keeping the supply chain safe. This means making sure that all the parts that go into the software are safe and secure. An SBOM is a tool that helps with this. It’s not just for tech experts; it’s for anyone who cares about keeping their information and systems safe. This includes big companies, especially those that provide critical services like electricity or hospitals, but also smaller businesses and even individuals. By using an SBOM, everyone can help keep not just their stuff safe but also make the whole digital world a safer place for everyone.

Prerequisites

An AWS account.
Activate Amazon Inspector.
An EC2 instance (for the examples shown in this article, Amazon Linux 2023 was used).

Understanding SBOMs

A formal definition of SBOM by the National Telecommunications and Information Administration (NTIA) is as follows:

A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e. compile and link) a given piece of software and the supply chain relationships between them. These components can be open source or proprietary, free or paid, and widely available or restricted access.

The usage of SBOMs generally aligns with one of three viewpoints: software producers, software selectors, and software operators.

Software producers employ SBOMs as tools to aid in the creation and maintenance of the software they provide.
Software selectors or buyers utilize SBOMs for evaluating software before the acquisition, negotiating price reductions, or devising deployment plans.
Software operators leverage SBOMs for managing vulnerabilities and assets, handling licensing and compliance issues, and swiftly pinpointing dependencies and supply chain threats in the software or its components.

The manufacturer or supplier of the software is responsible for generating and updating the SBOM. Each new version of a component needs the creation of a fresh SBOM. To ensure accuracy, any modifications to components must be reflected in corresponding updates to the SBOMs.

When there are weaknesses or security gaps found in a part of the software, SBOMs help to quickly find out which software is at risk because of that faulty part. They let us see how the part is used and what kind of danger it brings. Knowing about these weaknesses lets software makers fix the problem or offer ways to fix it. It also lets users protect their software on their own, even without the software maker’s help. Plus, it helps to figure out which software doesn’t have the issue. This way, attention can be given to the software that might be in danger.

Essential Elements of an SBOM

The basic building blocks of a comprehensive SBOM, known as elements, encompass three wide-ranging, interconnected domains. These foundational elements lay the groundwork for a progressive strategy toward software transparency, encompassing both the technological aspects and the practical workings.

Data Fields: They hold essential details about each component that needs to be recorded and kept up to date. The purpose of these fields is to provide enough information to properly identify these components, allowing them to be followed throughout the software supply chain and linked to other useful data resources, like databases for vulnerabilities or licenses.

Table 1. Minimum Data Fields required by an SBOM according to NTIA

Automation Support: The integration of automation capabilities, such as the automated creation and machine-readable formats, facilitates scalability within the software ecosystem, especially when it extends over different organizational borders. To fully leverage the data provided by SBOMs, specialized tools are essential, which in turn demand consistent implementation and standardized data formats.

The data formats that are being used to generate and consume SBOMs are:

Software Package Data eXchange (SPDX)
CycloneDX
Software Identification (SWID) tags
Practices and processes: Besides the structured data of an SBOM, an organization must follow certain practices and processes that focus on how to use an SBOM. This element includes information about the frequency of the creation of an updated SBOM, the depth of the components of the SBOM, how the SBOM will be distributed, etc.

Amazon Inspector

Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS infrastructure. It is designed to assist users in identifying potential security issues within their AWS environment by automatically assessing applications for vulnerabilities or deviations from best practices.

Here are some of the most important features of Amazon Inspector:

Automated Assessments: Amazon Inspector can automatically assess AWS resources such as Amazon EC2 instances, Amazon ECR (Elastic Container Registry) images, and AWS Lambda functions for vulnerabilities and insecure configurations.
Integrated AWS Services: It integrates with other AWS services like Amazon CloudWatch Events and AWS Lambda to automate the response to findings.
Security Best Practices: The inspector checks against a library of hundreds of best practice checks and common vulnerability exposures (CVEs) to ensure that the applications are following security best practices.
Network Reachability Analysis: It can analyze network configurations to check for potentially reachable and vulnerable ports on EC2 instances.
Actionable Findings: The service provides detailed findings that include a description of the issue, its severity, and guidance on how to remediate the problem.
Continuous Monitoring: Amazon Inspector can continuously monitor your AWS resources and report any new vulnerabilities that may arise over time.
Compliance Reporting: It helps in generating reports that can be used to demonstrate compliance with various regulatory standards.

Important: Inspector Classic will be retired on December 18, 2024. Amazon Inspector has been thoroughly reengineered and revamped, emerging as a new version that supersedes the original Amazon Inspector Classic. This updated service is now accessible in various AWS Regions. With its expanded scope, the new Amazon Inspector includes support for scanning container images housed in the Amazon Elastic Container Registry (Amazon ECR), alongside its existing capability to assess EC2 instances. It also introduces multi-account support by integrating with AWS Organizations, providing continuous scans for software vulnerabilities and network accessibility, and leveraging a database of common vulnerabilities and exposures (CVEs).

Amazon Inspector supports exporting SBOMs in CycloneDX 1.4 and SPDX 2.3 compatible formats. Amazon Inspector exports SBOMs as JSON files to the Amazon S3 bucket you choose.

Amazon Inspector SBOM Generator

Besides the capability of Inspector that can generate SBOMs of EC2, Lambdas, container images, and repositories, it also provides a tool to generate them manually. The Amazon Inspector SBOM Generator (refered as Sbomgen from now on) tool is designed to create an SBOM for various entities such as archives, container images, directories, local systems, and compiled binaries.

This tool operates by identifying files that detail the installed packages. Sbomgen extracts essential data like package names, versions, and additional metadata upon locating such files. It then converts this package information into an SBOM formatted in CycloneDX.

Sbomgen offers flexibility in its use; it can function independently to produce a CycloneDX-formatted SBOM as a file or output directly to STDOUT. Additionally, it can transmit SBOMs to Amazon Inspector to facilitate the process of vulnerability detection.

For those incorporating Sbomgen into their continuous integration and continuous deployment (CI/CD) workflows, it seamlessly integrates to automatically scan container images during the deployment process.

Sbomgen collects inventory for the following package types:

Alpine APK
Debian/Ubuntu DPKG
Red Hat RPM
C#
Go
Java
Node.js
PHP
Python
Ruby
Rust

Sbomgen is compatible exclusively with Linux operating systems.

To enable Sbomgen to examine locally stored images, Docker needs to be installed on your system. However, Docker installation is not necessary for analyzing images exported as .tar files or by those stored in remote container registries.

Installation of the Sbomgen tool

Depending on the architecture of your system:

# For AMD64: 
wget https://amazon-inspector-sbomgen.s3.amazonaws.com/latest/linux/amd64/inspector-sbomgen.zip
# For ARM64:
wget https://amazon-inspector-sbomgen.s3.amazonaws.com/latest/linux/arm64/inspector-sbomgen.zip

Unzip it:

unzip inspector-sbomgen.zip

2. The binary will be in this path:

~/inspector-sbomgen-1.1.0/Linux/amd64/inspector-sbomgen

Usage Examples

$ ~/inspector-sbomgen-1.1.0/linux/amd64/inspector-sbomgen list-examples

INFO[0000] Amazon Inspector SBOM Generator v1.1.0 - linux amd64 - Copyright 2024 Amazon.com, Inc. or its affiliates. All Rights Reserved
INFO[0000] [inspector-sbomgen list-examples]
INFO[0000] writing log file to: /home/ec2-user/.inspector-sbomgen/logs/inspector-sbomgen-log_2024-04-04_17-00-41.txt
1. Generate SBOM from a container image:
   ./inspector-sbomgen container --image alpine:latest
   ./inspector-sbomgen container --image alpine@sha256:bd649691cf299c58fec56fb84a5067a915da6915897c6f846a6e317e5ff42a4d
   ./inspector-sbomgen container --image /path/to/alpine.tar
2. Generate SBOM from local system:
   ./inspector-sbomgen localhost
3. Generate SBOM from local system with optional directory:
   ./inspector-sbomgen localhost --path /path/to/directory
4. Generate SBOM from a compiled Go or Rust binary:
   ./inspector-sbomgen binary --path /path/to/binary

[snip]

Vulnerable Python Script

To test the Sbomgen tool and Amazon Inspector, let’s first create a Python script with a vulnerable version of Django. For this example, an Amazon Linux 2023 EC2 instance was used.

Create a directory to keep the code:

mkdir python-django; cd python-django

2. Create the file vulnerable_django_app.py. The code itself doesn’t matter, but the dependencies:

import django
from django.conf import settings
from django.conf.urls import url
from django.http import HttpResponse
from django.core.handlers.wsgi import WSGIHandler

# Minimal Django settings
settings.configure(
    DEBUG=True,
    SECRET_KEY='a-very-bad-secret-key',
    ROOT_URLCONF=__name__,
    ALLOWED_HOSTS=['*'],  # Allow all hosts
)

def index(request):
    return HttpResponse("Hello, Django!")

urlpatterns = [
    url(r'^$', index),
]

# Create the WSGI application
application = WSGIHandler()

if __name__ == "__main__":
    from django.core.management import execute_from_command_line
    execute_from_command_line(['manage.py', 'runserver', '0.0.0.0:8000'])

3. Create a requirements.txt file:

Django==1.11.29

4. Create a virtual env to install the needed requirements and activate it:

python3 -m venv my-python-env && source my-python-env/bin/activate

5. Install the requirements:

pip3 install -r requirements.txt

6. Now, we can generate the SBOM of the directory:

cd ..
~/inspector-sbomgen-1.1.0/linux/amd64/inspector-sbomgen directory --path python-django/ -o ~/SBOM-python-django.json

Let’s review the contents of our SBOM file:

In this output, the amazon:inspector:sbom_collector:source_pathproperty is particularly significant. It provides a clear and complete path to the location of the specific requirements (like Django, setup tools, pip, etc.) within the application’s structure.

The granularity of this information is vital for several key reasons:

Accurate Dependency Tracking: It enables swift and precise pinpointing of each dependency’s location, which is particularly beneficial for finding deeply nested dependencies that are typically challenging to track.
Improved Risk Assessment: Knowing the exact routes of dependencies allows for a more effective evaluation and mitigation of security threats linked to those dependencies.
Efficiency in Time and Resources_ This level of detail cuts down on the effort and resources required for manually tracing and analyzing dependencies, making the process of managing vulnerabilities more efficient.
Greater Clarity and Openness: It offers a more transparent view of the application’s dependency framework, leading to enhanced management and upkeep.
In-depth Package Data: Sbomgen’s comprehensive package details, such as the name, version, hashes, and package URLs, provide you with an extensive understanding of each dependency, which is crucial for accurate vulnerability tracking and confirming the integrity of the software.

Integration with Amazon Inspector

We already have the SBOM of our application that helps us identify nested dependencies, in this case, for our Python project. Now, we should verify whether these dependencies are outdated or vulnerable.

We need to create an IAM role and attach a policy to give the role and the needed permissions to send the SBOM to Amazon Inspector and scan it.

Create the following policy InspectorCICDscan-policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "inspector-scan:ScanSbom",
            "Resource": "*"
        }
    ]
}

2. In the navigation pane of the IAM console, select Roles and then select Create New Role. For the Trusted entity type, choose Custom trust policy and paste the following policy using your current account ID:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{ACCOUNT_ID}:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

3. In Add permissions, search for and select the policy created in Step 1, then choose Next. Give the role a name, for example, InspectorCICDscan-role.

Besides creating an SBOM, you have the option to scan an SBOM using just one command through the Amazon Inspector Scan API. Amazon Inspector reviews the SBOM’s contents for any vulnerabilities and then sends the results back to Sbomgen. Based on what you specify, these results can either be shown directly or saved to a file.

~/inspector-sbomgen-1.1.0/linux/amd64/inspector-sbomgen directory \
--path python-django/ \
-o ~/SBOM-SCAN-RESULTS-python-django.json \
--scan-sbom --scan-sbom-output-format inspector \
--aws-iam-role-arn arn:aws:iam::123456789012:role/InspectorCICDscan-role \
--aws-region us-east-1

In this case, the scan results are saved to a file; let’s review some sections of it:

{
  "messages": [
    {
      "info_message": "Component skipped: no rules found.",
      "purl": "pkg:pypi/pytz@2024.1"
    }
  ],
  "vulnerabilities": [
    {
      "affects": [
        {
          "fixed_version": "2.2.26",
          "installed_version": "pkg:pypi/Django@1.11.29",
          "path": "python-django/requirements.txt"
        }
      ],
      "created": "2022-01-05T00:15:07Z",
      "description": "An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.",
      "id": "CVE-2021-45115",
      "properties": {
        "cvss": [
          {
            "cvss_3_base_score": 7.5,
            "cvss_3_base_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "severity": "high",
            "source": "NVD"
          }
        ],
        "epss": 0.0022100001
      },
      "references": [
        "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B4SQG2EAF4WCI2SLRL6XRDJ3RPK3ZRDV/",
        "https://docs.djangoproject.com/en/4.0/releases/security/",
        "https://www.djangoproject.com/weblog/2022/jan/04/security-releases/",
        "https://groups.google.com/forum/",
        "https://ubuntu.com/security/notices/USN-5204-1",
        "https://access.redhat.com/errata/RHSA-2022:5498",
        "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45115",
        "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003113"
      ],
      "related": [
        "SNYK-PYTHON-DJANGO-2329160"
      ],
      "severity": "high",
      "source": "https://nvd.nist.gov/vuln/detail/CVE-2021-45115",
      "updated": "2023-11-07T03:39:49Z"
    },
....

We can review the vulnerability description, its references, the severity, and the CVE associated. At the end of the file, there is a summary of the findings:

....
  ],
  "vulnerability_count": {
    "critical": 4,
    "high": 12,
    "low": 1,
    "medium": 6,
    "other": 1
  }
}

Conclusion

The concept of a Software Bill of Materials (SBOM) is a transformative step towards enhancing software transparency and security. As we’ve explored in this article, an SBOM serves as a critical tool for stakeholders across the software lifecycle to gain insights into the components that make up their software. By providing a detailed inventory of every piece of third-party and open-source software within an application, SBOMs empower developers, operators, and consumers to make informed decisions, manage risks effectively, and respond to security threats with agility.

The integration of Amazon Inspector in the SBOM creation and scanning process further streamlines the task of vulnerability management. With the ability to generate and scan SBOMs through a single command, Amazon Inspector simplifies the complex process of identifying and addressing security issues. This level of automation saves time and ensures that the findings are accurate and actionable. The examples provided in the article demonstrate how Amazon Inspector can be a valuable asset in the continuous effort to maintain software integrity and protect against the ever-evolving landscape of cyber threats.

Ultimately, the adoption of SBOMs, coupled with robust tools like Amazon Inspector, represents a significant advancement in the field of software security. As organizations continue to embrace these practices, we can expect to see a marked improvement in the resilience of software systems against vulnerabilities.