Is your AppSec program developer-centric?


You need an AppSec program.

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

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

  • Coded—It needs adequate defenses and to be free from vulnerabilities.
  • Software supply chain—The same goes for anything related to your code, including libraries, products, and developer tools.
  • Operations—Your AppSec program must intercept attacks and block exploits in production.

Given the different teams, technologies and corporate cultures, there is no right way to achieve all three goals while understanding what could go wrong, the likelihood of a given problem being discovered and exploited and the potential fallout.

Choosing how to configure your AppSec program is your most important risk decision. One misstep could leave you in the dark 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 for AppSec to consider:

1. Minimal

Minimal AppSec programs use a small team to do only what is required of them by requirements that arise from external standards or from their customers. It’s a “checklist” strategy: check the boxes whether or not it provides a real level of security. This strategy is most often adopted by small and medium-sized businesses and industries that are not so dependent on applications.

Well-known AppSec standards such as OWASP, PCI, and NIST are essentially checklists. A minimal AppSec program can be successful with free or very inexpensive tools like OWASP ZAP and DependencyCheck used just before production, with perhaps an inexpensive Cloud Web Application Firewall (WAF) launched for production. Because these tools are error-prone, they result in a significant number of false negatives and missed vulnerabilities, providing a false sense of security. Conversely, such tools can create a blizzard of false positives, overwhelming teams.

The advantage: they only require small budgets and a small staff. Paradoxically, minimal AppSec programs lack visibility into true levels of vulnerability, providing a hazy and inaccurate sense of true security which can, in turn, lead to underinvestment.

2. Confrontation

In adversarial AppSec programs, teams fight for control. The security team is ramping up activity in a never-ending quest to eradicate vulnerabilities. Developers are focused on delivering apps and features as soon as possible. This approach is common in industries that rely heavily on software, such as finance, banking, e-commerce, and insurance.

Adversarial AppSec programs require large teams to perform all security activities that are applied to code, including sub-teams that focus on architecture, policy, threat modeling, static analysis, dynamic scanning, web application firewalls, training and more. However, a lack of definition of desired outcomes leaves teams analyzing endlessly without actually fixing the code. With large enough teams and budgets, it can work. However, with the accelerating pace of software releases, these programs often struggle to manage the volume of code produced and the output of their own tools. Most of the vulnerabilities they find are never sorted or patched. Roadblocks and bottlenecks are created by security testing gauntlets, gates, and backlogs, which ultimately bog down innovation, slow software releases, and frustrate development teams trying to circumvent crippling security barriers to innovation.

3. Developer-centric

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

Developer-centric programs do not ignore the great machinery of software development. Instead, they’re taking the opportunity to do security work, rather than relying on smaller, siled AppSec teams. Given developer intolerance for slow pipelines and time wasted investigating false positives, these teams are automating security testing in pipelines that use fast and highly accurate tools, enabling fast security feedback loops and reducing costs.

Developer-centric programs use Interactive Application Security Testing (IAST) to perform fully automated security and quality testing simultaneously, aligning the interests of development and security teams, ensuring they work together to extend test coverage and strengthen security throughout 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, enabling teams to respond to new vulnerabilities without the need for a fire drill for each new ___4 Shell Vulnerability.

The developer-centric security approach can be applied to projects regardless of the DevOps transformation stage they are in. For traditional projects, this approach may not be able to take advantage of automated pipelines, quality testing infrastructure, and DevOps culture, but embracing 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 caused governments around the world to prioritize AppSec. They are developing regulations and standards that go far beyond the “checklist” approach to security, rendering minimal or contradictory programs obsolete. Instead, practitioners are faced with the need to make changes, including the application 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 these tests and fixing any problems detected.
  • Software BOMs (SBOM) to provide a list of components, libraries, and tools used to create a software application, including open source and commercial software components. To track components of an application, 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 responsible for generating customer SBOMs.

As governments take that first step towards a more meaningful AppSec, now is the time to make sure you’re steering your organization on the right AppSec path.


Comments are closed.