Is Your AppSec Program Developer-Centric?

You need an AppSec program. 

Software supports your business, and you need to know that attackers can’t kick that ground out from under you. But which is the right path to take for your application security program: Minimal, adversarial or developer-centric?

Regardless of what bells and whistles you opt for, your AppSec program must secure three crucial things:

  • Code—It needs the right defenses, and to be free from vulnerabilities.
  • Software supply chain—The same goes for everything that touches your code, including libraries, products and dev tools.
  • Operations—Your AppSec program must catch attacks and block exploits in production.

Given differing teams, technologies and company cultures, there isn’t one right way to achieve all three goals while understanding what could go wrong, how likely it is that a given issue will be discovered and exploited and any potential fallout. 

Choosing how to set up your AppSec program is your most important risk decision. A misstep could leave you clueless about the true vulnerabilities in your code and with a load of security debt weighing down the software development life cycle (SDLC). The wrong approach could lead to a catastrophic data breach.  

There are three possible approaches to AppSec to consider: 

1. Minimal

Minimal AppSec programs use a small team to do only what’s required of them by the dictates that flow out of external standards or from their customers. It’s a ‘checklist’ strategy: Check off the boxes regardless of whether doing so will bring about any actual level of security. This strategy is most commonly adopted by small and mid-sized businesses and industries that don’t rely on applications all that much. 

Well-known AppSec standards such as OWASP, PCI and NIST are, essentially, checklists.  A minimal AppSec program can succeed with free or very inexpensive tools like OWASP ZAP and DependencyCheck employed just before production, with perhaps an inexpensive cloud web application firewall (WAF) thrown in for production. Because these tools are prone to error, they give rise to a significant number of false negatives and missed vulnerabilities, imparting a false sense of security. Conversely, such tools can create a blizzard of false positives, overwhelming teams. 

The upside: They only require small budgets and lean staff.  Paradoxically, minimal AppSec programs lack visibility into true levels of vulnerability, providing a fuzzy, inaccurate idea of true security that can, in turn, lead to underinvestment. 

2. Adversarial

In adversarial AppSec programs, teams wrestle for control. The security team piles on activities in a never-ending quest to eradicate vulnerabilities. Developers concentrate on delivering applications and features ASAP. This approach is common in industries that heavily rely on software, such as finance, banking, e-commerce and insurance.

Adversarial AppSec programs require big teams to execute all the security activities that get slathered onto code, including subteams that focus on architecture, policy, threat modeling, static scanning, dynamic scanning, web app firewalls, training and more. However, a lack of definition for desired outcomes leaves teams endlessly analyzing without actually fixing code. Given big enough teams and budgets, it can work. However, with the accelerating pace of software releases, these programs often struggle to handle the volume of code being produced and the output from their own tools. Most vulnerabilities they find never get triaged or remediated. Roadblocks and bottlenecks are thrown up by gauntlets of security testing, gates and backlogs, ultimately bogging down innovation, slowing down software releases and frustrating development teams who seek to bypass innovation-crippling security hoops. 

3. Developer-Centric

Developer-centric AppSec programs aim to unburden security teams by weaving security into developers’ daily work. The goal is to eventually have development teams forge an automated pipeline, infusing security into every step of the SDLC. This inclusive security approach is often called  DevSecOps or shift left. 

Developer-centric programs don’t ignore the big machinery of software development. Instead, they take advantage of it to carry out security work, rather than relying on smaller, siloed AppSec teams. Given developers’ intolerance for slowed-down pipelines and time wasted investigating false positives, these teams automate security testing in pipelines that use fast, highly accurate tools—enabling fast security feedback loops and reducing cost. 

Developer-centric programs use interactive application security testing (IAST) to simultaneously perform fully automated security and quality tests, thereby aligning the interests of development and security teams, ensuring they work together to expand test coverage and strengthen security all along the pipeline. At the same time, visibility into attacks with runtime application self-protection (RASP) provides teams with threat intelligence to identify security priorities and prevent vulnerabilities from being exploited, allowing teams to respond to new vulnerabilities without the need for a fire drill for every new ___4Shell vulnerability. 

The developer-centric security approach can be applied to projects regardless of what stage of DevOps transformation they’re in. For traditional projects, this approach may not be able to take advantage of automated pipelines, quality testing infrastructure and DevOps culture, but adopting it may be the perfect spark to launch or accelerate a transformation.

Cyber-Transparency Is the Future 

Massive supply-chain attacks including SolarWinds, Log4Shell and Spring4Shell have pushed the world’s governments to prioritize AppSec. They’re crafting regulations and standards that go far beyond the “checklist” approach to security, rendering minimal or adversarial programs obsolete. Instead, practitioners are confronting the need to make changes, including the enforcement of:

  • Threat modeling applications to demonstrate the implementation of decent application controls.
  • Application security testing (AST) to thoroughly test the security of applications and their APIs while producing evidence of such testing and remediation of any problems found.
  • Software bills of materials (SBOMs) to provide the list of components, libraries and tools used to build a software application—including open source and commercial software components. To track an application’s components—such as dependencies on open source libraries—sensors that report library data to a constantly updated database will likely come into play. In the short term, DevSecOps teams will be responsible for generating customers’ SBOMs.

As governments take this first step in the march toward more meaningful AppSec, now’s the time to ensure you’re steering your organization down the right AppSec path.