Wednesday, 7 October 2020

Should you arm your SaaS software engineers with a web app vulnerability scanner?

Vulnerability scanner for cloud software development teams

Web application vulnerability scanners have been around for a long time. And they've been ignored by most software engineers for a long time.

Isn't it strange that the very people who build amazing software completely ignore other novel software that helps them secure their creations?

Why do software engineers not like vulnerability scanning tools?

There are many reasons behind this, but a primary factor is likely to be software engineers' lack of acknowledgement that they are responsible for securing the code that they write. Not the testing team. Not the security team. But the software engineer herself is responsible for building secure features. 

If you think that's a novel thought, there's a compounding problem: most software engineers don't trust application security teams and products, like vulnerability scanners. 

Given that very few software engineers take application security papers during their university education or in their formative professional years (primarily because few universities require that they be taken?), it follows they're more focused on building cool new features and not so much on building cool AND secure new features. 

But those blind spots lead to these problems:

So as a tech decision maker, when you thrust an application security assessment or a web app penetration test on your engineers, they're naturally weary of what they're going to face.

Let's call a spade, a spade: they're afraid of being made to look bad. It's that perception of professional embarrassment that they are really dreading.

But this sequence of facts and emotions leaves you, as a decision maker, in no-man's land. How do you deal with your engineer's emotions as well as solving your application security headaches?

To solve this conundrum, we need to dig a little deeper.

Does human nature cause software developers to dislike application security tools?

The weariness stems not just from a lack of technical understanding about the application security process, but also because it's natural human nature as Harvard Business School's Michael H. Yeomans puts it in his recent study, "people are less willing to accept recommenders when they do not feel like they understand how they make recommendations.”

The mistrust of recommendations from other seemingly learned professionals is only exceeded by humans' mistrust of technology, as Cornell's Jon Kleinberg and University of Chicago's Anuj Shah and Sendhil Mullainathan found in the paper with Yeomans, "there’s a mistrust in algorithms. People seem to view them as a cheap substitute for human judgment."

You'll agree that the above comment is especially true of technically advanced people who often mistrust advanced technologies (not built by them), often just because they don't have the time or requisite knowledge to understand it in greater depth. 

Cornell University's Malte Jung has studied the human-robot interactions in everyday work environments, specifically about how . He says, "human-robot interaction is not just about how you interact with technology, but how the technology affects how people interact with other people.” 

“It’s about moving beyond this one-to-one paradigm between a single human and a single robot into a group and team context because, the fact is, people rarely work alone," says Jung. 

And therein lies one of the big problems with application security tools robots. They are mostly designed for security testers conducting web application penetration tests, who are working alone. This setup is likely very different to the dynamics of your software engineering team, who are constantly collaborating with each other using developer tools like Jira or Github or Slack/Teams, etc. 

Cyber Chief is a cloud-based vulnerabilty scanner that is built for SaaS engineering teams.
Want to see how it could help your software developers find & fix security vulnerabilities by themselves?



Are vulnerability scanners "developer-friendly"?

In the case of vulnerability scanning tools, software engineers' mistrust is not solely a case of age-old human behavioural patterns. 

As I showed you before, most application security tools were built for cybersecurity experts - the ethical hackers of the world. They were not built for software engineers.

Most vulnerability scanners are not easy to set up, not easy to use and definitely do not help you patch a vulnerability unless you're willing to spend endless days scouring Google. They require tinkering with various add-ons and plugins just to run a scan. 

When you're giving your software engineers tight deadlines and overloaded sprints, I think they can be (somewhat) forgiven for focusing on finishing their day jobs, rather than engaging in hand-to-hand combat with a vulnerability scanner just to run a vulnerability scan!

My criticisms above are true for most of the bigger names in the vulnerability scanning field. However, there are at least two more modern vulnerability scanners that are actually built for software engineering teams that have no or very little application security experience.

Does your software engineering team need a web application vulnerability scanner?

The answer is yes, if you answer yes to any of these questions:

  • Is your software constantly enhanced or worked to improve it or add new features?
  • Do you have cloud software penetration tests performed on your software? 
  • Does your cloud software store or access data that your users will want you to protect?
  • Do you have a ISO27001 or SOC2 or equivalent accreditations?
  • Is your development outsourced to an external team or company?
  • Is your cloud software used by enterprise customers or are planning to get more enterprise customers?

Answering yes to any of the above questions means that your software is being modified often enough; and/or that your users expect you to keep their data safe; and/or you need to prove to enterprise customers or auditors that you have a consistent and strong application security program in place. 

Add to this the fact that most software breaches are a result of available patches or code fixes not being inititiated by the software engineering team, despite being readily available. I could present you a slew of numbers on this, but take this as just one very common example:

Vulnerability scanner for cloud software development teams

SQL injection is a vulnerability that has been well known, understood and patchable for well over 2 decades. Yet, such vulnerabilities are routinely introduced and reintroduced into software and not picked up until an external consultant performs their penetration testing services.

You can't blame sofware developers for not fixing a vulnerability if they don't have access to a vulnerabilty scanning tool that's made for SaaS engineering teams in the first place, can you?

When you combine the above variables with something as worrying as the following statistic, it becomes clear why you need to provide your software development team with a vulnerability scanner that can help them find and fix vulnerabilities on their own:


Now, the only remaining question to ask is:

Is there a vulnerability scanner that is built for software developers?

TL;DR Yes, there is. Click the "Get Your Free Trial" link at the bottom of this article to see how it might work for you. 

But in case you don't trust my recommendation, let me first briefly explain to you what makes a web app vulnerability scanner suitable for use by your software engineering team.

There are seven key things you must consider when choosing a vulnerability scanner for your software team:

  1. Do you need a dynamic scanner that actually attacks your web application or just a static scanner that identifies vulnerable code? Ideally, you should have both because they help you in different ways. 
  2. Does the vulnerability scanner provide fixes for each vulnerability in the languages that your application is built with? If not, your engineers will become frustrated and confused as they waste their time trawling through Google for the right fix.
  3. Dashboards - they're not there to only look pretty, but to also give a complete picture of your application's security posture.
  4. Vulnerability management - it's no good just finding vulnerabilities. They have to be ordered, presented and managed automatically for you in a way that helps your team assign accountability, collaborate where necessary and prioritise which vulnerabilities need to be fixed first. 
  5. How easy is it to use the vulnerability scanner? Can your team initiate scans with just one click or do they need to maintain different scripts and add plugins just to run a scan?
  6. Is the vulnerability scanner cloud-based or do each of your engineers need to install different packages on their local systems? 
  7. Does the scanner work with your DevOps or CI/CD deployment pipelines and processes?

You'll notice for some of these key considerations, there is no right or wrong answer. For example, a cloud-based vulnerability scanning tool might not work for all corporate environments that are heavily firewalled. 

On the other hand, it's absolutely crucial that the vulnerability scanner you choose has best-practices fixes that are relevant to your tech stack, along with an insight dashboard and full vulnerability management and collaboration features. 

It's not hard to find a vulnerability scanner that find all our vulnerabilities. It is hard to find one that will also be easy to use, require almost zero setup and won't slow down your software development team. 

We know this because we conducted primary product research with respected security experts and software engineers around the world. Then we designed, built and enhanced our own web application vulnerability scanner, Cyber Chief. 

Click the button below to get your own free trial of Cyber Chief to see how it works in your environment, on your cloud software and for your software engineering team.


 
–>