7 reasons why development teams skip security steps

The Fall 2021 Invicti AppSec Indicator has made us aware of an incredibly high percentage of development teams that have admitted to skipping security steps. There is a 70% chance that this happens in your business, leaving your web applications exposed to malicious hacker attacks. Here are potential reasons that you should explore as a business leader, along with ideas on how to eliminate these causes as quickly and as easily as possible.

Reason 1: Lack of example from the top

The primary reason why development teams skip security steps is that they do not think these steps are important. And the example comes from the top. If business leaders make excuses and do not care enough about web application security, developers and their managers are rarely going to take care of it by themselves. They are overworked enough without also worrying about keeping their web applications properly secured.

There are different ways to demonstrate a focus on web application security, but it all begins with acknowledging it and differentiating it from other cybersecurity areas. If your business invests in endpoint security solutions like antiviruses and network security solutions such as firewalls but makes zero investment in web application security, that’s exactly what you can expect of your development teams.

To rectify this:

• If you are a business leader, emphasize your interest in web application security.
• Make sure both you and your teams are aware that web application security is not covered by endpoint/network security at all.
• Support and promote investment into automated tools such as Acunetix to help secure your websites and web applications.

Reason 2: Harmful security assumptions

Many business leaders are aware of web application security, knowing both that it must be addressed and that it is not included in endpoint/network security. However, they may also feel that their web applications do not require any internal security steps. Here are some reasons why:

• Assumption 1: Externally built applications are safe because the application provider takes care of web application security. If your web application is not developed by your business directly but by a third party, or if it is open-source like WordPress, you might assume that the creators ensure sufficient web application security. This is, however, usually not true.
• Assumption 2: The application is for internal use or controlled use. If you allow only internal network access to an application or you control the range of IPs that are allowed to access it, you may think that the application is safer. It is not: many, if not most, attacks are initiated by employees or their associates.
• Assumption 3: The website/application is not at risk because it is simple. This is a common assumption for example for marketing sites or other types of websites with no sensitive data. However, such sites, if vulnerable, may lead to privilege escalation and allow the attacker to easily access other, more critical systems.

As a result of such assumptions, the situation is similar to that described in reason 1: development teams don’t have the time or the tools to take care of web application security at all and the best you can hope for is a few security-conscious developers who will painstakingly try to rectify this problem on their own. While you can, of course, prioritize securing some applications over others, you cannot skip any of them in your security program.

To rectify this:

• Take responsibility for web application security even if you believe that a third-party creator also follows web application security practices. Invest in your own tools or hire an MSSP.
• Treat every web application and website as part of the attack surface – even internal ones and even the simplest websites.

Reason 3: Lack of time and resources

Let’s assume that business leaders are aware of the importance of web application security and ready to invest in tools but don’t realize that web application security takes extra time and resources. For example, writing a simple form takes a few seconds. Writing the same form with suitable cross-site scripting protection routines takes at least a few minutes. If developers are pushed for time, they simply won’t have time for secure coding practices.

It’s the same with tooling. While top-class DAST tools used in the SDLC don’t hog the pipelines, they still add some overhead on top of existing QA testing time. Business leaders must be aware that to maintain web application security, development teams need extra time and effort. And they must make sure that developers feel comfortable with taking this time and not rushing. If developers, due to time constraints, only have time to search for code online and then copy and paste it into your application, you can only dream of web application security.

To rectify this:

• Allow for slight development delays, especially while your teams are getting used to focusing on web application security.
• Make your development teams comfortable by expressing that you’d rather have them spend more time writing secure applications than rush a release by copying-and-pasting vulnerable code from outside.

Reason 4: Security and development silos

Many businesses see the term “security” and automatically assume that everything associated with this term should be handled by a specialized security team. Unfortunately, this is not the best choice for web application security. Another mistake made by many business leaders is assuming that experts on endpoint/network security know how to handle web application security because they rarely do.

