Author: Jono Bergquist

Build versus buy is always a complex decision for most organizations. Typically there is a tipping point that is hit when the friction of building and running your own tooling outweighs the cost benefits of abstaining from adding yet another vendor to your SaaS bill. The signals that point to when an organization is approaching this moment varies based on the tool you’re considering.

In this blog post, we will outline some of the common signals that your organization is approaching this event for managing software supply chain risk. Whether your developers have self-adopted software development best practices like creating software bills of material (SBOMs) and now you’re drowning in an ocean of valuable but scattered security data, or you’re ready to start scaling your shift left security strategy across your entire software development life cycle, we will cover all of these scenarios and more.

Challenge Type: Scaling SBOM Management

Managing SBOMs is getting out of hand. Each day there is more SBOM data to sort and store. SBOM generation is by far the easiest capability to implement today. It’s free, extremely lightweight (low learning curve for engineers to adopt, unlike some enterprise products), and it’s fast…blazing fast! As a result of this, teams can quickly generate hundreds, thousands (even millions!) of SBOMs over the course of a fiscal year. This is great from a data security perspective but creates its own problems.

Once the friction of creating SBOMs becomes trivial, teams typically struggle with good ways to store and manage all of this new data. Just like any other context, questions arise about how long to retain data, query the data for security related issues, or even integrate all of that data with third party tooling to glean actionable security insights. Once teams have fully adopted SBOM generation in a few areas, it is a good practice to consider the best way to manage the data so your developers’ time is not in vain. 

Anchore Enterprise helps in a variety of ways, not just to manage SBOMs but to detect SBOM drift in the build process and alert security teams to changes in SBOMs so they can be assessed for risks or malicious activity.

Challenge Type: Regulatory Compliance

Let’s say that you just got a massive policy compliance mandate dropped in your lap from your manager. It’s your job to implement the parameters within the allotted deadline, and you’re not sure where to start.

As we’ve talked about in other posts, meeting compliance standards is more than a full-time job. Organizations have to make the decision to either DIY compliance or work with third parties that have expertise in specific standards. With the debut of revision 5 of NIST 800-53, the “Control Catalog”, more and more compliance standards require companies to implement controls that specifically address software supply chain security. This is due to the fact that many federal compliance standards build off of the “Control Catalog” as the source of truth for secure IT systems.

Whether it’s FedRAMP, a compliance framework related to NIST 800-53, or something as simple as a CIS benchmark, Anchore can help. The Anchore Enterprise SBOM solutions offer automated policy enforcement in your software supply chain. It serves to enforce compliance frameworks on your source code repos, images in development, and runtime Kubernetes clusters.

Challenge Type: Zero-Day Response

When a zero-day vulnerability is discovered, how do you answer the question “Am I vulnerable?” Depending on how well you have structured your security practice that question can take anywhere from an hour to a week or more. The longer that window the more risk your organization accrues. Once a zero-day incident occurs, it is very easy to spot the organizations that are prepared and those that are not. 

If you haven’t figured it out yet, the retention and centralized management of SBOM’s are probably one of the most useful tools in modern incident response plans for identification and triage of zero-day incidents impacting organizations. Even though software teams are empowered to make decentralized decision making they can still adhere to security principles that can benefit from a centralized data storage solution. This type of centralization allows organizations to answer critical questions with speed at critical moments in the life of an organization.

Anchore Enterprise helps answer the question “Am I vulnerable?” and it does it in minutes rather than days or weeks. By creating a centralized store of software supply chain data (via SBOMs) Anchore Enterprise allows organizations to quickly query this information and get back precise information on if a vulnerable package exists within the organization and exactly where to focus the remediation efforts. We also provide hands-on training that takes our customers through table top exercises in a controlled environment. By simulating a zero-day incident we test how well an organization is prepared to handle an uncontrolled threat environment and identify the gaps that could lead to extended uncertainty.

Challenge Type: Scaling a Shift Left Security Culture 

The shift left security movement was based on the principle that organizations can preempt security incidents by implementing secure development practices earlier in the software development lifecycle. The problem with this approach arises as you attempt to scale it. The more gates that you put in to catch security vulnerabilities earlier in the life cycle slows the software development process and requires more security resources.

In order to scale shift left security practices organizations will need to adopt software-based solutions to automate these checks and allow developers to self-diagnose and remediate vulnerabilities without significant intervention from the security team. The earlier in the software development process that vulnerabilities are caught the faster secure software can be shipped. 

