Buying Security Tools Does Not Mean You Have an AppSec Program

intro.

Companies spend thousands of dollars on security tools like SAST, DAST, IAST, and SCA, or even “AI-powered tools”. Yet, still struggle with vulnerability backlogs, frustrated developers and security findings that never get addressed.

That’s because buying security tools does not provide you with an Application Security program.

Security tools generate findings. Programs turn these findings into actions.

why the tools work, why they don’t.

These tools provide visibility into the application security posture and can help uncover security gaps but relying on tools alone will do that to a certain extent.

Assume a perfect scenario, where the tool is properly configured and you are able to integrate it into your SDLC and get a list of findings. Any engineer can do that. But what happens next?

• How do you know the findings are valid?
• Which findings should be fixed first?
• Who owns the remediation?
• When is a risk acceptable?
• What is the security lesson learned?
• How do you prevent similar issues from recurring?
• How do you know your security posture is actually improving?

Notice how tools do not answer these questions? These are the gaps AppSec programs look to fill. The latter provide visibility, but they do not provide the people, processes and governance that are required to turn that visibility into real security improvements.

what about AI-powered tools?

AI-powered tools are getting significantly better, there are tools that now can automatically triage findings, provide remediation guidance, and even generate security tests. However, regardless of how good these tools are becoming, they remain part of the Application Security program and not a replacement for it.

The better the tools get, the more effective an AppSec program becomes.

what comes after the tools?

the program beyond the tools.

An Application Security program begins before the first scan and continues long after the last finding is remediated. Every organization will and should implement Application Security differently. The tools, technologies and processes will vary but the model remains the same. It can be visualized as follows:

AppSec Operating Model Diagram

Notice how the tools are only a subset of the program.

the 4 pillars of an AppSec program.

The point of this blog is not how to build an AppSec program, but to highlight how the tools should be used as part of a program. This can be is well represented in what i like to call the 4 pillars of a successful AppSec program:

1. People: Security is ultimetly delivered by people. Engineers, developers, product owners and security champions all play a role in reducing risk and improving security.

2. Processes: Processes make security repeatable rather than just relying on individual effort. Activities such as threat modelling,vulnerability management and security testing define how security work is performed across an organization.

3. Governance: Governance brings structure to the program. It defines ownership, establishes security standards and provides a way to measure whether an AppSec program is actually improving.

4. Tools: Finally come the tools, that provide visibility and enable the other three pillars. Without people, processes and governance, they become merely finding reporting platforms.

Notice how the tools are only 1/4th of the program.

conclusion.

Organizations fail at security not because they don’t have the right tools, They fail because nobody decided what should happen after the scanner has finished. Security tools generate findings. AppSec programs decide what those findings mean, who owns them, which ones matter and how security improves because of them.

---

This post is part of Jad’s Cybersecurity Blog.