6 Software Supply Chain Security Best Practices
Software supply chain attacks strike at the most vulnerable segment of software, the build process. It’s where software vendors, system integrators, or internal developers bring together contributions and integrations from multiple sources. A typical list of software supply chain providers includes open source software (OSS) projects, subcontractors, and third-party software vendor partners.
The shift to cloud-native applications has only exacerbated this issue as the use of containers has exploded. By using containers, developers can leverage software components from outside their organization more easily, speeding development but increasing the level of risk and the due diligence required to ensure secure and compliant software. Organizations must enhance their development processes to deliver the highest levels of security for their cloud-native applications.
The compromise of the SolarWinds attack and the Log4j vulnerability sent shock waves through business and government as everyone scrambled to secure their software supply chains. No organization can afford to sit still as we increasingly depend on software supply chains to support the development of cloud-native applications that serve their internal and external customers.
The technical and operational complexity of a software supply chain takes security risk management to a new level. The supply chain owner’s DevSecOps teams need to work with their business and technology stakeholders to improve internal processes while also extending collaboration, communications, and security best practices out to their supply chain partners.
For those looking for a complete deep dive into the topic, get a complete guide to software supply chain security here.
One thing that is evident, software supply chain attacks will remain a mounting concern for business and government agencies for the foreseeable future. There are actions you can take as a software supply chain participant to improve your security infrastructure, collaboration, communication, and processes and reduce risks for your organization and its customers. The time to start implementing the best practices outlined below is now, as there is no way to know when the next Log4j worm might appear.
Fast Fact: What is software supply chain security?
A software supply chain is all of the individual software components that make up a software application. Software supply chain security, then, is the process of finding and mitigating security weaknesses that exist from impacting the software applications that utilize the vulnerable components.
Learn more with Anchore’s complete overview of software supply chain security.
Biggest security threats to the software supply chain
The extensive use of the Log4j vulnerability and the severity of the exploit was a serious wake-up call for many security professionals and development teams around the world. Getting immediate visibility into your software supply chain risk is imperative and the fastest way to get started.
As we get ready for the long haul, be sure to prepare for the next inevitable critical issue that surfaces. Anchore Enterprise can get you ready for a quick and full assessment of a vulnerability impact, immediate controls to prevent vulnerable software application versions from moving further toward production, and streamlined remediation processes.
Here are three of the biggest security threats to be aware of today.
Development toolchains
Cloud-native applications are constructed using a number of software development tools, from source code management (SCM) to continuous integration and delivery (CI/CD) tools to container repositories. These tools may be SaaS applications or run internally, but in either case, these toolchains must be secured in order to prevent internal or external actors from attacking the development toolchain and ultimately compromising the software that is being produced.
We tend to emphasize our open source dependencies, but those dependencies and the software we write ourselves are subject to our development toolchain. Secure dependencies are meaningless if they are running through an insecure toolchain.
Insider threats
Your internal systems such as your CI/CD toolchains also face compromise by insider threats that can run the range from an employee or contractor making a mistake such as a misconfiguration that opens up your supply chain to attack to a disaffected employee or contractor can also attack the supply chain using their accounts and credentials to bypass external security measures. Such attacks can affect your organization’s managed infrastructure, your SaaS applications, and even your cloud services provider (CSP).
Monitor software behavior
Software updates can introduce risk, especially since service desks have been advised on best practices for software updates since the dawn of IT. One piece of advice dictates that IT teams should update software to the latest version and only install signed versions of updates, patches, and software that can counter such an attack. However, in the case of SolarWinds, customers received software that was signed, but compromised. In following this best practice, you just did just what the attacker wanted by installing the compromised software on your systems. There’s also the best practice of monitoring software behavior. Unfortunately, as the SolarWinds supply chain compromise shows, the attackers were stealthy and patient so that they could wreak damage on SolarWinds customers before the discovery of the compromise by an external security vendor.
The importance of best practices in securing the software supply chain
We’ve become too accustomed to the news of data breaches in our news alerts, headlines, and evening news. People outside of the technology industry are even dulling to the “breach of the week” news. While industry and government cybersecurity teams face a new onslaught of attacks every day, a software supply chain attack takes emerging threats to the next level. Conventional cybersecurity strategies can’t counter an attack against an organization’s software supply chain.
According to the Anchore 2022 Software Supply Chain Security Report, supply chain attacks impacted 62% of organizations. Such widespread attacks like SolarWinds, MIMECAST, and HAFNIUM as well as the more recent Log4j vulnerability have brought the realities of the risk associated with software supply chains to the forefront. As a result, organizations are quickly mobilizing to understand and reduce software supply chain security risk.
There’s no one solution for reducing risk, especially supply chain risk. Every organization, product, and team has its own development methodologies. All of the best practices noted below must be customized to every environment. Just as we customize our development process we must customize our supply chain risk management.
This underscores the importance of understanding your software supply chain security and implementing best practices where and when possible.
6 software supply chain security best practices
For the software supply chain owner, here are six best practices that can be implemented as potential next steps for you to improve your organization’s supply chain security. Want to automate software supply chain security? Consider adopting Anchore’s software supply chain security solutions.
1. Improve relationships and collaboration
There’s a human angle to supply chain security that’s often ignored. Relationships with your developers, supply chain partners, and even customers are integral to building trust, collaboration, and communications. Put tools and processes in place that enable your DevSecOps team to collaborate with all involved parties. Options include a federated collaboration solution that enables you to communicate and collaborate with your vendors in real time. It’s also important to share threat intelligence and best practices amongst your supply chain participants.
Pro tip from Josh Bressers, VP of Security with Anchore:
The relationships between security and development have been historically underrated, but the relationships we build are one of the most important aspects of security. A development team that doesn’t trust the security team creates slowdowns and friction for the entire DevSecOps process.
2. Improve governance of software onboarding
A major challenge in the software supply chain is that it’s nearly impossible to have any practical visibility or control over your third-party software vendors’ security and compliance practices or other partners in your supply chain. This is even more complicated when open source software is used.
It’s imperative to have an onboarding process for software components or applications that includes collaboration, communication, and security best practices. Asking suppliers questions about their security program works with a commercial relationship, but it doesn’t with open source. Make sure however supply chain components are incorporated, a realistic vetting process exists.
Pro tip from Daniel Nurmi, CTO with Anchore:
Whether your third-party software is coming from vendors who provide security reports, or from OSS projects, instituting a ‘trust but verify’ approach is good practice. There are a wealth of tools and technologies available that provide us with a way to scan a given piece of software for security flaws, that should be added to your evaluation process during functional assessment.
Pro tip from Zach Hill, Chief Architect with Anchore:
The security posture of the components that comprise your supply chain is ever evolving. Initial onboarding and evaluation processes and tooling should be repeatable as well as continuous so you can update your assessments regularly and consistently for both new components and changes to existing components.
3. Harden your build environment
The DevOps and DevSecOps communities are paying more attention to hardening their DevOps toolchains against external attacks. The Linux Foundation recommends hardening of build environments using tools such as Supply-chain Levels for Software Artifacts, or SLSA (“salsa”). It’s now time for supply chain owners to extend this discussion to the entire software supply chain.
Treat all build systems up and down your software supply chain as the critical systems that they are. Apply the same or higher security requirements to your build systems as your production system. While the Linux Foundation admits it’s not clear if such a step would’ve made a difference in the SolarWinds compromise specifically, omitting this step opens the door for malicious actors to achieve the same outcome by infiltrating your build system.
Pro tip from Daniel Nurmi, CTO with Anchore:
Attackers are always looking for the weakest / least-monitored / lowest-energy aspect of any system as an entry point for applying their influence. Systems that have historically been considered ‘internal’ (like build pipelines, pre-GA publication registries, etc) have become targets because of these reasons, but now need to be put into the same operational category as runtime production systems from a security perspective.
4. Require an SBOM for all partners and vendors
The software bill of materials (SBOM) plays a key role in defending software supply chains. Look for SBOMs to become a requirement at contract signing time for firms of all sizes aiming to join the software supply chain of a large enterprise.
The SBOM by itself isn’t the end of the story, it’s the beginning. An SBOM can provide critical data that is needed to assist with your security efforts in the future. Software supply chain owners can use the SBOM provided by their supply chain partners to conduct their own vulnerability analysis and to gain a view into their risk as new threats emerge.
Pro tip from Daniel Nurmi, CTO with Anchore:
Most security technologies start with ‘data’ or some kind, in order to provide their value, but historically have their own bespoke methods for gathering just the data they need. Instituting an SBOM management program brings a valuable foundation of data to your organization, which can serve as the basis for a variety of emerging security, compliance, and insight tooling that can be made part of your organization’s standard practices.
5. Implement defense in depth
Defense in depth (DiD) is a security design concept where multiple security control layers are placed throughout a complex IT system. Defense in depth provides redundancy through multiple layers of security so that you are still protected in the event of a security controls failure or an attacker exploits a vulnerability. For example, if you check your source code, your container image, and your running container for vulnerabilities, you’re going to get the same report from all three checks. But if an attacker exploits just one of those software development artifacts or activities, you can miss it without a multi-layered approach. However, when you have multiple security controls with overlapping functionality at different levels or with a software supply chain at stages, you’re resilient if one of them suffers a malfunction, exploit, or compromise.
Pro tip from Josh Bressers, VP of Security with Anchore:
Defense in depth means there is no one solution to reducing supply chain risk. We need to look broadly across the entire process and look for those places we can add the most value while also being the least disruptive.
6. Apply a zero trust policy
Originating in network security, Zero Trust is the concept that organizations shouldn’t trust anything inside or outside their networks, and instead should verify all systems before allowing access. Such principles are also applicable to the larger security issues that the software supply chain poses. Both public and private sector cybersecurity experts are identifying the need to apply zero trust principles to software supply chain security.
Pro tip from Zach Hill, Chief Architect with Anchore:
One of the lines between the “inside” and “outside” of a supply chain is often the approval process to introduce a new component from a 3rd party. Applying zero trust principles to that process means continuously reviewing all components in your supply chain as if each update were a new approval with the same rigor and attention as the first. Automation is critical to success in achieving such a continuous process and will enable all your components to evolve with less friction.
