Why bad coding habits die hard—and 7 ways to kill them
Credit to Author: Jovi Umawing| Date: Wed, 23 May 2018 15:00:00 +0000
Developers are usually the focus of blame when software vulnerabilities cause organizational breaches. (Sometimes, quality assurance engineers are included in the flame.) Interestingly, though, hardly anyone looks at why bad coding habits form in the first place.
We’re talking about the culture, the processes, the unrealistic deadlines, and—perhaps the worst of this bunch—the lack of awareness between the business and development sides. The former must realize that as they innovate, they need to adapt and respond to the ever-changing threat landscape; the latter must know how to write good, clean, secure code.
Reasons why programmers fail at security
Each organizational breach is a testament to something going wrong somewhere. And it’s a lot more complicated than assuming developers are just lazy at coding. To understand what’s really going on, we’ve listed some of the reasons why programmers appear like they don’t care about secure coding when, in fact, they do.
They don’t know what secure code looks like.
Most of us assume that programmers, well-versed in multiple programming languages as they are, should also know how to write secure code. This just isn’t true. According to a study conducted by CloudPassage a couple of years ago, none of the top 10 computer science programs in the US require a cybersecurity course—not even an elective one—for graduation.
While computer science, information systems, and computer engineering students are taught how to code, accredited schools are simply not teaching them security by design. Secure coding is now something programmers must educate themselves on how to do.
They don’t have enough time to spend on security.
Software developers are expected to adhere to rigid deadlines. No ifs, ands, or buts. On top of this, they also have to balance conflicting interests from multiple stakeholders, refine code functionalities, and ensure that the program is reliable and stable. Programmers have to tick several more boxes before reaching the bottom of the list, where security is. In fact, it’s more common for programmers to skip security checks, so they deploy the program as-is: a working, efficient, but vulnerable product.
Essentially, it’s half-baked.
They lack the tools needed to identify security risks.
As much as software developers would want to keep their code as risk-free as possible, they cannot. The tools needed for this are expensive and can be a hard sell for organizations that have budget constraints or who utterly fail to grasp the importance of reducing software vulnerabilities.
Leading the charge
Vulnerable software is the bane of business organizations. In this age of breaches, you’d think it’s only logical for organizations to secure vulnerable software, starting with their own. Yet, bad code remains prevalent to this day. It’s up to management to take charge and prioritize security in the development process. By adopting any or all of these suggestions to eradicate bad code, businesses can not only help software developers do a better job, but also potentially secure their reputation, data, and ongoing survival.
Shall we begin?
Train developers to write secure code.
Training is perhaps the best and most effective way to get software developers to improve their coding. To do this, management has several options: invite a third-party organization to conduct training, have their software engineers enroll in workshops outside of the workplace, or have them register for online classes.
Should they decide to hire a third party, there are some private institutions they can turn to. WhiteHat Security, for example, has a program where developers who finish the requirements and pass the exam can be certified as a WhiteHat Secure Developer (WCSD). SANS and CERT follow a similar method. It’s crucial that develops use secure coding in every stage of the company’s software development lifecycle (SDLC).8
Introduce a standard coding convention.
Depending on the programming languages your developers are using, upper management must establish secure coding standards they can adhere to. Thankfully, they don’t have to start from scratch. There are a lot of sources online they can begin looking into, adapt as-is, or modify to fit their needs.
A convention includes recommended programming styles, methods, and other coding practices. Adhering to one significantly lessens errors, makes the source code readable to other programmers, and is easier to maintain in the long run.
Create a culture of security.
Make no mistake: secure coding should be as important to company culture as it is to the overall software development process. The aim of having such a culture is to imbibe security practices so deep that they become second nature. These practices grow into valuable traits programmers can take with them anywhere.
As we keep saying, security is no longer the job of one department in a company. It is now everyone’s job to ensure that sensitive client information is kept safe and secure, and to think twice before clicking that link or opening that email attachment. If security is stressed as an important part of company culture, that mindset can extend beyond staving off breaches to keeping your customers just as safe.
Read: How to create an intentional culture of security
Create a security policy.
A policy is vital to have as this guides software developers not only on what security features to bake into their applications, but also how these should be implemented. Unfortunately, organizations often overlook this, leaving their applications, intellectual property, and other vital information open to compromise. Embedding a security policy to the SDLC is a must. If the company makes their product available to the European market, then embedding GDPR to the SDLC is essential as well.
Conduct an internal bug bounty program.
Bug bounties in general are a form of security crowdsourcing that allow people to check software and systems for flaws. Monetary compensation and/or recognition are awarded to those who find flaws deemed critical. Upper management may opt to use this scheme once the product has passed over the QA and security teams in the hopes of further reducing exploitable vulnerabilities. If they wish, they can also hold a bug bounty program for non-employees.
Set a realistic schedule.
Rigid timelines may get the job done, but they also encourage sloppy coding. A finished product doesn’t mean it’s a secure one. If security checks on code are usually ignored because of the project schedule, wouldn’t it be better for project managers to set the timeline with a little padding in case something happens and the target date isn’t met?
Today’s threat landscape no longer allows half-baked applications. A slight schedule slippage can be remedied, but a breach due to flaws that wouldn’t have been missed during code reviews could cause more problems and unnecessary expenditures for the company.
Continue to motivate developers to write good code.
This can be done by creating an environment where developers are not only required to meet standards, but want to. One way is ensuring that software programmers have the tools and equipment they need. For app developers, they may require several mobile devices (phones and tablets) they can use for testing.
Upper management must also work closely with team and project leaders to provide programmers access to necessary information they need for the project and people they can reach out to for advice. Other things that are important to developers are ergonomic furniture, a fast PC, a personal space where they can work quietly and privately, writing materials and whiteboards, and an R&R area where they can meet with other employees. Should upper management set up an incentive program for good coding? It might be the natural step to take—although, it might actually do more harm than good, so have a good think.
A word on brogramming: One may think that its presence within a company is harmless, but reality, it hurts the organization as developers outside a particular clique, especially women, are naturally excluded and made to feel unwelcome. At times, brogramming may even spark bullying in the workplace. Upper management must never cater to this subculture if they want to make the environment more welcoming to all programmers, and the company a safe place where employees can do their duties without discrimination.
Welcoming the change
Every company looking to improve their overall security posture, beginning with addressing the problem of bad code, should know that a 100 percent turnaround isn’t possible at the onset. Change is usually slow. However, after about a year of baking security into the coding process, expect a highly significant return on investment. This was the result of a study by the Aberdeen Group about companies adopting secure coding practices.
Code that works is well-designed, efficient, usable, readable, and (most importantly) secure. It is not impossible to achieve. All organizations have to do is start getting rid of bad coding habits.
The post Why bad coding habits die hard—and 7 ways to kill them appeared first on Malwarebytes Labs.