This first blog post of the API security series addressed discovery, or the ability for an organization to identify which APIs are present and where they are hosted. The second post covered how a proper API inventory can reduce redundant development costs by identifying duplicate API functionality. The third post focused on the profile, where you need to classify API usage, exposure, data and compliance. For the final blog post, I will address maintenance and dependencies that can impact the API and ultimately you as the owner.

There are two areas I will focus on for the dependency check of APIs. The first was issued to the government for Federal Information Systems based the “Executive Order on Improving the Nation’s Cybersecurity” released in May 2021. The Executive Order requires a Software Bill of Materials (SBOM) for each product or a published list on a public website. Here is a key quote from the Executive Order:

The second area also deals with compliance. Version 4.0 of the Payment Card Industry Data Security Standard (PCI DSS) has a phased approach for March 31, 2024 and March 31, 2025. Requirement 6.3.2 requires that organizations address vulnerability and patch management. Organizations must now identify and list all their custom and bespoke software, including any third-party software that has been incorporated into the organization's bespoke and custom software. This requirement speaks directly to the SBOM. An SBOM does speak directly to the application. But based on open-source code or libraries used, organizations will need to address any discoverable vulnerabilities within the API.

API Review

Microsoft initially addressed the SBOM issue back in 2021 with the Software Package Data Exchange (SPDX), as they generate approximately 500,000 builds daily. You can find more recent information on the Microsoft SBOM tool on GitHub. The tool digitally signs each SBOM to protect its integrity, as well as creates a new folder at the root of the build. This is where the SPDX JSON file is stored. See an example JSON file below:

Image

Figure 1: Sample SPDX JSON file where the SBOM is stored

You can validate the hashes of all files listed in the SBOM against the hashes of the build drop itself and validate that the digital signature on the SBOM is the trusted signature from Microsoft. If the validation tool detects a hash mismatch or incorrect signature, deployment will be blocked.

The reports were designed off guidelines from the National Telecommunications and Information Administration (NTIA), who has advanced the SBOM since 2018. The Cybersecurity and Infrastructure Security Agency (CISA) has also generated community effort dealing with development, scaling and operationalization, tools, new technologies and use cases. CISA has provided facilitation guidance around four workstreams to drive this effort. One of these efforts deals with Vulnerability-Exploitability eXchange (VEX). Here is a key quote from VEX and see the Vulnerability Exploitability eXchange (VEX) workstream in the link provided for more details.

You can review the SBOM or VEX for potential vulnerabilities that will need to have maintenance or be upgraded. There are free tools available for checking the SBOM, or you can utilize Software Composition Analysis (SCA) tools.

When creating an SBOM, keep in mind that a lot of information is available for review against applications. For years, development groups and security communities have leveraged tools like Checkmarx, Veracode and Snyk for software assessments and composition analysis. We will look at the Checkmarx SCA device and an additional tool that Snyk provides called the SBOM security checker.

Checkmarx SCA allows you to review your code and determine risks within the package. Below is an example of a Checkmarx scan report, which identified and flagged the presence of the Log4j vulnerability.

Image

Figure 2: Checkmarx SCA scan

Additionally, Snyk’s SBOM security checker is a free tool that allows you to check the SBOM, as shown below.

Image

Figure 3: SNYK SBOM security check results

Concluding Takeaways

Information provided across this series will hopefully allow you to begin securing your APIs within your environment and give you support on key areas. There are multiple issues that you need to consider, but there are also multiple commercial and free tools that you can rely on to discover, inventory, profile and ensure dependency checks. Thank you for the time and interest in the API resource material that I have provided, and look forward to a secure year!