Chances are your organization is using open source somewhere in your software development lifecycle, but is it secured?

You could probably name at least one major supply-chain attack in the news by now (cue Log4Shell, CodeCov, Kaseya etc…). That’s how common these attacks are getting, and the reality is that weaknesses in any part of a supply chain can introduce risk. 

In the simplest terms, an organization cannot accurately or completely manage its risk without full visibility into its supply chain. With so many moving parts, all it takes is one unidentified weakness or design flaw to create opportunities for exploit. 

Meanwhile, the use of open source and third-party software continues to expand at a rapid rate. This means that development teams are undoubtedly using open source in some capacity within your organization’s software development lifecycle. 

A zero-day vulnerability in the widely used Apache Log4j utility can allow attackers to execute arbitrary code on vulnerable servers. This demonstrated the effect that insecure open source can have on a variety of businesses, both inside and outside of the software development industry. 

Your supply chain comprises everything that touches an application or plays a role in its assembly, development and deployment. From this perspective, your supply chain also includes proprietary code and components created by your development team, APIs and cloud services employed by your software, and the infrastructure used to build and deliver that software to your end-users. 

Greg Schmidt, Senior Security Solutions Manager, Synopsys Software Integrity Group, shares the 6 questions you need to ask when tackling supply chain security:

1. Is the open source you use secure?

The prevalence of open source marks a fundamental concern when addressing supply chain security. While open source is no more or less risky than proprietary code, failure to adequately secure it introduces great risk to your organization’s overall security. Since your developers very likely use open source in nearly everything they create, this translates to large portions of your applications being composed of code that you did not write. Synopsys confirms this reality: 98% of the codebases scanned for the 2021 OSSRA report contained open source. 

A key caveat to this reality is that developers may either purposefully or inadvertently include open source in their work. It is very likely that open source finds its way into every project, oftentimes unnoticed. The same is true for the vendors you use. While this is not inherently a bad thing, it does introduce an avenue for upstream risks to find their way into your applications. It is your responsibility to track open source components, licenses, and vulnerabilities, and their associated risk, in your supply chain. Given the scale of this undertaking, manual tracking is insufficient and far too labor-intensive to maintain. 

Beyond security risks, organizations must also consider their legal risk. Often less-publicized than security risks, legal implications stemming from license violations and conflicts can easily translate to issues with mergers and acquisitions, vendor disputes, and distribution problems. As a software vendor or distributor, the legal risk stemming from supply chain weaknesses poses a threat to an organization’s reputation and financial security. 

Lastly, operational risk can be introduced when teams use outdated components, components with no recent development activity, or components from projects without a sufficient developer community to actively maintain the code. Aside from leading to code quality, reliability, and maintainability issues, operational risk is a gateway to security risk. If there are no developers finding and fixing bugs in a project, there are no developers finding, disclosing, and fixing security defects. This is especially applicable when leveraging projects with poor or unknown reputation and history. These types of projects yield low-hanging fruit for threat actors. 

2. Is the code you write secure?

Since open source represents the majority of application code, it’s no surprise that it also represents the majority of the attack surface. However, it’s still crucial to ensure that the code your developers write protects sensitive data and systems from cyber-attacks. 

Security defects and weaknesses that are inadvertently coded into applications open the door to attacks such as buffer overflows, SQL injection, and cross-site scripting. Should a system breach occur, these security defects leave sensitive data vulnerable to exposure. A threat actor could exploit these weaknesses to inject the operating system and additional systems maintained by the organization operating the software. 

3. Are you protecting yourself against deliberately inserted malicious code?

Forrester forecasted that 33% of security breaches in 2021 would be caused by insider threats. Whether it is a disgruntled developer creating a back door or a hacker who has breached a system and is mounting a larger attack, carefully placed malicious code poses significant risk to the software you build and operate. Since most malicious code is planted by someone with intimate knowledge of the software system, the vulnerable system can appear to be completely normal, making it a challenge to identify these risks using traditional tooling. 

4. Is your development and delivery infrastructure secure?

Data storage needs are growing, deployment deadlines are getting shorter, and rapid scalability has never been more important. In response, the software industry has become increasingly dependent on cloud technology to power its applications. Part of this cloud-native approach means adopting application deployment methods that support the need for scalability and agility — something that containerization and infrastructure-as-code (IaC) do well. Therefore, businesses need to have a good understanding of what software is packaged into containers, and how the cloud platforms are using infrastructure-as-code for deployment safety. 

5. Are the APIs and protocols your applications use to communicate with other systems secure?

APIs and protocols enable the quick transfer of data and services between applications and users. Despite the growing use of these methods, most organizations struggle to maintain an inventory of the APIs they operate. As a result, they have limited control over which applications and which users can access which service. 

Lack of visibility and control over APIs threatens the security of critical systems and sensitive user information. Given the opportunity, a hacker can leverage built-in flaws to carry out tasks such as crashing a critical system or perpetrating man-in-the-middle attacks — essentially eavesdropping with the end goal of stealing information like keys, passwords, login credentials, and account details that can be used to mount more significant attacks elsewhere within the supply chain. 

6. Is your software supply chain transparent to your customers and other stakeholders?

It is important to provide consumers with visibility into the contents of the application they’re procuring, so they are better able to accurately identify and mitigate security and compliance issues in a timely fashion.

Maintaining a Software Bill of Materials (SBOM) is a best practice and the cornerstone of a successful supply chain security program. Without a complete, dynamic view of what’s in your applications, neither you, your vendors, nor your consumers can confidently determine what risk you’re exposed to.