Have a Secure Rails Application in 60 Seconds

Comments: Reply
Brett Hardin

Keeping your gem files up-to-date is challenging. When you begin building your app, only a handful of gems are used. But after a few weeks of development updating the gems becomes out of hand. Questions begin arising such as:

  • What security bugs are getting patched that I’m not aware of?
  • What optimization patches are available?
  • If I update my gems, how is my application going to break?

So, the question I pose to you is: Are their performance enhancements and bugs that currently exist in your application that are already patched in newer versions of the gems?

Even using github to watch all of the repos your application uses becomes too much after you track 5 repositories.

The History

At SourceNinja we have been developing products to help individuals and organizations manage their open source packages and open source third party libraries. Our customers have requested help in managing their RPMs and Debian packages. So we built those integrations first.

However, we quickly realized to deliver more value to our customers we needed to consume our own dog food. We wanted the ability to use SourceNinja ourselves. We have personally struggled with keeping our open source libraries up-to-date for years and now that we’ve built a product that could help us do it, we wanted to benefit.

SourceNinja is built using Ruby, Rails, and Clojure and hosted on Heroku. The first step in using SourceNinja on SourceNinja was to make a simple integration point between the rails stack and SourceNinja. We needed to create a gem.

One Gem to Rule Them All

We released the sourceninja gem to have your application push the gems and versions to us. This means that you can have a secure rails applications in less than a minute. The SourceNinja gem helps to seamlessly integrate your rails applications with SourceNinja. One of the key benefits of using the gem: we never need direct access to your source code.

Whenever any gems your application uses are updated, the SourceNinja dashboard will reflect the change. You can even create a dashboard to have production, staging, and development environments. All reflecting the current state of the gems in your applications.

The best part of integrating the gem with your application is that as additional features are released you directly benefit from them without any additional work on your part.

Full Commit History

In 60 seconds, your application’s gems will be constantly monitored for upstream patches that directly affect your application.

SourceNinja gives you full commit history from version to version. This means that when you have an outdated gem, you see all the changes up to the most recent version. Having this information quickly available not only helps you make an informed decision on what to update, but also helps with knowing if there is anything critical that needs to be called out.

How this directly benefits your application and your team:

  • Increase adoption of security patches into your application
  • Better information regarding whether the newer version will break your application.
  • Receive notifications when critical updates have been released for your gems.

Check out the documentation and try it out. We look forward to hearing your feedback or features that you would like to have.

Are you using a different technology stack? We also have a node module for your node stack. Not using Node, Rails, or Ruby? Tell us in the comments what technologies you would like us to support.

How To Keep Node Modules Secure

Comments: Reply
Brett Hardin

Just like other open source software, node modules get updated often to address bug fixes and new features. Staying informed of the updates is challenging and updating the modules by running npm update can break your current application.

Why You Should Care

Using any edge technology becomes a pain when trying to keep third party libraries your application uses up-to-date. With node, your application directly benefits from using the newer versions of modules vs. the older versions currently installed. Newer versions have:

  • Optimization Fixes - Making your application run faster and with less cycles. Which typically means a lower bill if your using cloud services for hosting.
  • Security Patches – When vulnerabilities are found in modules, they are resolved through patches. Do you have modules that have security patches sitting in the upstream changes?
  • Bug Fixes - When a library you use has a bug, your product has a bug.

Why would you not want to stay aware of the changes? Your application can benefit from any of these patches. Sweet, so let’s just run npm outdated and update everything blindly!

What about npm outdated

Node currently gives you the ability to run npm outdated. Running npm outdated tells you which of your currently installed node modules are outdated by the version definition in package.json.

mkdirp@0.3.2 ./node_modules current=0.3.1
charm@0.0.8 ./node_modules current=0.0.6
bunker@0.1.2 ./node_modules current=0.1.1
qs@0.5.0 ./node_modules current=0.4.2

But, how does this information help you? You now know a newer version is available. So, you say, “Something is out of date. I’ll just update it.” Then you spend a day resolving the broken things in your app. After a few times dealing with this you become apathetic to updating. You’ve decided that the pain of updating outweighs the benefits. So you stop updating.

A Better Way

Knowing that a node module has an update is a good starting point, but what would be really helpful would be the details of the change. This way, you aren’t updating blind, you are actually updating with purpose.

What you need is a way to see all of the changes between the newest version and the one your application uses. This is the critical information that is required in order to make a decision on whether to updated.

Full Commit History

In 60 seconds, you can have your application’s node modules constantly monitored for upstream patches that directly affect your application. The integration currently provides full commit history from one version of the module you use to the most recently released module. The best part of integrating the gem with your application is as we release additional features to the SourceNinja you will directly benefit from them without any additional work on your part.

How this directly benefits your application and your team:

  • Increase adoption of security patches into your application
  • Better Information regarding whether the newer version will break your application.
  • Receive notifications when critical updates have been released for your modules.

When any of the modules used by your application are updated your dashboard will reflect those changes. You can even create a dashboard to monitor production, staging, and development environments; all reflecting the current state of the modules in your applications.

SourceNinja gives you full commit history from version to version. This means that when you have an outdated module, you see all the changes that have happened up to the most recent version.

Check out the documentation and try it out. We would love to hear your feedback or features that you would like to have. We look forward to serving you.

When Vulnerability Patches Don’t Fix The Problem

Comments: Reply
Brett Hardin

A remote code execution bug was found in Samba 3.0.x and 3.6.3 (CVE-2012-1182) last week. The proof-of-concept code was provided by Brian Gorenc and an anonymous researcher. The Samba security team stated the RPC code generator did not validate input of an RPC array length in a manner consistent with validation of array memory allocation, which allows remote attackers to execute arbitrary code via a crafted RPC call.

