Never mind the buzzwords: Here’s the straight deal on application security

Buzzwords are a fact of life in the tech industry, especially in its more nebulous corners like cybersecurity. As the name implies, they crop up whenever buzz builds around the Next Big Thing. After a while many get overused, bleached out, watered down, or stretched to breaking point until they morph into the next buzzword. Yet, while they last and are understood, they provide a crucial shorthand for talking about complex topics. Is it even possible to discuss application security without them?

In a recent Invicti panel discussion, two seasoned CTOs hammered away at the buzzwords to expose the real core of application security: knowing and applying best practices. Ken Schirrmacher of Park ‘N Fly joined Invicti’s Frank Catucci to tackle the key security questions facing development leaders today, stopping along the way to deflate some AI hype. This post zooms in on their discussion of trends and best practices in securing web apps and APIs—away from all the buzzwords. Watch the full panel session for many more AppSec insights:

DISCLAIMER: No buzzwords were (permanently) harmed during the making of this article.

Shifting away from shifting left: It’s all about testing early (when you can)

Shift left is probably the oldest buzzword in application security. Depending on the year, company, and product, shifting left could mean introducing security testing into development, testing earlier than before, or extending staging-level testing to kick off earlier. The phrase originated at a time when security testing lived only on the right of the software development process and timeline—if it was done at all. Today, when most development pipelines incorporate some form of security testing (most often SAST), shifting left is a more ambiguous concept: what are you shifting, how far are you shifting it, and is there even anything left to shift?

The related concept of shifting right was coined in reaction to some organizations doing security testing in development (on the left) but not in staging or production (on the right). In practice, this boils down to doing security testing everywhere you can, as Ken Schirrmacher is quick to point out: “If you’re in IT, you already know the best points at which to implement security best practices in your development lifecycle,” he says. 

Some marketing person created the shift left and shift right terms, and it became a buzzword in the industry. But, realistically, you know when you should be scanning, it’s just not always what is done.

— Ken Schirrmacher, CTO and Senior Director of IT, Park ‘N Fly, Inc.

At the same time, Schirrmacher has no doubt that there are real advantages to bringing in security as early as possible: “The prize for getting it right is you get better software quality overall, and you don’t risk having to back and redo everything because you only found a security issue at the very end.”

Beyond improving security, following security best practices already during development (i.e. shifting left) can also have cost and compliance benefits. “It’s cheaper and easier to fix vulnerabilities before they make it to production than to back it all out and rerun it through the pipeline,” explains Frank Catucci.

There are also things that you simply can’t test for earlier, like vulnerabilities caused by the deployment configuration or issues involving APIs, and that’s the shift right.

— Frank Catucci, CTO and Head of Security Research, Invicti Security

When it comes to compliance, you often need to pick the most efficient route: “For the compliance itself, it doesn’t matter what you’re doing on the left,” says Catucci. “But if you can minimize the vulnerabilities that make it into production and also quickly fix any that are found, you’re saving a lot of time and money for yourself.”

Cutting AI down to size: Come back when you have reliable results

When user-friendly generative AI rapidly inflated an unprecedented bubble of hype and expectations, AI immediately became a tier-one buzzword thrown around by anyone and everyone in the tech industry, cybersecurity included. At one point, it seemed like a race between tech vendors to cram an “AI” feature into their offering and announce it as soon as possible. In security, many “AI-powered” products sprung up overnight among startups and established players alike.

Amidst the AI feeding frenzy, CTOs are urging caution, restraint, and informed decision-making when finding use cases for generative AI or building it into live products. This is especially true for software development and testing, as Ken Schirrmacher points out:

We talk about testing and standards that go through our entire process, but AI throws the biggest monkey wrench of all into all of this because you can ask it the exact same question five times and get five different answers. How do I develop a product that will perform well if I get different answers every time and I can’t methodically know how it will perform?

