Services, practices & tools that should exist in any software development house, part 2

Code quality (Practices and tools)

Code quality is very similar to testing. Everyone acknowledges that you should move forward implementing practices and actions enforcing quality of the delivered software but then again these actions are usually considered as waste of time, badly planned or non existent at all on any project time plan. On the other side developers either poorly trained or with no realistic time to tackle both the problem of the actual business development + building their solution with less mistakes and using best practices. Luckily enough there are ways to tackle the time and effort problem by using tools during development that can scan your code and provide reports, tips and todo’s. We must point that all these tools can not detect issues like a poor architecture or design but can proactively secure you from writing lazy or non efficient/’fast’ code.

The following list is a set of tools that any Java Developer can integrate to it’s daily work + IDE. These tools can also be automated by wiring their execution on the lifecycle of a continuous integration server which will perform code analysis tasks upon request or on predefined intervals. That way you can remove the extra processing (resource) burden on each developer’s machine and assign it to a central machine – sharing all the results and reports to the team or making it available to senior stuff.

• FindBugs
• PMD
• CheckStyle
• JDepend
• Sonar (one stop shop-code quality-platform)
• Prevent (commercial)
• EclEmma

(feel free to comment on other -that work either as standalone tools or plugins on your favorite IDE)

All the above tools (or many others added in the comments) provide us a first line of defense from our code development mistakes – but can not be considered as the holly grail of code quality. You still need developers with skills and will to learn and adapt. Enforcing or introducing these tools shall be on a department level – part of the development life-cycle. The more you apply such concepts on a wider level the better chances you have to see the results of this practice on the majority of your software development activity.

Continuous … training (Practice)

The road towards developing quality software solutions is related to tools, practices and people. This last part, the people part is the most important. As we have already said in the previous posts, none tool or practice is effective unless the people applying it are eager to participate, have a common sense of what is quality and love their job (that is software development). How can a company or department though help to preserve or even increase the skills of their people? How can we make people more motivated and how we can ensure that our people are capable of implementing and delivering the business promises we’ve sold to our customers?

It indeed a big question and may have multiple answers – on this post I would like to raise the importance of training (as a potential answer or activity on the above issues). I will try to list some practical and pragmatic actions.

