Choosing the Best AppSec Tools: Advice from Experienced Engineers

  • Share on Twitter
  • Share on LinkedIn
  • Share on Instagram

In our latest webinar Gary Robinson and Martin Hewitt from Uleska gave us a fascinating and comprehensive look into how experienced security teams choose application security tools.

They spoke about how the AppSec tool landscape looks at the moment and how organisations can determine which toolset is right for them based on how they build their software, their technical stacks, budgets, and team cultures.


We’ll have a quick look at some of the points covered below, and you can get the full webinar on-demand over here. It’s jam-packed with advice you can put into practice straight away, and illustrative case studies to guide your thinking.


Today’s application security tool landscape

Gary describes it in one word: Broad. Well-known testing environments like Kali Linux have over six hundred tools wrapped into them, with hundreds of commercial and other open source tools out there. So how do we decide which ones to choose and which will be effective? “It’s about the right tools in the right order as you grow your application security programs”, Gary says.

Categories of Security tools

Categories of Security Tools

It’s helpful to look at the tools in terms of release cycle areas so you can determine exactly where application security tools will have an impact at a pipeline level:

  • SAST: These are tools that check source code or binary to find flaws or vulnerabilities like SQL or Command injections
  • IaC: A slightly newer set, these tools test your Terraform, cloud formation, dockerfiles and such to see if there are any problems with how the code is used
  • SCA: These tools check third party libraries or dependencies you’re using for known problems and any necessary upgrades
  • Containers: Tools aimed at locating and reporting on flaws within your images
  • DAST: Tools that send traffic to running systems to find responses and point to any security flaws
  • IAST: These act like a WAF and a SAST together to add a layer inside your programs that can spot and relay flaws
  • Cloud and infrastructure: Tools that check for flaws like if your S3 buckets are lying open, what your IAM looks like from an infrastructure point of view, what systems you have running, and if any patches are needed

Gary notes that he’s seen many security programs which have to combine different aspects of each tool category to build up the required level of coverage for daily releases. And with things moving at such a speed, it cannot be a manual process.

Commercial, Open Source & Custom Application Security Tools

We’ve gone through the kinds of tools that can be plugged into each stage of the pipeline, but what classification of application tools exist? There are generally three kinds: Commercial, Open Source and Custom. And each comes with benefits and drawbacks. 

Commercial Tools

Commercial tools cover a wide range of security controls and are usually easier to use, but they come with a price tag that might be prohibitive for smaller outfits, or across all projects in larger companies. 

Open Source Tools

Open Source tools like OWASP and Kali Linux are free but generally come with less functionality and reporting abilities. 

Custom Tools

Custom tools are generally developed in-house and provide a level of niche coverage specific to business logic or product authorisation that off-the-shelf tools simply can’t. Still, again, they are restrictive in false-positive functionalities and recommendations and are hard to automate into an AppSec program. 

Determining which is right for your organisation combines internal aspects like culture and technical fit and external considerations like regulations.

How to Choose the Right Application Security Testing Tool

Regulations and Standards fit

The way we test has moved on leaps and bounds in the last few decades. In the past, we would have had penetration testing exercises conducted by manual teams or outsourced companies. They would run tests to check systems that we implicitly assumed would cover the whole security scope. In today’s release world, where automation is key and shifting left is crucial, this type of long-tail testing throws up security gaps. And therein lies risks.

What security do we care about?

You might be a mid- or enterprise-sized organisation having to adhere to specific regulations, or you’re a smaller outfit or SME selling into these larger companies, so you will have to adhere to them too. Companies have various standards they need to check, and by bringing them together into a list of controls, it can tell you what you need to check for down to the technical level. Standards like NIST or OWASP list hundreds of controls to test for. When you have a list, you understand the controls each tool tests for and can map the coverage your organisation needs.

For more on this, check out the full webinar here.

Plugging manual gaps with feedback loops

Plugging manual gaps

The goal is to get to a stage of plugging controls that are manually testing gaps with automated coverage. When you start seeing the same categories of results in automated testing, you can then add automated tools to address those fixes.

