Securing API Dependencies

January 30, 2024

Securing API Dependencies

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:

“Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability.”

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:

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.

"To reduce effort spent by users investigating non-exploitable vulnerabilities that don’t affect a software product, suppliers can issue a VEX. A VEX is an assertion about the status of a vulnerability in specific products. The status can be:

Not affected – No remediation is required regarding this vulnerability.
Affected – Actions are recommended to remediate or address this vulnerability.
Fixed – Represents that these product versions contain a fix for the vulnerability.
Under Investigation – It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release."

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.

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.

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!

By:

Todd Kendall

Manager - Demand and Delivery | Optiv

Todd Kendall is a manager for the Threat Demand and Delivery practice within Optiv services. Kendall brings over 20 years with broad-based experience in all aspects of information security management; encompassing vulnerability management, network security, penetration testing assessments, risk mitigation, and security architecture design within large corporate and government agency environments.

Kendall has been recognized for expertise in monitoring a variety of operations and infrastructures, executing security incident response programs, assessing potential risks, vulnerabilities, and threats on infrastructures in compliance with industry standards and legal policies. These efforts have brought significant contributions to the organizations I have worked for, which involved continuous process improvements, productivity enhancements, and operational excellence.

No license, express or implied, to any intellectual property or other content is granted or intended hereby.

This blog is provided to you for information purposes only. While the information contained in this site has been obtained from sources believed to be reliable, Optiv disclaims all warranties as to the accuracy, completeness or adequacy of such information.

Links to third party sites are provided for your convenience and do not constitute an endorsement by Optiv. These sites may not have the same privacy, security or accessibility standards.

Complaints / questions should be directed to Legal@optiv.com

Optiv Security: Secure greatness.^®

Optiv is the cyber advisory and solutions leader, delivering strategic and technical expertise to nearly 6,000 companies across every major industry. We partner with organizations to advise, deploy and operate complete cybersecurity programs from strategy and managed security services to risk, integration and technology solutions. With clients at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can. At Optiv, we manage cyber risk so you can secure your full potential. For more information, visit www.optiv.com.