As a result of these misconceptions, many businesses end up with a cybersecurity team that works completely separately from the development team. If the cybersecurity team handles web application security at all, they do it only at late stages (staging, pre-production, or even live production only). As a result, web application security issues end up being fixed weeks or months after they have actually been introduced with nobody really knowing what happened.

To rectify this:

• Make sure that cybersecurity teams and development teams are not separated. You can even assign a web application security expert to work directly within development teams.
• Put development teams in charge of fixing problems that are discovered early on in the software development lifecycle by automated tools such as Acunetix. Security teams should be involved only with the initial configuration and/or maintenance of such tools, not their everyday operation.

Reason 5: Lack of suitable education

Developers are usually well-schooled in many aspects of information technology. However, many developer schools don’t have the faculty to teach web application security due to a huge cybersecurity skills gap. Businesses find it hard to get cybersecurity experts, let alone educational institutions that often can’t compete with businesses financially. As a result of this lack of teachers, many developers are taught everything except how to create secure code.

If you, as a business leader, emphasize the importance of web application security, inexperienced junior developers may feel very anxious about their abilities in this aspect. It is your job not just to tell them that they are expected to pay attention to security but also to help them learn about security and feel comfortable doing so. This involves, again, having senior developers as well cybersecurity teams work together with junior developers to provide practical instruction on avoiding security vulnerabilities in their code.

To rectify this:

• Make sure that junior developers are not punished for their lack of security knowledge/experience and are not afraid to ask for help.
• Foster development team security champions and give them the time and tools they need to teach others how to avoid and fix web application security vulnerabilities.
• Use existing resources, such as articles on the Acunetix blog and site, to teach juniors about different vulnerabilities and how to avoid/fix them. Start by simply searching for the name of the vulnerability on the Acunetix website.

Reason 6: Having to fix someone else’s mistakes

Even if you foster security champions and they teach junior devs about avoiding security mistakes, without suitable controls to check how developers are doing, the progress ends up being slow. In an environment where web application security testing is only performed in late stages such as staging/pre-production or even live production, developers have no idea whether they’ve made a mistake. Issues can surface weeks after they are introduced, so even if they do go back to the original developer, that developer will remember very little about that code.

In an ideal environment, code should be tested for security vulnerabilities at the same time as it is being tested for functional correctness. This means that security verification should be performed along with QA testing. Your security tool should run right before or right after your Selenium tests (or whatever other test automation you use).

To rectify this:

• Integrate your security tool such as Acunetix with your CI/CD environment so it is part of regular development pipelines.
• Run a web application security scan not just for releases but for every new commit that goes into your master branch.

Reason 7: Frustrations due to bad tooling

At this stage, let us assume that you have analyzed and/or rectified all the listed problems. However, if your choice of tools was bad, you may still end up with developers skipping security steps simply because they can’t be bothered with a tool that makes their work harder, not easier.

The biggest problem for developers is false positives. If every report from your tool might be a false positive, developers are often going to waste tons of time trying to find problems that aren’t there at all. One false positive may mean ten times more work for a developer than a real vulnerability!

To rectify this:

• Don’t base your security on SAST tools alone – if you must use a SAST, use it together with a DAST. SAST tools are very likely to produce lots of false positives.
• Invest in tools that are designed to eliminate or help you control false positives. For example, Acunetix uses proof-of-exploit technology and confidence ratings to show you which vulnerabilities are definitely not false positives, so you don’t waste your time chasing phantoms.

Efficient security comes from business leadership

As you can see, while it is the development teams that actually skip security steps, it is their business leaders who make core mistakes that lead to this situation. That is why you cannot just assume that having security measures is the same as having effective web application security – and why you cannot simply blame your development teams for wrongdoing.

Luckily, you can rectify this situation with some simple measures while also strengthening security by choosing the right tool for the job. And Acunetix is the security solution to get you there.

THE AUTHOR

Tomasz Andrzej Nidecki
Technical Content Writer

Tomasz Andrzej Nidecki (also known as tonid) is a Technical Content Writer working for Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.