How to Secure Your Software Supply Chain in 10 Steps

A software supply chain is the list of components, libraries, and tools used to build a software application. Software vendors often create products by assembling open-source and commercial software components. A software bill of materials (SBOM) declares the component parts of most of this supply chain. The software supply chain is an ecosystem just like any other supply chain. Some resources are consumed, then transformed, through a series of steps and processes, and finally supplied as a product or service to a customer. With applications being core to most modern businesses, the software supply chain is a frequent target of attackers. Software supply chain security is a critical aspect of securing your applications.

The software supply chain refers to all components directly involved in developing an application. It includes three different segments:

1. Gathering of raw resources, including:

   1. Source Code Management systems (SCMs), testing suites, and CI/CD tools 

   2.  Compilers and editors 

   3. Drivers and dependencies 

   4. Open-source scripts and packaged software 

   5. Cloud services and data centers. 

2. Transformation of resources through development processes:

   1. External libraries, which are used as part of the compilation

   2. Third-party packages

   3. Consumed information being provided by third-party services

3. The finished product is supplied to the customer:

   1. Web application

   2. Streaming service

   3. Distributed operating system

Thus, building secure software relies on every element in the supply chain and the DevOps process being secure.

Why You Should Consider Security At Every Step in the SDLC

In today’s age of constant breaches, hacks, and attacks, there’s never been a better time to focus on securing your software supply chain. Over the years, software has become more susceptible to attacks because of the increasing amount of open-source dependencies combined with rapid iterations and CI/CD processes that often prioritize speed over secure software development. Software supply chain risks are inherited from dependencies that are introduced into the SDLC without proper checks in place. That’s why you should be embedding security protocols into every phase of the SDLC and software pipeline.

Secure software relies on the concept that your software is only as secure as the weakest link in your software supply chain. The more dependencies you have means that more security researchers - some malicious - are looking for vulnerabilities to exploit in your project. Open source software security risks are increasing over time (as you can see from this graph). More and more software security vulnerabilities are being found and 2022’s trajectory is at an all-time high in all severity types. Log4shell has proven the massive impact just one vulnerability in one project can have on the software industry as a whole, where over 40% of corporate networks worldwide were coming under attack. And many organizations have fallen behind in planning for and implementing software supply chain security best practices.

10 Steps to Securing Your Software Supply Chain

Thinking about how to protect code first requires a non-trivial, complete understanding of what makes up an organization’s code. Software supply chain security is a process that requires multiple ongoing steps. This starts with the gaining knowledge of what needs protection, which preventative measures to follow, and to take a detailed assessment of resources and their risks. Understanding where your software supply chain risk is coming from and putting a plan in place takes time, but is well worth the effort in the long run.

This list is by no means comprehensive, and there is always more that you can do to secure your software supply chain as you mature, but these 10 steps should help immature software supply chain maturity programs build security into every phase of the SDLC and ensure a base level of software supply chain security. This list may evolve, but adapting your program in the future will be easier than starting from scratch, or responding in an emergency fashion following a breach.

Step 1: Evaluate Your Pipeline Build

As previously stated, the first step of security is evaluating the components that need to be protected. Every software deployed in today’s continuous software release framework will have a pipeline containing multiple raw materials connected. Even building the most straightforward app will require a multi-step pipeline, starting with base libraries you’ve included in your source code, 3rd-party packages you’ve been using, and compiler for the transformation to deployment. Also, your build scripts, YAML files and the effect of running it on the SCM (Source Code Management system), testing suite and build logs, operating system, binary artifact repository manager, etc.

Software supply chain attacks can target these components, causing total corruption of your software supply chain security model. To fully understand your pipeline, it is recommended to map your entire pipeline - identify all entry points and all of the connections between them to assess the risk vectors possibly allowing attacks on your software supply chain. If possible, a centralized repository that can store this information and provide relevant visualizations of your SDLC pipeline can expedite your understanding.

Step 2: Eliminate Workarounds & Bypasses

Sometimes, we are our own worst enemy. This happens when internal members develop workarounds, and bypass security controls implemented to keep the software supply chain secure. Rushed development can cause undesirable security consequences. For example, you might be using the SLSA framework but not enforcing it fully. Imagine a scenario where a developer is under time pressure for deploying a feature, which makes the developer want to avoid a critical source requirement, like a Two-person review because the other developers charged with reviewing his/her code for the code review step not available. This could cause the pull request opener, for instance, to use a bot or a developer not familiar with the project as the reviewer, just to auto-approve.

Another example is the bypassing of security tests to speed up the development process. For example, if the security tests take a long time, it can cause the deployment team to skip the very time-consuming security tests. This exposes the business to unnecessary supply chain risks. But this is also a reality in today's CI/CD environments where the development teams are continuously being pressed to innovate.

Time pressure can be listed as a primary cause for skirting security practices, but laziness, ignorance, or negligence can also be a factor. Regardless of the reason, cutting corners can significantly raise your software supply chain risk.

Software supply chain management is about creating secure controls and fully enforcing them in a way that aligns to development workflows. Ideally this can be done in a way that doesn't interrupt their progress.