Anchore enables organizations to scale their shift left security strategy by automating security checks at multiple points in the development life cycle. On top of that, due to the speed that Anchore can run its security scans, organizations can check every software artifact in the development pipeline without adding significant friction. Checking every deployed image during integration (CI), storage (registry) and runtime (CD) allows Anchore to scale a continuous security program that significantly reduces the potential for a vulnerable application to find its way to production where it can be exploited by a malicious adversary. The Anchore Enterprise runtime monitoring capabilities allow you to see what is running in your environment, detect issues within those images, and prevent images that fail policy checks from being deployed in your cluster or runtime environment.

Wrap-Up

The landscape of software supply chain security is increasingly complex, underscored by the rapid proliferation of SBOMs, rising compliance standards, and evolving security threats. Organizations today face the dilemma of scaling in-house security tools or seeking more streamlined and comprehensive solutions. As highlighted in this post, many of the above signals might indicate that it’s time for your organization to transition from DIY methods to a more robust solution. 

Anchore Enterprise was developed to overcome the challenges that are most common to organizations. With its focus on aiding organizations in scaling their shift-left security strategies, Anchore not only ensures compliance but also facilitates faster and safer software deployment. Even though each organization has its own set of unique challenges pertaining to software supply chain security, Anchore Enterprise is ready to enable organizations to mitigate and respond to these challenges.

If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists.

Software serves as a powerful tool that simplifies complex and technical concepts but with the incredible power of software comes an interconnected labyrinth of software dependencies that often form the foundation for innovative applications. These dependencies are not without their pitfalls, as we’ve learned from incidents like Log4Shell. As we try to navigate the ever-evolving landscape of software supply chain security, we need to ensure that our applications are built on strong foundations.

In this blog post, we delve into the concept of a Software Bill of Materials (SBOM) as a foundational requirement for a secure software supply chain. Just as a physical supply chain is scrutinized to ensure the quality and safety of a product, a software supply chain also requires critical evaluation. What’s at stake isn’t just the functionality of an application, but the security of information that the application has access to. Let’s dive into the world of software supply chains and explore how SBOMs could serve as the bedrock for a more resilient future in software development and security.

What are Software Supply Chain Attacks?

Supply chain attacks are malicious strikes that target the suppliers of components of an application rather than the application itself. Software supply chains are similar to physical supply chains. When you purchase an iPhone all you see is the finished product. Behind the final product is a complex web of component suppliers that are then assembled together to produce an iPhone. Displays and camera lenses from a Japanese company, CPUs from Arizona, modems from San Diego, lithium ion batteries from a Canadian mine; all of these pieces come together in a Shenzhen assembly plant to create a final product that is then shipped straight to your door.

In the same way that an attacker could target one of the iPhone suppliers to modify a component before the iPhone is assembled, a software supply chain threat actor could do the same but target an open source package that is then built into a commercial application. This is a problem when 70-90% of modern applications are built utilizing open source software components. GIven this the supply chain is only as secure as its weakest link. The image below of the iceberg has become a somewhat overused meme of software supply chain security but it has become overused precisely because it explains the situation so well.

Below is the same idea but without the floating ice analogy. Each layer is another layer of abstraction that is far removed from “Your App”. All of these dependencies give your software developers the superpower to build extremely complex applications, very quickly but with the unintentional side-effect that they cannot possibly understand all of the ingredients that are coming together.

This gives adversaries their opening. A single compromised package allows attackers to manipulate all of the packages “downstream” of their entrypoint.

This reality was viscerally felt by the software industry (and all industries that rely on the software industry, meaning all industries) during the Log4j incident.

Log4Shell Impact

Log4Shell is the poster child for the importance of software supply chain security. We’re not going to go deep on the vulnerability in this post. We have actually done this in a number of other posts. Instead we’re going to focus on the impact of the incident for organizations that had instances of Log4j in their applications and what they had to go through in order to remediate this vulnerability.

First let’s brush up on the timeline:

The vulnerability in log4j was originally privately disclosed on November 24. Five days later a pull request was published to close the vulnerability and a week after that the new package was released. The official public disclosure happened on December 10. This is when the mayhem began and companies began the work of determining whether they were vulnerable and figuring out how to remediate the vulnerability.

On average, impacted individuals spent ~90 hours dealing with the Log4j incident. Roughly 20% of that time was spent identifying where the log4j package was deployed into an application. 

