Taking a holistic approach to application security [Q&A]

Application security is becoming mainstream, and that's a good thing as it means that security testing is becoming an embedded aspect of the software development life cycle (SDLC). It also means that automated security testing tools are becoming faster, more sophisticated, and better integrated, so they're less likely to slow down developers or burden them with too many trivial findings or false positives.

But as good and necessary as AppSec testing tools are, it's not nearly enough simply to buy them and run them -- you need to buy the right ones and configure them correctly so that they help build security into your SDLC without bogging it down. It's important to implement a security strategy and a plan. It’s also important to employ developers with the skills to build trust into your software -- a concept known as 'holistic AppSec'.

We spoke to Adam Brown, managing security consultant with the Synopsys Software Integrity Group, to discuss actionable strategies to implement and improve holistic AppSec programs.

BN: What do you mean by holistic AppSec and why is it important for organizations?

AB: Let's first take a step back even further and consider the history of AppSec. Looking back at the late 90s, into the early 2000s, application security testing in the SDLC consisted of writing code and pushing that app into production -- with minimal (if any) security testing prior to release. But around this time things began to change with the emergence of static application security testing (SAST). With this new strategy, people began testing the source code, moving security considerations 'left' in the development process, in other words, before being pushed into production. This novel concept of checking the code after it had been written, teams began discovering that by shifting left in the SDLC, they were actually saving a lot of time and money by not having to make changes once the code was in production -- which was a more expensive and time intensive process.

Jumping forward to today, application development isn't as straightforward. We're increasingly more reliant on open source components, for example. According to the 2022 Open Source Security and Risk Analysis (OSSRA) report, of the 2,409 codebases audited, 78 percent of the code present was open source.

What's more, today we're also now deploying many of these applications in the public, private, or hybrid cloud environments -- something that certainly didn't exist in the late 90s or early 2000s. Additionally, vulnerabilities are being introduced into the SDLC in practically every phase -- not just as developers are writing code, but as open source components are introduced, as configuration files are being written, as teams work to containerize applications to deploy them in the cloud, and so on. The point is that vulnerabilities are being introduced in a variety of ways and places. And this is what necessitates a holistic approach to security testing.

BN: 'Shifting everywhere' has become a buzzword recently. Can you elaborate a bit more on what that means?

AB: In addition to SAST which has become a mainstay in the past 15 or so years, we must also consider the open source aspect. Software composition analysis (SCA) detects open source vulnerabilities in code. Dynamic application security testing (DAST) evaluates code examines an application while it’s running, without knowledge of the application's internal interactions or designs at the system level, and with no access or visibility into the source program. Penetration testing should also be conducted before publicly releasing an application in the cloud. Teams must also check configuration files and container measures, and the list goes on and on.

As you can see, we're at a point now where we're not shifting security 'left', per se, but we need to test across the SDLC -- we're shifting security 'everywhere' as that's where vulnerabilities exist -- everywhere!

Performing the right test at the right time -- as soon as the given artifact becomes available -- is key. The artifact could be a design, code, a configuration file, scripts, APIs, container images. It could be any number of things. Testing at the right depth and breadth, as quickly as possible really shifts security everywhere.

One key aspect is how to carry out security testing in a way that doesn't lead development teams to tune it out? And that's a great question! Looking at security from the DevOps perspective, speed is key. As a DevOps engineer or a developer, your primary focus is to push new code out with differentiating features as fast and as frequently as possible, so anything hindering that velocity creates friction in the SDLC. Typically, a developer wants to avoid any friction, so automated testing that runs quickly at the right time and right depth introduces minimal friction.

However, not all software issues can be detected via automated testing. For instance, while many vulnerabilities can be detected with automated solutions, design flaws that are typically introduced very early in the SDLC -- oftentimes during the planning and design phases -- cannot be detected through such testing mechanisms. This is where threat modeling and architecture reviews come in. These techniques can discover design flaws early so that they can be resolved before automated testing comes into play.

BN: How can a CISO measure, report, and improve an organization's information security risk posture?

AB: Great question. As Peter Drucker said, "If you can't measure it, you can't improve it." So, the first step is to understand where you are in your security journey. Measure what you're doing today so you can identify gaps and areas to improve upon. One way to benchmark where you are today is by obtaining a Building Security In Maturity Model (BSIMM). The BSIMM is a data-driven model developed through analysis of real-world software security initiatives (also known as application or product security programs). BSIMM12, published in September 2021, represents the latest evolution of this detailed measuring stick for software security through the analysis of 128 organizations across nine industry verticals.

BN: What advice do you have for someone who is, say, an AppSec director with a small team and limited skills and resources?

AB: It's all about skills and tools. Hire or train the resources so that they can develop code securely and also maintain it consistently. The threat landscape is constantly changing. And as such, developer education is ongoing. Applications are expanding and evolving along with the threats. Hackers are always looking for new and different techniques to exploit vulnerabilities. And as new vulnerabilities are being identified on a near-daily basis, it’s absolutely critical to keep your development and security teams up to date with these changes. If you fall behind, you become more vulnerable to attack as applications become exposed.

And while it's easy to say, 'hire the right people', security skills are incredibly competitive. There is a well-known skills shortage to contend with. There are third-party managed services providers who can support your organization with security testing services. This is an excellent resource if you're in a regulated industry such as financial services and healthcare where certain compliance and regulatory requirements are involved. With limited budget and resources, third-party support can be a very worthwhile investment to ensure your holistic application security needs are met.

Image credit: mikkolem/depositphotos.com