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.
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.
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:
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.
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 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 like OWASP and Kali Linux are free but generally come with less functionality and reporting abilities.
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.
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
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.
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.
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.
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.
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.
You may unsubscribe at any time using the unsubscribe link in the newsletter.
Security tools are an essential part of software development today, especially with the ever-increasing number of attacks we see every year....
Security teams frequently struggle with the volume of alerts and issues they are tasked with daily. On average, most enterprises receive between...
Software development has evolved into an incredibly complex machine, with several moving parts to keep track of. Teams get more extensive, and...
Application Security is a constantly evolving industry, with new threats and methods to combat them appearing regularly. One of the more recent...
The application security (AppSec) industry moves fast. Development, security and operations (DevSecOps) practitioners are having to find creative...
We know starting your application security (AppSec) journey can be a little overwhelming. After all, choosing your tools from scratch and setting...
What is Application Security? Application Security is defined by developing, adding, and testing security features in an application or website....
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...
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...
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...
Building robust application security is a lot like building a house—you want it done thoroughly, without any missing parts. However, there is a...
Cybersecurity has been a rising concern in the last decade. In 2021, researchers have seen 50% more attacks per week on corporate networks compared...
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...
Open-source software has become a vital part of development in the last decade. However, utilising these components often comes with several caveats,...
The saying goes: “Many hands make light work.” Nowhere is this more apparent than in DevSecOps where developers and releases outnumber security...