hidden costs for developers

Watch out for hidden costs of security tools for developers

February 24, 2019 | Software Secured

Hidden Costs of Security Tools for Developers

As security “shifts left” in the application development lifecycle, developers will be called on to work with tools to reduce flaws in their code that could make their programs vulnerable to attack by threat actors. Those tools, though, can come with costs that aren’t immediately apparent.

For example, detection-based tools can distract developers from their primary tasks and lead to costly losses in productivity and increases in overhead expenses.

On the balance sheet, these tools can appear as advanced threat detection applications, detonation environments, antivirus programs and white and blacklisting. And for a 2,000 person organization, those tools could cost an average of $345,000 a year, according to a recent study conducted by Vanson Bourne for Bromium.

But the costs don’t stop there. There are human capital costs.

For a 2,000 person organization, security tools can cost up to 

$350,000

Human Capital Costs

Depending on how fine an organization sets the sensitivity of such tools, they can create an avalanche of alerts—as many as a million a year—for a security team or developers to triage. What’s worse, most of those alerts—75 percent by some estimates—are false positives.

Those hours chasing alerts, triaging threats, rebuilding compromised machines, and issuing emergency patches, can cost an organization more than $16 million a year.

Static Code Analysis Tools

Static code analysis tools can also contain hidden costs.

Static code analysis tools that identify security flaws can perform automated scans during the development life-cycle. However, some of these tools can slow down the process and add time to when an application is delivered.

It’s also important to be aware of the limitations of SAST tools. A study by the National Institute of Standards and Technology’s SOMATE Project found that static tools were able to find “simple” bugs in code but failed to find vulnerabilities that require a deep understanding of code or design.

For example, when a SAST tool was used to scan the popular open source software Tomcat, warnings were generated for only four of 26 Common Vulnerability & Exposure entries. In other words, if an organization produced an application like Tomcat and it depended on a SAST tool as its primary application security application, its software would be delivered with 22 of 26 vulnerabilities intact.

4/26

Common vulnerability & exposure entries were generated when a SAST tool scanned the open source software Tomcat.

Static tools can also be challenged by dynamically typed languages, like JavaScript and Python. Inspecting objects in those tongues at compile time won’t reveal their class/type. That hinders the tool’s ability to find certain security flaws in the code.  According to noted software security author Gary McGraw, code flaws that SAST doesn’t handle reliably include:

  • Storage and transmission of confidential data, especially when the data isn’t programmatically discernable from non-confidential data;
  • Authentication, such as susceptibility to brute force attack or effectiveness of a password reset;
  • Entropy for randomization of non-standard data
  • Privilege escalation and insufficient authorization; and
  • Data privacy, such as data retention and masking credit card numbers when they’re displayed.

There are several gaps that SAST tools often burden users with. We have built an automated tool called reshift that works to mitigate these hidden costs of SAST tools on the market today.

Open Source Problems

If an organization’s security tools are friendly to DevOps, most security tasks will be performed automatically in the same pipeline as the one used for producing the app. Only security issues that require human intervention will be flagged for developer action.

Instead of security erecting gates that code has to pass through before entering production, Laine explained, it needs to erect guardrails that allow developers to make mistakes but prevent them from creating disasters,

Tools and agility alone, though, don’t make DevOps and DevSecOps work, Laine noted. “It’s those things, plus a culture of respect and culture of collaboration,” he said.

Open source tools have steadily gained popularity among security practitioners for a number of reasons. They can be customized to fit an organization’s needs. They offer a way to avoid software licensing or subscription headaches, as well as vendor lock-in. And because they’re distributed without charge, they sometimes can save a business money.

There are also hidden costs connected to these tools.

Learning curve:

Open source software doesn’t always have intuitive interfaces so it can be difficult to learn. That means training may be necessary and reduced productivity can be expected as users advance up the learning curve.

That’s especially true when developers are asked to perform security tasks earlier in the application development lifecycle. Many developers have limited experience writing secure code. In addition, creating consistent, repeatable processes that enable developers with a variety of skill sets to find and fix security flaws can be challenging.

If the interface for the tool has to be redesigned, that’s another expense that has to be taken into account.

Installation:

The tools can also be challenging to install. If an organization has a strong IT department, that might not be a problem. If it doesn’t, outside help may be necessary. That kind of help can be expensive.

Even with a strong IT presence, open source tools can require large time commitments from an enterprise.

Customization:

The same is true for customization. If an organization has the IT chops to fiddle with an application, an open source tool may be able to meet its needs. If not, it may find itself buying add-ons to get a job done or worse, upgrading to a “premium” version of the tool, which comes with much of the baggage—and expense—of a commercial solution.

Support:

Support, too, can be a problem. Unlike commercial software, help isn’t a phone call away. If something doesn’t work or breaks and a shop doesn’t have an IT department or in-house tech guru, more expenses will be incurred.

Granted, the idea behind open source software is its community provides the support that in the commercial world is found on a help line. Not all open source projects have large communities, though. Even for those that do, finding information can be challenging. It may require combing through thousands of postings written in forums over years.

What’s more, the quality of the postings can vary. They are written by people with a variety of experience and knowledge of a tool. Some may even know less about an application than the person seeking information about it.

Remember, too, that the costs of an open source solution are ongoing. Resources have to be continually dedicated to updates, patches, maintenance and training existing and new users. Failure to do so can have disastrous consequences, as Equifax found out when it failed to keep its Apache Struts web framework up to date.

As organizations try to get greater developer participation in securing their applications, they’ll need to provide those developers with tools that are intuitive to use or better yet, integrated into the life-cycle process itself where a minimum of human intervention is necessary. That way many of the hidden costs associated with existing tools can be avoided.

Was this article helpful?

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

How can we help you?