Problem solve Get help with specific problems with your technologies, process and projects.

Checklist for building better software

Learn how to reduce the number of security vulnerabilities introduced to software during the development process.

The root of most security vulnerabilities is poor software quality. This is no great secret. But what isn't as...

well known is a cultural shift now placing more pressure on software development teams to clean up their code before it hits the enterprise network.

At the Software Security Summit in La Jolla, Calif., Djenana Campara, founder and CTO of Burlington, Mass.-based code analysis specialist Klocwork, outlined a checklist to help managers ferret out coding flaws that frequently result from ambitious projects that outstrip the architecture they're built on.

Here is what she suggests:

Perform a system-wide security assessment of software under development
To no surprise, the first step is an audit to unearth "unhealthy development practices." This helps determine the extent of unsafe coding practices and defects (such as resource leaks and buffer overflows) in software under development. The assessment also helps narrow the number of security-oriented flaws and identify who developed those components. From there, management teams can prioritize issues and build a roadmap to cleaner code creation -- one that includes training and awareness for developers.

'Stop the bleeding' in new development
By flagging bad practices, you can then deploy a rules-based security compiler to enforce good coding practices during new development. This means the compiler must be able to report on policies. Campara suggests three possible integration points for the compiler throughout the coding process: the developers' favorite integrated development environment, such as VisualStudio; the configuration management system; and directly into a product's build process.

Perform an in-depth, multi-dimensional analysis of your software
An audit of existing software designs and architectures helps determine remedies for soft spots beyond implementation defects. This can be done by creating a snapshot of the architecture and key components' boundaries and interfaces.

Convert findings into code improvements
Clean up "one-time fixes" and continually update your rules-based compiler to include any new policy requirements. "The quality-security compiler should be incrementally reconfigured to enforce application-specific rules and security policies," Campara suggests. "Each policy should be given a time stamp as to when it will take effect."

In addition, she advises proactive management to create new secure development roadmaps. "This way priorities and workloads for the development teams can be managed in the context of the ongoing development and release schedules."

Measure improvement
This is the temperature-taking phase. In addition to checking for continued compliance, look for trends that may mean policy thresholds should be tweaked to meet a team's objectives.

Manage future security and quality improvements
Finally, repeat this process as needed. "The key is to streamline the change process based on priorities, and balance it with the education and training of the team," Campara said. "Changes should be focused on the highest priority weaknesses, while addressing secondary weaknesses more over time and balancing them with educating the team and people."

Managers have multiple options for implementing this checklist. Depending on resources, they can manually review code or incorporate source scanning technology. A third option is the use of automated static analysis tools to generate vulnerability tracking metrics and isolate flaws. This allows developers to "inspect and correct" on their own.

Breaking software easier than you think
Whether you create applications or just use them, one way to make a system more secure is to understand how it's being exploited.

Software secured with CLASP
New guidelines to bake security into the early stages of software development come just as teams feel the squeeze.

Vendor liability: A pointless argument?
The war of whether vendors should be held liable for defects in their software will rage on at RSA. The debate, however, comes a decade too late.

This was last published in May 2005

Dig Deeper on Secure software development

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.