By now, everyone should have an AppSec program. Companies trust their businesses to software and need to know it can’t be used against them. At the highest level, an AppSec program must consist of three features:
- Secure code: The code must have the right defenses and remain free from vulnerabilities.
- Secure software supply chain: All libraries, products, and dev tools must be secure.
- Secure operations: The company can detect attacks and prevents exploits in production.
There’s no one way to get this right. A lot depends on how a software development organization works: the teams, processes, technology, and the company’s culture. The point of an AppSec program isn’t to eliminate risk – all business involves risk. But companies should not take “blind risks” where they don’t know what could go wrong, how likely attackers can find and exploit a problem, and the potential for bad outcomes.
Choosing a strategy for an AppSec program ranks as one of the most important risk decisions a company can make. The wrong strategy could leave the organization in the dark, with a massive amount of security debt, and possibly breached. While there are infinite strategy variations, consider which of these three types of AppSec programs best fits the company:
- Minimal AppSec programs.
Minimal application security programs use a small team to do only what’s required of them by external standards or their customers. These programs aim to “check the box” rather than achieve any particular level of actual security. Many different kinds of companies adopt this strategy, but it’s more common in small and mid-size businesses and industries where applications are less critical.
Most of the application security standards, like OWASP, PCI, and NIST are essentially checklists. So minimal AppSec programs can succeed with free or very inexpensive tools just before production and perhaps an inexpensive cloud web application firewall (WAF) for production. Because these tools are often error prone, the danger of false negatives (missed vulnerabilities) is significant, and organizations can end up with a false sense of security. At the same time, false positives can overwhelm resources and lead to large backlogs instead of remediation.
The upside of minimal AppSec programs: they require a small budget required for both people and tools. However, these programs paradoxically tend to lack a clear understanding of how vulnerable they are, and may underinvest based on incomplete information.
- Adversarial AppSec programs.
In adversarial application security programs, a siloed security team attempts to control the development team, which tries to deliver code as fast as possible. The security team has primary responsibility for AppSec, and often races to achieve “maturity” by adding more and more security activities. Development, despite controlling the code containing vulnerabilities, focuses on delivering features. It’s a common approach at large companies and more critical industries like finance, banking, e-commerce, and insurance.
The adversarial approach requires a large security team to execute all the activities. Most have various sub-teams that focus on architecture, policy, threat modeling, policy, static scanning, dynamic scanning, web app firewalls, and training. Adversarial programs always have more analysis to do, but security doesn’t actually fix code. Organizations often adopt “champions” programs to help get all the work done. However, without a clear definition of the desired outcomes, many activities have little to no measurable effect on the security of the software produced.
With a big enough team and a large budget, these adversarial AppSec programs can succeed. However, most programs struggle to handle the volume of tool output, particularly as development teams release software faster and faster. The majority of these vulnerabilities are never triaged or remediated. Security testing, gates, and backlogs lead to significant delays and bottlenecks for development teams. Ultimately these delays slow down innovation, causing frustration and leading development teams to seek exceptions and bypass security.
- Developer-centric AppSec programs.
Developer-centric application security programs strive to empower software development teams to do application security themselves, as part of their normal work. These teams seek to establish, over time, an automated pipeline that ensures strong security across the lifecycle from developer to production. Some call this type of program “DevSecOps” or “Shift Left,” but these terms aren’t perfect.
Developer-centric programs take advantage of the “big machinery” of software development to do security work, instead of smaller-siloed AppSec teams. Developers won’t tolerate slowing down pipelines or wasting time on false positives. So teams automate security testing in pipelines using fast and highly accurate tools, enabling fast security feedback loops and reducing cost. Developer-centric use interactive application security testing (IAST) to perform fully-automated security and quality tests at the same time. With this approach, development and security interests are aligned and working together on expanding test coverage and strengthening the pipeline. Visibility into attacks with runtime application self-protection (RASP) offers teams threat intelligence that informs security priorities. RASP also prevents vulnerabilities from being exploited, allowing teams to respond to new vulnerabilities without a fire drill.
The developer-centric approach remains ideal for projects at any stage of DevOps transformation. For completely traditional projects, the developer-centric approach cannot always take advantage of automated pipelines, quality testing infrastructure, and DevOps culture. On the other hand, adopting a developer-centric approach to security may function as the perfect catalyst to initiate or accelerate a DevOps transformation.
The AppSec Landscape is Transforming; Transparency is Coming
Inspired by incidents such as SolarWinds, Log4Shell, and Spring4Shell, the governments of the world are now focused on doing something about application security. New regulations and standards require a much more sophisticated approach to AppSec. NIST and PCI both require evidence that what a company does is actually effective. This means that if the company decides on a “minimal” or “adversarial” AppSec program, it probably will have to make some changes, including:
- Threat modeling: The days of checklists are over. Security teams will need to threat model applications and then demonstrate that they’ve implemented decent controls for each.
- Application security teating (AST): Security teams also need to do a much better job of testing the security of applications and APIs. They will need to provide evidence that they are testing the effectiveness of their defenses and remediating any problems found.
- Software bill of materials (SBOMs): To really get a handle on open-source usage, security teams will need sensors that report library data to an always-up-to-date database. But in the meantime, the team will need to generate an SBOM for customers.
This trend towards more meaningful application security will not likely stop here. For example, the U.S. government has been evaluating a software security labeling scheme to create visibility and drive better security from producers. Whether this becomes reality or not, it’s time to make sure the company has chosen the right strategy for application security.
Jeff Williams, co-founder and CTO, Contrast Security
