Developers today recognize the importance of secure software development. Indeed, security was one of the key topics at the DeveloperWeek conference in San Francisco. This level of focus should be applauded.

At the same time, however, we must recognize that planning for secure software development is not the same thing as implementing it. In fact, some software development organizations have yet to fully integrate security into their development process. Time and money constraints are a common obstacle for organizations, but developer mistakes can just as readily delay or mislead attempts at integration.

Building off of that last point, Bob Loihl, senior software engineer and secure software development expert for Tripwire, has identified three errors that organizations commonly make when they try to incorporate security into their development process. These are as follows:

MISTAKE #1: BOLTING SECURITY ON AT THE END OF A PROJECT

It is important for organizations to have a security plan in place from the beginning of the development process. Such foresight allows developers to adopt a secure architectural and design approach, which in turn makes it easier for them to safeguard all aspects of the code as it is created.

A well formulated security plan is particularly important to today’s software users, who have come to expect that developers will provide them with secure offerings.

“When you defer crosscutting security work on a subsystem of your project, you will end up reworking and retesting a large part of the system later,” said Loihl. “You can definitely put off something like logging because it is a concern across the codebase, but if you put off implementing access controls in the system because it’s hard and expensive, it’s an indicator that you have missed or downplayed important project requirements.”

MISTAKE #2: FAILING TO TAKE ADVANTAGE OF SECURE SOFTWARE DEVELOPMENT TOOLS AND EXPERTISE

Organizations would be wise to resist the temptation of “rolling their own” security in software, particularly when it comes to authentication models, encryption, and other complex functions. There’s no need to reinvent the wheel. Developers should instead leverage the work of others who have already developed proven, validated secure code and processes. Time has shown that those solutions work, which means that they can help increase developers’ confidence in the security of their projects.

“With so many resources available today–from static code analysis to pen testing–there’s no excuse for not understanding the security profile of a product before it ships,” said Loihl. “In addition, there are good organizations out there like OWASP, SAFECode, BSIMM and others that can help you understand how to build out a security program.”

MISTAKE #3: INHERITING OTHER DEVELOPERS’ SECURITY MISTAKES BY USING FAULTY LIBRARY COMPONENTS

Development teams need to make sure they know the origin of the libraries they use as well as the code they incorporate from other sources. They should also determine what security validation, threat modeling, and other assurances have been applied to any third-party code they leverage in their products.

“Bringing in third-party libraries and frameworks is a risky operation in terms of security and defect exposure,” noted Loihl. “Outsourcing development does not absolve you from due diligence or testing the code you are using. The recent CWE-502 issues with Java RMI deserialization and Apache Commons Collections are good examples of this–having the library on the class path exposed an issue, even if the class that had the issue had never been used.”

Ultimately, Loihl and other Tripwire experts believe developers should not rely on “security through obscurity.” Some developers either hide their implementations of security or believe that a very complex implementation will help make their products more secure. In fact, the opposite is true. Effective security implementations that are built on proven approaches will stand up better to peer review–a cornerstone of good security that increases the likelihood of discovering and addressing security weaknesses before software is shipped out to customers.

“Unfortunately, many software development teams are still trying to address security at the end of their process,” said Dwayne Melancon, chief technology officer and vice president of research and development for Tripwire. “This approach doesn’t work. To be effective, security needs to be baked into the entire process, from planning through deployment to usage.”

Loihl added: “Anyone who has lived through a breach or received surprising results from penetration tests right before a product is scheduled to ship knows how painful it is to add security in at the end of the development cycle. Today, developers face increased pressure to understand security issues and how they apply in their environments because of Internet of Things devices and pervasive computing environments. This can seem like a big investment, but the costs of doing it right the first time are much lower than responding to crises.”

To learn more about secure software development, including what you can do to clearly highlight its benefits to senior leadership, please click here.

Via: tripwire