Technical aspects to determine fit

Technical Aspects to determine tool fit

How your company is set up will rule in or rule out certain tools. There’s generally a 50/50 split of internal and external technical aspects informing security tool decisions. For example, based on your setup, do you require tools that run only in the cloud? What languages are you working in? If development teams are running in C# there's no point in running a tool that will only check a different language  as it’s not relevant to you. 

An outcome-first approach

The main thing is to ensure that application security testing isn’t tied to the tools you want to use or have used in the past. It must be built around the controls you need to test for and the programs you want to run.

Cultural fit to determine tool choice

No matter the size of the organisation and the amount of tools running, the program needs to work for every team. That’s why it’s crucial to think in terms of risk, not vulnerabilities.

Think in term of Risk

Language matters

Risk conversations can help make a case for security because it ensures a complete understanding of the risk context across all teams. For example, you could state that you have to fix an XSS vulnerability, but project managers and other stakeholders won’t understand this or grasp the gravity of the situation. Stating that it’s a $30 million risk, on the other hand, is a fact hard to ignore.

Determining tool fit: Context drives decisions

The fact remains that many companies believe they have a certain level of coverage operating the tools they like, know or have used before. But coverage comes with joined-up thinking: you understand the controls, map them to tool technicality and know what works culturally for your organisation. For automating security effectiveness and for teams using and understanding security, context is key.

For lots more on how to determine the right security tools, watch the full webinar here. And for more on AppSec automation, check out our previous webinars and our blog, play around with a free Uleska account or reach out to us for a chat.


overcome the challenge of devsecops

Subscribe to the Uleska blog

You may unsubscribe at any time using the unsubscribe link in the newsletter.

Popular Articles
Visit the Blog

Open Source Security Testing Tools

Security tools are an essential part of software development today, especially with the ever-increasing number of attacks we see every year....


Security Orchestration Automation and Response (SOAR)

Security teams frequently struggle with the volume of alerts and issues they are tasked with daily. On average, most enterprises receive between...


Secure Software Development Life Cycle

Software development has evolved into an incredibly complex machine, with several moving parts to keep track of. Teams get more extensive, and...


Application Security Orchestration & Correlation

Application Security is a constantly evolving industry, with new threats and methods to combat them appearing regularly. One of the more recent...


Top 5 AppSec Productivity Hacks 2022

The application security (AppSec) industry moves fast. Development, security and operations (DevSecOps) practitioners are having to find creative...


How to improve security tool selection and customisation with Uleska Toolkits

We know starting your application security (AppSec) journey can be a little overwhelming. After all, choosing your tools from scratch and setting...

Application Security

What is Application Security? A Beginner’s Guide

What is Application Security? Application Security is defined by developing, adding, and testing security features in an application or website....


Vulnerability Assessments in Application Security

Did you know that over 79% of developers surveyed in 2020 stated their applications had 20 or more vulnerabilities on average? As the digital world...


Defining and breaking down Vulnerability Management

No system is perfectly secure, as proven by software analysis firm CAST, which reviewed 278 million lines of code and discovered more than 1.3...

Company News, Featured

Toolkits: Taking the guesswork out of security tool selection and customisation

There are thousands of amazing AppSec tools out there, but this can be both a blessing and a curse. While the headway and innovation we are seeing...


How to eliminate risk when scaling application security

Building robust application security is a lot like building a house—you want it done thoroughly, without any missing parts. However, there is a...


What is the OWASP Top 10 and how to use it?

Cybersecurity has been a rising concern in the last decade. In 2021, researchers have seen 50% more attacks per week on corporate networks compared...


What is Shift Left? Ultimate Guide to Shift Left Security

With today’s fast development speeds, it’s hard to keep up with security practices for some organisations. This is especially true in the last few...


What is Software Composition Analysis?

Open-source software has become a vital part of development in the last decade. However, utilising these components often comes with several caveats,...


DevSecOps tool examples that will alleviate your workload

The saying goes: “Many hands make light work.” Nowhere is this more apparent than in DevSecOps where developers and releases outnumber security...