— Ken Schirrmacher, CTO and Senior Director of IT, Park ‘N Fly, Inc.

When it comes to AI-powered security products, the stakes are even higher. “Don’t point me and my development team at something that doesn’t exist, doesn’t happen, or is incorrect in general,” says Schirrmacher, noting that, while promising, generative AI is still nowhere near mature enough to rely on in production.

As the CTO and Head of Security Research for a DAST vendor, Frank Catucci is even more skeptical of AI hype in cybersecurity, especially with the “AI-powered” label now also being misapplied to machine learning (ML). “We as Invicti don’t want to jump on the AI bandwagon to sell anything,” he explains.

Internally, we’re looking at ways to use AI for improved risk profiling and scoring to give users a more focused and less noisy view of security priorities for their finite resources. But we don’t want to say anything like ‘hey buy this, it has AI,’ though a lot of companies are doing that.

— Frank Catucci, CTO and Head of Security Research, Invicti Security

In practice, extracting reliable information from large data sets is far better served by established and mature ML methods than fashionable LLM-based tools, so this AI/ML approach is where Invicti focuses its work on risk profiling.

Dividing by zero (noise): Agile teams don’t have time for security busywork

Automating application security testing is always a balancing act to find as much as you can without raising false alarms. Every vendor has always claimed to have fewer false positives than the competition until this too became something of a buzzword. Instead of misleading and technically incorrect claims of zero false positives anywhere, Invicti uses the term “zero noise” to describe its approach, which is based on proof-based scanning to show which vulnerabilities are exploitable and thus definitely real. That’s a big deal for automating security testing because, in Catucci’s words, “Automation is crucial, but so is accuracy to ensure we’re not wasting people’s time.”

Nobody is in any doubt that automated security testing is now a necessity, if only to keep up with the changing threat landscape. “The level of knowledge that would be required to intelligently talk about every vulnerability that exists out there—I don’t have any full-time resources that have that level of knowledge. And I don’t think there’s any one person that does,” says Schirrmacher. Provided they are regularly updated, high-quality tools can encapsulate the current state of the art in application security testing and take the burden of manual investigation off internal security resources and development teams.

Far from being a hollow buzzword, ensuring zero noise from security tools is a prerequisite for using them in productive development. “It’s not just about having finite security resources,” Catucci explains. 

Developers also have finite hours to build software and complete tasks and deliver the code that they’re getting paid to deliver. Their core job is to develop software that functions, meets requirements, and works for the customer.

— Frank Catucci, CTO and Head of Security Research, Invicti Security

Taking the example of Invicti as a security tool integrated into the CI/CD pipeline at Park ‘N Fly, Schirrmacher agrees that getting accurate and actionable vulnerability information to developers is a major time-saver: “The developer doesn’t have to sit there and google to try to figure out how to resolve this vulnerability—it’s already there in the reports.”

Easier said than done: Get the basics right

Buzzwords may make it easier to discuss new trends and technologies but, when overused and misapplied, they can obscure the bigger picture. Though challenging to implement, securing your web applications and APIs ultimately boils down to always keeping the fundamentals in mind. “If I want to enhance the security posture of my apps and APIs, it’s all about understanding where they are, how they’re being developed, what needs to be there to protect them, and having all those steps done in an automated, continuous process,” concludes Catucci.

“When you’re in the IT industry, you hear these buzzwords created by marketing people, but it’s really just following best practices, and that’s what the security mindset is about,” agrees Schirrmacher. And his advice on making those best practices a reality? “Know who the leaders in the field are and make sure they’re on your team to build your security-first posture,” he says. “For a department that’s rushing aggressively to a lot of technology goals, we can’t be doubling back and second-guessing ourselves. With Invicti, I get tangible results, and I count on the results that I get, and I drive forward with my developers and continue to focus more on innovation and less on tracking down wayward security issues.”

At the end of the day, application security is all about building better applications, no matter what comes up on this month’s buzzword bingo.