Straight Talking: Why application security testing practices need to change

Hi Sam, Sure. With the significantly increased pace of development, organizations can no longer rely on a very small and understaffed AppSec team, or external pen testers to secure their applications and APIs. They have to leverage the much larger developer teams.

Our platform enables development teams to carry out application security testing within the development cycle rather than at the end when they think their job is complete while enabling the AppSec team to provide the required governance.

Well, that sounds simple, but why’s it so important?

Current practices add considerable time and cost to DevOps when organisations are placing greater emphasis on them. As a result, development teams are coming under increasing pressure to reduce lead times and improve performance.

Balance that with the fact that security risks are growing at a faster rate than ever before, it becomes a fine balance between pressure to perform and compromise in working practices. 

Organisations now even have a name for it – Security Debt. With almost 90% of organizations knowingly releasing vulnerable applications and APIs into production because they don’t have a choice, something has to change.

So, organisations are potentially releasing applications with inbuilt security defects? Surely, with the breaches we’re all aware of, that poses a massive risk?

Yes, it does.  What’s important to recognise though is no business can ever be totally without risk.  Most industry leaders recognise this and focus on stopping the big threats and limiting the impact of lesser ones.

That’s what you mean about balancing pressure to perform and compromise then?

Absolutely.  The real issue for businesses is how they manage to implement the necessary security practices without compromising the efficiency of delivery. This has always been a challenge, but the explosion in Apps and APIs used for mainstream activity has changed the dynamic.

And how does Bright Security change that?

Traditionally, security testing is the domain of security teams and takes place after the completion of the App development cycle, increasing the cycle timelines and often leading to the significant reworking of code, none of which is scheduled.

To accommodate the new demands, development teams are beginning to take responsibility for security within their development cycle, but only a quarter of vulnerabilities are identified at this stage.

A developer-focused DAST solution can help address this, but less than 19% of companies have a DAST.  Of those, less than 10% are run by the development team. Why? Because traditional DAST requires specialist skillsets only found in the security team and they’re not automated, resulting in significant false positives.

Research shows that implementing DAST as part of the SDLC enables to reduce the time to remediate vulnerabilities by 25 days on average. That is a very significant impact!

How does that impact the role and remit of security specialists?

We recognise the importance of the security specialist, but they are just that – specialists, so they need to focus on those big risks we spoke about. They already have massive demands on their time and have an ever-increasing number of releases to review.

They need to focus on providing the governance and defining what and how to test and tracking significant risks, but not do all the work themselves.

Did you know that the latest estimates suggest that over 50% of all businesses are now releasing 100X the code they did 10 years ago? You’ll never cope with that volume if you rely on manual pen-testing.

I can see your point, but what’s so special about your Platform?

Although our platform would normally be classified as a DAST, we talk about ‘developer-focused DAST’ because we’ve automated a number of actions that would otherwise require specialist manual input.

Most important is our AI that ensures no false positives so development teams can use our platform without needing specialist security training.

Also, we automatically provide everything they need to remove the risk in the code, so they don’t need to reference any other tools, engage other teams – it’s all there for them in the platform.

We recognised the need to make any technology readily available to everyone – you can’t have barriers because only half your team can access the tool.

Our platform is cloud-based, with unlimited users so, once implemented, it's available to the entire DevOps team wherever they are. Traditional DAST’s don’t accommodate this, so introducing them has significant operational and financial barriers.

We recently attended a webinar with DNX Ventures, a leading US Venture Capital consultancy specialising in the tech sector. One of the speakers was Omkhar Arasaratnam, formerly Executive Director, Head of Data Protection Technology at JP Morgan Chase & Co. He described the legacy development practices are still influencing how we treat security.

He talks of how the old waterfall methodologies have been replaced with more agile, sprint-based approaches more suited to our new economic landscape.

When you listen to what he says, you can see the issues and what needs to change. He did have some other take-outs worth sharing:

• You can’t 'bolt on' security in DevOps
• Security management and software development must occur in parallel, not serial
• Integrating security early and iteratively saves time down the road
• Developers like security fact, not security hyperbole - he could be from Yorkshire!
• Automation and consistency yield secure results

Can we access the webinar?

Of course. Here’s the link

The biggest take-out I got from Omkhar was the need to bring security testing into the development arena and, with his background, he should know.

The reality is that you can’t achieve this without automation.

Which is why this is the right time for Bright Security?

I don’t want to be just another voice shouting about the pandemic, but the reality is that Covid accelerated the onset of the digital economy by more than 7 years and security has to keep up.

So it’s not the right time for Bright Security. It’s the right time for a new ‘modern’ DAST. We just happen to have developed one, so here it is!

Thanks for your time, Richard. Have you got any questions for me?

Yes. Don’t you want to know what our platform’s called? ;)