Home » Software Development » Yes Small Companies Can – and Should – Build Secure Software

About Jim Bird

Jim Bird
Jim is an experienced CTO, software development manager and project manager, who has worked on high-performance, high-reliability mission-critical systems for many years, as well as building software development tools. His current interests include scaling Lean and Agile software development methodologies, software security and software assurance.

Yes Small Companies Can – and Should – Build Secure Software

‘For large software companies or major corporations such as banks or health care firms with large custom software bases, investing in software security can prove to be valuable and provide a measurable return on investment, but that’s probably not the case for smaller enterprises, said John Viega, executive vice president of products, strategy and services at SilverSky and an authority on software security.’

Schneier on Security: Is Software Security a Waste of Time? Bullshit. It’s foolish and short sighted to pretend that software security is only a problem for enterprises or enterprise software vendors. Small companies write software that big companies use,
which means that these big companies are putting their customers at risk. This is happening all of the time. And it’s wrong to believe that small shops can’t do anything practical about building secure software. I’m not talking about swallowing something like Microsoft’s SDL whole – for some people, the argument seems to be that

“If you aren’t following Microsoft’s SDL then you can’t build secure software, and
nobody except Microsoft can follow the SDL, so you might as well give up.”

But you don’t need to adopt the SDL, or any other large-scale, expensive, enterprise-quality software security program. Any small shop can take some reasonable steps that will go a long way to building secure software:

  1. First, take some time upfront to understand the business requirements for security and compliance and for handling confidential and private data – what information do you need to protect, who can see and change what data, what data do you have to encrypt, what data should you not store at all, what do you need to log? All of this is just part of understanding what kind of system you need to build.
  2. Think about your application architecture, and choose a good application framework. For all the noise about “emergent design”, almost everybody who builds business apps – even small teams following Agile/Lean methods – use some kind of framework. It’s stupid not to. A good framework takes care of all kinds of problems for you – including security problems – which means that you can get down to delivery features faster, which is after all the point.If you’re a Ruby developer, Rails will take care of a lot of security problems for you – as long as you make sure to use Rails properly and you make sure to keep Rails up to date (the Rails community has made some mistakes when it comes to security, but they seem committed to fixing their mistakes).Play, a popular application framework for Java and Scala, includes built-in security features and controls, as do many other frameworks for Java, and frameworks for PHP and other languages, and of course there’s .NET for Microsoft platforms, which is loaded with security capabilities.None of these frameworks will take care of every security problem for you – even if you use them properly and make sure to keep them patched as security vulnerabilities are found. But using a good framework will reduce risk significantly without adding real costs or time to development. And when you do need to do something about security that may not be included in the framework (like properly handling encryption), there are good security libraries available like Apache Shiro that will make sure that you do things right while still saving time and costs.
  3. Write solid, defensive code: code that works and won’t boink when it is used in the real world. Check input parameters and API return values, do a good job of error handling, use safe libraries. Program responsibly.
  4. Take advantage of static analysis tools to catch bugs, including security bugs. At least understand and use any static analysis checkers that are in your IDE and free, easy to use tools like Findbugs and PMD for Java, or Microsoft’s tools for .NET. They’re free, they find bugs so you don’t have to – why wouldn’t you use them?Most commercial tools are too expensive for small teams, although if Cigital comes through with small-bundle pricing for Secure Assist this would finally provide small development teams high-quality feedback on security bugs.

Sure there is a lot more that you could do or should do if you need to. But even modest and reasonable steps will go a long way to making software safer for customers. And there’s no reasons that small teams can’t – or shouldn’t – do this.


Reference: Yes Small Companies Can – and Should – Build Secure Software from our JCG partner Jim Bird at the Building Real Software blog.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
Email address:

Leave a Reply

Be the First to Comment!

Notify of