Originally published in Hakiri Blog.
Remember January 2013? A major vulnerability was found in Rails and the whole community got riled up: blog posts, rushed security audits, impromptu email alerts… No one really expected it in the Rails world because Rails was considered so “secure.” Then a new disaster came: RubyGems—the heart of any Ruby project—was compromised; several companies started to consider migrating their projects to Python or Java. This was clearly a serious problem.
What happened after that? Developers talked about security for a couple more months, updated some technologies, kept their ears to the ground for a bit and… became indifferent about security after a while, which is a surprisingly common attitude. I should clarify that by “developers” I mean freelancers, consultants, and startup/small company engineers. Larger companies have their own sophisticated security processes that are not always optimal, but that’s a topic for a different post.
A Problem with Security
Why do developers stop caring about security even though vulnerabilities (perhaps not as severe) keep getting discovered? I think there are a handful of reasons. For starters, security is not the most exciting thing in the world. Yes, sure, security is part of quality just like TDD or clean code, but no one really wants to dig into it. And besides, there are dev ops engineers that should take care of such matters, right? Technically yes, but the problem is that a lot of smaller companies don’t have a dedicated dev ops or security person. Therefore, developers have to take care of deployments, security and other unsexy things. For example, Heroku, a great set of tools for automating different processes, was created for this exact crowd: no need to setup deployment scripts or cook your upgrade recipes with Chef—just type
git push heroku master and you are golden. But Heroku doesn’t address the problem of security.
I think the current state of web security faces a lot of user experience issues: there is no simple process for ensuring security of a web app. And this problem is not unique to Rails.
Man with the Plan
How should developers keep their apps secure? Ideally, there ought to be a streamlined process for vulnerability monitoring and version upgrading. For a lot of developers, the former bit consists of randomly stumbling upon a security vulnerability warning in their Twitter feed or simply overhearing it at a co-working space—basically, there is no systematic approach for security monitoring.
Not a lot of developers know that security vulnerabilities for their apps come out on a weekly basis. This is not surprising given that an average project uses many different technologies (think web servers, databases, cache stores, frameworks, etc.) as well as dozens of gems, each of which can have a potential vulnerability. And don’t forget about code! All of us have had late nights before a deadline, when a cross-site vulnerability or a silly SQL injection can just slip in unnoticed.
I think security monitoring can be and should be automated. The Common Vulnerabilities and Exposures (CVE) database provides great coverage of public security issues, but it’s only a database. You can’t make it notify you whenever a new vulnerability for your particular version comes out. I made Hakiri to help developers and dev ops engineers set up a streamlined monitoring process for their stacks, gems, and code.
This covers the security monitoring, but what about version upgrading? This problem is harder to fix with an outside tool because so many shops and companies have different business processes that in turn affect deployment and integration. I am going to write more articles covering this problem in the future, but for now give Hakiri a try and let me tell what you think.
I am always interested in your feedback. Have an opinion or a better solution? Comment away! Also, check out @hakirisec on Twitter for the latest web security news and articles.