• United States



Contributing writer

Why don’t developers have a ‘spellchecker’ for security’?

Oct 31, 20169 mins
Enterprise ApplicationsInternet SecuritySecurity

Wouldn't it be nice if software developers had something like spellcheck, but instead of catching simple grammar mistakes, it caught basic security problems?

Despite all the news coverage about successful cyberattacks, developers are still writing code full of security vulnerabilities.

Of course, nobody is perfect. We all make mistakes, and as software projects get more and more complex, it can be easy to mix potential problems.

But that doesn’t explain why so much software is full of the most basic errors.

According to a report released this month by Veracode, 61 percent of all internally-developed applications failed a basic test of compliance with the OWASP Top 10 list on their first pass. And commercially developed software did even worse, with a 75 percent failure rate.

These are basic, well-known problems, like SQL injections and cross-site scripting.

Or take hard-coded passwords. Who still does that? According to Veracode, 35 percent of all applications they tested.

Eliminating these basic vulnerabilities would go a long way towards making software more secure. And the earlier on in the process they’re caught, the easier they are to fix.

Today’s integrated development environments can already catch common syntax errrors, like missing semicolons, said Ron Arden, COO at security vendor Fasoo.

“If there’s a function you’re using, it shows the parameters,” he added. “But it won’t tell you if there’s a SQL injection or cross-site scripting or something stupid like that.”

Wouldn’t it be nice if software developers had something like a spellchecker, but instead of catching typos and simple grammar mistakes, it caught basic security problems?

Developers would be able to fix them immediately, and also learn to write more secure code in the process.

The traditional approach is to test software for vulnerabilities after it has been written. But today the testing is moving to earlier in the development process, to when commits are made, or even earlier, while the developer is actually writing the code.

“We really need to be implementing this type of application security in our software development stage,” said Doug Cahill, analyst at research firm Enterprise Strategy Group. “There are some organizations that are integrating these types of security best practices into their software methodology, but not enough. One part is just lack of awareness, and one part is the need for automation. If we can hit the easy button, more of us will do it.”

According to Veracode, there are some signs that development is moving in that direction.

Although 40 percent of applications only get scanned once, 9 percent of applications get scanned much more frequently, suggesting that those companies are running some kind of continuous testing program, with some applications in developer sandboxes getting tested as much as six times a day.

According to the report, the number of vulnerabilities per applications can improve dramatically with this approach. Flaw density goes down 46 percent when application scanning is added to the development process. When e-learning features are added, there’s a six-fold improvement in flaw density reduction.

Enterprises aren’t just looking at their internal development processes, but are also starting to ask their software vendors to improve their security.

“It’s happening more and more because the supply chain is responsible for security incidents and breaches,” said Cahill. “And one of the things they ask is, do you do software scanning and security analysis?”

The tools are also getting better, he said, with a number of vendors offering software scanning and orchestration tools so that companies can integrate the security checks earlier into the development process.

“But it should be contextual,” he added. “If you just get ‘you made a coding mistake,’ that’s not especially helpful. But if you get an advisory that because of the way you structured your code, it could be exploited by a SQL injection, and here are some ways to adjust your code … we can improve our security posture.”

It’s important to avoid alert fatigue, he added, or having a “Clippy” of security — annoying and unhelpful.

“These types of alerts need to be prescriptive, consultative, and actionable,” said Cahill.

Citigal, an application security vendor, first looked at doing a security “spellchecker” back in 1999, but creating another “Clippy” was a serious concern.

“Clippy was universally hated,” said John Steven, Internal CTO at Cigital. “It was hated because it was in your face, you were typing and it distracted you, and its advice was always daft. It was telling you the wrong thing all the time.”

It would have been too easy to do the same for application security.

For example, he said, take cross-site scripting.

“Every line of code you’re writing could potentially be vulnerable to cross-side scripting,” he said.

But developers are now more willing to consider tools that help them write code, he said. Plus, the new early-state software security tools are not being used to find all possible vulnerabilities, but are used as training tools, instead.