Step 3: Use Automated Tools to Your Advantage

Any time there’s a manual component to a security step, there’s increased risk. That can be due to human error, slower response, or simple failure to execute. That’s why using automated tools to enhance the security of your software pipeline is essential to keeping things locked down. Automation can be faster, more consistent, and won't be accidentally overlooked. To better enforce your software supply chain management policy, here is a list of recommended software security tools:

• SAST - Static Application Security Testing means analyzing program source code to identify security vulnerabilities. These vulnerabilities include SQL injection, buffer overflows, XML external entity (XXE) attacks, and other security risks. OWASP is maintaining a list of up-to-date Top 10 security risks. There are many commercial SAST tools available on the market.

• SCA - Software Composition Analysis (SCA) is a category of tools that analyze and manage the open-source elements of your applications. Organizations and developers use SCA tools to verify licensing and assess vulnerabilities associated with their applications’ open-source components. SCA tools analyze the composition of an app either from source code or from binary and match it with their database of known information such as license, open vulnerabilities, and more. The “Log4Shell” incident is an example of a vulnerability in a common open-source library where SCA tools can help detect where this library is being used across all applications. Understanding how these open source vulnerabilities can impact your applications is a key component of effective software supply chain management.

• DAST - Dynamic Application Security Testing is a testing method to evaluate a software application. DAST testing simulates the actions of a malicious actor trying to break into an application remotely. DAST tools scan software applications in real-time against leading vulnerabilities, like the OWASP Top 10 or SANS/CWE 25, to find security flaws or open vulnerabilities. DAST tools are also associated with API security since the standard way for a DAST tool to interact with an application is by testing its APIs. While DAST solutions are necessary for comprehensive application security, ideally you can shift your security program left to detect vulnerabilities earlier in the SDLC and minimize risk to your production environment.

Unfortunately, these tools are unaware of their placement in your software supply chain. Your SAST scanner, for example, is unable to inform you of which repositories you should be scanning but isn't. 

Step 4: Understand Your Pipeline Infrastructure

Understanding your pipeline infrastructure is a vital part of optimizing DevSecOps. To incorporate security controls and software supply chain tools effectively, you need to ensure your infrastructure is free from contradicting permissions logic within your pipeline. For example, imagine this permissions breach scenario:

• user A has read/write permission to repo B and should not have access to repo C.
• Everyone up to that point who had read/write permissions to repo B also had read permissions to repo C
• So, the DevOps team created a permissions group that everyone with read/write permissions to repo B would have read to repo C, which was logically contradicting the pipeline infrastructure, causing user A forbidden and unintended access to repo C.

When thinking about software security vulnerabilities, don't forget to think about less obvious supply chain vulnerabilities, such as the pipeline itself, which can be the target of an attack. When this happens, all other security controls are provide no protection. Determine who has the root access to your pipeline, then modify privileges to secure it and only give access to those who need it. Failure to control access to your SLDC pipeline is a critical process failure and can be a major threat to your overall software supply chain security.

Step 5: Establish Hygiene & Container Method Protocols

In the software supply chain, multiple components are connected. One must use a high level of management and separation to reach a high security level, avoiding staining one resource with the other obtained by containers. The role of containers is growing, turning the building, testing, and running applications across various environments faster and more efficiently. As containers have grown in popularity, so too has the realization that we need to find solutions to keeping the code within them secure from vulnerabilities.

Threats can be unknowingly introduced to the software supply chain through several methods like the ingestion of vulnerable components or the tampering with supply chain by negligent/rogue actors. 

Understanding how to protect code doesn't do much if you fail to take the right steps to protect your software supply chain. To ensure good code hygiene, you should mandate vulnerability scanning and only use known components (i.e. don't use suspicious third-party packages).

Step 6: Go Beyond the Minimum Safety Requirements

The minimum safety requirements created by NIST are about six key components:

1. Threat modeling - Threat modeling methods create an abstraction of the system, profiles of potential attackers and their goals and strategies, and a catalog of potential threats. Threat modeling can identify design-level security issues and help focus verification. Visualization can help to improve threat modeling efficacy.

2. Automated testing - Automated testing can run tests consistently, check results accurately, and minimize the need for human effort and expertise. Automated testing can be integrated into the existing workflow or issue tracking system. Automation also takes over repetitive and boring tasks, allowing developers and security professionals to focus on more interesting, higher skilled work.

3. Code-based (static) analysis - Static analysis tools can check code for many kinds of vulnerabilities and compliance with the organization’s coding standards. Use a scanner capable of detecting race conditions for multi-threaded or parallel processing software.

4. Dynamic analysis (i.e., run the program on test cases)

   1. Run with built-in checks and protections.

   2. Create “black box” test cases.

   3. Create code-based structural test cases.

   4. Use test cases created to catch previous bugs.

   5. Run a fuzzer.

   6. If the software might be connected to the Internet, run a web app scanner.

5. Check included software - Use the verification techniques recommended in this section to ensure that included code is at least as secure as code developed locally. The components of your software must be continually monitored against databases of known vulnerabilities; a new vulnerability in existing code may be reported at any time. Failure to check 3rd party dependencies leaves a critical gap in your software supply chain security.