Network remote code execution bugs are the worst type of security bugs. In essence, they allow either an attacker or a worm to run code on the vulnerable machine as the root user from an anonymous connection (meaning unauthenticated). No local machine access is required. This results in full compromise of the system.

In response, Samba has released versions 3.6.4, 3.5.14 and 3.4.16. These versions patch the bug in question.

The Problem with Patches

Awesome! A really bad vulnerability was found, an exploit was written, and the samba security team has released a patch. We’re done. Wait a minute. How do we let all of the people that are running vulnerable versions of samba know about the fix?

We have now identified a major problem with Information Security. The distribution of security information to the people that need it is not effective. You could subscribe to every blog and security changelog for all packages that you use, but how many new packages are added with each release?

The Problem with Vulnerability Management

You could use a Vulnerability Management solution and hope they implement a script that checks for the vulnerability in a timely manner. Hopefully this is done in a way that limits false positives. If you use Redhat or Debian, then you get to deal with the fun problem of handling the false positives yourself.

Using an Open Source Management Tool

Using an open source management solution, like SourceNinja, solves this problem for you. SourceNinja knows about all the versions of software and third-party libraries your servers and applications use. When patches are released, you see the patch that is available to you in the dashboard immediately and receive email notices each week until it is fixed in production.

The best part about using an open source management tool is that you integrate it once, in 60-seconds, and never need to do it again. All of your servers and applications are managed automatically. Sign up for SourceNinja if you want to be notified when your applications and servers are running insecure versions of Samba or other pieces of software.

Additional Resources

Keep Your Application Secure and Optimized

Comments: Reply
Brett Hardin

Today we are announcing the public beta of SourceNinja. SourceNinja helps keep your applications optimized, secure, and compliant by keeping you informed to the changes in the software libraries you use.

As developers, we have always had the problem of staying on top of our software updates. We want to keep our applications secure and optimized, but monitoring all the repositories that store the open source software we use is painful and too time consuming. Even with the ability to follow repos on github, once you follow more than 10 repos the data becomes overwhelming.

Simple Integration

SourceNinja provides a library you include in your product. Once integrated, we begin keeping you informed to the updates automatically. Anytime you update or add a library to your application, SourceNinja immediately begins tracking it.

When a newer version of a library you used is released, you receive a notification. This helps you stay informed to what libraries specific to your applications have been updated. Our alpha customers really liked being notified of the change. This helped them stay on-top of their updates, making sure no known security bugs or optimization issues exist in their applications.

Why wouldn’t I just use Bundle Outdated?

If you’re on Ruby, awesome. We love bundler. When bundle outdated was released in bundle 1.1, we were ecstatic. But, unfortunately bundler only tracks gems. Very few application use only a single technology, instead developers rely upon a host solutions which vary from JQuery on the front-end to Apache on the backend, and no solution provided a centralized point of management for all of these assets.

Our goal is to track every piece of open source across every platform whether that be Java, Node.js, PHP, or the underlying operating system and provide that information in an easy to understand dashboard.

Welcome to SourceNinja

We currently support Java, Ruby and CentOS with more languages and platforms being added every week. Give us a try, it’s free to sign up and we’d love to hear your feedback.

Third Party Software Updates Are Critical

Comments: Reply
Brett Hardin

Image Credit: EssjayNZ

The Internet is hostile. As soon as you deploy an application, the application will be attacked. Automated attacks are looking for known security vulnerabilities. When a new vulnerability is identified in a commonly used library, the vulnerability is weaponized and actively exploited within days.

Jeff Williams and Arshan Dabirsiaghi of Aspect Security just released a study on “The Unfortunate Reality of Insecure Libraries.” The paper focuses on the vulnerabilities in Java open source libraries, but can be extrapolated to other languages, such as Ruby, Python, and node.js as well.

Some key takeaways:

  • On average a typical application uses 30 libraries, making up 80% of any applications code base.
  • 26% of libraries have known vulnerabilities that have been fixed with software updates.
  • Typical applications are likely to include at least one vulnerable library.
  • Organizations don’t have a strong process in place for ensuring that the libraries they rely on are up-to-date and free from known vulnerabilities.
  • Aspect Security consistently finds widespread use of out-of-date libraries, including those with known vulnerabilities.

It is important to understand that once a developer uses a library, the application code (through a transitive property) is implicitly trusting the code. Since libraries run with full privileges of the application, having a vulnerable library makes your entire code base vulnerable.

Developers and organizations often think that automated tools or penetration tests will catch these vulnerabilities, but that is not the case. The paper states:

Currently, developers have no way to know that the library versions they are using have known vulnerabilities. They would have to monitor dozens of mailing lists, blogs, and forums in order to stay abreast of this information.

This is the reason we built SourceNinja. We wanted a place where developers could have a holistic view of the libraries they use in their applications. Once SourceNinja is integrated with an application the developers know which libraries have patches to security issues and performance enhancements.

The paper continues:

While organizations typically have strong patch management processes for software products, open source libraries are typically not part of these processes. In virtually all development organizations, updates to libraries are handled on an ad-hoc basis, by development teams.

The process for third party software updates should not be ad-hoc. Development teams should have tools at their disposal notifying them when critical patches are released for the libraries integrated into their application. SourceNinja sends you immediate notifications when a third party libraries you use are updated and gives you actionable information so you can decide whether it should be updated.

How are you staying on top of your third party software updates?

30-Day Free Trial

Know what patches are available so that you can upgrade your open source dependencies with confidence.

Twitter Feed