Say, for example, a developer is considering linking to an insecure open source library. Cigital offers a tool that can catch that problem right away, suggest a better library, and even automatically convert existing code.

“We want to find the choke points to help them make a good decision,” he said, “And cut out whole swathes of later opportunities to create problems.”

In fact, the security education aspect is one of the top benefits of early-stage application testing.

According to a Sans report released earlier this year, the lack of application security skills is the top challenge when it comes to improving software security, ahead of funding and management buy-in.

Built-in security education

Checkmarx is one of several vendors looking to address that very issue.

“We take source code, and do the analysis on 10 or 100 lines of code, allowing the developers to see the vulnerabilities at a very early stage,” said Amit Ashbel, director of product marketing at Checkmarx. “And then we take them to a brief, five to 10 minute session on how to fix the code. We show them how to hack the code, and they can try it in real time. Then they understand what that vulnerability could have exposed to their code to.”

As a result, the learning is delivered exactly when the developers need it most, he said.

“They don’t have to move away from their desk, they don’t have to spend too much time sitting in a room and listening to lectures,” he said. “I think this is the way to do secure coding education.”

On the issue of whether the product is more helpful or more annoying, he pointed to its page on Gartner PeerInsights, where the reviews were very positive.

“What I like most is the level of adoption usage and impact within our engineering department the product has made,” wrote one CISO at a large manufacturing company.

“The feedback from our developers had been very positive, which has aided our adoption of code scanning as a routine activity,” wrote a technical specialist at a large financial firm.

Early-stage testing can miss big problems

The security testing that takes place while code is being written is a type of static analysis.

With static analysis, the tools simply look at the code the way it is written, while dynamic analysis actually follows the flow of logic. That means that static analysis can miss many problems.

“The tools can only protect against errors that have certain patterns that it knows about,” said Mike Milner, co-founder and CTO at Immunio, which offers run-time application security detection.

Meanwhile, as more companies move to agile development, the dynamic analysis tools are identifying problems quicker and quicker.

“You write and deploy several times a day,” he said, “So it becomes a development tool.”

When companies first began moving from traditional waterfall development to agile, security was often sidelined, said Mike Kail, chief innovation officer at Cybric, which offers a service that scans code whenever a developer commits it to GitHub or BitBucket, using Veracode or other commercial and open source vulnerability scanners.

“Currently, companies are testing for SQL injections or cross-site scripting once a week, or maybe once a quarter,” he said. “We need to make this a continuous process because the hackers are attacking companies continuously.”

It makes sense to have security testing tools as part of the software development process — but not during the writing phase, said Brian Doll, vice president of marketing at SourceClear, which makes tools that look for open source security vulnerabilities during the built process, instead.

“Logistically, it’s time consuming and painful to interrupt your authoring process to get feedback from those tests,” he said.

And it’s almost impossible to get good results during these early stages, he added.

“Until you build the software product and understand the relationship between components, you’re just guessing,” he said.

It’s the difference between static and dynamic analysis, he explained.

For example, if a developer calls a particular open source library, the exact version of the library that’s used in isn’t locked in until the build takes place, once the package managers resolve all the dependencies — and dependencies of dependencies.

“We can get much better insights and can tell you exactly where in your software you’re linking to vulnerable methods or vulnerable libraries,” he said. “And you’re not going to do a build every time you type a word. It just wouldn’t be efficient.”

But a tool that checks for problems during the writing stage doesn’t have to catch all potential vulnerabilties, said Cahill, the ESG analyst.

“This is just the first step,” he said. “There are no silver bullets in security, but you can at least reduce the mistakes and the attack surface area along the way.”

The optimal approach is to use each kind of security tool at the point where it works best, he said.

“Static and dynamic analysis should happen at the appropriate stage of the software life cycle,” he said. “There should be scanning done in each environment. If you layer, you can dramatically reduce the security attack surface in production.”