6. Fix bugs - Correct critical bugs as soon as possible and make process improvements necessary to prevent such bugs in the future or to at least catch them earlier in the development process. Shift left to fix bugs and vulnerabilities earlier in the SDLC and stop threats sooner.

Ignoring some of these points is a sure path to security breaches. All points are important in the sense that they evaluate risks, find vulnerabilities, and fix security breaches through time - but they are not enough. In regards to software supply chain security, it is crucial to be alert, map your pipeline, understand your infrastructure and try to layer your security for ensuring one breach doesn't affect the entire software supply chain. This will significantly lower the overall risk to your mission critical applications.

Step 7: Monitor Privileges & Secure Access Management

Once an attacker has gained initial access to your pipeline it’s much easier for them to move laterally between accounts. Then, it’s only a matter of time before they find the privileged account that they need to deal a devastating blow. Always apply the principle of least privilege across all networked accounts. Grant/revoke elevated access whenever necessary/possible. Continuously keep an eye on privileged account activity. Use automation whenever possible to help monitor activity for you. Continuous monitoring of your software supply chain is a critical component of ensuring that your application security posture is effective.

Secure software is about two key concepts: prevention and risk mitigation. Even though prevention is ideal, it’s not always possible to prevent all threats, and sometimes, the only solution available is to reduce the possible damage of threats. To do so, ensure you are monitoring your pipelines and able to make dynamic decisions quickly to reduce the possible damage. The more you know sooner, the faster you can respond to critical threats to your software supply chain.

Step 8: Only Work with Trusted Partners

Partners have more knowledge and ability to compromise your project than an outside attacker unfamiliar with your business. A software supply chain attack is an easy task for a trusted partner who is able to compromise your project from the inside and has a deep understanding of your security flaws before you can fix them. Ideally they can provide a software bill of material (SBOM) for any software they provide that may make it into your software supply chain.

Before jumping into a project with a new partner, assessing them on a handful of criteria is essential:

• Credibility

• Service history

• Past projects

• Market reputation

• Certifications

• ISO 27001

Also, here are a few measures that can be taken to assess the risk of possible bad intentions:

• Background checks

• Criminal records

• Bankruptcy filings

Step 9: Keep an Eye on Third Parties

Most of the code in your software supply chain is not a code you wrote – it is code from a third party. This has many advantages - using third parties saves a lot of time, and when used correctly, can reduce bugs and security risks. Nevertheless, open-source software security risks are prevalent. When you use a bad third party, you create a data breach that is very difficult to detect.

Vendor data breaches aren’t just a threat to your suppliers; they’re also a threat to you if they’re an integral part of your software supply chain. There are ways to monitor third parties:

• Request/inspect supplier’s security documentation.

• Request data breach history

• Monitor for credentials exposed on the dark web

• Request an SBOM for any software that they provide

Step 10: Establish an Incident Response Plan

Even with strong software supply chain security you need to be prepared for the worst-case scenario. Be prepared for the scenario of a compromised DevOps supply chain.

As software becomes more pervasive and integral to our daily lives, attacks are becoming increasingly common for businesses of all types. It’s only a matter of time before attackers make their move on your software supply chain and attackers continue to improve their ability to monetize successful attacks at the expense of businesses. You have to make sure that you are taking appropriate steps organization wide to improve software supply chain security.

A few key steps to establish a solid incident response plan:

• Identify a few ways that attacks might manifest themselves.

• Define what needs to be done and by whom

  • Use the RACI matrix for defining roles.

    • Who is accountable?

    • Who should be consulted?

    • Who should only be informed?

  • Define the communication plan between critical stakeholders

  • Identify communication channels

  • Establish an escalation tree

Don’t Wait to Secure Your Software Supply Chain Until It’s Too Late

To summarize, a software supply chain is a multi-component system where the components work together to build the final application to be deployed. Therefore, the severity of software supply chain attacks is critical since they can create an attack on every user - steal their data, and control their actions. What unifies supply chain attacks is that their attack surface is quite large - every single component is a target, and every component can be used in multiple projects. An attacker can try to attack a third party you’ve been using and end up attacking your project in a blink of an eye. And without the right tools in place to detect an attack on your software supply chain, attackers may have more time to wreak significant damage to your business.

Supply chain vulnerabilities are a threat that merits thoughtful consideration - you need to understand the state of the software supply chain - your components, and the way they work together to assess the threats. You need to prevent and mitigate them using the 10 steps introduced here. You have to follow through - enforce the good practices and don’t let time pressure interfere with your goal of securing your supply chain. Eliminate as many risks as possible and understand that you can never do a perfect job - be prepared for an attack scenario. Be dynamic - at least apply the minimum requirements, but go beyond them when you can. Use software supply chain tools for assessing, mitigating, and fixing your risks. Don’t allow your security policy to be bypassed by human error - software is much less forgetful than developers, so institute a programmatic method of governing security policies across your SDLC. With the right tools in place, your entire organization can become an integral part of security your applications and protecting your bottom line.

Legit Security helps you follow all these steps and secures your software supply chains.

Get Help Securing Your Software Pipeline Today!