The 3 Pillars of Web Application Security

In web application security, as in other areas of the tech industry, we tend to focus on the tools and all the new and exciting features they bring. Choosing the right tools is crucial, but tools don’t use themselves, so they are only one of the pillars holding up your AppSec roof. To get the best from your tooling, you need the right workflows – and to get those, you need the right internal structures and security culture.

The 3 Pillars of Web Application Security

Pillar One: The Right Tools for the Job

Picking your tools is both the easiest and the hardest part. It is easy because you are spoiled for choice in the current market. On the other hand, it can be tricky because your choice of tooling will affect security, development efficiency, and (ultimately) the company’s bottom line. It’s a complicated balancing act between the scope of testing, application security, workflow efficiency, usability, and overall cost.

Quality Tools for Quality Results

The purpose of tools (not just in IT) is to make work easier, faster, and more effective. To get all those benefits at a professional level, good tools are a must. Inadequate or inaccurate tools generate hidden costs due to extra manual work and rework.

For example, think of a furniture maker cutting some boards on a high-end professional saw, where every cut is straight and accurate and each board is immediately ready for use. Now imagine doing the same work on a cheap home-center saw, where each cut is followed by lots of extra work to correct everything the cheap tool did wrong. Which saw would you choose for a full-time professional workshop?

Going back to security, in smaller environments, you might get away with manually correcting minor inefficiencies and inaccuracies. But if you need to scale web security to many hundreds of websites, applications, and services, these small inefficiencies will quickly multiply, making it impossible to automate security testing to the same extent as application development.

You don’t see home-center tools in professional manufacturing plants – yet many organizations still believe that home-center web application testing should be good enough for them.

Know Your Tool and Know Your Vendor

Whatever tools you end up selecting, they won’t run themselves – you need to set them up and know how to get the best out of them. This is especially important in web application security testing where each organization has its own unique environment, requirements, and challenges. Having the right tool and the right vendor support from the very start can make the difference between getting results and value within days and struggling for weeks or even months just to set up a working toolset.

Pillar Two: Processes and Workflows

Modern software development relies on heavily automated workflows that enable developers to focus on business logic rather than the nuts and bolts of working with ever more complex web frameworks. To be truly effective at scale, web application security tools need to fully integrate into the software development lifecycle (SDLC) so they are launched automatically and feed the right tasks and information to the right people at the right time.

Integration is often one of the hidden costs of tooling. Making a new tool work in an existing environment could potentially mean weeks of configuration work, adjustments to existing processes, and custom scripting or coding to glue it all together. On the flip side, having out-of-the-box integration with popular issue trackers, collaboration platforms, and authentication methods can save lots of time – and money.

Having said that, each organization and each web application environment is unique, so there is no ready one-size-fits-all security solution. Some organizations will only need to tweak and configure an existing product while others may wish to pick and mix to fit selected features and data sources into a mature security testing environment. This requires solution flexibility on every level, from setup and deployment right through to UI-based configuration and internal integration APIs.

Pillar Three: Building a Security-Oriented Culture

And now we get to the toughest part of the AppSec puzzle: integrating security into the application development culture. While software development has grown in leaps and bounds over the past decade, security testing is lagging behind. In many organizations, software security is still treated as one final thing to check before a release, not an integral part of the development process. In other words, security bugs are treated differently from typical software bugs – often because the security and development teams work separately.

To match the agility of modern DevOps workflows where application development is integrated with operations and maintenance, security needs to move out of its ivory tower and into everyday development work. This requires the right tools, workflows, and integrations – but above all, it needs the right company culture. We can talk about building DevSecOps all day long but it’s not going to happen until security is everyone’s concern, not something that “security people” use to persecute “development people”. In a perfect world, application security would be handled within development teams to eliminate communication overhead and improve code security in the long run.

Again, having the right tools can go a long way towards minimizing internal friction and gradually moving application security considerations to earlier stages of the SDLC (also known as shifting left). If you can automate security testing and be sure that you are only passing valid issues to the developers, any cultural and organizational changes related to application security will go more smoothly and, ultimately, yield better results. Even so, changing organizations is a slow and difficult process – and changing people’s habits is even harder. This means you also need the flexibility to get measurable value from your tools no matter where you are on your security journey.

Putting It All Together

If you’ve been following this blog for any length of time, you will know that we firmly believe that a quality DAST solution is a vital part of every AppSec toolkit due to its versatility and broad coverage. Whether used standalone or in combination with other application security testing methods such as SAST, a modern DAST solution like Invicti is the central pillar of your application security program.

To build up the remaining two pillars, you need to know your current maturity level and have a plan for integrating security into your SDLC. As your workflows and culture change and mature, your tools will need to keep up so you can continue to get security benefits (i.e. actual value) from your investment.

In the case of Invicti, you always benefit from a mature and accurate scanning engine with Proof-Based Scanning to deliver high-quality results based on broad test coverage, including authenticated scanning. With a wide array of integrations and an extensive internal API, vulnerability report processing can be automated whenever your workflows are ready for it. And best of all, our technical support and customer success staff are always there not just for troubleshooting but also to help you grow and adapt across all 3 pillars of web application security.

Zbigniew Banach

About the Author

Zbigniew Banach - Technical Content Lead & Managing Editor

Cybersecurity writer and blog managing editor at Invicti Security. Drawing on years of experience with security, software development, content creation, journalism, and technical translation, he does his best to bring web application security and cybersecurity in general to a wider audience.