From conversations with our customers and prospects the primary culprit for why this took up such a large portion of time was whether or not an organization had a central repository of metadata about the software dependencies that had been utilized in building their applications. For customers that did have a central repository and a way to query this database, the step of identifying which applications had the log4j vulnerability present took 1-2 hours instead of 20+ hours as seen with the other organizations. This is the power of having SBOMs in place for all of the software and a tool to help with SBOM management.

What is a Software Bill of Materials?

Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that go into the software that your applications consume. We normally think of SBOMs as an artifact of the development process. As a developer is manufacturing their application using different dependencies they are also building a recipe based on the ingredients. In reality, an SBOM can (and should) be generated at all steps of the build pipeline. Source, builds, images, and production software can all be used to generate an SBOM.

Similar to Maslow’s hierarchy of needs, software supply chain management has an analogous hierarchy of needs. 

At the base of the pyramid are the contents of the application, in other words, SBOMs about the application. The diagram below shows all of the layers of the proposed hierarchy of software supply chains.

By using an SBOM as the foundation of the pyramid, organizations can ensure that all of the additional security features they layer on to this foundation will stand the test of time. We can only know that our software is free from known vulnerabilities if we have confidence in the process that was used to generate the “ingredients” label. Signing software to prove that a package hasn’t been tampered with is only valid if the signed software is both free of known vulnerabilities. Signing a vulnerabile package or image only proves that software hasn’t been tampered with from that point forward. It can’t look back retrospectively and validate that the packages that came before are secure without the help of an SBOM or a vulnerability scanner.

What are the Benefits of this Approach?

Utilizing Software Bills of Materials (SBOMs) as the foundational element of software supply chain security brings several substantial benefits:

1. Transparency: SBOMs provide a comprehensive view of all the components used in an application. They reveal the ‘ingredients’ that make up the software, enabling teams to understand the entire composition of their applications, including all dependencies. No more black box dependencies and the associated risk that comes with it.

2. Risk Management: With the transparency provided by SBOMs, organizations can identify potential security risks within the components of their software and address them proactively. This includes detecting vulnerabilities in dependencies or third-party components. SBOMs allow organizations to standardize their software supply chain which allows for an automated approach to vulnerability management and impacts risk management.

3. Quick Response to Vulnerabilities: When a new vulnerability is discovered in a component used within the software, SBOMs can help quickly identify all affected applications. This significantly reduces the time taken to respond and remediate these vulnerabilities, minimizing potential damages. When an incident occurs, NOT if, an organization is able to rapidly respond to the breach and limit the impact. 

4. Regulatory Compliance: Regulations and standards are increasingly requiring SBOMs for demonstrating software integrity. By incorporating SBOMs, organizations can ensure they meet these cybersecurity compliance requirements. Especially when working with highly regulated industries like the federal government, financial services and healthcare.

5. Trust and Verification: SBOMs facilitate trust and confidence in software products by allowing users to verify the components used. They serve as a ‘proof of integrity’ to customers, partners, and regulators, showcasing the organization’s commitment to security. They also enable higher level security abstractions like signed images or source code to inherit the underlying foundation security guarantees provided by SBOMs.

By putting SBOMs at the base of software supply chain security, organizations can build a robust structure that’s secure, resilient, and efficient.

Building on a Strong Foundation

The utilization of Software Bills of Materials (SBOMs) as the bedrock for secure software supply chains provides a fundamental shift towards increased transparency, improved risk management, quicker responses to vulnerabilities, heightened regulatory compliance, and stronger trust in software products. By unraveling the complex labyrinth of dependencies in software applications, SBOMs offer the necessary insight to identify and address potential weaknesses, thus creating a resilient structure capable of withstanding potential security threats. In the face of incidents like Log4Shell, the industry needs to adopt a proactive and strategic approach, emphasizing the creation of a secure foundation that can stand the test of time. By elevating the role of SBOMs, we are taking a crucial step towards a future of software development and security that is not only innovative but also secure, trustworthy, and efficient. In the realm of software supply chain security, the adage “knowing is half the battle” couldn’t be more accurate. SBOMs provide that knowledge and, as such, are an indispensable cornerstone of a comprehensive security strategy.

If you’re interested in learning about how to integrate SBOMs into your software supply chain the Anchore team of supply chain security specialists are ready and willing to discuss.