Supply Chain Insecurity: Keep Your Eyes On The Road With Ruby on Rails


The software supply chain attracted more attention than usual Over the past few months, companies have revealed issues resulting from flawed approaches to protecting the integrity of their software applications. The software supply chain is loosely tied and most people have no idea how fragile it is. This state of affairs suggests that we should ask ourselves, “Can I guarantee all of the software dependencies that make up my Ruby on Rails application?”

Before analyzing all of your applications, it’s essential to understand the three main categories of software supply chain attacks: infiltrated repository, primed repository, and source swap. Each of these can lead to compromise of third-party or open-source software you use in your applications.

Infiltrated repository attack

Infiltrated repositories are particularly devious because they involve the attacker using a social engineering attack to gain the trust of a project owner. A busy gem author may not have the time or resources to keep a package up to date. Then a wolf disguised as a sheep arrives and offers to give time to maintain the project. Well-intentioned project owners provide the attacker with access to the repository, allowing the injection into the gem of any malicious code desired by the attacker.

An alternative scenario involves the attacker directly targeting the handling of weak credentials in a repository. Sensitive data should never be stored in repositories where everyone can see it. An attacker can take the time to search your repository for keywords to use in a dictionary attack, thereby gaining validation authority. Attackers are persistent and creative, and once they have credentials, they will release an updated version of the package, including their malicious code. They will take advantage of the trusting relationships you have established in the community to cause the download of this now malicious package.

Repository attack initiated

It takes a patient attacker, and often a lazy developer, to perform a primed repository attack. A primed repository is when a convenience package exists for the sole purpose of being sneaked into code bases. An example is the “is_odd” gem. This gem returns “true” if the evaluated number is odd, and returns “false” if it is even. If you look at the source code, this gem doesn’t even do the math itself! It calls another gem called “is-int-even” and uses the “IsEven” method to check the number and return the opposite result.

None of these gems currently contain malicious code. This attack takes advantage of developers who abuse third-party software to reduce development time and not really measure the usefulness of the packages they add. After adding the gem to your project, the attacker can modify the code in the “is-int-even” gem, and the next time you update your dependencies, it will now include malicious code from the attackers. These gems were created for educational purposes only and will never contain malicious code. However, if you find them in your code, you should take a moment to think about your processes to find out how you choose which dependencies you include in your projects.

Source swap attack

The final and most common attack on the software supply chain is a source swap. In this approach, the attacker attempts to trick a developer into including a malicious package that appears legitimate. The most common source swap attacks use typosquatting. An attacker creates a project with a name similar to a popular gem, in the hope that the developer will make a spelling or typing error and download the malicious gem instead.

Profiting from typos is not a new concept for malicious actors. For years, attackers have used domain addresses with similar names to steal sensitive data from unsuspecting users. This type of attack on the software supply chain has seen a steady increase in recent years due to its effectiveness and the fact that it requires minimal effort to deploy. The advantage of Ruby developers is that RubyGems has built-in protection that prevents new gems with similar names from being released.

How to Mitigate Supply Chain Attacks in Ruby

Mitigating the risk of software supply chain attacks is a difficult task. In modern software development, it is impossible to remove reliance on third-party or open-source software. However, there are several things you can do to reduce your risk.

Some things are beyond the control of the development team. You cannot force everyone who creates a gem to ensure that they have configured Multi-Factor Authentication on their repositories. You also have no control over the verification process of the people working on these projects. You can make smart decisions to reduce your attack surface and manage any dependencies you choose to include in your code.

As a Ruby developer, take these three tips to secure your software supply chain: control and organize your gems, audit your gems, and use software composition analysis (SCA) tools to build security controls into your pipeline.

1. Veterinarian and parish priest

When checking which gems to include in your Ruby project, you should ask yourself a few questions. The first is: do you really need the gem or can you quickly write the added features yourself? If you decide the gem is needed, make sure the package is well documented and contains good code base comments. The second question you should ask yourself is about gem maintenance: when was the last commit? An under-maintained and poorly documented gem should raise red flags. Obsolete packages are ripe for attackers to target for malicious purposes.

Even after the verification process and the decision to include a piece of jewelry in your project, you cannot assume that it will always be good and forget about it. You have to constantly audit your gems due to the newly discovered vulnerabilities. The ruby-Advisory-db maintains a database of vulnerable Ruby gems. the bundler audit The utility examines the application’s gemfile.lock and ruby-Advisory-db to see if you are using a vulnerable version of a gem. You need to integrate it into your CI pipeline to automate the task instead of executing it manually.

2. Audit your gems

Your applications change over time. You are constantly adding and removing code. You revise and refactor code for security or performance reasons. When this happens, you end up with stagnant gems in your projects that are no longer needed. It takes an exceptionally long time to go through all the packages to manually remove unnecessary ones. You can run the “bundle clean –force” command to remove all unused libraries from a project. Don’t let stagnant gems stay. They become a target for potential attackers.

3. Use SCA tools to build security into the pipeline

Include SCA tools to check for vulnerabilities and abort compilation if you have a known vulnerability. These tools must fit into your CI pipeline. Sonatype’s Synk and Chelsea are two premier tools for conducting SCA for Ruby applications. Synk and Chelsea will check for vulnerabilities in your third-party packages. Automate security as much as possible. These scans should be a step in your CI pipeline that runs every time you push code.

All eyes on the software supply chain

There are benefits to using third-party gems in your Ruby on Rails projects. However, knowing that attackers will target your applications using techniques such as an infiltrated repository, primed repository, and source swap, you must be vigilant to include only useful, safe and necessary gems in your projects. . Check and organize these gems, audit them, and use SCA to prevent attackers from taking advantage of your software supply chain and infiltrating your projects.

Keep learning

Leave A Reply

Your email address will not be published.