Buy technical books: Every software house or department should have its own mini tech book library. I would recommend, bring something new every month. There are lots of companies that do buy books from amazon or so – but only when they are necessary. If you go one step further with minimum amount of money (come …just a portion of other bonuses and freebies – in terms of budget the company is willing to pay to its employees.

Send people to training sessions: This practice indeed costs a lot more comparing to buying a few books every month. Good training sessions are considered a good investment and provides a quick and flexible way on acquiring certain skills that can be leveraged through a specific project. Realistically I would propose to every company to provide some sort of less ‘other bonuses’ and invest on training of its stuff. In the software /IT business knowledge is power, the more in you invest on knowledge skills the better the investment on the future and on the abilities on delivering to your potential customers.

Engage people internally: Organize internal sessions, code reviews between different development teams and encourage people who seem to be more active than others to give talks or workshops. It can be a great way of engaging the developers and raise expectations.

The rest of the article is contributed by a fellow reader of this blog and experienced professional, Dimitris Stergiou (linkedin, twitter, blog). Dimitris is working as a Information Security Manager and through this post is eager to highlight the importance of designing and building a secure software solution.Security must part of the overall software development lifecycle.

As it was mentioned before, testing is one of the most important software activities. However, in most of cases, testing is limited to functional requirements and non-functional requirements (such as application security) are largely ignored.

Before we dive into the details, there is an acronym that you need to keep in mind, OWASP (and yes, we will reference it a number of times)

Practice: It is common knowledge, that unless the software product is scrutinized non-stop (e.g. Adobe, Microsoft), the organization is not putting any “effort” in non-functional requirements (such as security). And in all fairness, why should senior management devote resources (people and money) to address security, when it provides no directly marketable feature, nor any tangible benefits?

The answer is simple. Security requirements are there to act as an insurance (pay now, prevent bad things from happening), preserve market share (who wants to use a crappy product?) and provide resilience (especially if your product is used as a service – web based)

Now that we have established that we need security, let’s see how will achieve it. Since the latest trend is Agile Development, here is an example on how you tie security activities with development activities:

Since this is not a “be all, end all” post, we will only focus on the security testing (code inspection and dynamic testing).

Before starting the security testing activities, we need to know what we are looking for and how to find it. The best resources on this subject are provided by OWASP in the form of the “OWASP Top 10 Web Application Security Issues” document and the “OWASP Testing Guide v3” (v4 is on its way). These 2 documents will provide the basics on what are the most common (and harmful) web application issues, what are the defenses against them and how to identify them in your project.

Tools

There are a number of tools available to help with security testing. For code inspection, some of the solutions are:

Peer review: Have development teams read each other’s code. Yes, it is a manual process, but enhances awareness and improves the developers’ ability to produce “better” code. If your programming language is not supported by any of the open source static code analysis tools, and you have no budget for a commercial solution, this is the only way to go.

Static code analysis [PDF]: Depending on the programming language in use, it is a good idea to use one of the open source static code analysis tools to check your code for common problems (OWASP maintains a list of tools as well). It is not a bulletproof procedure, and it usually generates enough issues to look at, but if you manage to find a code analysis tool that you like and you manage to built custom rules (to adhere to the organization’s coding style) it will definitely catch a lot of the low hanging fruit (empty try / switch blocks, unused variables, etc.)

Commercial static code analysis: As Gartner suggests [PDF], there are 3 major players in this area: IBM (after buying Ounce Labs), HP (after buying Fortify) and Veracode (they didn’t buy anything – not directly at least). Be prepared to pay crazy amount of money, depending on the number of projects, the programming languages used and a number of other parameters which are solely used to complicate the licensing model (or that is my impression). After working with 2 out of these 3 products (IBM/HP) i can say that they are amazing products but in no way they can provide “out of the box” functionality. They require a LOT of configuration in order to provide meaningful results (no one will be happy with a scan producing 19,387 defects) but AFTER you manage to establish the baseline, they will be quite helpful

Static code analysis in the cloud: Fortify also offers a cloud (hosted) solution, if you can’t afford the in-house hosted solution. They have some special offers for open source software, but i have never tried the service, mainly because every company i have worked for was not happy “publishing” their source code in the cloud

By now you should have an idea on how to cover static testing. However, you need to cover dynamic testing as well. Let’s take a look on how to do this.

Tools

Manual penetration testing: Although a number of tools are available, when it comes to web application security, no tool can match results from an experienced penetration tester. Penetration testers DO use automated tools for automating tedious, time-consuming tasks, but DO NOT solely rely on the scan results of a scanner. Amongst other reasons, we are VERY FAR away from being able to create a web application scanner that understands and evaluates business logic

Web application scanners: This category includes a number of sub-categories, depending on how the product actually performs its functions. Some that definitely worth a second look are:

• Nikto (written in Perl, one of the oldest kids on the block)
• w3af (metasploit approach to web application security)
• Arachni (installs as a Ruby gem, nice concept)
• skipfish (from Google’s Michael Zalewski)
• websecurify (Nice GUI and nice coverage)
• sqlmap (for SQL injections)

The 5 products mentioned here are open source, decent communities supporting them and obviously provide the ability to extend the products as you see fit. However, if you have the budget for a commercial solution, here are some interesting ones to try:

• Accunetix VWS (one of the oldest companies in the field)
• IBM AppScan (ties nicely with IBM’s static code analysis)
• Tenable Nessus (although more of an infrastructure scanner)
• Rapid7 Nexpose (again, more of an infrastructure scanner)

For a complete list of open source, commercial and cloud solutions, you can go here.

MITM proxy: MITM (Man In The Middle) proxies are used by penetration testers to craft of modify requests to / from web applications on the fly. Some of the proxies also contain active reconnaissance capabilities, such as spidering, XSS / SQL injection vulnerability scanning and session manipulation. Some proxy tools to check are:

• paros
• burp
• OWASP’s ZAP
• charles

However, expect to be putting in some manual work, since the proxies are a tool to help the penetration (security) tester and not replace him.

People, Process, all that Jazz

One thing must be made clear. No matter how many (or few) of the tools an organization implements, it’s the people and the process that will make the difference. Imagine that it has to go something like:

Awareness: Managers, development, everyone needs to be aware of what the goals are and how they will be achieved. Managers need to devote time and money to security testing, developers need to understand how to produce less security bugs (and how to fix old ones) and operations needs to help by deploying infrastructure controls which will help web application security (web application firewalls)

Training: Developers need to understand why the code has security issues, and how to fix them. One of the best weapons in the arsenal of developers is OWASP and specifically the ESAPI (Enterprise Security API) framework. By using ESAPI developers can focus efforts on developing the parts of the software they have their expertise in (bussiness logic) and leave security functions to be implemented by the ESAPI framework

Development: Use open and proven solutions, don’t re-invent the wheel. There is no way that your in-house developed hashing algorithm is better than SHA, nor that your encryption module is faster / better than AES.

Testing: Testing for non-functional requirements is a must. End of story!

Lather, rinse, repeat: Whatever you do, remember: it’s a continuous process, you don’t get to do it once and be secure for ever

If you decide that you want to have the process in place, the best way to start is to go through the BSIMM (if your organization is really big) and OpenSAMM (for medium / smaller organizations) and decide which parts of the model you would like to see implemented.

Reference: Services, practices and tools that should exist in any software development house / department – Part 3 and Part 4 from our JCG partner Paris Apostolopoulos at Papo’s log.

• This comes BEFORE your business logic!
• How many bugs do you have in your code?
• Using FindBugs to produce substantially less buggy code
• Introducing new technologies – How to battle resistance
• Java Tools: Source Code Optimization and Analysis
• Can we replace requirement specification with better understanding? 
• Things Every Programmer Should Know 
• Why Automated Tests Boost Your Development Speed